“Er zijn twee dingen moeilijk in de IT”, vertelde een collega me ooit: “Een printer installeren en communiceren met een extern systeem”. In de praktijk blijken beiden vaak waar. Met printers kan ik jammer genoeg niet helpen. Met het oplossen van integratievraagstukken hopelijk wel.
Een tijdje terug heb ik samen met een klant nagedacht hoe een aantal lang lopende taken verdeeld kunnen worden over een aantal computers. Via een web interface moeten bezoekers makkelijk taken kunnen aanmaken zonder af te weten van het achterliggende computerpark. Na een aantal uur komt een computer met een rapport, wat weer te downloaden moet zijn voor de klant. Daarnaast moest de klant het computerpark kunnen beheren, dus computers uit het rekencluster halen of juist nieuwe toevoegen. De beheerschermen voor taken en computers (vanaf hier: workers) zijn uiteindelijk geïmplementeerd met behulp van Struts 2 waarover meer in deze blog.
Lees verder
Vanaf eergisteren is officieel de stabiele versie van Ruby on Rails 2.3 (versie 2.3.2 dus) de deur uitgegaan. Omdat er nogal wat wezenlijke toevoegingen en veranderingen aan het framework zijn gedaan, bespreekt Iain enkele highlights van deze release.
Hoewel Java al een flink aantal jaren meegaat, wordt er toch nog steeds aan gewerkt om de taal te verbeteren zodat deze ook in de toekomst nog bruikbaar is. Java 6 is inmiddels ruim twee jaar geleden uitgebracht en begint dus een beetje ouwe koffie te worden. De meeste mensen geven voorkeur aan verse koffie, dus daarom werkt een groot aantal ontwikkelaars al aan Java 7, die we in maart 2010 kunnen verwachten. In dit artikel zal ik proberen een overzicht te geven over de huidige stand van zaken en wat we zoal in Java 7 kunnen verwachten.
Lees verder
Deze maand plaatsen we op het Finalist Developer Blog een serie over Ruby en scrum. Dit artikel is het laatste in die serie, waarin één van onze testers – Marco Plaisier – vertelt over zijn ervaringen met Ruby en scrum binnen Finalist.
Ik ben gefascineerd door de titel van het boek The 4-Hour Workweek. De strekking van het boek is dat je, door werk slim in te delen, maar 4 uur per week hoeft te werken. Je kunt dit bereiken met het vier (alweer) stappen plan: DEAL. Oftewel, Definition, Elimination, Automation, Liberation. Dit past toevallig genoeg perfect op onze scrum aanpak.
Vorige week bezocht ik de QCon conferentie in London. De meeste conferenties die ik tot nu toe bezocht gingen over oplossingen, zonder deze specifiek te koppelen aan een probleem. QCon is precies andersom, architecten en developers vertellen juist hoe ze bepaalde problemen hebben opgelost. Het kader is in dat geval dus niet zozeer de programmeertaal (alhoewel de meeste sprekers wel een Java/JDK achtergrond hebben) maar bijvoorbeeld de beschikbare resources of het sociale klimaat.
De setting was erg informeel. Denk ‘klaslokaal’ in plaats van de ‘bioscoopzaal’ die je wellicht kent van andere conferenties. In deze setting zit je met een man of 20 te luisteren naar bekende architecten uit het IT landschap zoals Martin Fowler, Dan North, Rich Hickey, Dion Hinchcliffe, Ola Bini, Venkat Subramaniam, Graeme Rocher, Joe Armstrong etc. En in plaats dat ze hun nieuwe boek of framework aanprijzen geven ze je een kijkje in hun eigen keuken.
Deze maand plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Vandaag geeft Felix zijn visie op Ruby/ Scrum volgens de product owner.
De product owner vertegenwoordigt de klantorganisatie, het financieel belang en de domeinexpertise in een Scrumproject. De meest ontzagwekkende taak van de product owner is dat hij de te bouwen softwarefuncties kiest (prioriteert). Dat is niet zo gemakkelijk. Product owners kunnen het best streven naar Conceptuele Integriteit als ze een sprint vullen.
Lees verder
HTML levert je een setje elementen om je documenten mee te markeren. Aangezien HTML oorspronkelijk is bedoeld voor het markeren van wetenschappelijke documenten [1], en daarna langzaamaan uitgebreid is naar de wensen van gebruikers, is het vaak niet compleet genoeg om alles te kunnen beschrijven wat we zouden willen. Gelukkig is er een mechanisme om de boel betekenisvol uit te breiden, in de vorm van het class attribuut.
Deze maand plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Vandaag geeft Iain zijn visie op Ruby/ Scrum volgens de ontwikkelaar:
Ik hou van Scrum. Zo, dat is er uit. Ik ben een van die programmeurs die liever niet eindeloos vergadert en interviewt over hoe iets moet gaan werken. Ik krijg liever een korte instructie, ik bouw wat en laat dat zien. Mijn eerste ingeving is zelden gelijk naar wens, dus ik krijg feedback over wat ik gebouwd heb en verwerk dat weer. Zo komen we samen dichter bij het eindproduct. Ik houd er niet van om de gehele dag alleen maar te praten. Ik wil zo snel mogelijk mijn handen vuil maken en aan het werk. Effectief biedt scrum je evenveel overleg als de wat traditionelere projectaanpakken, maar meer verspreid, waardoor het wat beter uit te houden is.