~pperalta

Here’s some news on JRuby, a version of Ruby that runs on the JVM. Sun is hiring the developers that created JRuby to work on it full time.

As told by Charles Nutter, one of the JRuby developers:

The primary goal is to give JRuby the attention it really needs. The potential for Ruby on the JVM has not escaped notice at Sun, and so we’ll be focusing on making JRuby as complete, performant, and solid as possible…

And yes, JRuby will remain as open source as it is today. It just might start moving a bit faster (as if it weren’t moving fast already!)

This is yet another indicator of the growing influence of dynamic programming as talked about by Jim Moore at the last OJUG meeting. The JRuby team should be congratulated and commended for their good work and contribution to the Java and Ruby communities.

Last Thursday Jim Moore gave a well attended session on dynamic programming with Java at OJUG. Although Java is a statically compiled (to some extent) strongly typed language, the reflection API provides opportunities for dynamic programming that scripting languages are famous for, albeit with a clunkier interface. He went through some of the scripting languages that are available for the JVM, including Groovy, Jython, JRuby, and Bean Shell.

The subject of closures came up, as Java has been taking a beating lately over the lack of closures. Bloggers are talking more about this topic since there is a proposal floating about that would add closures to Java 1.7.

Monday was my first time attending the Orlando Ruby Users Group. I saw some familiar faces from OJUG, including Mike, Dominic, and Gregg, who runs the show at ORUG. He gave a great recap of the meeting on the ORUG site. There were two presentations, one by Nathan Bibler about a Rails i18n plugin, and the other by Robert Depmsey on project management for really small (as in one person) development project management. He introduced us to Basecamp, a hosted service by 37signals to collaborate with end users, as well as FreshBooks which is hosted invoicing software.

One of the coolest things that was mentioned was hackfest. This is where a bunch of developers get together and hack out some software in a day. Think of it as a lan party, except that you get to code instead of frag. The last hackfest resulted in a Google maps mashup, even though no participants had ever done one before. The next one is on September 9th, and they will attempt to create the rails version of PHPbb.

I have to say that I’m impressed with the group so far. This is a true grassroots organization, and the attendees are very bright and enthusiastic. Hopefully I’ll get a chance to learn some more Ruby so that I can keep up with them!

The No Fluff Just Stuff conference came to Orlando two weeks ago, and as always it did not disappoint. Although the turnout this year was smaller than last year, the quality of the conference was top notch. Many of the presentations for this conference addressed the Agile software development process.

A major aspect of software development that I enjoy is to witness satisfied customers using my software. In spite of heavy weight processes, endless meetings, feature creep, blown deadlines, and other disruptions that don’t help with creating software, finally delivering the product is an immensely rewarding experience.

This is why Agile appeals to me. As a software developer, the only thing that matters at the end of the day is whether you have software to deliver, and that is one of the major principles of Agile. Many other aspects of Agile were covered in depth by Bruce Tate, Neal Ford, and Venkat Subramaniam. I will attempt to give a brief summary of the major points.

As previously mentioned, working software is the highest priority in the Agile process. To that end, progress is measured from the customer’s perspective based on the number of user stories completed. Note that user stories are not the same as requirements. A requirement usually reads something like this: “The system shall <insert function here>.” Stories are more in depth, and speak in terms of the needs of the end user as opposed to a bullet list of functions. This provides a deeper understanding of the expectations that users have for the system.

So what is the definition of a completed story? The answer, quite succinctly, is a completed screen. End users don’t care about your DAOs or your automated builds or passing unit tests (more on that later.) They want software that they can actually use. This provides an incentive to build software in vertical stacks instead of horizontal slices. For example, if writing a distributed application with a Swing client, build the DAOs, services, and UI screens required for a piece of functionality instead of sitting down and trying to write all of the DAOs up front (or even worse, the entire UI.) This has two benefits: for one, it allows the customer to see progress after an iteration (as opposed to just having a bunch of DAOs.) In addition, it helps build confidence that the architecture and design of the system will actually work.

This brings up another point. Those that architect a system should also be helping to code it. For one, if you are coding all the time then you are painfully aware of leaky abstractions. Decisions that are made at the architectural level will have an impact all the way to the code, and the only way to understand that impact is to have the skill and desire to write code. Again, the most important artifact is working code, and you can’t code in PowerPoint! We see examples of this all of the time. For instance, projects like Spring, Hibernate, and Ruby on Rails all evolved from actual working production code. These are projects that were essentially refactored to be generic enough to be usable by the masses. The unpopular EJB 1.x and 2.x specs were designed by committee, and only really put to the test after release.

Test driven development is a major factor in the success of an Agile project. As time passes and iterations are completed, aspects of the project will change. Perhaps the customer will request a modification to a story. Or some new stories have similar functionality to older stories, so you have duplicate algorithms (or copy/paste code.) In these instances, TDD will help when it comes to refactoring code in order to address these issues. By having a test that expresses the expectation of a story, this greatly increases your confidence in the code that provides the functionality. When removing duplicate code or splitting a method into two or three, having a test that exercises that code will verify that the refactoring didn’t change the behavior of the system.

Tools such as unit tests, code coverage, and dependency analysts are a great measure for the overall health of a project. Note that these metrics are strictly for use by development. (Mis)use of these metrics by management would be misguided, as they do not provide a relevant measurement of progress. It should be emphasized that completed stories are the metric that truly matters, not achieving 100% code coverage.

Last weekend I picked up My Job Went To India (And All I Got Was This Lousy Book) by Chad Fowler. I must admit that I found the title and the cover to be a bit cheesy, but I decided to look through it anyway. (Insert cliché here about judging a book by its cover.) While reading it in the bookstore, I found it to be such a good read that I decided to bring it home. (In general, if I can’t put down a book at the bookstore, that is the deciding factor on whether I decide to purchase it.) It is full of…well…pragmatic advice on how to improve and enjoy yourself and your career in software development. As I was reading through it, I thought to myself “this really belongs in The Pragmatic Programmers” series. It was only after bringing it home that I realized that not only did it already belong (again, the cover does not look like the other books in the series), but that the author is a coauthor of Programming Ruby, which is another book that I’m going through at the moment.

One of the most interesting anecdotes that Chad gives is when he is going through hundreds of resumes looking for Java developers. After having spent many hours going through candidates that were unqualified, he suggests adding Smalltalk as one of the required keywords for the resume search. Even though Smalltalk won’t be used in the project, using this technique he is able to narrow the resumes down considerably. The developers that make this cut turn out to be “diamonds in the rough.” These are the guys that really enjoy to program, and people that enjoy to program are usually pretty good at it.

Languages are not just a set of instructions to a computer, they are also a medium to express thought on problem solving. It is not hard for a seasoned developer to pick up a new language, but it does take a little more time to think in that language. For a simple example (and a bit of a digression), take a for loop in Java:

for (int i = 0; i < 5; i++) {
System.out.println("Hello");
}

Here’s how to express this loop in Ruby (thanks, Why the Lucky Stiff!):

5.times { print "Hello" }

In the Java loop, we are incrementing an integer variable and printing to the console during each iteration. In the Ruby loop, the number 5 is an actual object, and it contains a method called “times” that will execute the block of code that is passed to it the number of times represented by the integer object. This is reminicent of the Template design pattern that I’m used to using with JdbcTemplate in Spring, except that this is built into the Ruby language and this is a much more concise way of expressing it.

Back on topic, Chad makes the argument that knowing multiple languages makes you more attractive to perspective employers. Via his anecdote, he also demonstrates that this is a very effective way to filter out resumes when looking for good developers. Other than the career implications, being able to think of and express solutions in multiple languages enhances your creativity and effectiveness for solving everyday problems.