As a front-end developer, I work with a lot of tools to develop code. There are a few popular tools that I use and recommend for programming better front-end applications. Also, I would like to describe what I do to manage applications and how to simplify the process. It can be a really difficult process when you are building a bigger front-end application. I will explain the tooling that I use in this article.

Find and fix problems in your JavaScript code

The first recommended tool is ESLint. Most of the newest JavaScript applications are using Typescript. With the combination of ESLint and Typescript, the code quality will improve. When you are using this tool, it is possible to enforce standards for your team, but also for yourself. On the other hand, it helps you to think about your code and will help you when you forget something. For example, if you forget a type definition for one of your methods.

You can start with ESLint by installing it via npm. After installing ESlint you will find a configuration file in the root of your folder directory called eslintrc.json. The recommended way is to use a config like this:

"extends": [
  "eslint:recommended",
  "plugin:prettier/recommended",
  "plugin:@typescript-eslint/recommended"
],

I do not like to have a lot of custom configuration. This helps to prevent discussion within the team about specific rules. There are some rules that I do recommend. One of these is a simple rule to give an error for unused imports. To enable this rule, you will need a plugin.

In your rule configuration can you define what you should do in case of unused imports.

"@typescript-eslint/no-unused-vars": ["error"],
"unused-imports/no-unused-imports": "error",

In addition to these rules, I have a few other rules. I always want to give a type definition for a return function and do not allow the use of the any type. You can read the complete documentation of ESlint on the website.

An example eslint configuration can be found here.

One of the biggest frustrations, when I start at an existing project, is having no code standards. You want to talk about the function of the new code when somebody has opened a pull request and not about its formatting. That is why code standards are important. Of course, both are important, but formatting should be consistent across files. That is pretty hard when you do not have rules or principles. We cannot automate everything, but some tools can help us. One of these tools is Prettier.

Prettier is a tool that you can use in your codebase to format your code. It supports a lot of programming languages. You do not need to discuss style in your code review and this will save you time and energy. After you install it with npm, you also have a simple configuration file called prettierrc.json. I use a configuration like this:

In the above example, you can see a few options. I want to use a maximum of 140 characters per line, not use double quotes, and format with spaces instead of tabs. The complete list of the Prettier options can be found on their website.

An example Prettier configuration can be found here.

Automate your code standards before you commit

The next step would be automating the tools above. I prefer to do two different things. The first one for Prettier is to implement an auto-save functionality for your code editor. For example in Visual Studio Code, you can create a settings.json in a .vscode folder at the root of your codebase. You can set a default formatter and a format on save boolean for the whole project. The default formatter below can be installed as a plugin.

"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,

The other step is to implement a pre-commit hook before you commit definitively to your repository. I use the tool Husky for that part. Husky is a tool to lint your commit messages, run tests, and in my case run the lint rules above. Also, it is possible to combine those. I often use it for linting code and running unit tests.

You can install Husky via an automatic command. It will give you everything you need for your first pre-commit hook, including an example to run your test. You can also install Husky manually. The steps to do this can be found here. After installing you will find a .husky folder in the root of your codebase. Inside this folder, you will find the commit hooks that are used. 

The latest step to prevent adding bad code in your codebase is to use the tool lint-staged. With this tool, it is possible to run linters over staged git files. By using this tool you can have control before you push code into the repository. To use lint-staged you need to install it via npm. After that part, you can configure which files are checked while using the lint-staged command. You can do this via a lint-staged part in your package.json or via .lintstagedrc.json file in the root of your directory. The recommended way is to use a config like this:

{
  "*.{ts,tsx,html}": "eslint --cache --fix",
  "*.{ts,tsx,html,scss}": "prettier --write"
}

The example above also includes a fix flag for eslint and a write flag for prettier. During the pre-commit phase, files are changed automatically when possible. To use lint-staged in your pre-commit hook, add a file like this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
 
npx lint-staged
npm run lint

It does not always stop everything, but it does help. To get control over your application, I can recommend running linters and tests to your pipeline. In that case, you know for sure that your code has been checked.

An example Lint-Staged / Husky configuration can be found here.

It can be difficult to produce quality code when the business is waiting for new functionality. To improve code quality, I use SonarQube. This tool helps you to find bugs, code smells, vulnerabilities, and duplications. It is available in a lot of languages including JavaScript, TypeScript, HTML, and CSS. For brevity, I will not explain how you should install SonarQube in this article, but I hope you see the added value.

SonarQube does scan your static code. For me, the greatest benefit is the simplicity of the code, which helps to better understand other developers' code and make fewer mistakes in the code. After the scan, you see metrics of complexity, vulnerabilities, and duplications. This information increases your productivity, maintainability, and consistency. I believe that this can help you to increase the lifetime of the application. In addition, it will help to improve your developer skills.

Each front-end application consists of a lot of packages. These are included in the package.json with a specific version. It is important to update these packages regularly. If you do not, you get a big bang upgrade scenario which takes a lot of time, or more importantly, you could get security issues. Furthermore, your application can be outdated for specific devices. It can make future development hard when you postpone this.

Like using hooks you can use a bot to update these packages. Renovate is one of these bots which you can use for automated dependencies updates. It scans your dependency tree for old versions and updates them via a pull request. First, you should connect Renovate to your repository, so it has permission to read your codebase. Then you can create a renovate.json in the root of your directory. There are some configurations that I can recommend to use. One of these is to auto-merge for a minor or patch update.

“packageRules”: [
  {
      “matchUpdateTypes”: [
      “minor”,
      “patch”
    ],
    “automerge”: true
  },
]

By default, Renovate will create a PR for every package that can be updated. There is a rule to group packages so that we get fewer pull requests. You can create groups based on a pattern. With this can you bundle packages. In the example below I created a group for eslint. This combines updates for eslint and @next/eslint to a single pull request.

{
    “matchPackagePatterns”: [
    “^eslint”,
    “^@next/eslint”
  ],
  “groupName”: “eslint”
},

There are many more options to configure. For instance, when Renovate should run and how many pull requests are allowed to be open at the same time. Auto merge is useful if you have a good CI/CD pipeline with linters, tests, and finally deployment. The complete documentation can be found on the website.

An example Renovate configuration can be found here.

A great part of this article goes about consistency and automation. The code must be clear for other developers and yourself. The lifetime of your application will be longer when you have good maintainability. A few simple tools and configurations can make the code a lot better. Why not use it? It will not get any worse.

I am working hard for code consistency. In my experience, I want to discuss what the code should do and do not like to talk about personal preferences of coding standards. By automating and maintaining you avoid the discussion. Hopefully, this article is helpful for your challenges with developing front-end applications.

Which tools do I use for improving front-end applications?

Deze presentatie gaat over het verbeteren van je debugging game. De meeste ontwikkelaars gebruiken alleen het spreekwoordelijke topje van de ijsberg bij het werken met de debugger. Er valt nog zoveel meer te leren, dus laten we eens kijken naar interessante mechanismen zoals:

frames laten vallen ("teruggaan in de tijd")

foutopsporing op afstand (waarom op uw lokale computer blijven?)

hot code swapping (sneller dan het opnieuw implementeren van de code)

stream debugging (voor die moeilijk te debuggen streams)

De hele presentatie zal in IntelliJ zijn. Sommige delen zijn specifiek voor IntelliJ, maar de meeste delen zijn van toepassing op alle IDE's.

Improving your skills with the debugger by Bouke Nijhuis

Bouke Nijhuis
Bouke Nijhuis is CTO bij CINQ ICT. Hij vindt het leuk om nieuwe dingen te leren en hij vindt het nog leuker om die aan andere mensen uit te leggen. Verder is hij een internationaal spreker en een committer van open source projecten. Je kunt hem bereiken op Twitter via @BoukeNijhuis.

Bouke Nijhuis op Devoxx 2022 - Improving your skills with the debugger

Sinds ongeveer een jaar werk ik met Kotlin, een taal die ik persoonlijk zie als de spirituele opvolger van Java. Het wordt ontwikkeld door JetBrains, de ontwikkelaars van de populaire editor IntelliJ, en heeft een hoop voordelen ten opzichte van Java. Deze voordelen zijn ook niet dusdanig obscuur dat ze niet opvallen - ik gebruik ze bijna dagelijks. In deze blogpost wil ik een blik werpen op welke onderdelen van Kotlin mij helpen, en in sommige gevallen hoe ze zich verhouden tot Java.

Het belangrijkste voordeel wat Kotlin tegenover Java heeft is misschien een valse start, maar het is de reden dat Kotlin zo groot aan het worden is denk ik, en dat is de Java interoperability. Dit houdt in dat Kotlin vlekkeloos samen kan werken met Java in dezelfde codebase. Nog beter, wij kunnen Java-code aanroepen vanuit Kotlin en omgekeerd Kotlin code aanroepen vanuit Java. De compiler heeft hier geen problemen mee en zal zijn werk doen zoals altijd.

Het grote voordeel hieraan is dat Kotlin overal geadopteert kan worden waar Java wordt geschreven. Als een team niet comfortabel is met Kotlin kunnen zij kiezen om kleine stukken van de code te pakken en die om te schrijven naar Kotlin, om zo gaandeweg meer ervaring op te doen met Kotlin en comfortabeler te worden met de taal.

Voortbouwend hierop is dat de ontwikkelaars bij JetBrains er alles aan hebben gedaan om de conversie van Java naar Kotlin zo makkelijk mogelijk te maken. In hun IDE, IntelliJ, hebben zij de functionaliteit ingebouwd om Java-code in een Kotlin bestand te plakken (via copy-paste) om een popup te tonen die vraagt “Wil je deze code omzetten naar Kotlin?”. Als er akkoord wordt gegeven zal IntelliJ zelf de Java-code converteren naar Kotlin code dat in 99% van de gevallen klaar is voor productie. Dit kan een software engineer helpen om bekende Java-code automatisch te converteren en het resultaat te bestuderen om Kotlin beter te leren begrijpen. Er wordt immers vanuit een bekende basis gewerkt in dat geval.

Nu voor de echte start, en mijn persoonlijke favoriet: data classes. In Java bestaan de zogeheten POJO’s, of Plain Old Java Objects. Het zijn simpele objecten met een aantal velden, en methodes om de waardes van die velden op te halen of te veranderen. Een voorbeeld hiervan voor een boek klasse is als volgt:

public class Book {
     private String title;
     private String author;
     private int amountOfPages;
 
     public Book(
         String title,
         String author,
         int amountOfPages
     ) {
         this.title = title;
         this.author = author;
         this.amountOfPages = amountOfPages;
     }
 
     public String getTitle() {
         return this.title;
     }
 
     public String getAuthor() {
         return this.author;
     }
 
     public int getAmountOfPages() {
         return this.amountOfPages;
     }
 
     public void setTitle(String newTitle) {
         this.title = newTitle;
    }
 
     public void setAuthor(String newAuthor) {
         this.author = newAuthor;
     }
 
     public void setAmountOfPages(int newAmountOfPages) {
         this.amountOfPages = newAmountOfPages;
     }
 }

De bovenstaande klasse bestaat uit 38 regels code en is erg simpel. Er zijn drie velden, title, author, en amountOfPages, een enkele constructor, en de getters en setters. Kotlin kan dezelfde code genereren door een data class aan te maken. In het geval van een Book klasse gaat dit als volgt:

data class Book(
     val title: String,
     val author: String,
     val amountOfPages: Int
 )

Dat is alles! Vijf regels code en hetzelfde resultaat is bereikt als de 38 regels van Java code. De Kotlin code beschrijft een constructor tussen de gewone haakjes, en daarbinnen de drie datavelden die wij willen. De compiler zal begrijpen wat nodig is voor de data class en daarmee alle getters en setters genereren.

Het bestaan van de data class maakt het zoveel eenvoudiger om een POJO (of eigenlijk POKO in dit geval) te maken dat het erg aantrekkelijk is om “even gauw” een data class ergens voor aan te maken omdat dit simpelweg eenvoudiger is dan ingewikkeldere constructen zoals een tuple of pair.

De data class is niet de enige soort nieuwe klasse. Kotlin kent voor de visibility van classes naast de private, protected, en public types ook de types sealed en internal.

Een sealed class is een klasse of een interface waarbij alle subklassen en implementaties bekend moeten zijn tijdens het compileren van de code. Dit zorgt ervoor dat een derde partij niet nog een extra subklasse later toe kan voegen als er bijvoorbeeld een library geschreven is (de klasse is “sealed” voor verdere subklassen). Sealed classes hebben hun weg wel gevonden naar Java als een preview sinds Java 15, en als volwaardig onderdeel sinds Java 17. Echter, ze zijn langer aanwezig in Kotlin en hebben betere support. In Kotlin is het bijvoorbeeld mogelijk om een sealed class in een switch statement te gebruiken - Java staat dit als preview functie toe in Java 17, maar er is nog geen officiële support. Ook is Java stricter in het gebruik van sealed classes. De sealed class zelf moet expliciet aangeven welke subklassen toestemming hebben om een extension te maken via het keyword permits.

In mijn optiek zorgt dit voor meer verbose code en ligt mijn voorkeur bij de aanpak van Kotlin. Daarbij mag elke klasse een subklasse zijn, maar de subklassen moeten in dezelfde file als de sealed class staan. Een voorbeeld daarvan staat hieronder. Het werken met sealed classes vind ik zelf erg fijn in Kotlin doordat de code compact is, en ik weet dat ik klassen kan schrijven die alleen de subklassen heeft die ik wil, wanneer dan ook. Dit kan recente versies van Java inmiddels ook.

sealed interface Error
 
sealed class IOError(): Error
class CustomError(): Error

Een companion object is een manier in Kotlin om statische variabelen te maken die onderdeel zijn van een klasse, maar gebruikt kunnen worden zonder de klasse te instantiëren. Doorgaans gebruik ik een companion object zelf om statische variabelen aan een klasse toe te wijzen zoals normaal in Java gedaan zou worden. Dit gaat heel eenvoudig op de volgende manier:

class Coffee {
     companion object {
         const val optimalTemperatureInCelsius: Int = 140
     }
 }

Belangrijk hierbij is dat er een annotatie extra nodig is voor goede Java interoperability. Door @JvmStatic boven de companion object variabele te plaatsen kan dit bereikt worden. Dit is nodig omdat een companion object in Kotlin kan overerven van klassen of interfaces, maar in Java is dit niet mogelijk.

Er zijn nog andere manieren waarop nuttig gebruik gemaakt kan worden van een companion object. Een voorbeeld hiervan is het Factory design pattern. Door gebruik te maken van een named companion object kan een Factory heel eenvoudig opgezet worden:

class Coffee {
     companion object Brewer {
         fun brew(): Coffee = Coffee()
     }
 }

De factory is Brewer genoemd in dit voorbeeld, en de gebruikelijke createInstance is nu brew genoemd om in het thema van de klasse te blijven. Vervolgens kan de factory gebruikt worden op de volgende manier:

Ik vind persoonlijk null safety erg belangrijk in code, en ik ben erg blij met het type system in Kotlin. Het type system probeert namelijk om null referenties te voorkomen. Dit wordt gedaan door variabelen niet standaard een null mogelijkheid te geven, maar dit expliciet af te laten dwingen. Bijvoorbeeld, bij het aanmaken van een String moet de String een waarde toegewezen krijgen, anders compileert de code niet. Door gebruik te maken van een ? bij de variabele vertel je de compiler dat null toegewezen mag worden aan de variabele.

val someString: String = "Hello There" // mag geen null zijn
val anotherString: String? = null      // mag null zijn

Helaas zie ik in mijn dagelijks programmeerwerk een hoop mensen die denk ik uit gemak toch vaak met null willen werken. Ik zie dit als een soort “Java-isme” wat over is gekomen naar Kotlin. Hierdoor is de code al vrij snel bezaaid met ?s en de bijbehorende if-statements die op null controleren. Gelukkig is Kotlin hier op voorbereid en is er een shorthand voor de null checks in de vorm van, alweer, een vraagteken ?. Dit werkt als volgt:

Kotlin controleert hier of de waarde van anotherString null is of niet. Als er null geconstateerd wordt dan gebeurt er verder niks - de check heeft gefaald. Als er geen null wordt geconstateerd dan heeft anotherString dus een waarde gekregen. In dat geval voert Kotlin het let deel uit en wordt de waarde van anotherString geprint.

Een andere manier van nullable variabelen gebruiken is minder veilig dan de ?, maar kan soms zijn nut hebben. Het kan namelijk gebeuren dat Kotlin een variabele als een mogelijke null ziet, maar als software engineer is duidelijk in de code te zien dat dit nooit kan gebeuren. In zulke gevallen kan gebruik gemaakt worden van een dubbele bang (!!). Dit dwingt af dat de waarde van de variabele gebruikt wordt - ook als dit alsnog null zou zijn. Het gebruik van !! moet dan ook, vind ik, minimaal blijven en het liefste voorkomen worden. Helaas heeft het vele gebruik van nullable variabelen met ? als gevolg dat de code ook al snel bezaaid is met !!s, waardoor de null safety van Kotlin in mijn ogen onderuit wordt gehaald. Dit neemt alleen niet weg dat de null safety van Kotlin een welkome functionaliteit is die goed werkt.

Named arguments neem ik tegenwoordig dusdanig voor lief dat ik verbaast was toen ik (her)ontdekte dat Java deze feature niet ondersteunt. Het is een kleine toevoeging in de code, maar het maakt (in ieder geval voor mij) echt een wereld van verschil. Bij het gebruiken van een functie met argumenten kunnen de argumenten namelijk een toegewezen naam krijgen, zoals gedefinieerd in de functie zelf, maar nog belangrijker is dat ze ook een eigen plek toegewezen kunnen krijgen.

Normaal gezien zou een functie in Java gedefinieerd en gebruikt worden als volgt:

public static Coffee create(String name, int temperature, BeanType beanType) { ... }
 
Coffee.create("Cappucino", 95, BeanType.DARK_ROAST);

In bovenstaand voorbeeld is impliciet duidelijk waar de argumenten voor staan, maar om zeker te zijn moet toch naar de functie definitie gekeken worden. Dit kan nog omzeild worden door de argumenten eerst te definiëren:

String name = "Cappucino";
int temperatureInCelsius = 95;
BeanType beanType = BeanType.DARK_ROAST;
 
Coffee.create(name, temperatureInCelsius, beanType);

Echter, dit zorgt voor meer regels code en is een manier van werken die ik tegenwoordig niet mooi meer vind. De zojuist gegeven voorbeelden kunnen met behulp van named arguments in Kotlin geschreven worden op een mooiere manier.

class Coffee(name: String, temperature: Int, beanType: BeanType)
 
Coffee(name = "Cappucino", temperature = 95, beanType = BeanType.DARK_ROAST)

Nu is direct bij het aanmaken van een Coffee object te zien waar de argumenten voor staan. In dit geval staan de argumenten nog in dezelfde volgorde, maar stel dat we de argumenten in een andere volgorde willen, bijvoorbeeld om extra focus te leggen op het type boon. Dit kan eenvoudig opgelost worden door beanType naar voren te plaatsen. Of stel dat name een standaard waarde heeft die wij willen gebruiken. In dat geval slaan wij het hele argument simpelweg over.

// Andere volgorde
Coffee(beanType = BeanType.DARK_ROAST, temperature = 95, name = "Cappucino")
 
// Argument overslaan. Eerst wordt een klasse definieerd met een standaard waarde voor 'name'.
class Coffee(name: String = "Black", temperature: Int, beanType: BeanType)
 
Coffee(beanType = BeanType.DARK_ROAST, temperature = 95)

Als laatste functionaliteit wil ik de string templates van Kotlin in het licht zetten. Strings zijn in Java lastig om mee te werken, of in ieder geval om te manipuleren. In Kotlin kunnen argumenten direct in de String zelf worden geplaatst. Deze functionaliteit is ontzettend eenvoudig maar voegt zoveel plezier in het programmeren toe, simpelweg doordat een complexe String opbouwen zo makkelijk gaat.

Als voorbeeld, stel dat wij een rekensom uitgeprint willen hebben als String. Dit is in Kotlin direct uit te voeren:

val firstNumber = 25
val secondNumber = 5
 
println("First number is $firstNumber. Second number is $secondNumber.\n$firstNumber / $secondNumber = ${firstNumber / secondNumber}")

De argumenten kunnen direct in de String gebruikt worden door er een $ voor te plaatsen. Bij complexe onderdelen van de String kunnen simpele berekeningen gedaan worden door de berekening te plaatsen binnen haakjes {}. [String templates zijn in versie 19 ook aan Java toegevoegd - red.]

Ik hoop dat deze blogpost meer was dan een simpele vergelijking tussen Java en Kotlin. Kotlin is een programmeertaal die dagelijks het programmeren makkelijker en leuker maakt voor mij dankzij het gemak van de features die het heeft. Het voelt op zijn minst als een goede toevoeging aan het JVM-ecosysteem, en uiteindelijk als een oprechte opvolger voor Java. Als je Kotlin nog nooit hebt gebruikt, geef het een keer een kans!

De dagelijkse voordelen van Kotlin

Simpel, eenvoudig en snel. Je wil snel aan de slag en dat is wat je als frontend developer maar al te graag wil. Bij verschillende projecten heb ik al meegemaakt dat je meermaals (lang) bezig bent met het configureren van de build tool, zonder dat je ook maar toe komt aan een regel programmeren. Dat hoeft niet erg te zijn, maar er zijn leukere dingen om je mee bezig te houden. Vite stelt zich voor als de volgende generatie frontend tooling.

Vite heeft een ecosysteem neergezet waarbij je snel kan beginnen met het ontwikkelen van een project. Hierbij is het mogelijk om direct gebruik te maken van de populaire frameworks als React en Vue, maar ook vanilla JavaScript is een kwestie van je ogen dicht doen. Met zero configuration heb je snel een tooling gereed waarbij je gebruik kan maken van SASS, TypeScript of wat dan ook. 

Vite richt zich op snelheid en performance door de development ervaring te verbeteren. Zo maakt het niet uit hoe groot je applicatie is, de applicatie start altijd snel op. Hot Module Replacement (HMR) zit eveneens in de core configuratie. Hiermee wordt dus alleen herladen wat je op dat moment hebt aangepast. De laatste belangrijke pijler is het compileren/bundelen van JavaScript door middel van ESBuild, welke bekend staat als een van de snelste bundlers van dit moment.

Onder de motorkap maakt Vite gebruik van zowel ESbuild als Rollup. Een van de redenen om gebruik te maken van ESbuild is omdat deze slim overweg kan met dependencies. Doordat deze niet frequent veranderen hoeft deze niet bij elke build opnieuw gecontroleerd te worden. Rollup wordt gebruikt zonder dat je daarvoor iets extra’s hoeft in te stellen. Dat kan natuurlijk wel, net als een heleboel andere dingen.

Vite omschrijft zichzelf dus als de tool die gebruikt maakt van de nieuwe ontwikkelingen van het ecosysteem; de beschikbaarheid van native ES-modules in de browser en de opkomst van JavaScript tools die compilen tot native languages. 

Nu de theorie veel belovend klinkt ben ik benieuwd hoe dit in de praktijk zal uitpakken. Begin een Vite project met het volgende commando in de terminal:

Bij de eerste keer van dit commando krijg je de vraag om de laatste packages te installeren, waarna je het project van een naam en framework moet voorzien. 

npm create vite@latest
Need to install the following packages:
  create-vite@latest
Ok to proceed? (y) y
✔ Project name: … vite-cinq
✔ Select a framework: › react
✔ Select a variant: › react-ts

Scaffolding project in /Users/jeroen/Development/_temp/vite-cinq...

Done. Now run:

  cd vite-cinq
  npm install
  npm run dev

Na een npm install en npm run dev is mijn lokale omgeving tussen 350-500 ms opgestart. Dat is best snel en dat zonder enige configuratie. Om het wat spannender te maken heb ik het React TypeScript TodoMVC 2022 project uitgecheckt en in mijn Vite project geplaatst. De conclusie was al vrij snel dat ik tot hetzelfde resultaat kwam als bij de initiële setup. Ook de standaard beloofde Hot Module Replacement (HMR) deed wat het moest doen. Ik heb op geen enkel moment een harde refresh van de hele applicatie nodig gehad. 

Het bouwen van productiecode gaat even makkelijk als het starten in de development mode. Hoewel dit bij andere tooling ook wel te doen is, lijkt het voor mijn gevoel sneller te gaan. Een mooie toevoeging is dat je na het commando npm run build ook een commando npm run preview hebt om het eindresultaat snel te kunnen zien. Dat vind ik een leuk pluspunt.

Zo zijn er nog meer dingen die out of the box al standaard werken, bijvoorbeeld:

het toevoegen environment variables volgens de dotenv structuur; 

het gebruiken van CSS modules en/of CSS Pre-processors;

het instellen hoe je assets ingeladen moeten worden en;

het gebruiken van global en dynamic imports.

Of Vite de vervanger van Webpack gaat worden durf ik niet te zeggen. Net als met veel andere tools en frameworks gebeurt er veel onder de motorkap, waardoor je niet zelf inzicht hebt over hoe en wat er gebeurt. Je hebt alleen zicht op de input en de output. Bij Vite vind ik het verschil tussen development (esbuild) en productie (rollup) niet prettig.

Al met al krijg ik over Vite als tool een goede indruk, omdat het mij – na een paar uurtjes ermee spelen – een positieve vibe geeft aan de developer experience. Je krijgt veel out of the box om een snel een project te kunnen starten. Dit maakt het voor mij toegankelijk om hier bij een greenfield project voor te kiezen. Of je ook echt moet willen dat een tool je (snel) alles geeft betwijfel ik. Graag zou ik wat meer controle willen hebben.

Wordt ViteJS de opvolger van Webpack?

In this blog, I would like to share something I recently discovered when studying for the Java 11 certification. Strangely enough, it is not a new Java 11 feature. It’s not even something introduced in Java 8 or 7. No, it’s something that's been around since the early days of version 6. It’s the ServiceLoader class. A long-forgotten feature which thanks to the introduction of modules in Java 11 has become especially relevant again.

The ServiceLoader class was first introduced in Java 6. It was used to make applications extensible, so you could add functionality without recompiling the whole application. Basically, the SeviceLoader scans the classpath looking for an implementation of any interface you may want and returns the results, which then can be used at runtime in your code. Essentially, this is a form of dependency injection.

Dependency Injection
What is dependency injection and why is it important? Quality code should adhere to the following design principle:

This principle is not rocket science. It simply means that an object that uses another object should not create that object, but instead receive the objects it is dependent on. This technique is called dependency injection.   

There are many ways of injecting dependencies into objects. 

1 - You could use a framework. There are quite a few dependency injection frameworks Java developers can choose from. For example, Spring Framework or Google Guice are very popular. 

2 - However, a framework is not necessary. There are far simpler techniques for achieving the same goal. There are several methods of dependency injection in Java without the need of leveraging third party frameworks and only rely on simple regular everyday code. The simplest are: 

Constructor injection. The dependencies are injected via constructor parameters. 

Setter injection. After the object has been initialized, setter-methods are used to add the dependency. 

Factory method. Similar to the Constructor injection method, however, the constructor is called with the necessary parameters within a method belonging to a Factory class.  

Factory injection. This is an improvement to the Factory method. By implementing the Factory Pattern. Basically, all the logic needed to initialize the object with all the necessary dependencies are abstracted away within an independent class, a Factory class. This object internally decides which dependencies are needed. 

The main advantages of these methods are that you don’t need to add any external libraries to your build path, nor do you need to use any ‘funny looking’ annotations to tell the framework what needs to be injected and where. It is done in plain old, easy to understand Java code.  

3 - “But I need to dynamically switch between implementations in my code”, I hear you say. Yes, there are some use cases where you may need to load an implementation of a class at runtime. Luckily, that’s not a problem in Java. There is the ServiceLoader class. 

As previously discussed, this class has been around since version 6, and can be found in the java.util package. This class will scan through the classpath or (from version 11) through the module path of your application and retrieve the available implementations. Giving you a Java native way of dynamically loading classes and injecting them into objects. Most probably in conjunction with some kind of Factory class to abstract away some of the code.

Module path
Before we dive further into the workings of the ServiceLoader class, I need to discuss the new module system introduced in Java 11. 

In layman terms, in Java 11 the classpath has been replaced by a module path. Don’t panic, you can still use a classpath, but this is no longer advised. 

The biggest difference between a classpath and the newer module path is that when using a classpath Java searches through all the locations designated on the classpath looking for the class to use. Often, this works fine. However, it is possible to have multiple instances of the same class defined on your path. And because Java has no strict way of traversing through the classpath, your application will randomly use different implementations of a class. Potentially causing all kinds of unpredictable problems, colloquially called “Dependency Hell”.

This has been fixed in the module path way of working. Instead of an unorganized collection of available classes. Classes and packages are now ordered into neatly organized modules. And because modules need to declare which classes they make accessible for other modules and which modules they use; java has the ability to validate all modules loaded at compile time helping to prevent dependency hell. 

The ‘exports’ keyword is used for making packages available and the keyword ‘requires’ is used for declaring which modules are used. This information is placed in the module-info.java file, which can be found in the source folder.

ServiceLoader
As previously described, the ServiceLoader is able to search the classpath looking for implementations. But how does it work when using a module path? Modules no longer implicitly expose any classes. Therefore, an implementation (also called a Service in Java 11) needs to be exposed to the outside world. This is done by using the keywords ‘provides … with ...’. Also, you need to declare that a module uses an external implementation. This is done by using the ‘uses’ keyword.

Module 1 – The module exposing (exporting) the interface
Module definition

Module 2 – The module providing the service implementation (doesn't need to be exported!)
Module definition

 Module 3 – The module using the service: 
The module definition of a module using a service.

If all the modules have been correctly defined, then using the ServiceLoader is easy. You only really need to know one static method ‘load’ which takes a class as a parameter and returns a collection of Classes. Because the ServiceLoader can retrieve an unknown number of classes, you will have to write some code to determine which class instance (if any) to use.

Summary
To quickly summarize. In many cases of injecting dependencies, we don’t need a framework to get the job done. Java out-of-the-box offers us the tools needed to solve the problem of dependency injection.

In this blog, I would like to share a long-forgotten feature which has become especially relevant again, the ServiceLoader class

The ServiceLoader and Native Dependency Injection in Java 11

In this blog I want to give a short introduction into the use of monads in Java. Interestingly, the concept of a monad has been around for quite some time now. Originating in mathematics it’s a design pattern which has previously only been popular in functional programming languages. However, it has found its way to Java. There is even a large chance that you have already been using them unknowingly. Especially, if you have been using the Optional and Stream libraries introduced in Java 8. So, what is a monad and how does it help me write clearer code? 

The Problem
First, I’m going to start with the problem that a monad helps us to solve. Its main goal is to help abstract away boiler plate code that isn’t the main concern of your code. Think of null checking, exception handling, validation, logging, concurrency, etc. 

In this first code block, four classes have been declared. The first three classes represent a bank with customers which in turn may each have an active account. The Bank class has a single method which returns the Customer with the supplied id. The Customer class has a single method which returns the customer’s Account. The Account class also has a single method which returns the balance of the account. The final class ATM has a single method which takes a Bank instance and an id as a parameter and returns an account's balance.

The problem is that the methods in Bank, Customer and Account may return null. The id might not be correct, or the customer may no longer have an account at the bank, or the balance may not be available. This will result in the fetchBalance method of the ATM class throwing a NullPointerException, which will cause the program to crash.

We can fix this by refactoring the fetchBalance method to check if each value returned by Bank, Customer or Account happens to be a nullpointer (Alternative 1). We can all agree that this code works, but it’s not a pleasure to read. Alternatively, you could use nested if-statements to check for not null. However, this also has little effect on the readability of your code (Alternative 2).

 Another alternative (Alternative 3) would be to place the code in a ‘try-catch’. This would improve the readability, but hide the cause of the exception, limiting your ability to later add some code to be able to recover from the exception. 

What is a Monad?
 So, what is a monad and how can it help us write more readable code? A monad is defined as any class (data type), which represents a specific calculation. It must implement at least these two functions:

A function to wrap any basic value, creating a new monad. Also called the return function.

And a function that allows you to perform operations on a wrapped data type (monad). Also called the bind function.

It must also adhere to the following three monad laws:

Left identity, passing an operation to a monad should yield the same result as applying the operation to the original value.

Right identity, passing a wrapper function to a monad should yield the same result as creating a new nomad.

Associativity, when chaining functions, it should not matter how the functions are nested.

The first two identity laws basically say that the only thing the return function is allowed to do is to wrap the object. It cannot manipulate the data in any way.

The final law ensures that it doesn't matter how bind functions are nested, the results are the same. Which simply means that the same sequence of operations will always produce the same value.

In Java the Optional class has all the necessary characteristics of a monad:

Does it represent a specific calculation? Yes, it encapsulated a mechanism for performing actions on values safely without causing a null pointer exception. 

Is there a function for wrapping basic values and creating a new monad? Yes, ofNullable which takes any value and returns a new Optional instance containing that value. 

Does it have a function to allow operations to be performed on its contained value? Yes, flatMap does the trick nicely. 

Does it adhere to the three monad laws? The short answer is yes.

Other commonly used monads found in Java include: Stream<T> (and all the different types of streams) and CompletableFuture<T>.

How do monads solve our problem?
Now that we know what a monad is, let’s use the Optional monad, also known as the Maybe monad in other languages, to clear up our code.


Refactored code using the Optional monad.

We start by changing the return type of the getter methods in the Bank, Customer and Account classes, we do this by using the ofNullable method to wrap the return values. Thanks to the Optional we have also clearly declared that the methods may return null. 

Then, we refactor the ATM's fetchBalance method. First, we wrap the Bank input parameter in the Optional monad. Finally, we use a chain of flatMap calls to perform operations on the wrapped value. Each time calling a getter method to replace the value inside the Optional with a new value. If at any time the value becomes null, any remaining transformations have no effect.

After refactoring, we end up with code that is easier to read and safer to run. The messy null pointer checks have been abstracted away and you are left with a chain of declarative transformations. Not bad.

 And now?
I hope you enjoyed reading this introduction to monads in Java. Now that you have a general idea what a monad is, you should have an easier time following other more in-depth articles, blogs or presentations about this subject.

In this blog I want to give a short introduction into the use of monads in Java.

Monads in Java: a short introduction

Don’t worry! I’m not going to talk about dressing up casually for work as the title may suggest. This is going to be a little story on how, after eight years since introduction, I stumbled into using functional style programming. Apart from using the occasional Java Stream here and there, I never wrote any code in a functional style kind of way. Until now that is…

An important aspect of my current project is logging. One of the requirements we defined for testing is that we want to be able to assert that things are logged correct. The objective was simple. Write a piece of code that can do that in an easy way (and if the code is flexible then that is a plus).

As a huge clean-code fanatic, instead of starting to type relentlessly and crank out the code as I go, I started at the end. How do I want it to look when I use my custom made class? How can I design it in an elegant way?

Asking myself these kinds of questions made me sort of design the code upfront. Which sounds to me like doing the right thing. And while I am at it I might as well throw in some TDD and write a test for my custom LoggerSpy first.

Awesome! Short, concise and it does the job. Although it is clear what LoggerSpy does, it isn’t very flexible. It accepts a string and checks if the list of log events contains a message that exactly matches the given string.

But what if I want to check if the log contains a message that ‘starts’ with a given string? Or ‘ends’ with it? Or complies to a certain regex? Should I make extra public methods in my LoggerSpy for each of those checks? That doesn’t sound overwhelmingly flexible.

My next design attempt was something along the lines of the Hamcrest library. It’s time to introduce the ‘equalTo’ matcher.

Now I could potentially make a matcher for every way I want to match my  log message against a given string. The code reads well, it is flexible, the call to containsMessage is very self-explanatory and it looks nice also. This seems like a good time to start implementing the whole thing.

My first reflex for implementing LoggerSpy was doing it hardcore Java style. None of that functional style voodoo code! (Note: by voodoo code I mean code that seems to work great but you don’t quite understand what it does or how it exactly works) 

Job accomplished. My design is implemented. The usage of the LoggerSpy is clean and simple. But we already knew that since we designed it upfront. The only thing that bugged me was the amount of boilerplate code needed.

1. for each type of matcher (equaITo, startsWith etc.) I had to create a separate class, create a static method that accepts a String value and create a field to store the String value. While actually the only thing that truly matters is this piece of code: 




2. and since I have to create a different class for each type of matcher, I had to create an Interface (LoggerSpyMatcher) as well in order to pass along all my different types of matchers to the containsMessage method.

But altogether a very good attempt. The main goal was easy and flexible in use. Commit-Push. Next story…

A week or so later I accidentally stumbled upon a talk by a software engineer called Mama Samba Braima (aka Nelson). In that talk he explained functional style programming in an easy to follow manner. What first seemed like reading a book written in Chinese started to make some sort of sense to me all of a sudden.

What if I saw functional style programming as a way to create methods that you can pass along to another method and execute it inside that other method when needed? Although this explanation feels like selling the concept of functional style programming a bit short and not telling the whole story, it was a good metaphor that helped me visualize it a bit better. All of a sudden the idea of refactoring my LoggerSpy functional style was born.

If you take a look at the java.util.function package you’ll see all these kinds of interfaces. Consumer, ObjLongConsumer, Supplier, DoubleSupplier, Function, BiFunction, Predicates. There are 43(!) of those guys in there. Not very inviting to read.  

But as it turns out these functional interfaces are basically descriptions of the kind of method that you want to pass. It defines the input parameter(s) and the return type, for instance:

a Function<String, Integer> represents a method that you want to pass which accepts a String as input and returns an Integer as output.

a BiFunction<String, Long, Integer> represents a method that you want to pass which accepts a String and a Long as input and returns an Integer as output.

a Consumer<String> represents a method that accepts a String and returns nothing.

a Supplier<Integer> is the opposite of a Consumer, it accepts nothing but returns an Integer

a Runnable doesn’t accept anything and it also returns nothing. It’s like Nike. It just does something. 

a Predicate<Person> represents a method that accepts a Person object as input and returns a boolean.

There are many more functional interfaces but it is basically all the same.

I read about Functions… and then it clicked…

As you can see in the code example above, my “matches” methods in the non-functional style LoggerSpy  accept a list of ILoggingEvents and return a boolean.

So, for my functional style LoggerSpy to work I need to create matchers of type Predicate<List<ILoggingEvents>>.

That piece of code above looks confusing at first glance. EqualTo returns a LoggerSpyMatcher while events.stream().anyMatch() would return a boolean, huh??? But it is not the value (or the outcome) of the anyMatch method that the equalTo method returns. Nope, it is the “logic” itself that the equalTo method returns.

Looking good, but all I have created up until now are my “methods” that I want to pass to the containsMessage method of the LoggerSpy. I can pass along all the matchers that I want but at this point it doesn’t do anything.


The only thing that I need now is a way to invoke the matcher. That is where the “Single Abstract Method” (SAM for short) of a functional interface comes into play. 

All I have to do now is call the SAM on my matcher object inside my containsMessage method. Calling that method on my matcher invokes the method that I just passed into my containsMessage method and returns a boolean result.

… and I use LoggerSpy in my tests like this

Super clean, simple and easy to use. Never thought that I would end up actually using functional style programming after all this time. But I have to admit… I kinda like it!

The full working example can be found on my GitHub:

https://github.com/vlouisa/logger-spy/tree/feature/functional-style

https://github.com/vlouisa/logger-spy/tree/feature/non-functional-style

Functional style programming - a story of a software engineer who tries it for the first time.

Functional style programming in Java

Oh no! I am going functional style after all this time...

In april 2021, Bouke Nijhuis has discussed 4 tips for passing the Java 11 Developer exam. In this blog I am going to expand on those original tips and add some more. 

The Java Developer exams are notorious for asking difficult and misleading questions. But why do so many people find them so hard? Do they just lack experience? Are the questions incredibly difficult? Don’t you have enough time to answer all the questions? The simple answer to all these questions is ‘No’. Not that it’s an easy exam, but with the right preparation you can pass it during your first try.

A previous blog has discussed 4 tips for passing the Java 11 Developer exam. In this blog Ian van Nieuwkoop is going to expand on those original tips and add some more.

Onze laatste blogs over Development

Which tools do I use for improving front-end applications?

Bouke Nijhuis op Devoxx 2022 - Improving your skills with the debugger

De dagelijkse voordelen van Kotlin

Wordt ViteJS de opvolger van Webpack?

The ServiceLoader and Native Dependency Injection in Java 11

Monads in Java: a short introduction

Oh no! I am going functional style after all this time...

Four more tips to pass the Java SE 11 Developer exam

De CINQeria; een wereld van microservices en frontends

Is Flutter de toekomst van cross-platform native apps?

Waarom ik nog steeds Angular gebruik, maar ook andere frameworks niet vergeet