talkative, friendly, programmer

Go Binary Charm Layer

| Comments

I like go. One of the things I like is not worrying about dependencies during deployment. You just scp your binary to your server and you’re done. Well, after you configure it to connect to the database, ah yes, we forgot about haproxy, let’s set that up as well, but after scping to a server and doing some minor setup you’re ready to go, scale it out you say? Just scp to other servers, do the same config setup……..

The solution to this problem is to use an orchestration tool like juju. Now thanks to the go binary layer orchestrating your go program with juju couldn’t be easier.

Here’s how it works. The go-binary layer looks in the top level of your charm for a go-binary.yaml file that contains the name of your binary and any arguments that should be passed to it.

binary: server
args: /etc/myserver/config.yaml

Your compiled binary should be placed in a “files” directory at the top level of your charm. Build your charm and you’re all done.

$ tree
├── files
│   ├── server
├── go-binary.yaml
├── layer.yaml
├── metadata.yaml

Under the covers the go-binary layer will add your binary to $PATH,write an upstart file for your binary and start it when the server starts.

There are examples of this in action with the http (website) relation (

and with the mongodb relation (

If you’d like to see these charms in action take a look at the following videos:

Jupsen: Modelling Networking Partitions With Juju

| Comments

Jupsen is a tool that allows you to drop or delay packets between juju units.

Why is this useful?

Network problems happen, if you’re working on a distributed system you need to deal with them, this is much easier to do if you’re able to recreate these situations easily.

With jupsen you can

  • Block traffic between two units in only one direction
  • Block traffic between two units in only both directions
  • Delay packets in one direction
  • Delay packets in both directions.

This can be used to recreate some of the experiments in Kyle Kingsbury’s jupsen series (from which I have shamefully taken the name) (

If you want to have a play around with jupsen you can get it here: (

If you want to see it in action you can take a look at this demo I gave at the recent Ubuntu Online Summit.

The Remote-deployer Charm: Playing With Juju During a Tea Break

| Comments

The power of juju, and its model driven approach to deployments is undoubtedly the relationships. Being able to specify what services you depend on and what you provide to other services is extremely powerful.

To get all of those benefits you need to write your app as a charm. With the new layering approach ( this has got even easier. There will be more posts about that coming soon.

But I’ve always pondered the following:

Is there a useful shortcut around writing a charm that would let you deploy your app in < 5 minutes

My idea was the remote-deployer charm (

It doesn’t replace writing your own charm, indeed the cases in which it’s useful are limited. (you must have a publicly available file path that you want to deploy from) The intention is to facilitate playing with juju in less time than the typical tea break.

The idea goes:

  1. Deploy the charm
  2. Give it something to do
juju deploy cs:~mattyw/trusty/remote-deployer-2
juju action do remote-deployer/0 deploy source=

The something to do is just pointing it at some remote file tree (like a github url). It downloads this file tree and looks for a file called remote-deployer. It runs this as the ubuntu user. The example above installs the clojure build tool lein and creates a hello world web app (

# remote-deployer
set -ev
sudo apt-get install -y --force-yes openjdk-7-jre-headless
sudo cp lein /usr/bin
cd $HOME && lein new compojure-app my-app
cd $HOME/my-app && nohup lein ring server &
open-port 3000

Juju fans will notice that the normal hook tools are available to you in this file.

If you’d like to suggest or help make improvements the project is here:

Take a look at in action:

Video: Juju Status Flasher on Ubuntu Snappy

| Comments

I’d like to share a proof of concept project I’ve been working on that combines the worlds of ubuntu snappy and juju.

I wanted to use the flashing leds on the raspberry pi 2’s piglow to tell me the status of my cloud services. The idea being that if there’s something I need to fix the flashing leds will tell me, without me having to keep checking my phone or laptop to get updates.

This demo will use the realtime syslog analytics big data bundle as my example environment. It’s deployed in ec2 but it’s controlled and managed by juju running on my raspberry pi. I’m going to show you a working environment with happy led status. Then I’m going to cause some trouble and we’ll see the leds change to unhappy.

The idea being that if I want to know the status of my cloud services I only need to glance at my raspberry pi for a moment.

There’s still some work to be done around optimising the various led patterns. There could be a way that I could convey seriousness of the problem via the leds, or even how long there has been a problem. That’s work that can come later.

Keep a Logbook and Love Your Tools

| Comments


If your job requires thinking of any kind you should be keeping a log book/ journal to keep a note of what you are doing. If you learn to love the process of keeping the journal it will be even more useful to you.

The story

When I first started work I instinctively started keeping a logbook of all of my activities. I grabbed an A4 notebook out of the stationary cupboard and started writing, this was mostly because the rate of information coming at me was more than I could handle, so I wanted somewhere to store it that was better than my head. But it was also because I could own a nice A4 notebook without having to pay for it, and this was quite a novelty.

Then this year I discovered the pen addict podcast and (despite my left handedness) I really got into paper and pens again. For the past 3 months I’ve been keeping a log of my work. Experiments, meetings, things that need fixing, ideas, new tricks, everything to do with my job.

Keep a Logbook

This is how I make use of a logbook, it’s mostly common sense:

  1. Always have it with me, even if I go for a walk.
  2. If you’re working at your desk, have it within arms reach.
  3. If you take a break, leave a note of where you’ve left off.
  4. When you return from a break refer to your log book to help you regain context.

This is what I write:

  1. Things I need to remember.
  2. Things I need to do.
  3. Things I want to talk about with colleagues.
  4. Ideas for future projects.
  5. Solutions to problems
  6. Results of experiments I’ve done
  7. Cool tricks I’ve discovered (editor shortcuts, programming patterns etc)

Reviewing your Logbook

An important part of any process is reviewing. Most days I will flip through recent pages of my notebooks and record anything that I think is important in Evernote or my teams kanban board. The act of reviewing notes also helps cement any new tricks I’d learned. The whole process I use is a topic for another time.

Love your tools

Something I’ve known to be true in programming for a number of years is that if you can learn to really love the tools you use then no matter how mundane your task seems to be you will love doing it, because using the tools is part of the fun. I’ve started to realise that the same is true of a number of walks of life. I’ve bought a couple of fountain pens, made my own pocket and full size midori notebooks, spent a stupid amount of money on field notes. But I also have a collection of programming related notes, ideas, insights that I keep catalogued. The process of writing all these notes is one I enjoy, in fact I look forward to it because I’ve come to love the tools I use to do it.

My tools

Here’s my current stuff (left->right, top->bottom)

  1. A4 clipboard from some team building thing I did a number of years back.
  2. A Field notes sized fauxdori (it also supports midori inserts).
  3. A lamy safari with LH nib.
  4. A Kaweco skyline with F nib.
  5. Full size fauxdori. (It also support field notes)

I made both fauxdoris myself, which means the act of using them is a pleasure in itself.

Simple Piglow Snap for Raspberry Pi 2

| Comments

Using a Raspberry Pi 2 with Ubuntu Snappy installed we’re going to write a simple snap that will flash a piglow attached to the gpio pins.

If you want to skip these steps you can download the snap itself from here

1. A simple piglow flashing binary

To make things simple we’ll use go to produce a simple binary that will flash the legs of the piglow. We’re using go because the static compilation means our snap will have no dependencies to deal with. The code itself is small. I modified the piglow library I was using to get a bit more feedback about piglow errors, the change is trivial to revert should you need to.

2. Create the snap

The package structure is simple

├── bin
│   └── flasher
└── meta
    ├── package.yaml

flasher is the binary I produced in step 1. The package.yaml just contains information about the snap:

name: hello-piglow
version: 1.0.0
vendor: me
 - name: bin/flasher

Once you’ve got all this in place build it and send it over to your pi.

snappy build .
snappy-remote --url=ssh://<ip-address>:22 install <snap-name>

3. On the Pi

You need to give your snap permission to access the i2c device

sudo snappy hw-assign hello-piglow.sideload /dev/i2c-1

4. You’re done

sudo hello-piglow.flasher

If all goes well you should have a flashing piglow

Generics and Monads in Good Time

| Comments

In this blog post I attempt to connect monads in haskell with generics in go, avoiding flame wars as I go. If I’ve made mistakes please let me know and I’ll gladly fix them.

The Thought

I’ve just finished listening to episode 10 of the bikeshed which is largely a discussion about haskell, and well worth a listen to. However the conversation that starts at around 29:40 is what triggered this thought.

Haskell without monads

If you want to do IO in Haskell you need to use monads. But it’s possible to write a number of programs without IO(1).

According to “A history of haskell, being lazy with class” 6 years passed between the first release of haskell, and monadic IO being introduced. Why so long?

The language designers were under no pressure, they had time to think about how IO should be dealt with in the language.

The question of Go Generics

Go doesn’t support generics, and it’s often cited as a big downside or even a failing of the language. However you can still write very useful programs in go without generics(1). But here’s the thing:

The language designers are under no pressure, they have time to think about how generics should be dealt with in the language.

This is important. Just because a language doesn’t do something now, doesn’t mean it never will. If you’ve not taken a look at go previously because you’ve been swayed by the “no generics” argument I recomend taking a look at go again.

(1) An infinite number for maths fans

What Have You Learned From Language X?

| Comments

Alan Perlis wrote

A language that doesn't affect the way you think about programming, is not worth knowing.

That’s an interesting statement, it made me wonder what people think they’ve learned from certain programming langues, and how much it differs between people.

If you have a moment, I’d love to know: Survey

Getting Software Done

| Comments

I’ve recently finished reading Getting Things Done. And I’m trying it out as my method for organising all of my work. Regardless of how it goes there are several key ideas which I think transfer directly onto the world of software development. These are (in no particular order):

  • If something takes less than 2 minutes do it,
  • Stuff that needs doing is defined as something that isn’t how or where is should be.
  • A project (something that needs planning) is something that requires more than one action to complete
  • Always think in terms of “What’s the next action?”

This last one I consider crucial especially when it comes to learning new things. I’ve been guilty of having goals such as “learn functional programming”. This type of thing is far too broad, you need to think it through until you end up on the next thing that needs doing to reach your goal. All of us are guilty of having a number of projects “on the go” as well. I’ve found forcing myself to think about the next action has really helped me make progress with them. In some cases I’ve made progress on projects that haven’t made progress in >2 years. Like everything, GTD is no silver bullet, and isn’t for everyone, but I think the book is worth reading, if you don’t find it useful, at least you know.

Vim Survey Results

| Comments

I don’t normally find programming koans enlightening or amusing, there is one execption – which pretty much sums up my approach to vim:

Master Wq and the Markdown acolyte

A Markdown acolyte came to Master Wq to demonstrate his Vim plugin.

"See, master," he said, "I have nearly finished the Vim macros that translate Markdown into HTML.
My functions interweave, my parser is a paragon of efficiency, and the results nearly flawless.
I daresay I have mastered Vimscript, and my work will validate Vim as a modern editor for the enlightened developer!
Have I done rightly?"

Master Wq read the acolyte's code for several minutes without saying anything. Then he opened a Markdown document, and typed:

HTML filled the buffer instantly. The acolyte began to cry.

But I was starting to get the feeling that most vim users had loads of plugins installed – so I decided I wanted to find out if this was true.

20 minutes later I had hacked my way through a basic survey – which was full of holes and typos. Despite this I had over 1000 responses in 24 hours – which gives us our first ‘statistic’:

Vim users love talking about vim

So, here are the results. 1300 of you responded to the survey. Percentages have been rounded down to the nearest integer. Because I said so. Questions where the answers were freeform I’ve done my best to group. But it might not be perfect. Each question was optional so each question had a number of empty responses, I’ve left these out. This is why most percentages do not add up to 100%

I welcome others to take a look at the raw results: Link to Raw Data

Do you spend most of your time in vim or gvim?

I forgot about macvim, and had never heard of vim-qt – but thankfully most of you seemed to work out that my intention was – gui or terminal.

vim 946 72%

gvim 347 26%

How often do you use vim?

daily 1227 94%

weekly 54 4%

monthly 11 0.8%

The obligatory operating system question – Which do you use most?

The world is full of programmers using macs in coffee shops right?

linux 807 62%

os x 347 26%

windows 131 10%

freebsd 19 1%

One person said they used “your face” which is an odd choice as my face has very poor memory management.

What key do you have mapped as your leader key?

I’ve always just stuck with the default, althought I was aware that alot of people use ‘,’. Using space was new to me, but according to this it’s one of the most popular keys

comma 470 36%

backslash 309 23.7

none/ don’t use, never heard of leader 220 17%

space 169 13%

semicolon 13 1%

forward slash 12 0.9%

esc 11 0.8%

colon 8

underbar 5

ctrl 4

alt/ caps lock 2

How often do you make changes to your vimrc file?

montly 603 46%

weekly 459 35%

yearly 138 10%

daily 60 4%

no customisations 21 1%

When did you first use vim?

2010’s 613 47%

2000’s 505 38%

1990’s 162 12%

How many plugins do you have installed at the moment?

This is the question I really wanted answered. Thankfully it seems like most of us would rather have less plugins

Your favourite plugin?

ctrlp 171 13%

syntastic 59 4%

nerdtree 59 4%

youcompleteme 50 3%

fugitive 41 3%

airline 39 3%

surround 30 2%

vundle 30 2%

pathogen 24 1%

Do you remove plugins you no longer user?

yes 1009 77%

no 229 17%

What is your average typing speed?

61 – 80 391 30%

41 – 60 360 27%

> 80 344 26%

20 – 40 wpm 121 9%

< 20 wpm 8 1%

Roughly how many different computers will you use in a particular week?

6 – 10 143 11%

2 – 5 877 67%

> 10 122 9%

1 132 10%

Have you written a plugin?

no 1006 77%

yes – publicly available 121 9%

yes – kept it private 148 11%

Give me a single piece of advice

Some of it is great, some is crazy, you’re welcome to take a look at the raw results:

It’s all here

Your view of emacs?

never used emacs – don’t want to 498 38%

never used emacs – but willing to try 418 32%

i use it every now and again 221 17%

it’s another tool in my toolbox 113 8%

I spent a while trying to work out how to construct this question, what I was trying to work out is if the editor war really existed, I don’t use emacs, but I did, and there are some things I think it does better than vim, and some things it doesn’t. I spent ~2 years using emacs before moving to vim, I wanted to get a broad idea of how emacs is view by the vim community. The results were a suprise

That’s it

That’s all there is nothing more. I’m not great with statistics so I encourage others to take a look at the raw data and come up with a much better ‘analysis’. If anyone feels that the above is in some way worthy of a small tip here’s my btc address: