Ubuntu Cloud Images now available for Google Compute Engine

I'm really pleased to announce that Ubuntu is now a supported platform on Google Compute Engine. There are currently images available for 12.04 LTS, 14.04 LTS and 14.10. You can read more about the launch and how to get started in utlemming's blog post, Google's announcement or the Google Compute Engine documentation.

Setting up a Stellar trust line

Recently Stellar, a decentralized protocol for sending and receiving money in any pair of currencies, was announced. I decided to have a play around (because why not?). A core concept to Stellar is that of a gateway; an individual or organisation that takes a deposit (in 'real' currency) and credits you on the network.

Coinex are a New Zealand-based gateway, and are the first gateway for Stellar; they put up a challenge to be the first person to use them as a gateway (which I won!). To do this, you have to say that you trust that gateway to hold a particular amount of currency; in this case I wanted to publish the fact that I trust Coinex to hold up to $20 NZD for me.

To do this, you'll need to interact directly with the API (Stellar clients are still playing catch-up), and submit the following JSON:

{
    "method": "submit",
    "params": [
        {
            "secret": "<SECRET>",
            "tx_json": {
                "TransactionType": "TrustSet",
                "Account": "<your Stellar address>",
                "LimitAmount": {
                    "value": "<the amount you trust the issuer to hold>",
                    "currency": "<the currency the issuer will hold>",
                    "issuer": "<the issuer's Stellar address>"
                }
            }
        }
    ]
}

You can find <SECRET> on your Stellar settings page; everything else will obviously depend on what you're trying to do.

WARNING: POSTing your secret to live.stellar.org is potentially insecure; you would be better off signing requests locally; a blog post on this may be forthcoming.

You'll then need to POST this to the API:

curl -X POST https://live.stellar.org:9002 -d'<JSON>'

There's a bug in Stellar that means that newlines and/or indentation cause problems, so you'll need to make the above JSON just a single line and slot it in to the above command line.

Once you run that, you're done!

Push It!

Earlier today, Alex Couper presented me with a challenge on a captainhook issue:

I want to play "push it" by salt n pepa on every push.

Challenge accepted.

If you are using a sufficiently recent version of git (i.e. one which supports the pre-push hook) and have youtube-dl, mplayer and curl installed, then dropping this in to .git/hooks/pre-push for a repo will play Push It (in its entirety) on every push:

#!/bin/sh
curl -s "$(youtube-dl -g http://www.youtube.com/watch\?v\=vCadcBR95oU)" | mplayer -really-quiet -cache 8192 -vo null - > /dev/null 2>&1 &

PyCon UK 2013 Notes

Over the weekend, I was at PyCon UK 2013, which was fantastic! I took notes of some of the talks I went to, and the links to my Evernote notes are below:

• Tim Golden: Ten Things Coming in Python 3.4
• David Winterbottom: A Smorgasbord of Testing
• The Test People: Breaking Things for Money
• Rob Collins: Test-Driven Madness

For more PyCon UK follow-up goodness, check out the conference wiki.

Fixing nose.tools pylint errors

What is nose.tools?

If you've engaged in any test-driven Python development, you've probably considered using nose as your test runner. One of my favourite parts of nose (among its many excellent parts) is the nose.tools module. This not only contains a number of helpful tools (documented here), but also all of the assertion methods on unittest.TestCase converted to PEP-8 compatible functions (e.g. self.assertEqual becomes assert_equal).

These assertion functions are useful for a few reasons: readability, line length, PEP-8 compliance. Most importantly, though, is the fact that nose allows you to write test functions and test classes which don't subclass unittest.TestCase. The only way to access these assertions, therefore, is through nose.tools.

The assertion functions in nose.tools are generated at runtime from unittest.TestCase and put in to the nose.tools namespace. This has a couple of consequences: firstly, any new assertions in the standard library will immediately appear in nose.tools (a word of warning: as nose doesn't implement the assertions, you need to pay attention to stdlib unittest assertion changes). Secondly, this means that they don't appear anywhere in the source code if you go looking for them. This will become relevant shortly.

What is pylint?

If you've engaged in any team Python development, you've probably considered pylint to help you maintain code quality. pylint uses static analysis to find problems in your code. Static analysis just means that it looks at your code as text, rather than executing it (which would be dynamic analysis). The problems it finds range from bad syntax to poor style; it can even work out when you've tried to import a non-existent symbol from another module.

What's the problem?

This last feature is really useful most of the time; it has saved me from pushing broken code innumerable times. However, it does cause one major headache: because the nose.tools source code doesn't contain the PEP-8 assertion functions (remember, they're dynamically generated!), pylint's static analysis can't find them; every single time you import one of them you get a pylint error (E0611, to be precise). If you're using nose as part of your continuous integration to check your pylint errors, this can be a major source of pain. Luckily, pylint has a solution: disabling checks.

Fixing with disabled checks

pylint allows you to disable checks in a couple of ways: you can disable them globally (i.e. none of these warnings should ever be displayed), or based on scope (i.e. this module, class, function or line should never have warnings displayed). So, for example, an import line could look like:

from nose.tools import assert_equal  # pylint: disable=E0611

Problem solved! Your pylint run will no longer flag this line up as problematic. There are a few issues with disabling checks, though. Firstly, you have to remember to do it. Secondly, it crufts up the screen when you're trying to read, and gives you more information that you need to process. Finally, and often most crucially, you can accidentally change the scope of your disabling. Consider the following lines at the top of a module:

# pylint: disable=E0611
from nose.tools import assert_equal, assert_items_equal, assert_greater

This does solves the warning (and avoids violating PEP-8's line limit), but it has an unintentional consequence: E0611 is now disabled for the entire file. pylint will no longer catch this obvious error!

# pylint: disable=E0611
from nose.tools import assert_equal, assert_items_equal, assert_greater
from mcok import Mock

Fixing with a pylint plugin

Luckily, there is a better way of solving this problem than disabling individual checks everywhere. pylint provides a plugin interface so that people can implement their own checks and plugins. Using this, we can also modify the way that the static analysis looks at the nose.tools module. In this pylint plugin, I have implemented a function which transforms the abstract syntax tree which pylint uses when looking at nose.tools to inject all of the functions which are generated at runtime:

from nose import tools

function_template = """
def {}(*args, **kwargs):
    pass
"""

def nose_transform(module):
    funcs = ''.join(function_template.format(func_name)
                    for func_name in tools.__all__)
    fake = ASTNGBuilder(MANAGER).string_build(funcs)

    for func_name in tools.__all__:
        if func_name not in module.locals:
            module.locals[func_name] = fake[func_name]

Just follow the installation instructions in the gist, and all of your pylint nose.tools problems will disappear!

BrightBox munin plugin

We're signed up with EE for broadband, and they provide us with a BrightBox router. I wanted to see what connection speeds we were getting over time, so I wrote a munin plugin which would graph it for me.

You can find the source, installation instructions and sample output on GitHub.

Zero-Hour Contracts: Letter to my MP

Earlier this evening, I read the Guardian article about Sports Direct's zero-hour policy for their part-time staff. After my wife pointed out that a bitchy outburst on Twitter wasn't going to change anything, I decided to write a letter to my MP, Kate Hoey, using the excellent WriteToThem service.

If this issue (or any other) winds you up as much as it does me, I would recommend using some of your self-righteousness to write a letter to your MP. How I did so is enclosed below.

Dear Kate Hoey,

You may recently have read in The Guardian about Sports Direct's policy of keeping all of their part-time employees on zero-hour contracts[1].                                                                                      
                                                                                                                                                            
I feel like zero-hour contracts are unacceptable, as they leave employees with no sick pay, holiday pay or guarantee of future earnings. This sort of security is something that I feel an employer should provide their employees with.

I would appreciate hearing your thoughts on this matter which I consider very important.

Yours sincerely

Daniel Watkins

[1] http://m.guardian.co.uk/business/2013/jul/28/sports-direct-staff-zero-hour-contracts