Ik ben deze blog aan het verhuizen naar een andere host en een ander platform. Als je me leest via mijn feed, controleer dat je http://feeds.feedburner.com/tomklaasen gebruikt. Ik ga ervoor zorgen dat die zeker nog werkt na de verhuis.

Last night I actually looked for the time at the top right hand corner of the magazine I was reading…

I have the same feeling when I want to click on a page number in the table of contents of a book…

Bon, op het gevaar af dat ik hier spijt van ga krijgen, een poging om uiteen te zetten waarom wij gekozen hebben om tijd te investeren in Ruby on Rails.

Vreemd genoeg moet ik daarvoor eerst de ontstaansgeschiedenis van 10to1 uitleggen. Wij waren twee collega’s, Java consultants, die een beetje teleurgesteld waren in het soort werk dat ze deden. We sprongen om met ingewikkelde datamodellen en lastige zoekalgoritmes, maar we hadden hoegenaamd geen idee wat voor mensen ons ding gingen gebruiken. Als het al gebruikers waren, sommige systemen dienden alleen als input voor andere systemen. We voelden ons een heel klein radje in een heel groot raderwerk.

We voelden wel aan dat we elkaar goed aanvulden, en allebei hadden we de indruk dat hetgeen we samen deden, sneller en beter ging dan hetgeen we elk apart deden. Het geheel was meer dan de som der delen.

Van daaruit groeide de idee om samen een bedrijf op te richten. We zouden gaan werken voor projecten waar we voeling hadden met onze gebruikers, en waar we samen aan konden werken. Voor zover wij de markt kunnen zien, houdt dat in dat we vooral zouden werken voor kleine bedrijven, en voor mensen die van een idee een bedrijf willen maken, startups zeg maar.

Nu zijn er verschillende factoren die het moeilijker maken voor zo’n bedrijven om met Java aan de slag te gaan: zij hebben geen eigen IT departement, en dus niemand die kan zorgen dat hun servers 24/7 blijven draaien. Zij hebben geen budget voor doorgaans dure Java hosting. En hun projecten zijn dikwijls te klein om veel tijd te spenderen aan het ‘opzetten van een project’, en het schrijven van vele lagen ‘mappers’ die in feite niet meer doen dan data van het ene formaat omzetten naar het andere.

Net in die tijd was er een nieuw web application framework in opmars: Rails. Dat beloofde de bovenstaande problemen aan te pakken: er was goedkope hosting voor beschikbaar, de opzetkost is minimaal, en in plaats van ‘mappers’ werd er vanuit gegaan dat de meest logische mapping gebruikt werd: een gegeven dat in de databank ‘name’ heette, zou in het domein model ook wel ‘name’ heten. Daar heb je geen ingewikkelde xml-files voor nodig.

Het enige ‘controversiële’ van dat framework is dat het in een vrij onbekende taal geschreven was: Ruby. Dat maakt dat de keuze voor Rails een iets grotere overgang is dan de overgang van, ik zeg maar wat, Struts naar Spring Web MVC, of zelfs van Struts naar Tapestry of JSF.

Maar dat kon en mocht ons niet afschrikken. We pakten het nieuwe framework vast voor wat het waard was, en begonnen er in te programmeren. En het beviel ons. Het maakt de beloften waar, ondanks veel religieuze oorlogen op de internetten, die dikwijls naast de kwestie zijn.

Wil dat zeggen dat we nooit nog een Java project zullen doen? Weinig waarschijnlijk. Java is zo ingeburgerd in de grote bedrijven, dat de meeste bestaande projecten, en het gros van de nieuwe projecten, er met Java gemaakt wordt.

Wil dat zeggen dat Ruby on Rails onze eerste keuze is als we niet beperkt zijn in verband met de technologie? Jazeker. Het is niet voor alles geschikt, maar het is zeker geschikt voor de toepassingen waar wij op mikken: ‘kleinere’ projecten, met een grote web component, die op relatief korte termijn moeten geïmplementeerd worden.

(Hmm, dat paragraafje is iets groter geworden.)

In C++, you have the concept of ‘friend’, where a callee can define which callers are allowed. Or so it exists in my memory, but that doesn’t matter.

To achieve the same thing in Java, you can inspect the stacktrace:

public boolean isFriend() {
new Exception().getStackTrace()[2].getClassName().startsWith(MY_PACKAGE_NAME);
}

And use it as follows:

public void something() {

if (!isFriend()) {

throw new NotFriendException();

else {

// do nifty stuff here

}

}

Now, while this works, I have a sneaky suspicion that this isn’t the most performant solution: creating a stacktrace is said to be an expensive operation. But it’s useful once in a while.

vs.

CollectionUtils.find(addresses, new Predicate() {

public boolean evaluate(Object obj) {

Address address = (Address) obj;

return address.getStreet().equals(”Groenplaats”);

}

});

Laat ons eerst eens even ingaan op de idee van “de switch maken”. Dat wil zeggen dat je een ding inwisselt voor een ander ding. Ik maak de switch van Windows naar Mac, of van Dreamhost naar Openminds, of…

Het ding dat ik hier zou inwisselen, is mijn kennis van Java, en ik zou dat vervangen door mijn kennis van Rails. Helaas. Hoe graag ik het soms ook zou willen, doelgericht vergeten ligt niet in mijn skillset. Dus zal het enige alternatief zijn dat mijn kennis van Java aangevuld wordt door mijn kennis van Ruby, wat toch een andere kijk op de dingen geeft. Het is niet omdat ik nu tijd investeer in Ruby, dat mijn investering in Java plots verloren gaat. Het is ook niet zo dat Java nog steeds zo razendsnel evolueert dat je het enkel kan bijhouden door er full-time mee bezig te zijn. De grootste bedrijven standaardiseren trouwens nog altijd op Java 1.4, toch ook al een paar jaar oud.

Los daarvan: als je in een enterprise Ruby wil binnenbrengen, denk ik inderdaad dat je er goed aan doet om een oplossing te zoeken die bovenop de bestaande infrastructuur (lees: de Java Application Server) kan draaien. Persoonlijk heb ik me even met Groovy bezig gehouden, en ik vond de gelijkenis met de Java syntax (die ze bewust nastreven) eerder hinderlijk dan gemakkelijk: het lijkt er heel hard op, maar in de details is het net anders. Dan liever een helemaal-andere syntax die je toelaat om een (al dan niet denkbeeldige) knop in je hoofd om te draaien.

JRuby lijkt me daar dan ook de meest aangewezen manier, ook al doordat Sun daar meer in lijkt te investeren, en doordat de JRuby developers meer tijd lijken te steken in hun ‘evangelizing’: je kan geen IT conferentie binnengaan tegenwoordig, of Charles Nutter staat daar wel een presentatie te geven.

Waarom zou je Ruby gebruiken in plaats van Java? Om net dezelfde redenen als je 10 jaar geleden Java gebruikte in plaats van C++: er zijn meer abstracties, die ervoor zorgen dat je je minder met het spreekwoordelijke metaal moet bezighouden, en meer met de business logica.

Ruby maakt meer gebruik van dingen die ‘er niet toe doen’: het kan levensnoodzakelijk zijn om je database veld anders te noemen dan je object attribuut, maar meestal doet het er niet toe. Dat is weer een gegeven minder dat je in je hoofd moet houden.

Om te leren uit de ervaringen van een project manager met een Ruby project, kom je best eens kijken op FOSDEM.

Is Java dood? Verre van — het is nog nooit zo levend geweest. Is het goed om verschillende tools in je gereedschapskoffer te hebben zitten? Ik ben overtuigd van wel.

Eén bedrijf is me in het bijzonder bijgebleven: op een zonnige zaterdagmorgen werden we na een korte introductie met een man of 100 in een zaal met lessenaars gestoken, en kregen we vragenlijsten om onze kennis te testen. Zonder ons eerst te vragen of we nu eigenlijk overtuigd waren, zo na die introductie, maar soit.

Na dat toelatingsexamen was ik er toch in geslaagd om een lokale manager aan te klampen. Ik vroeg hem “ik heb de indruk dat hier nogal veel met mainframe technologie gewerkt wordt. Eigenlijk ben ik nogal geinteresseerd om met Java te werken, web-addict zijnde enzo. Hebben jullie daar plannen mee?”

Zijn antwoord?

“Java? Wie zegt dat dat gaat blijven bestaan? Over een jaar of twee hoor je daar niets meer van, mijn beste. Nee, daar doen wij niet aan mee.”

Blogposts alom doen mij regelmatig aan deze anekdote terugdenken, de laatste tijd.

| View | Upload your own

… and the WiFi works! Good news for everybody who comes in later this week - make sure to bring your laptop