Author Archive

groene software

September 9th, 2010 · Peter Paul Bakker · Column No comments

Vandaag zag ik op een pak De Ruijter witte vlokken een keurmerk voor duurzame cacao.

Het lijkt mij ook de hoogste tijd voor een keurmerk voor duurzame software. En dan denk ik niet zozeer aan dat software niet wordt geproduceerd door kindertjes in arme landen en dat de developers er een eerlijke prijs voor krijgen (misschien ook eens het onderzoeken waard), maar aan groene software.

In eerste instantie denk ik dan toch aan mij zelf en een beetje aan de natuur. Het begon met een hele handige applicatie van Parleys.com. Een van de eerste multi-media apps geschreven bovenop het Adobe air platform. Daarmee kan je presentaties van onder andere (toen) JavaPolis, het huidige Devoxx downloaden en offline bekijken.

Hartstikke handig om m’n technische Java kennis een beetje bij te spijkeren in het vliegtuig naar Londen om de jaarlijkse QCon conferentie te bezoeken.

Net op weg klap ik mijn laptop open en begin de eerste van vijf presentaties te bekijken. Al snel wordt de laptop te heet om op mijn ‘lap’ te zetten en de fans beginnen hard te blazen. Als ik de presentatie pauzeer om het aangeboden drankje en mini zakje nootjes te verorberen, blijft de laptop blazen. Na 20 minuten en 15 minuten presentaties kijken, die er erg fraai uitzien, meldt mijn batterij dat ‘ie zo goed als leeg is. Handig zo’n offline app!

(Ik weet niet hoe de huidige versie zich gedraagd, dat zou al een beter kunnen zijn).

Dit bracht mij op het idee van “groene software”. Software die geschreven is om zo zuinig mogelijk om te gaan met CPU cycles. Een grote plus voor mobieltjes en laptops. Maar grote data centers die tegenwoordig meer energie opslurpen dan een kleine stad kunnen er ook baad bij hebben.

Terug naar de programmerstijl van de jaren 80, waar elke bit en elke CPU cycle telde. Nu niet meer omdat de bits en cycles schaars zijn, maar om minder energie te gebruiken. Minder warmte. Minder koeling. En batterijen die langer mee gaan!

Apple heeft nu al zoiets ingebakken in het accepteer proces van de iphone/ipad applicaties (neem ik aan). Dat zou ook een reden zijn waarom energie en batterij verslindende flash apps worden geweerd.

Ik heb tegenwoordig een flashblock add-on in de firefox browser. Om batterijen te besparen op de laptop (en die irritante reclames zijn ook plots weg).

Mooi vond ik het toen ik de openingspagina van een open source text editor, notepad++, zag: “When using less CPU power, the PC can throttle down and reduce power consumption, resulting in a greener environment”. Die krijgt van mij een “groene software” keurmerk!

log files

September 9th, 2010 · Peter Paul Bakker · Software No comments

Focus on your users and stakeholders. Dat is voor mij een belangrijke regel bij software ontwikkeling. En dat zijn niet alleen de eindgebruikers, maar ook degenen die onderhoud doen en de afdeling operations.

Voor de laatste groep is monitoring en configuratie erg belangrijk en voor beide de is goede logging van belang. Goede logging helpt bovendien het ontwikkelteam bij het oplossen van bugs en operationele problemen. Toch zie ik vaak dat logging, monitoring en configuratie een ondergeschoven kindje is.

Voorbeelden zijn log files waarin zoveel onzinnige informatie wordt geschreven dat de belangrijke en zinvolle meldingen ondergesneeuwd raken.

In principe maakt het niet veel uit welk logging framework gebruikt wordt als de basis maar gezond is. Naar mijn idee voldoet goede logging aan onder meer de volgende regels:

  • in productie en acceptatie test omgevingen worden alleen de info, warnings, error en fatal categorieen geschreven in de log files
  • fine en debug levels worden alleen geactiveerd als er een probleem is
  • de log levels moeten dynamisch aan te passen zijn per software component in geval van problemen
  • op info niveau worden meldingen gegeven van de hoofd processen die starten en eindigen, inclusief voldoende context informatie
  • een “chain of actions” kunnen identificeren door een uniek id te loggen
  • errors en fatal levels alleen gebruiken bij echte errors, en alle context informatie meegeven die voorhanden is; stacktrace, user id, waarde van input velden of method parameters, regel nummers en column van de input op moment van falen, relevante configuratie settings
  • bij opstarten van componenten alle configuratie settings loggen

Als ik een software project uitvoer let ik bij systeem test en vooral bij acceptatie test op de log files. Kan je goed volgen wat er in grote lijnen gebeurt met de info logging? Staan er geen errors of fatals in die genegeerd worden? Staan er op info logging geen zaken die beter op fine of debug niveau thuis horen? Als er een error in de log staat, is dan direkt duidelijk wat er aan de hand is?

Als dit niet het geval is neem ik meteen aktie om het te verbeteren.

Wat ik merk is dat developers en operations veel meer vertrouwen krijgen in de software en dat problemen snel kunnen worden opgelost.

Neem de volgende twee voorbeelden van een log file snippet:

INFO connecting to remote system
INFO getting sales.xml file from system
INFO processing file
FATAL cannot read file contents: conversion error
[stacktrace]
INFO processing file

en vergelijk met de volgende versie:

INFO processId: 837468874 connecting with FTP to account@archive.backoffice.org:2121
INFO processId: 837468874 getting file 'outgoing/sales.20100909.xml'
INFO processId: 647837443 start parsing file 'sales.20100908.xml'
FATAL processId 647837443 cannot convert 'null' to integer. File: 'sales.20100908.xml' line: 2244 column: 156
[stacktrace]
INFO processId: 837468874 start parsing file 'sales.20100908.xml'

In de eerste stukje log is het niet duidelijk dat er eigenlijk twee threads lopen. De FATAL hoort niet bij de twee INFO log statements daarboven, zoals in het tweede voorbeeld wel duidelijk is door toevoeging van het processId.

Het zal de lezer duidelijk zijn wat de benodigde effort is om de bug op te lossen in het eerste geval en het tweede geval. En de winst in effort is niet alleen in productie te incasseren, maar ook op alle test omgevingen.

Voor software ontwikkelaars is het een een kwestie van even stilstaan bij het schrijven van logger.log(…) statements. Het kan veel tijd en kosten besparen.

Automatische testen

September 8th, 2010 · Peter Paul Bakker · Software No comments - Tags:

Om de kwaliteit van software te garanderen is een goede test van groot belang.

Testen kan behoorlijk wat tijd kosten, vooral als er vaak een nieuwe release gemaakt wordt. Bij iteratieve ontwikkelmethoden is dat bijvoorbeeld iedere maand. Handmatig regressie testen doen is een kostbare zaak.

De oplossing lijkt voor de hand te liggen: automatiseer de testen.

Toch zie ik vaak dat het ook een hele investering is om automatische testen op te zetten en belangrijker nog, om de testen up-to-date te houden. Een unit test is snel geschreven, maar het bijhouden van een grote set van unit tests kost discipline van de software ontwikkelaars. Een eerste vereiste is dat de tests continue blijven werken. Een automatisch bouw proces met monitoring is essentieel. Alle tests groen is goed, een rode test mag niet voorkomen en moet direct worden verbeterd.

Unit tests werken dan ook het best als ze heel lokale tests uitvoeren. Bijvoorbeeld het testen van validatie regels of andere “stateless” functies.

De meer complexe unit tests die gebruik maken van mock objecten voor “dependend objects” zijn al snel bewerkelijk en lijken ook meer op integratie tests.

Waar ik meer waarde in zie is een automatische integratie test. Daaronder versta ik testen die software van voor naar achter testen in een integratie omgeving. Denk dan aan een automatische build waarbij het resultaat ook automatisch gedeployed wordt naar een volledige test omgeving, inclusief applicatie server, queueing software, database en ldap servers.

Door de opbouw van de test omgeving volledig te scripten zorg je ervoor dat je altijd een up-to-date omgeving hebt met de juiste configuratie en settings. Denk aan scripts die de applicatie server inrichten met onder andere datasources en system properties, database setup scripts en initiële data. Door van de juiste settings parameters te maken kunnen dezelfde scripts bovendien gebruikt worden om de hele otap straat in te richten.

Dit lijkt veel werk, maar als deze opzet vanaf het begin van het project wordt gekozen, kan er ook veel tijd bespaard worden. Bijvoorbeeld doordat er minder handmatige configuratie fouten gemaakt worden.

De testen zelf worden geschreven op de user interface. Bij web applicaties kan dit met behulp van tools als selenium of een watir script. Deze tools zijn behoorlijk op ontwikkelaars gericht. Als testers of analisten test cases schrijven kan er gekozen worden voor bijvoorbeeld fitnesse.

Met deze scripts kunnen complete use cases worden uitgewerkt, zoals het aanmelden van nieuwe gebruikers, iets kopen op de website of het invullen en doorlopen van wizards.

Bij deze testen worden alle onderdelen en lagen van de software applicatie geraakt en getest, alsof er een echte gebruiker aan de gang is.

Uitdagingen blijven er, zoals het constateren dat er iets mis is gegaan (plotseling een error pagina in plaats van de volgende wizard pagina). Als het te testen systeem (of SUT: System Under Test) ook met andere systemen communiceerd kan daar gewerkt worden met stubs. Deze kunnen slim zijn en reageren met verschillende responses op bepaalde requests.

Vaak gaat de communicatie met andere systemen tegenwoordig via SOAP over http. Met soapui is dan redelijk eenvoudig een slimme stub of proxy te bouwen. Mijn ervaring is dat soapui stubs, als het er wat meer worden, lastig te onderhouden zijn. Met SOAP stubs in mule esb, met bijvoorbeeld groovy scripts voor de slimme stub, heb ik betere ervaring.

Automatisch testen blijft een hele uitdaging en een behoorlijke investering. Met de juiste tools en een pragmatische aanpak kan je een eind komen.

Expertise

September 8th, 2010 · Peter Paul Bakker · The Office No comments

Stokpop is gespecialiseerd in

  • Java Enterprise Edition
  • Performance Trouble Shooting
  • Software Integration

Peter Paul Bakker heeft veel ervaring in complexe enterprise omgevingen en is in te zetten als

  • Performance Consultant
  • Lead Developer
  • Technical Team Lead
  • Software Architect

Stuur een email naar info@stokpop.nl voor meer informatie.

nljug artikeltje

June 18th, 2010 · Peter Paul Bakker · The Office No comments - Tags:

Dit artikel over Stokpop verscheen in het blaadje van de nljug, ik meen in 2008. (en ja… kinderen houden ervan met pennen te krassen).

Stokpop in nljug magazine

Stokpop in nljug magazine

Een nieuwe StokBlog!

June 17th, 2010 · Peter Paul Bakker · The Office No comments

Dit is het nieuwe gezicht van de StokBlog, de blog van Stokpop Software Solutions.

Mix and Match CSV data with Ruby

December 2nd, 2008 · Peter Paul Bakker · Software No comments - Tags: , , , , ,
robabank

funny

Multiple times a year I have to submit my VAT or ‘BTW’ tax forms. As I have a small business to run, I use good old Excel to calculate the numbers for the last Quarter. Most of the input comes from the payment transactions of my online bank account.

I found myself copy-pasting all relevant transactions from the financial transactions overview screen in the browser to the appropriate excel columns. Very boring and repetitive work. Time consuming as well. Translating dates into the appropriate format, mixing the columns to get the expected order, …

To go with my philosophy to automate everything that is repetitive, I created the following solution that I know will save me time all upcoming VAT rounds.

There is an option to download all transaction data from my account to a comma separated values file, or CSV file. You can download transactions with a start and end date, which makes it easy to get a file with records for the last Quarter only.

Next, with a little Ruby script, extract all relevant rows and columns and put them in the right order.

Then copy-paste the resulting file to the area in my BTW excel sheet and … done.

For this I used the fastercsv library, which made parsing the file quite simple.

require 'rubygems'
require 'faster_csv'
require 'parsedate'

# parse a csv file from Rabobank online banking download
#
# copy-paste or import the resulting output into excel
#
# note: to install the gem for faster_csv, use 'gem install fastercsv' e.g. without underscore!
#
# This is input for the BTW excel file!
whole_file = File.open(ARGV[0]) 

FasterCSV.parse(whole_file) { |row|
  # "tb" seems code between own accounts: skip these
  # filter out the Debit records "D" or Credit records "C"
  if row[3] == "D" and not row[8] == "tb"
	# put together the description fields
    description = "#{row[6]} #{row[10]} #{row[11]} #{row[12]}".strip.gsub(/s+/, ' ').downcase
	# put date in expected format for excel
    date = ParseDate.parsedate("#{row[2]}")
    my_date = "#{date[2]}-#{date[1]}-#{date[0]}"
	# change comma into a dot for price field
    price = row[4].gsub('.', ',')
    puts "#{my_date}|#{description}|#{price}"
  end
}

Note that this is used with the download of the Rabobank (or “Rob-a-bank”, as pitched by Boom Chicago)

Earth as Art

December 2nd, 2008 · Peter Paul Bakker · uncategorized No comments - Tags: , , , ,

Delta Plan

Delta Plan

Some time ago I ran into beautiful Nasa satelite pictures on “Earth as Art“.

You can actually see the Chaos Theory in clouds.

And see tracks that I drove on in the Namib desert. This has been my desktop picture for some time now.

Enjoy!

Guidelines for Struts2 projects – part 1

May 14th, 2008 · Peter Paul Bakker · java, Software No comments - Tags: , , ,

Struts2 is a very flexible framework. And with so much flexibility, consistency may be at stake.

Lot’s of freedom brings rules to adhere to. As a team.

Here are some of the rules that I found after some team meetings on how to work with Struts2. As the application architect, some guidelines needed to be put on paper.

Rule: do not use interceptors for business related code and logic; interceptors are the Framework

It is very tempting to create lots of interceptors that will gather all kinds of almost always needed data. For instance to always pull the main object for you application from the database and insert it into the current Action. This results in Actions being dependent on a certain interceptor stack, otherwise it is missing business information. This information can be very specific to (one part of) the application. And if more interceptors are needed to process business information, your action cannot considered to be one coherent component.

So consider Interceptors being the Web Framework. In Struts 1 you would know the exact sequence of calls to the Forms and Actions ( validate, execute, …). In Struts2 this sequence can be tweaked by simply changing the interceptor stack. All developers should have a clear view on what the framework is, and not be dependent on specific interceptor stacks to have their Actions work correctly.

Not following this rule will make

  • Action code harder to read and understand, because there are hidden dependencies
  • testing more difficult, because you need the interceptor stack for testing your Action
  • struts2 configuration more complex, because you will probably end up with many different interceptor stacks

    • Think of it this way: interceptors should only deal with infrastructural concerns, such as logging, calling lifecycle methods on the Actions, transforming values from web pages to actions, security, and others. So if you write an interceptor, check if the interceptor can also be used in other applications, and have no dependencies on the business model of the application you are working on.

    Also watch for having too many parameters on interceptors. Sometimes business logic can creep into an interceptor this way. You will notice that for some actions you will need to set a param of the interceptor to false to exclude some logic from running in that particular interceptor stack. Maybe you are better of to include the logic explicitly in the Action, or in some component that the Action can delegate to. This will make the logic in your Action explicit and better to understand.

    More guidelines will follow…

    What is this [Z?

    May 3rd, 2008 · Peter Paul Bakker · Software No comments - Tags:

    Braille ZIn a dump from a Java Virtual Machine, just before an out of memory, there was a list of numbers of instances of objects in the JVM. So there was a table with a ‘number of instances’ column and a ‘type’ column.

    One of the types was [I, so probably arrays of integers, but what are the [Z's?

    Here is a little program to find out:

    public class DumpClassType {

    public static void main(String[] args) {
        System.out.println(“String[0][0][0]: ” + new String[0][0][0].toString());
        System.out.println(“short[0]       : ” + new short[0].toString());
        System.out.println(“double[0]      : ” + new double[0].toString());
        System.out.println(“long[0]        : ” + new long[0].toString());
        System.out.println(“char[0]        : ” + new char[0].toString());
        System.out.println(“int[0]         : ” + new int[0].toString());
        System.out.println(“boolean[0]     : ” + new boolean[0].toString());
        System.out.println(“byte[0]        : ” + new byte[0].toString());
        System.out.println(“float[0]       : ” + new float[0].toString());
    }

}

    And the output:

    String[0][0][0]: [[[Ljava.lang.String;@3b2a3b2a
short[0]       : [S@3c183c18
double[0]      : [D@3c8c3c8c
long[0]        : [J@3d003d00
char[0]        : [C@3d743d74
int[0]         : [I@3de83de8
boolean[0]     : [Z@3e5c3e5c
byte[0]        : [B@3f443f44
float[0]       : [F@3faa3faa

    So, obviously, an array of booleans!