Tox and Travis CI

Until recently, my approach to building python projects that used Tox on Travis CI was simply to have two separate configuration files, each duplicating the others settings.

This would normally work okay, with both Tox and Travis defining a set of python runtimes to use and a command to run on them. However, when it came to the more complex tox.ini file I’m using for python-dice, recreating this in the Travis configuration would have difficult to do, and require a lot of maintenance when the Tox settings changed.

The solution? Using Travis to run Tox, using it’s matrix feature and the TOXENV environment variable to create a different build for each of several Tox environments, like so:

:::yaml
language: python
env:
- TOXENV=py26
- TOXENV=py27
- TOXENV=py32
- TOXENV=py33
- TOXENV=pypy
install:
- pip install tox
script:
- tox

Playing with the Github Timeline data

I came across ‘The Open Source Report Card’ today, which included some interesting results on my report. It claimed I’d contributed to repositories using VimL and Go, neither of which I could remember doing anything in relation to.

Looking into how it worked led to the Github Archive, which is available as a dataset on Google BigQuery. Playing with this eventually led to finding the problem - the ‘contributions’ graph included all of a users events. This included ‘star’ (previously ‘follow’) events, so it was counting repositories I’d starred as repositories that I had contributed to.

A more accurate result was achieved with the following query:

    /* Count the number of my events by language excluding stars/follows */

    SELECT repository_language, count(repository_language) as n,
    FROM [githubarchive:github.timeline]
    WHERE actor="borntyping" AND type != "WatchEvent"
    GROUP BY repository_language
    ORDER BY n DESC

The Github Archive documentation seemed to be devoid of simpler example queries, so this is how I reached the above one, starting from one adapted from the primary example on githubarchive.org.

    /* List all of my repositories, counting the number of events */

    SELECT repository_name, repository_owner, count(repository_name) as events,
    FROM [githubarchive:github.timeline]
    WHERE repository_owner="borntyping"
    GROUP BY repository_name, repository_owner
    ORDER BY events DESC

    /* List all of my repositories, counting the number of events, and sorted by language */

    SELECT repository_name, repository_owner, repository_language, count(repository_name) as events,
    FROM [githubarchive:github.timeline]
    WHERE actor="borntyping"
    GROUP BY repository_name, repository_owner, repository_language
    ORDER BY repository_language, events DESC

    /* Count the number of my events by language */

    SELECT repository_language, count(repository_language) as repository_language_count,
    FROM [githubarchive:github.timeline]
    WHERE actor="borntyping"
    GROUP BY repository_language
    ORDER BY repository_language_count DESC

Spotter at Show and Tell

My second talk at a BCS Mid Wales Show and Tell event, this time on Spotter, a command line tool I wrote. The slides are available here.

ZSH startup time

I’ve had issues with zsh starting up and running very slowly for a while. I’d assumed the problem simply lay with the number of plugins and other scripts run by oh-my-zsh, but a bit of research has found two solutions that have worked very well for me (your mileage may vary):

  • Removing the github plugin. I don’t think I was using it much, if at all, and removing it stoped the noticable delay each time the prompt was shown (Source)
  • Adding skip_global_compinit=1 to .zshenv. This dropped the startup time of zsh from ~0.85 seconds to ~0.15 seconds. This was benchmarked using /usr/bin/time zsh -i -c exit (Source)

Nerf Rough Cut

I got the new Rough Cut ‘shotgun’ today - I shan’t bother with many pictures, as I’m sure most of you will have seen lots of them already. Instead, I’ll show some of the neat features that haven’t been talked about.

Nerf Rough Cut

It’s got a pair of small indicators at the back of the blaster, showing whether the blaster is loaded - one indicator for each side, as you can (with a little difficultly) fire single darts, and priming the blaster primes two chambers/springs/whatever (I’ve not looked at the internals).

Primed

Empty

As well as just having two chambers, instead of firing row-by-row, the blaster will always fire the highest dart from each side, regardless of which row it’s on. However, it doesn’t fire unless the darts are pushed all the way in.

The blaster is also a little wider than most of the pictures show, but the build is pretty nice, and quite easy to spin around! The slamfire also works better than I expected, firing 8 darts in just a couple of seconds.

Nerf Rough Cut