Geschiedenis

History

In de jaren 80 als kind begonnen met BASIC en 6502 assembler op de VIC20 en later de C64. Tijdens mijn middelbare school in 1985 meegedaan aan Micro Masters Holland met het C64 spel KOKO. Wat voor mij destijds best wel gaaf was.

As a kid in the 80's I started with BASIC and 6502 assembler on the VIC-20 and later the C64. During my highschool period in 1985 I joined the national Micro Master Holland contest with the C64 game KOKO. For me that was pretty cool at the time.

In de jaren 90 na een studie elektronica mijn software loopbaan gestart met Informix database applicaties te integreren met externe apparaten en systemen vanuit Unix systemen in C. Dit groeide daarna langzaam uit naar standalone machine besturingen in C++ waar communicatie protocollen, PLC's, machine Vision en performance de boventoon voerden.

During the 90's after my studie electronics my software career started of with integrating Informix databases against external devices and systems in C. Later this evolved to standalone machine control systems in C++ where communication protocols, PLC, machine Vision and performance were leading.

In de 00's via de detachering bij de grote jongens (o.a. Philips, ASML) terecht gekomen waar procedures, formaliteiten, tooling en grotere architecturen een zeer interessant gebied waren.

In the 00's I became a contracter and worked for the big companies (a.o. Philips, ASML) where procedures, formalities, tooling and bigger architectures were very interessting areas.

In de 10's zijn managed talen C# en Java toegevoegd aan mijn arsenaal en deze ingezet voor schaalbare metadata management systemen. Deze combinatie stelt mij in staat om systemen te ontwikkelen waar zowel de executie snelheid van C++ als de productiviteit van C#/Java tot hun recht komen.

In the 10's I added managed languages C# and Java to my skills and applied these in scalable metadata management systems. This combo allowed me to develop systems where both execution speed of C++ and the productivity of C#/Java are used to their fullest.

De laatste periode wordt voornamelijk gebruikt om concepten uit tewerken met reeds opgebouwde kennis. Het totaal plaatje van architectuur tot aan implementatie vind ik momenteel het interessants om te doen.

The last period I used mainly to develop concepts using active knowledge. The total picture from architecture to implementation is what I find most interesting to do.

Als hobby is electronica altijd wel op de achtergrond aanwezig geweest. Vroeger analoge elektronica, daarna microcontrollers en de laatste jaren is het meer integratie en totaal PCB oplossingen met FPGA's en integratie hapklare externe modules.
Daarnaast vind ik met hout werken een plezierige bezigheid, 10Km rennen, en 3D printen. Oh en ik probeer sinds mijn jeugd al een grote(re) modeltreinbaan te maken, maar dat zal waarschijnlijk tot mijn pensioen moeten wachten...

As a hobby, electronics has always been there in the background. In the early days analog electronics, after that microcontroller and in recent years total PCB development using FPGA's and integration with external ready-to-use modules.
Besides that i like to work with wood, run the 10KM and do 3D printing. Oh, and since my childhood I have been trying to create a larger modeltrain, but that will likely have to wait till retirement...

Opleidingen, cursussen etc.

Education, courses etc.

Het software ontwikkel process

The software development process

Door de jaren heen heb ik veel software projecten in alle fasen meegemaakt. Daar heb ik enorm veel ervaring mee opgedaan welke ik toepas in het oplossen van software vraagstukken. Veel dingen die ik aan den lijve ondervonden heb zijn wellicht open deuren. Desalnietemin zal ik toch een poging doen te vertellen hoe ik over een aantal zaken denk.

Over the years I have worked on many software projects in all phases which gained me a lot of experience. I apply that experience in solving software problems. Many things I have personally experienced first hand may be open doors. Nontheless I will make an attempt in telling how I think about certain things.

Architectuur / Design

Architecture / Design

Architectuur is het plaatje dat overblijft als je van een afstand naar een systeem kijkt. Bepalend hierin is dan ook de afstand vanaf waar je naar de architectuur kijkt. 'One man's design are another man's requirements'. Afhankelijk van je rol of het moment in het ontwerp process, neem je wat meer afstand of juist zoom je meer in op specifieke onderdelen. Bij een groot systeem zal de architectuur een aantal functionele blokken laten zien. Design teams zullen individueel deze blokken oppakken en hierom wederom een architectuur voor bedenken. Bij de grotere bedrijven en complexere producten is architect/designer vaak een voltijd functie. Bij kleinere bedrijven neemt de lead-developer de rol van architect/designer er vaak bij. In bedrijven waar Agile development is doorgevoerd, zie ik architectuur ook wel als een team aangelegenheid.

Architecture is the picture that remains when you look at the system from a distance. Decisive in this is the distance from which you look at the architecture. 'One man's design are another man's requirements'. Depending on your role or the moment in the design process, you step back or zoom in on specific parts. On bigger systems the architecture will reveal a number of functional blocks. Design teams may individually take these blocks and again design an architecture for it. With bigger companies and more complex products, architect/designer is a fulltime job. In smaller companies, the lead developer usually takes up the architect/designer role as part of its own job. In companies where Agile development has been introduced, I sometimes see architecture as a team effort.

Doel van de hele architectuur/design excercitie is enerzijds om complexere problemen steeds verder op te splitsen tot realiseerbare brokken. En anderzijds om repeterende patronen te herkennen en deze mogelijk te benutten. In deze fase kunnen in enig stadium al subsystemen ontstaan welke off-the-shelf beschikbaar zijn. Bijvoorbeeld door een product in te kopen of door opensource software te gebruiken. Kies je in een vroeg stadium al voor een bepaalde technology dan kan deze constraint wellicht betere alternatieven in het verdere design uitsluiten. Soms zijn er op voorhand al constraints b.v. vanwege legacy, omdat klanten of de industrie een technology afdwingen, of vanwege in het bedrijf aanwezige kennis/vaardigheden. Als dit niet het geval is is het zaak om technologie keuze zo lang mogelijk te vermijden. Het vaststellen van een interface kan op dat moment voldoende zijn om de requirements vast te leggen. Latere design fases kunnen deze interface dan implementeren door een technology keuze te maken.

Goal of the architecture/design phase on one hand is to split up complex problems into smaller realizable chunks. On the other hand to recognize and exploit repeating patterns. In this phase it is possible that subsystems show up which are readily available off-the-shelf. For example by purchasing a product or using opensource software. If you choose for a certain technology in an early phase then this constraint may exclude better alternatives further in the design. Sometimes constraints exist upfront for example due to legacy, due to customer or industry standards or available in-company resources. If this is not the case then it is of importance to delay the technology choice as long as possible. It can be sufficient to specify an interface to capture the requirements. Successive design phases can implement this interface by choosing a certain technology.

Als een technology keuze wordt gemaakt is het nog steeds zaak om goed te kijken in hoeverre de API van deze technology as-is te gebruiken. De vendor lock-in welke hierdoor ontstaat hoeft helemaal niet slecht te zijn als je er bewust voor kiest. In plaats van de geboden API te gebruiken kan er wederom ook een interface worden gedefinieerd. Dit keer niet om requirements te vangen, maar om in een latere fase eenvoudig-(er) van technology te kunnen wisselen. Hier ontstaat wel een spanningsveld. Aan de ene kant kies je voor een bepaald product vanwege unieke onderscheidende eigenschappen. Aan de andere kant zal de genericiteit van een interface deze onderscheidende eigenschappen teniet doen. Zo'n interface heeft immers als doel om functionaliteit van implementatie te ontkoppelen. Twee factoren welke hier een rol kunnen spelen zijn;

If a technology choice is made, then how effortlessly can the API of the technology be used as-is. The resulting vendor lock-in does not have to be bad if it is a concious decision. Instead of using the provided API, again an interface may be defined. This time not to capture the requirements but to allow for an easier replacement of the implementation by a different technology. This will result in some tension because on one side we choose a a specific product for its distinguishing characteristics . On the other side the genericity of an interface will nullify the distinguishing characteristics. After all, the purpuse of such an interface is to decouple functionality from implementation. Two aspect can play a role here;

• Moet het product langere termijn worden ondersteunt?
  Als op het product na oplevering geen of weinig support verwacht wordt is het erg efficient om te gebruiken wat er is in plaats van een abstractie laag er tussen te zetten.
• Should the product be supported for a longer period of time?
  If the product does not have to be maintained after delivery, then it can be very efficient to use whatever is available as-is, without putting an abstraction layer in between.
• Is de interface public facing?
  Als er externe partijen zijn (dus buiten onze controle) welke de interface direct of indirect gebruiken is het erg lastig om de interface achteraf te wijzigen.
• Is the interface public facing?
  If there are external parties (beyond our control) that use the interface directly or indirectly, then it can be far more complicated to make changes to it.

Daarnaast is de technology keuze ook geen triviale aangelegenheid. Waar 15 jaar geleden nieuwe technologieen mondjesmaat op de markt kwamen is er tegenwoordig een overvloed aan oplossingen beschikbaar. Wat nu hot is, kan over 6 maanden alweer zijn achterhaald. Dit is voor projecten of one-offs niet zo belangrijk. Maar voor producten welke voor vele jaren moeten worden gesupport, is het de moeite waard om nog eens goed rond te kijken en wellicht zelfs een ietsje oudere techniek te gebruiken.

Besides, choosing technology is not a trivial affair. Where 15 years ago, new technology appeared gradually, nowadays there is an abundance of choices following up one another in rapid succession. What is hot now may be outdated in 6 months. This is not a problem for one-offs. But for products that have to be maintained for many years, it is worth the effort to look around carefully and even stick to somewhat older and proven technology.

Door de jaren heen heb ik ervaren dat mechanismen vaak efficienter zijn dan specials. Met mechanismen bedoel ik dat er één mogelijkheid is voor een soortgelijk stukje functionaliteit. Eenheidsworst. Om algemene mechanismen te kunnen gebruiken is er een vorm van uniformiteit nodig. Bijvoorbeeld het generaliseren van alle data entiteiten als een identificeerbare set van key-value pairs in plaats van specifieke classes of definities voor ieder type. Of het generaliseren van een varieteit van sensor data tot een discrete of analoge variant.

De echte voordelen van deze werkwijze worden pas duidelijk op het moment dat niet-functionele requirements gaan spelen. De design fase is meestal gefocussed op functionele requirements en het is dan natuurlijk om te modelleren naar de werkelijkheid. Als niet functionele eisen (b.v. logging, monitoring, configuratie, visualisatie, distributie, upgrade, backup) worden meegenomen, dan is het erg makkelijk als alle informatie uniformiteit vertoont en niet inhoudelijk hoeven te worden geidentificeerd. Dit neigt naar weak-typed informatie, maar discussies hierover hebben geen basis als niet functionele requirements niet worden meegenomen.

Er kan hierbij nog steeds met domein objecten worden gewerkt, maar op plaatsen waar de informatie getransporteerd of opgeslagen wordt is het zaak om deze uniform te maken. Hierbij gelden vanzelfsprekend de nodige semantische afspraken om een geldig domein type te duiden. Het is bijvoorbeeld triviaal om een set key-value pairs om te zetten in een strong-typed domein type als in een 'contract' vastligt welke keys wat voorstellen. Het is daarentegen omgekeerd vaak erg lastig om een strong-typed domein type om te zetten in een uniforme set key-value pairs. In de praktijk merk ik dat men meestal de toevlucht zoekt in reflectie wat vaak rommelige en slecht onderhoudbare code oplevert.

Natuurlijk leidt de keuze tot uniformiteit onvermijdelijk tot situaties waar deze minder makkelijk is dan strong-typed domein types. Deze strong-typed types zou echter door alle overige (niet functionele) processen moeten worden ondersteunt, ook als deze geen inhoudelijke kennis hiervan hoeven te hebben. Met andere woorden; aanpassingen van strong-typed types hebben vaak op veel onnodige plekken in het systeem effect. Door strong-typed types pas te instantieren als het domein type nodig is kun je meer focussen op mechanismen en uniformiteit. Oplossingen blijven vaak lokaal en het systeem als geheel blijft goed beheersbaar. Het eindresultaat is een consistent systeem waar goed over te redeneren valt en welke makkelijk(er) te begrijpen is.

Over the years I have experienced that mechanisms are in general more efficient than specials. With mechanismens I mean that there is only 1 approach to implement a similar piece of functionality. To use general mechanism a form of uniformity is needed. For example the generalisation of all entities as an identifiable set of key-value pairs instead of using domain specific classes or definitions. Or the generalisation of a variety of sensor data into discrete or analog values.

The real benefits of this way of working only become apparant when non-functional requirements are considered. The design phase is generally focussed on functional requirements and as such it is only natural to model after reality. If non functional requirements (e.g. logging, mnonitoring, configuration, visualization, distribution, upgrade, backup) are taken into account, then it is very convenient if information is uniform in structure and does not have to be identified individually. This approach inclines to using weak-typed data, but discussion on this miss any basis if non functional requirements are not considered.

One can still use domain entities but on places where information is transported or stored it is convenient to have uniformity. Of course this uniformity must be accompanied by a semantic contract to denote a valid domain object. It is for example trivial to convert a set of key-value pairs into a domain entity if the contract states which keys denote what. The opposite on the other hand is very difficult. I have noticed that attempts to generalize strong typed entities usually rely on reflection resulting in messy and hard-to-maintain code.

Of course this choice inevitably leads to situations where uniformity is more difficult to do than using strong-types domain types. These strong types however would have to be known by all other (non-functional) processes, even if they don't care about the types. In other words modifications to strong-typed types can have impact throughout the system even in places where the type is irrelevant. By instantiating strong types only when needed one can focus more on mechanisms and uniformity. Solutions often remain local and the system as a whole remains well manageable. The end result is a consistent system that you can reason about and which is easier to understand.

Code

Coderen is een creatief process. Net als bij het schrijven van documenten of het maken van designs, zijn bij coderen ook vaak meerdere pogingen nodig alvorens tot een oplossing te komen waar je trots op kunt zijn. Ik heb het niet over vroegtijdig optimaliseren of gold-plating. Maar over elegante oplossingen welke makkelijk lezen en goed te onderhouden zijn.

Coding is a creative process. Just as with writing documents of making designs, coding also requires multiple attempts before ariving at a solution you are proud of. I am not talking about premature optimization of gold-plating, but about elegant solutions which are easy to read and maintain.

Wat betreft coderen is er een aantal werkwijzen welke ik door de jaren heen als nuttig heb ervaren;

As far as coding is concerned, there are a few techniques that I find useful;

• Zet brokken (gemeenschappelijke) functionaliteit achter een interface.
  Het geeft een duidelijk gezicht aan de geboden functionaliteit en zorgt er op een eenvoudige manier voor dat er geen implementatie details doorlekken. Niet onbelangrijk, een interface is een contract welke toe staat dat teams die de interface implementeren en gebruiken parallel aan de slag kunnen.
• Put chunks of (common) functionality behind an interface.
  It provides a clear identity for the offered functionality and assures in a simple way that no implementation details leak through. Not unimportant, an interface is a contract that allows different teams to work on both sides of the interface in parallel.
• Laat interfaces alleen basis types of andere interfaces als argumenten or return value gebruiken.
  Dit staat toe om een library met alleen interfaces te maken. Het zorgt dat voor sterke ontkoppeling van componenten omdat ze compile time alleen van de interface library afhankelijk zijn.
• Only allow basic types or other interfaces to be used as arguments or return values
  This allows creation of an interface-only library. It assures a very strong decoupling of components because at compile time they only depend on the interface library.
• Maak unittesten op interface niveau
  Dit soort unittesten zijn stabieler omdat ze onafhankelijk zijn van de achterliggende implementatie. De volledige implementatie mag door b.v. een refactor slag wijzigen, interface-unittesten blijven overeind. Dit is niet onbelangrijk aangezien unittesten minstens de helft van de coding-effort zijn.
  Daarnaast zullen er ook nog wel een aantal white-box testen zijn die specifieke implementatie aspecten testen.
• Create unittests at interface level
  These kinds of unittests are more stable because they don't rely on underlying implementation. The full implementation may change for example due to a refactoring, but the interface-unittests remain intact.
  Besides these there will always remain a number of white-box tests to verify specific implementation aspects.
• Zorg dat een afgesproken coding style door een tool word afgedwongen.
  Dit voorkomt nodeloze stijl discussies binnen een team, zorgt dat er uniformiteit in de code ontstaat en voorkomt voor een deel Broken Windows.
• Assure that an agreed upon coding standard is enforced by a tool.
  This prevents needless style discussions within the team, assures uniformity in the code and partly prevents Broken Windows.
• Alle interfaces en publieke methodes van commentaar voorzien.
  Minimaal op class/interface en method niveau aangeven wat de intentie is, multi-threaded gedrag en indien mogelijk voorbeelden van gebruik. In de Agile geest 'prefer working code above documentation', is deze vorm van documentatie eenvoudig te onderhouden en zeer waardevol om latere ontwikkelaars snel op het juiste been te zetten.
• Provide all interfaces en public methods with comment.
  At a minimum describe on classes, interfaces and public methods, the intention, multi-threaded behavior and where feasible examples of use. In the Agile spirit 'prefer working code above documentation', this type of documentation is easy to maintain and very useful to put successive developers quickly on the right track.

Usability

Dit betekent voor mij dat een product een manier van werken oplegt, welke aansluit bij het denk process en verwachtings patroon van de gebruiker.

For me this means that a product enforces a way of working that coincides with the thinking and expectation of its user.

• User interfaces
  Dit is het eerste waar men bij usability aan denkt. Zij zijn immers bedoelt voor de eindgebruiker die met het product moeten werken. Een typische eindgebruiker ziet graag een user interface die aansluit bij zijn mental model en bij zijn dagelijkse werk processen. Een valkuil is om user interfaces te maken welke een afspiegeling zijn van de onderliggende techniek of implementatie.
  Naast de gebruikelijke manier om regelmatig feedback van de eindgebruiker te vragen pas ik zelf de 'eat you own dogfood'-test toe. Met andere woorden, ik ga eens een uur serieus met mijn eigen software werken. Inefficienties worden dan al snel duidelijk.
• User interfaces
  This is the first thing users think about with usabilty. After all they are meant for the people that actually have to work with the product. A typical user likes to see an interface that matches his own mental model and daily work process. A common trap is to allow user interfaces reflect the underlying technology or implementation.
  Besides the obvious way of regularly asking potential users for feedback, I often apply the 'eat you own dogfood'-test. In other words , I sit back for an hour and work with my own software. Inefficienties will quickly become appearant.
• API's
  In de vorm van een library of online interface zijn eveneens een belangrijk onderdeel welke gevoelig zijn voor usability. Een API met een onduidelijke syntax of waar gedrag niet duidelijk is of kan worden voorspelt levert de nodige frustraties op. Zeker als er aan een of beide zijdes meerdere implementaties bestaan.
  Ik stel me bij het definieren van een API op als gebruiker om tot een zo gebruiksvriendelijk mogelijke interface to komen. Consistentie in syntax en semantiek, en het volgen van duidelijke patronen zijn hierbij erg belangrijk. Dit zorgt er ook voor dat de API eenvoudig te leren is, makkelijker wordt geaccepteerd, minder plak-code nodig heeft en uitbreidbaar is naar de toekomst.
• API's
  As a library or online interface are also very sensitive to usability. An API with an unclear syntax or with ambiguous semantics is a source of frustrations. In particular when multiple implementations exist on either side.
  When defining an interface I position myself as a user to arive at a user-friendly interface. Consistency in both syntax en semantics and the application of clear patterns are very important. It assures that the API is easy to learn, easy to accept, requires less glue-logic and is extensible towards to future.
• Operations
  De afdeling operations is vaak een ondergeschoven kind binnen software ontwikkeling. De professionals van operations moeten de software bij de klanten installeren en onderhouden. Maar ze zijn niet de primaire doelgroep van de software. Installatie, (rolling) upgrades, (trent-)monitoring, troubleshooting. Het zijn allemaal niet functionele requirements welke niet altijd de aandacht krijgen die ze verdienen.

  Ik erken dat het niet altijd triviaal is om dit op te lossen, zeker bij bestaande producten. Ik ben me wel altijd bewust van deze niet-functionele eisen, en zal ook altijd proberen dit bewustzijn op mijn omgeving over te brengen.

• Operations
  The operations department is often forgotten during software development. The professionals from operations have to install and maintain deployments. But they are not the primary target during development. Installation, (rolling) updates, (trent-) monitoring, troubleshooting. They are all non functional requirements that do not always get the attention they deserve.

  I realize that it is not always trivial to solve these issues, especially with existing products. I am however always aware of these non functional requirements and will always try to rub this off on my environment.

Kwaliteit

Quality

Voor software is natuurlijk de primaire eis dat deze moet werken. Daarna is kwaliteit erg afhankelijk van de belangen van degene die je het vraagt. Een eindgebruiker van software zal bijvoorbeeld andere kwaliteits eisen hebben dan een project leider. Een eindgebruiker zal onbewust de wereld om hem heen en zijn eigen ervaringen als referentie nemen. Hij zal zaken als vanzelfsprekend beschouwen en derhalve niet benoemen. Een projectleider zal eerder streven de gemaakte afspraken op papier na te komen. Hier zitten een hoop niet-functionele eigenschappen niet bij. Als software direct met mensen interacteert, is usability een interessant kwaliteits aspect.

For software a primary requirement is that it does what it should do. After that quality is very dependent on interests of the person who is asked. A user of the software for example will have different demands than a project leader. The user will subconsciously take the world around him and his own experiences as a reference. He will find certain aspect obvious, take them for granted and as such not mention them as a requirement. A project lead will strive towards meeting agreed upon written requirements. Many non functional requirements will not be part of this written agreement. If software directly interacts with people, then usability is an interesting quality aspect.

Voor mij betekent kwaliteit dat iets reproduceerbaar voldoet aan de verwachtingen én voorspelbaar moet werken. Hiervoor moet er een duidelijk referentiekader (requirements) zijn. Dit referentiekader probeer ik vast te stellen tijdens sessies met verschillende stakeholders. De stakeholders zijn ook de enige die de zo vastgestelde requirements kunnen valideren.

For me quality means that software reproducably meets expectations and functions in a predictable way. For this a clear reference must be set. I try to set this reference during sessions with various stakeholders. They are also the only ones that can validate the so collected requirements.

Een belangrijk aspect in kwaliteit is dat er geen onnodige fouten worden gemaakt. Waar requirements nog de menselijke factor in zich hebben voor validatie, is het in de software mogelijk om nagenoeg alles te automatiseren. Structureel code van unittesten voorzien zodat initiele progressie kan worden aangetoont en de risicos van refactoren wordt beperkt. Automatische integratie testen zorgen dat interpratie problemen van interfaces (documenten) worden verminderd. Voor het gehele build, test en deployment process betekend dit zoveel mogelijk stappen te automatiseren.
Dit alles zorgt ervoor dat er geen tijd hoeft te worden besteed aan geestdodend en foutgevoelig testen. Als 100 regels tekst op een soortgelijke manier moeten worden aangepast, is het leuker om 10 minuten te puzzelen op een regex dan om deze tijd te besteden om alles met de hand aan te passen. Om dezelfde reden is het voor developers ook veel motiverender om te automatiseren dan om keer op keer hetzelfde te testen. Procedure fouten (memory-slips), welke vaker door ervarener medewerkers worden gemaakt, worden hiermee vermeden en iedere afwijking van de geautomatiseerde referentie kan als regressie worden gezien. Continuous Integration, Continuous Deployment, DevOps zijn mooie voortangen op dat gebied.

An important aspect in quality is that no unnecessary errors are made. Where requirements still have a human factor in them for validation, for the software itself is possible to almost verify everything automatically. Structurally provide all code with unittests so that initial progression can be shown and risks of refactoring are reduced. Automatic integration tests assure that interpretation problems with interfaces (documents) are reduced. For the entire build, test and deployment process this means that as many steps as possible are automated.
This all makes that as little as possible time is spent on tedious manual and error-prone testing. When 100 lines of text need to be modified in a similar way, then it is more fun to puzzle on a regular expression for 10 minutes than to spent the same amount of time to make the change manually. For the same reason it is far more motivating for engineers to automate than it is to manually test stuff over and over. Procedural error (memory-slips), which occur more often with experienced employees, are prevented and every deviation from the programmed reference can be seen as regression. Continuous Integration, Continuous Deployment, DevOps are neat developments in that area.

Werkgevers

Employers

• Besi

  Den Bosch (2022-heden)
  In de rol van developer werk ik mee in een team van 4 personen aan de dagelijkse ontwikkeling en onderhoud van de software voor een sorteer machine voor ic's (chips). De software voor deze machine is continue in ontwikkeling om de performance in termen van te sorteren devices per uur te verhogen. Daarnaast documenteer ik in samenwerking met de systeem architect nieuwe ideeen zodat anderen ze kunnen gaan begrijpen en er een mening over vormen. Ik werk sommige van deze ideeen ook uit in prototypes.
  Gebruikte tooling en technieken zijn o.a. C#, Lasal (PLC), Mercurial, WCF, WPF, Scrum
  As developer in a team of 4 I do daily development and maintenance of software for a chip sorting machine. The software for this machine is continuously improved to increase performance in terms of number of devices sorted per hour. Besides that, in cooperation with the systems architect, I document new ideas so that others can understand them and form an opinion. Some of these ideas I develop prototypes.
  Gebruikte tooling en technieken zijn o.a. C#, Lasal (PLC), Mercurial, WCF, WPF, Scrum
• Omron

  Den Bosch (2020-2021)
  Mijn taak as Team Lead on een team van 3 onmtwikkelaars, is om de diverse geautomatiseerde productielijnen te onderhouden and te verbeteren. Ik heb bestaande software voor een aantal bestaande lijnen gedocumenteerd met als doel om nieuwe ontwikkelaars in de toekomst sneller op weg te helpen. Daarnaast heb ik een bestaande component pick-to-beamer welke operator instructie geeft middels een projector en de handelingen monitored via een camera verbeterd. Dit product was het resultaat van een afstudeer opdracht en dat had een redesign nodig om op alle vlakken eenvoudiger en gebruiksvriendelijker te worden. Ontwikkeling is primair in .Net Core, C# en WPF.
  My job as Team-lead of a team of 3 is to maintain and improve the automation software for various production lines. I documented existing software for a number of production lines to kick start future developers. I also redesigned an existing component called pick-to-beamer that provides a operator with instrucions using a beamer and monitors its actions using a camera. This product was the result of a traineeship and needed to be improved on simplicity, user friendliness. Development is primarily .Net Core, C# en WPF.
• De Jong Duke

  Sliedrecht (2018-2019)
  In de rol van senior developer ben ik initieel verantwoordelijk voor het toevoegen van een API aan de bestaande besturings software ten behoeve van een nieuwe stand alone GUI. In een latere fase werk ik mee om de bestaande embedded machine besturings software uit te breiden en te verbeteren en de transitie van gegenereerde Rhapsody naar 'gewone' C++ code te verwezenlijken.
  Gebruikte tooling en technieken zijn o.a. C++, Rest, Scrum, TDD, Gitlab(-CI), CMake en docker.
  As senior developer I am initially responsible for adding an API to the machine control software to allow for an external GUI to be developed. In a later phase I join the embedded team to extend and improve the existing control software and facilitate the transition from generated Rhapsody code to 'normal' C++ code.
  Used tooling and techniques are a.o. C++, Rest, Scrum TDD, Gitlab(-CI), CMake and docker
• Axon

  Gilze (2017-2018)
  In de rol van senior developer stel ik high level software requirements op voor verschillende producten. Daarnaast werk ik als lead developer primair aan een nieuw product. De ontwikkeling hiervan is in C++/Qt. Interessante zaken waren nieuwe tooling zoals Gitlab(-CI), Robot integration test framework, CMake en WAMP.
  As senior developer I write high level software requirements for various products. Besides that I primarily work as lead developer on a new product. Development is in C++/Qt. Interesting aspects were new tooling like Gitlab(-CI), Robot integration test framework, CMake and WAMP.
• Seachange

  Eindhoven (2008-2017)
  In de rol van systeem architect, aan uitbreidingen op de bestaande architectuur gewerkt en voorbereid om te worden opgepakt door de development teams. In de daaraan voorafgaande periode ben ik voornamelijk als lead developer bij diverse projecten betrokken geweest. Dit waren zowel nieuwbouw projecten als grote lang lopende refactor projecten waarbij 'de winkel' open moest blijven.
  Als developer heb ik zowel C++, Java als C# projecten gedaan met als hoofd tools Visual Studio en Netbeans. Interessante aspecten in deze periode waren o.a. Scrum, DVB, TVA, scalability aspecten (upgrading, caching), backward compatibility, Cassandra, Lucene en Jetty.
  Daarnaast heb ik rol van scrum master vervuld met alle daarbij horende ceremonies.
  In the role as Systems Architect I currently work on investigating and preparing extensions on the existing architecture to be picked up by development teams. Before that I was involved in various projects primarily as a lead developer. These were both new projects as well as long running major refactors where the application had to keep working in the mean time.
  As developer I did C++, C# as well as Java projects. With main tools Visual Studio and Netbeans. Interesting aspects during this period were a.o. Scrum, DVB, TVA, scalability aspects (upgrading, caching), backward compatibility, Cassandra, Lucene and Jetty.
  I also performed the role of scrum master along with all relevant ceremonies.
• PTS Software

  Baarn (1999-2007)
  Via PTS ben ik als professional bij Philips, Delem, NXP en ASML gedetacheerd geweest. Dit was in de rol van senior software engineer/designer en gedurende 1 project was ik tevens team lead. De projecten waren zowel nieuwbouw als onderhouds projecten.
  De projecten waren voornamelijk C/C++ met als hoofdtool Visual Studio. Interessante aspecten binnen deze periode waren o.a. DVB-H, Hatley & Phirbai, Lex&Yacc.
  Via PTS I have been outsourced as a professional to a.o. Philips, Delem, NXP and ASML. This was in the role as senior software engineer/designer and during one project I was also team lead. The projects were both new developments as well as maintenance.
  Development was mainly C/C++ with Visual Studio as main tool. Interessting aspects during this period were a.o. DVB-H, Hatley & Phirbai, Lex&Yacc.
• SPC Company

  Nieuwkuijk (1991-1998)
  In deze periode ben ik van junior ontwikkelaar gegroeid naar senior. SPC Company maakte in eerste instantie Informix kantoor toepassingen. In de begin periode was ik de enige technische ontwikkelaar en zorgde voor integratie software met externe systemen/hardware. Later is SPC Company primair industriele machines gaan maken met Vision als kern-technology. In deze periode ben ik lead developer/designer geweest van de software voor een aantal industriele machines. Een leuk aspect in deze periode was een aantal keer het begeleiden van stagieres.
  Ik ontwikkelde in Assembler/C/C++ met als tools Watcom/Visual Studio. Interessante aspecten in deze periode waren o.a. 80x86 assembler, SCO Unix, Vision Algoritmen, DOS-Extenders, TCP, Novel IPX/SPX.
  In this period I grew from a junior to a senior developer. Initially SPC Company developed Informix office applications. In the beginning I was the only 'technical' developer and took care of integrating the software against external systems and hardware. Later on SPC Company primarily focussed on industrial machines with Machine-Vision as core component. During this phase I was lead developer/designer for the software of many industrial machines. In this period I also guided and trained some interns which I found very rewarding.
  I developed in Assembler/C/C++ with Watcom/Visual Studio as main tools. Interesting aspects during this period were a.o. 80x86 assembler, SCO Unix, Vision Algoritms, DOS-Extenders, TCP, Novel IPX/SPX.

Een greep uit mijn projecten

Some of my projects

• Senior Developer

  Axon (2017-2018)
  Op basis van een bestaand product en nieuwe eisen van product management, stel ik high level software requirements op voor een next generation Multiviewer. Een multiviewer is primair in staat om vele lineare TV services als mozaiek te visualiseren. Ik maak een technisch design en werk ik als lead developer aan de volledige UI, communicatie protocollen en alle integratie logica.

  Ik verplaats mezelf continue in de gebruiker om het product zo gebruiksvriendelijk mogelijk te maken. Voor zowel ontwikkelaars, mensen van operations en de eindgebruikers.

  Interessant was dat we vanaf dag 1 serieus werk hebben gemaakt om debugging, test en troubleshoot faciliteiten te integreren. De software schrijf ik in C++/Qt. Voor inter process communicatie gebruiken we voornamelijk WAMP. Helaas ben ik door omstandigheden niet in staat geweest het product verder te zien evolueren dan de eerste versies.

• Senior Developer

  Axon (2017-2018)
  Based on the existing product combined with the many new demands I assemble high level software requirements for a next generation Multiviewer. A Multiviewer's primair goal is to visualize many lineare TV channels as a mosaic. I create a technical design and as lead developer I implement all user interfaces, communication protocol and integration logic.

  I continuously place myself in the user in order to make the product as user-friendly as possible. Both for developers, operations and the end-user.

  Interesting was that we put serious effort in integrating debugging/testing and troubleshooting facilities from day one. The software is written in C++/Qt. For inter process communication we primarily use WAMP. Unfortunately due to circumstances I was no able to complete the product beyond the initial versions.

• Systeem architect - VOD BackOffice

  SeaChange (2016-2017)
  Als systeem architect ben ik in een team van 5 mede verantwoordelijk voor het uitbreiden van het Video On Demand back office platform. Uitbreidings verzoeken komen zowel van klanten als van ons eigen product management (roadmap). Het is mijn taak om de individuele componenten, interne en externe interfaces zo uit te breiden om aan de wensen te voldoen. Hierbij zijn de spanningsvelden;
  1) geen klantspecifieke oplossingen in onze one-and-only codebase
  2) uitbreidingen moeten backward compatible zijn
  3) de impact (nieuwe code, wijzigingen) moet zo laag mogelijk zijn.
  Naast het doorgronden van het onderliggende probleem en een of meerdere oplossingen te bedenken, was hier ook een zekere mate van lobbyen en onderhandelen nodig om iedereen op één lijn te krijgen.
• Systems architect - VOD BackOffice

  SeaChange (2016-2017)
  As part of a team of 5 it is my responsibility to extend the existing Video On Demand Back Office platform. Change requests originated both from the product management (roadmap) as well as from customers. It is my task to extend and change components, internal and external interfaces to fullfill the requested change.
  Fields of tension are;
  1) no customer specific solutions in our one-and-only code base.
  2) extensions must be backward compatible.
  3) the impact (new code, change of existing code) must be kept to a minimum.
  Besides comprehending the underlying problem and coming up with one or more solutions, there was a certain amount of lobbying and nogotiating required to get everyone on the same page.
• Lead Developer - BMS

  SeaChange (2014-2016)
  Een van de producten is BMS, een web-based GUI om het onze klanten makkelijk te maken producten en catalogus te onderhouden. BMS was initieel ontwikkeld in de ASP tijd waar de totale hoeveelheid data beperkt was. Door de jaren heen werd het duidelijk dat BMS op de schop moest om weer met de tijd mee te kunnen. BMS moest een frisse look krijgen en intuitiever worden, het moest 'snappy' werken ook met meerdere gebruikers.
  Dit resulteerde in server side query interfaces en clientside Javascript. Als lead developer van de server side heb ik een zeer flexibele JSON Rest interface gedefinieerd welke de Javascript developers alle vrijheid gaf. Een zeer interessante uitdaging waren de lokale undo-able edits per gebruiker bovenop een gedeeld datamodel.
  Door de pure functionele aard van de diverse back-office interfaces was er geen mogelijkheid om efficient door alle data te zoeken en navigeren. Een noodzakelijkheid voor BMS. Lucene, in-memory navigatie modellen en caching zijn ingezet om deze beperking te omzeilen.

  Niet direct gerelateerd aan mijn werk, maar bij deze refactor hebben we een UX-designer (User-Experience) ingezet. Hierdoor ging niet alleen het uiterlijk, maar ook de interactie met het product met sprongen vooruit. In deze periode heb ik veel geleerd over hoe GUI's voor eindgebruikers moeten zijn en dat UI-designer != UX-designer.

• Lead Developer - BMS

  SeaChange (2014-2016)
  One of the products is BMS, a web-based GUI that allows customers to easily manage products and catalogs. BMS was initially developed in ASP era when the total amount of metadata was limited. Over the years is became appearant that BMS required a major overhaul in order to get along in the years to come. BMS needed a new and fresh look, become more intuitive and snappy to use, also in the face of multiple users.
  This resulted in the decoupling of server and GUI via query interfaces and clientside javascript. As server side lead developer I designed and created a very flexible JSON Rest interface that provided Javascript developers with full freedom of use. A very interesting challenge was support for local undoable edits per user on top of an otherwise shared datamodel.
  Due to the various pure functional interfaces provided by the back-office there was no possibility for BMS to perform generic queries over the datamodel, a neccesity for BMS. Lucene, in-memory navigation models and caching were deploysed to overcome these limitations.

  Not directly related to my job, but during this refactor we had the support of UX-designer (User-Experience). This not only improved the look and feel, but also the interaction with the product drastically improved. During this period I learned a lot on how GUI should behave for end-users and that UI-designer != UX-designer.

• Lead Developer - Publisher

  SeaChange (2010-2013)
  Een kritiek onderdeel van het Video On Demand back office is het beschikbaar stellen van een API richting de miljoenen client devices (Settop Box, PC, Tablet). SeaChange had reeds een Publisher geschreven in C# gebaseerd op SQL.
  Mijn opdracht was om een versie te maken in Java (platform onafhankelijk) en beter schaalbaar middels NoSQL databases. Daarnaast moest voor migratie van de amerikaanse markt, een aantal legacy client interfaces ook gesupport moest worden.
  Ik heb de nieuwe Publisher ground-up opnieuw gedesigned, gebaseerd op Cassandra als NoSql database, Lucene als search engine en Jetty als embedded Application Server. Veel werk is gaan zitten in mechanismen om Cassandra efficient te kunnen gebruiken voor relaties, log-queues, instant data-updates en rolling upgrades. Voor mij was dit mijn eerste grote Java klus, maar na C++ en C# bleek de stap een kleine.
  Vanwege praktische reden is de verdere ontwikkeling in 2013 helaas naar het amerikaanse hoofdkantoor verhuist.
• Lead Developer - Publisher

  SeaChange (2010-2013)
  A critical part in the Video On Demand back office is the API for use by millions of client devices (Settop Boxes, PC's, tablet). SeaChange already had a Publisher writting in C# based on SQL.
  My job was to create a version in Java (platform independent) that was easier scalable by using a NoSQL database. Besides that for migration of the american market, a legacy interface had to be supported as well.
  I designed and developer the new Publisher ground-up, based on Cassandra as NoSql database, Lucene as search engine and Jetty as embedded Application Server. A lot of work went into mechanisms to apply Cassandra efficiently for relations, log-queues, instant data-updates and rolling upgrades. For me this was my first big Java project, but afterbaswe C++ en C# the step was a small one.
  For practical reasons, further development unfortunately moved to the american head quarters in 2013.
• Lead Developer - PSI/SI Verifier

  SeaChange (2008)
  Een klant had de wens om zijn Lineare TV MPEG/DVB streams, te valideren op correctheid. Omdat een dergelijk product niet in ons portfolio zat werd besloten om er een te gaan ontwikkelen.
  Vanwege een totale sustained input bitrate van ruim 300MB/sec, was mijn initiele opdracht om vanwege performance een C++ service te ontwikkelen. Deze service moest 24/7 realtime alle MPG aspecten en DVB metadata (tabellen) verzamelen en via TCP interface 'hapklaar' beschikbaar te stellen voor verdere verwerking.
  Als vervolg opdracht heb ik het verdere modules ontwikkeld om de controle uit te voeren welke door de ASP developers werden gevisualiseerd.
• Lead Developer - PSI/SI Verifier

  SeaChange (2008)
  A customer had the request to validate their MPEG/DVB streams for correctness. Because such a product was not in our portfolio, it was decided to develop one.
  Due to the overall sustained input bitrate of over 300MB/sec, my initial task was to develop a monitor service in C++ for performance. This monitoring service had to be available 24/7, collect all MPEG characteristics and raw DVB metadata (subtables) and expose this ready-to-eat over a TCP interface for further processing.
  A follow-up assignment was to develop successive modules to execute the verification and expose this validation information towards ASP developers for visualization.
• Developer - DVB-H Test generator

  NXP (2006)
  NXP ontwikkeld een DVB‑H receiver chip voor ontvangst van digitale TV op een mobieltje of PDA. Om variaties in input te kunnen testen is een test generator nodig.
  Mijn opdracht is het om een MPEG DVB‑H generator te ontwikkelen om alle functionele eigenschappen van een DVB‑H stroom te genereren. Daar hoort tevens het injecteren van definieerde fouten bij om de forward error correction te testen. Als tegenhanger is tevens een DVB-H demultiplexer ontwikkeld om DVB‑H streams uit het veld te analyseren.
  Deze tools zijn in C++ ontwikkeld.
• Developer - DVB-H Test generator

  NXP (2006)
  NXP develops a DVB‑H receiver chip for reception of digital TV on a cell phone of PDA. To verify for correct behavior on variations of the input a test generator was required.
  My assignment was to create an MPEG DVB‑H generator that allows verification of all functional characteristics of a DVB‑H stream. That included injection of deliberate errors to verify forward error correction. As counterpart I developed a DVB-H demultiplexer to analyse DVB‑H streams recorded in the field. The tools were developed in C++.
• Developer - Driver generator

  Philips Semiconductors (2004-2005)
  Philips Semiconductors ontwikkeld een all-in-one TV chip voor ontwikkeling van analoge TV’s. De variatie in chips en de bijbehorende aansturing maak code ontwikkeling een saaie en foutgevoelige aangelegenheid. Omdat de registers van deze chips door hardware development in excel sheets werden beschreven, heb ik voorgesteld om een driver-generator te maken.
  Mijn werk bestond er uiteindelijk uit om een generator te maken welke vanuit deze excel sheets een driver kon genereren. Deze driver boodt een generieke interface om alle registers te benaderen. Na C++ implementatie heb ik interne developers begeleid bij invoering van de nieuwe driver interface.
• Developer - Driver generator

  Philips Semiconductors (2004-2005)
  Philips Semiconductors develops all-in-one TV chips for use in van analoge TV’s. The variation in chips and the associated control makes developing code a tedious and error-prone engagement. Because the hardware department documents register descriptions in excel sheets, I proposed to create driver-generator.
  My job was to design and implement the driver-generator that could generate a driver library from an excel sheet. This driver offered a generic interface to access all registers. After the C++ implementation I helped colleague developers integrating and using the generic drivers.
• Lead developer - Download Module (DOMO)

  ASML (2003)
  ASML ontwikkelt VME borden met FPGA’s welke middels een DOMO (Download Module) worden geconfigureerd. Het is softwarematig mogelijk om de DOMO inhoud (en dus bord-functionaliteit) te upgraden. Dit was nodig om machines in een cleanroom niet fysiek te hoeven openen.
  Mijn opdracht was om een DOMO software component te specificeren, implementeren en uit te rollen binnen de ASML afdelingen. Naast rol van teamleader heb ik de specificaties, het OO/Hatley & Pirbhai design, en het testplan opgesteld. Ik heb aan de implementatie meegewerkt gebruikmakend van Lex&Yacc en C. Interessant aan dit design was dat de interface een god-functie bood welke voor klanten met minimale input nagenoeg alles deed.
• Lead developer - Download Module (DOMO)

  ASML (2003)
  ASML develops VME boards containing FPGA's that can be configured via a DOMO (Download Module). It is possible to software-wise upgrade a DOMO module. This allows machines to get hardware updates without physically opening them in the cleanroom.
  My assignment was to specify, design and implement the software to manage DOMO modules and to instruct component developers in how to use them. Besides being the team lead, I managed requirements, created an OO/Hatley & Phirbai design along with a testplan. I assisted in part of the implementation using Lex&Yacc and C. Interesting about this design was the presence of a god-function that performed all required tasks with a minimum of input making it very easy for clients to integrate.
• Developer - Encoders

  ASML (2002)
  In het kader van kostenbesparing is een bestaand interferometer positie bepalingssysteem vervangen door een encoder meet systeem. Hiervoor is een speciaal VME bord ontwikkeld welke de gemeten encoder licht signalen omzet in een nanometer posities. Voor dit interface board was een support library nodig.
  Binnen dit project was mijn taak het ontwikkelen van een C support library van analyse tot implementatie.
• Developer - Encoders

  ASML (2002)
  In the context of cost reduction an existing interferometer system was replaced with an encoder system. For this, a dedicated VME board was developed that measured the encoder light signals and turned them into nanometer acurate positions. For this board a support library was needed.
  Within this project my task was creating a C support library from analysis to implementation.
• Developer

  Delem (2001)
  Delem ontwikkelt elektronica voor aansturing van zet-banken en wil een nieuwe generatie ontwikkelen.
  Mijn taak was initieel het in kaart brengen van het bestaande proprietary Delem-OS, de bijbehorende real-time functionaliteiten en de scheiding bepalen met de applicatie code. Daarna heb ik het OS geredesigned in de vorm van een cooperative multitasking OS. Implementatie hiervan is in 80386 assembler en C. Binnen het applicatie gedeelte ben ik verantwoordelijk geweest voor de generieke classes en templates. Binnen dit project werken we met Rational Rose als design tool vanuit waar code wordt ge(her)genereerd.
• Developer

  Delem (2001)
  Delem develops electronics for controlling press brakes and wants to develop a new line.
  My initial task was to map the functionality of their proprietary Delem-OS, the associated real time aspects and the boundaries with application code. After that I re-designed the OS using a form of cooperative multitasking in 80386 assembler and C. Within the application part I was responsible for generic support classes and templates. Within the project we worked with Rational Rose as design tool and for (re-)generating code framework.
• Developer - Alignment

  ASML (1999-2000)
  In deze periode heb ik diverse onderhoudswerkzaamheden verricht aan een alignment driver component. Vanwege onderhoudbaarheids problemen heb ik de driver voor een groot deel gerefactored of opnieuw geïmplementeerd. Documentatie in in Hatley & Phirbai, implementatie in C.
• Developer - Alignment

  ASML (1999-2000)
  During this period I picked up various maintenance tasks for the alignment driver component. Due to maintenance issues I refactored and re-implemented most of the driver. Documentation was all in Hatley & Phirbai, implementation in C.
• Developer - Vision

  Jentjens (1998)
  Een machine, die trommeltjes vult met korrels voor medische dialyse doeleinden, moet visueel worden gecontroleerd. Een Windows gebaseerd vision systeem met 4 camera’s analyseert de inhoud van deze buisjes op juiste vullingsgraad.
  Binnen dit project was ik verantwoordelijk voor het totale software traject inclusief Vision algoritmen. De analyse software maakt gebruik van een eigen ontwikkelde C++/assembler vision library. De Vision applicatie alsmede rapportage en TCP/IP machine interactie zijn uitgevoerd in C++. De user interface is geïmplementeerd door middel van het eerder ontwikkelde MMIR.
• Developer - Vision

  Jentjens (1998)
  A machine that fills tubes of medical drums with grains had to be visually inspected. A Windows-based vision system with 4 cameras analyses the contents of all tubes for the correct fill level.
  Within this project I was responsible for the entire software development, including vision algorithms. De analysis software uses our own developed C++/assembler vision library. The Vision application, reporting and TCP/IP machine interactions were developed in C++. The user interface was implemented using an earlier developer UI component MMIR.
• Developer - Blauwebessen sorteermachine

  SPC Company (1997)
  Een blauwe bessenkweker wil een machine om rijpe bessen te sorteren. Door middel van fluorescentie en beeldherkenning worden niet-rijpe bessen van een snarenband geblazen.
  Binnen dit project heb ik alle software specificaties en het design opgesteld. Daarnaast heb ik de juiste vision algoritmen ontwikkeld en een bijbehorende real-time applicatie om de bessen te tracken en de niet rijpe op het juiste moment eruit te blazen. De volledige implementatie heb ik uitgevoerd onder DOS in C++ en een DOS extender.
• Developer - Blueberry Sorter

  SPC Company (1997)
  A blueberry grower wants a machine to sort ripe and unripe berries. Using fluorescence and machine vision non ripe berries are recognized and physically blown of a snare-belt.
  Within this project I designed and created all software. Besides that I developed the realtime Vision application to track the unripe berries and control air-valves to blow them away at the right time. The entire implementation was done in DOS using C++ and a DOS extender.
• Developer - Man-Machine Interface Runner

  Detron (1996)
  Detron wil een touchscreen gebaseerde Man Machine Interface voor een PLC bestuurde wafer processing machine.
  Mijn rol was om de klant interactie wensen om te zetten in GUI requirements. Daarnaas was ik verantwoordelijk voor het design en de implementatie. Vanwege de onduidelijkheid in requirements heb ik gekozen voor een script gestuurde oplossing. Dit stond mij toe om de interactie en look-and-feel via een script-file te configureren en zodoende flexibel met klantwensen om te kunnen gaan. De gekozen oplossing is daarna gedesigned en geïmplementeerd in OO/C++.
  Omdat de MMI zo flexibel bleek, is de hard-coded PLC interface later vervangen door een generieke DLL interface waardoor een variëteit aan PLC’s kan worden bediend evenals een interface naar reguliere Windows applicaties. De MMI is binnen SPC daarna voor nagenoeg alle projecten gebruikt als standaard user interface.
• Developer - Man-Machine Interface Runner

  Detron (1996)
  Detron wants a touchscreen based Man-Machine Interface for an otherwise PLC controlled wafer processing machine.
  My role was to turn customer requirements into GUI requirements, and come up with a design and implementation. Due to the unsure GUI requirements I choose for a script based UI. This allowed me to change the interaction and look-and-feel via an external scriptfile to accomodate the changing requirements from the customer. The choosen solution was design and developed in OO/C++.
  Because the MMI turned out to be so flexible, the hard-coded PLC link with the machine was replaced with a generic DLL interface. This allowed a variety of machines to be controlled in various ways, including regular Windows applications. After that, the MMI was used within SPC for nearly all successive projects as the standard UI component.
• Developer - Standalone Lendomaat

  Checkpoint (1995)
  De eerder ontwikkelde Lendomaat was zo succesvol dat een stand-alone versie is gewenst. Deze nieuwe Lendomaat moest onder Windows 95 gaan werken systeem met een grote diversiteit aan hardware en bibliotheek databases.
  Mijn rol in dit project was het opstellen van alle requirements, designs en implementaties. De basis Lendomaat is een OO applicatie geschreven in C++ welke via plug-ins een diversiteit aan hardware (activators, scanners, chipcard etc.) bestuurd en met databases communiceert.
• Developer - Standalone Lendomat

  Checkpoint (1995)
  The earlier developed Lendomat was so successful that a stand-alone version was requested. This new Lendomat had to run on Windows 95 with a great diversity of hardware and library databases.
  My role in this project was writing down all requirements, the design and implementation. The basic Lendomat is an OO application written in C++ that uses plugins to control diverse hardware (activators, scanners, chipcards etc.) and communicate with databases.
• Developer - Kleerhanger sorteerder (Chips)

  Kobes Plastics (1993-1994)
  Kobes plastics is een kleerhanger recycler welke door middel van automatisering zijn capaciteit wil vergroten. De sortering werd gerealiseerd door middel van spindel transport systemen en machine vision. Alle mechanica werd via een Siemens PLC aangestuurd, de Vision systemen draaiden onder DOS en communiceren via directe IO met de PLC. Novell’s SPX/IPX protocol verbond alle systemen met elkaar. Via een back-office applicatie met Windows-look wordt de volledige installatie bestuurt en rapporten gegenereerd.
  Ik ben in dit project verantwoordelijk voor de software requirements, designs, vision algoritmen en alle software implementaties. De vision en back-office applicatie zijn geschreven in C++ onder Novell. De PLC is op een erg onconventionele manier in Step5 geprogrammeerd.
  De hoeveelheid mechanica in project was het werkelijk een genot om te besturen en om uiteindelijk tot een werkend geheel te brengen. Daarnaast was het herkennen van tientallen verschillende soorten kleerhangers middels een camera een erg leuke uitdaging.
• Developer - Coathanger sorter (Chips)

  Kobes Plastics (1993-1994)
  Kobes Plastics is a coat hanger recycler that wanted to increase its capacity by means of automating the physical sorting. The sorting was realized by means of spindels transporters and machine vision. All mechanics were controlled via a Siemens PLC. The Vision systems ran DOS and communicated via direct IO with the PLC. Novell's IPX/SPX protocol connected all systems. A back-office application with a windows-look controlled the entire system and could generate reports.
  In this project I was responsible for the software requirements, design, vision algorithms and all software. The Vision and back-office applications were written in C++. The PLC was programmed in Step5 in a very unconventional way.
  The amount of mechanics in this project was truly a joy to control and to finally see at work. Additionally creating the vision algorithms to recognize and distinguish dozens of coathangers was a very nice challenge.
• Developer - Video Library Systeem

  Hogeschool Eindhoven (1992)
  Voor de Hogeschool is een gedistribueerd video systeem ontwikkeld waarbij in veel leslokalen een serieel bestuurbare TV en een losse besturings terminal aanwezig zijn. Een centrale ruimte bevat een collectie 20 VCR’s, 600 video banden en een robot welke videobanden kan (ver)plaatsen. Een centraal SCO Unix systeem bestuurt alle TV’s, besturingspanelen en de robot. Via een Informix database applicatie worden videobanden op voorhand gereserveerd.
  Mijn rol is het opstellen alle software specificaties voor de besturing, een interface definiëren met de Informix database en de implementatie van alle besturings software om de robot videobanden te laten verplaatsen tussen VCR en opslag en om de terminals en TV's te bedienen.
  De interessante aspecten hier waren het bijhouden van de state machines voor tientallen parallele sessies en de bijbehorende terminal en TV aansturing. De besturings software van dit project is gedaan in C onder SCO Unix met vi en make als 'tool-chain'.
• Developer - Video Library Systeem

  Hogeschool Eindhoven (1992)
  For the university of Eindhoven a distributed video system was developed in which most rooms were equiped with a remotely controlled TV and a separate control terminal. A central room in the university contained a collection of 20 VCR's, approximately 600 video tapes and a robot that could move tapes around. A central SCO Unix system controlled all TV's, control terminals and the robot. Via an Informix database application, tapes could be reserved upfront.
  My role was specifying the software requirements for all control systems, defining an interface with the Informix database and all control software. The software controlled the robot in moving tapes between VCR's and their storage location, monitoring the terminals and controlling all TV's.
  An interesting aspect was maintaining the various state machines for dozens of parallel sessions and the control of individual terminals and TV's. The control software for this project was in C running under SCO Unix and created with vi and make as 'tool-chain'.
• Developer - Lendomaat

  Katholieke Universiteit Brabant (KUB) (1991)
  De KUB wil een geautomatiseerd uitleen en retour systeem ontwikkelen dat personeel ontlast van deze standaard taken. Een SCO Unix systeem vormde de centrale besturing van de uitleen en retour stations.
  De uitleen en retour transacties in de PICA bilbiotheek database worden uitgevoerd door een standaard gebruikers TELNET terminal sessie te simuleren. De uitleen en retour stations bestonden uit standaard DOS systemen uitgebreid met specifieke hardware en een seriële link voor aansturing vanuit Unix. Mijn rol hierin zijn het opzetten van communicatie protocollen tussen besturing en stations en implementatie van alle software in C.
• Developer - Lendomat

  Catholic University Brabant (KUB) (1991)
  The KUB wants to relieve personal from lending out and taking in books from customers by automating these processes. An SCO Unix systeem formed the central control for the automated lending and return stations.
  The required underlying library transactions in the PICA library database were done by emulating regular TELNET terminal user. The lending and return station existed from standard DOS systems extended with specific hardware and a serial link for the control from Unix. My role in this was designing a communication protocol between Unix and the DOS system and implementing Unix and DOS applications in C.

Techniek gerelateerde onderwerpen, zaken, quotes etc. waar ik tegen aan gelopen ben en waar ik energie van kreeg, motiverend vond of enthousiast van werd. Onderwerpen waar ik het liefst direct mee aan de slag zou gaan of waar ik jaren later nog steeds gebruik van maak of naar verwijs.

Technology related subjects, stuff, quotes etc that I ran into and that gave me energy, motivated me or made me enthousiastic. Subjects I love to dive into instantly or that I still use or refer to years later.