Tools: Enhancing peer review through GitHub

You love GitHub. Of course you do. You love peer review. You especially love sending a pull request back asking for nits to be picked. So when your submitter claims to have addressed your concerns, how do you check? You could walk the commits. You could diff the entire pull request against master. If only you could diff the HEAD of the pull request against the original state of the pull request, letting you check just the new set of commits…

With github-differ you can!

Simply add this tiny extension^[1] to your Chrome, and it will decorate each commit in GitHub’s Commits tab. Pick any two commits, and the extension will redirect you to a page showing the comparison of those two commits! Job done!

[1]The JavaScript involved is so small that it should be trivial to port this to FireFox’s GreaseMonkey framework.

Tools: Comments are important

Nat Pryce wrote a fun little library the other day called code-words. It rips your source into words, and turns the words into a wordcloud. In short, a visual representation of the most common words in your source, and using font size to indicate the more common terms. The aim is to give an introduction into the concepts the code speaks about. And in playing around with it I noticed something interesting.

(more…)

Tools: Three approaches to ambiguous grammars

We have many tools in our parsing toolbox. Today let’s look at how three different parsing techniques handle ambiguity caused by choice.

(more…)

Tools: Just In Time Development

Since the dark ages of yesteryear Squeak has had a very interesting button in its Debugger – “create”. Today we’re going to teach it a new trick.

(more…)

Tools: cloverage – a code coverage tool for clojure

A couple years ago we presented a couple design sketches for a code coverage tool for clojure. More recently we spent some time researching whether existing code coverage tools would suffice for our requirements, and after finding out that java based code coverage tools either don’t work at all, or produce unhelpful output, we decided to finally write cloverage. You can find it on github: https://github.com/lshift/cloverage.

To try it out, add the lein-cloverage plugin to your user profile in ~/.lein/profiles.clj:

Then run lein cloverage in your project root.

It’s based on a prototype one of our commenters mentioned on Tim’s post. Thanks Mike!

Tools: Continuous Integration for Github Pull Requests with Teamcity

Most developers with an interest in open source software these days have seen the Github interface for handling pull requests, and relatedly, Travis CI’s support for pull requests. And so we thought it’d be useful to have something similar for our internal CI system.

(more…)

Tools: Using GitHub for planning

An important part of delivering software is knowing how long it will take to deliver some piece of functionality. Today we will see a small GitHub hack to help control estimation.

It’s all very well knowing the parts we need to implement some system. We need to know how long it will take to build. To that end, several of LShift’s GitHub-hosted projects use numeric tags to indicate the size of a task – maybe it’s in perfect engineering days, or abstract points. Regardless, with a large number of tickets, we can’t easily see how much work we’ve signed up for.

Something that would really help in understanding how much work is left in a milestone is simply totalling up the estimates. Given 5 tasks of 0.5 days each, and 2 tasks of 1 day each, it’d be nice to see at a glance that we have 5 × 0.5 + 2 × 1 = 4.5 days’ worth of work left.

Handily, Chrome makes it really easy to write an extension to augment GitHub’s pages.

(more…)

Tools: Making (Kindle) books from blogs

Admittedly, more and more of them are doing this already, but this is a slightly more DIY option…

So, you’d like some more reading material for your Kindle. Maybe you’re going away for the holidays, or just want to survive the elongated journey times of the Olympic period. There’s a few blogs I’d like to read more of, but I’d never gotten around to because of the sheer volume of back-reading I’d need to do first. What if we could dump those blogs (and blog-like things) onto the Kindle? Glad you asked, as that’s exactly what I’ve put together. (more…)

Tools: Using Debian Multiarch for cross-compiling

I’ve recently acquired a Raspberry Pi, and was considering using it for SNES emulation. However, as it turns out that Zsnes is x86-only, and that Snes9x got kicked out of Debian a while back for having an annoying “no-commercial use” license, so we’re into the compile-it-yourself options. As Snes9x is a configure/makefile-type project, I should in theory be able to just compile in on the Pi directly, but then we hit the problem that it hasn’t got enough RAM to be able to do all the compiling… fine, fine, I’ll go back into the messy world of cross-compiling. (more…)

Tools: Debian build-depends metapackages

When I’m doing development on an existing software project, and especially when I’m trying to bugfix something with a Debian package, I find that I install random packages I need to rebuild something, and then later on I’m wondering why I’ve got those installed. I tend to try to keep with the philosophy that the bits of software I’m using are pretty knowledgeable about whatever they’re intended to do, and so trusting them to make smart decisions is a good idea. For package managers, this means I should only keep track of the software that I actually use, and tell the package manager that everything else has been automatically installed and can therefore be removed when they cease to be a dependency of something I actually need. Having packages that I only installed for building something else without a record of that in the package management system breaks that mental model.

Enter dh-builddep-metapackage (the naming is inline with the names used by the debhelper scripts used for other debian packaging stuff). dh-builddep-metapackage builds build-dependency metapackages in order to ease package management for package rebuilders. In effect, it builds a “<package name>-builddep” package that has no content, but depends on everything that the existing package build-depends on. By using dh-builddep-metapackage to create metapackages rather than using “apt-get build-dep”, I keep a record in the package management about why I need a particular development package, and can remove the dependant packages when I’m no longer working with the relevant source package.

I think someone’s done this before, but some work with Google didn’t find it, and it was an interesting exercise anyway. Standard usage is “dh-builddep-metapackage -b <package name>”, which will create the metapackage data and build the package for you using dpkg-buildpackage. A folder called “<package name>-<package version>” will be created in the current local directory, and if an existing folder exists then dh-builddep-metapackage will refuse to overwrite it (unless you give the -o/–overwrite option).

So far I’ve used it a few times, and it’s quite nice to have those packages around to remind me about the dependencies. I’m considering building a full repository with *-builddep packages for everything in the Debian archives, but I’d like to make sure I’d use this enough first.