We all write code which ends up frustrating us or our colleges sooner or later. Sometimes you copy-paste some code and don’t get around to tidying it up or you make a design decision which seems like a good idea at the time, but later turns out to be a time-consuming mistake. 

In this blog I’m going to describe two sources of frustration, with the focus on Java, when trying to change code: duplication and unnecessary coupling caused by inheritance. 

It can be very frustrating when you need to make a change and you think: “I am finished", only to find out that you need to make the same change in a dozen other places. 

When designing a system, you should always follow what is called the DRY (Don’t repeat yourself) principle: Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. 

However, this doesn’t mean every identical line of text or code is duplication. It could just be the case that the implementation happens to be identical.   

DRY is about the duplication of knowledge; it is found in:

It’s easy to forget that documentation also needs to be updated, along with the changes you make to your codebase. The only thing worse than no documentation is wrong documentation. Out-of-date documentation is very misleading and can cost you a lot of unnecessary time. 

Comments are just another form of duplication. Functions and variables with clear names do not need comments.  Comments inside of methods are a sign the method is too large and should be split into private methods, with descriptive names. 

Developers who don’t know what their colleges are building are likely to write similar code. They end up duplicating functionality which already exists.

This can only be reduced by better communication. Active and frequent communication during the daily standup, forums etc. You should read other people’s source code and documentation, either informally or during code reviews.

Finally, duplication in code. It’s best to start small. First, by locating and extracting the smaller pieces into separate methods. Then you can more easily start locating and removing the larger pieces of duplicate code. Remembering, of course, to run unit tests after each significant change, to prevent having to roll back too many changes.

Move duplication across multiple classes, to its very own class. After extraction this new class needs to be coupled to the classes using it. In Java you basically have two options:

Option 1: A “has-a” relationship. The original classes can be given an instance of the new class as a private attribute. This is also called composition or delegation, because you delegate functionality to components of a class. 

Option 2: A “is-a" relationship. The original classes can extend the new class. 

When choosing the option to implement, the most important thing to take into consideration is: Inheritance Tax. 

You need to make another change, and again you think you’re done. However, you find out you just broke the code in a dozen other places. 

Fortunately, there are several best practices when it comes to reducing unnecessary coupling. One of which is:  Don’t pay Inheritance Tax. Inheritance is a form of coupling and therefore must be avoided if unnecessary and most the time, this is the case.

Paradoxically, this is not what you have probable been taught. Using inheritance for behavioral composition and polymorphism is a common practice you find in every OOP textbook. However, in practice it has some serious disadvantages.

Firstly, you might not directly realize this, but when a class is extended it creates coupling between multiple concrete classes. Not only is a child class coupled to a parent, the parent’s parent, and so on. But also, any object which uses this child is now not only coupled to this child, but also to all the ancestors.  

Secondly, in a limited domain, it makes sense that a Car is a kind of Vehicle. However, as soon as the domain you are working in becomes more complicated and closer to reality, these models become more complex and nearly impossible to model. For example, what happens when a Car is also a kind of Asset, InsuredItem, and so on. This needs multiple inheritance, not only isn’t that possible in some programming languages, like Java, but when available you end up with complex models that end up just causing you a headache.

Instead use one of these techniques, so that you never need to use inheritance again:

Interfaces. Implementing Interfaces give us polymorphism without inheritance. These declarations don’t normally create any code and a class can implement an unlimited number. 

Delegation. By implementing a class instance as an attribute, you can hide all the unnecessary methods of the class you aren’t using. Significantly reducing its complexity. However, this comes at the cost of writing more code.

Mixins. The basic idea of a mixin is simple: you want to be able to extend classes and objects with new functionality without using inheritance. Say you have two related functions called ‘find(id)' and ‘findAll()' and you want multiple classes to be able to use these functions. But you don’t want to use inheritance and delegation adds unnecessary code. If the language you are programming in has this feature built in, it would look something like this:

// in sudo code

mixin CommonFinders {

  def find(id){ … }

  def findAll(){ … }

}

 
class AccountRecord implements BasicRecord with   CommonFinders { … }

This isn’t available in Java. However, since Java 8 we can define Interfaces with (public) default methods. This allows us to add methods with implementations to interfaces. Java 9 added the ability to use private methods in interfaces, enabling us to have nice clean default methods. In Java we could emulate a mixin using an interface as followed:

// in Java 9+ code

public interface CommonFindersMixIn {

  default Record find(String id) { … }

    default Record findAll() { … }

 

// some private methods

// private void example () { … }

}

class AccountRecord implements   BasicRecord, CommonFindersMixin { .. }
 

One problem remains. Because private attributes are still not allowed in interfaces, this limits your options when writing complex methods. In this case you will have no choice but to use delegation and be forced to write a bit more code.

Duplication and inheritance are nothing more than anti-patterns. Practices which only have short-term advantages, but eventually end up causing more harm than good. Clean code is not only concise and void of duplication, but it also definitely doesn’t extend concrete classes unless absolutely necessary. 

References
David Thomas and Andrew Hunt (2020): The Pragmatic Programmer. 
Michael Feathers (2005): Working Effectively with Legacy Code.
Nicolo Pignatelli (2018): Inheritance Is Evil. Stop Using It. 

Don't Repeat Yourself and Don’t Pay Inheritance Tax

Why reinvent the wheel, when you can save yourself some time by using some vendor library, open source or even libraries that come bundled with the platform you are using? 

Using existing libraries is often easier and quicker. However, if you are not careful you can end up in a mess with code which is:  

Difficult to change. Leveraging third-party APIs leaves you with code which often looks like it is nothing but repeated calls to someone else’s library. Frequently resulting in your code being tightly knotted with the library’s.  

Difficult to test. Use of someone else’s code lulls you into a false sense of security. You end up thinking that you don’t need tests. After all, we aren’t doing anything significant, just calling some methods here and there. And before you know, the code has continued to grow and you are now left with something that isn’t simple anymore. It’s a patchwork of untestable code that no one wants to touch.

Help your future self and colleges and start wrapping third-party APIs.

“Wrapping third-party APIs is a best practice.” — Robert C. Martin

When you wrap a third-party API, you minimize your dependencies upon it. You are able to more easily move to a different library or mock out third-party calls when you are testing your own code.

You are not tied to a particular vendor’s API design choices. You can define an API that you feel comfortable with. 

Systems littered with library calls are harder to deal with than homegrown systems. First, it's hard to see how to improve the structure, because all you see are API calls. Most things that can give you a hint at a design is hidden in an external library. Secondly, you don’t own the API. You can’t rename anything to make them clearer. You can’t hide or add extra methods. 

Uncle Bob goes as far as advising you to wrap internal platform classes, like the Java Collection Map class. This may be a little much in most cases. 

So, you are refactoring code not implementing wrappers, how do you do this safely? Michael Feathers, in his book ‘Working Effectively with Legacy Code’, describes two methods:

Skin and Wrap. When refactoring existing code, this is the safest method to use.   

You start by making an interface which mirrors the existing API as closely as possible. Most IDEs come with build-in options for extracting interfaces from classes. 

You can now choose to preserve the signatures of the original API. First, you create wrappers for each one of the external library classes used in your code. These wrappers can delegate to the real API in production and point to mock objects when testing. (Code Snippet 1 & 2.) 

You may recognise this as the Decorator-pattern. If the third-party class contains too many methods, which you simply don’t need, you can skip creating the interface. Just wrap by passing the library class as a parameter to the constructor of your wrapper. (Code Snippet 3.)

After swapping out the third-party class for your own, you are left with code which is more loosely coupled and easier to test (using mock objects). 

 //   Example class to be wrapped 
class API{
    public void doSomething(){ /*implementation*/ }
  // … more methods 
}

//Wrapping using the Decorator Pattern
interface API {
  void   doSomething();

}

//Example wrapped class
class CustomAPI extends API{
    private API api;

    public CustomAPI(API api){
     this.api = api; 
    }  

    public void doSomething(){
    //add new functionality here
      this.api.doSomething();  
    //or here without breaking   previous code 
  }
  //other methods
} 

//Example wrapped class, but not so decorator-ish
class CustomAPI{
    private API api;

    public CustomAPI(API api){
     this.api = api; 
    }  
    public void doSomething(){
    //add new functionality here
      this.api.doSomething();  
    //or here without breaking   previous code 
  }
  //other methods
}

Responsibility-Based. However, when working with complex APIs with multiple classes containing dozens of methods it soon becomes unmanageable. 

Basically, you start designing your own API based on the functions you are using. And then wrap your new methods nicely in classes based on their responsibilities. Most likely, you will combine multiple third-party classes, or use the same third-party class in multiple custom classes. 

Of course, when you wrap a class, your new methods should only return standard Java classes or your own custom classes.

When moving code around, you want to separate the external libraries API from your custom logic. This is because you don’t want to test the third-party library. It has already been tried and tested. Also, you want your business logic to be library agnostic. Any major future changes to the third-party library, should at most only affect your custom API classes. 

By slowly extracting larger pieces of code into smaller methods, it makes the code easier to understand. When you locate custom logic, extract it to a new utility class. As soon as you feel like you have finished grouping functions together, you can more easily refactor and rename your utility classes to better reflect their functionality.

/*
*Example of custom designed Interfaces. They only accept standard or your own designed *parameters.

*/
public interface ContentEngine {
 CETask getTaskObject(String id);
 // etc.
} 

public interface CETask {
  //getters
  String getAttribute();
  //setters
  void setAttribute(String value);
  //more complex commands
  void doSomethingNeat();
  //etc
}

/*
*In this example Domain, ObjectStore, Factory and Connection belong to 
*a third-party library.
/* 
public class ContentEngineImp implements ContentEngine { 
    private ObjectStore objectstore;
     
    public ContentEngine(Connection connection, String defaultObjectStoreName) {
        Domain domain = Factory.Domain.getInstance(connection, null);
        this.objectstore = 
          Factory.ObjectStore.getInstance(domain, defaultObjectStoreName);
    }
    
    public CETask getTaskObject(String id){
      Task task = Factory.Query.findObject(this.objectStore, id);
      return new CETask(task);
    }

  // … more custom API methods
}

/*
*Task is a third-party Class.
*/
public class CETaskImp implements CETask {
  private String attribute;
 
  public CETaskImp(Task task){
    this.attribute = this.parse(task.getSomething());
  }
  
  protected String getAttributeImp(String attribute){
    return doSomethingWith(attribute);
   }    
  
  public String getAttribute(){
    return getAttributeImp(this.attribute); 
   }
  
  // … more custom API methods
}

Wrapping third-party libraries is definitely a good practice to follow. It may cost you some extra time, but in the long run you are left with a system which is easier and faster to change.

References
Robert Martin (2009). Clean Code. A Handbook of Agile Software Craftmanship.
David Thomas and Andrew Hunt (2020). The Pragmatic Programmer. 
Michael Feathers (2005). Working Effectively with Legacy Code. 

Working with third-party libraries and what to do when you find yourself in a mess

During the past few years, I have worked in several scrum teams on different projects. Thinking the time was right to validate my knowledge of the Scrum framework, I set about researching what certifications were available and how you need to prepare. 

The first certification I came across was the Professional Scrum Master I (PSM I) which is made available by the Scrum.org organization.  Scrum.org was founded by Ken Schwaber, no one less than a co-creator of Scrum. A good place to start. Scrum Alliance is another well-known organization which offers professionals a way of getting certified. Which one you choose is up to you, but I chose the Scrum.org certification route.

But isn’t this blog about passing the Professional Scrum Developer (PSD I) exam, not the PSM? Yes, you are correct. However, my first tip for passing the PSD is: first pass the PSM I. 

Before I took the PSD, I studied and passed the PSM I exam. When comparing the two exams nearly two-thirds of the questions asked during the PSD are copy-pasted from the PSM I.  So, if you have already comfortably passed the PSM I, you have already mastered the majority of the knowledge needed to pass. 

So how do you pass the Professional Scrum Master I Certification? 

When studying for the PSM I exam I used the following resources:

The Scrum Guide.  This document is the heart of Scrum. If you fully understand this document you will pass the exam, and more importantly you will understand Scrum. I recommend downloading this and reading it a few times. Then put it away for a week, and then read it again. 

The guide contains a few learn by heart definitions. Make sure you memorize these definitions, or at least know where you can find this information quickly when taking the test. The first 75% of your exam grade will be made up of relatively simple questions related to the different definitions defined in the guide. 

The final 25% of the questions will be related to the ‘spirit’ of Scrum.  You will be given several scenario questions and you will have to determine which answer best fits within the Scrum framework. These are the hard questions. But don’t worry there are ample resources out there to help you.

Open Assessments. There is an open assessment (practice exam) for every entry-level certification. These are free of charge practice exams; whose questions closely mirror the real exam. The great thing is, that you can take them an unlimited number of times. Every time you start an assessment you will get 30 randomly selected questions from a larger pool. 

After completing the assessment a few times, you will start recognizing questions.  From experience I can tell you that the real exam will have several questions directly taken from this pool, and some more which are really only slightly different. 

So, if you can consistently score 100% when taking the open assessments, you will be ready to take the exam.

Online courses. If you want, you can also follow an online course. Myself, I followed the ‘Scrum Certification Prep + Scrum Master + Agile Scrum Training' by Paul Ashun, course via Udemy.  Would I be able to pass the exam after solely following this course? No, I don’t think so. But it did help me when doing the Open Assessments. 

Third-party Practice Exams. The best way to practice for an exam is to practice with mock exams. After, you know all the Open Assessment question by heart, there is one more place where you can find plenty of mock exam questions: https://mlapshin.com/index.php/scrum-quizzes/.

Mikhail Lapshin is a developer who has been so kind enough to have created an online quiz tool and repository for practicing for a Scrum exam. This is a great place to practice and it helped me a lot.

How to prepare for the Professional Scrum Developer Exam?

So now you have studied for the PSM I and you have passed. Congratulations! Now you are ready for the next few steps. If you enjoyed studying for the PSM, then I will recommend quickly continuing with the preparations for the PSD. 

Firstly, if you are fresh out of college and you majored in Software Engineering, most likely you will be able to pass the PSD straight after completing the PSM I. At most, I would recommend you practicing with the PSD Open Assessment questions, and after you feel confident go for it.

However, if you have a more practical and less theoretical programming background, or you are curious what kind of theoretical works are at the heart of the Scrum framework, then I can highly recommend the following three books:

Clean Code. A Handbook of Agile Software Craftsmanship by Robert C. Martin.

The Pragmatic Programmer. your journey to mastery by David Thomas and Andrew Hunt.

Working Effectively with Legacy Code by Michael C. Feathers.

Finally, you should visit the Agile Alliance website. On their website you can find the Agile Glossary.  Here you will find the 75 must know terms and their definitions for Agile developers. This is a great resource for checking if you already have the theoretical background for the exam, or to use as a quick lookup, if you need to double-check certain terminology used during the exam.

After following these steps, you shouldn’t have any difficulty passing your Professional Scrum Developer Exam. Good luck!

In this blog by software engineer Ian van Nieuwkoop, you will read how to prepare yourself for the Professional Scrum Developer I certification exam.

Tips for passing your Professional Scrum Developer I (PSD I) Certification

In de wondere wereld van frontend technieken zijn er nog zoveel dingen om nader te onderzoeken. In afwachting van mijn screening voor de opdracht bij de Politie besloot ik om een nieuwe website te maken voor CINQ. En nu – medio oktober – staat deze eindelijk live. In dit blog deel ik graag mijn ervaring over – met name – Next.js. Dat is namelijk precies waar je nu naar kijkt.

Na het zien van de eerste proof of concept raakte collega Marc Jacobs geïnteresseerd in mijn positieve wil. Samen besloten wij te brainstormen om tot een plan van aanpak te komen om toe te werken naar wat voor ons een succesvolle website zou zijn. 

Woorden als specialisten in Data, DevOps en Development vormen de basis voor ons verhaal, gevolgd door sociale IT’ers. Tijdens het ontwerpen en ontwikkelen van de website stond verschillende kenmerken constant centraal: de unit’s, events, vacatures en blogs. Ons doel was duidelijk.

Voor ik deze vraag ga beantwoorden is het interessant om te weten wat Next.js is. Zij omschrijven zichzelf als een React Framework voor Productie waarmee je met simpele handelingen een applicatie van A tot Z kan ontwikkelen en in productie kan zetten. Je krijgt hierbij toffe mogelijkheden, wat je kan zien als builts-in functionaliteiten, om een hybride en server side rendered applicatie te bouwen met minimale configuratie.

Dat klinkt als een kind kan de was doen, maar dan? Er waren redenen om de oude CINQ-website te vervangen, bijvoorbeeld dat deze niet makkelijk door onszelf was aan te passen, het op de mobiel beter kon werken en dat wij graag ons verhaal nog beter zouden willen vertellen. Wij hebben voldoende specialisten in huis om - ook voor onszelf - mooie dingen te ontwikkelen. Hoe mooi zou het dan zijn als wij zelf onze eigen website zouden ontwikkelen en onderhouden? Met deze voorkennis, natuurlijk ook in afweging van vele andere aspecten als bijvoorbeeld Next.js of NuxtJS, besloot ik om te kiezen voor Next.js in combinatie met Prismic CMS.

Toen ik eenmaal begon met het ontwikkelen van de website in Next.js was natuurlijk alles nieuw voor mij. Waar begin je dan? Gelukkig heeft Next.js een duidelijke documentatie. Om een snelle start te maken heb ik ervoor gekozen om te beginnen met een ‘bootstrap’ van Next.js via commando: 

Door de afgelopen jaren heen ben ik gewend om al in componenten te denken, omdat je dit bij alle frameworks wel op een bepaalde manier gebruikt. Waar je normaal vanuit een router pagina of module iets doet, heb je dit bij Next.js onder een folder pages. Bij de bootstrap installatie krijg je de onderstaande folder structuur.

├── pages             # folder voor alle pagina's
│   ├── api           # folder voor alle serverless functies
│   _app.js           # overal document voor je applicatie
│   index.js          # index.js verwijst naar / van de applicatie
├── public            # folder voor alle assets
├── styles            # folder voor styles
│   global.css        # globale style (voor bv. body tag)
│   Home.module.css   # module style voor homepage

Bij het ontwikkelen van een Next.js applicatie zijn er twee belangrijke folders, dit zijn pages en pages/api. In de folder pages zet je alle pagina’s die de applicatie kent. Je kan dit zien als een soort van router structuur. In de folder pages/api zet je alle API endpoints die je als Node.js serverless functie kan gebruiken. In de praktijk voor de CINQ-website hebben wij daarom pagina’s als bijvoorbeeld: pages/index.js, pages/contact.js pages/[uid].js en pages/blog/[id].js Deze pagina’s verwijzen naar de homepage (/), de contact pagina (/contact), een willekeurige content pagina waar geen andere pagina voor is (/data) en een blog artikel (/blog/toffe-developer-ervaring). Voor wat betreft de serverless API endpoints moet je denken aan het ophalen van meer artikelen voor de blogpagina of het versturen van het contactformulier.

Als je eenmaal een pagina hebt aangemaakt in de pages directory, dan is de volgende stap om data op te halen en componenten te gaan ontwikkelen. Voor het ophalen van data en de manier van renderen heeft Next.js verschillende implementaties. Met getStaticProps() kan je ervoor zorgen dat een pagina bij het builden van de applicatie wordt gemaakt, dit heet dan static site generation. Deze wordt dan voor elk request gebruikt. Daarnaast heb je ook een server-side rendered variant, dit gebruik je door de methode getServerSideProps(). De laatstgenoemde is wel langzamer dan de static variant, want deze doet bij elk request het opnieuw opbouwen van de pagina. Voor ons geldt voor de meeste pagina’s het laatste.

Mijn collega Marc wilde graag de website zelf kunnen beheren. Prismic is een Headless CMS dat uitstekend te combineren is het met het gebruik van Next.js. Je kunt in Prismic een aantal content types definiëren, dit resulteerde bijvoorbeeld in types als een blogpagina, een content pagina, een medewerker, een review of een vacaturepagina. Deze types werden er zo op gericht dat je dacht vanuit het componenten niveau wat wij in de applicatie kennen.

Om je een voorbeeld te geven hebben wij in Prismic een content pagina type. Stel wij hebben de pagina over Development. Deze bestaat nu uit een intro header, een intro content, kernwaarden met logo’s, vacatures en blogs. In Prismic heb ik het zo ingericht dat je deze blokken kan invullen, wijzigen van volgorde of het juist aanvullen van informatie met een tag. Zo zie je bij de vacatures alleen de vacature voor development, evenals bij de blogs dat je alleen de blogs zie over development. Kijk je naar de homepage zie je weer alle vacatures en blogs.

Wellicht vraag jij af hoe ik vervolgens de koppeling heb gelegd tussen Next.js en Prismic. Vanuit de Next.js pagina heb ik in getServerSideProps() een functie geschreven die de data ophaalt vanuit Prismic. Dit doe ik aan de hand van het type pagina. Nadat ik deze informatie heb opgehaald, stuur ik deze properties als JSON terug naar de pagina. Vervolgens laat ik door een soort van beslisboom de juiste componenten in de juiste volgorde zien. Dit betekent ook dat ik dus herbruikbare componenten heb ontwikkeld. Zo zijn componenten als bijvoorbeeld de intro tekst - in de code noem ik dit hero content- gebruikt voor de content pagina’s, maar ook voor pagina’s zoals dit blog artikel.

Samenvattend kom je steeds terug bij de kernwaarden die wij onszelf eerder hebben gesteld. Zowel bij de pagina’s, als de componenten als de inrichting van het Prismic CMS zie je deze terug. Hierdoor hebben wij een dynamische website, voorzien van herbruikbare componenten en slim gebruik van het CMS. Bij lange na heb ik natuurlijk niet alle toepassingen en keuzes over Next.js, Prismic of zelfs het in productie nemen via Vercel in dit blog kunnen toelichten. Mocht je naar aanleiding van dit blog een deep dive willen, dan kan je daarover altijd contact met mij opnemen via jeroen.burgers@cinqict.nl of via mijn Linkedin-profiel. 

Hoe maak je een succesvolle website of applicatie met Next.js en Prismic? Lees onze ervaring.

De nieuwe CINQ website: Geslaagde combinatie van Next.js met Prismic CMS

In de afgelopen periode heeft zich een vrij nieuwe techniek zich aangediend genaamd WebAssembly. Wat kunnen wij ermee en wat zou het kunnen veranderen?

Vrij simpel gezegd is WebAssembly een techniek waarmee je in verschillende talen, dus niet vastgepind op één specifieke taal, iets voor de webbrowser kan ontwikkelen. Het is erop gericht om op een laagdrempelige manier de code te schrijven en hoogwaardige (native) gevoel te creëren. Daarnaast heeft het als doel om gecompileerd te kunnen worden tot een taal die de moderne webbrowser begrijpt. Niet als Javascript code, maar om hiernaast te kunnen draaien. Voorheen kon je alleen met Javascript een volwaardige ‘native’ webapplicatie voor de browser maken. 

WebAssembly kunnen wij zien als aanvulling op de Javascript code. Je kunt deze dan ook prima combineren om het beste uit beide werelden te halen. WebAssembly zegt een volwaardige oplossing te kunnen bieden voor een sterke performance. Wat hun sterk maakt is dat alle moderne browsers de techniek ondersteunen.

WebAssembly gebruik je om een webapplicatie voor de browser te ontwikkelen. Je kunt de componenten van je applicatie schrijven in diverse talen, waarna deze gecompileerd worden naar WebAssembly code. Door middel van de payload kan de browser het uiteindelijk via Javascript begrijpen. Belangrijk om te weten is dat WebAssembly een techniek is en geen nieuwe taal is. Het doet iets wat voor veel developers ongrijpbaar is. 

Met WebAssembly kan je grootschalige dingen als games of tekenprogramma’s bereiken. De vraag is alleen zijn wij al zover? Het geeft ons vandaag de dag wel al de mogelijkheid om bijvoorbeeld een complexe reken functionaliteit uit een andere taal als module over te nemen.

Aan elke techniek of code zitten voor- en nadelen, zo ook bij WebAssembly. Ten eerste geven zij aan geen vervanging te zijn voor Javascript. Zij zien de combinatie van bijvoorbeeld DOM manipulatie veel beter via Javascript gaan en bijvoorbeeld tijdelijk opslaan van data via WebAssembly. Het zou sneller en kleiner moeten zijn dan andere dingen. Volgens de makers zou je zelfs de gecompileerde code – wat zelfs voor Javascript lastig kan zijn – op een eenvoudige manier te debuggen is. De nadelen richten zich vooral op het feit dat het nog steeds geen native code zal zijn. Het voegt ook weinig toe voor de normale webapplicaties. 

Persoonlijk denk ik dat WebAssembly de wereld weer een extra mogelijkheid geeft. Ik zie vooral de voordelen in voor de zwaardere applicaties en niet voor meer ‘user friendly’ webapplicaties met wat data. Hiervoor is bijvoorbeeld de opstarttijd te zwaar, wat al snel weer als nadeel gezien kan worden. Daarnaast zie ik een vervanging van Javascript ook nog niet zo snel gebeuren. Hiervoor moet nog te veel gebeuren op allerlei vlakken. Javascript heeft zich al tientallen jaren bewezen als betrouwbare code voor het web. Kort gezegd geeft het ons weer nieuwe mogelijkheden en zal de toekomst, zoals wel vaker, gaan uitwijzen wat voor effect het heeft. Het zijn in elk geval mooie ontwikkelingen!

Verslaat WebAssembly het gewaardeerde JavaScript? Lees het blog op de CINQ website.

Verslaat WebAssembly het gewaardeerde JavaScript?

In de wonderlijke wereld van front-end technologie gaan de ontwikkelingen bijster snel. Het is niet altijd mogelijk om deze nieuwe ontwikkelingen direct toe te passen bij de opdrachtgever. Hier werk je namelijk vaak aan al een bestaande applicatie/project, waardoor je niet altijd direct in staat bent om nieuwe keuzes te maken. Toch krijg ik steeds vaker de vraag wat nu de beste keus is om een toekomstbestendige front-end neer te zetten. Dat vind ik persoonlijk een lastige vraag die ik niet binnen twee minuten kan beantwoorden, omdat dit ook te maken heeft met wensen, tijd, capaciteit en budget. In dit blog deel ik graag één van de keuzes die dit mogelijk zouden kunnen maken, namelijk Web Components. Zal dit de standaard worden en daarmee ook meer toekomstvast? 

In het kort gezegd zijn Web Components geïsoleerde componenten die je kan (her)gebruiken in HTML-pagina’s en webapplicaties. Een Web Component bouw je zonder tussenkomst van een toegevoegde bibliotheek. 

Als developer ben je in staat om je eigen Custom Element te schrijven, wat in principe dus je eigen HTML-element is met zijn eigen CSS en Javascript. Dit element is gebaseerd op web standaarden, waardoor het nu al in de meest gebruikte browsers toegepast kan worden. Ook Microsoft Edge ondersteund sinds januari 2020 dit principe. Dat maakt het bijzonder interessant.

Web components are based on existing web standards. Features to support web components are currently being added to the HTML and DOM specs, letting web developers easily extend HTML with new elements with encapsulated styling and custom behavior.

bron: https://www.webcomponents.org/introduction

Een Web Component bestaat uit vier specificaties, dit zijn:

Custom Elements
Een Custom Element is een HTML-element die je kan toevoegen aan de DOM.

Shadow DOM
Shadow DOM zorgt ervoor dat de styling gespecifieerd kan worden voor alleen dat element.

Es Modules
Het gebruik van ES Modules geeft de mogelijkheid tot het schrijven en gebruiken van modules op een standaard Javascript manier.

HTML Template
Declareer je eigen herbruikbare templates die getoond worden bij de rendering.

Hoe verhouden Web Components zich tot frameworks?

Nu wij simpel gezegd weten dat een Web Component een native component is, nu de vraag hoe deze zich verhoudt ten opzichte van de al bestaande frameworks. Ten eerste de vraag of wij moeten kiezen voor een Web Component, een framework of een combinatie van beiden? Uit mijn eigen ervaring heb ik nooit een combinatie van deze twee gezien. Neem ik het statement van React als voorbeeld, dan herken ik zeker dat elk framework zijn eigen problemen probeert op te lossen.

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. 

bron: https://reactjs.org/docs/web-components.html

Angular geeft zijn eigen invulling door het gebruik van Angular elements. Dat komt neer op een soort van afgeleide Web Component alleen dan met een isolatie van Angular eromheen.

De redenen waarom frameworks zo populair zijn komt omdat deze vaak bestaan uit één of meerdere van de volgende dingen: LifeCycle “de leef status” van het component voor view en data, data binding, routing, templating en herbruikbaarheid. Natuurlijk bevatten frameworks ook voordelen om sneller een applicatie te ontwikkelen, maar is het daarmee altijd de juiste keuze?

Ik denk het niet. Deze frameworks gebruiken namelijk ook gewoon native Javascript om de applicatie te laten runnen. Als voorbeeld neem ik het stukje routing. Zou ik dit zonder framework doen en in combinatie met Web Components, dan gok ik dat ik rond de 100-150 regels code nodig heb om de browser history API aan te sturen.

Natuurlijk is dit maar een minimale vergelijking en zijn er nog tientallen andere vergelijkingen te maken om een verschil aan te duiden. Dat zal alleen voor deze blog veel te veel (rand)informatie geven.

Het is niet zo simpel als dat het lijkt. Web Components zijn niet moeilijk om te ontwikkelen, maar met alle randzaken erbij kom je al snel op flink wat “maatwerk”. Wanneer ga je dan overstag? Ikzelf zie een aantal nuttige dingen.

Wanneer er in een organisatie de nodige applicaties ontwikkeld worden en/of er wordt met meerdere teams gewerkt, dan is het zeer belangrijk om niet in herhaling te vallen. Web Components werken onafhankelijk van andere frameworks. Doordat het zo dicht bij de standaard ligt, zou het dus een optie kunnen zijn om je design system (branding) hierin op te zetten. De componenten kunnen dan in elke willekeurige applicatie gebruikt worden. Een win-win situatie en daarmee dus ook toekomstbestendig? Wie weet.

Wanneer je met ontwikkelaars afspreekt om 1 taal te spreken en schrijven zal dat de kwaliteit van je code ook verhogen. Je kan naar mate de applicatie groeit, nog steeds vastbijten op web standaarden voor HTML, CSS en Javascript. Ik denk dat je ownership kan geven en eisen, maar nog belangrijker kan blijven houden. Daarnaast denk ik dat je als ontwikkelaar ook meer hebt aan het leren van web standaarden dan het leren van een framework.

Als je bereid bent om een investering te doen in Web Components, inclusief het hierboven beschreven “maatwerk”, dan denk ik dat je op termijn geld kunt besparen. Ontwikkelaars zullen namelijk sneller in staat zijn om de business te kunnen bedienen, doordat zij enkel bezig zijn met nieuwe componenten gebaseerd op web standaarden.

De nadelen van het gebruik van Web Components

Hoewel de meest gangbare browsers inmiddels Web Components ondersteunen blijft het toch een redelijk nieuw begrip. Daarom zal je ook rekening moeten houden met de volgende zaken.

Er zijn developers die erbij zweren dat alles per definitie in 1 file zou moeten staan, dus ook de styling van je component. Mijn voorkeur gaat echter om de styling altijd te scheiden van hetzelfde document, maar de styling moet wel alleen voor dat component toepasbaar zijn. Dit is meer een persoonlijke voorkeur, dan een hard argument.

Om een webapplicatie geschikt te maken voor een goede indexbaarheid voor zoekmachines als Google, dan vereist dat wel de benodigde best practices. Voor Google geldt dat de HTML gerenderd moet worden, zodat de bot de informatie kan lezen en begrijpen. 

Wanneer je Web Components gaat gebruiken, dan ben je in meer of mindere mate nog niet af van libraries. Er zijn namelijk een aantal libraries die het leven met Web Components een stuk fijner kan maken, bijvoorbeeld: Hybrids, lit-html, Skate.js, Slim.js of Stencil. Daarnaast is ook Open Web Components een actieve bibliotheek. Kort gezegd ben je dus niet af van het gebruik van third party stuff.

Dat de juiste frontend technologie kiezen een lastig vraagstuk is blijkt maar. Ik heb geprobeerd een kleine inkijk te geven op het gebied van Web Components. Terugkomend op de vraag of deze de standaard worden en toekomstbestendig zijn? Ik denk wel dat Web Components zeker de toekomst hebben. Juist omdat deze op de web standaard gebaseerd zijn. Alleen wanneer is een webapplicatie nu toekomstbestendig? In de afgelopen 30 jaar is er nog geen toekomstvaste applicatie neergezet die eeuwig blijft leven. 

De keuze om voor Web Components te kiezen zou het leven van de applicatie wel kunnen verlengen. Je blijft, voor nu, afhankelijk van libraries die het ontwikkelen makkelijker maken. Daarnaast is het ook nog maar de vraag of Web Components past bij de wensen, tijd, capaciteit en budget van de opdrachtgever. Er zijn nog niet heel veel bedrijven die nu al (volledig) gebruik maken van Web Components. In Nederland is ING er bijvoorbeeld heel actief mee bezig. Kijk je naar de trends van installatie, dan zie je dat lit-html wel aan het groeien is de afgelopen 6 maanden.

Om af te sluiten zie ik dus potentie in het ontwikkelen van Web Components. De vraag ernaar zal gaan toenemen. Ik zal het in elk geval altijd meenemen in mijn afweging tussen een framework als bijvoorbeeld Angular, Vue of Svelte en Web Components. Ik verklaar alleen niet mijn volledige liefde eraan. Op het gebied van front-end development blijven de ontwikkelingen immers nog steeds razendsnel gaan.

In de wonderlijke wereld van front-end technologie gaan de ontwikkelingen bijster snel. Het is niet altijd mogelijk om deze nieuwe ontwikkelingen direct toe te passen bij de opdrachtgever.

Web Components - de toekomst van front-end ontwikkeling?

I prefer to use Spock for my tests, but it doesn’t play nice with the latest Java versions. The latest release version of Spock runs fine on Java 8, but every newer version prints a bunch of warnings, as shown below.

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.codehaus.groovy.reflection.CachedClass (file:/C:/Users/Bouke/.m2/repository/org/codehaus/groovy/groovy-all/2.4.15/groovy-all-2.4.15.jar) to method java.lang.Object.finalize()
WARNING: Please consider reporting this to the maintainers of org.codehaus.groovy.reflection.CachedClass
WARNING: Use –illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Furthermore Spock 2.0 is in the works for some time and there has been a milestone release in the beginning of January 2020. So I decided to kill two birds with one stone. I went looking for a solution that combined the use of Spock 2.0 and that got rid of the warnings. The following solution is tested with Java 14 (and below).

Basically the solution consists of the following three components:

use the first milestone release of Spock 2.0

To see the three components working together have a look at this pom file:

https://github.com/BoukeNijhuis/spock-with-new-java-versions/blob/master/pom.xml

So let’s explain all relevant sections in this pom file.

<plugin>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.8.0</version>
    <configuration>
        <source>14</source>
        <target>14</target>
    </configuration>
</plugin>

We have to specify some configuration for the maven-compiler-plugin. Here you set the Java version you would like to use. In this case we use Java 14. Please make sure that you use a Java version at least as high as the one that you specify here. So for this example you will need to run it with Java 14 or higher.

<plugin>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.22.0</version>
</plugin>

You need a newer version of the surefire plugin otherwise the test runner will not find your tests.

<dependency>
    <groupId>org.spockframework</groupId>
    <artifactId>spock-core</artifactId>
    <version>2.0-M1-groovy-2.5</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.codehaus.groovy</groupId>
    <artifactId>groovy</artifactId>
    <version>3.0.0-rc-2</version>
    <scope>test</scope>
</dependency>

Use the latest version of Groovy which does support the latest Java versions. And so the warnings disappear!
I hope you found this useful and thanks for reading! 🖖

Watch my talk on “Why I prefer Spock over JUnit” at Devoxx 2019 here:

Why I prefer Spock over JUnit  by Bouke Nijhuis

🖖 How to run Spock with the newest Java versions without the annoying warnings

Welcome back! In our previous blogpost: “Building our own augmented reality app,”we explained how we chose Unity and Wikitude as our weapons of choice to explore the world of augmented reality and build our own AR app. In this next episode, we will show you how we put the chosen frameworks into practice. Will we have a working AR app by the end of this blogpost? Keep on reading to find out!

We mentioned before that next to recognizing the scene or objects, all that is left is to augment the screen with something. For our demo/prototype we wanted to try a series of things such as:
– show text
– show photos
– play video
– show a 3D model
– have interactions (such as starting a call or opening a website)

We took our own office as a subject (to recognize) and display some basic information about the office and our company.

Furthermore, we also experimented with features such as:
– keeping the augmentation on the screen until the UI is closed
– switching it when a new object or scene is detected
– switching as soon as the scene or object is no longer detected

The result can be seen below in Figure 3.

Figure 3 – the app recognizes the building and shows the UI

The app itself is built in Unity because it enables us to do cross-platform easily and facilitates a lot of core things that we will require anyway. Building a UI in Unity can be a little cumbersome at times as the initial way to get started is to click and drag your UI together.

For now, we have structured the demo in the following way.

The two main Unity Components used are the WikitudeCamera and ObjectTracker. These are part of the Wikitude API. The Camera object renders the video of your camera inside the App. The ObjectTracker is the logic that takes the camera’s video input and matches it with the point cloud and then determines what to show on your screen.

One of the important properties on the ObjectTracker is the Target Collection. This is where you select your point cloud(s). Keep in mind, a Target Collection can be a collection of point clouds, not just one thing, so it can hold multiple buildings, objects and scenes to detect. In our case, our point cloud holds four models.

As children of the Object Tracker we have defined empty Unity objects with the “Object Trackable” script from the Wikitude API. We will call these trackers from now on. The trackers will activate when certain conditions are met, in our case when a specific model is detected.

While there are four trackers we only track two real-life objects: we detect a logo on our wall in the office and the office building itself. The office building is split into 3 separate planes, because we had some trouble with getting our office building in one model. We believe that with more time spend on making photos and creating a point cloud we could bring this down to a single point cloud.

Each tracker has actions, for example, the CINQ Logo Tracker and one of the building trackers have the properties as shown in Figures 4 and 5.

For Figure 4 we have set the Target Pattern to “CINQ LOGO”. This is the name of the model in the point cloud and is the condition on which the object activates. We also set actions for when an object is recognized and when the object is lost. With this configuration the augmented view would be lost when you point your camera at something else.

In this case, we draw a 3D object in the scene and enable the canvas. A canvas in Unity is what renders your UI elements.

For the second object, when the front of our office building is on the camera, we opted to just display a UI element but not remove it when it leaves the camera. The user has to click it away. This makes it easier to interact with UI. You do not have keep the camera pointed towards the object.

For the prototype, we chose to use the visual configuration of the Object Trackable’s in Unity for the sake of speed of prototyping. However when making a real application with many trackers it would pay off to turn this sort of event handling into reusable scripts. So we can perform actions programmatically which makes development and maintaining the app a lot quicker.

We can do whatever we choose with the triggers but for now, we left it to rendering 3D objects and standard UI elements. However, with these same techniques you could render entire virtual worlds over your camera image and make them fully interactable by the user.
We will not go into too much detail about the Unity Canvas elements, but if you want to know more about that have a look at the Canvas documentation of Unity.

Two other components that are of interest are the “Generic Image Shower” and “Generic Video – Player”. These are reusable objects we build in order to easily show a photo or video. The idea behind this is that we turn features like this into components. So we can easily reuse these in any augmented scene we create. Other features that would be good candidates in the future would be audio clips, one for 3D models and possible even generic UI components.

There are lots of potential paths of improvements for the prototype if we would turn it into a real application.

Localization would be beneficial so we could offer our app in multiple languages. You would achieve this by separating all the text from the presentation layer and have a piece of middleware (unity script) select the text based on the current language selected.

Building the entire UI by hand in the Unity editor can become cumbersome with many different screens and visuals. Ideally, you would want to have generic UI components that make up your screen which gets generated based on code and configuration rather than manual actions in an editor.

Content in these sorts of apps need to be maintained in order to achieve this. The same configuration mentioned above could be obtained from a CMS server which holds the latest definitions of what to show to the end user. This would also enable the app to be easily adapted for multiple use cases. The type of content you should think about is text, videos and/or images to display.

A target collection is small enough that it can be transmitted over an internet connection. So if you would be building an app where internet access is not an issue it would theoretically be possible to create one generic app that reads the point cloud, what to do and its output.

So we have achieved our goal. We have an app that is capable of recognizing a building. Furthermore it shows a text and video (once it is recognized). Actually the app can also show photos, open a website and open the phone app with a predefined number. Last but not least it shows a dancing 3D model when recognizing our logo on the wall. Mission accomplished!

Screenrecording of our AR app

Building our own augmented reality app – the results

Welcome back! In our previous blogpost: “Augmented reality deep dive,” we wrote about our hackathon and its results. This blog will explain what we did after that, and where we stand now. But before we continue, let’s recap what we are trying to achieve:

We would like to build an app that is capable of recognizing a specific building (through the camera). Once this happens it augments the screen with text, photo, video or other audiovisuals.

In the previous blog we gave several directions in which we could expand our research. We choose to look into existing AR frameworks, because this seemed to be the most promising area. There are a lot of AR frameworks out there, but pretty soon we found the one that matched with our use case: Wikitude.

The main reason we chose this framework is the fact that it supports scene tracking. For people unfamiliar with this term: besides recognizing (small) objects it can also recognize scenes (or big objects). As we are trying to recognize a building, this is a perfect fit for our use case. Furthermore, the framework supports cross-platform development. So we do not have to develop a separate app for Android and iOS. And last but not least, you can download a trial version for free. This will add a watermark to the app, but that is fine for early development and testing.

Besides recognizing the building, there is also the user interface part. Remember that we would like to show a text, photo or video when having the building on the screen. We chose to use Wikitude in combination with Unity. This was the logical choice because one of the developers already has quite some experience with this platform. We will get back on the user interface in a few paragraphs.

So how does this scene recognition work? How does it know what building it should recognize? Great questions! This is actually quite simple, because Wikitude does the heavy lifting for you. First, you have to take a lot of pictures of the building that you would like to recognize. Then you upload them to their servers and it will return something called a point cloud. So the input is photos and the output is cloud of points in 3D.

To understand the concept of a point cloud a bit better, please have a look at the two pictures below. Figure 1 shows the building from the top. Figure 2 show the building from the front. In both pictures you easily recognize two planes of the building. Hopefully this helps in understanding the concept of a point cloud.

Once you have the point cloud, you can start recognizing the object from the photos (in our case the building). The framework will take the input from the camera (from your phone) and will continuously create point clouds from this. Then it will try to match the point cloud from the camera with the stored point cloud (of the building). When there is a match, we have a recognized building!

With the heavy lifting done in terms of recognizing the scene or objects, all that is left, is to augment the screen with something. For our demo/prototype we wanted to try a series of things such as:
* show text
* show photos
* play video
* show a 3D model
* have interactions (such as starting a call or opening a website)

In order to accomplish this, we decided to make a demo app showing these capabilities. We took our own office building as a subject (to recognize) and display some basic information about the office and our company.

In part 3 of our Augmented Reality adventure, we will show you how that went and what the app looks like! Stay tuned!

Building our own augmented reality app

This time a more high-level recap of day 2 and 3 of Oracle CodeOne.

In the last two days I visited three types of talks: keynotes, workshops and technical sessions. There were two keynotes and both were bad. Luckily one was bad on purpose, so it was funny. The other one was just bad. Apparently not everything is great on conferences. 🙂 Furthermore I did some workshops about streams & lambdas. Interesting and fun to play with. I have enough knowledge about both to finally start using them in my projects!

Onze laatste blogs over Development