Thoughts on agile software development
Wie man es besser macht
Every now and then, a way of working creeps in that is assumed not to correspond to established procedures. How nice it is when it is seen by many as a best practice and even has a name. In this case, it is a special version control practice, you guessed it, Trunk Base Development.
Sometimes a new feature also needs to be a bit of fun. When updating the FreshMarker Grammar, I noticed that the operators lt, gt, gte and lte were still present. These are variants of the usual <, >, <= and >= operators and are reminiscent of the opcodes of a long-forgotten era when assembler languages still roamed the steppes of programming. Since FreshMarker was given its Unicode capabilities by CongoCC, the question arose as to why not allow ≠ and other operator characters in the template.
It will come as no surprise that FreshMarker, like all other template engines, must take precautions against template injection. Template injection is a security vulnerability that occurs when an application handles templates insecurely. Templates are prefabricated files or strings with placeholders that are replaced by data from users or other sources. Similar to FreeMarker, FreshMarker also has an escape mechanism that detects special characters in the interpolations using a harmless variant. If the standard mechanism is not enough, OWASP can help out.
FreshMarker started as an academic project. The main aim was to show how a template engine can be created. At some point, however, the question arose as to how fast the template engine actually is. To be honest, it has been slow so far. But first things first.
This is an article that reports directly from the bowels of FreshMarker. It is therefore mainly worthwhile for readers who want to know a little more about how FreshMarker works.
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.
Anyone who has ever worked with Web APIs, and who hasn’t, will be aware of the difficulties of testing in an API environment. When testing an API, there are two sides to consider, that of the producer and that of the consumer. If both do not work hand in hand, then problems are inevitable. Consumer contract tests are designed to avoid some of the difficulties in API testing.
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.
Since the introduction of Java Records in Java 14 (JEP 359), their support in many frameworks has continued to grow. Support is now so great that we should consider banning Lombok from all our projects.
When storing data, their temporal changes are often not sufficiently taken into account. The following example of a club member database shows the problems of simplified temporal data storage and the advantages of bitemporal data storage.