Wired Development

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.

Why a single source tree ? At a previous employer the code started out with the main code base in a single checkout with only infrastructure components of the code in their own repositories. As the code base grew the build time gradually become painful. To resolve this developers began to pull out components into their own repositories. This initially solved the problem of slow build times and improved productivity for the developers working on a single component. However, it soon became apparent that making changes to components that had many internal dependencies was particularly cumbersome. It also made it difficult to make changes across multiple repositories. This was solved by moving everything back into a single source tree. What about the slow build times? The short answer is Buck - a build tool from Facebook which is inspired by Google's internal build tool called Blaze, now open sourced as Bazel . In summary these build tools allow you to easily modularize your rep

At TransFICC for MiFID compliance (as explained in my previous blog) we need to obtain the time of an event within 100 microsecond accuracy with respect to UTC. To achieve this in Java we first need to be able to obtain the time from the OS with better than millisecond precision. We can then make use of Precision Time Protocol (PTP) to ensure the system clock is synchronised to UTC with sufficient accuracy. Take a look at the excellent posts from Luke Bigum on how to achieve this . As of Java version 8 it is not possible to directly obtain the time with higher than millisecond precision. Java 8 System.currentTimeMillis() will return the time since the Unix epoch in milliseconds. Higher precision time is possible on some underlying systems such as Linux. On Linux the code that the OpenJDK JVM executes is: The full source can be found  here . The code makes the function call gettimeofday(). This returns the time since the Linux epoch in micro seconds however it is rounded to th

This is part of a two part series on time measurement. Part 2 will explain how to obtain accurate time measurement in Java. This first part explains the general concept of time measurement. How do we measure time? With a clock of course. So how do we build a clock? The first thing we need is to observe something that occurs at a constant rate. Humans have built clocks based on observations of changes in their environment that appeared to occur at a constant rate. Sundial Some of these earliest clocks were Sundials. The shadow cast by the Sundial moves based on the rate of rotation of the earth on its axis. This observation of the Earth's rotation is what Greenwich Mean Time was based on. At the Royal Observatory in Greenwich astronomers would observe the sun and other stars in order to calibrate their clocks. In principal on average the sun would appear directly above in the sky at 12h00.00. This is why its called Mean time. The current