Sometimes the simplest solutions are the best solutions

How many times have you seen or written code like this (in any language):

[code]
if(someFlag){
someFlag = false;
}
else{
someFlag = true;
}
[/code]

I’ve written code myself like this many times, and seen it in many places too. Usually for toggling display of some content: “if it’s hidden, show it; otherwise, hide it”.

Recently I’ve been spending a lot of time learning and coding an app using AngularJS and I keep seeing this pattern repeatedly in many code examples:

[code]

someFlag = !someFlag;

[/code]

When I first saw a statement like this it took me a couple of seconds to understand the purpose, but then when it clicked I laughed out loud in one of those ‘ahah!’ moments, as the outcome of this code is exactly the same as the code above.

When we translate design to code, sometimes thinking in logical, procedural steps hurts the ability to translate to code that best uses the features of the language or platform that you are running on. Sometimes the simplest solutions really are the best solutions, although maybe it takes a different thought process to get there.

Time to dig into Scala

I’ve been putting it off for a while, but I think it’s time to get the Scala plugin for Eclipse installed and start to work through some tutorials to see what the buzz is about Scala. In particular I’m interested to see what approach the Lift framework takes for building webapps, and how this compares with the endless list of webapp frameworks we have in Java-land.

There’s been a lot of stirring recently regarding replacements for Java – the trouble is, so many enterprises have major investments in Java based systems at this point. Java (the language) will not go away any time soon. The change that’s about to happen is that I think alternatives to the Java language are on the cusp of being realistic alternatives for new development projects – Ruby, JRuby, Scala etc.

Programming languages are an interesting thing when it comes to making a choice which to use for a new project. For small projects with a small development team (<5 developers) the choice is less about finding resources who have experience in language XYZ, it’s more important to think about what resources you’ll have around in the future who have experience with obscure language XYZ which the 2 man developer team originally chose because they read some article about it and it sounded cool at the time.

For larger development efforts, if you’re staffing a 100 developer team it’s obviously more important initially to pick a language for which you can find 100 developers that have experience in that language. At this point, Java is obviously a natural choice since you can easily find plenty of Java developers in most metropolitan areas. I challenge you to find 100 Scala developers in any city who are available to start a new project next week. That’s going to be a tough challenge for your recruiting team.

I can remember around 1996 when Java first started to get attention as a ‘language for the Web’ that at the time it was an interesting curiosity but definitely not a language you’d pick to use on a new development project. It took a couple more years before it matured and started to see more use on the server-side rather than for web page front ends using Applets. At this point in time, Java has been called ‘the new COBOL’. You’ll face little or no resistance if you recommend a Java-based solution for a new web-based enterprise system (unless you’re already a Microsoft shop in which case you be using C# and .NET etc).

The interesting thing about Ruby and Scala is that as languages they’re both already been around for years. Scala takes an interesting approach in that it capitalizes on the years of investment developing and refining the JVM platform, and then takes a blend of OO features and syntax from Java and mixes in some Functional style programming. Whereas Java took the good parts of C++ and left out some of the not-so-good features, Scala seems to be going down the same path for the evolution of Java – takes some good features, leaves out not-so-good stuff (static properties, primitives, non-OO features), and then builds upon it, and adds Functional language features too.

I still think it’s too early for Scala to be recommended for a large scale development project (namely because of the lack of developers with Scala experience), but it will be interesting to see in the next few years whether it starts to make inroads and take over from Java.

What’s the significance of Nov 18th 1883 to software development in the US?

On November 18th 1883, the US adopted standardized time zones across the US. From a software development point of view, this means there is an interesting shift in the time zone offsets at this point in time – for example, after this date, Pacific Time is GMT-8, whereas before this date, Pacific time was GMT-7:52:58 (approx).

This becomes more interesting when dealing with Date apis that respect this date or not. For example, JodaTime does, but java.util.Date does not. When persisting dates to a database table via JDBC, JDBC does not know about the JodaTime types, it only knows about Types.DATE and Types.TIMESTAMP. Therefore this is there it starts to get wierd.

If you go DateTime -> Date -> Table, and then Table -> Date -> DateTime – you’re all good.

If you directly populate dates in the tables e.g. from scripts of other systems prior to 1883 though, JodaTime puts it’s offset on these dates when you retrieve them back out and you end up with dates and times that are off by 7mins 2 secs (approx).

An interesting issue that’s worth knowing about if you’re dealing with dates in the past.