According to Wikipedia, unit testing is a method by which individual units of source code (…) are tested to determine whether they are fit for use. “Fit for use,” is a very broad concept, and for unit tests it typically corresponds to how the author-developer in question looks at their implementation. Better tests are less tied to the implementation, but they nonetheless provide validation of an implementation against someone’s view of the desired behavior. Sometimes, though, it’s also behavior of the developer that we want to validate, using tools like Checkstyle or test coverage tools. I see also a distinct other class of validations, the ones where a unit test validates code constructs against agreements in the team. I’m specifically talking about code constructs that are locally relevant, so not the ones that the software industry has an opinion about, and probably has (better) tools for also. These are the ones where we crafted our own validations, some of which might qualify as “poor man’s”.

While there is plenty of excellent material out there about Docker, the bi-weekly lightning talks that we do at my workplace are a good opportunity to bring some basic information about this awesome technology in front of engineers in our team that would otherwise not easily be exposed to it (for instance because they mostly work on very unrelated parts of our stack, like the user interface). This particular lightning talk was the first that I did in a possibly long series about many aspects of our cloud deployments. I used the five minute lightning talk format to introduce Docker containers.

How to add custom properties to JWT tokens in Spring Security.

I’m excited about this new library I ran into and I would like to share the excitement. It’s called Restito, it’s on GitHub, and I actually found it on a blog from 2012, so… where were you all this time?

According to Wikipedia, unit testing is a method by which individual units of source code (…) are tested to determine whether they are fit for use. “Fit for use,” is a very broad concept, and for unit tests it typically corresponds to how the author-developer in question looks at their implementation. Better tests are less tied to the implementation, but they nonetheless provide validation of an implementation against someone’s view of the desired behavior. Sometimes, though, it’s also behavior of the developer that we want to validate, using tools like Checkstyle or test coverage tools. I see also a distinct other class of validations, the ones where a unit test validates code constructs against agreements in the team.

20 GOTO 10, infinite loop (can’t argue with Urban Dictionary). It is the higher language equivalent of the “jump” instruction (JMP) used to change the instruction pointer register, in assembly language.