Categories
continuousdelivery

An Enterprise Java Hello World

The ‘hello world’ program is of great importance to developers. It’s usually the first thing written when using a new language or framework, pretty much the simplest thing you can do: output 12 characters (assuming a newline). Writing the hello world program in C, the first time I’d written a compiled program, was an incredible moment for me: I could make the computer do something. This simple idea has an entry on wikipedia and a list of examples.

Hello World is supposed to be simple and there are a few jokes about Java EE hello world programs, mocking the framework for being long-winded and unwieldy – see for example, item 8 in The top Java viral jokes of 2014. In its defence, the contents page shown in the article covers a lot more than code, and is intended to get someone up and running from a bare-bones structure. But Java definitely doesn’t have the concision of Python’s print “Hello, world!”

One of the proud boasts for Spring Boot was how simple it was, with an example application that fitted into a single tweet (the link includes instructions for running it):

spring-boot

As easy as it is to get a Spring Boot application working, this is only part of the task of the development life-cycle. By focussing on the output, it’s easy to miss a lot of the non-functional aspects of an application. You can deploy a new piece of software to a server without making it easy for developers to work with. This is particularly dangerous with non-technical stakeholders who only see these non-functional requirements indirectly. It’s hard to prioritise infrastructure against features and bug-fixes. They are also incredibly difficult to fit into an application after it goes live.

I’ve recently set up a new application. The initial project was produced using Spring Initializr but, rather than start cutting code, I’ve been thinking about what else I need for a basic application. The essentials include:

  • Source control – and, preferably, some sort of branching and versioning strategy
  • Continuous integration and related process to make sure that new commits don’t break tests
  •  A deployment process allowing the same binary to deployed to immutable servers – preferably using some sort of container or virtualisation – preferably with the binary produced once and stored in a centralised location.
  • A means of externalising configuration for different environments
  • Some sort of monitoring and log management

It’s easy to drop a Spring Boot jar file onto a server and run it, but that’s not going to work in the long term and the easiest time to sort these infrastructural items in place is at a project’s start. The more complicated things become, the harder it is to add them in.

In short: an application isn’t just the software you are writing: it’s also the infrastructure that you put around it. In order to release and maintain an application you need to do a certain amount of work beforehand. Your hello-world application isn’t ready for production until these things are done.

Categories
brightonjava

Brighton Java – Continuous Deployment

IMG_20150304_195142
I had a break this month as Mr. Stanier hosted the meeting

 

Last Wednesday we had Brighton Java’s March event. It was another good turn-out, with about 35 people turning up to hear Jose Baena talk about his experience of continuous delivery.

Hearing about other people’s experiences with introducing a technology is incredibly valuable. The talk was followed by a discussion, chaired by James Stanier. We’ve not often used this format but it drew out some interesting discussion points.

Jose’s presentation was great (especially the hypnotic footage of an apple-slicing machine), with some useful suggestions on how to get Maven, Nexus, Ansible and Jenkins working together – with Jenkins acting as the driving force. There was also a detailed explanation of the importance of versioning.

The discussion underlined something I’ve been thinking about for a while – that things like continuous delivery need to be put in place early on, that these sort of infrastructural things are hard to retrofit. But that’s a story for another post.

Dan Chalmers has also posted a response to the meet-up: Continuous Deployment and Developers on-call. Dan does a good job of explaining the issues around making developers responsible for their code. I still think this is important but making it work in practise is a subtle, difficult problem.

Categories
openstreetmap

Getting Open Streetmap working on Ubuntu

It’s taken me quite a bit of time but I’ve finally got an open streetmap tileserver working on my laptop. The main issue appears to have been that I was following the manual Ubuntu set-up instructions rather than building a tile server from packages. Which isn’t to say that using packages was plain sailing. This post will outline some of the problems I ran into and how I solved them.

(Bear in mind that I’d already tried to install OSM using the manual method on the laptop and fragments of these installs were still on the system. Installation might be a lot easier on a clean OS. However, it’s worth documenting the issues in case anyone runs into the same issues and is googling for them)

The main point of this post is to say that I have managed the open streetmap set-up and now have a map of Brighton working on my laptop:

Screenshot from 2015-03-03 08:11:32
I can see my house from here!

The installed slippymap.html page is great as the radio buttons on the top right allow you to compare a remote instance against the local one – useful for finding out where you are when things aren’t working, or you only have a small area set up. Now I’ve fixed this, I can get on with actually using the server.

The main problems I had to solve with the packaging method were:

Mod-tile dpkg installtion hangs

The command to install mod-tile hung. Googling around, I found a patch for this  – a line was missing from the libapache2-mod-tile.postinst script. Editing the script and re-running the installation fixed this issue.

osm2psql didn’t work

When I ran the command osm2pgsql I received an error:

Osm2pgsql failed due to ERROR: SELECT AddGeometryColumn('planet_osm_point', 'way', 900913, 'POINT', 2 ) failed: ERROR:  AddGeometryColumns() - invalid SRID

This seemed to have been caused by not having set up data in the spatial_ref_sys table. To check this see if there are any lines from the SQL query

SELECT * FROM spatial_ref_sys;

If not, then this is easily fixed:

psql --username=postgres --dbname=gis --file=/usr/share/postgresql/9.1/contrib/postgis-1.5/spatial_ref_sys.sql

After re-running this script, the osm2psql script worked. Note that this may have been a problem due to me incorrectly removing previous installation attempts.

Tiles not rendering

This is more of a generic issue. Basically, when the slippymap page is working, but the images are not being generated, a lot of missing images will be displayed:

Pink tiles

You can open the blank tiles in a new page and see there where they are being generated from. Some of the help online suggested that it could be down to the slippymap.html pointing to the wrong OSM server (it defaults to localhost). In my case it was a permissions issue:

Database permissions not set correctly

There seems to be a minor issue with the installation scripts. This was fixed by explicitly setting up the postgis user.

I was able to diagnose this issue by running renderd as a foreground process (ie renderd -f) and seeing permissions errors such as the following:

renderd[26466]: An error occurred while loading the map layer 'default': :
FATAL: role "www-data" does not exist (encountered during parsing of layer 'landcover' in map '/etc/mapnik-osm-data/osm.xml')
renderd[26466]: An error occurred while loading the map layer 'default': :
FATAL: role "www-data" does not exist (encountered during parsing of layer 'landcover' in map '/etc/mapnik-osm-data/osm.xml')