The source code for this post can be found on GitHub.

Managing a live database, and in particular dealing with database migrations without allowing for any downtime in your application, is typically the most challenging part of any automated deployment strategy. Services can be spun up and down with impunity because their state at the beginning and at the end are exactly the same, but databases store data–their state is always changing.

Antifragile, by Nassim Nicholas Taleb, presents a truly unique viewpoint about the world. While there are many things here that are far fetched, there is far more that is very sound in its analysis. Even if you disagree with everything in it, this book’s usefulness, in the form of working theories about how to survive in the world, will prove itself very apparent.

Next, by Michael Lewis, is probably my least favorite book my him. Regardless, I’m convinced that he’s in his own league, so Next is still an excellent book.

Behind the Cloud, by Marc Benioff, is his own story about how Salesforce became one of the first software-as-a-subscription services. While it honestly sometimes felt like another marketing ploy for Salesforce, there were many nuggets of wisdom to take out of it.

Improvements to the Java 8 Date and Time API–in particular Instant, LocalDate/LocalDateTime, and their absolute counterpart ZonedDateTime, provide a much more intuitive and friendly way to deal with time than previous versions of Java.

The sample code associated with what follows can be found on GitHub.

One of the biggest paradigm shifts in software engineering, since the invention of the computer and software that would run on it, was the idea of a MVR (minimum viable release) or MVP (minimum viable product). With the lack of internet access becoming the exception in developed countries, it becomes more and more powerful to put your product out there on display, and to design a way to continuously make improvements to it. In the most aggressive of circumstances, you want to be able to push something up to a source control server, then let an automated process perform the various steps required to actually deploy it in the real world. In the best case, you can achieve all of this with zero downtime–basically, the users of your service are never inconvenienced by your decision to make a change. Setting up one very simple example of that is the subject of this post.

Often when we program, we find ourselves creating patterns, usually in the form of boilerplate code, that seem to always do the same thing. For example, let’s say you have some logging logic that is non-trivial, and you want to make extra sure you don’t blow up your main application while it’s running, so you surround it with a try/catch block:

You can view the sample code for this repository on GitHub.

In our last post on Using Maven to Setup and Teardown Integration Tests, we saw how to run Java code before and after our integration tests to setup and teardown any data that our tests depended on. What if we are using Spring, and we want to use our ApplicationContext, and its dependency injection/property injection features? After all, we would be testing the configuration for our specific application more than anything else, so we should be certain to use it in our setup and teardown code.

The sample code for this post can be found on GitHub.

Unit testing with Maven is built in, and is the preferred way of validating code is performing correctly. However, sometimes you need integration testing, and most non-trivial applications built in the 21st century are reliant on network connections and databases–that is, things which are inherently third party to your application. If you don’t adequately take that to account in your CI/CD pipeline, you might end up discovering that something very bad has happened after damage has already been done.

The sample code for this post can be found on GitHub.

While we can always install PostgreSQL on our host machine, it’s a much cleaner solution to create something like a local virtual machine with Vagrant or a container using Docker. That way, any changes we make to the database and then forget about are not around as soon as we destroy either the container or the virtual machine. It is one more way to tighten that feedback loop we need as developers.

In my post about how to provision any version of Java using a bash script, we saw that:

The sample code for this post can be found on GitHub.

Aspect Oriented Programming In Spring is a clever way to reduce code duplication, by taking a different approach than traditional tools like dependency injection or inheritance. Cross cutting concerns like security and logging can permeate a code base and make maintainability a nightmare unless properly taken care of, and aspect oriented programming is one way to properly take care of that, when used appropriately. This post will illustrate how to get started with a transparent way to log without cluttering up business logic.