![foto eric](images/eric_foto.png)
Eric van Orsouw
Ik ben een pragmatische software designer met een brede ervaring van meer dan 30 jaar. Van architectuur tot implementatie in C/C++/C# en Java. Ik denk graag out-of-the-box en zoek naar gebruiksvriendelijke oplossingen waar op voorhand goed over te redeneren valt. Geen black magic, maar White Magic!
I am a pragmatic software designer with a broad experience of over 30 years. From architecture to implementation in C/C++/C# and Java. I like to think out-of-the-box and try to find user‑friendly solutions that are easy to reason about upfront. No black magic, but White Magic!
Neem gerust contact met mij op als u een software vraagstuk heeft of als u op zoek bent naar handjes voor een kleinere of grotere klus. Feel free to contact me if I you have a software challenge or if you need some extra capacity for a smaller of bigger task.- requirements
- architectuur / design
- architecture / design
- refactoring / redesign / software archeologie
- refactor / redesign / software archeology
- schaalbare software
- scalable software
- embedded systemen
- embedded systems
- machine besturing
- machine control
- high efficient code
- C/C++/C#/Java
- Scrummaster
- ...
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.
2019 | Machine learning / Neurale netwerken | Machine learning / Neural networks | MOOC Standford University |
2015 | Java EE training | Info Support | |
2014 | ScrumMaster | Zilverline | |
2013 | Microsoft Certified Developer - Web Development | Zelf studie | |
2013 | Microsoft Certified Developer - Web Development | Self study | |
2009 | Effectief projectmatig werken | Schouten en Nelissen | |
2005 - 2006 | Embedded Systems Architect | ESI - Embedded Systems Institute | |
2003 | Real Time System Development Overview | ISES | |
2002 | Introductie cursus Windows CE | Getronics | |
2002 | Introduction course Windows CE | Getronics | |
2001 | Object Oriented Design | Datasim | |
2001 | Object Oriented Analysis | Datasim | |
2000 | Hatley & Phirbai | ASML inhouse | |
1999 | Object Oriented Methoden & Technieken | RUG - Rijks Universiteit Groningen | |
1999 | Object Oriented Methods & Technologies | RUG - Rijks Universiteit Groningen | |
1999 | Personal Software Process | PTS | |
1998 | Object Oriented Software Ontwikkeling | PTS | |
1998 | Object Oriented Software Development | PTS | |
1985 - 1990 | HTS Electrotechniek - Informatietechniek | HTS 's-Hertogenbosch | |
1985 - 1990 | Polytechnic Electronics - Informationtechnology | HTS 's-Hertogenbosch | |
1980 - 1985 | HAVO | RSG 's-Hertogenbosch |
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 valuesThis 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 niveauDit 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 levelThese 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 interfacesDit 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 interfacesThis 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'sIn 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'sAs 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. -
OperationsDe 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.
-
OperationsThe 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
-
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, ScrumAs 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 -
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.
-
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 -
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.
-
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. -
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 CompanyNieuwkuijk (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 DeveloperAxon (2017-2018)
-
Senior DeveloperAxon (2017-2018)
-
Systeem architect - VOD BackOfficeSeaChange (2016-2017)
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 BackOfficeSeaChange (2016-2017)
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 - BMSSeaChange (2014-2016)
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 - BMSSeaChange (2014-2016)
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 - PublisherSeaChange (2010-2013)
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 - PublisherSeaChange (2010-2013)
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 VerifierSeaChange (2008)
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 VerifierSeaChange (2008)
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 generatorNXP (2006)
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 generatorNXP (2006)
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 generatorPhilips Semiconductors (2004-2005)
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 generatorPhilips Semiconductors (2004-2005)
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)
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)
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 - EncodersASML (2002)
Binnen dit project was mijn taak het ontwikkelen van een C support library van analyse tot implementatie. -
Developer - EncodersASML (2002)
Within this project my task was creating a C support library from analysis to implementation. -
DeveloperDelem (2001)
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. -
DeveloperDelem (2001)
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 - AlignmentASML (1999-2000)
-
Developer - AlignmentASML (1999-2000)
-
Developer - VisionJentjens (1998)
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 - VisionJentjens (1998)
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 sorteermachineSPC Company (1997)
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 SorterSPC Company (1997)
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 RunnerDetron (1996)
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 RunnerDetron (1996)
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 LendomaatCheckpoint (1995)
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 LendomatCheckpoint (1995)
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)
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)
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 SysteemHogeschool Eindhoven (1992)
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 SysteemHogeschool Eindhoven (1992)
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 - LendomaatKatholieke Universiteit Brabant (KUB) (1991)
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 - LendomatCatholic University Brabant (KUB) (1991)
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.
Machine learning
Systemen welke niet uitgeprogrammeerd maar zelf hun weg vinden om een bepaalde klus te klaren zoals mensen dat ook doen. Artificial General Intelligence of AGI lijkt voorlopig nog ver weg maar de concepten van neurale netwerken en machine learning zijn niet meer te stoppen en zullen langzaam vele menselijke taken overnemen. Afgezien dat de mogelijkheden immens zijn is deze tak van sport vanuit job-security de komende decennia ook een goede keuze. System that don't need to be programmed but find their own way to solve an issue just as humans do. Artifical General Intelligence or AGI seems far away at the moment but the concepts of neural networks and machine learning seem unstoppable and will gradually take over many human tasks. Apart from the immens applications, this branch of technology also seems a safe job-career choice for the coming decades. |
|
Homo Deus
De mensheid heeft honger, oorlog en ziektes grotendeels overwonnen en is op zoek naar nieuwe doelen waarvan onsterfelijkheid bovenaan de lijst staat. Dit boek beschrijft op een zeer open en toegankelijke manier hoe de mensheid zijn huidige status heeft bereikt en welke opties we richting de toekomst hebben gegeven de technologische ontwikkelingen welke in het verschiet liggen. Alhoewel ik waarschijnlijk geen van de mogelijke scenarios zal meemaken, is het zeker stof tot nadenken. Humanity mostly overcame famin, war and diseases and is looking for new goals of which immortality is on top of the list. This book describes in a very open and accessible way how humanity reached its current state and which options there are towards our future given the technological advances that are expected in the near future. Although I probably won't live to see any of the depicted scenarios, it is definitely food for thought. |
|
Robustness Principle (aka Postel's law)
Postel heeft in het kader van internet RFC-760 een statement gedaan: Be conservative in what you sent, be liberal in what you accept. Ik gebruik dit concept erg vaak op momenten waar software met fouten moet omgaan. Bij voorkeur wil ik eindgebruikers zo min mogelijk lastig vallen met fouten. In plaats van een programma af te breken of botweg een error tonen, kan een foutsituatie worden weggemoffeld door geleidelijk functionaliteit te verminderen. Postel made a statement in internet RFC-760 that became famous: Be conservative in what you sent, be liberal in what you accept. I use this concept regularly at moment where software deals with failure. Instead of just aborting a program or bluntly reporting a failure, where possible, hide failures by graceful degradation. |
|
RAII
Ik ken het concept al heel lang, maar het is veel later pas echt tot me doorgedrongen. Zorg dat als je een resource alloceert, alles in-place wordt gezet om de resource op te ruimen als je er klaar mee bent. En hiermee bedoel ik dat je de resource/geheugen gewoon 'los laat' zoals we met managed talen al lang gewend zijn. std::map, std::vector, std::shared_ptr etc. zorgen dat je een hoop hoofdpijn minder hebt. RAII voegt een zekere overhead toe in de vorm van clockcycles of geheugen, maar het komt de betrouwbaarheid van de code echter zeer ten goede. I know the concept for a long time. I only realised its potential much later. When you allocate a resource, meka sure everything is in place for releasing the resource when your done. And with this I mean that you can just 'let go' of the resource like we are used to in managed languages. std::map, std::vector, std::shared_ptr etc. take away a lot of potential headaches. RAII adds some overhead in terms of clockcycles and memory footprint, but it does add to reliability of the code. |
|
Design of everyday things - Donald Norman
Ik heb thuis een kookplaat met 4 kookpitten en daaronder 4 knoppen. De linkse knoppen zijn voor de linkerpitten, de rechtse knoppen zijn voor de rechterpitten - dat is intuitief. Maar van de 2 linkse knoppen welke is voor de bovenste en welke voor de onderste? Dit is een van de vele voorbeelden uit het boek welke erg herkenbaar was. Ik vond het een enorm inspirerend boek. At home I have a stove with 4 burners and below that 4 knobs. The left knobs are for the left burners, the right knobs for the right burners - that's intuitive. But of the left 2 knobs, which is the top and which is the bottom burner? This is one of the many examples from this book that were very recognisable. I found this a very inspiring book. |
|
There are only two hard problems in Computer Science;
cache invalidation naming things - Phil Karlton In gedistribueerde systemen is cache altijd een bron van ellende. Bij een recente opdracht werd dat weer eens bevestigd. Een collega vond daarop deze quote. In distributed systems cache is always a source of troubles. This was yet again confirmed in a recent task assigned to me. A college found this quote. |
|
The Expert
Filmpje over een project betreffende 7 loodrechte lijnen.
Short movie on a project about 7 perpendicular lines.
|
|
Shepard tones
Het typische tekenfilm geluid van het alsmaar neerstortende vliegtuig is me vaak opgevallen. Maar ik heb daar verder nooit aandacht aan besteed. Totdat ik tijdens een bezoekje aan Nemo tegen de uitleg aanliep. I often noticed the typical cartoon sound of the ever-crashing plane, but never paid much attention to it. Until I visited Nemo and stumbled upon the explanation. |
|
Screaming Architecture
Het deed mij denken aan de 'eendentest'. Ik vind het een erg mooie manier om te duiden dat, als een architectuur/design aansluiten bij algemeen aanvaarde concepten en design patterns, het makkelijker wordt begrepen door anderen. It reminded me of the 'duck-test'. I find it a very elegant way to express that if an architecture/design matches up with generally accepted concepts and design patterns, it becomes easier for others to undestand. |
|
Strategies for Real-Time System Specification
Hatley & Pirbhai. De ontwerp methode met o.a. de bekende bollen en pijlen om systemen functioneel te beschrijven. Bijna door iedereen intuitief te volgen, maar tegenwoordig in het UML tijdperk niet meer erg populair. Ik ben er bedreven in geraakt tijdens mijn ASML periode. Ik vind het door het in/uit zoomen nog steeds zeer nuttig gereedschap om complexe problemen op te splitsen in te behappen componenten. Hatley & Pirbhai. The design method with the well known spheres and arrows to functionally describe systems. Almost anyone can intuitively follow it, but it fell into disgrace with the rise of UML. I got experienced with it during my ASML period. I think that the functional zooming in/out is still a very useful tool to split complex problems into manageable ones. |
|
'Mand'
Erg leuk om duidelijk te maken als mensen te lang van stof zijn... For the dutch speaking...very funny short movie for when people talk too much. |
|
3D printers
Een werkelijk revolutionaire techniek welke iedereen in staat stelt om willekeurig complexe tastbare objecten te maken. Ik ben sinds een tijdje de gelukkige bezitter van zo'n printer. En ik ontdekte dat originaliteit en het omzetten ervan in 3D modellen een erg tijdrovende bezigheid is. A truly revolutionary technology that allows anyone to create arbitrary complex objects. Since a while I am the lucky owner of such a printer. And I discovered that originality and converting it into a 3D mode is a very time-consuming activity. |
|
Multitasking
Toen ik in mijn begin jaren, komende vanaf DOS, op Unix systemen het multitasking ontdekte op Unix was ik overdonderd en het opende een wereld aan nieuwe mogelijkheden. Ik heb daarna de poor-mans variant cooperative multitasking vaak toegepast voor DOS applicaties tot Windows95 het native beschikbaar stelde.
When in my early years, coming from DOS, I discovered multitasking on Unix I was overwhelmed and it opened an entirely new world of possibilities. After that I often used the poor-mans variant cooperative multitasking for DOS applications until Windows95 natively offered real multitasking.
|
|
CleanCoder
Erg vermakelijke video reeks over software development van coding tot architectuur van Robert Martin aka 'Uncle Bob'. Als ervaren software ontwikkelaar doe je (ik) vaak dingen 'uit ervaring' zonder dat je daar direct een reden voor kunt formuleren. Uncle Bob weet al deze zaken geweldig te verwoorden en te beargumenteren. Very enjoyable video series on software development from coding to architecture by Robert Martin aka 'Uncle Bob'. As a skilled software developer we often do things 'out of habit' without and are often not able to express why we do this way. Uncle Bob has arguments for all these situations and expresses and illustrates them wonderfully. |
|
Shiny Object Syndrome (SOS)
Je begint ergens aan, maar voordat het klaar is zie je al iets wat beter of mooier is. Schijnbaar hebben veel bedrijven hier last van. Ik herken het zelf voornamelijk in mijn hobby-projecten waar ik vol enthousiasme aan iets begin en na de proof-of-concept fase al snel de drive verlies om het af te maken omdat er alweer iets uitdagenders voorbij komt. You start on something but before its done something better pops up. Appearantly a lot of companies suffer from this. I mostly recognize it from my hobby projects that I start full of enthousiasm and loose interest after the proof-of-concept phase because something new and more challending comes by. |
|
Raytracing
De huidige 3D render technologien zijn allemaal gebaseerd op rendering van scanlines over een set polygonen. Lang daarvoor was er al het concept van het recursieve ray-tracing. Een erg simpele techniek welke de lichtstralen vanuit het oog door iedere
pixel in het scherm back-traced naar de virtuele objecten in de computer. Allerlei visuele effecten zoals spiegelingen, breking, filtering zijn met ray-tracing programmeer-technisch nagenoeg gratis.
The current 3D rendering technologies are al based on rendering scanlines over a set of polygons. Long before, there was already the concept of recursive ray-tracing. A very ''simple' technology that traces rays of light from the eye through each pixel
on the screen back to the virtual objects in the computer. All sorts of visual effects like reflection, refraction, filtering are programming-wise almost for free with raytracing.
|
|
Principle of least Astonishment
Als je een gebruiker iets voorschoteld waarvan de eerste reactie een wazige blik of WTF! is, dan zit er iets niet goed. Ik denk dat je veel van deze situaties kunt voorkomen door de 'eat you own dogfood'-test. If you present something to a user and the first reaction is a vague stare or a WTF, then something is wrong witht he design. I think that a lot of these situations can be prevented with the 'eat you own dogfood'-test. |
|
Sound synthesis
Altijd al een geweldig onderwerp gevonden hoe digitaal geluid te genereren, met filters, envelope generators etc. Net als met 3D printing, is dit ook een erg creatief medium met onbeperkte mogelijkheden. Ooit begonnen aan een digitale synthesizer, tot proof-of-concept fase werd bereikt... staat nog op de todo lijst. I have always found it a wonderful subject to digitally generate sound using filter, envelope generators etc. Just as 3D printing, this is also a very creative medium with unlimited possibilities. Once started on a digital synthesizer until proof-of-concept phase was reached...still on the todo list. |
|
Virtual Machines
Ik heb vroeger zelf een VIC-20 emulator op de PC geschreven. Een computer binnen een computer! Alhoewel het doel voor mij anders was, gaf het wel een klein inkijkje in de wereld van virtualisatie en vooral ook de interactie met de buitenwereld.
In the early days I created a VIC-20 emulator on the PC. A computer within a computer! Although the goal was different at the time, it did already give some insights into the world of virtualization en especially the interaction with the outside world.
|