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!

Always use the latest version of everything

One of the more interesting sessions was about security. The presentation showed how easy it is to extract useful version information from server responses. This can be used to find known bugs and these can be exploited. The presenters showed us how simple it was to hack a website. The main takeaway of the session is to always update your software. Nowadays it takes hackers on average two days to start exploiting known vulnerabilities. So always use the latest version!

3 techniques to build more resilient applications

Furthermore I visited a talk about making your Java application more resilient by using the following techniques:

timeouts: make sure that your application does not wait forever on an answer, because the number of threads is finite

bulkheads: compartilize your application, so if something breaks it does not pull down the entire application (use more than one threadpool)

circuit breakers: prefer a little damage (a direct error response) over a lot of damage (requests that time out)

Kotlin – the 2nd most popular JVM language

I also attended two sessions about Kotlin, already the second most popular language on the JVM. One showed how to use Kotlin with Spring Boot. The other showed how you can start using Kotlin on a small scale in your projects. Kotlin is designed to play nice with Java, so it should not be too difficult to use this next to your Java code. I think it’s time to start using it in my projects. Looking forward to it!

We visited the Github HQ with the people from NLJUG. We got a tour of the office and it was a nice sneak peek in US software development culture. Tomorrow we will visit the offices of Pivotal (the owners of Spring). This should also be fun. So one more day left!

NLJUG on Twitter: "Let the show begin! #CodeOne… "

On-demand video’s and livestreams of CodeOne ’19

By the way, did you know that you can watch a lot of the talks and technical sessions in this Youtube playlist? They also stream some of the keynotes and technical sessions live!

Day 2 & 3 take-aways at Oracle CodeOne

So the first conference day at Oracle CodeOne in San Francisco is over. I have learned some interesting things today. First I would like to show two new features in Java 13 and then finish with the tip of the day.

On the second conference day, the latest Java version (13!) will be released. Two new features already caught my eye: the switch expressions and text blocks.

Let’s start with the new switch expressions. There was already a new switch expression in Java 12, but they refined it even further. The easiest way to show this, is by a simple code example:

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

When using the traditional switch statement one has to use around twenty (!) lines to do the same. Please also note the absence of the break statement and the default label. The new switch statement for the win!

Another killer feature is the introduction of the text blocks. This is a much requested feature which finally will be available in Java 13. Again a piece of example code.

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;

So in the past we needed five different Strings for this which we had to concatenate. Furthermore the first four lines needed a new line at the end. So using a text block is much more elegant. It uses less code and it is much more readable. If you are worrying about the spaces in front of every line, the new text block feature got you covered. It will detected those obsolete spaces and remove them for you.

Last but not least: the tip of the day. Since Java 8 we can use streams. This is a wonderful feature, but it is a bit hard to debug. Apparently IntelliJ has a stream debugger. Whenever you are working with streams, you can put a breakpoint on the line containing the stream. When the debugger pauses the execution of the program, you can click on an icon to show the stream debugger.

The screenshot below shows you exactly where you can find this incredible feature. 

The next screenshot shows you what the debugger looks like. Why didn’t anybody tell me this earlier? 🙂

I am already looking forward to the next conference day, more updates will follow!

Oracle CodeOne `19 update: A sneak peek into Java 13

One of the hottest new technologies in software development is augmented reality (AR). This is not the kind of technology we use in a common workday. So we did a hackathon with the entire team to familiarize ourselves with this new “kid” on the block.

Before we can tell you more about the hackathon we have to explain the bigger picture first. One of the reasons to look into augmented reality is the following: We would like to build an app that is capable of recognizing that the camera is looking at specific buildings. Once this happens it should also be capable of showing a text or video. The most difficult part of this plan is, of course, the detection of (looking at) specific buildings. Therefore we created three different tracks which we thought would all bring us closer to a proper final solution.

The three tracks are:
– Location tracking
– Compass
– AR anchors

The first one is putting Augmented Reality content (markers) on GPS coordinates. So when a user comes near the location and points its phone toward the coordinate, it should show the marker. If this would work as expected, we could put markers on the GPS coordinates of the specified buildings.

After playing with it for several hours we identified the following problems:
the markers jump all over the scene and the size changes over time
the markers disappear sometimes and you have to search the room to get them back
two markers with the same GPS location are not drawn on the same location in AR.

So this technology is not ready for prime time (yet). We think a lot of these problems are caused by our indoor tests. Therefore we also think that taking this outside will improve the performance quite a bit.

GPS data alone would not be sufficient, the application also needs to know what the camera is looking at, for this we use the bearing of the compass. The second track was using the compass (of a phone) to see where somebody is looking at. This is important because initial research showed that the accuracy of the compass leaves a lot to be desired. So this track was about finding out how inaccurate the compass really is.

For the compass track, we tried two approaches: compass data directly from the phone or through the ARCore framework. In the end, there is only one big difference between both approaches. The compass data obtained through the framework is wildly inaccurate when the phone is level (with the ground).

Furthermore, they share the following observations:
There is a lot of drift in the direction of the needle (depending on the phone it is between 10 and 20 degrees off)
High-end phone seem to have better compasses than low-end phones
Manual calibration of the compass helps a little (but not enough)
The compass seems to suffers a lot from (magnetic) interference from laptops or other phones nearby

The mentioned drift is too much to tell if the user is looking in the direction of the building. With a drift of 10 degrees it would seem that the building is on the screen, but in reality it will not. So again not good enough to use right now. We do think that repeating this exercise outdoors would improve the outcome (so less drift). The main reason for this is less magnetic interference.

The last track was about using ARCore anchors to see if the building is on your screen. An ARCore anchor is something you put in the augmented world and then it should be visible on other phones as well.

At the start of the Augmented Reality hackathon, we played with a quick demo for cloud anchors and came to the conclusion that it was worth investigating as it seemed to solve our problem. During the hackathon, we started to dig deeper into the technology and started experimenting.

The conclusions were quite disappointing. We had mistakenly identified ARCore anchors as a magic bullet that would solve our problems and we quickly ran into some interesting behaviour:
The anchors seemed to disappear over longer distances (more than 10 meters).
While anchors could be shared with other devices, setup of them looked to be all manual not programmatically.
The anchors lived only a short period of time (24h).

The reason for this is that cloud anchors are created by taking screen input and building a 3d profile based on that screen input from multiple angles. This profile then is stored in the Google cloud and compared to the data currently on the screen constantly. If there is a match then the anchor is displayed. If we could visually display these profiles they would look something like this:

One challenge with this is that if you increase the distance and make the object or scene you are looking at smaller, you will have fewer reference points and the match will become harder to make.

Because the cloud anchors are volatile in nature with a lifetime of only 24 hours, they were not created to be able to make permanent profiles. Furthermore not being able to setting them up programmatically is an issue. So AR anchors will also not solve our problem.

Our preliminary conclusion is that all tested techniques seem not good enough to achieve our goal of recognizing (looking at) specific buildings. We will investigate further on these follow-up items:
– look into existing AR frameworks (mapbox, wikitude & blippar)
– look into image recognition
– look into existing apps (that do something similar)
– test GPS & compass outdoors

Thanks for reading and stay tuned for the next update in our AR adventure!
Robin & Bouke

Augmented Reality Deep Dive – What can we do with AR?

Dit artikel van onze Java eindbaas Bouke verscheen in print in het Java Magazine 03-2018. Het magazine is een uitgave van de Nederlandse Java User Group.

Je kunt het volledige artikel hier in pdf formaat downloaden, of hier onder lezen als je erg goede ogen hebt.

Ook het Java Magazine ontvangen? Lid worden van NLJUG en abonneren op het magazine doe je hier.

blog-javamag-bouke-1.png

blog-javamag-bouke-2.png

Voice adventure voor Google Assistant

De chief architect of Java (Mark Reinhold) heeft tijdens de keynote de grootste veranderingen in Java 9 laten zien. Voor mensen die de ontwikkeling van Java een beetje bijhouden, weten dat de grootste wijziging project Jigsaw is. Het is nu mogelijk om je software in modules op te hakken, waarbij een module een groepering van packages is. Dit mechanisme kan je gebruiken naast het al bestaande (inferieure) classpath mechanisme. Tevens zijn alle bestaande java packages opgedeeld in 25 optionele en 1 verplichte module. Dat betekent dat je nu veel kleinere deployment units kan hebben, want alle ongebruikte, optionele modules heb je niet meer nodig. Precies wat je wilt in deze tijden van microservices en serverless computing.

Daarnaast komt er nu elke zes maanden een nieuwe versie van Java. De vorige versie van Java (8) is namelijk alweer drie jaar geleden gereleased. Dit releaseschema kun je je als zelfrespecterende taal eigenlijk niet meer veroorloven. Oftewel in maart kunnen we Java 10 verwachten. Eén van de zaken die er zo goed als zeker in zit is Local Variable Type Inference. Je kent het principe waarschijnlijk al uit andere (script)talen. Dit kunnen we het beste uitleggen aan de hand van een voorbeeld.

var list = new ArrayList<String>();
var stream = list.stream();

Wat je hier ziet is dat de compiler in staat is om zelf het type van de variable af te leiden. Dit kun je namelijk makelijk uit de gegevens aan de rechterkant van het statement halen. De eerste variable zal als type ArrayList hebben en de tweede Stream. De tweede is iets lastiger, maar dit is simpelweg het returntype van de stream methode.

Daarnaast zit Generic Specialization eraan te komen. Dit houdt in de we straks ook Collections van primitieven kunnen hebben. Het is nu alleen mogelijk om de Collections API op objecten te gebruiken en dus niet op simpele waarden zoals int, boolean en char. In code ziet dit er dan alvolgt uit:

List<char> charList = new ArrayList<char>();

Tot slot was het ook interessant om te horen dat alle verschillen tussen OpenJDK en de Oracle JDK gaan verdwijnen. Oftewel alle extra tools (zoals Mission Control en daarin de Flight Recorder) zijn straks zonder lastige Oracle restricties te gebruiken door iedereen.

Live vanaf JavaOne ’17 #2

Vakmensen, dat zijn we. En wat we doen op het gebied van informatie- en communicatietechnologie helpt organisaties slim verder. Effectief en meetbaar bovendien. Aangenaam, CINQ. Specialisten in Data, DevOps en Development. Wij geloven in specialisten, vandaar de driedeling Data, DevOps en Development binnen ons bedrijf. Zo zorgen we dat jij excelleert, want je werkt het best waar je je het meest thuis voelt. Logisch, toch?

cinq_logo.png

CINQ ICT

We delen graag onze kennis over Data, DevOps en Development met je. Op ons blog lees je tips en tricks over bijvoorbeeld Splunk, Docker, Kubernetes en Java.

Onze laatste blogs over Development