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:
Update: So I’ve learned that there’s actually some work to be done here around sandboxing before it’s actually ready for public use. Until then I’ve removed the server, but the code is still available if you want to play around with it in a trusted setting.
It’s a great idea, it means you can actually try the code out while you’re reading the docs. But it only works on code from the stdlib. But that makes sense doesn’t it? You don’t want to allow anyone to import some arbitrary package.
But it occured to me that when someone develops a package, the author might want to include runnable examples for their own code.
The source for something similar to the playgrond is incuded in the go release (misc/goplay) I’ve modified it very slightly to allow /compile to be called from any location.
I’ve called it goplaas (It’s not really as a service, but that’s the standard suffix these days isn’ it? And it got your attention!)
The idea is you install it on your own server, and it will have access to anything installed on your GOPATH. This means you can control what packages can be imported, and also the version.
Here’s an example using the loggo package from launchpad.net. Try it
I've removed it - sorry
I’ll try to keep my server running with goplaas for the next few weeks. If it suddenly stops working, it’s likely that I’ve pulled the server down. You can experiment yourself by running
go install github.com/mattyw/goplaas
./goplaas -http :9999 #Listen on 9999
goplaas includes a -compile flag for sending compilation instructions to another server, full instructions are in github.
A good next step would be to package this all up into a docker container to allow anyone to install it with relative ease
Today I finally got round to trying out something i’d been meaning to look into for nearly a year, and seeing as clojure and editors seems to be a topic again I thought it would help add some diversity.
Acme is an editor unlike any other. It was designed by Rob Pike for Plan9 (although it’s available for unix-like systems using Plan9 from User Space).
It’s designed to be an editor and shell. Unlike emacs and vim which encourage you to keep your hands on the keyboard, acme requires use of a 3-button mouse, and it supports something called mouse chording. A rough guide would be:
Button 1: Select Text
Button 2: Execute Command
Button 3: Search/ acquire text (or load file)
Button 1-2 Cutting
Button 1-3 Pasting
Button 1-2,3 Cut+Paste (Copy)
My introduction to acme was via Russ Cox’ video, which is a great starting point:
You can probably summarise the whole thing by saying that in acme – text is data. Once you type some text, it can be saved into a file, executed as a command or passed as an argument to a command.
Obviously this resonated with the clojure part of my brain. It occured to me that being able to select some clojure code in acme and evaluate it would make acme a great editor for clojure.
Thanks to nrepl the job is really quite easy. I wrote a very very simple nrepl client in go. You can find it on my github
All it does is read clojure code from stdin and send it to nrepl. This is really all there is to do. In acme you just need to type your command in one of the scratch areas:
Take a look at the below screenshot. You can see:
In yellow: selected clojure code with mouse button 1
In red: selected command with mouse button two
Release the buttons and the window in the bottom right contains the evalutated code
tl;dr: Juju is aimed at deploying and scaling hundreds of services. But it’s also a handy alternative to buying a VPS.
I don’t have a VPS, I have in the past but I’ve never used them enough for me to be able to justify the cost long term.
Juju provides a perfect solution to this use case.
I have a very simple charm I call devenv, it doesn’t do much more than install stuff I use for doing development, like installing tmux and grabbing my configuration files. I’ve blogged about it previously here.
This week I was having trouble getting a client library to connect to a simple server program I’d written, I was lost with debugging but luckily the library author volunteered to help me out.
I already had a binary of the server that could be used to generate the error in the client library, but I don’t have a VPS, so what’s the quickest way for me to make the server public so the library author can play around with it?
All I needed to do was to add the following line to the start hook of my devenv charm:
And copy the app binary to my charm directory.
It’s sort of an anti pattern – but because juju copies the whole charm dir when it deploys, it will grab any binaries in the charm dir as well, it’s not a great idea to make use of this for serious deployments, but for me it was great
From deciding I wanted to deploy the binary – to having it deployed was under 5 minutes. 20 minutes later the library was fixed and the server was taken down
That was it. All in all it cost around $0.02 (that’s just over 1p). Much better than having a VPS that would largely sit idle.
Of course the other advantage with using juju is that I’m not tied to a particular cloud provider, so I can choose which one I want depending on the pricing at that moment. And since juju now supports local mode you can do your charm development offline to save even more money!
Great, how does this help me?
If you’re thinking of getting a VPS – but don’t feel you can justify the cost because of the amount of use you’d get out of it, then you really should try out juju. Once you’ve got it installed there’s a handy charm that just deploys ubuntu server, it’s a great starting point for writing a charm to setup your own development environment.
Not too much magic (as far as macros are concerned) here. Make a unique symbol with (gensysm) to keep our macro hygienic.
We syntax quote our whole list using ` to not evaluate anything unless we say so. That means we have to do some magic with our args parameter: ‘~args. ~ here means
evaluate args (so we get the symbols we passed in) but then we quote with ’ so that we don’t evaluate these symbols. That’s the magic that lets us not need quotes around our arguments.
The rest of the code just puts them in the right place by mapping our args list against the str function and applying it to sh.
This is how you use it:
(prn (mcallls-l))(prn (mcallgrep-rinnot "./")); We still need quotes around ./ because it's not valid syntax
Elixir is a lovely little language I’ve been playing with recently, so naturally I wanted to try out the macros.
I needed to ask a few questions on the irc channel (thanks ericmj and true_droid!), but I got it cracked:
Again, not much magic, map_join maps our list using the Macro.to_string function then joins at the end, this is done outside of the quote since we will work it out at compile time.
We then pass this to System.cmd in a quote block – which means don’t evaluate this yet, that will happen when we call mcall at runtime.
IO.inspectMacroTest.mcall([ls,-l])IO.inspectMacroTest.mcall([grep,-rin,def,"./"])# We still need quotes around ./ because it's not valid syntax
We’re going to use a raspberry pi and juju to setup a wordpress blog on aws.
The raspberry pi is an amazing little gadget. Low power enough that I don’t feel guilty about leaving it turned on overnight, but flexible enough that I can shove leds into it to grab my attention if needed.
Juju is ubuntu’s answer to setting up services in the cloud. Once installed you simply setup your credentials with an existing cloud provider like aws or hp cloud and then deploy things into it. Setting up wordpress for example is as simple as
juju bootstrap # Setup the cloud environmentjuju deploy wordpress # Start an instance and install wordpress on itjuju deploy mysql # Start an instance and install mysql on itjuju add-relation wordpress mysql # Connect wordpress and mysql togetherjuju expose wordpress #Allow wordpress to be accessed from a public ip
Install go onto the raspberry pi
Deploy a wordpress blog
We’re going to be installing the latest version of juju which is written in go.
Dave Cheney has written an excellent article on Installing go on the raspberry pi. On my model B (1.0 revision) I had to update raspi-config so that I could select the 240M/16M memory split, but you might have to see how you get on here. I choose to skip the tests and just ran ./make.bash to build go rather than all.bash.
I was unable to build juju using go 1.0.3. I ended up building go 1.1.1 from source, which seemed to work fine. From memory I believe you need to setup a folder to be your GOPATH before you can install the latest version of go.
Getting the latest tip of juju-core is easy using the go get command, it grabs all the dependencies for you, it does mean we’re grabbing tip, but there are ways to fix that later if we need to. juju-core is hosted on launchpad.net which uses bazaar for source control. This means you need to install it before you can run go get. I was able to install it on raspian using
sudo apt-get update
sudo apt-get bzr
Without doing the update I was unable to grab all of bzr’s dependencies, so I recommend running the update first.
Once bzr is installed you can install juju using go get:
sudo apt-get install libcurl4-gnutls-dev
go get launchpad.net/juju-core/...
When it’s finished you should find a juju binary installed. Mine ended up in my GOPATH, I think because I had something setup wrong somewhere. But if you’ve got this far I’m sure you’ll be able to find it.
Setting up Juju
There’s much better instructions for setting up juju here The basic steps come down to
Setting up a public key
Generating an environments.yaml file
Filling the file in with the data for your cloud provider
I configured juju for aws. My ~/.juju/environments.yaml file looked like this: