Monthly Archives: January 2016

Where I go find Go is like Go

I’ve been playing with Go recently; writing a little REST server that will do some stuff on hitting various end points. So far so copy-and-paste-from-Stack-Overflow. The issue is that, while my application works, I know at a visceral level that it sucks. I’m using go run to test it, and everything is lumped into one file. As an experienced developer I know this is bad – and it’s going to get worse.

And herein lies the problem. Architecturally I know what I should be doing, but as a Go newbie I don’t know if I should be splitting my file into many files in the main package, or splitting it into lots of little single file libraries, or something else entirely. I’ve picked up the syntax of the language, but the paradigms and idiosyncrasies are still, for the most part, unknown to me.

Remove the architectural knowledge that a few decades bashing away at various languages has given me and what you’re left with is a program that compiles, runs and does some nifty stuff – so it must be good, right? Look at me, I’m a Go developer!

I’m all for teaching people about how computers work, and the fundamentals of programming them, but lets not kid ourselves that we’re raising a generation of software engineers. There’s a world of difference between barfing a small, toy project into existence and writing performant, fault tolerant, scalable software that can drive business. Seriously, if I’d presented what I wrote yesterday as some production code I’d fire me. And yet too many people out there don’t know that they don’t know how to be a software developer.

Sadly, I have no idea what the solution is. Computers are fairly ubiquitous, learning to code is easy, and putting together need little programs that, on the surface of it, look impressive, is reasonably trivial. A good parallel would be the game ‘go‘. It’s trivial to pick up and learn, but takes a lifetime to master.

Now, do I know any friendly Go developers who would be willing to give a gentle code review of some truly awful code? Now that I’ve learned Go I need to learn Go.

Of Neo4j and Docker

So here’s a fun one. We’re using Docker, because, you know, DevOps, startup and all that jazz; and we’re using Neo4j because graphs. Until recently Neo4j didn’t have an official Docker repository, but we’re enterprising people and we know how to build Docker images. We also know how to Google, so lets just use someone else’s Docker image. Which is fine, until you come to use the shiny new official Neo4j Docker image with all the lovely new features it brings.

And then this happens:

Caused by: org.neo4j.kernel.impl.storemigration.StoreUpgrader$UnexpectedUpgradingStoreVersionException: '/var/lib/neo4j/data/graph.db/neostore.nodestore.db' has a store version number that we cannot upgrade from. Expected 'v0.A.3' but file is version ''.

Which is problematic, because you need your 2.1.8 datastore updating to 2.3.1 to run with this image. And Google isn’t being helpful in providing a solution (which is mostly the reason behind this post). Long story short, Neo4j prior to 2.3.0 didn’t play well with Docker. You run docker stop neo4j and it casually sits there for a few seconds before issuing a kill -9 and taking the database down at it’s knees. This became apparent when I took my 2.1.8 database files and ran it using a local (non Docker) install of Neo4j 2.1.8 and it told me:

Detected incorrectly shut down database, performing recovery..

Once I’d done that the official Docker image was more than happy to start up and upgrade the files. So if you’re sat staring at whacking great big stack trace, that culminates in an exception with a blank (or garbled) version string, go fire up a local copy of Neo4j (ideally the same version you’re running in Docker), hand it your data files (or edit the file to point to the files), run neo4j console, wait for it to repair and startup, hit CTRL-c and go use the official Docker image – which shouldn’t suffer from this issue with future upgrades.

Good luck 😉