## React Async package

Spreker: Gert Hengeveld
 
Door: Mitchell Izelaar

De meeste ontwikkelaars gebruiken packages van andere ontwikkelaars. 
Het is ontzettend handig dat je code van een ander kan gebruiken, dit scheelt veel tijd en is vaak makkelijk om te doen. 
Alleen sta je er vaak niet bij stil dat de andere ontwikkelaar veel tijd steekt in zijn package. 
Gert Hengeveld legt in zijn talk globaal uit wat er bij komt kijken om een package te maken, en waar hij tegen aan liep bij het maken van zijn React Async package.

Tijdens het maken van de package moet je al rekening houden met veel diverse scenarios waar je zelf misschien niet aan gedacht had. 
Zo moest Gert ook rekening houden met diverse smaken van React, denk aan React Native bijvoorbeeld.
Daarnaast staat React ook niet stil, dus elke keer als er een nieuwe versie van React komt moet hij ervoor zorgen dat zijn package gewoon werkt.
Gert vond het zelf ook erg belangrijk dat zijn package backwards compatible is. 

Om ervoor te zorgen dat het testen, bij voorbeeld een nieuwe versie van React, niet al te veel tijd kost is zijn package 100% getest. 
Hiervoor gebruikt hij Jest. 100% code coverage heeft nog meer voordelen namelijk dat als andere ontwikkelaars een pull request maken voor React Async dat hij direct kan zien of de tests nog werken.
Is dat niet het geval dan hoeft hij niet eens naar de pull request te kijken, wat veel tijd scheelt. Daarnaast geeft 100% code coverage ook meer geloofwaardigheid.
Bij Github zie je namelijk badges staan met onder andere de de code coverage, grootte, licence etc. Dit valt erg op en wordt door veel ontwikkelaar meegenomen in de keus of ze de package kan gebruiken.
Uiteindelijk is het natuurlijk het doel dat ontwikkelaars jou package gaan gebruiken. Wat daarin ook bijdraagt is goede documentatie. Daarom heeft Gert een uitgebreide documentatie geschreven inclusief veel examples.

Het was interessant om te zien hoeveel tijd en moeite erin gaat zitten om een package te maken en te onderhouden. 
Dus in plaats van het voor lief nemen dat er zoveel packages zijn is het misschien eens leuk om zelf bij te dragen aan een package of er zelf een te maken!


## The state of Web Components (with a bit of React)

Spreker: Pieter van Drost
 
Door: Tijmen van den Bos

Pieter van Dorst was de tweede spreker van de avond met zijn presentatie “The state of Web Components (with a bit of React)”. Hij is een Full stack JavaScript developer werkende bij Passionate People en heeft onder andere gewerkt aan de Web Components library van ING. In zijn talk begint Pieter met een korte geschiedenisles om ons zo mee te nemen naar de huidige staat en de toekomst van Web Components.

Voor iedereen die denkt “Wat zijn Web Components eigenlijk?” heeft de MDN web docs een mooi stukje uitleg geschreven.

“Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.”[1]


Als dat wat abstract is kan je het ook zien als een soort docker container voor html, css en JavaScript code die in de browser draait. Web components zijn bedoelt om het onderhouden en hergebruiken van de elementen waaruit website opgebouwd zijn gemakkelijker te maken. Het mooiste aan Web Components is dat bijna alle moderne browsers ze out of the box ondersteunen.

Nu we een beeld hebben van wat Web Components zijn, kunnen we een kijken naar hoe ze zijn ontstaan. Hiervoor moeten we terug naar 2011, de tijd dat Angular JS nog maar een jaar bestond en de meeste website geschreven waren in een combinatie van html, css en misschien wat JavaScript. Deze combinatie was prima voor statische content, maar leverde een hoop ongewenste complexiteit op voor de meer dynamische website. In deze periode kwam Alex Russell met een aantal nieuwe ideeën over de toekomst van het web, welke hij op de Frontiers Conference 2011 presenteerde in de talk “Web Components and Model Driven Views”[2]. Hij besprak hierin de basis van wat nu de Web Component standaard is.

Het duurde tot 2013 voor de release van Polymer, een web component library van Google. Deze library gaf ons de mogelijkheid om zelf met Web Components aan de slag te gaan. Maar net zoals veel nieuwe technieken was Polymer niet perfect. Zo hadden browsers nog geen ingebouwde ondersteuning voor Web Components en konden test tools slecht omgaan met de shadow DOM. De shadow DOM is een ingekapselde DOM in de normale DOM welke intergraal onderdeel is van de web component standaard.

Sinds de release van Polymer is er een hoop veranderd. Zo heeft Firefox, in oktober 2018, als eerste browser ondersteuning voor web componenten toegevoegd wat libraries zoals Polymer overbodig maakt. De meeste grote browsers hebben het voorbeeld van Firefox opgevolgd door ook ondersteuning toe te voegen. De enige uitzondering hierop is Microsoft Edge waar ze op het moment van schrijven hard aan het werken zijn om over te stappen naar Chromium.

## Hoe werken Web Components?
Met deze korte geschiedenisles kunnen we eindelijk beginnen met een korte programmeer oefening. Hiervoor gaan we een bestaande open source web component toevoegen aan een website waar je momenteel aan werkt.

Als eerste kiezen we uit een van de vele open source libraries op open-wc.org[3] een mooi component kiezen. Voor deze oefening gebruik ik het amp.dev youtube component[4]. Hierna moeten we de browser laten weten waar de source van het web component dat we willen tonen staat. Voeg hiervoor de volgende twee regels code toe aan de header van je website.

`<script async src="https://cdn.ampproject.org/v0.js"></script>`
`<script async custom-element="amp-youtube" src=“https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>`



Voeg hierna de volgende regel toe aan de body, herlaad de pagina en je kan genieten van een prachtige YouTube video.

`<amp-youtube width="480" height="270" layout="responsive" data-videoid=“dQw4w9WgXcQ"></amp-youtube>`



## Hoe maak ik zelf een Web Component?
Nu je zelf een Web Component heb toegevoegd zit je vast en zeker te popelen om er een te maken. Helaas moet ik, om deze blog bondig te houden, je hiervoor doorsturen naar de Mozilla tutorials pagina[5] waar ze het veel beter uitleggen dan ik hier ooit zou kunnen doen. Wat ik wel kan bespreken zijn de vier specificaties die nodig zijn om een Web Component ta maken, namelijk:

1.	Custom Elements
Custom elements zijn bijna hetzelfde als de bekende html elementen, zoals “table” of “div”. Het grote verschil is dat je ze volledig kan aanpassen met een unieke naam en een berg aan functionaliteiten. Om ervoor te zorgen dat je browser jou element herkent moet elk Web Component de volgende regel code bevatten.

`customElements.define(name, element)`


De “name” is de naam van de element selector, b.v. ‘awesome-table’, en het element is de ES class, met alle functionaliteit en de HTML template, die je wil blootstellen.

2.	HTML Template
De HTML template wordt samen met alle andere code blootgesteld via de ES class door middel van de “customElements.define()” code. In tegenstelling tot hoe HTML normaal gerenderd wordt, namelijk direct, rendered de HTML code van een Web Component pas wanneer wij dat willen. Dit geeft ons veel meer controle over wanneer we iets willen weergeven of verbergen.

3.	Shadow DOM
De shadow DOM is al eerder te sprake gekomen, maar het kan geen kwaad om de beschrijving nog een keer te herhalen. De shadow DOM is net zoals de normale DOM maar dan volledig ingekapseld. Dit zorgt ervoor dat de code in de Web Component zit geen effect heeft op de rest van de website, en dus ook geen onverwachte bijwerkingen heeft.

4.	ES modules
ES modules zijn technisch gezien geen onderdeel van de Web Components zelf, maar wel verdomt handig om ze toe te voegen aan je website. Kijk maar naar het YouTube voorbeeld.


Waar kruizen Web Components en frameworks elkaar?
De volgende vraag die je kan hebben is “Waarom zou ik Web Components gebruiken als Angular, Vue of React het zelfde kan doen?”. Dit is wat het team achter React erover te zeggen heeft.

“React and Web Components are built to solve different problems. Web Components provide strong encapsulation for reusable components, while React provides a declarative library that keeps the DOM in sync with your data. The two goals are complementary. As a developer, you are free to use React in your Web Components, or to use Web Components in React, or both.”[6]


Deze quote stipt twee interessante punten aan over het combineren van Web Componenten en frameworks. Namelijk dat ze allebei andere problemen oplossen en dat er meerdere manieren zijn om ze te combineren.

Laten we eerst kijken naar de verschillende problemen die Web Components en frameworks oplossen. Terugkijkend naar wat we tot nu toe geleerd hebben is het redelijk duidelijk waarom we Web Components willen gebruiken, namelijk de verschillende browsers ze out of the box ondersteunen en het heel gemakkelijk is om ze te hergebruiken.

De vraag is dus meer waarom we ze willen gebruiken in plaats van de oplossingen die frameworks zoals Angular, React en Vue bieden? De voornaamste reden hiervoor is dat de verschillende frameworks de Web Components imiteren en je dus niet de voordelen ervan heb. Je bent dus nog steeds afhankelijk van de framework specifieke code om het component te laten werken. En hoe je het ook went of keert, frameworks komen en gaan terwijl de onderliggende technieken, zoals JavaScript, nog steeds gebruikt worden.

Helaas werken nog niet alle frameworks lekker samen met Web Components. Dit is wat Pieter erover te zeggen had.

“We aren’t there yet […], it’s pretty much the end goal we are striving to.”[7]


Waarschijnlijk gaan we in de komende jaren een verschuiving zien in het front-end landschap waar we langzaam overstappen naar het gebruik van Web Components in plaats van de framework specifieke componenten. Tot die tijd moeten we ze zelfs maar moeten combineren.

Het tweede gedeelte van de quote gaat over de verschillende manieren waarop we Web Components kunnen combineren met frameworks. Bij het gebruik van Web Components in een framework kan je vast wel iets bedenken. Let er wel op dat er haken en ogen aan het gebruik van Web Components in frameworks kunnen zitten. Zo is de data binding in React zo opgezet dat het alles als String objecten overzet. Hierdoor moeten complexe datastructuren handmatig geparset worden, wat de Web Components een stuk complexer maakt. Controleer voor je begint met het toevoegen van Web Componenten aan een framework eerst of ze goed samen werken op https://custom-elements-everywhere.com/.

Naast Web Components in een framework gebruiken kan je het ook omdraaien en een framework in een Web Component gebruiken. Pas wel op dat je niet teveel verschillende frameworks, of versies van frameworks, tegelijkertijd gaat gebruiken. Alle verschillende versies moeten namelijk als dependency opgenomen worden wat een hoop extra complexiteit met zich meebrengt. Iets wat we juist proberen op te lossen met het gebruik van Web Components.


Samenvatting
Om deze blog af te sluiten heb ik nog een mooie opsomming van wat we geleerd hebben. Het belangrijkste om te herinneren is dat je met Web Components zonder dependencies herbruikbare en onderhoudsarme componenten voor je website kan maken. Hou er rekening mee dat het geen wondermiddel is dat al onze problemen oplost, maar het help wel om een beter front-end ecosysteem te creëren. Als allerlaatste nog kort de voor en nadelen van Web Components.

Pro’s:
-	Geen dependencies nodig door de ingebouwde ondersteuning in browsers.
-	Herbruikbaarheid van Web Componenten verminderd de vendor lock in.
-	Toegang tot een groeiende bibliotheek aan bestaande Web Components. 
-	Web Componenten zijn ontworpen om super snel te zijn.

Con’s:
-	Testen is nog steeds moeilijk door de shadow DOM.
-	Het combineren van Web Components en frameworks kan lijden tot extra overhead en complexiteit als je niet oppast.
-	Ondersteuning voor oude browsers is niet geweldig, ook niet met polyfills.

1.	MDN web docs, Web Component documentation, https://developer.mozilla.org/en-US/docs/Web/Web_Components
2.	Web Components and Model Driven Views by Alex Russell, (2011), https://fronteers.nl/congres/2011/sessions/web-components-and-model-driven-views-alex-russell
3.	List of open source web component libraries, https://open-wc.org/faq/component-libraries.html
4.	Amp.dev youtube web component, https://amp.dev/documentation/components/amp-youtube?format=websites
5.	Mozilla web components documentation, https://developer.mozilla.org/en-US/docs/Web/Web_Components#Tutorials
6.	Statement from React about web components, https://reactjs.org/docs/web-components.html
7.	Quote Pieter van Dorst about React and web components, (2019), https://youtu.be/MIaKV-zM1Lg?t=5944

Velen uit Rotterdam en omstreken waren weer  uitgelopen voor een interessante Meetup.  Voor het eerst in de geschiedenis van Developers.nl twee talks binnen één TechNight, ditmaal ging het over 'React Async package' en 'The State of Web Components.

TechNight: Webcomponenten met React en meer

Amer Grgic was al vroeg van de partij. Terwijl hij aan het opwarmen was, genoten de inmiddels toegestroomde gasten van de, bij Technights traditionele, Chinese maaltijd en een drankje.

Daarna was het tijd voor de presentatie. Alexa is dus de voice assistant van Amazon. Vergelijkbaar met Siri, Cortana van Apple respectievelijk Microsoft en de voice assistant van Google, die je aanspreekt met 'Hey Google'.

Alexa is nog niet zo bekend in Nederland omdat ze nog geen Nederlands verstaat. In Engelstalige landen hebben de Echo devices waarop Alexa draait een veel groter marktaandeel. Veel fabrikanten van andere 'slimme' apparaten werken samen met Alexa en hun devices kunnen ermee bestuurd worden.

Dit doen die fabrikanten door zogenaamde 'skills' te maken voor hun gadget. Dit zijn spraakcommando's waarnaar Alexa luistert en die het betreffende apparaat aansturen (via een api).

Er is al een library van zo'n 30000 skills, die je naar believen kunt installeren voor je Alexa. De brains van dit systeem draaien natuurlijk in de 'cloud'. Dit is bij Amazon uiteraard Amazon Web Services (AWS), een van de eerste publieke cloud aanbieders.

Wat Amer deze avond aan ons liet zien is hoe je zelf zo'n skill maakt. AWS heeft hiervoor een aantal tools beschikbaar.

Om een skill te bouwen, maak je een skill project. Dit bestaat uit een groot aantal config bestanden en code, naar keuze javascript of python. Je kunt de gebouwde skill uploaden naar AWS en met je eigen Echo direct testen.

![developing](https://developers.nl/uploads/img/image/4fotoMR.jpeg)

Het gaat hier uiteindelijk vooral om het maken van bepaalde commando's, die als je ze aan Alexa geeft bijvoorbeeld api calls aanroepen. De api responses kunnen weer in spraak omgezet worden. In een skill bundel je een aantal van die commando's. Door Alexa aan te spreken met "Alexa, say hello from demo", wordt van de 'demo' skill de code achter de 'say hello' phrase uitgevoerd. Zo hou je per skill een eigen namespace, waardoor je geen problemen krijgt met al bestaande commando's of commando's uit andere skills.

Amer had op kantoor vaak collega's die de status van hun geautomatiseerde mailings wilde weten. Hij logde dan in op een dashboard en somde de belangrijkste gegevens op. Hiervoor heeft een skill gemaakt. De collega's kunnen het nu aan Alexa vragen in plaats van hem.

![publiek](https://developers.nl/uploads/img/image/6fotoMR.jpeg)

Hij liet ook nog zien hoe je door een aantal andere AWS services te combineren bijvoorbeeld Alexa kon laten zeggen of er een beroemdheid herkend werd in een image bestand dat je in een map (een s3 bucket) hebt gezet.

Er kwamen uit de zaal nog vragen of het ook mogelijk is om Alexa conversaties te laten voeren. Dit zit niet standaard in skills, maar door verschillende services te combineren, zou er wel e.e.a. op dat vlak mogelijk zijn.

![napraten](https://developers.nl/uploads/img/image/8fotoMR.jpeg)

Thuis maar eens kijken wat zo'n Echo kost... Je kunt er zeker leuke dingen mee maken. Maar voordat we allen huiswaarts keerden, was er natuurlijk nog tijd om wat na te praten onder het genot van een drankje en knabbeltje.

Woensdagavond 22 mei was het weer tijd voor de Technight bij Developers. Dit keer "Master Alexa". De titel leek even te hinten op een soort van gender neutrale SM mistress..., maar de ingewijden weten natuurlijk dat het hier gaat over de voice assistant van Amazon.

TechNight: Master Alexa

At the time of the talk I was reading up on the many resources available on internet about how best and where to get started with Kubernetes. This talk unravelled a vital aspect about Kubernetes and the whole containerization world of web application. Jan kicked off the session by asking – by a show of hands, anyone who had experimented with Kubernetes or Docker – of course my hand shot up on the Docker part. 
 
Immediately, I became interested in the next question he posed to the gathering. Why Containers? You are probably already guessing how many hands had been paraded on the Kubernetes experimentation – just a few!! For someone in the state of mind like I was at the time – this set home. He told about a Pet and Cattle analogy – many cattle lovers won’t love this one however he simply meant to say that if your pet for any reason dies, you might want to make a special commemoration to the funeral than a farmer with thousands of cattle who won’t care if one cattle dies. If we are to apply this to containerization of application, we will observe a surge of management control and consistency across your development line and as if that is not enough your continuous delivery trail will bolster development and productivity while keeping costs low. 
 
Nevertheless, achieving the core benefits of containers – in this case Kubernetes he recapped of the three unsophisticated rules. First and foremost, stick to stateless – keeping our application to no persistent storage like it was intended. Additionally, running a single process instance on a node and finally, he warned strongly against running an application as a root. This is critical when designing a secure system. Whether malicious or because of bugs, a process may have unexpected consequences at runtime. One of the best ways to protect yourself against any unexpected access is to grant only the minimum amount of privileges necessary to a process to run. All having been said, he added that very few developers stick to these rules for a simple reason of trying to force result, or to put it plainly - to fix a square block in a round hole!! However, thinking about it – what are some of the aspects that Kubernetes will NOT do for you(us). The system will not limit the types of applications supported, nor will it deploy the source code and of course it won’t build your application!! Furthermore, Kubernetes will NOT dictate logging, monitoring or alert you of any errors, nor provide application level services and it won’t configure a language or system. These are all responsibilities a developer will devise ways to include in the whole setup.
 
Digging a little deeper, given the different kinds of containers they all seem to have the same setup. In this next section I will deliberate on a few terms explained in the session to remember about Kubernetes. A pod, being a group of one or more containers (could be Docker containers) with a shared storage or network. This is the smallest and simplest unit in the Kubernetes object model. Pods provide a self-healing capability at cluster scope – readiness nature that waits for redundancy to give traffic whereas the liveliness nature that will restarts a pod. Kubernetes pods are mortal, while their IP addresses cannot be relied upon to be stable overtime and this creates a problem where a service or Services determine a policy by which to access pods. This bring us to an Ingress; this is simply an object that manages external access to services in a cluster. It can provide load balancing or load distribution of the traffic. Controllers maintain a stable set of pods running at a given time and are classified in three different modes namely; - Deployment, Daemon and Replication. A common mistake a developer does while deploying is to tag their versions with ‘latest’, as developers this in a total no DO! Additional deployment tips are as follows – simple minimal configurations will make errors less likely, furthermore we were advised to declare unique values with in a deployment process as well as staying away from naked pods simply because they will not be rescheduled in the event of a node failure. The best way to separate a set of pods is to namespace them. Kubernetes starts with two initial namespaces namely, default and kube-system. Why namespaces? Probably you are already guessing but this provides us (you) with the ability to create a role-based access (RBAC) security. It’s a is a method of regulating access to computer or network resources based on the roles of individual users within an enterprise. 
 
Finally, Jan suggested Google for Kubernetes given the amount of time setting up a Kubernetes cluster. He exaggerated how quick and simple it is – indicating only 5 clicks to have one already setup.

The third edition of the Developers.nl TechNight of 2019 was presented by Jan Stomphorst, an ICT Architect at ACC IT. His talk concerning Auto Scaling Kubernetes was practically inclined but also very intuitively drawn to this day and age of cloud computing.

Technight: Spelen met Kubernetes

Additionally, Marc Dekker, one of our Java team members, will give a practically oriented talk by the end this year that will include a life coding session to show how our ideas on Code Quality can be implemented. I hope you all will be able to attend this meeting. 

Reasons for bad code and a new approach to improve it

When starting the talk, Jarra argues that the foremost reason we produce bad code is haste. We as developers are always under pressure to deliver changes ASAP, within an often too short-set time period, preferably handling both new features and any last minute bug fixes at the same time. This time pressure often forces developers to deviate from standard practices that take time to implement. If the standard practices of enforcing code quality so that our fellow developers can maintain and elaborate on our code are not sufficient to guarantee quality in times of stress, what can we do to ensure understandable code?

Jarra proposes to go back to the fundamentals of language for information transfer. That is, how to use the written word to best communicate your intentions. How to adequately transfer meaning, purpose and goals in the code itself and its structure. IMHO, a completely different perspective than another list of “best practices” that only take in additional time and stress.

Chunking theory, mental models and their relation to understanding complex systems

Next in the presentation was a quick test of how many words the viewers could remember over a short period of time. It’s purpose was to show the limited capacity of our short-term (working) memory; that is, how many chunks of information we can keep retained simultaneously. For most people this number lies between 6 and 9 (Miller, 1956)[1].  Interestingly, we had several viewers that indicated that they had written down more than 9 of the words. An exceptional performance if correct! Chunking theory in psychology states that chunks are coherent elements that can be grouped together based on an association. For instance; Chase and Simon (1973)[2] and later Gobet, Retschitzki and de Voogt (2004)[3] showed that chunking could explain several phenomena linked to expertise in chess. Following a brief exposure to pieces on a chess board, skilled chess players were able to encode and recall much larger chunks than novice chess players. However, this effect is mediated by specific knowledge of the rules of chess; when pieces were distributed randomly (including scenarios that were not common or allowed in real games), the difference in chunk size between skilled and novice chess players was significantly reduced. Removing the common ground between the elements, that is their association to the rules, removed the possibility of using chunking to retain more information.

This capacity limit of our working memory makes it difficult and slow to understand highly complex systems because they more often than not consist of more than 7 cohesive pieces of information that can be interrelated in different ways. An example of a system that proved to be too difficult to maintain and bug fix because of its size and complexity was the software implemented in Toyota cars. Toyota modern cars started accelerating without the gas being pressed, causing accidents. Various experts looked at the code but it was such a mess they could not explain why it happened. But more importantly, they could also not rule out that the incidents were not created by the software. There was too much badly documented unreadable complex code to oversee all its objects and their relations, and so no way to predict the resulting effect on the cars’ driving performance.

Over time such large and complex code systems start to show similarities to the dynamics of natural systems rather mathematical ones (Samuel Arbesman, 2016). That is, extensions and added dependencies will not only be improvements on the current code, but also be adaptations to a changing input context. The more interdependencies are added, the less transparent and predictable the output of a system will be given the input. This is because we can only oversee a limited amount of relationships between the system’s elements.

The way information is presented influences our representation of it

Jarra proceeds on discussing an indian ritual that was last performed in the 70's. Historical priest were constantly rehearsing and perfecting their rituals as it’s success depended on the experience and expertise of the priest performing the ritual. When the first rituals were put onto paper our relationship to god, and to the other participants or observers, was changed. Writing down the ritual, disconnects the delivered content from the body language and identity of the performer and thus removes a significant amount of the information from the message. Script as medium influences the perceived reliability and validity of it’s content. Since the content is less detailed and its source unclear, people tend to perceive written texts as more accurate and more official. It enables the belief in singular, disembodied, authoritative forms of being such as God and the psyche (Karman). It also causes us to interpret cause and effect mainly in a linear way. These days, information is distributed across networks, presented using multimedia, and with a less distinct boundary between personal and public information. This modern way of storing, presenting and experiencing information, will again produces a shift in how people perceive and process reality. The current receiving of information and learning is again more immersive, more similar to the verbally presented rituals than the written word. As a consequence, we can be expected to create a less linear, more distributed and more detailed construct of reality, but also a change in attitude in which we accept that we cannot possibly process all information available on a topic and find more adequate ways to deal with this. In a first attempt, Brian Rotman (2008)[5] argues that we should treat the current vast and complex computer systems such as that of Toyota cars more like an anthropologist; studying the system like it is a black box and describing it’s dynamics simply by which input results in what output. Preferably using statistics and mathematical models.

As an illustration of successfully treating a complex and buggy system as a blackbox to adequately explain and predict its behaviour, Jarra moves on to discussing the story of a Soviet army officer, Lt. Col. Stanislav Petrov. On September 26, 1983, amidst the cold war, this Soviet officer detected 5 missiles on his radar screen. All incoming from the U.S.A.. Immediately responding and reporting their detection to higher up command would -at that time- have had a probability of resulting in a global nuclear war with casualties up to in the hundreds of millions. The Soviet protocol would leave no room for double-checking the system, nor negotiations with the US. More importantly, the staff had experienced false alarms for missiles the months before, showing that the system might not be 100% reliable. This is why Stanislav hesitated and waited to respond until he had more information. That is, he and the rest of the staff decide to wait and see whether more information would pop up on the screens or be relayed to them by phone and decide later. Nothing happened in three minutes time and the staff concluded that the missiles on the screen were indeed glitches. False alarms. After investigation, the system was shown to mistaken the sun’s reflection off clouds as missiles. For preventing these deaths Stanislav got honored at the United Nations and received the Dresden Peace Prize. This example not only shows why it is important for a system to be both accurate and reliable, but also how having info on these issues is necessary to interpret its behaviour and predict what actions to take. Improving code quality thus not only encompasses the code itself but also taking proper care of documentation about its behaviour and its communication to end users. 

However, to be properly able to do so, the creator of the system needs to fully understand the problem that gave rise to it and have the full structure of its solution in code available in his or her head (Paul Graham, 2009). This is more doable for complex systems if the source code intuitively explains itself and human capacity to oversee a complex system is taken into account. How do we achieve this?

Applying logic to this question suggests two possible perspectives… Either we make the system simpler by forgetting parts of it, that is, abstracting the gist of the system and forgetting about non important details. Or we can become cleverer so that the things that first seemed incomprehensible become clear to us (Eugenia Cheng, 2018)[7]. Jarra approach discussed below that is based on combing OOP, functional programming concepts and chunking theory from psychology implements both.

Creating intuitive systems that are easy to comprehend and oversee

Composition
Composition breaks down a vast complex system in its meaningful components so that it becomes easier to understand and oversee. Each composite has a single purpose, and their combined interaction produces the wanted behaviour. Composition is very intuitive, as breaking down information in parts, processing these separately and later combining the results, is the way the brain itself deals with the information coming in from the different senses when constructing a percept of the external world. Either to simply perceive, or to also interact with it. Composition is also inline with the way information is currently distributed over the internet, and the way we search and find, interact and interpret this information when problem-solving. For instance, when finding the most optimal way to code a solution, we consult different web sources, combine their suggested solutions into one and test out whether or not this works for our situation.

Object Oriented Programming
One way to implement composition, is ofcourse Object Oriented Programming, first proposed by Alan Kay in 1966, in which the system is represented by groups of instantiated classes or nodes that each have a single identity and purpose, and communicate with one another to create the information flow that represents the business process for which the system was designed. The nodes can inherit each other’s characteristics and actions, forming categories within a cluster. Alan Kay has a background in Biology, and the way he designed OOP closely resembles the way neural networks and neurons process information. 

In OOP the content of each node is shielded, so that you do not have to worry about what it is inside the object (Alan Kay). The overall functionality of OOP systems is often defined more by the messaging between it’s objects, than within the elements themselves. These should be easily substitutable (low coupling), but changing the messaging will result in big changes in the overall functioning of the system (as a result of high cohesion, Donella Meadows, 2008)[8]. Large systems lacking in (proper) cohesion will have a high information flow complexity as they are likely to have more connections due to a higher amount of components performing similar but slightly different operations (Sallie Henry and Dennis Kafura, 1981)[9]. As a result, such systems will be harder to understand and maintain because of the sheer number of information flows (Eric Elliott, 2019). This is problematic because the number of flows often exceeds our mental capacity to process the chunks simultaneously (plusminus 7, George Miller, 1957).

Jarra argues we should strictly adhere to OOP principles, creating applications with high cohesion but low coupling, and each instantiation serving only one single purpose, when implementing a system. This gets more important as the size of the system increases, as information flow complexity will have a bigger impact on our understanding if we near the limits of our capacity to chunk information when building a mental model of the system.

Pure functions in monads
A way to reduce information flow complexity and sheer size of a system is by using pure functions when designing and implementing it. A concept borrowed from functional programming, pure functions are methods that are 100% predictable, in that they always give the same output for a given input, whatever the context may be, and produce no side effects. Pure functions produce no unexpected behaviour when called and they can be substituted by their own product. Their output should be the same regardless of the type and value of the input. Pure functions reduce information flow complexity by minimizing the  output flows and thus make the system easier to comprehend and maintain.

Pure functions can be implemented by using monads. A monad is a design pattern that allows to structure a program more generically by automating away the boilerplate code needed by the program logic. It achieves this by accepting any type of input (also null, thus reducing the number of methods needed in boilerplate code), wrapping the input into a single data type of itself, resulting in a monadic value, and processing this monadic value using a procedure that composes functions that process the data within the wrapper but again output monadic values. So instead of implementing boilerplate code into different objects, a category object is created that handles any possible input and shields the internal boilerplate code from the rest of the system. Effectively chunking the information so that the system’s size reduces and becomes easier to understand. 

Monads not only accomplish, with pure functions, what normally is done with side effects in imperative programming but they also do it with a high degree of control and type safety (Eugenio Moggi, 1989). When using pure functions in monads is not possible, side-effects effects should be isolated from function that are 100% predictable to increase transparency. 

Test Driven Design: States and Messaging by using Mock Objects
Finally, as the number of objects and dependencies between objects within the system reduces because similar functionality is encapsulated and processed by pure functions in monads, it becomes more important to test whether the monads and their connections really perform in all situations as expected. For this not only unit testing of the involved classes needs to be done, to check the different states of the objects, but also their interdependencies should be mocked and tested for correctness and reliability of the interactions and the information flow between the objects (Freeman & Pryce, 2009)[10].

Conclusion

Jarra finishes the talk by discussing a 3D fractal image and explaining that it symbolizes his ideal architecture in which all possible chunks (lines, classes, dependencies, modules, applications) are maximized on the number 7. Ensuring that both higher level and lower level order within the system takes the limits of human processing capacity into account. A nice idea.
 
![](https://developers.nl/uploads/img/image/CodeQ.jpg)

Afterword

I think we all can benefit from more intuitive code & structure as the time we can spend on documentation and knowledge transfer is severely limited. Most complex systems that I have been working on suffer from evolution through changing context, and as a large part of our work encompasses maintenance, reduced complexity for large systems will make my life a lot easier. Certainly as integration issues between systems arise.

I hope to have given Jarra’s abstract concepts more body. Thank you for taking the time to read this, if you have any questions, don’t hesitate to contact me.

1.	Miller, G. A. (1956). "The magical number seven, plus or minus two: Some limits on our capacity for processing information". Psychological Review. 63 (2): 81–97. CiteSeerX 10.1.1.308.8071. doi:10.1037/h0043158. PMID 13310704.
2.	Chase, W.G.; & Simon, H.A. (1973). Perception in chess. Cognitive Psychology, 4, 55-81.
3.	Gobet, F.; de Voogt, A.J.; & Retschitzki, J. (2004). Moves in mind: The psychology of board games. Hove, UK: Psychology Press.
4.	Arbesman, S. (2016). “Overcomplicated”. Portfolio
5.	Rotman, B. (2008). Becoming Beside Ourselves: The Alphabet, Ghosts, and Distributed Human Being. London: Duke University Press
6.	Graham, P. (2009). Hackers and Painters: Big Ideas from the Computer Age. O’Reilly Media
7.	Cheng, E. (2018). The Art of Logic. How to make sense in a world that Doesn’t. Profile books
8.	Meadows, D.H. (2008). Thinking in Systems. Chelsea Green Publishing Co.
9.	Henry, S. and Kafura. D. (1981). Software Structure Metrics Based On Information Flow IEEE Transactions on Software Engineering SE-7(5):510 - 518
10.	Steve Freeman, Nat Pryce (2009) Growing Object-Oriented Software, Guided by Tests. Addison-Wesley Professional

On February 20th 2019 Jarra Schirris gave an inspiring but abstract presentation at developers.nl on how to improve Code Quality. In this blog I will discuss Jarra’s ideas in more detail, as an hour was a bit short for him to go deeply into all of the discussed topics.

TechNight: Code Quality

Wat zijn Web Components en waarom zijn ze zo cool? Voordat we in deze materie duiken krijgen we een waarschuwing vooraf: we gaan vanavond ongezouten meningen horen. En er gaan ook lelijke dingen gezegd worden over veel gebruikte programmeertalen. Maar het is voor een goed doel, we willen toewerken naar een betere wereld.

Web components zijn web platform APIs die het mogelijk maken om HTML elementen met encapsulation in herbruikbare componenten te modelleren. De APIs maken gebruik van Custom Elements, waarmee je je eigen HTML elementen kunt definiëren, van een Shadow DOM, waarmee je jouw specifieke HTML/CSS kunt isoleren van de globale definities en HTML templates, waarmee je herbruikbare stukjes HTML kunt definiëren. Inladen van HTML imports wordt met behulp van ES Modules gedaan. Web components worden ondersteund door chrome, opera, safari, firefox en edge (met wat trucjes, edge loopt nog een beetje achter). Maar belangrijker dan dit is het om te beseffen dat web components een web standaard is.

![](https://developers.nl/uploads/img/image/Blog1.jpg)

In een stukje live coding wordt duidelijk hoe web componenten eruit zien en hoe je hier in de praktijk mee werkt. We zien het goede van web components, hoe attributen gebruikt worden om data te verzamelen en hoe events gebruikt worden om die kennis te delen. We zien het lelijke van web components, als we  proberen alles in componenten te stoppen. Dit wordt wel zo gepromoot door Google, maar is geen goed idee. En we zien het slechte, als we in een quiz geconfronteerd worden met de akelige kanten van de meest gebruikte frontend taal: Javascript. Er volgt een reeks voorbeelden van de soms bizarre en weinig intuitive manier waarop onze code wordt geïnterpreteerd.

En dat is waar ELM ten tonele verschijnt. ELM is een puur functionele, statisch getypeerde en sterk getypeerde taal die makkelijk is in het gebruik en een goede performance en robuustheid heeft. Het wordt net als typescript getranspiled naar Javascript en het belooft dat je geen runtime errors meer zult krijgen. Er volgt geen quiz, want dat zou saai zijn: ELM interpreteert onze code op een intuitive manier. In een live coding session krijgen we een voorbeeld te zien van web components gebouwd met ELM en eerlijk is eerlijk: het ziet er smooth uit. We zien de code van de eerdere quiz  https://github.com/JordyMoos/elm-quiz en we zien dat er inderdaad een compile error volgt als we een nieuwe button maar half implementeren.

![](https://developers.nl/uploads/img/image/Blog2.jpg)

De boodschap waarmee we naar huis gestuurd worden is:

<ol style="list-style-type: disc;">

<li>Klamp je niet vast aan een framework, want die gaan niet zo lang mee</li>
<li>Web Standaarden hebben een langere levensduur, dus stap over op Web Components</li>
 <li>Scheid logic en view, schrijf de logic in ELM en stop de views in Web Components</li>
    
</ol>

Jordy Moos, Senior software engineer bij ING, laat ons zien waarom WebComponents met ELM een toekomstvaste frontend oplossing zijn.

TechNight: Voeg een beetje 'static type checking' toe aan een wereld van Web Components

"Playing a game is the voluntary attempt to overcome unnecessary obstacles" - Bernard Suits

Een spel heeft een doel, deelname is vrijwillig en er moeten overbodige obstakels in zitten. Marc gebruikt Golf als perfect voorbeeld. Het doel is om een bal in een gat in de grond te laten rollen. Maar in plaats van een groot gat te maken waar de bal in kan rollen, is het gat vrij klein. Om het nog moeilijker te maken kan er tussen het beginpunt en eindpunt honderden meters aan gras, zand en water zitten. Om het af te maken is het clubhoofd, het gedeelte van een golfclub waarmee je de bal moet raken, ook nog eens lekker klein. Allemaal voorbeelden van obstakels die niet nodig waren, maar die het spel wel interessant maken.
 
Dat een spel leuk kan zijn, snappen we allemaal, tenzij je natuurlijk 
niet zo goed tegen je verlies kunt! Maar wat maakt een spel nou precies leerzaam? Marc gebruikt Professor Layton als voorbeeld van een spel waar je algoritmes leert herkennen, problemen optimaliseert en de logica van puzzels moet identificeren. Ontwikkelaars hebben voortdurend te maken met complexe logica, code optimalisatie en algoritmes. Alle bovengenoemde vaardigheden zijn dus toepasbaar! Oefening baart kunst. Hebben we daar nou echt spelletjes voor nodig? Nee natuurlijk niet. Echter versterkt het vermaak van een spel de beleving en daarmee ook de overdracht van informatie en kennis. Leren kan dus leuk zijn!

![](https://developers.nl/uploads/img/image/Game1.jpg)

Minecraft is een mooi voorbeeld van een spel waarmee met een gering aantal verschillende basisblokken een hele wereld kan worden opgebouwd. Een simpele basis en kleine producten kunnen met expertise en tijd tot grote resultaten leiden.
 
Code kan op den duur erg complex en ingewikkeld worden door constant wijzigende eisen. Mini Metro is een spel waar de speler een metronetwerk moet ontwerpen en onderhouden door steeds meer metrohaltes aan elkaar te koppelen. Doordat er steeds weer nieuwe haltes bijkomen blijkt achteraf dat een eerder gemaakte keuze toch niet zo handig was als eerst gedacht. Onderhoud is vereist om de reizigers zo snel mogelijk van A naar B te brengen. Door het inzichtelijk maken van de problemen die je kunt tegenkomen en creatief om te gaan met de middelen die je hebt, leer je verstandigere keuzes te maken die in de toekomst ook nog volstaan.

![](https://developers.nl/uploads/img/image/Game2.jpg)

Spelletjes helpen ook met softskills. Ga eens met collega’s een spel spelen in de pauze. Het liefst bordspellen, gezien we al de hele dag achter de computer zitten. Je leert elkaar beter kennen, identificeert elkaars zwakke en sterke punten en daarnaast is het gewoon leuk!

Waarom developers spelletjes moeten spelen. Spreker Marc Dekker, Senior Java ontwikkelaar binnen Developers.nl, heeft ons overtuigd dat spelletjes niet alleen leuk, maar ook heel leerzaam kunnen zijn.

De volgende meetup wordt binnenkort aangekondigd