Hek of muur

In de naslaap van een terroristische aanslag worden altijd maatregelen genomen. Zo ook na die van 13 november in Parijs.
De Franse premier liet al vrij snel blijken dat de toen aankomende milieuconferentie in Parijs zeker zou doorgaan, maar dat bijna alle protest acties die er rond hingen zeker niet zouden doorgaan. Alle mogelijks protest handig in de kiem gesmoord.
Maar ja, niet dat enige protestman gemakkelijk tot Parijs zou gaan. Terwijl de Parijse burgemeester zei “wij hebben geen schrik”, sloot Frankrijk haar grenzen. En ook enkele andere landen deden daar mee mee.
Precies of een grens bestaat nog? Toch niet in West Europa zeker! Dan maar een hek bouwen aan de buitengrenzen van het grote Europese rijk.
Waarom dan geen muur? Die zijn evenveel intrek. Zie de Israëlische, de Berlijnse of de Chinese muur. Die laatste staat er nog en is nu een toeristische attractie. Muren zijn in de mode en mogelijks economisch een betere investering dan een hek.

Wanneer je een hek bouwt, heb je metaal nodig. Dat komt waarschijnlijk via China. Een hek is zo kapot geknipt. Dus dien je dit frequenter te controleren en waarschijnlijk ook repareren.
Een muur daarentegen kan je op de meeste plaatsen met lokaal verkrijgbare materialen maken waardoor de lokale economie gesteund wordt. Een muur knip je niet zo maar door en vereist dus waarschijnlijk minder onderhoud. Wanneer je er dan nog een mooie muur van maakt, wordt die in 1000 jaar misschien wel een toeristische attractie.

Have we not all dreamt of the ultimate integration testing?

Have you ever achieved it in your company? I have worked in a couple companies and yet have to see it done the ultimate way.

Mostly it boils down to a combination of one, if not all, of these problems

  • not enough resources (invalid manager or lazy peon argument)
  • to many stakeholders and all use the same environment(s)
  • data is constantly changing, data is polluted
  • silo’s
  • unstable releases of dependencies wrecking tests
  • no automation what soever
  • no integration testing whatsoever (no kidding, it happens)
  • no build server ( huh what? you still build on your local machine??)
  • a backward ops team reluctant to do cool stuff

you can probably find some more reasons! feel free to let me know.

So let’s create a situation. Let’s say you have a simple infrastructure:

  • database servers
  • micro services ( API’s)
  • front end applications

All of them being built by different teams.

  • Team DB does databases,
  • Team MS builds the java backend services
  • Team FE does some nodejs fronted magic

Let’s also assume you have at least 3 different environments: development, test and production. Each of them a version of all applications on it.

Suppose that you have at least the problem of data consistency and unstable test wrecking dependencies. Then your current scenario could be something like:

  1. Team DB updates a database schema Z to version 2, tries it out on development. “Yay it’s works! Our update scripts are mighty cool! Let’s rollout to test.
  2. Team MS, sitting close by, quickly noticing the failing build on the CI Server. “Ho Ho Ho! Wait let us update our service Y that uses your update DB X.“. Update done, deploy to development. Runs some tests to verify that implementations correctly use the new database with it’s new functionalities . “Yay it works! Rollout to test!” Run the integration suite all seems fine!
  3. BOOM, front end was just giving a demo to stake holders on the test environment. An angry product owner with on it’s tail 15 nodejs developer storms in the back end room shouting all over the open space. “WTF #$FJIEAÏOXCBVEEEE$HIT# what where you thinking releasing that to test! We search a street name in your service and we get only cities back!  And the search name we initially use in our demo isn’t there anymore!!  You broke our whole front end! Fubar our demo! AGAIN !”
    Frustration, depression, the downfall of the team spirits, the downfall of a company, IMPEDIMENTS.

Well now! WE ARE ALL SAVED from this!  Just call 1-800-DOCKERIZEwarning next up is simple theoretical docker porn 
Continue reading Have we not all dreamt of the ultimate integration testing?


Once in a while one find itself on a task where numerous WTF moments appear. You can imagine such a task?

Yes you can. It’s adding new features to legacy code/database or to a ‘WTF’ code base.

A ‘What the F***’ code base, a collection of lines of code that make you shout WTF more than is healthy. You can usually hardly call it a program. It’s a collection of blunders after blunders. Not testable due to lack of interesting unit tests, thus not refactorable (if that’s even a word) without adding a unit test.

And then comes the day. ‘Hi mister, we’d like feature X, Y, Z added to this application.’  You say, ‘ok’ and come back with a rough estimation after carefully reading the specifications. Architect and Programmers decide: ‘Should take about 4 weeks in optimal man days’, what the client then hears that it will take around 3 months. And so the waterfall started spoiling it’s liquid.

Continue reading ReFRACKtoring

Children’s wisdom

The first thing I noticed when exiting the train in Antwerp Central Station.
A police officer with a semi automatic machinegun.
The aftermath of the Charlie shooting in Paris.

Second thing: it doesn’t make me feel safer. On the contrary. I feel uncomfortable and don’t trust it.

In the evening when I tell my seven year old son what I saw, he replied: ‘No, it can’t be. Cops  do not carry machine guns’

Now that’s real wisdom.