Babel IT

Java software ontwikkeling

DevOps

Ik kwam een leuk artikel tegen over DevOps: http://zkybase.org/blog/2012/05/08/devops-what-it-is-and-why-you-should-be-doing-it/.

DevOps gaat over de samenwerking tussen development en operations (beheer). Zaken als Continuous Delivery zijn alleen mogelijk indien development en operations samenwerken, hun expertises bundelen.

Open-source versus closed-source

De meeste bedrijven waar ik mijn opdrachten voor uitvoer zijn fervente gebruikers van closed-source software. Daar betalen ze jaarlijks (vaak) enorme bedragen voor aan bedrijven als IBM, Oracle, SAP en (niet te vergeten) Microsoft. Ik begrijp dat niet zo goed. Voor de meeste producten van hiervoor genoemde leveranciers bestaan open-source varianten. Deze varianten zijn doorgaans gratis of tegen veel lagere (licentie) kosten te verkrijgen. Waarom doen bedrijven dat niet? O, er zijn wel bedrijven die dat doen en die zijn er vaak ook erg succesvol mee. De licentiekosten zijn lager, in sommige gevallen zijn de personeelskosten hoger omdat er meer kennis in huis moet zijn die anders bij een leverancier wordt “ingekocht”. Maar waarom doen niet veel meer bedrijven dat?

Waarom stappen niet alle bedrijven over op open-source alternatieven? Zelfs de overheid heeft ooit geprobeerd in het kader van het programma “Nederland Open In Verbinding” overheidsinstellingen kritisch te laten kijken naar de software die ze gebruiken en die, waar mogelijk en nuttig, te vervangen door goedkopere en aan open standaarden voldoenende alternatieven. Dit is bij de meeste overheidsinstellingen jammerlijk mislukt: welke gemeente gebruikt alleen OpenOffice? Of zijn de ministeries overgestapt op Linux op de desktop? In Duitsland (en ook België) vindt dit op veel grotere schaal plaats, dan in Nederland. (Sterker nog, in openbare aanbestedingen wordt doodleuk vereist dat Microsoft Office moet worden gebruikt.)

Waarom gebruiken bedrijven geen open-source software? De meeste bedrijven gebruiken wel degelijk open source software, alleen ze weten het niet. Neem een product als IBM WebSphere applicatie server: een groot deel van de kernfuncties van dat systeem wordt door IBM ingevuld met open source libraries, zoals Axis 2 (voor webservices), OpenJPA, etc. En nu het frappantste: als je binnen een bedrijf dat bijvoorbeeld WebSphere gebruikt, gaat vragen of iemand zich ervan bewust is dat er zoveel open source libraries in het product zitten, dan kijken ze je meestal heel vreemd aan. Maar, waarom zou een bedrijf als IBM dat doen? Open source libraries gebruiken in zijn producten? Dat doen ze niet als het kwalitatief niet aan hun standaarden voldoet. Kortom, die libraries zullen dan dus best goed zijn. Als een bedrijf als IBM dat doet, waarom zou de gemiddelde bank, overheidsinstelling of ander bedrijf dat dan niet ook kunnen doen?

En dan komen we aan het heikele punt: als je iets van een bedrijf koopt, kun je hem/haar ervoor aansprakelijk stellen als het niet werkt. Mijn ervaring met bedrijven als IBM maar ook Oracle en Microsoft, is dat hun support nou niet direct het beste onderdeel van het bedrijf is. Mijn ervaring met open source communities is daarin veel positiever. Meld maar eens op een forum dat feature X of Y van open source product B niet goed functioneert. Meestal ligt de fix de volgende dag al klaar. Dat heb ik bij grote bedrijven nog nooit meegemaakt. Ik kan me herinneren dat we een keer tegen een probleem in DB2 op AIX aanliepen (eind jaren ’90 speelt dit). Het heeft alles bij elkaar ongeveer 6 maanden geduurd (en dat is erg snel) voordat daarvoor een fix beschikbaar was (we hebben de livegang van het systeem ervoor moeten uitstellen). Sterker nog, het duurde 4 maanden voordat IBM toegaf dat het inderdaad een bug in de software was. Kortom, je betaalt als bedrijf enorme bedragen aan leveranciers en vervolgens moet je nog maar hopen dat ze je probleem kunnen c.q. willen oplossen. Beetje vreemde situatie.

Ook het argument dat een leverancier niet zo snel de stekker uit een product zou trekken omdat het er zoveel aan verdiend, is niet valide. In IBM Portal 6.0 zat PDM, dat hebben ze in 6.1 (en alle latere versies) gewoon laten vallen zonder er een directe vervanger voor in de plaats te zetten. Lekker betrouwbaar. Indien in een open source pakket zo iets gebeurd, heb je altijd de source code nog. Mocht je per se gebruik willen blijven maken van de betreffende feature, dan bouw je hem desnoods zelf in in de nieuwe versie. Ook het fixen van problemen, kan op deze manier. De meeste Java libraries zijn zo opgezet dat het zelfs gefaciliteerd wordt zelf aanpassingen aan het framework aan te brengen.

 

Mijn punt is dus: gebruik open source software. Zorg dat je de mensen met de juiste kennis en kunde in huis hebt, danwel inhuurt (dat moet je voor closed source producten ook doen, dus daarin is geen verschil) en houdt die licentiekosten lekker in je zak en doe er leuke dingen mee, zoals meer business genereren.

m2eclipse

Handig om Maven projecten in Eclipse te gebruiken en dan ook direct alle dependencies goed te hebben. Dat is wat de m2eclipse plugin doet. Inmiddels is er een nieuwe versie van de plugin die voor elke plugin een extensie nodig heeft, maar de oudere versie probeerde dit allemaal zelf uit te vinden. In het algemeen met hele goede resultaten: directories voor gegenereerde code werden automatisch toegevoegd en zo. Erg fijn. Maar toen ik wat code (xsd’s in dit geval) wilde uitpakken in een bepaalde directory met de standaard magen-depenendencies-plugin ging het binnen Eclipse toch mis. Wat blijkt: m2eclipse runt Maven met een speciale EnhancedLocalRepositoryManager. Deze repository manager zorgt er (onder andere) voor dat indien een dependency zich in de workspace bevindt, deze niet als jar maar als project dependency wordt opgenomen. Voor Eclipse zelf is dat heel fijn, voor mijn probleem niet. De maven-dependency-plugin probeerde namelijk een jar uit pakken terwijl dit als een directory, namelijk de classes directory van het project, werd gepresenteerd. Ik heb uiteindelijk zelf een unpack-maven-plugin geschreven die als de repository manager een directory teruggeeft een kopieer actie uitvoert en als het een bestand is (doorgaans een jar) een unpack actie. Daarmee werkt de plugin zowel correct binnen Eclipse als daarbuiten.

JAX-WS en Spring

Normaal laat je de dependencies door Spring injecteren. Maar hoe doe je dat met objecten die niet door Spring gemanaged worden? In het geval van JAX-WS endpoint klassen is dat ene probleem. Instanties van deze klassen worden gemaakt door de container. Spring biedt wel wat mogelijkheden. In WAS 7 werkt de super-klasse aanpak niet, omdat de Spring context nog niet geinitialiseerd is op het moment dat de instantie wordt aangemaakt. WAS 7 doet dat voordat de web applicatie zelf geinitialiseerd wordt gezamenlijk met de WebApplicationContext. Dat werkt dus niet.

Via een statische klasse die geïnjecteerd wordt door Spring kun je via een omweg alsnog aan de dependencies komen.

Maar, misschien dat de manier met AspectJ in combinatie met Spring 3.1.0 en WebSphere Load Time weaving wel gaat werken. Ik moet het nog verder uitzoeken.

In Glassfish met CDI zijn er blijkbaar ook problemen mee, geeft een kennis van mij aan. Het is blijkbaar allemaal niet zo simpel.

Zodra ik weer wat verder ben, komt er weer een berichtje over.

Update: Met de LTW lukt het ook niet. Ondanks dat de Endpoint klassen door de classloader worden geladen die door Spring is voorzien van LTW, is de endpoint klasse zo’n beetje de enige klasse die niet geweaved wordt. Allemaal heel raar, maar het is zo.

Uiteindelijk gekozen voor een oplossing waarbij de Endpoint klasse zo goed als leeg is. Alle functionaliteit wordt in een Delegate geprogrammeerd. Deze delegaten is een Spring managed klasse. Via een base klasse kan dit op een eenvoudige manier worden gerealiseerd met een minimum aan code in de Endpoint klasse. Het is niet de meest mooie oplossing, maar het werkt wel.

Clean code

Het boek Clean Code van Uncle Bob (Robert C. Martin) is interessant voor zowel ervaren als minder ervaren ontwikkelaars. Het boek richt zich vooral op het belang van goed onderhoudbare code. Uiteindelijk bevat de source code van een programma de waarheid over wat er uitgevoerd wordt. Alle andere documentatie, functionele en technische ontwerpen, architecturen, user stories, etc, bevatten geen uitvoerbare code. Ze hebben hun eigen waarde, maar uiteindelijke zegt de source code echt wat de machine doet. Het is daarom van essentieel belang deze source code goed op te zetten en te onderhouden. Het boek geeft een aantal zeer bruikbare tips om dat te doen.

Inkoppertje is natuurlijk de naamgeving van alle onderdelen van de code. Een goede naam is essentieel voor het begrip van de code. Beter lang nadenken over een goede naam, dan zomaar iets doen. Probeer maar eens code van een paar dagen geleden te lezen en te snappen wat er precies gebeurd. Als de namen niet kloppen, kost dat veel tijd.

Een aanbeveling uit het boek: code moet lezen als een boek. Je moet dus ook structureren als een boek. In geval van Java gebruik je klassen en methoden. Door onderscheid te maken in de verschillende niveau’s van abstractie, krijg je duidelijke hiërarchieën van elkaar aanroepende methoden en elkaar gebruikende klassen. Dit bedenk je niet op voorhand, ja misschien de grote structuren, maar de details komen pas later na een aantal iteraties en refactorings.

Ondanks mijn 15 jaar ervaring met software ontwikkeling, haal ik nog steeds nuttige tips uit het boek. De meeste dingen weet ik wel, maar pas als je er weer eens op gewezen wordt, ga je ze weer netjes toepassen. Het leidt uiteindelijk tot veel betere code en ook betere applicaties voor de eindgebruikers. En daar gaat het tenslotte om.