Star Trekavond en Pizzarecord

Na de drukte rond de verhuizing (met saaie zaken als tafels en bureaustoelen plaatsen), zijn we langzaamaan eindelijk weer toe aan het komen aan de essentiële zaken van het ISAAC-bestaan. Eén daarvan is het houden van de inmiddels "Befaamde Ende Traditionele" Star Trekavonden.

De benodigde beamer en het projectiescherm zijn vorige week al opgehangen in de Wii en Star Trekhoek, en hoewel we het nog zonder Dolby 5.1 geluid moeten doen, konden we gisteravond wel voor het eerst in het nieuwe kantoor genieten van Deep Space 9 en The Next Generation. Kortom: ISAAC Star Trekavond nummer II!

Tijdens de vorige Star Trekavond kregen we het voor elkaar om een New York Pizzabestelling te hebben van meer dan 80 euro, maar die paste nog wel nèt in één scooterbox van de bezorgpuber (met wat nadelige pleteffecten als gevolg). Dat moest natuurlijk dit keer overtroffen worden! Met wat zachte dwang besloot iedereen dit keer dan ook om rijkelijk side-dishes te bestellen; met daarbij ook een groter aantal Star Trekkijkers, kwamen we uit op een totaalbestelling van 126 euro! Daarmee was ook het expliciete doel van deze bestelling bereikt, namelijk om niet één, maar twee bezorgpubers-op-scooter tegelijk onze bestelling te laten bezorgen! Whoahahaa! Volgens mij moeten we intussen toch wel een key-account zijn bij NYP.

Op het programma stonden wat fijne Dominion en Cardassian afleveringen van Deep Space 9, met daarna de klassieke dubbelaflevering Decent uit The Next Generation. Dat is die episode waarin prof. Steven Hawking zelf ook nog even een cameo rolletje heeft.

Enfin, het was natuurlijk weer een groots succes, maar de doelstelling voor de volgende keer is een pittige. Want hoeveel pizza's moeten we wel niet bestellen om (in goede IT-traditie), van 2 naar 4 bezorgpubers te komen bij Star Trek Night III?

Live long and prosper!

Het is me in de (aard)bol geslagen

“In mathematics, you don't understand things, you get used to them.” von Neumann

En met dat in gedachte zal ik toch proberen om een verhelderend stuk te schrijven over dit favoriete vak van menig programmeur. Waar heb ik dat aan te danken, hoor ik je denken en ergens heb je gelijk. Waarom zou ik je lastig vallen met een onderwerp waar je vroeger al slecht in was en wat je sinds het behalen van je diploma waarschijnlijk achteraan in je hersenen hebt geduwd (nog achter die genante herinneringen van toen je veertien was en je je geluk waagde bij het mooiste meisje van de klas). Hiervoor verwijs ik je naar Google in Mountain View, Californië. Die bedachten enkele jaren geleden dat het grappig zou zijn om een virtuele aarde te maken met aaneengeregen foto’s. Google Earth is in een korte tijd uitgegroeid tot een begrip en steeds vaker word je geconfronteerd met opdrachten waarbij locatiegegevens en kaarten een rol spelen. Het is een kwestie van tijd voordat je oog in oog komt te staan met de opgave om de afstand tussen twee coördinaten te berekenen en erachter komt dat deze coördinaten (uitgedrukt in lengtegraden en breedtegraden) niet altijd even ver van elkaar af staan. Met alleen de stelling van Pythagoras, die je ooit uit je hoofd hebt geknald omdat je wiskunde docent je wist te vertellen dat je hiermee alles kon uitrekenen, kom je letterlijk en figuurlijk nergens. Wat jij nodig hebt is een stevige dosis haversinus.

De haversinus formule kun je gebruiken om de afstand tussen twee coördinaten te berekenen en wel op de volgende manier:

• Je neemt de radius van de aarde (R), 6371 km


• Je neemt het verschil tussen de twee breedtegraden (∆b = b1 – b2)


• Je neemt het verschil tussen de twee lengtegraden (∆l = l1 – l2)


• En dan gooi je die in de onderstaande formule:
  
  afstand = R * (2 * atan2(√(sin2(∆b/2) + cos (b1) * cos(b2) * sin2(∆l/2) ), √(1-a)))

Ho ho ho, even een stapje terug, wat was die laatste? Laat me het uitdrukken in Java code, dat begrijp je vast beter.


public double calculateDistance(double long1, double long2, double lat1, double lat2) {
Integer r = new Integer(6371);
Double deltaLong = Math.toRadians(long1 - long2);
Double deltaLat = Math.toRadians(lat1 - lat2);
Double x = Math.sin(deltaLat/2) * Math.sin(deltaLat/2) + Math.cos(Math.toRadians(lat1)) * Math.cos(Math.toRadians(lat2)) * Math.sin(deltaLong/2) * Math.sin(deltaLong/2);
Double y = 2 * Math.atan2(Math.sqrt(x), Math.sqrt(1-x));
Double z = r * y;
return z;
}

Ok, laten we het er maar op houden dat je in wiskunde niks begrijpt, maar er aan went.

Mozilla 3 Merge conflict

Mozilla heeft met Firefox 3 een behoorlijke verbetering geleverd op de vorige versie, minder geheugengebruik en snellere opstarttijden lossen het grootste probleem van de browser op. Maar dat neemt niet weg dat we niet nog een schop onder de gordel kunnen geven in de richting van Mozilla. Neem een kijkje naar de afbeelding, dit is de site zoals die live stond op de releasedag van Mozilla FireFox 3. Het ziet er naar uit dat er een SVN/CSV merge conflict door het net is geglipt.

Een webservice in 5 minuten

EJB 3.0 en webservice annotations maken het mogelijk om webservices te maken, zonder alle details te kennen van WSDL of binding of wat dan ook. Sterker nog, je kunt in enkele minuten een webservice maken. Het enige dat je nodig hebt is een interface klasse, een implementatie klasse en een paar annotations. Laten we dit eens van dichtbij bekijken met het aloude “Hello World” voorbeeld. Maak een EJB 3.0 project en maak daarin allereerst de interface klasse.

package nl.isaac.ejb.service;

import java.rmi.Remote;

import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.jws.soap.SOAPBinding.Style;

@WebService
@SOAPBinding(style = Style.DOCUMENT)
public interface HelloWorld extends Remote {
String hello(String name);
}

Hierin zie je twee annotations staan. De eerste “@WebService” geeft simpelweg aan dat het om een webservice gaat. De tweede geeft aan welk soort SOAP binding je gebruikt, hierin heb je twee smaken “RPC” en “Document”. In het voorbeeld gebruik ik “Document”, maar in dit geval maakt het niet uit om hier “RPC” van te maken (Het verschil tussen document en RPC is grofweg gezegd dat RPC maar een enkel element als resultaat geeft en document een uitgebreid XML document terug kan geven). In de interface klasse staat verder alleen onze methode gedefinieerd. Let er wel op dat de interface jave.rmi.Remote extend. Nu kunnen we onze implementatie klasse maken.

package nl.isaac.ejb.service;

import javax.ejb.Stateless;
import javax.jws.WebService;

@Stateless
@WebService(endpointInterface = "nl.isaac.ejb.service.HelloWorld")
public class HelloWorldImpl {
public String hello(String name) {
return "Hello " + name;
}
}

Let erop dat, ondanks dat dit de implementatie klasse van een interface is, je deze niet implementeert met de code “implements HelloWorld”. Dit gebeurt in de annotation @WebService, die in deze methode zijn endpoint interface instelt. Deze verwijst naar de interface klasse die we zojuist gemaakt hebben. Onze methode wordt geïmplementeerd en voilá, een webservice is geboren. Deploy je project in JBoss en controleer voordat je een client maakt of je service draait door de WSDL file aan te roepen. Dit kun je doen door de URL van je project in IE in te voeren met daarachter “/HelloWorldImpl?wsdl”, dit zou je een XML document moeten tonen met alle details over de webservice.

Onautomatiseerbaarheid

Onautomatiseerbare zaken... ze bestaan echt!

Soms begin je vol goede hoop aan het bedenken van requirements voor een systeem(pje), maar besef je na een paar uur analyseren dat je in een soort ondoordringbaar woud van verradelijke schaduwen, valse doorstruiken, moerassige dalen en onoverbrugbare kloven terecht bent gekomen. Dan kun je stevig door blijven hakken in dat woud in de (ijdele) hoop ooit nog eens aan de andere kant te komen. Of je kunt gewoon zuchtend opgeven. Neem nu een persoonlijk knutselprojectje waar ik al een tijdje over aan het denken ben: een prima voorbeeld van zo'n Mirkwood vol valse bijtspinnen. Althans, dat denk ik.

Ik ben zelf nogal een liefhebber van boeken. Correctie, van mooie boeken. Ingebonden, leeslint, Nigeriaans lammerleer, goud-op-snee, eerste druk, je kent dat wel. In de loop der jaren is dat (volgens de laatste gefundeerde schatting) uitgekomen op zo'n 3000 kloeke folianten op een kleine 80 meter plank. En daar begint langzaamaan een probleem te ontstaan: wat staat waar, en wat heb ik eigenlijk?

Nu ik laatst voor de derde keer -blij ende tevree van bevredigde hebzucht- een boek uit een postpakket haalde om enkele uren later vol frustratie te ontdekken dat exact zo'n zelfde exemplaar al op m'n planken staat, werd het tijd voor ondersteuning middels ICT. Keiharde registratie zonder enig respect voor de privacy van de betrokken boeken, hoe speciaal of zeldzaam ook. Minister Hirsch-Balin zal trots op mijn plannen zijn!

Wat moet zo'n registratiesysteem kunnen? Dat was de vraag die ik mezelf in goede IT-traditie stelde (niet erg Agile, ik weet het...) Wel, er moeten printbare lijsten uit kunnen komen. Op auteur, op titel, op taalgebied, op uitgever en wellicht ook op "reeks" (iets waar ik nogal waarde aan hecht, bijvoorbeeld alles uit de Baskerville-reeks van uitgeverij Atheneaum, of alles uit de Franse Bibliotheek van Van Oorschot). Die lijstjes zijn ideaal om mee te nemen op strooptocht in muffige antiquariaten (over zulke strooptochten op leven-en-dood is overigens een hilarisch boek verschenen van de duitser Walter Moers, "De Stad van de Dromende Boeken" - heerlijk zulke meta-literatuur!). En ik moet makkelijk en snel kunnen zoeken met mijn systeem om te zien of ik iets al heb. Liefst per SMS, maar dat is toekomstmuziek. Het vullen van het systeem moet eigenlijk met een barcode-lezer, maar dat is vast te moeilijk voor een high-level niet-embedded mannetje als ondergetekende. Dan maar ISBN-nummers kloppen.

Verder is sorteren, het heerlijke ordenen ook een belangrijke zaak. Want alleen met ordening kan ik ook élk boek meteen vinden op de plank, zonder lelijke planknummers te moeten gaan monteren. Nu koester ik de blijde gedachte dat mijn huidige ordening op de plank vrijwel ideaal is, zeker gezien constraints als plankhoogte, diepte-ruimte en visuele uitstraling. Maar in die plankordening komt dus veel complexere logica om de hoek dan iets triviaals als alfabet, auteur of aankoopdatum. Zulke zielloos efficiënte systemen zijn meer iets voor professionele biobliotheken, niet voor een persoonlijke thuisbibliotheek.

Boekomvang speelt dus een rol. Maar hoe orden ik daar digitaal op zonder elk boek te moeten nameten? De plankhoogte wil ik nog wel invoeren, maar 3000 keer een rolmaat trekken gaat zelfs mij te ver. Wellicht kan ik iets met een plugin van Amazon.com (Jeff Bezos en co hebben boekmaat in de database staan) en het Centraal Boekhuis. Maar die laatste heeft weer geen gratis toegankelijke API. En dan die visuele uitstraling van een boek. Die ordening gaat bij mij vaak op het type omslag. Is het leer of linnen, of toch gewoon stofomslag of (de horror!) een paperback? Die informatie is deels nog wel te vinden voor moderne boeken, maar niet voor een oude uitgave van Couperus uit 1950, of een obscuur museumgidsje uit 1972. En wat te denken van mijn (zeldzame maar her en der met zorg toegepaste) plankordening op basis van "ideologische compatibiliteit van de auteurs"? Je kunt Nietzsche niet zonder uitlokking van oorlog naast een lieve schat als Montesqieu zetten. En gaan Rimbaud en Verlaine alsnog in boekvorm hun relatie verdiepen als ik ze naast elkaar zet? Of wat te denken van een Wagner-biografie bij een facsimile-dagboek van Anne Frank? Dat gaat finaal mis natuurlijk! Maar hoe automatiseer je dat? Moet je de Wikipedia gaan parseren, een neuraal netwerk aanzwengelen en dat beslissingen laten nemen? En gaat dat algoritme zo zwaar op mijn arme core2duo CPU worden dat ik er een distributed computing project van moet maken via BOINC? Zucht... te veel vragen! Aargh! Scope Creep!

Ja, soms moet je eigenlijk gewoon al opgeven voor je beginnen gaat. Ik doe het wel met de hand, ja!

SOA in een web 2.0 omgeving

Software ontwikkelaars komen steeds vaker de term SOA of WebServices tegen. Deze twee termen zijn erg vergelijkbaar. SOA is misschien een wat ruimer begrip, maar hierover zijn de meningen verdeeld. Wat vaak niet wordt begrepen is dat SOA een essentieel onderdeel is van de zogeheten web 2.0 hype. Er wordt onder de noemer web 2.0 vaak veel gewerkt met technieken om rijke webapplicaties te ontwikkelen, maar er wordt vaak niet gedacht aan de gegevensbronnen die deze technieken moeten aansturen. Deze gegevensbronnen zijn het kloppend hart van de web 2.0 applicaties. In het komende artikel wordt dit verduidelijkt en wordt een introductie gegeven op SOA en WebServices.

Web 2.0

Het is de IT eigen om vage termen te bedenken. Web 2.0 is daar misschien wel het beste voorbeeld van. Er is niet echt een vaste definitie van web 2.0 te vinden, maar het baseert zich op het idee van bijdrage van gebruikers en het delen van data op het internet. Websites die onder de noemer web 2.0 vallen, zoals wikipedia of flickr, bieden de gebruiker meer dan alleen harde data, ze bieden de gebruiker de mogelijkheid om hun eigen inbreng aan deze data toe te voegen.

SOA

Wanneer men spreekt over web 2.0 wordt de term AJAX vaak gretig aangehaald. AJAX, ofwel Asynchronous Javascript and XML, is bedoeld om van de “ouderwetse” websites, rijke applicaties te maken, door zonder een browser refresh data van de server te halen. De term SOA is daarbij lange tijd ondergesneeuwd geraakt door de vele technieken om schitterende applicaties te maken. Toch is SOA de spil rond web 2.0. SOA staat voor Service Oriënted Architecture en slaat op de gedachte die ook achter web 2.0 staat, het delen van data. Of, iets gedetailleerder, het aanbieden van data in een uniforme wijze. Dit kan op allerlei manieren, denk aan XML, SOAP, kommagescheiden bestanden, dynamic link libraries, etc. Hierdoor kan de data hergebruikt worden en gedeeld worden (met bijvoorbeeld businesspartners, of zelfs de hele wereld). Vanuit een bedrijfsvoeringaspect kan men op deze manier ook dynamischer werken en sneller reageren op wat de concurrent doet. Vooral dit laatste heeft ervoor gezorgd dat de term SOA aan populariteit wint.

De opbouw van een webservice

Bij een service zijn drie partijen gemoeid, de requestor, de provider en de broker. De requestor is de cliënt die gebruik gaat maken van de service. De provider is de partij die de service implementeert en de verzoeken van de cliënt verwerkt. De broker kan worden gezien als een makelaar waarbij de cliënt terecht kan om de juiste service te vinden. In grote settings kan dit middels een UDDI register, maar vaak ontbreekt dit onderdeel.

Een WebService is opgebouwd uit een aantal componenten. Het contract, de implementatie en de interface. In het contract staat beschreven hoe de webservice is opgebouwd, welke techniek gebruikt wordt en hoe de service kan worden aangeroepen. De implementatie is de daadwerkelijke code die de verzoeken van clients verwerkt en beantwoord. De interface wordt door de client gebruikt om verzoeken naar de service te sturen.

Belangrijk bij een webservice is de zogeheten “interoperability”. Dit houdt in dat de implementatie van de provider dusdanig moet zijn dat de cliënt altijd hiervan gebruik kan maken, ongeacht de techniek die hij gebruikt. In de mooiste gevallen volgt men de richtlijnen van het Basic Profile, die het gebruik van SOAP en WSDL voorschrijft, maar vaak worden ook JSON (Javascript object notation) objecten, Dynamic Link Libraries of kale XML gebruikt. In deze gevallen zijn er vaak online API beschrijvingen te vinden over de services.

De mashup

Populair op het internet is de mashup. Een webapplicatie die gebruik maakt van verschillende services en gegevensbronnen en deze mengt tot nieuwe informatie. Denk bijvoorbeeld aan het koppelen van bedrijfsgegevens aan de plattegronden van Google Maps. Vaak worden er op internet mashups gemaakt, simpelweg voor de mashup. Zo is er een site waar men op een plattegrond kan aangeven hoe een bepaalde locatie ruikt, waarop men vervolgens kan zoeken waar op deze planeet het zoal stinkt naar rotte eieren. Maar een mashup kan voor een bedrijf van nut zijn. Door gebruik te maken van vrijelijk beschikbare data op het internet kan het zijn eigen data verreiken, of extra diensten aanbieden op zijn website. Denk bijvoorbeeld aan een persoonlijke routebeschrijving van een bezoekers’ thuis adres naar de dichtstbijzijnde bedrijfsvestiging.


ESB

Laten we om te beginnen een kijkje nemen naar een site die op een bescheiden manier gebruik maakt van een webservice. De site climacount.com bevat onder andere informatie over een aantal CO2 reductie programma’s. Hierbij maakt het gebruik van data die vrij beschikbaar is op internet om een kaart te laten zien van de omgeving waar een programma aan het werk is. Dit is natuurlijk maar een kleine invoeging van externe data en hierbij hoeft verder ook niet nagedacht te worden over de implementatie van externe data in de site, maar stel er worden van meerdere bronnen gegevens opgehaald. Het is dan onwaarschijnlijk dat al die bronnen met dezelfde techniek beschikbaar zijn. Zeker wanneer je gaat denken aan e-banking applicaties, waar nog vaak van zeer ouderwetse technieken gebruik gemaakt wordt zoals COBOL. Dan is het verstandig om na te denken over de architectuur van je applicatie om te voorkomen dat toekomstige wijzigingen het risico met zich meenemen dat de hele applicatie op de schop moet. Hier komt de term ESB, ofwel Enterprise Service Bus, in het verhaal. Het klinkt vreemd maar om het eerder genoemde risico te vermijden maak je een applicatie die niks anders doet dan gegevens van derden beschikbaar maken. Een soort service die de andere services omsluit, zeg maar. Je webapplicatie kan op die manier altijd de zelfde techniek gebruiken om gegevens op te halen bij de ESB en de ESB zorgt voor het aanroepen van de daadwerkelijke service. In de onderstaande illustraties zie je vrij duidelijk het voordeel van het introduceren van een ESB.

Situatie zonder ESB


Situatie met ESB

Nadelen van SOA en Web 2.0

De toevoeging van componenten om de services beschikbaar te maken, de XML lagen die over componenten geplaatst worden en de extra beveiliging die nodig is bij openbare services vereisen allemaal extra processorkracht en dus zwaardere servers.

Conclusie

In dit artikel heb je de basisideeën achter SOA en WebServices in een Web 2.0 setting kunnen lezen. Essentieel hierbij is het beschikbaar stellen van data, het gebruiken van data van derden en het letten op de interoperability van de data. Bij het gebruik van meerdere WebServices kan het gebruik van een ESB de architectuur van je software overzichtelijk houden en eenvoudig bij te werken of uit te breiden. Een nadeel is dat het werken met een SOA denkwijze voor overhead in de software kan zorgen die extra processorkracht vereist en de hardwarekosten kan verhogen.

Heb je zin gekregen om zelf aan de slag te gaan met SOA, maar weet je niet goed waar je moet beginnen, neem dan een kijkje op http://www.programmableweb.com waar een opsomming van allerlei API’s en WebServices te vinden is.

JSR 303 bij ISAAC

De afgelopen twee dagen heb ik samen met Jan Willem JSR 303 (Bean Validation) besproken. Tijdens de gesprekken heeft hij zijn ervaringen met deze specificatie in wording uit de immer spreekwoordelijke doeken gedaan. Aangezien ik zelf de afgelopen maanden meer in de frontend hoek heb gezeten (flex, dojo) was het een voor mij zeer interessant gesprek. JSR 303 is een poging om het valideren van JavaBeans te standaardiseren en bouwt voort op de gebleken 'best practices' van XWork en Hibernate validator.

De kracht van Bean Validation is dat de programmeur declaratief controles kan definiëren die moeten worden uitgevoerd op de waarden van javabean properties. In plaats van dit soort controles te vangen in code, kan je deze logica met annotaties definiëren. Met behulp van een standaard validatie framework worden de annotaties uitgelezen en gebruikt om de bean te controleren. Dus in plaats van bijvoorbeeld de volgende code in bijvoorbeeld PersonFacade.java te moeten schrijven:

if (person.getEmailAddress() == null) {
 throw new ValidationException("person.email.isNull");
} else if (person.getEmailAddress().length() > 100) {
 throw new ValidationException("person.email.tooLong");
} else if (!isValidEmailAddress(person.getEmailAddress()) {
 throw new ValidationException("person.email.notValid");
} else {
 person.makePersistent();
}

kan het volgende worden geschreven in de EJB Person.java

@NotNull
@Length(max=100)
@EmailAddress
private String emailAddress;

en in PersonFacade.java vervolgens:

person.validate();
person.makePersistent();

Alle "heavy lifting" vindt plaats achter de schermen, hoeft maar eenmalig te worden geschreven en kan eenvoudig als een component worden gebruikt binnen verschillende projecten.

Ik heb in de interne ISAAC wiki een artikel geschreven waarin ik onze aanpak uit de doeken doe. Daarnaast staat daar wat voorbeeld code en enkele sequence diagrammen waarin uit wordt gelegd hoe het valideren precies in zijn werk gaat.

Mocht je verder willen lezen, hier zijn enkele intressante artikelen over JSR 303 op Gavin King's blog: 1, 2 en 3

Swingende Nick

Stel je eens voor: Je rijdt in je auto naar je werk. Het is als redelijk laat en de meeste files zijn al opgelost. De snelheidsmeter wijst vrolijk naar de 135 kilometer per uur. Uit je speakers knalt een oude van AC/DC (uiteraard nog met Bon Scott) en net kwam Motorhead nog even voorbij gedenderd. Je bent een jonge man aan het begin van een veelbelovende carriere bij het snelgroeiende en ass kickende (web)software bedrijf ISAAC. De afgelopen maanden waren nogal zwaar, want een tijdje terug is beslist dat jij de Java Swing frontend gaat bouwen op een redekijk complexe JBoss backend. Je hebt nog niet veel ervaring met deze techniek, maar je bent al hard aan het studeren voor je SCJP. Bovendien heb je net de klassiekers "Concurrency in practice", "Thinking in Java" en "Effectice Java" verslonden. Je ademt Java, kan genieten van elegante code en sinds Javapolis 2007 ben je stiekem een beetje verliefd op Fabrizio Giudici (omdat hij zulke mooie swing demo's kan geven). Gisteren heeft je collega Jan Willem de JBoss remoting koppeling over HTTP beschikbaar gesteld, dus je kan niet wachten om die te koppelen. Je wil doorgaan, meer listhandlers schrijven, meer race conditions spotten en vooral kijken of die nieuwe nimbus look and feel wellicht al stabiel is, zodat die trage substance eindelijk kan worden vervangen. Je hebt immers inmiddels meer dan genoeg van al die collega's die telkens melden dat "het er leuk uitziet, maar wel wat traag is.". Tsss, ze zullen hun woorden terugnemen zodra jij klaar bent. "Java is niet traag, kijk maar naar Eclipse. Of nou ja... wellicht is dat niet zo'n goed voorbeeld.", denk je terwijl je bridgestones de paardenkrachten aan het asfalt overdragen.

"Oh fuck! Niet nu! Ik zit in mijn auto op de fucking snelweg, dit is NIET handig!" schiet het door je hoofd, meteen gevolgd door een hoestbui waar de Marlboro man een puntje aan kan zuigen. Je klapt dubbel op je stuur en stuurt je auto zo goed en zo kwaad als het kan naar de kant van de weg. Je hebt het gevoel dat je longen een verblijf buiten je borstkas zoeken. De hoestbui waar je in vastzit, zorgt ervoor dat je maag nog van streek raakt ook. "Toch jammer van dat gebakken ei van vanmorgen", denk je als je ontbijt met een antiperistaltische beweging op dezelfde manier naar buiten komt als waarin het in eerste instantie in je maag terecht is gekomen. Als de hoestbui na een minuut of drie tot bedaren is gekomen en je de restjes ei met melk van je voorruit veegt, besef je eens te meer dat de dokter het toch waarschijnlijk bij het rechte eind had toen hij de diagnose kinkhoest stelde. Je baas Mark had dan wel gelijk toen hij zei dat het "Wel redelijk rock 'n' roll, is, als je 's ochtends in je auto de boel onderkotst", maar jij geeft dan toch zelf de voorkeur aan grote hoeveelheden bier als reden in plaats van een allesverzengende kinkhoest aanval.

"Dus nu is hij aan het rondzwerven en zullen we hem moeten vervangen.", zegt de arts met zijn typische ""kijk eens hoe ik met je meevoel" artsenstem. "Waarschijnlijk is het gebeurd tijdens een van uw hoestaanvallen.", vervolgt hij zijn verhaal. Het metalen plaatje dat enkele jaren geleden in je lies is bevestigd om de liesbreuk te fiksen, is inderdaad losgeschoten en nu moet je dus onder het mes om hem opnieuw te laten bevestigen. Het zit je niet mee. Eerst kinkhoest, dan wordt je huis leeggeplunderd door een inbreker, een sterfgeval in je naaste familie en nu ook nog eens opnieuw een liesbreuk. Je kan je nog goed herinneren dat de eerste drie weken na je vorige liesbreuk operatie geen pretje waren. Verdomme! En net nu het zo lekker ging met het ontwikkelen van de swingclient. De koppeling werkt nu als een tierelier. De CLP engine begint ook vorm te krijgen en we zijn zo dicht bij ons doel. Java code schrijven is toch wel wel veel leuker dan twee weken plat te moeten liggen. Hopelijk gaat het dit keer minder pijn doen dan de vorige keer.

Helse pijnen, al twee weken. Je kan amper lopen en langer dan een half uurtje zitten kan je wel vergeten. De operatie is dan wel goed verlopen, maar je verdenkt je chirurg er wel van een roestend tweedehands plaatje met weerhaken te hebben bevestigd. De vrolijke tijden waarin je de zelfgeschreven imageviewer aan de swing applicatie toevoegde lijken ver weg. Ah ja, die imageviewer die je laatst nog op java.net hebt gezet en een heuse reactie kreeg van Fabrizio. Je glimlacht als je denkt aan je java.net gebruikersnam: cuswatesl, ze zouden eens moeten weten waar dat voor staat. Auw! Het glimlachen was overgegaan in een grinnik, maar daar je is lies toch nog echt niet aan toe. "Hoe zou het nu gaan op het werk?", vraag je je af, meteen gevolgd door vrolijk bellen van de deurbel. Mark, je baas staat daar, met een heus cadeau van al je collega's van ISAAC. En helemaal in ISAAC stijl is het geen bos bloemen, of een lullig fruitmandje, maar een heuse VLEESMAND. Kijk, daar knapt een jonge rockgod van op: worsten en varkenslappen. Fuck de pijn! Het leven is goed!

Korte Eclipse tip

Een korte Eclipse tip voor iedereen die vind dat zijn Eclipse te traag is. Start Eclipse op met de volgende parameters:

-vmargs -Xmx1024m -XX:MaxPermSize?=128m

Op deze manier maak je een gig beschikbaar aan geheugen en 128Mb aan PermSize (voor het laden van Classes)

Gratis Photoshoppen met Photoshop Express

Iedereen die 'iets met websites' of 'iets met internet' doet komt er op een gegeven moment niet onderuit een plaatje te moeten bewerken in Photoshop. Aangezien Photoshop voor dat af en toe een plaatje bewerken vrij duur is en illegale software natuurlijk illegaal is, is er nu een gratis en legale manier: Adobe Photoshop Express.

Maak gratis een account aan en je kunt gratis en online foto's bewerken en opslaan met 2GB aan eigen online opslagruimte.

Natuurlijk niet zo uitgebreid als Photoshop maar wel met de standaard benodigdheden als rode-ogenreductie, de kleurinstellingen en de mogelijkheid om foto’s bij te snijden en het formaat aan te passen.

Check Photoshop Express