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.
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.
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:
Deploy the charm
Give it something to do
juju deploy cs:~mattyw/trusty/remote-deployer-2
juju action do remote-deployer/0 deploy source=https://github.com/mattyw/compojure-app-bootstrap
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 (https://github.com/mattyw/compojure-app-bootstrap)
# remote-deployer#!/bin/shset -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 &
Juju fans will notice that the normal hook tools are available to you in this file.
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.
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.
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:
Always have it with me, even if I go for a walk.
If you’re working at your desk, have it within arms reach.
If you take a break, leave a note of where you’ve left off.
When you return from a break refer to your log book to help you regain context.
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.
Here’s my current stuff (left->right, top->bottom)
A4 clipboard from some team building thing I did a number of years back.
A Field notes sized fauxdori (it also supports midori inserts).
A lamy safari with LH nib.
A Kaweco skyline with F nib.
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.
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
│ └── flasher
flasher is the binary I produced in step 1. The package.yaml just contains
information about the snap:
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.
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).
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.
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.
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 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 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: