Lately I've been having a lot of fun playing around with the mingle api via active resource. I've developed a couple of small projects including one for reporting feature prioritization, as well a release notes generator. As it turns out, the release notes generator is a pretty big hit with our software support staff and the new feature requests are rolling in. Most recently a new feature required accessing the comment history of a story.

Now for the ruby part. To review; in part one of the Ruby in Java with Maven series, we built a simple maven project which executes java 6 code and fires off a simple javascript using the built in javascript script engine. Now let's try another language. If you recall from part 1, the only supported engine was the "Mozilla Rhino" engine which is the built in javascript engine. In order to run ruby, we're going to have to add support for Jruby.

Java is a great language. It has many positive attributes, however one thing java is not good for is fast development. Now that I'm older and a little more impatient, I prefer to work in dynamic languages largely because of their short feedback cycle and instant gratification. Over the last few years, there's been a movement towards the ability to run other languages within the JVM. This makes a lot of sense with the JVM being arguably the best part of Java. It makes it possible to use a dynamic language but still get some of the robustness and scalability of Java.

The project

I have some very simple release data that I would like to report to my executive team on a weekly basis. The data includes the target release date, and the feature sets and feature set benefits that are targeted for delivery in the current release. Fortunately all of this information is stored in our project management and collaboration system as a result of our release and iteration planning procedure.

My sister and I used to fight constantly growing up. Maybe it was personality differences or maybe sibling jealousy, but whatever it was it certainly wasn't me being annoying. Sometimes it would get so bad that my mother would break out the unorthodox parenting tactics. When she had finally had enough and standard practices failed to quell the argument, she would send us both to one of our rooms and say, "Don't come out until someone is bleeding." Then she would shut the door and walk away.

Sometime last year I came across Dave Thomas's Code Kata page and I thought, what a great way to learn a new language, or even just shake the rust off. Eventually I learned that some teams practice code kata's together. This is known as a code dojo. Since I enjoy team building possibly more than I like software building, dojo's make kata that much more intriguing.

Yes it's true. Managers love metrics. Some managers may even attend clandestine weekend meetings to come up with more useless numbers to apply to the work that developers do. As we know from the days of LOC (Lines Of Code), these fail to capture the value or productivity of developers and sometimes mismotivate developers.

There is a lighter side of metrics though. They do have a critical place in software development, however it's not for managers to measure their developers rather for developers to understand their code.

As a programmer I never had the pleasure of working on a team that had effective code reviews. In fact, I don't ever recall being in a code review. I certainly remember a lot of lip service being paid to the importance of code reviews, just never actually saw one. Maybe that was because of bad management, or maybe code reviews weren't as important as we thought, or maybe we tried and failed, or maybe we were having code reviews every day but they were so horribly unrecognizable that I just thought they were something else.