June 2011

There were 2 posts published in June 2011 (this is page 1 of 1).

Waarom Ruby on Rails voor web applicaties en business software?

In ons web applicatie en software bedrijf Zorros maken we overtuigd gebruik van het web applicatie framework “Ruby on Rails”. “So what” hoor ik u denken. “Ik ben enkel geïnteresseerd in het eindresultaat en de business value. Technologie interesseert me niet, zolang het onze business maar ondersteunt.“ Leest u dan zeker verder…

Ruby on Rails (RoR) is een web applicatie framework: een stevige verzameling code die toelaat om op een zeer efficiënte en doelgerichte manier web applicaties te maken. Ruby on Rails focust sterk op het ondersteunen van de business en het oplossen van problemen door middel van IT en (web) applicaties. Deze business oriëntatie en filosofie zit in Ruby on Rails ingebakken door middel van volgende eenvoudige principes:

  • Don’t Repeat Yourself (DRY): informatie, code, business logica en layout wordt slim gebundeld en verzameld op centrale plaatsen in de architectuur van de applicatie. Hiernaar wordt vanuit de rest van de code verwezen. Dit betekent dat een wijziging in je bedrijfsproces, in de business logica, in de code, of in je kleurenschema steeds maar op één centrale plaats moet gebeuren. Een veranderende business vraagt een flexiebele applicatie.
  • Convention over configuration: Rails vraagt je geen overbodige zaken te configureren die er in 99% van de gevallen niet afwijken van “het typische scenario”. In een applicatie om foto’s te beheren, gaat Rails er van uit dat je (1) foto’s kan uploaden, (2) foto’s kan bewerken, (3) foto’s kan verwijderen en (4) je foto’s kan bekijken. Hiervoor moet je als developer niets doen. Rails neemt dat aan, aangezien dit voor 99% van de gevallen zal kloppen. Moest je toch willen afwijken van wat Rails standaard voorziet, dan kan dat uiteraard. Werken met zoveel mogelijk “conventies” en dus minder “configuratie”, zorgt voor minder code. Minder code is minder frustratie, problemen, verrassingen, maintenance, vergissingen. En dus meer tijd voor je échte business.
  • Test driven development: Rails moedigt developers aan om automatische testen te schrijven, en voorziet out of the box een mooi test framework. Deze geautomatiseerde testen gaan de applicatie zeer regelmatig testen. Bij een groeiende en meer complexe applicatie wordt het voordeel hiervan zeer duidelijk: je laat je testen lopen, en op enkele minuten gaat een “robot” heel je applicatie na op bugs, fouten of onverwachte scenario’s. Eventuele problemen kunnen snel ontdekt worden. Dit geeft beslissingsnemers een gerust gevoel wanneer aan de business logica wordt gesleuteld die gevolg heeft op de code. De automatische tests geven ons eventuele problemen aan, ook inconsistenties in de business logica. Ook kunnen er wekelijks nieuwe functionaliteiten gereleased worden, zonder dat een 10-koppig test team telkens door de hele applicatie moet gaan om na te gaan of er nergens problemen opduiken. Dat doet onze geautomatiseerde test omgeving wel wekelijks voor ons!

tests

Hierboven: 467 tests, waarin 686 “assumpties” over de code en business logica positief verlopen. En dat in 38 seconden! Een mens doet hier enkele dagen over. Alle testen zijn “groen”: we kunnen met een gerust hart de code online zetten.

Rails geeft developers de mogelijkheid om meteen op de business logica te gaan focussen. Zaken zoals paswoord management voor gebruikers, converties naar XML, API’s, overbodige configuratie en vaak terugkerende stukken code die onafhankelijk zijn van de business worden allemaal voorzien, telkens met als doel het ontwikkelings team te ontlasten van niet project specifieke taken en beslissingen.

Daarnaast moedigt Rails agile ontwikkeling aan: de brug tussen de ontwikkelaars en de klant wordt zo klein mogelijk gehouden, door middel van vele, snel op elkaar volgende releases en feedback rondes. Feedback van de klant kan snel in rekening worden gebracht, waardoor het project snel kan bijgestuurd worden. Hoe vroeger een fout wordt rechtgezet, hoe minder duur de fout is. Rails doet er alles aan om flexiebel en “vinnig” te zijn, en slaagt hier bijzonder goed in.

Daarnaast is Rails open source. En dat blijft niet bij een theoretisch principe. Een hele gemeenschap van ontwikkelaars deelt op Github stukjes interessante en business onafhankelijke code. Andere developers verbeteren deze code, of breiden ze uit. Na verloop van tijd zijn er honderden interessante, herbruikbare componenten ontstaan die je in je Rails applicatie kan gaan aanwenden, waardoor je weer beter op je eigen business logica kan gaan focussen. Er zijn ook nieuwe frameworks ontstaan bovenop Rails, zoals Spree voor e-commerce of Radiant voor CMS, die een stevige basis vormen voor zulke projecten.

Tot dat iemand me van het tegendeel kan overuigen, ken ik geen beter framework voor complexere (web) applicaties die steeds veranderende business, processen, wereld of markt moeten ondersteunen…

ruby-on-rails

Niet té agile, aub…

Agile software ontwikkeling is een mooi principe. Het principe zegt dat je snel van start gaat met programmeren, snel iets oplevert (ook al is dat nog niet 100% af), op basis daarvan feedback verzamelt van de klant, en op basis van die feedback de ontwikkeling bijstuurt. Dit herhaal je. Door regelmatig feedback te verzamelen en bij te sturen groeit het project letterlijk in de juiste richting.

Zoals overal, zijn er ook in software development veel dingen kan je onmogelijk op voorhand plannen. Denk maar even aan de renovatiewerken die je ooit hebt laten uitvoeren, of de bouw van je huis. Zelfs niet met een 300 pagina’s dikke functionele design en technische analyse kan je heel het project uitstippelen. En dat is precies het probleem dat agile ontwikkeling wil aanpakken. Planning is guessing. De weg die je op voorhand uitstippelt aan de hand van een gedetailleerde functionele design wordt toch nooit bewandeld. Er zijn onderweg altijd bijsturingen nodig. Die vangen we op door onderweg feedback te vragen en bij te sturen. We proberen niet eens om de weg uit te stippelen. Agile software ontwikkeling.

Daarnaast is het zo dat gaandeweg een project, zeker bij grotere projecten, de functionele vereisten wijzigen. Dit omdat het in het begin nog niet helemaal duidelijk was wat nu eigenlijk de bedoeling was van de software, omdat er nieuwe elementen opduiken die invloed hebben op de uiteindelijke vereisten. Agile ontwikkeling speelt hier mooi op in, aangezien de functionele vereisten pas gaandeweg worden bepaald.

Echter, ik vind het een probleem als Agile ontwikkeling een excuus wordt om helemaal geen functionele of technische analyse te doen. Er zijn namelijk een heel aantal zaken die je wél perfect op voorhand kan uitstippelen. Agile ontwikkeling is geen reden om de functionele design over te slaan. Een document van een paar pagina’s met een redelijk gedetailleerde uitwerking van de gewenste functionaliteiten is niet overbodig. Agile ontwikkeling is geen reden om helemaal geen technische analyse te doen. Bepaalde belangrijke technische keuzes kunnen pas correct gemaakt worden als er wél een volledig helikopter overzicht is van de volledige scope. Het is dus heus niet overbodig om de data die je ter beschikking hebt en de business logica die later met die data zal werken, even nader te bekijken.

Een goede functionele en technische analyse zorgen ervoor dat je koers zet in de juiste richting, zonder over details te praten. Agile ontwikkeling kan/moet gaandeweg die koers nog bijsturen. Maar als je op basis van “gevoel” en “Agile-we-zien-wel-na-de-eerste-iteratie” je koers kiest, kan je wel eens de verkeerde koers kiezen. Ik geloof dat een deftige functionele en technische analyse vòòr de eerste letter code het project serieus kunnen inperken qua tijd, kost, frustratie en misverstand. Ik geloof ook dat agile ontwikkeling nodig is om het project, na de eerste letter code, op koers te houden, en rekening te houden met onvoorziene omstandigheden die tijdens de functionele en technische analyse niet duidelijk waren.

scrum-sprint