We all know the theory of distributed computing: by dividing tasks among several computers rather than having all processes originating from one central computer, we can increase overall throughput. The problem is that in reality the actual implementation of such a scheme is often quite complex. Technologies like EJB were supposed to make it easier, but they proved extremely intrusive to both the design and development process. Fortunately, the emergence of JVM-level clustering technologies like Terracotta into the mainstream now provides a viable alternative.

There are two programming buzz areas that get a lot of thought mileage on the interweb at the moment: Dynamic typed languages; and languages that support concurrent programming. Both are important concepts that are driven by their own good reasons, but they exist in isolation in separate communities with very little overlap. Each is pursuing their own goals separately of the problems the other is trying to address (and making great progress with).

The one thing I've always liked when working with static type systems, and one that is often glossed over when discussing dynamic typing systems, is how easily tools can interpret and navigate code. When coding Java in Eclipse, it's amazing how easy understanding a massive code base can become. You've got simple hyperlink navigation, sophisticated refactorings, and smart code analysis that can show you what is called from where and how. Even interfaces and figuring out which implementation is used (which is kinda dynamic typing for Java) can be groked easily with a good IDE.

Recently there's been a lot of discussion around how processes in Erlang could be considered to be objects and that Erlang can therefore be considered an object oriented language. I really think that's stretching the definition. They're kind of right, but in the same way that the people who saw a vision of the Virgin Mary in a cheese sandwich were right.

Like most bits of Rails, ActionMailer has an elegant and coder friendly interface. With a bit of set up, it's remarkably quick and easy to get running from vanilla Ruby outside of Rails.

A while back I wrote about my frustrations trying to get Ruby to talk to Oracle on Mac OS X. I've tried a new approach using JRuby and ActiveRecord-JDBC with great success.

After reading about benchmarking various languages generating fractal patterns, I tried throwing the Ruby code at both the standard MRI Ruby and JRuby interpreters to compare relative performance. This is all totally unscientific, but is interesting all the same.

Despite my last post, I'm not actually a raving anti JavaFX maniac - the script language itself is really pretty cool. Here is a summary of some of the key language features.

Rant about the how the current crop of Rich Internet Application frameworks lack enthusiasm and support from the development community, and mostly seem to be a hollow marketing push with old ideas from Microsoft, Sun and Adobe.

Shine Technologies (my workplace) has sent a couple of international jet setters over to San Francisco for this year's JavaOne conference. Mark Johnson and Ben Teese have been writing about their experiences on Shine's blog. Reports on various presentations and the keynote are covered.

Developers are lazy, and will generally choose the solution that meets fits the constraints with the least amount of work (the path of least resistance). By understanding this, the process can be tweaked to produce the desired result - either by making the undesirable paths harder, or making the desirable ones easier.

Very comprehensive overview of JRuby and how it fits in with Java and Ruby.

Follow up to the responses received from the original "JRuby Can Save Swing" article, which itself proposed that JRuby could be used to make Swing development much easier and more productive.

Summary of a recent talk given by Martin Fowler. Covers the good, bad, and near future of Java.

Swing is hard. Needlessly so. With the advent of scripting support on the JVM, why not wrap a light and elegant Ruby layer around Swing? Why keep coding Swing at it's lowest API level using a heavy-weight language like Java?

Details of a method for adding Java style Property Change Listener suppot to any ruby class

Environment setup is one of the worst aspects of software development. You can get all hyped up about the latest and greatest technology and techniques, but at some point you've got to get your environment set up so you can use them. I've spent a good part of this afternoon trying to get Ruby to work with an Oracle database on my Mac OS X box.