We have come a long way since the introduction of Servlets back in 1999. Back then, implementing and getting to run a Servlet required a lot of development, class overloading, XML configuration and a host of other tasks. It prompted improvements like Java Servlet pages and the subsequent move towards frameworks like the model-view-controller model with Struts that have evolved from framework to framework to where we are today, with powerful frameworks like Spring Boot, Micronaut et al. But the Servlet component has not remained idle through those times.

Breadcrumb navigation, known to some as cookie crumb navigation or navigational path to others, where a path like structure is displayed, most commonly at the top of the current page, that typically shows you the path of pages that you as the user took to get to the page where you are now is a well known staple of many websites. And, when implemented properly, is a very helpful feature on many websites. But for every good implementation there is a bad one, and all the bad ones are there usually due to an age old mistake: trying to fix a problem by addressing the symptoms instead of solving the actual underlying problem. A problem that should not have been here in the first place. A problem that even the good implementations usually fail to address which in turn has created a much larger problem.

Because everyone should use Hexagonal architecture…​ except when they shouldn’t.

Zero Trust; you’ve probably, at the very least, heard of the term. Some may have worked on a project where a Zero Trust policy was in effect, and others may well be working for a company with a company wide Zero Trust policy in effect. But do you know what Zero Trust actually entails? And if you know, do you know how best to develop software that has to comply to a Zero Trust policy?

Depending on your level of exposure to Zero Trust, you may well have had a bad experience with it, may not want to have anything to do with it, or may not want to develop in such an environment at all. If you had a bad experience, it is most likely due to the company or project not understanding the Zero Trust methodology and implementing it incorrectly; but that is a subject for different blog post. Regardless of your experience with (or opinion of) Zero Trust, this post will give you some helpful hints on how to best develop for a Zero Trust environment.

Password must be at least 12 characters long, must include lower and upper case letters, must include numbers, must include special characters, must have at least 3 numbers, must have at least 2 special characters, may not include words in the dictionary. Your password is rejected because it does not comply to our policy. A policy that isn’t published anywhere, but you must make one that complies anyway. Your password has expired, make a new one that does not resemble any of the passwords that you have created in the past. And it’s all useless. We’re all doing it wrong.

We have all gotten acquainted with git in the last decade. We have adopted a way of working that has made it easy for all of us to work together in large teams and reduced the times our code changes collided to a minimum. When we do run into problems, they’ve culminated to a single important moment; the merge. We all know the merging feature of git with all its pro’s and con’s. But what about another feature of git: rebase?