Alef Arendsen

Sometimes you just have to say how good a product is you’re working with. I previously did this with Pixelmator and I feel the urge to do it again right now. This time it’s Solve360 that’s making me happy.

When we started our new business we quickly settled on the need for a CRM system. I looked at the options and finally opted for ZOHO. SalesForce proved to be too expensive and ZOHO seemed to fit my needs. We’ve been working with ZOHO for about 4 months now and I seemed to be looking at the system less and less. I think one of the key factors in a CRM system is that your staff should be happy using it, in fact they should be excited to use it. Well, with ZOHO, this definitely was not the case.

In the end, there were three other things that made me want to look at other options:

• Decent integration and data export possibilities. ZOHO does have an API and you can export data to CSV and Excel and alike, but in some areas the API is quirky and the export possibilities are sometimes limited. I’m setting up my new IT infrastructure in a very loosely coupled way, with desparate systems integrating with eachother via HTTP (REST) and ZOHO facilitates this only to a certain extent
• Rigid way of handling sales. I’m a big fan of systems that don’t force you into a particular way of working. ZOHO unfortunately does this however. There’s a very strict division between Leads and Contacts (client), while I consider everybody to be a client, not just leads. It’s very forced at optimizing the sales process and not on serving the customer in the best way possible. I want to have a system that facilitates my serving our customers, not serving some VP of Sales we might eventually hire
• Last but not least there’s project management. Our sales process itself is not just about selling products, it’s about delivering service. In essence we’re a service provider and even in the sales process, it’s not about closing the deal, it’s about giving the customer the best service experience possible. This means I need a system that does not only help me with the conventional sales tasks (creating opportunities, upping the probability of a sale, sending out quotes), but also with more service-oriented things (task management is the most important one). And even after the sales process has finished, I need a tool that helps me manage the service we’re delivering to the client. ZOHO does not do this. It does have task management, but once a sale is done, it’s hard to keep using ZOHO to deliver service to the customer)

There are a few other things that made me look for other solutions (ZOHO’s UI is sluggish, not very Web 2.0 and sometimes hard to work with), but these were not the most important reasons.

One last thing kind of itched as well. As a service provider, ideally you want your suppliers (of for example IT tools) to be just like you: delivering excellent service. This was not the case with ZOHO. On the forums, questions remained unanswered from time to time, most of the time feature requests were answered with a simple ‘we do not support this at this time’ reply. This made me feel bad about forking out money for something like that.

Ironically on the ZOHO forums, I came across a thread where people were recommending other CRM solutions, amongst others Solve360 and this made me start to look around for better.

Fast-forward to today: I’ve been working all weekend to move my data from one place to the other (from ZOHO to Solve360 that is) and it’s been fun. The API is very usable (although it could use some improvements here and there–more on that later). The system is very flexible (which makes you think about your process–something I like, as opposed to being forced into a process that somebody else thought up for me). It supports project management, opens up to our actual customers (by publishing project-related info to them and even allowing them to work on the projects with you side by side) and doesn’t stop there. Integration with an email marketing solution (Constant Contact) is available and on top of that, it’s totally Web 2.0 (in the sense that it offers a very usable, very nice single-page UI). One minor thing (tongue in cheek): it has a button that strongly resembles the Windows start button and the button with which you can manipulate the windows (close, maximixe) are on the wrong side of the windows and being an avid Mac user, I don’t like that, but well, you can’t have it all, can you .

On top of all this one thing made me decide this was the company that was going to help solve my problem: their customer service so far is excellent. The API has a 12k call limit per day. I can understand this, but I really needed to move my data from ZOHO to CRM over the weekend and I didn’t want to run into the limit. So I fired off an email to them asking about this. Within an hour I had a reply, telling me they had taken off the limit for me. This was in line with all the other interactions I had with them: quick replies, to the point and always helpful.

A few other things I like (amongst others):

• It does tagging. And yes, tags are different than multi-select fields or checkboxes. You can tag anything in the system, with self-defined tags
• It has iCal integration, synching your tasks to your iCal calendar automatically. This is great!
• It facilitates lead nurturing very well with scheduled emails and things alike
• It integrates with Google Docs and Google’s address book

So, conluding I can say: ’so far so good’.

Of course there are always negatives, but so far I haven’t been able to find a lot. One that’s itching is the XML they’re outputting when using their API. Now before I go on let me state that it’s a great API that just works, but having been a software engineer for quite some time I’m a bit perfectionistic in this area. The issue: their XML doesn’t conform to a schema. When requesting a list of contacts using the API I would have expected something along these lines:

<customers>
  <customer>
      <id>1235</id>
    <firstname>Alef</firstname>
    <lastname>Arendsen</lastname>
    <status>On Hold</status>
    ...
  </customer>
  <customer>
      <id>1236</id>
    <firstname>John</firstname>
    <lastname>Doe</lastname>
    <status>In Progress</status>
    ...
  </customer>  
</customers>

but instead I got this:

<response>
  <id31507>
    <id>1235</id>
    <name>Alef Arendsen</name>
    <parentid>52541</parentid>
    <flagged>1</flagged>    
    <custom52857>On Hold</custom52857>
  </id31507>
  <id34943>
    <id>1236</id>
    <name>John Doe</name>
    <parentid>52542</parentid>
    <flagged>1</flagged>    
    <custom52857>In Progress</custom52857>
  </id34943>
  ...
  <count>21</count>
  <status>success</status>
</response>

Ouch! First of all, with the id-element including the contact’s identifier, this XML document is never going to conform to a particular schema (well, it might, but not the way I want it too). The second thing is the custom fields. While on the one hand it seems to make sense to include the custom field’s identifier (you might want to change the name of an identifier, and then you don’t want your identifiers to change), but what I would really like is for the field to have some kind of symbolic name (that I can define myself) that will be included in the XML. API design is important, and I’ve always like how people like Juergen and Arjen (former colleagues at SpringSource) spent countless hours working on the best possible experience for a developer.

Now again, let me restate that their API is way better than what I’ve seen from other providers (SOAP, anyone), but I just *had* to find one negative point . And then again, knowing the guys at Norada, maybe they’ll even work on improving it (hint, hint).

Last thing: I’d like to upload my own background. Right now I’m stuck with a set of preselected backgrounds . But well, the backgrounds Norada in combination with their very slick UI provides are way more attractive than a dull Web 1.0 interface, so I think this’ll have to do for now .

As far as pricing goes, Norada offers plan ranging from $24 (per month) for a single-user subscription to $149 for a subscription that’ll get you 18 users. In comparison, the ZOHO edition we used (Enterprise) cost us $112 per month for 4 users (including the Mail Add-on). SalesForce would cost approximately the same per month, but only for one user(!). I need the API and this is only offered in SalesForce’s Enterprise Edition, which costs $125 per month per user.

Okay, that’s all for today, I think I’ve done enough promotion work for the Norada guys. Keep up the great work!

Questa sera i olandesi hanno dato una grande schiaffone agli italiani. Okay, that’s enough Italian for now. I won’t repeat the other stuff I learnt tonight. After I asked an Italian friend of mine (by text message): ‘come stai? ’, he responded by saying ‘come con tre dita nel ….’. I think Italians will probably be able to fill in the rest of the sentence .

Anyway, for those not in the know, the Dutch soccer team beat the Italian team tonight with 3 to 0. This is a great victory, as first of all, the Italian are the ruling world champion and second, it was 30 years ago since the Dutch soccer last won from the Italian. Now, of course (as always) we keep our feet on the ground in Holland and are all saying that we still have another two matches to go before we have survived the ‘group of death’ (with France and Romania being the other two teams).

I have a few workers dropping by at my house next week (a tubista, a muratore and an elettricista). If any Italian are listening in. What should I bring to ease the pain and to convince them they should still work for me (they have do do a lot of stuff next week, such as finishing the installation of the electricity, installing hot water and so on)? Anything slightly more original than a bottle of limoncello will do. It’s in the North of Italy (Valle d’Aosta).

Update: wow, the amount of press is amazing, and not just that, the headlines are great:

• Dutch thrash aging Italians (International Herald Tribune)
• Italy humbled in Euro shocker (Melbourne Herald Sun)
• Orange crush Italy in Group of Death opener (London Free Press)
• Rampant Netherlands crush sorry Italy (CNN International)
• Italy peeled like Oranges (Goal.com)
• First blood to Dutch in Group of Death (The Herald)
• Dutch masterclass sinks Italy as France only draw (Earthtimes)

Ah, and about that off side thing, let’s quote from the source:

“If a defending player steps behind his own goal line in order to place an opponent in an offside position, the referee shall allow play to continue and caution the defender for deliberately leaving the field of play without the referee’s permission when the ball is next out of play.”

(warning Dutch content ahead)

Voor de verandering weer eens een technisch artikel op mijn geliefde blog, maar wel in het Nederlandsch. In een tweet maakte Nils_R mij attent op een artikel genaamd Liever geen Inversion of Control waarin Ralf Wolter zegt:

Ik ben tegen de Spring manier van ontwikkelen! Ik heb een hekel aan het zogenaamde ‘inversion of control’ (IoC)!.

Ik ken Ralf redelijk en hij werkt bij Sogyo, ook al niet de minste van de Nederlandse IT dienstverleners. Ik hou van mensen met een uitgesproken mening (daar zijn er sowieso veel te weinig van), vandaar dat ik het artikel dat Ralf oktober afgelopen jaar schreef wel kan waarderen. Ik had er tot nu toe eigenlijk nog nooit op gereageerd en nu Nils_R me erop wees en ik op het fantastisch mooie vliegveld van Tel Aviv toch niks anders te doen had, dacht ik dat het er tijd voor was. Dus Nils_R (en voor overige geïnteresseerden) hierbij mijn reactie .

Ford met z’n Model T auto

Maar… eerst een verhaaltje: bijna 100 jaar geleden (September 1908 om precies te zijn) bracht Henry Ford zijn eerste Ford Model T (ook wel Tin Lizzie genoemd) op de markt. Zoals waarschijnlijk wel bekend, werd de Model T de eerste op zeer grote schaal geproduceerde auto. De vraag naar auto’s steeg tijdens de begindagen van de Model T enorm. Auto’s werden voor meer mensen dan alleen de elite bereikbaar.

Henry Ford had moeite om aan de vraag te voldoen. In de eerste maanden dat de Model T werd geproduceerd werden er slechts 11 auto’s per maand geproduceerd. Dit alles gebeurde in de fabriek van Ford op Piquette Avenue in Detroit. In 1910 waren er ’slechts’ 12.000 Model T Ford auto’s geproduceerd en dat was het moment dat Henry Ford de productie verplaatste naar het Highland Park Complex, waar tot op de dag van vandaag de archivering plaatsvindt voor Ford.

In het Highland Park Complex werd de assemblagelijn ontwikkeld. Henry Ford deed dit niet zelf, het was een van zijn medewerkers die in een fabriek in Chicage een straat gezien had die kippen deassembleerde. De deassemblage (klinkt mooi, niet waar?) van de kip gebeurde in deze fabriek op een gecontroleerde manier, stapje voor stapje en volledig automatisch. Ik moest zelf toen ik dit las denken aan een vriend van mijn ouders, die zelf jarenlang erg succesvol in kippen handelde en de meest gruwelijke verhalen kan vertellen over hoe kippen middels uitbeenmachines, ontbeenmachines en nog veel meer machines met gruwelijke namen uit elkaar gehaald worden. Met meesterlijke efficiëntie worden miljoenen kippen (gok ik zo) per dag ge-deassembleerd. Okay, genoeg off-topic. De persoon die de deassemblagelijn zag dacht: als we dat nou in omgekeerde volgorde doen (assemblage in plaats van deassemblage) maar dan voor autos… Het was dus niet Henry Ford zelf die de assemblagelijn introduceerde, maar goed, hij was wel degene die de gok durfde te nemen deze revolutionaire manier van produceren uit te proberen.

Fast forward naar 1914. Dit was het jaar dat er elke 93 minuten een Model T Ford van de band rolde. Een paar jaar eerder waren dit er slechts 11 per maand geweest. Als je ervan uitgaat dat men 8 uur per dag en 5 dagen per week assembleert betekent dit dat Ford meer dan 10 keer zoveel auto’s kon produceren per maand (als je meeneemt dat er gemiddeld 21 werkdagen in een maand gaan). De assemblagelijn had z’n succes bewezen! Natuurlijk was niet alleen de assemblagelijn de grote reden dat er elke 93 minuten een Model T Ford van de band rolde. Ook de introductie van de 5 daagse werkweek en het vaste loon, onafhankelijk van de ‘productie’ van medewerker waren belangrijke factoren die meehielpen bij een snelle productie van de Model T Ford. Die Henry Ford was een visionaire man!!

Even iets dieper inzoomend op de assemblagelijn. Deze lijn klikt verschillende onderdelen aan elkaar, om uiteindelijk een auto te fabriceren. De onderdelen zelf zijn op een ander tijdstip gemaakt en zijn zo gemaakt dat ze op andere onderdelen aansluiten (boutjes, moertjes, schroefjes, pasvormen). Zo zal een kogelvrije voorruit voor een Model T Ford (zouden ze die toen al gehad hebben?) dezelfde vorm gehad hebben als een voorruit waarmee de gewone man het moest doen. Ditzelfde geldt voor de wielen. Winterbanden (nee, die hadden ze toen zeer nog niet, gok ik) zul je op ongeveer dezelfde manier op de Model T Ford gezet hebben als normale banden.

Als eerste kunnen we observeren dat de assemblage van de verschillende componenten waaruit de auto bestaat volledig en voor 100% losgekoppeld is van het het daadwerkelijk functioneren van deze componenten. Dit is logisch lijkt me. Een cake bakt zichzelf niet, daar heb je een recept voor nodig en iemand die de eieren, bloem, suiker en dergelijke voor door de mixer haalt en in de oven zet. Een huis bouwt zichzelf niet, daar heb je architecten voor nodig die een bouwtekening maken, metselaars en timmermannen en bouwopzichters. Een auto bouwt zichzelf niet, die wordt geassembleerd.

Een interessante vraag is waarom die assemblagelijn nou eigenlijk zo succesvol is? De algemene consensus hierover is dat specialisatie efficientie bevorderd. Als je je als persoon ergens in specialiseert wordt je er beter in. Dat kunnen we ook over machines zeggen. Als je een machine bouwt die specifiek moertjes op boutjes draait, zal het gemakkelijk zijn deze machine hierop te specialiseren.

De algemene consensus binnen de productiewereld is naar mijn weten ook, dat het zich specialiseren ingeval van mensen ook nadelen heeft. Overspecialisatie kan leiden tot mensen die hun werk saai gaan vinden, specifieke blessures krijgen door zich te vaak repeterend werk (RSI, anyone). Vandaar dat later eilandproductie werd uitgevonden en roulatie werd ingevoerd van activiteiten die mensen in een productieproces uitvoeren. Dit is tenminste wat ik me kan herinneren van de lesjes productieprocesleer die ik in een ver verleden gehad heb. Overspecialisatie is echter een volledig andere discussies.

Separation of Concerns

Laten we bij nog even bij assemblagelijn blijven. Het onderliggende principe van de assemblagelijn is dus specialisatie. Vrijvertaald zou je die specialisatie ook een goed voorbeeld kunnen noemen van het “Separation of Concerns” principe (voor de ingewijden: denk nou niet meteen aan AOP, daar gaat dit artikel niet over). Dit principe werd al in 1975 belicht door onze vriend Edsger Dijkstra, nog steeds een van de belangrijkste en invloedrijkste computer scientist ooit. In zijn paper On the Role of Scientific Thought beschrijft Dijkstra dit concept als volgt:

“Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained –on the contrary!– by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”, which, even if not perfectly possible, is yet the only available technique for effective ordering of one’s thoughts, that I know of. This is what I mean by “focussing one’s attention upon some aspect”: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect’s point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.

Met andere woorden; het zich richten op één deelprobleem tegelijkertijd zorgt voor een efficienter en gemakkelijker manier van het oplossen van een groter probleem.

Dit is exact wat er in de assemblagelijn ook gebeurt. Door verschillende delen van de assemblagelijn zo in te richten dat ze elk één klein deel probleem oplossen (het op de auto schroeven van de banden, het plaatsen van het motorblok) en de assemblage in z’n geheel los te koppelen van de eigenlijke functie van de auto, wordt het mogelijk om:

• Elke individuele stap in de assemblage te optimaliseren
• Elke individuele stap in de assemblage te beschrijven en herhaalbaar te maken zodat bij het inrichten van een nieuwe assemblagelijn er slecht een copy-paste actie uitgevoerd hoeft te worden
• De individuele stap te observeren ten einde kwaliteitstestjes in te voeren die specifiek gericht zijn om deze stap in het proces te controleren (is deze schroef wel goed vastgedraaid)
• Ten einde het hele proces van het in elkaar zetten van een auto (bijna) oneindig veel te optimaliseren en controleren

Applicatieassemblage

Okay, terug naar de IT, want al die auto’s, dat is wel leuk, maar daar waren we hier niet voor, toch Nils? Ik ben een groot voorstander van de mensen die roepen dat softwareontwikkelaar een art is… een vak wat je tot op zekere hoogte kan leren, maar mits goed uitgevoerd kunstig mooie creaties op kan leveren. Ik kan de term softwarecreatie dan ook veel meer waarderen dan de term softwarebouw. Nou is de vraag waar in de creatie van de software dit creatieve zich nou precies afspeelt. Het creatieve en tegelijkertijd het complexe speelt zich af in de plaatsen waar de software daadwerkelijk iets doet, in de onderdelen die de eisen en wensen van de klant implementeren. We hebben allemaal geleerd dat object-orientatie een goede manier is om een model te bouwen waarmee we de problemen van de klant kunnen oplossen (lees hiervoor verder over de definitie van modellen). Wat voor model? Een model dat de echte wereld (de wereld waarin het probleem van de klant zich afspeelt) weerspiegelt.

Laten we nog even kijken naar de auto: die bestaat uit een (zeer grote) verzameling onderdelen die allemaal een belangrijke rol spelen in het laten rijden van de auto. De auto dient geassembleerd te worden. We zouden middels object-orientatie ook de auto kunnen modelleren (public class Wiel {}, public class Engine{}, public class Car{}) , maar als we dat doen, dan moeten we nog wel iemand hebben die voor ons die auto (de applicatie) assembleert.

Als je assemblage als centrale analogie neemt voor het creeëren/bouwen van een auto als je het hebt over het creeëren/bouwen van software, kun je wat mij betreft geen andere conclusie trekken dan dat diezelfde assemblage, maar dan die van een applicatie uit verschillende onderdelen (instanties van types) een absolute must is in plaats van die verantwoordelijkheid bij de applicatie zelf te leggen (kortom: een auto assembleert zichzelf ook niet). Dit is wat mij een goed argument om de discussie rondom Dependency Injection mee te concluderen.

Welk probleem wordt er nou eigenlijk opgelost?

Ralf Wolter zegt ergens halverwege z’n artikel het volgende: “De complexiteit van de applicatiekern is echter niet signifikant kleiner. Nog steeds verhoogt elk component de complexiteit van onze kern. In het plaatje hierboven brobeer ik dit weer te geven. Het gearceerde gedeelte is nauwelijks kleiner dan in het vorige plaatje [Ralf gebruikt plaatjes om de complexiteit van een applicatie weer te geven]. Dit is mijn belangrijkste bezwaar met IoC. Het lost het verkeerde probleem op.”

Ironisch genoeg denk ik dat Ralf de spijker op z’n kop ramt hier! Ralf vindt dat IoC het verkeerde probleem oplost. De rest van het artikel gaat Ralf volgens mij in op de manier waarop componenten in een applicatie met elkaar praten. Het lijkt erop alsof hij in de rest van zijn artikel praat over event-driven applicaties. Ik kan niks anders dan concluderen dat Ralf denk dat Inversion of Control het probleem van de communicatie tussen verschillende componenten probeert op te lossen. Als dat inderdaad zo is, dan ben het volledig met hem eens: Inversion of Control verlaagt de inherente complexiteit van logica in applicaties niet. Deze logica was complex, is complex en zal altijd complex blijven. Lees alsjeblieft Fred Brooks’ Mythical Man Month alvorens te proberen hierover een discussie aan te gaan… hell, als je Mythical Man Month nog niet gelezen hebt en je hebt ook maar een klein beetje te maken met software ontwikkeling, stop nu met het lezen van deze blog entry, ga naar de dichtbijzijnde Amazon.com winkel, haal deze klassieker op en lezen maar! Het lijkt mij volledig logisch dat je de creatie van complexere logica in de vorm van componenten loskoppelt van de meer mundaine taken als het assembleren van deze creatieve onderdelen tot één applicatie. Maar daar bovenop, stelt het ons in staat die assemblage op een efficientere en productievere manier te doen, in plaats van hier kostbare ontwikkeltijd aan te besteden. Het blijft natuurlijk de verantwoordelijkheid van de applicatieontwikkelaar zelf (of in geval de analogie de bouwer van de voorruit of die nou kogelvrij is of niet) om te zorgen voor de constructoren, setter methods (de vorm van de voorruit) die het mogelijk maken om het component (de voorruit) in de assemblage te gebruiken om uiteindeijk tot een applicatie te komen.

Dependency Injection lost het probleem op van de assemblage van een applicatie, niet van de gedrag van deze componenten zelf waaruit deze applicatie bestaat, of de communicatie tussen deze componenten. Separation of Concerns is een goed principe en ik zou bijna zo arrogant willen zijn door te zeggen dat niemand zou meer een applicatie moeten willen bouwen zonder zich op één deelprobleem tegelijkertijd zou moeten focusen en de individuele componentjes die deze deelproblemen oplossen te assembleren door middel van Dependency Injection.

Ik bedenk me nu ineens dat Arjen zich vast nu over z’n kin wrijft en denkt : “Waar ga je heen jongen, toch niet richting de eeuwige belofte van de component-assembler?” Nee Arjen, maak je geen zorgen, hier geloof ik nog steeds niet in. Maar dat ter zijde.

Een paar opmerkingen voordat ik ‘dag’ ga zeggen. Ik begon dit artikel te schrijven toen ik op het Ben Gurion vliegveld van Tel Aviv zat. Inmiddels zit in het vliegtuig en we hebben heldere uitzichten ingewisseld voor een dik wolkendek. Gelukkig vlieg ik daar nu nog boven, dus zonnig is het (nu) nog wel. Ik kom er net achter dat in dit artikel niet één keer Spring heb vermeld. Het is dan ook een artikel dat zich niet richt op het nut van Spring. Het is een artikel wat zich richt op het nut van Dependency Injection, of je dat nou doet met Spring, PicoContainer, Google Guice, Plexus of custom configuratie code. Zo lang je assemblage maar als een apart traject beschouwt ben je goed af! Of je het nou in XML doet of Java, met Properties-files of met een scripting language, dat maakt niet uit! Of anders gezegd: dat is niet het onderwerp van deze discussie.

Hoe je die assemblage dan precies vormgeeft is natuurlijk vraag twee. Als je gelooft in de kracht van een analogie zou je nu al kunnen concluderen dat een wereldwijd geaccepteerd manier van het assembleren van autos (waarin er misschien slechts 10 varianten bekend zijn voor elke autofabrikant eentje) beter is dan het met-het-handje assembleren van de applicatie. Ten slotte ‘deed’ Ford zonder assemblagelijn 11 Model T Fordjes per maand en deed hij er één per 93 minuten toen de assemblagelijn algemeen geaccepteerd en doorgevoerd was.

Ondertussen, Nils_R: bedankt voor de aanzet tot deze rebuttal. Lezers: hou Nils_R in de gaten (op www.nilsr.net ofzo)! Hij gaat leuke dingen doen! Z’n bedrijfsnaam (WaterCooler Topics) is in ieder geval al cool!

En nu met z’n allen weer lekker Spring XML typen!! … totdat JavaConfig uitkomt natuurlijk!

Eclipse on Leopard used to have a very nasty bug that made it to crash in certain circumstances. Now I just downloaded the main Eclipse distribution (I figured, it’s been a while, the main download SHOULD have fixed this now). And it still crashes.

Now, I’m sure it’ll be fixed in the next version, but what does it take to supply all people on Leopard with patched version (as the main download version).

Sure, I know the integration and stream builds all have the fix, but do I really have to go through all the trouble of downloading a stream integration build to get such a patch? What about people that just want to try things out and don’t know about this bug.

Of course, I could be totally wrong here and maybe there is a easily downloadable version for Leopard somewhere, but then I missed it. Let me know if you have any alternatives.

Okay, apart from Java 6 not being available on the Mac, I’m not complaining at all:

Last login: Thu Nov 15 10:06:52 on ttys000
Macintosh:~ alefarendsen$ which ant
/usr/bin/ant
Macintosh:~ alefarendsen$ which mvn
/usr/bin/mvn

I just got a new laptop and immediately installed Leopard on it. I was in such a rush that I really didn’t have time to do anything else than the bare necessities. So when I checked out some source code today and needed Ant to build it, I didn’t need to download it at all!

Thanks, Apple

And about that Java 6 thing: who’s on Java 6 anyway

I was reading a piece on Leopard the other day over at Ars Technica and I was dumb-struck by a survey that Apple apparently took among its customers before creating Time Machine. Apparently only four percent backup regularly:

Apple took a survey of its customers’ backup habits before creating Time Machine. Eighty percent of Mac users said they knew they should backup their data. (This is scary already. Only 80 percent?) Twenty-six percent said they do backup their data. That actually doesn’t sound too bad until you get to the next question. Only four percent backup regularly.

I realized just now that I’ve been pretty lucky that I do a backup every two weeks (or whenever I’m at home), to a networked drive at my place. This is meant to make any data survive that’s not in our version control system. I actually needed the backup desperately a short while ago, as I had to switch to a new laptop without having access to the old one all of a sudden anymore.

The story is that Time Machine takes away all the hassle of doing backups manually and completely and transparently automates the process. As Ars Technica puts it:

If you have more than one hard disk attached to your Mac, it’s more difficult not to use Time Machine than to use it.

I do have to change my setup a little bit though. I heard it’s possible to first connect a networked NAS drive via USB and initialize it as a Time Machine drive, after which (if the NAS supports AFP) you can reconnect to it through the network and Time Machine will still work. That’s suboptimal though, as I want to change to a RAID setup anyway. I’m going to buy a Firewire RAID drive soon that will serve as my Time Machine drive. The networked drive that I already have (a Lacie too) will continue to serve as my music drive (I don’t have backups of my music, maybe I’ll use the RAID drive for that too).

If you have any suggestions (different drives, different setup), let me know!

Last week, two ex-colleagues of mine made the exact same mistake as I made almost two years ago: leave their laptops in the trunk of the car. Both laptops were stolen and one of the guys lost a lot of pictures I heard.

That made me realize: I do have a backup script that copies all the important stuff from my laptop to a NAS drive, sitting in the basement somewhere, but I didn’t manage to get my pictures backed up yet in a nice way.

I’m using Aperture, which has its own internal backup mechanism using what they Vaults. Vaults however cannot be stored in a network drive–at least, that’s what the error message said when I last tried a couple of months ago. Today I found an article buy a guy that did manage to get his vault stored on a networked drive. Thanks!

p.s. I have a MacBook and like it for its size. The only time I actually hate it is when using Aperture. The graphics card is just too slow, so any real digital post processing is kind of a nightmare.
p.p.s. Just as Pages files, Keynote presentations and many other file types on a Mac, the Aperture Vault is a bundle. In other words, it’s just another directory which MacOS shows as if it were a single file. Very nice…

I love my Apple power adapter (wow, thats sounds realllly weird doesn’t it?). It’s got magnets and all you know! (for those who are not into computers: the power adapter had a magnetic connector that keeps it attached to the computer instead of you having to ‘plug’ it in). Even if after a few beers (or more) I stumble over the power cord (which happens about five times a week), I don’t ruin my Mac. It’s simply great!

I also hate my Apple power adapter (okay, that’s sounds a little more normal). You can exchange the part that goes into the wall socket for different (international) ones. Of course this is a smart thing to do, but then you always have to remember to put the original one back in place when you get back home. Now I have two power adapters, so I don’t forget one when I head to a client (it’s always in my bag), but I don’t always keep those little what-’should-we-call-it’s with me so occasionally I have to deal without an adapter for a while.

Sometimes that doesn’t always work however… Today I had to do some serious speeding again to drive back home after my morning appointment to pick my power adapter (or rather, the European part that goes into the power socket) and be in time for my afternoon appointment. Afterall, I wouldn’t want my laptop to die down in the middle of a presentation would I . I hope the camera on the A9 was out of film…

p.s. If anyone can tell me what this adapter-adapter-thing is called, please tell me!
p.p.s. I was kidding about those five times a week, just in case you were wondering…

This summer has been pretty hectic. Usually the summer in Europe is quite easy going, but this one proved to be full of trips to places like Berlin, Antwerp, Rome, Helsinki, Hong Kong and more.

It looks like this is not going to slow down any time soon. I have several gigs lined up all over Europe and the conference season is also starting very soon:

• September 18th: Cap Gemini is hosting a Java Night in Utrecht. If you’re interested in hearing what the future of Spring will offer, register and drop by. Patrick Linskey of JPA fame is going to be there too. Update: I just learned that there is a waiting list available for this event. The conference itself is already fully booked.
• September 24th – 26th: JAOO, in Aarhus, Denmark. I’m hosting a session there on web frameworks. I will be discussing with the audience whether or not stateless web framework architectures are still relevant and for what types of applications. I’ve actually never been to JAOO, so I’m looking forward to it!
• October 6th: The Greek Java User Group (JHUG is organizing a one-day conference early October and I will be speaking there about some of the future development in the Spring world. I still have to turn in an abstract (note to self: I need to spend some time on that tonight!) and this will probably be a brand new talk! I was in Greece last July and I had great fun, so I’m already looking forward to this again.
• October 11th: This is the day for the annual J-Fall conference, organized by Klaasjan Tukker or the NL-JUG (the Dutch Java User Group). I’m not sure if I will host a session here, but I will definitely be at the conference. I definitely look forward to seeing all Dutch Java people again.
• December 12th – 15th: this is the week in which we’re organizing The Spring Experience in Hollywood, FL for the third time. I will host three talks here. One together with Ramnivas on architectural enforcement, one on finding AOP in corners of your application in which you would never have thought it would be and another on complex deployment scenarios.

See you there.

In about a month, I’ll be organizing another Java Meetup in Amsterdam. This will be the seventh time this event is taking place, and so far I’ve enjoyed all of them. Reading all responses and emails I received over time, this also holds for loads of you that have joined in in the past.

I’ve already published more about this quarter’s Java Meetup, so I’m not going to be repeat any info here. Just be there!!

more info on this quarter’s Amsterdam Java Meetup on blog.interface21.com