De PHP-conferentie is inmiddels al weer twee weken terug, maar ik was nog niet toegekomen aan het schrijven van mijn verslag van dag 2 en 3. Hierbij dan een samenvatting van de lezingen die ik heb bezocht, waar er weer keus genoeg was. Ik heb gekozen voor lezingen over herbruikbaarheid, ORM, schaalbaarheid, REST, testen en SCRUM.

De dag begon met een keynote van Kevlin Henney. Auteur van het boek 97 things every programmer shoud know. Deelnemers van dag 1, waaronder ik, kregen een gratis kopie aan het eind van de dag, dus ik had al een aantal hoofdstukjes gelezen. Het is een boek dat erg makkelijk wegleest, met wijsheden van verschillende programmeurs van elk 2 pagina’s. In zijn keynote lichtte Kevin er een aantal uit, waar ik er een van zal uitlichten. Namelijk waarom vaak een verschil optreedt tussen de initiële schatting en de inspanning die uiteindelijk geleverd wordt.

Zo moet er onderscheid gemaakt worden in drie fasen die altijd worden doorlopen:

1. De ontwikkelaar maakt een inschatting (estimate)
2. De klant (of projectleider) geeft aan dat het in minder tijd moet (target)
3. De klant of projectleider komen tot een nieuwe inschatting (commitment)

Doordat de termen door elkaar heen lopen, kan de klant de estimate en de commitment door elkaar halen. De ontwikkelaar voelt zich gedwongen zich te commiteren aan een onmogelijke deadline. De drie fases scherp houden kan dit helpen voorkomen, door niet alleen de hoeveelheid tijd terug te brengen, maar ook de hoeveelheid te volbrengen taken.

De eerste lezing van de dag die bezocht was van Derick Rethans, de maker van XDebug. De lezing had als titel Designing for Reusability en dat vond ik veelbelovend. Het begon dan ook goed toen Derick een high-level plaatje met componenten liet zien en vertelde dat de afhankelijkheden tussen de componenten verkleind moet worden.

Helaas bleef het hierbij en dook Derick al snel code op micro niveau in en lepelde de code refactoring praktijken van Martin Fowler op en legde de nadruk op testbaarheid van code. Zinvol, maar niet direct relevant. Ik had toch iets meer op architecturaal niveau verwacht. De titel van de lezing was nogal misleidend.

Sebastian Bergman vertelde in The cake is a lie over zijn ervaringen met scaffolding, code generation en ORM. Het was duidelijk dat hij sceptisch is.

Voor een Duits IT magazine werd hij gevraagd om een webapplicatie te maken in PHP in een serie waarin implementaties in verschillende programmeertalen werden vergeleken. Zonder voorgaande ervaring, besloot hij het op te pakken met het Symphony raamwerk, dat is gebaseerd op het Propel ORM raamwerk.

Zijn ervaring was dat het mogelijk was in zeer korte tijd een functionele applicatie te maken, waarbij een groot deel van de code (met name de infrastructurele code) gegenereerd is. Hij stelde echter vraagtekens bij de onderhoudbaarheid van de code.

Daarbij haalde Sebastian een artikel aan waarin ORM het Vietnam of Computer Science wordt genoemd. ORM kan in een aantal gevallen grote voordelen op kan leveren, maar als het overal gebruikt wordt, dan loopt de return on investment sterk terug Zelf was hij als consultant al bij verschillende bedrijven binnen geweest waar ORM tot onbeheersbare applicaties had geleid. De gegenereerde code heeft een te sterke onderlinge koppeling, waardoor aanpassing tot ongewenste bijeffecten leidt.

In het kort, scaffolding leidt tot technical debt. Sebastian adviseert om code generation te vermijden en om het Data Mapper patroon te gebruiken in plaats van Active Record. Onder andere Doctrine 2 maakt gebruik van Data Mapper. Ook adviseert hij frameworks met loosely coupled componenten te gebruiken als Symphony Components of Zeta Components.

Na een goede lunch startte Lorenzo Alberton een lezing over The Art of Scalability. Het was op zich een prettig verhaal over de high-level aspecten voor het schaalbaar maken van applicaties met een grote load.

Lorenzo wilde hier een brede kijk op geven door het vanuit drie aspecten toe te lichten:

1. mensen
2. processen
3. techniek

Het idee is dat voor het schaalbaar maken van een applicatie, het niet voldoende is om alleen naar de technische aspecten te kijken. Er moeten mensen zijn met de juiste competenties en verantwoordelijkheden en ook de processen moeten goed zijn ingericht.

In plaats van lukraak de applicatie te optimaliseren moet met de klant de pijnpunten en beoogde groei in kaart gebracht worden waarna, door middel van een proces aangestuurd door een projectleider, de applicatie kan worden aangepast. Wat ik erg jammer vond, is dat er geen enkele verwijzing is naar bestaande en wijd toegepaste best practices voor applicatiebeheer zoals BiSL, ASL en ITIL. Zijn verhaal kwam rechtstreeks uit het boek The Art of Scalability van Abott en Fisher, misschien dat er daar wel gerefereerd worden naar deze praktijken.

In het technische deel toonde Lorenzo onder andere een interessante afweging tussen de verschillende manieren waarop een applicatie opgedeeld kan worden. Het doel van optimaliseren is hierbij om het aantal requests dat de applicatie kan verwerken te verhogen en niet zozeer de applicatie sneller te maken. Een tweede doel is om de applicatie goed om te laten gaan met teveel requests. De applicatie mag dan niet vastlopen, maar moet goed verder werken als de load weer minder wordt. Tevens dient het uitgangspunt hierbij de business te zijn, met andere woorden waarmee wordt organisatie het meest geholpen, in plaats van te kijken waar het technisch het makkelijkst een optimalisatie te maken is.

Met 123 (!) slides is het wat teveel om samen te vatten, maar de architectuurprincipes wil ik nog wel laten zien:

Architectuurprincipes voor schaalbare applicaties

Al met al een informatieve presentatie, maar de spreker moest door zijn sheets racen om zijn verhaal binnen de 45 minuten af te ronden. Het gebruik van een procesmodel voor het beheer van de applicatie is goed, maar zou niet specifiek voor het schaalbaar maken van applicaties moeten zijn. Dit geldt natuurlijk voor het beheer van alle volwassen applicaties.

In de presentatie Writing Re-usable RESTful Web Services with ZF van Matthew Weier O’Phinney vertelde Matthew hoe hij RESTful webservices ontwikkelt met het Zend Framework. Zend Framework heeft een REST-module, maar dit is een REST/RPC interface en maakt geen gebruik van de standaard HTTP methoden als GET, PUT, POST, DELETE en HEAD.

Matthew heeft daar zelf code voor ontwikkeld en hij vertelde hoe het allemaal had weggestopt zodat er een schone controller en view overblijft. De manier waarop hij dit deed was erg netjes zodat er een goede separation of concerns is.

Gek genoeg schrijft hij daarbij voor elk project sniffers die de accept header inspecteren om te achterhalen wat voor type bestand opgevraagd wordt door middel van strstr. Dit kwam erg low-level over bij mij. Hopelijk wordt het gestandaardiseerd in een declaratievere oplossing. Het toevoegen van een pure REST-module lijke me een welkome aanvulling voor Zend Framework.

In Testing Untestable Code ging Stefan Hochdörfer in op hoe unit tests toegevoegd kunnen worden aan code die zonder unit tests ontwikkeld is. De manier waarop hij dit doet is erg bijzonder.

Stefan stelt dat voor het toevoegen van unit tests, de code gerefactord moet worden. Maar, zoals Martin Fowler stelt in zijn boek Refactoring: voordat je start met refactoren, controleer dat je een solide suit van tests hebt. De conclusie is dat unit tests moeten worden toegevoegd zonder de bestaande code te wijzigen. Om dit te kunnen doen maakt Stefan optimaal gebruik van de flexibiliteit van PHP:

• Gebruik __autoload om een mock class te laden
• Pas de include path aan of maak een custom FileStreamWrapper om include bestanden te mocken
• Laad extensies niet zodat je eigen mock implementaties kunt maken van functies of gebruik de runkit extensie om een functie te vervangen door een mock functie

Met bovenstaande opties zijn veel afhankelijkheden te vervangen door mock implementaties voor testen. Vaak is dit niet genoeg. Stefan gaat dan nog verder door testcode te genereren. Door middel van een transformatietaal genereert hij vanuit de originele broncode testcases. De unit tests worden op de gegenereerde code uitgevoerd in plaats van op de originele code. De code wordt gegenereerd door het maskeren van delen, het aanpassen van globale variabelen en het toevoegen van pre/postfixen aan methodes en klasses zodat er eenvoudig een mock implementatie kan worden gemaakt.

Het is een onconventionele aanpak, maar bij code die niet mag breken maar toch onderhouden moet worden is het wellicht de enige optie.

De laatste presentatie op de dag was Agile PHP Software van Thorsten Rinne. Hierin beschreef hij hoe het SCRUM-proces bij zijn bedrijf wordt toegepast. Redelijk volgens het boekje, waarbij er ook uit Crystal Clear en Extreme Programming elementen zijn gehaald. De ontwikkelaars worden onder andere zoveel mogelijk bij elkaar in een hok gezet, waarbij ze twee aan twee naast elkaar zitten om aan “Side by side” programming te doen. Pair programming blijkt niet zo goed voor ze te werken.

Hoewel het onderwerp interessant is, was de presentatie bijzonder saai. Er was een klein hoogtepuntje aan het eind van de presentatie toen er een discussie op gang kwam. Een van de toehoorders vroeg zich af hoe de architecturele integriteit bewaard wordt, waarop werd geantwoord dat dit een continu proces is.

Een andere vraag was hoe SCRUM is toe te passen als om een fixed price project wordt gevraagd. Hierop antwoordde Thorsten dat er in zo’n geval een backlog wordt gemaakt met alle user stories. Als er tijdens de iteraties stories bijkomen, dan gaan andere stories uit de backlog.

Hiermee kwam een einde aan de presentatie en aan de tweede dag van de conferentie. Het waren veel interessante onderwerpen en vaak ook interessante presentaties.

Noot: Slides van de presentaties zijn te vinden op de Dutch PHP Conference 2010 pagina op joind.in.