Twenty years ago, my first job was to assist visitors of the Computerette — something of an Internet café without the Internet. This small company had been started by someone who did freelance jobs coding some very obscure Cobol dialect. While he kept doing his well-paid job, he hired me to take care of the shop. Besides this rather dull work, he let me do small programming jobs on the side. For this, he introduced me to Clipper, the compiled variant of the then-popular dBASE III language. Himself, he would not dream of quitting his Cobol job for this; even though he loved Clipper and Clipper jobs were abundant at the time. “It’s not about the language,” he told me, “it’s about the problems you’re asked to solve.” While I was coding my first address book application for a start-up law firm, his software was controlling the oil refineries of Pernis (the Rotterdam harbour). I did not understand him back then. Who ever would want to keep coding in Cobol, the language of the past?

At yesterday’s RubyEnRails 2008 conference, a friend told me that I’m in a golden cage: getting paid more in my current job for coding Java, than I could get in another job for doing Ruby/Rails — preventing me from switching to Ruby/Rails. His remark reminded me of my old boss who did not want to switch to Clipper. Am I turning into him? Am I coding in the language of the past? Will I still be doing so 10 or 20 years from now?

Whatever. It’s not about the language.

JavaBlackBelt is a fast growing community whose members take tests to assess their skills in various Java-related topics. The tests themselves are created also by the site’s members. A small number of Ruby enthusiasts is currently working to add a Ruby exam to this Java-oriented site. I interviewed Mr. John Rizzo, one of JavaBlackBelt’s founders, and asked him what JavaBlackBelt has to offer Java and Ruby developers.

Danny: Why do we need JavaBlackBelt if we already have Sun’s Java certificates?

John: We felt that, in the real world, with real teams and real projects, we have no way to assess, in an objective way, Java developers. Java requires so many things to learn. Sun is responsible for many Java apis, like JMS, Java2D, Swing, JDBC, servlet, EJB and so on. But their exam covers only a very small part of that. For example, the Sun Certified Java Programmer (SCJP) is a coverage of a small part of Java SE; JDBC, simple database access, is not even in it. And there are so many other tools and apis that are covered by other groups: Jakarta, Eclipse, jBoss. Their core business is developing their framework, not doing certifications. So there is nothing for this. If you see what a Java developer has to learn the first six months, or the first one or two years, to be productive in a project… All these technologies, and certification covers a very small part, maybe less than 10%. This is the first reason.

The other reason is that when you have three years of experience as a Java developer, and you’d like to do the first Sun certification (SCJP), you still need to study for a few days before you can take the test. Is that normal? You are an experienced developer, and you need to study, before Sun recognizes your skills. That’s why the exams on JavaBlackBelt are made keeping in mind that the candidates have all the resources available. Books, Eclipse, Google, whatever. They can search the web, search the Java apis, they can try things out in Eclipse. They’re only limited by time. They don’t have to remember things by heart. But the exams are hard, even with that. It depends on the exams, we also have basic exams, to help the beginners and to encourage the beginner to learn. Like Ruby Basic for example. And then we have more advanced exams; not just one big certification with a lot of questions.
Continue Reading »

After yet another inspiring presentation by Romain Guy at last year’s JavaPolis, I’ve taken more interest in programming Swing. I programmed desktop applications for many years, using mostly Delphi. Now, after some years of web application development, discovering Swing is like finding back a long-lost friend. Why oh why did we ever turn our backs on desktop programming and open this Pandora’s box of browser incompatibilities, stylesheet hacking, a multitude of web frameworks, html files full of JavaScript, JSP files full of scriptlets, back-button-workarounds etcetera etcetera?[1] Fortunately for me, after about ten years of existence, Swing finally has a decent GUI builder as well: Matisse–even if I have to endure NetBeans to use it. At the moment, I’m working on a Swing-based variant of Picasa‘s auto-collage function (which is a nice idea but only has limited functionality).

You will probably know that Swing GUIs can be programmed as well as designed with a GUI builder. That is generally not a very pleasant activity: the code is verbose and you don’t see what you get right away. Following the ancient principle of “use the best programming language for the job, and if there isn’t one, invent a new language”, Chris Oliver developed F3, a Java-based declarative language for GUI development. In other words, a fine example of a Domain Specific Language. So maybe it was only a matter of time before someone took Ruby (great for implementing DSLs), JRuby and F3, connected the dots, and created an Ruby implementation of F3 for the Java platform. That someone is Jean Lazarou, and he named his creation Swiby. Swiby looks something like this:

require 'swiby'

class HelloWorldModel
  attr_accessor :saying
end

model = HelloWorldModel.new
model.saying = "Hello World"

Frame {
  title "Hello World F3"
  width 200
  content {
    Label {
      text bind(model, :saying)
    }
  }
  visible true
}

The question remains what you would use this for. For designing GUIs, I would still want to use a GUI builder like Matisse rather than having to code everything myself. Maybe the GUI builder could be made to generate F3/Swiby instead of spitting out endless lines of badly formatted Java gibberish. Maybe it could be made to work with a Ruby GUI library, for fast prototyping. Or maybe the Swiby code could even be used to generate… a web application?

[1] I’m not serious here, of course. I really love the browser and everything that comes with it.

Five days after my nightly arrival in beautiful Antwerpen, I drove back over those same dreary roads to Holland, to my home. Five days that have flown by. I’ve been completely submerged in mixture of Java and a little Ruby. Everything I heard about, everything I spoke about, even dreamt about, was Java. I’ve got so many new ideas, so many things I’m eager to check out or try out:

• SwingLabs
• Apache Tuscany
• Custom HTML tags in Ruby (can I get them into Rails?)
• Could Rails have a web admin console like I saw at the Phobos demo?
• Deploying a Rails app on GlassFish
• Matisse on NetBeans
• JRuby on Spring 2.0
• And last but not least find out more about the Closures in Java proposal

Many thanks go to Stephan Janssen and the rest of the JavaPolis team for organizing this superb event! I’ll be back next year.

Okay, okay, I’ll humbly admit I was wrong. A little bit. About ehm… that Groovy thing. An inspiring session by … about the Grails framework made me see things from a different perspective. There’s actually some quite nice features in Grails that could well be of use in Rails (or in some cases, Rails on JRuby).

For example, I’ve been looking for some time now for a system that would allow custom html tags in Rails’ rhtml files. The idea is to allow for all sorts of html tags, for example

  <r:for_each list="some_list" var="item">
    <li><%= @item %></li>
  </r:for_each>

This would then trigger a method named for_each (e.g. in a app/helpers/application_tags class) which could process the passed inner html block in any way you want (in this example, probably looping through some_list). Even though Ruby code in rhtml is usually not hard to read, it would still clean things up a bit and get rid of some duplicate code.

In short, it turns out that Grails already has this. Grails also has deployment to war (which is still experimental in JRuby, it’s the first thing I’ll try out once I’m back home from Belgium). And because Grails is built on top of Spring and Hibernate (amongst others), it’s easy to script-prototype your model classes that could be Hibernate-mapped or EJB3s. To be honest, that one isn’t any more difficult in JRuby if you see how easy it is to call any EJB.

Another interesting Groovy/Grails language construct I saw:

Book.get(params.id)?.true

The interesting part here is the question mark operator. This will (apparently) check if get() returns null, and if so, prohibit an error being thrown. There was an interesting discussion about this some time ago on rubyenrails.nl (in Dutch; I’ll post the link when I’m home), looking for ways to do this in Ruby.

All in all, I’m still not comfortable with the Groovy syntax (too many curly braces and arrows; and I’m missing semicolons at the end-of-lines–it’s not Ruby after all!) but there’s definitely things to learn and shamelessly steal from those Groovy and Grails guys.