The Tomes of Experience

I’m running Raspbian (Wheesy 2013-05-29) under QEmu just to make dev a bit quicker. The problem goes that the Raspbian image is 2GB which leaves only 200Mb free for apps/data.

To resize the image, start by resizing the image and giving it an extra 2GB (this is run on the host):

> qemu-img resize 2013-05-29-wheezy-armel.img +2G

Now boot into Raspbian and issue the following to resize the partition (from within linux):

1. > sudo fdisk /dev/sda
2. Print the partition table ("p"). Take note of the starting block of the main partition
3. Delete the main partition ("d"). Should be partition 2.
4. Create (n)ew partition. (P)rimary. Position (2)
5. Start block should be the same as start block from the original partition
6. Size should be the full size of the image file (just press "enter")
7. Now write the partition table (w)
8. Reboot (shutdown -r now). After reboot,
9. > sudo resize2fs /dev/sda2

When that’s all done, run “df -h” and you should have plenty of space.

Like most things in life, our current software project is powered by Git, and historically we’ve been using git to generate the version numbers for our builds by sucking it out from the tags in our repository via git-describe.

$ git describe --tags --long --match v*
v0.3.0-0-g865eb5f

This works wonderfully well when you have a single-line commit history, as the tag for versioning is the most recent tag.

Recently, however, we switched to using Vincent Driessen’s Git branching model, which opens up a serious hole in the simple versioning system. When you prepare a hotfix release for master, you tag the hotfix branch at the point the hotfix is being applied. This has the unfortunate side-effect of screwing up the way git describe determines the “nearest” tag.

I’ve created a sample repo demonstrating this problem. If you’re not keen on grabbing the repo, follow along with the screenshot below.

Basically what we see here is a hotfix being applied for release v0.1.0 while development continues on v0.2.0. The hotfix is merged back into develop (but decided not to be merged into master as the hotfix could wait until the next release).

Running the git-describe command above *SHOULD* yield v0.2.0-4-gba68c2f as the tag for develop in order to be true, however it comes back as v0.1.1-4-gba68c2f, which leads to our builds being completely mis-versioned. (We just versioned 0.2.0 code as 0.1.1 – how shit are we?)

Okay, so why is git picking up my v0.1.1 tag instead of the v0.2.0 tag? Turns out it has a lot to do with the explanation of how git-describe works:

If multiple tags were found during the walk then the tag which has the fewest commits different from the input committish will be selected and output. Here fewest commits different is defined as the number of commits which would be shown by git log tag..input will be the smallest number of commits possible.

Which is all well and good, however the describe algorithm ended up traversing a merge-branch down from develop and erroneously (for our purposes) finding v0.1.1 because it was closer to HEAD than v0.2.0 (well specifically in this example case they have the same number of commits, but the depth of the merged branch seems to be more appealing to git)

Digging around a bit more, I found that the git log command actually has an argument to have git-log search only the first (oldest) of multiple parent commits (ie: merges). enter –first-parent

Follow only the first parent commit upon seeing a merge commit. This option can give a better overview when viewing the evolution of a particular topic branch, because merges into a topic branch tend to be only about adjusting to updated upstream from time to time, and this option allows you to ignore the individual commits brought in to your history by such a merge.

…and when you use that to find the appropriate tag, it does!
$ git log --oneline --decorate=short --first-parent | grep '(tag:' | head -n1
b4aa13c (tag: v0.2.0) continued work on develop

So first-parent history search behaviour is what I want, but it’s not available on git-describe. Turns out, i’m not the only one who’s come across this…It’s a shame, really because describe does everything else perfectly, except for the algorithm to find the closest tag.

Unfortunately there’s no clear work-around or even a solution as to when a –first-parent argument will be made available for git-describe, which meant I had to come up with this monstrous flake of rake script to get the build version identifier (formatting doesn’t do it justice):

def git_version_identifier
  tag_number = `git log --oneline --decorate=short --first-parent | grep '(tag:' | head -n1`

  version_number = /v(d+).(d+).(d+)/.match(tag_number)

  `git describe --tags --long --match #{version_number}`.chomp
end

which (in a nutshell):

1. Finds the appropriate tag number for the current branch as per the bash-fu you saw earlier
2. Parses the previous output for the tag identifier (vx.x.x as per our convention)
3. Fires THAT tag id into git describe to get it to generate the identifier properly, bypassing its search mechanism

Seems convoluted and i’m not really happy with the result. Hoping that someone out there knows something I dont.

When it comes to software tools, i like to spend my time bleeding on the edge, where possible. One of the downsides to this, however is when you hit the carotid artery and bleed your tech heart all over the place. Having recently experienced this problem while using the dev channel build of Chrome, i’m fairly cautious of all the tabs I have open and losing them was a (queue Elton John…) sad sad situation, to say the least.

More recently I became the custodian of an older generation MacBook Pro as a challenge to see how much of my life could transport over to OSX from Windows. One of the things I wanted to make sure of was that (at the very least) I managed to keep a backup of all my open tabs, should the shit hit the fan and a dev build of Chrome for Mac bit the proverbial. The nice thing about Chrome is that when your normal life is replaced with a gLife, you can sync all your bookmarks with big brother and they’ll keep them around for you to access anywhere.

So after a few tweets and pointers in the right direction, I learned that Mac has long had this thing called AppleScript – basically a language which can be used to automate any part of the operating system and programs which it hosts. After a lot of googling, reading help files and finding the incredibly useful Ukelele i managed to scrounge together the following script (saved here in case i ever need it again)

tell application "Google Chrome" to activate
tell application "System Events"
	-- bookmark all tabs
	keystroke "d" using {command down, shift down}
	tell application process "Google Chrome"
		repeat until sheet 1 of window 1 exists
		end repeat
	end tell
	
	keystroke ((current date) as string)
	
	-- tab to bookmark folder list
	key code 48
	
	keystroke "Other"
	key code 124 -- retain focus on "Other..." folder
	key code 125 -- down arrow for "Tabs" subfolder
	
	keystroke return
end tell

It’s not a highly dynamic or robust script, but then again nor does it need to be – it’s running in a controlled environment and does the job of what I need (near) perfectly well.

Scheduled an iCal event to execute the script at 1am, and hey presto i’m happy to be playing around on the edge once more.

Notice in a previous paragraph I said the script is near perfect. One of the limitations of AppleScript is that its higher-level functions require a library of commands to be built into any application you intend on scripting. Currently, the script library for Chrome is pretty average, so everything has to be done by simulating keystrokes. The only thing I can’t do (or at least couldn’t immediately see how to do) was to prune old backups – the only way I’ve found I could do this was to highlight the bookmark folder from the bookmarks bar and right-click to delete.

Either way, im happy with the result, and it’s another language I can add to my arsenal.

I’ve been writing a little bash script to wrap up the functionality in the JIRA CLI, and i’d noticed that sometimes, my script was spitting out the following error:

sh.exe": [: too many arguments

The code in question was:

j () {
if [ -z $3 ]; then
echo jira --action progressIssue --issue "$1" --step "$2";
...
...

It turns out the problem was that the variable $3 in the second line was being substituted directly into the if statement, without being quote delimited. So Bash is treating any input in $3 with spaces as multiple arguments (hence the “too many arguments” error). Duh.

Solution is to quote the $3 variable in the conditional to treat it as a single argument. Shouldn’t make this mistake again…

Whenever i’m teaching my class, my laptop is connected to the projector and i’m running through an example on the screen, I make a conscious effort to NOT use ReSharper because its refactorings do so much and the keystrokes are so fast that my students are unable to keep up with the content i’m presenting. Remember in most cases, these are students who don’t know how to create a property or a field or variable, so my “Extract Field” refactor just completely loses them. Just because I make a conscious effort not to however, doesn’t mean I subconsciously make the mistake every now and then. And almost every time I make the mistake I have to explain what just happened, what the tool was, and what it did for me. Most classes just nod their head and placate me so that we don’t run overtime (again). Keep the loud, talky-talky man happy and we might all get out before 10pm…

Except this semester. For the first time, I had students come up after the class and ask me about ReSharper, and what it did. I gave them a 5 minute whirl-wind tour of the tool, showing them the extract field/variable/method refactorings, move file refactoring, live templates and the integrated unit-testing. It seemed like they were hooked. In the weeks following, I was inspecting code they were writing on their personal computers, and noticed the ReSharper menu in the VS toolbar. Seemed like a victory! One step closer to bridging the gap between academia and industry.

This got me thinking about ways I could further motivate my students to put more effort into this subject, and had an idea of getting in touch with JetBrains to see if they’d be interested in partnering by providing a licence for ReSharper to give away to the student who performs best in the subject. The idea would be for me to dedicate 10-15 minutes at the start of my lesson to actually explain the tool to the class, why it’s important for them to use this particular tool and give them the demo to blow their metaphorical pants off. This all started to brew about 2 months ago…

Well as of last night, the first part of my plan fell into place. After long discussions with JetBrains, I’m pleased to say they’re happy to award a personal edition licence of ReSharper for C# to the best student in the class, for each semester as an ongoing initiative! I really wasn’t expecting such a committed outcome from them, but thoroughly pleased with the result!

Now all I have to do is evangelise…I figure that the students who get the best marks are the ones who have put genuine care and effort into the project, and one of them deserves to be rewarded with a tool which makes them more productive and helps them enjoy what they do more.

Just wanted to shout-out here to anyone who reads this blog and hasn’t used ReSharper – you really are missing out.