Update d. 10/09-2012: Jeg blev opmærksom på denne artikel idag af Erik Dörnenburg: The Buy-vs-Build Shift (part 1). Den beskriver hvordan argumenterne for at købe standard produkter frem for at bygge selv, er blevet mindre relevante det sidste årti. Software udvikling som disciplin er blevet bedre funderet, værktøjerne er blevet mere modne og vi er blevet bedre til at vurdere ricisi og tilpasse os forretningens mål gennem agil udvikling. Det er en utrolig interessant læsning og jeg synes den følger ånden i mine oplevelser med Clojure nedenfor rigtig godt.
I december 2011 startede jeg hos en kunde hvor jeg skulle videreudvikle på en eksisterende email-kvitterings-platform. Platformen var bygget i Sitecore og anvendte Sitecore’s Email Campaign Manager (ECM) til at konstruere og udsende emails automatisk til kunder og det fungerede faktisk ganske glimrende. Selve opsætning af indhold og rendering af HTML til emails foregik på vanlig Sitecore/CMS-manér. Men der hvor Sitecore udemærkede sig var ved workflow-styringen af udsendelserne: Via et grafisk flow-chart/state-machine kunne løsningen sættes op til at sende emails, tjekke for hard- eller soft-bounce og reagere ud fra forskellige scenarier ved f.eks. at sende email igen eller eksekvere egenudviklet rutiner. Det hele var ganske ituitivt at sætte op og det var legende let at samle statistik på brugeradfærd selvom trafikken gik på tværs af email og web og danne sig et overblik over kommunikationens effektivitet.
Sitecore ECM retter sig i højere grad til kampagner (én email til mange modtagere) end kvitteringer (mange emails til mange modtagere). Så det krævede en del tilføjelser som virkede out-of-place at få hele løsningen til at virke på den mest hensigtmæssige måde. Og i vanlig CMS-stil var det ganske besværligt at flytte koden fra udvikling til test til produktion. Min vurdering er at i løsninger hvor databasen indeholder både redaktionelt indhold, forretningsmodeller, systemopsætning, metadata og meget andet godt, vil koden være notorisk svær at flytte at miljø til miljø. Der er simpelthen for mange afhængigheder ift. mindre monolitiske systemer. Det er utrolig vigtigt at kan skabe et lokalt udviklingsmiljø som minder om produktion så meget som muligt – noget der i praksis er meget besværlig i Sitecore.
Lidt inde i projektet blev det, pga. politiske og organisatoriske årsager, besluttet at droppe Sitecore og bygge eget email-kvitterings-platform. Normalt vil jeg ikke lovprise beslutninger om at bygge noget fra bunden når der findes standardprodukter, men i dette tilfælde var jeg helt solgt: Vi besluttede at benytte Clojure som sprog, Amazon AWS (Simple Workflow/SWF, Simple Storage/S3 og DynamoDB) som platform, SendGrid som mail relay, FreeMarker som HTML-templatemotor, GitHub som koderepository og en masse andre biblioteker, plugins og tools. Det var ren grøn IT.
At gå fra en monolitisk platform til dette, føltes den nye platform meget letvægts, dynamisk og utrolig distribueret. Der blev tilmed udnyttet lidt cloud-services. Så platformen var oven i købet utrolig trendy. Personligt gav det mig en masse ny læring og indtryk. Især funktionelt programmering i Clojure. Det var en radikal anderledes måde at arbejde på; en måde som jeg havde tilsidesat for en del år siden og som jeg hele tiden har haft et ønske om at tage op igen: I mit studieliv har jeg arbejdet udelukkende med Linux og jeg har haft en stor præference for open source. I mit professionelle liv som udvikler har jeg udviklet primært i .NET og været vant til hele Microsofts stack og infratruktur. Fra tid til anden har jeg arbejdet med “græsrods”-projekter, JavaScript/jQuery og andre dynamiske sprog. Men af den ene eller den anden grund er det ikke lykkes at arbejde med open source fuld tid - før nu. Så det var lidt som at “komme hjem” og jeg tog chancen med åbne arme.
At starte med Clojure er umiddelbart simpelt. Java SE skal være installeret og clojure.jar på classpath. Så er man kørerende. Men hele økosystemet bliver virkelig fedt når man f.eks. anvender Leiningen til at automatisere builds og håndtere project-dependency, jetty som letvægts HTTP-server, compojure som web-framework og en lang række andre biblioteker til at lettegøre arbejdet. Vi benyttede ThoughtWorks Go som continuous deployment og delivery. Hele denne tooling-chain og platform gjorde det fantastisk nemt at etablere et udviklingsmiljø som stort set identisk med produktionssystemet. Du kunne etablere et nyt miljø på få minutter uagtet om det var et produktionsmiljø eller et testmiljø. Samtidig var release noget der foregik flere dagligt. Jaja, dette er der ikke noget nyt i men det var fedt og værd at nævne fordi et af de største elementer i agil udvikling er det korte feedback-loop; tiden der fra man skriver sin kode, til at koden bliver testet i pre-produktion, fejl identificeres, analyseres og rettes. Kan man få feedback-loopet ned på få minutter er man godt på vej til en moden og agil udviklingscyklus.
Et must-read i den forbindelse: The Twelve-Factor App.
Den endelige løsning havde nogle gaps ift. SiteCore løsningen. Bla. var tracking af brugeradfærd var væsentlig forsimplet og redaktørernes interface var af langt mere teknisk karakter. Til gengæld var der en let og legende logik bag al funktionalitet. Løsningen kunne skalere, tilpasses, komponenter udskiftes og vi havde kontrollen. Den var mere levende og vi kunne bygge den klods for klods!
På den korte bane tror jeg ikke det var givet kunden nogen økonomisk gevinst ved at skifte platform, men jeg tror det stærkt på at det gør på lang sigt.
Jeg er super heldig at kunne skrive dette projekt på mit CV. Lad der endelig komme flere af den kaliber.
/p>
