I’m being urged to choose sides. Colleagues say I should specialize in either frontend or backend development. I’ve never liked to commit to any specialization. Partly because I’ve always admired the renaissance ideal of the uomo universale who knows and does it all. But also because, when I started out my career, 20 years ago, jobs were a lot scarcer then nowadays, so you couldn’t be all too picky about which job you wanted to do. Specialization is nice until the market changes and you find yourself out of a job because you happened to choose the wrong side.

All this might explain why I enjoyed a full day of Swing yesterday at JavaPolis, even though my day job is now exclusively about backend domain design and coding (and I love it, I love being in the silend, cold spelonks that the domain is, where everything perfectly fits, everything is under tight control with unit tests, and the evil outside world of user interfacing is far far away).

To be honest, the alternatives didn’t appeal to me either. A session on POJO programming–who on earth can talk about plain old POJOs for three whole hours? Or what about a Spring 2 session? Never mind, I’ll read the release notes. Now Swing, that’s something you want to see live. Not that there were many flashy demos though; just a very cool mashup that allows you to map your holiday snapshots to a route you can draw yourself on a Google map. Most of the time was filled with new Java SE 6 features, tips & tricks, a useful tutorial on Java Web Start, and an interesting but theoretical presentation on humane user interfaces (by Romain Guy).

Those new SE 6 features, they’re nice enough, sure; but it made me think back to my Delphi days, about 10 years ago, when we already had things like date pickers and hyperlinkable labels. In a way, it’s really the same as with all the fancy Ajax stuff. We’re all so excited about a web page that can behave like a desktop application; but if we’re actually developing a desktop application, then why bother with web pages when we could have made life easier and used Swing instead?

When expectations are high, you’re invariably up for some disappointment. Charles and Tom were unable to demo Rails-in-a-war-on-Glassfish; but at least they gave a warning in advance. But I definitely expected something more–or rather something else–from Eric Evans’ university session on domain-driven design (ddd).

The afternoon session on scripting languages went well enough anyway–or at least, the JRuby part did. The session took off with a theoretical explanation of JSR-2something (the support for scripting languages in Java SE). After that, Charles and Tom got their chance to warm up the Java-minded public for all goodness of Ruby. It took a little while for them to get comfortable, but then Tom was at the keyboard showing the simplicity of building a small Rails app from scratch; and Charles got the flow of the presentation going, explaining what Tom was doing and going into JRuby details. The hour flew by for most of the audience. When I got back after the half our break, Charles and Tom were still answering questions.

Charles and Tom showing some well-known faces

Now you have to believe me, in the 90 minutes of Groovy that followed, I did keep an open mind. I tried to look at the code samples objectively. I tried to admire the work that has gone into creating a dynamic variant of Java. I really tried hard to imagine a scenario where I would be tempted to remotely consider using Groovy in a real-world app. Okay, and I was also just a little bit busy trying to get my laptop to talk to the JavaPolis wireless network, which wasn’t easy either. But at least that one I finally succeeded at. The Groovy thing–I’m afraid it’s not for me. It gives me the worst of both worlds: no sweet Ruby syntax, and on top of that uglified Java syntax as well. Maybe next time I’ll see the light. I promise to keep an open mind.

The thing that most disappointed me however, was Eric Evans’ morning session on domain-driven design. Not that it was a bad presentation, not at all. Maybe it’s all about expectations. I expected an introduction into ddd. What is it, what’s so great about it, why should we use it, what lessons have been learned, what tips can a ddd guru give us? Instead we got a session about domain modeling: how do we get from use case to domain model. And also, if we have multiple models within our application/organization, what patterns can we discern regarding the interfacing between those models and the teams that design them? Interesting enough, no problem there; but what does this have to do with ddd? Domain modeling like this can well be done without any domain-drivenness. Or can it? I’ll know more in a week or two, when Evans’ book that I ordered will arrive.

Just arrived in Antwerp, Belgium, for the JavaPolis 2006 conference which starts tomorrow morning. Same venue (Metropolis, where I stopped on the way to pick up this year’s goodies bag), same hotel (Astrid–yeah I know it has a tacky name but it’s really not that cheap). Fortunately, the state of Antwerp’s wireless networking has advanced in a year’s time; I now have free wifi in my hotel room as well as at the JavaPolis venue. Allowing me to write this short blog entry.
And so I won’t be accused of blogging just for the sake of it, just because I can blog, I will list the university sessions that I’ll be attending tomorrow.

• First off is Eric Evans, talking about domain-driven design. This promises to be not only a theoretical introduction to the subject, but also an interactive domain modeling session. I’ve been looking forward to hear more about ddd since visiting Sogyo’s evening session two weeks ago. Especially as that session has left me confused whether Rails might be seen as a domain-driven development framework. I’m still not convinced; maybe tomorrow’s session will bring some clarification–and new arguments!
• In the afternoon, I’ll be at room 4 for the Dynamic Languages session. More in particular, for the JRuby part of that one. Originally, this session was scheduled as an all-JRuby university session; but somehow, the Groovy guys have managed to squeeze their way in as well. I really don’t see the point of Groovy, other than proving that Java can be as cool as Ruby if only we mutilate the language enough and make it dynamic. I promise I’ll keep an open mind during their session tomorrow, though I don’t think I’ll be able to take in anything after seeing Charles and Tom perform the miracle of Rails-in-a-war-on-Glassfish.

The all new JavaPolis 2006 bag

Yesterday evening I attended a session on domain-driven design (ddd) at Sogyo‘s offices, a nicely converted farmhouse located somewhere in the center of Holland. I was amazed to hear Ruby and Rails being used as an example of domain-driven development. One of the presenters even claimed that Dutch Rubyists Remco and Michiel (who reached 2nd place at this year’s RAD Race, a programming contest) had done so well because they were able to work domain-driven, thanks to Rails.

Surely he was joking. If there is one data-centric framework out there at the moment, it has to be (my beloved) Ruby on Rails. Let’s see…

• Rails’ “domain” classes (the model) are literally an implementation of the Active Record pattern, which has a direct coupling to corresponding database tables.
• As a result, Rails’ model classes correspond directly to database tables; a change in your table (e.g. an extra field) is automatically a change in your model class.
• Worst of all, DHH is actually on a mission to model the whole world under the constraints of CRUD.

I really don’t see how you can call this domain-driven. This is not to say that you couldn’t implement a domain model (as in ddd) in Ruby. But in my opinion, that is not what Rails is about. Rails is limited to the presentation layer, so its model is nothing more than a view model. For small scale applications that’s good enough. But if you need your business logic to be available independantly, to be accessible from multiple views (presentation layer applications), you’ll want to put that business logic in a separate layer, not in the model of one of those views. That is how I see “enterprise Rails”: as a tool to rapidly develop presentation side applications that use and combine existing business services (WS, EJB) (using JRuby on a Java application server).

The question remains if a domain model could be implemented in Ruby (not Rails). Technically, you could, of course. But would I want to? I’m not sure. It’s very reassuring to have the Java compiler checking your back and Eclipse’s refactoring tools at your disposal. You’d have to have some very tight unit testing to replace those and still feel safe about any changes you make. I mean, we’re potentially talking about a large company’s vital business rules here. Would I feel comfortable duck-typing those? On the other hand, there’s Ruby’s excellent DSL capabilities that would come in very handy for specifying exactly those business rules. What do you think?

After being completely flushed away by heavy rain last week, from the streets of Toulouse, M. and I now find ourselves in the city of Oslo. She has to work, I get to play. Or at least to wander around the city a little. Disappointed by the (walking) distance from the hotel to the Munch Museum, but also pleasantly surprised by the radiant, sunny weather (although the sun doesn’t seem to reach much higher than in Holland on a midwinter’s day–it does make you very aware the you’re closer to the pole), I decided to change plans and explore the city center and the harbour. So I walked round, all the way down Universitatsgata, which eventually leads to a strange looking, huge red brick building with two towers, called RÃ¥dhuset (town hall), behind which you’ll find the waterfront: a little fish-auction where fresh fish (I’m assuming it’s fresh) is being sold directly off the fisherboats, and a long quay winding along Aker Brygge, which appears to be Oslo’s Port Vell, with restaurants and shops on one side, and yaughts and ferries on the other.

There’s a smell of seawater, shrimps and diesel oil; shrieks from the seagulls flying around; creaking of boats on the gentle waves; sharp light of the sun low on the horizon; a murmur of the Norwegian language that creaks much like the boats do; and of course the constants sound of rippling water. There’s an old looking seagull, lying near the edge of the quay, looking out over the water, bathing in the sun, with a tired look on its face; it won’t budge however close I get. Is it near its end, waiting to die, reminiscing over the days when it would fly around freely over this harbour, hunting for fish, scavenging for people’s leftovers?

A french-speaking couple walks by. It’s only four days ago that we left France after a two-week holiday, the car boot stacked with wine, driving all the way home from Carcassonne (where we stayed) in one day to have some more preparation time for Oslo. You can only travel so much, it seems, before you start getting enough of it–and it seems that M. is certainly reaching that point (she did four more trips this summer). What an impressive city, Carcassonne. Very touristy of course, but you can hardly blame the city for that. Carcassonne is a city in the south of France, some 200 km north of Barcelona. It was originally built as a walled city in the Middle Ages, then eroded away in the centuries after, because its walls weren’t up against newer methods of warfare (like explosives and catapults). In the 19th century, a French architect decided to restore the old city to its former glory, rebuilding the walls where necessary, as well as the coned roofs on the towers–and filling in some of the details using his own imagination. Which is of course always the danger of restoring things: you’ll be tempted to rebuild them “as they were”, being under the illusion that you end up with the original thing.