Wired Development

JMH is a tool to measure Java code that is executed within  micro-second time scales. You may ask the question why do I care about the performance of code that by definition is executed in a very short period of time? It is important to only optimise code that will have a significant effect on the overall application. Sometimes a small portion of the your application's code is executed many times or your latency requirements of your application is in the micro-second time scale. Once your application is performing as required it can be difficult to maintain that performance whilst making code changes. An automated collection of micro-benchmarks running on key components of your application is an invaluable tool in maintaining the required performance. As a starting point a history of your JMH results needs to be stored in order to analyse trends in benchmark results. Influx JMH reporter is an open source tool we have written that parses the JMH JSON results file from a ben

It is often argued that software configuration should not be hard-coded as it is important to be able to make configuration changes without deploying a new revision of the software. I consider this to be an Anti-pattern as the problem is with the application deployment process, and moving everything into configuration essentially creates a way of editing the code directly in your production environment. These configuration changes are never tested as they skip your testing and deployment pipeline and therefore result in software failures. This obviously makes the assumption that you are not selling physical packaged software, surely no one does that anymore. There is still a need for configuration but that comes out of the requirement to have environment specific settings for an application. Data that may be considered configuration should be hard-coded until it becomes apparent that the data is required to be environment specific in which case it can be moved into configuration.