Inspiring people. Excellent results.

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?

Richard de Zwart, 26-07-2017

Ik ben echt dol op Test Driven Development. Sterker nog, ik kan me geen (werkend) leven voorstellen zonder unit testen. Als ik geen test suite heb die me vertrouwen geeft, hoe kan ik dan ooit mijn code refactoren om de onderhoudbaarheid te verhogen –en ondertussen zeker weten dat ik niks kapot maak?

TL;DR

Het werkt. Als je de juiste packages installeert en wegblijft van .NET Core of het nieuwe CSPROJ formaat.
Update VS2017 15.3 en 15.4: het werkt nog beter! Er is nu ook ondersteuning voor .NET Core.

Vroeger

Helaas heeft Visual Studio nooit echt goede ondersteuning geboden voor unit testen, laat staan voor TDD. Om een beetje fatsoenlijk TDD te kunnen doen heb je een test-runner nodig die snel en bij voorkeur continue draait. Om dat te kunnen doen in Visual Studio gebruik ik al jaren NCrunch. Het is een plugin die voortdurend je code compileert en je testen draait. Daarnaast geeft het je per regel informatie over de coverage van je code: is er uberhaupt coverage? Gecovered door een falende test? Gecovered door een geslaagde test?

Tijdens het debuggen wordt daar nog eens timing aan toegevoegd voor elke regel. Het is een heel plezierige ervaring. Terwijl je je test schrijft begint Ncrunch te compileren en zodra je code compileert heb je een falende test. Rode fase compleet, door naar de groene fase! En terwijl je je implementatie schrijft zie je direct een groene bal verschijnen zodra je genoeg code hebt geschreven om de test te laten slagen. Door naar de refactor fase! Uncle Bob zal trots op je zijn…

Wat biedt Visual Studio 2015 je?

Toegegeven, je kunt unit testen draaien. Je kunt zelfs niet-Microsoft frameworks zoals NUnit en xUnit gebruiken als je de juiste adapters installeert. Maar het resultaat is niet veel meer dan dit:

Een lijst van geslaagde en falende testen. Geen zinvolle manier om je testen te organiseren, zoals met een tree-view die je op het nivo van classes of assemblies laat open- en dichtklappen.

En elke keer dat je je testen wilt draaien moet je wachten op een volledige build, zelfs als je net nog gebuild en gerund hebt. Dat verhoogt de drempel om je testen te draaien zodanig dat je ze steeds minder gaat draaien. En als je je testen niet meer draait dan verliezen ze alle waarde als vangnet.

Als je Resharper gebruikt (en dat moet je sowieso doen), dan ben je iets beter af. Het lijkt alsof je testen eerder starten en sneller draaien. Maar je moet er nog steeds aan denken om ze te starten. En nee, “run after each build” is geen alternatief, omdat het build process dat volgt je hele Visual Studio blokkeert.

VS2017 to the rescue!

VS2017 heeft iets dat Microsoft “Live Unit Testing” noemt. Het is in essentie hetzelfde als wat Ncrunch doet: build en run terwijl je je code schrijft. En het voegt ook tekentjes toe aan elke regel code om te laten zien of deze gecovered/geslaagd/gefaald is.

Als je op zo’n X of V klikt dan krijg je een overzicht welke testen voor coverage van deze regel code zorgen.

Hoe te beginnen?

Nou, om te beginnen heb je Visual Studio 2017 Enterprise Edition nodig. Ik hoop echt dat Live Unit Testing uiteindelijk ook beschikbaar komt voor de Community Edition van VS2017. Het is zo belangrijk dat de drempel voor TDD zo laag mogelijk is. Microsoft zou daar een mooie bijdrage aan kunnen leveren door Live Unit Testing voor iedereen beschikbaar te maken.

Vervolgens ga je in het menu naar Test > Live Unit Testing > Start.

And then (zoals in het Heineken spotje), we wait. Hoe weet je of het werkt? Nou, het kan even duren voordat je dat doorhebt. Je moet het Output Window open hebben:

En zoals je kunt zien, gaat het in mijn geval fout. Daarover straks meer…

Bij grotere projecten kan het even duren voordat de streepjes, vinkjes en kruisjes (sympatieke keuze voor kleurenblinde programmeurs) tevoorschijn komen. Eigenlijk komen de streepjes (geen dekking) vrij snel, ook bij code waarvoor wel dekking is. Uiteindelijk veranderen ze wel in kruisjes en vinkjes; een beetje verwarrend in het begin, maar je went er wel aan.

Uiteindelijk wordt het Test Explorer Window ook bijgewerkt.

Nog steeds dezelfde view, maar gelukkig is in VS2017 15.2 dit window in sync met je Live Unit Testen. Daarvoor waren het twee volkomen naast elkaar levende systemen.

“No test adapters are referenced by this solution”

Als je begint met “Add new project”, “Unit Test” enzovoorts –zoals je in de meeste voorbeelden ziet- werkt alles natuurlijk meteen, right out of the box. Maar als je al een class library met testen hebt, misschien met Nunit testen, en je wilt profiteren van Live Unit Testen dan krijg je bovenstaande foutmelding om je oren.

Je moet de juiste adapters installeren, zelfs voor MsTest gebaseerde testen. Dat is ok, het hoort bij het moderne Microsoft dat zegt: „Je moet zelf weten wat je wilt gebruiken, het is jouw keuze“.

Als je testen hebt met MsTest moet je er wel even aan denken de referentie naar de oude Microsoft.VisualStudio.QualityTools.UnitTestFramework weg te halen.

MsTest: https://www.nuget.org/packages/MSTest.TestFramework/1.1.18 en https://www.nuget.org/packages/MSTest.TestAdapter/1.1.18
NUnit: https://www.nuget.org/packages/NUnit3TestAdapter
xUnit: https://www.nuget.org/packages/xunit/2.2.0 en https://www.nuget.org/packages/xunit.runner.visualstudio/2.3.0-beta3-build3705

Zodra je de adapter van je keuze hebt geinstalleerd beginnen de blauwe streepjes tevoorschijn te komen en (afhankelijk van je code-coverage natuurlijk…) te veranderen in rode kruisjes en groene vinkjes. Nu kun je de Red-Green-Refactor cyclus in met onmiddellijke feedback!

Ik gebruik.NET Core!

Ja, uiteraard. Ik ook. Maar helaas Visual Studio vertelt je dat .NET Core nog niet ondersteund wordt in versie 15.2. De belofte is dat het in VS2017 15.3 komt, dus hopelijk komt die heel snel.Tot die tijd, als je geen bezwaar hebt om de command-line te gebruiken, kun je een referentie opnemen naar de DotNet Watcher Tools  die bij elke file wijziging “dotnet test” voor je draait.

Update 22-10-2017: Inmiddels zijn zowel 15.3 en 15.4 beschikbaar. Daar is de ondersteuning voor .NET Core helemaal in orde. Het is zelfs zo dat versie 15.4 bij het openen van een Solution iets roept van “Er zijn unit-testen aanwezig, wil je Live Unit Testen proberen?”.

En ik hou van de nieuwe project file structuur!

O, zeker! Heb je al gezien hoe je CSPROJ opgeruimd kan worden als je een paar simpele stappen volgt zoals Nate McMaster laat zien? Het werkt met je gewone .NET Full projecten! Je kunt de packages.config weggooien en je krijgt spontaan edit support in je Solution Explorer zonder dat je het project eerst hoeft te unload-en. Het nieuwe formaat is zoveel schoner en duidelijker.

MAAR. Live Unit Test kan nog niet overweg met het nieuwe formaat. Het besluit dat het “.NET Core” is en niet gebruikt kan worden. Nu maar hopen dat het in VS2017 15.3 wel gaat werken…

Dindag 13 juni 2017  zijn we aanwezig door middel van een technisch-inhoudelijke postersessie op de Data Science Dag Noord-Nederland bij de Gasunie. Daarnaast verzorgen Get There collega’s Wilco Oelen en Martijn Bodewes namens Get There een korte projectpresentatie over het thema Big Data.

Data Science is voor veel Noordelijke organisaties een bekend onderwerp, de mogelijkheden van data science worden door die bedrijven al op verschillende manieren in de praktijk gebracht. Samenwerking Noord wil al die prachtige initiatieven een podium geven op dit informatieve en aantrekkelijke event over Big Data. Het onderwerp wordt dan ook uit vanuit meerdere perspectieven belicht: vanuit het management én vanuit de data scientist. Want Big Data: wat brengt het ons nu eigenlijk en waar zit de meerwaarde?

Donderdag 1 juni gaven we een lezing over Internet of Things op de Hanze Hogeschool – voor meer dan 250 enthousiaste HBO ICT studenten. Onze collega Jasper de Jong (full stack developer) verzorgde de presentatie, waar hij met maar liefst 4 usecases liet zien hoe makkelijk het is om zelf IoT applicaties te bouwen:

–          Koelkast inventorisatie systeem voor thuis – dat slechts 66 euro kost!

–          Energy data hub, onze dashboard om energie en gas meetwaardes van een huishouden bij te houden.

–          TimeBoard, een OV dashboard van 50 euro voor op de deur, om de laatste OV reistijden bij te houden.

–          Zes biometrische IoT producten om je gezondheid op pijl te houden.

Tot slot, demonstreerde Jasper waarom de HoloLens & Mixed reality the toekomst is van IoT. De Hololens maakt het namelijk mogelijk om in de échte wereld visueel met je IoT applicaties te interacteren.

Samen met: RDW (zelfrijdende auto’s), Jos Bredek (ÎPv6) en natuurlijk SV Realtime!