.london domain name

After living in London for almost six years, I'm now on my very own .london domain name.

Running Docker on Mac

Tonight's mission - get an application from the day job up and running on one of my Macs at home...

So, Docker is designed to run on top of a Linux kernel - which Mac OS X obviously doesn't offer.

A quick Google leads to:
http://docs.docker.com/installation/mac/

which directs me to Boot2Docker :
https://github.com/boot2docker/osx-installer/releases

Open the downloaded package and double click to install the VM image

Binaries are now on the path and ready to run from a command line terminal:

> boot2docker init
> boot2docker start

Then the top secret bit for pulling down the Dockerised application...

Tweak the configuration properties to use the newly created Docker host instead of the hand-coded Linux environment's Docker configuration (host IP address).

Run the application's tests.

Let out a satisfied "Aaah" or "Mmm" (optional).

This all took about 20 minutes, but most of the time was spent waiting on downloads.

Generating an application jar using Gradle 2

In an earlier post I mentioned that my latest work project encountered some surprises when trying to bundle an application and all of its dependencies into one big jar.

Last week a colleague tried using a different Gradle plugin to generate the jar more quickly, as that had been a noticeable bottleneck in the build process.  He encountered more problems and reverted back to fatjar.

This week I stumbled across the shadowJar Gradle plugin.  From all of the description and sample configuration it looked like nearly a drop in replacement for the fatjar plugin.

Some colleagues agreed that it looked quite promising and tried it out.  It worked fine on one of our applications, but resulted in runtime failures on the other one so they abandoned this build optimisation activity.

After a little compare and contrast I found that the size of the files in META-INF/services differed.  The jar generated with the fatjar plugin had some larger files than the jar generated with the shadowJar plugin.

Tracing back through the project dependencies indicated that the missing content was from the Jersey client artifacts.  It soon became apparent that the duplicate file names across two jars wasn't intended for one to be a substitutable implementation of the other, so I looked into merging.

Sure enough, by default the fatjar plugin merges the contents of service files when generating the jar, but shadowJar does not.

A single line configuration update resulted in shadowJar producing a working jar - with a complete definition of the services.

Why Optional in Java 8 is not Serializable

So far in my exploration of Java 8 I have encountered a couple of "why'd they do it like that?" discussions.

One particularly contentious new class is java.util.Optional.

The reasoning behind not implementing Serializable boils down to discouraging developers from misusing the concept.  It's not intended to be stored as a field value, but rather to act as a temporary representation when returning a potentially null value from a method.

See the relevant JDK 8 Developers mailing list discussion for the range of perspectives.

I suspect my current team and I may have already misused Optional - time for some refactoring...

Unexciting update: I managed to find 0 offensive usages of Optional in the current project's codebase.

If the code looks weird - it probably is

I have a good habit of examining code changes when I synchronise my codebase with the latest changes from version control.

Yesterday I noticed a one liner which included an unintuitive chaining of calls. I asked my colleague about it and we briefly jumped around the code and saw a passing functional test which supposedly indicated that all was well, and moved on.

A couple of hours later I decided to try out the application through a web browser and observed that the application would fail on any request.

I went back to the questionable code and realised that the class that contained it was not covered by any unit tests.

Half an hour or so later the component in question had its own unit tests and an additional half dozen lines of code to make it perform its intended purpose.

As with many things in life, with the benefit of hindsight I realise that I should have paid more attention to when my spidey sense told me our use of the API didn't look right.

Validation handling for Post-Redirect-Get

There are plenty of descriptions of the Post-Redirect-Get pattern online, but I am bit surprised and disappointed to see that most descriptions do not bother to cover a validation path.

With the obvious exception of search forms, most of the forms that I encounter online or develop in my day job will involve some input validation so I am taking it as not being a moot point.

As a toy application we can think of a web application which prompts the user to enter their date of birth and then displays back some information about that date - it could be the person's current age or a mash up of other people born on the same day and important events for that date, use your imagination.

Let's consider the application as consisting of two views:

• input form to accept the day, month and year
• display interesting information about the date specified through the form

In this setup the Post-Redirect-Get pattern would work as follows:

• Web browser HTTP GET request results in display of html page with the input form view.  The input form specifies method as POST and action as the appropriate form processing action on the server.
• A form submission results in an HTTP POST request being sent to the server including any form values that have been populated.
• In the Happy Days scenario a valid date has been specified, the server side action performs any necessary calculation or lookup and redirects the browser to a GET resource which will duly present the second view.  To avoid having to consider passing any state with the redirect this example application might embed the date into the resource URL - /doDateStuff/{yyyy}/{mm}/{dd} might work as a suitable resource URL pattern.

Now, what about the situation where an invalid date has been entered? For example, 29 February 2015 is an invalid date because 2015 is not a leap year.

My preferred approach to this is to allow the POST request to provide a response with the input form view along with the validation error message(s). In this path there is no redirect to a GET resource. If the browser refreshes then the form submission will be repeated and the validation will fail again and the input form will show the error(s) afresh.

An alternative approach that I have never used in my 14 or so years of professional web development treats the Post-Redirect-Get approach as applying to validation.  In my opinion this approach involves additional complexity for carrying the validation state across to the request that the browser will send when it receives the redirect response. The use of a short-lived cookie seems to be the hack for this.

Taking the non Happy Days scenario further, what happens if the user refreshes the invalid form?

• In my preferred approach the browser will probably detect that a POST request is going to be repeated and present a dialogue asking if the user really wants to do that. If the user accepts the warning and continues with the repeat submission then the form post is repeated, the validation is applied by the server and the same input form view response with the same validation error messages will show.
• With the short-lived cookie approach the GET request will go to the server and the input form view will be rendered without the old error messages and without the values showing in the form  - because the short-lived cookie has been disposed of.