Over the last few years I have become a much bigger fan of dynamic languages like Ruby and Python. Today I was thinking about one of my old gripes about dynamic languages, which was a lack of method overloading.
There are plenty of examples of basic Dockerfile based builds out there, but a production
application requires a bunch of different things, such as reproducibility, hardening,
health checks, static analysis - and ideally still be quick to build.
Using Git on macOS is largely a positive experience, other than (in my opinion) the
out of the box experience with merge tools. With my recent
merge
to Homebrew Cask you can use p4merge with no extra work.
Modern containerised 12 factor applications are expected to derive their configuration from environment variables.
While Spring Boot does import its
common properties from environment variables,
sometimes you need to interpolate several variables together, e.g. to form a URL.
An oft-repeated and sensible principle in software engineering is DRY, or
“don’t repeat yourself”. Here we will apply this principle to Docker compose
files.
To package our application, we’re going to be using Docker. The natural
build language for Docker images are Dockerfiles, so we will use
Spotify’s Dockerfile Maven plugin.
Spring Boot is a very popular Java framework for creating standalone, production
ready web applications. In this series of blog posts, we are going to walk through using Spring
Boot 2.0 to build and deploy a simple CRUD REST application.
It’s pretty common when doing Java development to need mutiple versions installed alongside each other.
With Brew and Jenv, switching Java versions between projects becomes easy.
I was recently given the task of modernising a simple internal site’s front-end. It was built using plain hand-written
HTML, CSS and JavaScript, with all layouts being done using HTML tables.