IHomer - thuis in IT

Bij het uitvoeren van collaboratief werk is informatie over de context van het werk essentieel. Voorbeelden hiervan zijn kennis over de andere leden van het projectteam, hun activiteiten en de huidige staat van het project. De Engelse term ‘awareness’ (wat zoveel betekend als bewustzijn) wordt vaak gebruikt om het beschikken over dergelijke informatie uit te drukken. Zulk soort informatie is essentieel, omdat dat het nodig is om de onderlinge acties af te stemmen, issues te bediscussieren, te anticiperen op acties van anderen, en hulp te vinden.

Onder meer doordat het hebben van voldoende ‘awareness’ zo belangrijk is ligt traditioneel bij het uitvoeren van projecten het zwaartepunt van de aanwezigheid op de kantoorlocatie. Dit komt omdat mensen onderbewust (en veelal automatisch) veel context informatie opvangen door op één locatie samen te werken met hun collega’s. Dit gebeurt bijvoorbeeld door geluiden en gebaren die collega’s maken en houdingen die zij aannemen. Wanneer er vaker wordt samengewerkt zonder fysiek bij elkaar aanwezig te zijn, zoals bij IHomer vaak het geval is, moeten er alternatieven worden gevonden om toch voldoende ‘awareness’ te krijgen om goed te kunnen samenwerken.

So assume you are assigned to a JEE/Web project with no written functional requirements, no technical design, no functional and unit tests and even no business process description. Sounds really hopeless, but it is your responsibility to learn the system and make adjustments to it. Does this sound familiar?? Hopefully not :) But every now and then this scenario seems to happen. One can start to complain :), stop working on the project or even better master the concept of Software Archeology. An additional thing is to adopt the use of Cobertura a code coverage tool which can easily be used to track down Functional Code Coverage.

Normally the concept of Code Coverage is used to identify what code is executed during development and test phase. This to give an indication on how much code you cover with your testing strategy (often unit testing). This is IMHO something you will always want to know! But in the case you do not have unit tests or creating them is impossible due to the technical/organisational nature of the project, you can rely on creating functional tests and still track down the ‘functional’ coverage with tools like Cobertura (or alternatives like Emma).

This tackles several problems:

• You are creating functional tests which can be used for regression testing
• You are creating awareness on how little is tested or is known about the system

Note: By functional testing we mean that we are going to test via the Web layer of the JEE project

To see an example on how the reporting looks like, check out this sample report!

Toen ik in 2000 de overstap maakte van industriële automatisering naar kantoor automatisering ben ik bij meerdere grote IT bedrijven op sollicitatie geweest. Eén van deze bedrijven liet sollicitanten met busladingen tegelijk opdraven. De eerste sollicitatieronde bestond uit het invullen van een IQ test, die me deed denken aan een Cito toets.

“We zoeken mensen met kennis van een vak, IT kunnen wij ze wel leren”, was het devies. De uitslag van de IQ test gaf aan dat ik niet geschikt werd bevonden als medewerker van het bedrijf. Bemoedigend kreeg ik de woorden mee dat dit niet hoefde te betekenen dat er voor mij geen carrière in de IT was weggelegd, alleen niet bij dit bedrijf. Op weg naar huis vroeg ik mij af: “Software maken is toch ook een vak?”.

In mijn tot nu toe nog jonge leven speelden sprookjes altijd een belangrijke rol. Wie kent de verhalen van Hans en Grietje, Kleinduimpje en Roodkapje niet. Later kwamen daar verhalen bij zoals Dr Who, Battlestar Galatica & Avatar. Dan weten jullie meteen welke genre sprookjes ik graag mag bekijken :) Het leuke aan deze sprookjes is dat je een bepaald niveau van volwassenheid moet bereiken om ze uiteindelijk allemaal op waarde te schatten. In de jonge jaren is een sprookje van Roodkapje bijzonder spannend moet ik je zeggen en later worden de Dalek en Cylons bijna levensecht.

Have you already implemented an multi-server artifact deployment using a Continuous Integration Engine? If not, then read ahead and maybe this article is of help.

The need for Continuous Integration

A good practice in a software development methodology and lifecycle is the use of a Continuous Integration Engine. The adoption of Continuous Integration improves you software quality by quickly reporting failed builds so you can modify/correct your code. Popular Continuous Integration Engines can often be extended with software quality tooling so you can report on specific quality aspect of your software. Thus informing developers and even other people who take an interest in the status of the latest build.

IMHO a failed build can also be identified as code that compiles but that does not meet the quality standards set by your organization. You are off-course totally free in defining what in your opinion a failed build actually means! A good build compiles, quality requirements have been met and automatic functional and unit testing has been successful.