Thoughts on agile software development
The last article described how the .version variable in FreshMarker can always be kept up to date. In this article, we want to simplify the use of the variable.
As the .version variable was previously of the string type, it was only possible to work with the string comparison operators and built-ins.
FreshMarker is strongly characterised by KISS and YAGNI. This makes the template engine lean and yet powerful. But in some places, the simplicity leads to careless mistakes.
In the first versions, the system variable .version was defined as a constant for the FreshMarker version. Unfortunately, this meant that the version number was regularly forgotten to be updated before the release.
With Partial Template Reduction, the template is filled with a fraction of the necessary data and thus simplified as far as possible. This articel presents the first part of the implementation.
Sometimes changes to a library are made so easily that it’s not really worth talking about. The Maven Plugin from posts Build Automatisierung mit eigenen Mojos verbessern and Trivial Pursuit – API MarkDown generates AsciiDoc documentation for simple OpenAPI descriptions. So far, the Maven Plugin uses a JSON description as input format. Since the YAML representation is used more frequently, its support would also be desirable.
I am proud to announce the release of FreshMarker 1.0.0! Having started as a small example for blog posts two years ago, FreshMarker has evolved into a robust and versatile framework designed to meet diverse templating needs.
While implementing some tests for the Freshmarker 1.0.0 release, I discovered another interesting possibility for a JUnit 5 TempDirFactory implementation. But first things first.
FreshMarker is an embedded Java template engine that focusses on extensibility and simplicity. For this reason, every implementation of an extension is associated with weighing up its pros and cons. For a long time, the import directive therefore remained an unrealised feature.
While reviewing the mutation tests for FreshMarker, I noticed an implementation gap in the logical expression. So if something needs to be changed, why not quickly add something new.
A Java developer always likes to look into the JDK, like a magician in his old tomes, to see if there is an unknown spell, er method, with which he can improve his source code. In fact, Java 21 has introduced a lot of new methods that make everyday life a little easier.
When I first heard about mutation testing, I was – to put it kindly – very confused. The idea that we change our code to see which tests fail doesn’t look particularly promising at first glance. But if you take a closer look at the approach, you realize the potential it holds.