Op 21 februari 2012 was er weer een DEMO meeting. DEMO (Dynamic Engineering Methodology for Organizations) is een modeleringstechniek om bedrijfsprocessen te modelleren en biedt architectuurprincipes om de implementatie te leiden en toetsen. Bij deze meeting kwam de tooling voor het tekenen en beheren van DEMO-modellen aan bod.
Van 12 tot 15 juni was ik bij de SPA Conference 2011, een jaarlijks terugkerende conferentie in Londen over Software Practice Advancement. De sessie die de meeste indruk maakte was getiteld: Wolf Pack Programming. Lees verder
Bij programmeren is het een vereiste dat je de code die je schrijft goed test. Dat weten de meeste programmeurs ondertussen wel. En omdat het testen met de hand te veel tijd kost, willen we dit graag automatiseren. Daarom schrijven we naast de productiecode nog meer code die de andere code uitprobeert en kijkt of het nog steeds werkt.
Tenminste, als je deze op de typische Scrum-manier invulling geeft. Denk eens serieus na over de informatie die in een typische daily stand-up wordt meegedeeld: Wat heb je gisteren gedaan? Wat ga je vandaag doen? Heb je nog blokkades? We zijn verteld dat we deze drie vragen moeten beantwoorden tijdens de daily stand-up. We moeten ook allemaal even gaan staan zodat het niet al te lang duurt, want stel je voor dat er wat nuttigs verteld wordt!
Ik doe niet meer mee!
De discussies over de randvoorwaarden waaraan een project moet voldoen om het wel echt Scrum te mogen noemen. De bedrijven die voor een mooi uurtarief ook “Scrum” doen. De Scrum Master die als Project Managers opereren. De examens waarvoor je niet kan zakken. De teams die Scrum doen zonder enige agility. De mensen die keer op keer het Half-arsed manifesto opnieuw uitvinden. De slechte reputatie die Scrum krijgt naarmate er steeds meer Scrumfall projecten falen. Vooral het laatste punt hield me een tijd erg bezig maar dat is verleden tijd. Ik doe er gewoon niet meer aan mee.
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.
Op dit moment ben ik in Baltimore, Maryland. Daar is deze week RailsConf 2010, de officiële conferentie over Ruby on Rails. De komende paar dagen zal ik vanaf hier verslag doen van wat er hier zoal gaande is.
Lees verder
Finalist zet graag in op innovatie en daaronder valt ook onze projectmethodiek. Hoe fijn Scrum/Agile ook werkt, mijn ervaring is dat het soms niet “past”. Dus hoe weet je nu of Scrum voor jou is?
In een vorig artikel heb ik drie handige principes voor gebruiksvriendelijke interfaces uiteengezet, maar hoe weet je nu of een GUI gebruiksvriendelijk is?
Lees verder
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
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.
De komende vier weken plaatsen we op de Finalist developer blog een serie over Ruby en scrum die vanuit vier verschillende rollen wordt beleefd. Wellicht ben je bekend met deze projectaanpak en programmeertaal? Wij hebben er het afgelopen jaar een aantal succesvolle projecten mee gedaan en we hopen je met deze serie te laten zien hoe Finalist Ruby/scrum projecten aanpakt en waarom deze aanpak zo succesvol is. Deze week is het woord aan Firas Daoud die het afgelopen jaar als projectmanager een aantal scrum projecten heeft begeleid.In mijn verhaal focus ik me op het scrum gedeelte van een Ruby/scrum project, met name over de opstartfase. Inmiddels heb ik het genoegen gehad om een aantal scrum projecten met Ruby (on Rails) de doen. Meestal waren dit kleine projecten en om zo’n klein project goed te doorlopen is het eeuwenoude gezegde ook binnen de ICT nog altijd waar: “een goed begin is het halve werk”.
In deze blog wil ik Lotus Notes beschrijven zoals ik het 18 jaar geleden heb leren kennen. Hierbij wil ik me met name richten op een aantal zeer prettige eigenschappen van het product. Waarom? Omdat het al zo lang geleden is dat ik met Notes werkte en ik me wel eens afvraag waarom ik een aantal van die prettige aspecten zoveel jaren later in de dagelijkse praktijk moet missen. Het afgelopen jaar heb ik bij Finalist kennis mogen maken met modernere technieken, waarop de huidige webapplicaties zijn gebaseerd. Daar zitten toepassingen bij waar Notes niet geschikt voor zou zijn geweest, maar ook een aantal die ooit in zeer weinig tijd te realiseren waren en nu na zoveel jaren ineens weer raketwetenschap lijken. Waarom worden sterke kanten van Lotus Notes niet hergebruikt? Wellicht gebeurt dat ook wel maar gebeurt dat tot nu toe buiten mijn blikveld. Daar zou ik dan graag kennis van nemen. Vandaar ook de licht provocerende titel van deze blog. Mijn doel is om reacties uit te lokken.
Goed, duidelijk, onderhoudbaar en overdraagbaar CSS schrijven levert nog wel eens wat problemen op. Maar al te vaak ontstaan ellenlange CSS files met enorme hoeveelheid klassedeclaraties. Als je ooit een dergelijk project mag onderhouden of aanpassen, dan ben je nog niet jarig. In dit artikel geef ik aan hoe je structuur in je CSS kan aanbrengen. Object georienteerd werken is daar één van. Weet je eindelijk waarom een “class” een “class” heet.
Lees verder