Take a ride on a Locomotive for the simplest Ruby-on-Rails-on-Mac experience May 15, 2006
Posted by James Webster in : apple, development , 2 commentsIf you are a Mac developer hankering for some Rails fun and games, and haven’t checked out Locomotive yet, go now! It has just been updated to version 2.0 and it is without a doubt the simplest and most complete way to do Rails development on a Mac. It includes a helpful GUI for creating new Rails apps, starting and stopping them. It also has a number of useful modules compiled in; most notably ImageMagick and its Ruby binding RMagick. By themselves these things are a real beeyotch to get built but no problem whatsoever with Locomotive. One handy new feature in the latest version is the inclusion of a command-line tool for interacting with Rails applications.
Now if only Steve Jobs would hurry up and introduce the MacBook I might have a slightly faster development environment than this Mac mini that’s just SO ‘05!
Reflective parameter names in Java 6 May 8, 2006
Posted by James Webster in : java , add a commentUpdate: Paul has summarized the conversation about this issue but disappointingly it looks like the Java 6 team may be dropping this feature. It is a great shame that Java is becoming less and less willing to evolve, especially when the opposite is needed to compete against C#/.Net, Python, Ruby et al. Aside from an arguably broken implementation of generics, what did Java 1.5 bring to the table that C# 1.0’s syntax didn’t already have? (Yes, there is more to the platform choice than language syntax but that’s another conversation) Don Box is acutely aware of Ruby’s growing mind share and the reality that it has already started to take market share from the incumbents. Hopefully the Java 6 team will reconsider their decision.
My colleague Paul Hammant is asking about how we would like reflective access to parameter names to work (if it is indeed implemented) in Mustang.
He asks whether this should be enabled via an annotation or via a javac compiler flag. Via annotations feels like the right way to me (compiler flags are SOOOOO ’90s) but preferably with a way to enable parameter name access for a whole class/package/package hierarchy with the placement of a single annotation in an appropriate location. I am presuming Java 5 annotations have a similar mechanism to C# AssemblyInfo.cs and its behaviour with .Net attributes.
In addition to the possible uses that Paul defines; IDE clues, interface definitions for remoting/web services and AOP frameworks; I wonder whether this feature, inconjunction with an AOP framework, might allow a way to introduce keyword arguments with defaults, in a similar fashion to Python and Ruby?
In what other ways might this feature be potentially useful?
Java 5 syntax tricks to keep you DRY May 2, 2006
Posted by James Webster in : java , 7 commentsUpdate: I have changed the example a bit…
Which do you think is more readable; this…
someMethod(23, new String[]{"one", "two", "three"}, 42);
…or this…
someMethod(23, array("one", "two", "three"), 42);
The latter can be achieved in Java 5 with the following method leveraging both varargs and generics;
<T> T[] array(T... objects) {
return objects;
}
I’m finding it useful to help maintain DRYness as the type of the array is stated once rather than twice. Of course, the array argument could be shifted to the last argument and varargs used on the method being called (if it can be implemented in Java 5). Its impossible to completely remove this sort of duplication in Java but not impossible to remove it from statically typed languages altogether. Have a look at Boo, a Python-esque language that targets .Net and Mono and supports type inference.
My examples were originally…
String[] arrayOfStrings = new String[]{"one", "two", "three"};
and
String[] arrayOfStrings = array("one", "two", "three");
As Brandon correctly identifies in the comments, the following is syntactically valid prior to Java 1.5 anyway…
String[] arrayOfStrings = {"one", "two", "three"};