As a follow up to my previous post. The languages are (in order): Java, Groovy, Scala, Ruby, and Python.
I find the Ruby example to be the most readable, however it does use a magic variable ‘ARGF’ to help its readability. What’s surprising to me is how I find Scala not that readable. At least, not that much more readable that Java. Its shorter, so that alone is helpful, However, its a little hard to see Scala as the replacement for Java if its not substantially more readable.
I found a simple example program done in five languages. I’m not saying which is which (but one is obvious). I find the “new” languages interesting, though none of them seem to be getting significant traction in my circles.
I’m posting this now looking for comments and I’ll have a follow up post soon.
example 1
public class LongLines{
static int MAXLENGTH=70;
public static void main(String[]args)
throws Exception{
for(String arg : args){
BufferedReader br = new BufferedReader ( new FileReader ( arg ) );
String line;
for(int lineNo=0; null != (line=br.readLine()); lineNo++){
if(line.length()>MAXLENGTH){
System.out.println(arg+" line="+lineNo+" chars="+line.length());
}
}
}
}
}
example 2
def MAXLENGTH = 70
args.each { filename ->
new File(filename).eachWithIndex { line, lineNumber ->
def length = line.size()
if (length > MAXLENGTH) {
println "$filename line=$lineNumber chars=$length"
}
}
}
example 3
val MAXLENGTH = 70
def process(filename: String) =
for {
(line, lnum) <- Source.fromFile(filename).getLines.zipWithIndex
if line.length - 1 > MAXLENGTH
} println(filename+" line="+(lnum + 1)+"chars="+line.length)
example 4
MAXLENGTH = 70
ARGF.each{ |line|
if line.chomp.length > MAXLENGTH
puts "#{ARGF.filename} line=#{ARGF.lineno} chars=#{line.length}"
end
example 5
MAXLENGTH = 70
def process(filename):
for i,line in enumerate(open(filename)):
if len(line) > MAXLENGTH:
print filename, "line=", i+1, "chars=", len(line)
for f in sys.argv:
process(f)
None of these examples really show the robustness of their perspective languages I’m sure, but I think readability is very important and readable brevity is even more important (especially compared to Java).
Expect to see a new blog post here soon! I wonder what it’ll be… 
I mentioned in my previous post that I prefer Information Radiators over digital tools if done right. When Googling for a link to Information Radiators I ran across this article on InfoQ discussing the value of them. Check it out if your interested and share your thoughts in comments!
Don’t know if you saw this or not, but Atlassian has released a new version of their bug tracking tool JIRA and on top of that, they’re selling each of their products for $10 bucks (so called ‘starter‘ licenses).
I didn’t realize this until now, but they also have an agile project management tool called ‘GreenHopper‘ (which looks a lot like Mingle to me – in fact it looks like ThoughtWorks and Atlassian are duking it out product to product).
The best part is that for $10, you get 10 licenses!
I’ve used JIRA quite a bit and its not bad. I really don’t like any defect tracking software (most of them have a lot of noise for little information). However, JIRA ties in nicely with their build server Bamboo and that is huge. Being able to say what defects went into what build without manually tracking build numbers, subversion revision numbers, release numbers, etc provides a lot of value. It automatically answers the question “what’s in the latest build?”
If they’ve integrated GreenHopper in the same fashion, that would also be huge help.
In general, I’m more of a fan of whiteboards, index cards and information radiators. But, if you have a distributed team, Atlassian’s product suite for 10 bucks is definitely worth evaluating.
I’ve been spending time with Ruby a bit lately and the more I learn, the more I like it.
One of the simple things that I learned early on is that everything is an expression (including if statements).
That allows you to do things like this:
new_value = if some_flag then calculated_value else default_value end
That’s a bit contrived. You’d probably use the ternary operator instead, but you could have blocks of code or methods executed in each step.
Its not huge, but its still much better than the Java way of:
if (someFlag) {
newValue = calculatedValue
} else {
newValue = defaultValue
}
Another simple thing that is huge is that Ruby sees “nil” (aka “null” in Java) as being “false” you can do nil checks elegantly like this:
my_var = some_func_that_might_return_nil(val_to_calc) || "default"
The code will get the value of “default” if the function call returns nil. Again, in Java you’d have something like:
String myVar = someFuncThatMightReturnNull(valToCal);
if (myVar == null) {
myVar = "default";
}
Again its subtle, but it reads and flows much better to me.
When I was a kid, I worked on a small golf course my family owned (we no longer do). One of my tasks was to mow the ditch out in front of the parking lot. The parking lot was about 20 ft above the highway and therefore the ditch had a fairly step slope to it. Mowing it was a challenge. The only mower we had that was up to the task was one called Yazoo. They don’t make this model anymore, but it was a rear-steer three wheeled mower with wide wheelbase, a large mowing deck out front and a fairly low center of gravity. It was the only machine we had that could do the job.
However, doing the job was a bit of an art. The mower’s transmission was a bit old, and unless you kept your hand on the lever, forcing it into gear, it liked to slip into neutral. On top of that, the slope of the hill forced you to sit on the very edge of the uphill side of the seat or you risked sliding off. Finally, the real trick was managing the weight of the mower deck. At the steepest part, enough of the weight came off the high-side wheel. It would slip, lose traction, and cause the mower to turn uphill until you were stuck with no other option but to back down the hill and start over. The only way around this was to carefully transfer the weight off the mower-deck by lifting it slightly with the lever used to raise the deck for transport. Then, and only then, could you successfully mow the steepest part of the hill. Also, keep in mind that any wheel spinout left a nasty scar in very public view of all that drove by the golf course (and the ensuing “discussions” about my lack of mowing talents with my father).
To recap, the trick was – sit on the very edge of the seat leaning heavily to the hillside, with one hand hold the mower in gear, with the other hand hold the steering wheel, with the right foot, push carefully down on the “deck lift lever” and with the left foot balance yourself (100% OSHA approved! 
).
So what does all this have to do with software?
The other day I was working through some issues with the system we’re building. The system is a replacement for a semi-manual data entry process.
In it, there’s a lot of “if use sets flag X and Y then set flag Z to true” and a lot of “the users are trained to know that they need to add B when they see A”, etc. All of these rules the users need to remember make getting the system to work sound a lot like describing mowing the ditch with the Yazoo.
The system feels like someone observed me mowing and build a new mower to make my life easier, but missed the point. They put a button the steering wheel that as long as I push it, will hold the mower in gear – “Now you can keep both hands on the wheel”, they made the seat twice as wide – “Now you can just slide over instead of leaning on the edge”, they made the “deck lift lever” foot operated instead of hand – “Now you’ve got a pedal to push”.
If only someone had asked “why?” and kept asking “why?” instead of just observing and asking “what do you do?”. If they had, the designers would have built a mower that stayed in gear, had much better weight over the powered wheels, and… maybe an iPod holder (every project needs a little gold plating!!)
Far too often analysis seems to end at asking “What do you do?” with out asking enough about “why?” is it done. I recommend following the “5 whys” to get the root cause. This is really important! Only with that kind of questioning do business systems really deliver the productivity gains and competitive advantages that justify their costs.
There is a danger in all of this though. Its easy to copy the existing process – broken as it may be at least its known to work. As you start to build the system that strives to solve the root cause, there is the real chance that you may deviate too far from their old process and miss the mark – creating clever software that doesn’t solve the real problem. Mistakes during the analysis at this level can be disastrous.
The key to avoiding it? Agile Methods.
Get the software with the new process in front of the users ASAP – short, focused iterations. Have the users use it to do their jobs (not just “play” with it) and get their feedback… and continue to ask why.
Agile is the buzz word everybody uses these days. A lot of places claim to be doing agile development, but follow very few if any of the practices. Then when the inevitable failure comes around they blame the “Agile” for it and run back to their old, unproductive process that the never really got away from.
This is an old post from Ron Jefferies that I missed when it was posted. Just thought I’d share in case you missed it too.
Sorry I’m a day late with this post.
Usually I think of Sunday as the low point on the NFJS session list. In years past most of the sessions were kind of “ho-hum” and I’d have to admit that going into Sunday… I was thinking the same thing.
Boy was I surprised!
I started the morning listening to Matthew McCullough talk about Git version control. I’ve looked a little at “distributed version control”, but I didn’t get it, nor did I see a need for it. Was I wrong! Git is one of the coolest things I’ve seen. It really is hard to explain so I won’t try to do it here. Instead go pick up the PragProg’s book on Git here. I think approaching Git for me right now is like approaching CVS was after working with “locking VCS” systems for years. I thought it was going to be total chaos. What happens when two people edit the same file? Won’t you constantly be stepping on each other’s toes? Well, as I’m sure you all know… it doesn’t really lead to chaos, but instead gives you great flexibility and freedom. I think Git is that same freedom granting experience taken to the next level!
Next I sat in on Nate Schutta‘s talk on “Making Web Apps Suck Less”. I kinda like the names of sessions that are in your face like that. Nate is an old friend of mine. Life being the way it is, this seems to be about the only time we see each other these days and it was fun to catch up. This session was a lot of review for me. That said, it contained a lot of good ideas that it pays to be reminded of. The main point of his talk was: Usability matters! It matters way more than how elegant your code is, how nice your domain model is, etc. The UI is the application as far as your users are concerned.
The first afternoon session was back with Matthew McCullough talking about Maven. He went over a lot of intermediate level stuff with Maven and I learned a few things that I was immediately able to put to work on Monday (like setting a default goal!). It was a good presentation. It appears that Maven’s acceptance is really growing which I think is a Good Thing!
Finally, I wrapped up the day back with Nate again with his talk “Hacking your Brain for Fun and Profit.” This was a really useful talk. Nate covered a lot of stuff and it built upon some of the things I learned from Andy Hunt’s book Pragmatic Thinking and Learning. Some of the stuff was pretty basic – get sleep and exercise. The interesting part was some of the statistics to back it up. He covered the Pomodoro technique for staying focused and talked a lot about things you can do to improve your work environment. I learned the term “Walking Desk” and I’m considering building one for my office at home. I now have several more books I need to read like A Whole New Mind and Brain Rules, Mind Hacks.
I’ve got some more general thoughts about takeaways from NFJS this year, but… I’ll save that for another post.
Growing Object Oriented Software, Guided by Tests by Steve Freeman, Nat Pryce