Inspiring people. Excellent results.

NDC London is een uitvloeisel van de Norwegian Developer Conference in Oslo. De conferentie was zo succesvol dat ze tegenwoordig ook in Londen, Sydney en Massachusetts worden gehouden.

Waarom ze zo succesvol zijn? Een combinatie van dingen denk ik: de locatie, de sprekers, de organisatie, de sfeer en het eten.

TL;DR

Conferenties zijn de allerbeste besteding van je tijd en je geld als je geïnspireerd wilt worden om je dagelijkse werk met een frisse blik te bekijken. De NDC conferenties staan bij mij daarbij op nummer 1!

Eten

Om maar bij het laatste te beginnen: na de eerste sessie staan er diverse stands met warm eten; Indiaas, Thais, Engels, Italiaans. Elke dag anders en elke dag lekker. En voor iemand zoals ik met een gluten-allergie erg prettig om veel keuze te hebben. En misschien wel het allerbelangrijkste: er is een echte barista die perfecte espresso’s en cappuccino’s maakt.

Grote namen

Onder de sprekers waren dit jaar absolute toppers zoals Scott Hanselman, Scott Guthrie, Rob Conery, Jon Skeet (de man met een miljoen punten op StackOverflow) en de mannen van .NET Rocks. Maar daarnaast ook wat mindere goden met verhalen van hoge kwaliteit, zoals van onze eigen Delftse professor Felienne die de opening Keynote mocht doen.

Verrassingen

Er waren behoorlijk wat verhalen die niet persé over de nieuwste technologische snufjes gingen, maar over meer alledaagse dingen waar je als software maker mee te maken krijgt. Kevlin Henney vertelde bijvoorbeeld over  “Refactoring to Immutability”, Troy Hunt over security (You’ve been pwned), Rob Conery over zelfstandig worden en Scott Hanselman over het leven met diabetes-1.

Eén van onze favoriete verhalen was over Cake. Dat is een C# Make taaltje dat je kunt gebruiken ter vervanging van al je batch scripts en Powershell of al je aanklik-taken in Visual Studio Online. Het is verrassend aangenaam om je favoriete programmeertaal te zien in de context van een build script. Het wordt direct duidelijk wat er gebeurt:

var target = Argument("target", "Default");
var configuration = Argument("configuration", "Release");

// Define directories.
var buildDir = Directory("./src/Example/bin") + Directory(configuration);

Task("Clean")
    .Does(() =>
{
    CleanDirectory(buildDir);
});

Task("Restore-NuGet-Packages")
    .IsDependentOn("Clean")
    .Does(() =>
{
    NuGetRestore("./src/Example.sln");
});

Task("Build")
    .IsDependentOn("Restore-NuGet-Packages")
    .Does(() =>
{
   // Use MSBuild
   MSBuild("./src/Example.sln", settings =>
        settings.SetConfiguration(configuration));
});

Natuurlijk uitbreidbaar met je eigen C# code en ook beschikbaar als Task in Visual Studio Online; dat betekent dat je hele CI opzet uit één taak bestaat met daarin een Cake script dat zich weer prettig laat versioneren in je favoriete source control system (Git uiteraard…).

Sfeer

De sfeer bij de NDC conferenties is geweldig. De sprekers bijvoorbeeld zijn zeer toegankelijk; ik heb geprobeerd met al mijn helden even te babbelen en dat kan heel makkelijk.

NDC heeft ook strikte gedragsregels. Op andere tech conferenties hebben vrouwen regelmatig last gehad van “Brogrammer” gedrag; bij NDC wordt je dan direct op straat geschopt. In de lezingen mogen geen vrouwonvriendelijke grappen gemaakt worden en er is hard gewerkt om de aantallen vrouwelijke sprekers en vrouwelijke bezoekers omhoog te krijgen. Het komt ons vrijgevochten Nederlanders misschien wat zwaar over, maar de sfeer is mijns inziens daardoor echt relaxed.

Conclusie

Dit soort conferenties zijn zeer inspirerend. Het is zo belangrijk om af en toe even een paar dagen uit de sleur te stappen en je helemaal te laten verfrissen door het enthousiasme van de mensen wiens boeken je leest en wiens videos je kijkt op Pluralsight.

In juni is er weer een NDC Oslo. Gaan!

Ons standmateriaal op de beurs van Connect.frl bestond uit een volledig elektrische auto met een laadpaal.

Waarom? Omdat wij een rol vervullen in het softwareproces om alle betrokken partijen (stroomleverancier, laadppaalbeheerder, laadpasleverancier) real-time met elkaar te laten communiceren.

Tijdens de beurs kon je een dag in een volledig elektrische auto rijden winnen. En de winnaar is Willem!

Gefeliciteerd Willem, en we weten inmiddels dat je een leuke dag hebt gehad.

Richard de Zwart, 31-12-2017

Okay, de titel is een beetje click-bait. Strings zijn niet de oorzaak van ALLE kwaad in software; we hebben immers ook nog “Magic Numbers”, “Code Duplication”, “Premature Optimization” en geld (volgens de Bijbel, 1 Timoteüs 6). Maar we gebruiken strings wel te vaak op plekken waar we beter iets anders kunnen gebruiken.

Strings zijn lekker makkelijk, er mag immers van alles in. Het maakt niet uit of je een string hebt met het sprookje van Roodkapje, een bedrag, een datum, een postcode of een BSN.

Het probleem is dan alleen dat die dingen die voor het menselijk oog herkenbaar zijn en betekenis hebben, meteen betekenisloos worden. Een compiler kent niet het verschil tussen een string met een datum en een string met een postcode. En die compiler is nou net onze vriend als het gaat om het voorkomen van bugs: hoe beter de compiler weet wat voor informatie we -bijvoorbeeld als een parameter- doorgeven hoe beter hij kan helpen voorkomen dat we het verkeerde doorgeven.

Stringly typed code

Er is een term die opgetekend werd door Jeff Atwood op zijn blog Coding Horror: stringly typed code:

A riff on strongly typed. Used to describe an implementation that needlessly relies on strings when programmer & refactor friendly options are available.

• . parse it and create an enum, then you have strong typing throughout the rest of your codebase).
• Message passing without using typed messages etc.

Excessively stringly typed code is usually a pain to understand and detonates at runtime with errors that the compiler would normally find.

De laatste zin is voor mij waar het om gaat: code die veel strings gebruikt is moeilijk te begrijpen en faalt pas tijdens het runnen. Is dat zo? Dat het moeilijk te lezen is? var person = FindPerson("Jan", "Janssen"); is vrij duidelijk. De parameters zijn een voornaam en een achternaam. En normaliter zou je variabelen doorgeven  en als je die meer beschrijvende  namen geeft dan p1 en p2 dan is het nog duidelijker wat de functie verwacht.

Enums

Wat is dan code die beter zou kunnen? Allerlei typeringen zoals “Eenrichtingverkeer” (typefout met opzet) voor een straat of “Granen” voor een stuk uit de schijf van vijf. Die typeringen kun je altijd modeleren als een  enum. En dan is de compiler weer in staat om voor je te controleren of je wel een geldige waarde gebruikt. Maar dit soort informatie komt vaak als string je systeem binnen; soms als een keuze van een dropdown op een scherm, soms als een waarde uit een database of uit een API van een derde partij.

Die moet je dus op de plek waar ze binnen komen omzetten naar een enum zodat de rest van je code getypeerd kan zijn.

Helaas hebben Enums wat nare eigenschappen. De belangrijkste is dat het eigenlijk een  int is  (well actually: het kan ook een long of een byte zijn…). Het ziet eruit als een leesbare tekst, maar het is een getal. Dat was 400 jaar geleden toen computers nog op stoom liepen misschien heel slim en efficient, maar ik zou best blij zijn geweest met een implementatie die meer op die van Java lijkt. Je moet dus her en der dat getal omzetten naar een tekst. En daarmee komen we op de tweede nare eigenschap van  enum in C#: de ondersteuning voor die omzetting  is niet geweldig. We hebben allemaal te vaak dit soort code geschreven:

var rijrichting = (Rijrichting) Enum.Parse(typeof(Rijrichting), "Eenrichtingsverkeer", true);

In .NET Core is het gelukkig zoals je het zou willen:

var rijrichting = Enum.Parse<Rijrichting>("Eenrichtingsverkeer");

Datum velden

Datum velden hebben natuurlijk al problemen genoeg van zichzelf. De omzetting van de ene tijdzone naar de andere, het feit dat een DateTime in C# altijd een tijd heeft ook als je alleen maar een datum nodig hebt, maar vooral natuurlijk het parsen van verschillende formaten. Is “1-12-2017” nou 1 december of 12 januari?

Ook hier geldt natuurlijk dat je de string zo snel mogelijk omzet naar een DateTime voordat je de informatie verder je applicatie in stuurt. Maar datum velden hebben altijd ook nog een andere betekenis dan alleen maar een punt in de tijd. Het kan een geboortedatum zijn, of een ShipBeforeDate of een combinatie van twee datums die samen een periode vormen. Daar zit altijd bepaalde business-logica aan vast. Een ShipBefore datum mag misschien nooit meer dan 14 dagen na een OrderPaidAt datum liggen. Die business-logica hoort vaak bij de datum en verdient een eigen class. Maar dat is eigenlijk een heel ander verhaal dat valt onder de Primitive Obsession code smell.

Postcodes

Eerlijk gezegd heb ik nog nooit een Postcode class gezien in een systeem. Niet zo heel raar omdat je deze meestal alleen maar via een formulier van een gebruiker door krijgt, opslaat in je database en misschien weer eens ophaalt om een brief (zo’n papieren ding met een envelop eromheen en een postzegel erop) te kunnen samenstellen. Maar als je ook maar enige validatie op een postcode doet is het al voor de hand liggend om een Postcode class te maken. En NIET een PostcodeValidator class… Je maakt het je leven in eerste instantie niet makkelijker, omdat je dan ook moet nadenken over postcodes in andere landen. Met een string-veld kun je alle varianten aan van over de hele wereld. Tja, heeft iemand je ooit beloofd dat progammeren makkelijk zou zijn?

EAN, IBAN, BSN, E-mail

Ik werk nu aan een project waar heel veel EANs worden gebruikt. Dat zijn getallen van 13 of 18 cijfers die bijvoorbeeld een elektriciteitsmeter in je meterkast identificeren. Deze worden als string in de applicatie verwerkt. De validatie zit in aparte validatie-helper classes. Je komt dat ook tegen met IBANs en BSNs: allemaal tekenreeksen die absoluut niet willekeurig zijn en smeken om in aparte classes te worden opgenomen. Het is geen tekst, het is een IBAN. Het is geen tekst, het is een e-mail adres.

Veel werk? Welnee, alleen verplaatsen van code die je toch al hebt. Je komt er dan ook achter hoe vaak je die code gedupliceerd hebt in je systemen. En het zijn ook van die zeldzame objecten in je systeem die je daadwerkelijk misschien nog wel over projecten heen kunt hergebruiken.

Samenvattend (TL;DR)

Als het werkelijk om een willekeurige reeks tekens gaat (zoals een sprookje of een achternaam) mag je een string gebruiken. In alle andere gevallen verdient het (en verdien jij als vakman) een echte class.

Kwaden

• Repetition is the root of all evil,
• Want de wortel van alle kwaad is geldzucht,
• Premature optimization is the root of all evil,
• What is a magic number, and why is it bad?.

Inspireren en zelf geïnspireerd worden door andere IT professionals? Het gebeurde allemaal op Connect.frl, 6 december 2017!

Connect.frl is een stichting die als doel heeft het aanwezige IT-talent in het noorden te inspireren en te behouden voor de regio. Middelen? Events, kennissessies, netwerkbijeenkomsten, traineeprogramma’s en nog veel meer.

Hoogtepunt elk jaar is het event in december. Thema 2017? Jezelf opladen met inspiratie.

Get There is niet alleen partner (ontmoet ons eind dit jaar weer op onze stand!), maar we hebben ook wat te vertellen: graag tot dan!

Goed bezochte sessie van Arnoud en Richard

Richard de Zwart, 1-11-2017

Er is natuurlijk al het nodige geschreven over het hoe en waarom van het Builder Pattern. Dus ik ga er vanuit dat je hier gekomen bent omdat je zeker weet dat je een Builder nodig hebt, en dat je zoekt naar een manier om het anders te doen.

De implementaties die ik tot zover vond (zoals die van Cameron McKay of Nat Pryce) volgen uiteraard altijd hetzelfde patroon: een builder class met een methode voor elk stukje van het object wat er gebouwd moet worden (aantal deuren, kleur, type brandstof). Die code ziet eruit als heel veel meer-van-hetzelfde, terwijl je juist een pattern zoekt om je code te vereenvoudigen. Je Director daarentegen is heel netjes. Stel dat je een Fluent Interface wilt (nee, niet het Fluent Design waar Microsoft het nu veel over heeft) dan ziet het er ongeveer als volgt uit:

Car car = new CarBuilder()
  .WithDoors(4)
  .WithColor("red")
  .WithABS(true)
  .Build();

(met dank aan Tobiask).
Maar stel nou dat ik het bakken van de objecten generiek en herbruikbaar zou kunnen maken, met een stuk configuratie dat de bakker vertelt wat ie moet maken?
Gelukkig had ik enige tijd geleden een briljante collega (@JelleHissink) die de code die ik zocht in 3 minuten uit zijn hoofd intikte. En vervolgens nog 5 minuten doorratelde over verbeteringen die ik totaal niet kon volgen…

Een generieke Builder

Code first.

public class Builder<T> where T : new()
{
  IList<Action<T>> actions = new List<Action<T>>();
  public T Build ()
  {
    var built = new T ();
    foreach (var action in actions)
    {
      action (built);
    }

    return built;
  }

  public Builder<T> With(Action<T> with)
  {
    actions.Add (with);
    return this;
  }
}

Ik zal eerst uitleggen hoe je ‘m gebruikt, dan hoe het werkt.
De eenvoudigste manier om een Builder te configureren is:

var pet = new Builder<Pet> ()
  .With (p => p.Name = "Dolly")
  .With (p => p.Age = 3)
  .With (p => p.Type = "Cat")
  .Build();

Waarbij de Pet class in het voorbeeld gewoon een class is met 3 publieke velden.
Wat win je daar nou mee? Nou, je hoeft niet een aparte Builder class te maken, dat scheelt. Je moet wel alle namen van de properties die je wilt zetten aangeven, en dat is nou eigenlijk wat we net niet wilden. Maar ik vind het wel beter leesbaar dan een rijtje constructor overloads; en je kunt zelf de volgorde bepalen, velden weglaten en het is duidelijk wat een parameter betekent.

Een voorbeeld van dat laatste. Als je defaults wilt gebruiken kun je het volgende doen:

public class DogBuilder : Builder<Pet>
{
  public DogBuilder ()
  {
    With(a => a.Type = "dog");
  }
}

Een eenvoudige afgeleide class waar je de defaults zet in de constructor. Je kunt dan bij het bakken van je hond zulke code gebruiken:

var dog = new DogBuilder()
  .With(d => d.Name = "Tarzan")
  .With(d => d.Age = 1)
  .Build ();

En omdat je een lambda gebruikt kun je de 2 aanroepen ook nog samenvoegen.

var dog = new DogBuilder()
  .With(d => { d.Name = "Tarzan"; d.Age = 1; })
  .Build ();

Hoe werkt het?

De Builder heeft een Build() methode die het gewenste type T teruggeeft. De methode is verantwoordelijk voor het feitelijke creëren van het object. In regel 6-10 gebeurt dat door het aanroepen van de default constructor, gevolgd door het doorlopen van alle Actions die je hebt gespecificeerd door de With() methode aan te roepen.

Dat is de essentie van het verhaal: je neemt als het ware de acties die je uitgevoerd wilt hebben op, en die worden afgespeeld zodra je Build() aanroept. Niet eerder dan dat je Build() aanroept krijg je echt een object.
Het is een beetje als een verlangslijstje maken: eerst schrijf je op wat je wilt en dan stuur je het naar de Sint om te zorgen dat je het ook allemaal daadwerkelijk krijgt.

Nadelen

Je hebt een default constructor nodig en publieke velden of properties. Dat zou in een Domain Driven Design natuurlijk uit den boze zijn. In DDD vaak een private constructor gemaakt en een static Create() functie. Dat heeft wel iets van een Builder behalve dat je weer een functie krijgt met soms een enorme bak aan parameters.

Voordelen

Separation of concerns. Het mooie van deze oplossing is dat hoe je een object bouwt de verantwoordelijkheid is van de Builder; en dat wat je bouwt de verantwoordelijkheid is van de Director of de afgeleide class. Of zoals Zoran Horvat het zou zeggen: de infrastructuur is losgetrokken van de business logica.

Op dit moment ben ik Builders aan gebruiken om test data te genereren voor een integratie test. Ik bouw een entiteit op met zijn/haar sub-entiteiten en voeg in dat proces van alles toe aan een Entity Framework context. Pas als de Build() wordt aangeroepen doe ik een context.SaveChanges(). Daarmee functioneert mijn Builder in feite als een Unit of Work.

Al weer de 31ste editie van De 4 Mijl van Groningen. Ook dit jaar deed Get There mee met een team sportieve collega’s. Allen zetten ook nog een goede tijd neer. We feliciteren onze collega’s voor de sportieve prestatie en we bedanken onze collega Bert voor de trainingen.

Volgend jaar zijn we weer van de partij! Doe jij dan ook mee?

Scrum is een Agile Software Development Framework om productontwikkeling (dagelijks) te bewaken. Door middel van stand ups met alle betrokkenen worden (details van) de vooraf gedefinieerde ‘brokken’ werk besproken en eventueel aangepast. Dit flexibele proces houdt daarbij rekening met nieuwe inzichten; zo kunnen klanten tijdens het proces tot het inzicht komen dat hun wensen veranderd zijn en teamleden kunnen hun oplossingen voor de meest efficiënte werkwijze inbrengen. Dagelijkse afstemming hierover verbetert het proces om tot optimale klanttevredenheid te komen. En daar doen we het voor.

We bedanken opleidingsinstituut StarTel voor de professionele training.

slim laden: gas- en kolencentrales overbodig maken en tegelijkertijd geld verdienen

Energieleverancier Vandebron presenteerde de volgende stap in haar ambitie de energietransitie te versnellen: slim laden.

In oktober is een pilot van start gegaan met een selectie van Vandebron klanten die ten doel heeft om schommelingen in het energienet beter op te vangen. Door slim gebruik te maken van de batterijcapaciteit van auto’s veranderen elektrische rijders in duurzame stroomhandelaren. Van der Galiën: “Simpel gezegd stoppen wij met het laden van de honderden auto’s als er meer vraag dan aanbod is naar energie en starten we juist als het tegenovergestelde het geval is”.

Klanten doen ook hun voordeel met deelname: naar schatting verdient een gemiddelde leaserijder €250,— op jaarbasis, zonder in te leveren op comfort. Klanten geven zelf hun laadvoorkeuren aan zodat zij nooit zonder een lege batterij komen te staan.

De rol van Get There

Samen met ECEDO heeft Get There de implementatie gedaan van het OCPI protocol dat nodig is om de Vandebron laadpassen met de laadpalen te laten communiceren.

Wij feliciteren Vandebron met de geslaagde kick off.

Vanaf 1 oktober 2017 heeft het Centraal Justitieel Incassobureau (CJIB), een uitvoeringsorganisatie van het ministerie van Veiligheid en Justitie, een nieuwe raamovereenkomst voor het tijdelijk inhuren van ICT-professionals. Get There is er trots op dat zij één van de geselecteerde partijen is, samen met Seven Stars Noord (Penvoerder) en Brunel. In totaal zijn zes partijen geselecteerd.

Ook de mantel voor detavast-constructies van ICT-professionals heeft Get There icm Seven Stars en Brunel gegund gekregen. Bij een detavast-constructie is het de bedoeling dat de ICT’er na een opleidings- en trainingsperiode bij goed functioneren instroomt in een functie bij CJIB.

Het mantelcontract vertegenwoordigd een verwachte inhuurwaarde van EUR 32.000.000 met een doorlooptijd van 4 jaar.

Natuurlijk is Get There, als sponsor en Microsoft Gold partner, aanwezig. Onze collega’s Pieter Leijenaar en Richard de Zwart verzorgen twee presentaties: ‘Angular frontend zonder backend’ en ‘Azure functions’. De sessies zijn praktisch van aard, met aandacht voor het laatste nieuws van Microsoft en het schrijven van code.
Ben jij er ook bij?