~pperalta

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.

In this months issue of Men’s Health, they rank 100 cities for angriness. The criteria includes the following:

• percentage of men with high blood pressure
• rates of aggravated assaults
• numbers on workplace deaths from assaults and other violence
• traffic-congestion
• speeding citations

And the winner of the angry city sweepstakes? None other than Orlando, FL!

This ranking prompted an article in the Orlando Sentinel, as well as lots of commentary on the Sentinel blog. A quote from the Sentinel article:

“How can they say that of a city as beautiful as ours?” Salvagio asked. “Haven’t these people been to New York City?”

New York ranked 57 in this list, to the disbelief of many. I have not lived in NY for many years, but I do visit often. I don’t believe that New Yorkers are angry people (with the exception of most token booth clerks); I think that they are impatient. If you can adjust to the pace of life (or in some cases thrive on it) I think that you can do quite well there. Many people do, and they could not see themselves living anywhere else. Many don’t, and thus either can’t wait to get out or already have and have no intention of ever going back. That being said, New Yorkers can be quite helpful and courteous; in fact it ranked number one among world class cities in courtesy in this Reader’s Digest test.

Orlando seems to have a mix of both extremes. On the one hand, you have people that are impatient, especially while driving. They are easy to spot; those are the people that change lanes every few seconds to gain a few inches, run red lights, and tailgate. At the other extreme are those that drive on the left lane at the speed limit or below regardless of the traffic situation, and those that take 5 seconds to notice that the traffic light changed. So what we have is a mix of impatient, clueless, elderly (no offence to older people but their reflexes and eyesight aren’t what they used to be) and lost tourists all sharing the same road. There is no real public transportation to speak of so you must drive. All of this can lead to a bad driving experience. People are also not themselves behind the wheel of a car. It is much easier to flip the bird when you’re in your own car rather than doing it in someone’s face who you’re sharing a sidewalk or subway car with.

Something else that may have contributed to this ranking: crime. If you think that Orlando is safer than New York, think again!.

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.

On NPR’s All Things Considered last Friday, I enjoyed the story about the “Adult-Proof” Ringtone. A British inventor created a device called the “Mosquito teen repellent,” a device which emits a very high pitch sound that can only be heard by people under the age of 20. This device was put into place by a shop owner who was having trouble with unruly teenagers hanging around the front of his store. It didn’t take long for some of these kids to figure out that the same frequency could be used as a ring tone for cell phones. This gave high school students the ability to text message each other during class, and everyone (but the teacher) was able to hear the ring. Despite one’s opinion on whether students should be texting each other during class, this is a great hack. Even Howard Stapleton, the creator of the original device, had to admit that this story “brings a smile to my face.”