# Category Archives: General

Paraphernalia and chaos.

# Interaction in team projects

I had an interesting experience over the summer, working in a small but diverse team on a single project for several months. I was contracted to design and maintain the build system, and so ended up getting involved in all areas of the project. As a result, I came across many of the problems which my team mates were having. A lot of these problems were my fault, some were my team mates’ faults; but a lot of the problems were a result of bad communication.

While this all occurred in a (unfortunately) closed source project, I’ve seen similar things happen in open source. I thought I’d come up with a list of suggestions for people starting out in the open source world, to try and help them understand the best way to interact with other people on the same project, or with their mentors in GSoC (for example). None of this is targeted at anyone in particular (especially not the GSoC students I had the pleasure of interacting with this summer)!

Thinking about this has been useful to me; hopefully I won’t do any of these things in future (because I certainly have in the past). I just hope it’s useful to someone, somewhere.

• Don’t spam chats with half-written messages. Take your time and formulate your thoughts properly in a full sentence. Spamming messages just means the other conversant has to sit there and wait for the rest of the sentence, rather than getting on with something else.
• Don’t join a chat, say “hi” or “someone please help” or “ping” and then sit there without giving more information. This just introduces an extraneous round trip in communication, since someone has to then ask what the problem is before they can start to help. Conversely, if someone joins a chat and says “someone please help”, don’t lecture them about it. Be patient, and help them as much as you can.
• After asking a question in a chat, wait patiently for the answer to the question. Although they’d love to help, developers are not constantly looking at their chat client. If you leave a fully-formed question in the chat and then wait, a developer should answer in their own time.
• If you encounter an error or warning (e.g. from a compiler or program) and want help with it, always provide the full error message and some context. The person who’s helping you isn’t psychic.
• Always give context and be careful of over-using pronouns. “It’s running awfully slow” is not specific enough. What is ‘it’? What were you doing with ‘it’ when things slowed down?
• Look at man pages and --help output before asking people. Documentation for established software (e.g. SVN) is generally quite good. The person who’s helping you will probably just look at the man page anyway.
• Read VCS commit logs. Ideally, people will explain and justify all of their work in their commit messages, and mention things which you should be aware of. Reading the logs may well save you debugging later.
• Use the correct terminology as much as possible, and don’t use that terminology in other contexts where it could confuse matters. Communication is a lot faster if a common vocabulary is used.
• Learn your version control system and learn it well. It’s a tool you’ll be using every day, and making mistakes with it can be costly for your (uncommitted) work and/or for other people’s productivity. Always check the changes you’re about to commit, especially if conflicts have occurred. People will not take kindly to their work being overwritten because you’ve made a mistake, especially if it happens regularly.
• If you’re making use of someone else’s code/APIs and you have a problem or can’t get it working, double check (against the documentation which they have written) that you’re using the code correctly. In many cases, the problem might be the way you’re invoking/using that code, not the work itself (thought such problems do suggest a lack of user friendliness in the work which could be fixed).
• Always check to see if the code at least compiles before committing it to VCS. Committing something which doesn’t compile due to a trivial error shows a complete lack of testing or care. Compile it using the build system which everyone else uses, too. Manually invoking the compiler doesn’t count.

# More festive drinks

It turns out that stuffing my failure of an apricot liqueur full of spices has worked, and I now have a bottle of tasty festive spicy apricot vodka. Here's the recipe in full:

## Ingredients

• 300g dried apricots
• 700ml vodka
• 1 large cinnamon stick
• Rind of 1 orange
• 4 cloves
• 8 juniper berries
• ~200g granulated sugar

## Method

1. Submerge the dried apricots in boiling water and leave them overnight to re-inflate. I had to do this because I could only buy dried apricots, but I guess an equivalent mass of fresh apricots would work.
2. Split the apricots into halves and put them into a 1.5l plastic bottle (an empty water bottle is perfect) with a cinnamon stick and the vodka. It's better to put the apricots in first so that they don't splash.
3. Seal the bottle well and shake it.
4. Leave the bottle in a cool, dark place for around four weeks, shaking it every day. The precise amount of time you leave the mixture to infuse doesn’t really matter, as long as it’s more than about three weeks. Try to avoid opening the bottle during this time, as that’ll introduce contaminants.
5. After the mixture has infused for a suitable amount of time, filter it out into another bottle. This might take a day or longer, depending on your filter paper. Use fine filter paper (coffee filter papers worked well for me), and be prepared to use several filter papers, as they will get clogged up. Keep the apricots!
6. Once filtering is complete, add sugar to the filtered liquid to taste. 200g should be about right (I used 225g this time, and it was a little too sweet). Add the cinnamon stick again (or use a fresh one), and the orange rind, mace blades, cloves and juniper berries. Seal the bottle up again and leave it for at least another two weeks, shaking it daily.
7. After at least two weeks, filter it again. This should take a lot less time, as most of the fine sediment will have been removed during the first filtration.
8. Drink and enjoy! The recipe produces about 700ml of spiced apricot vodka. The apricots left over from filtration are nice in a pie, though they will have lost a lot of their flavour (more so than the raspberries).

I'm sure it would be quite possible to infuse the vodka with the apricots and spices at the same time, but I didn't try this, so I can't be sure. Another thing I probably should've done is added the sugar after infusing the vodka with the spices, as that would've allowed it to be added to taste. As it was, I added what I guessed was the right amount and fortunately it turned out well.

While not busy playing around with drinks, I've got around to finishing off and releasing libgdata 0.8.0. This vastly improves upload and downloads via streaming I/O, as well as fixing a lot of race conditions, leaks and cancellation problems. This release doesn't introduce much new functionality, but breaks a lot of API, hopefully for the better.

# Festive drinks

Earlier in the year, I experimented with making fruit liqueur at home; I made a bottle of raspberry vodka with great success. Seeking to repeat the success and add some variety, I recently tried making apricot vodka (with the intent to have it ready for Christmas and the New Year). Unfortunately, I failed. It turns out that apricots don't have enough flavour in them to overcome the taste of vodka, and so I've ended up with pale yellow coloured bleach. I'm now attempting to rescue it by ramming it full of spices.

I realise it's a little late now for anybody who's interested in making this for Christmas, but if anyone fancies making it some other time, here's the (successful, at least in my opinion) recipe for raspberry vodka. It takes three weeks or more to do. A good recipe for apricot vodka is left as an exercise for the reader.

## Ingredients

• 675g fresh raspberries
• ~1tbsp lemon juice
• 700ml vodka
• ~250g granulated sugar

## Method

1. Slightly crush the raspberries and put them into a 1.5l plastic bottle (an empty water bottle is perfect) with the lemon juice and vodka. It's better to put the raspberries in first so that they don't splash.
2. Seal the bottle well and shake it.
3. Leave the bottle in a cool, dark place for around four weeks, shaking it every day. The precise amount of time you leave the mixture to infuse doesn't really matter, as long as it's more than about three weeks. Try to avoid opening the bottle during this time, as that'll introduce contaminants.
4. After the mixture has infused for a suitable amount of time, filter it out into another bottle. This might take a day or longer, depending on your filter paper. Use fine filter paper (coffee filter papers worked well for me), and be prepared to use several filter papers, as they will get clogged up. Keep the raspberries!
5. Once filtering is complete, add sugar to the filtered liquid to taste. 250g makes it fairly sweet, so you could quite easily use less. If you're not sure, add it gradually, since it only takes a few tens of minutes (and some shaking) to dissolve.
6. Drink and enjoy! The recipe produces just under 1l of raspberry vodka. The raspberries left over from filtration are excellent when eaten with cream or ice cream.

I can't take much credit for this, as it's based on a recipe I found here: http://www.guntheranderson.com/liqueurs/raspberr.htm. I made some alterations, though, such as doubling the ratio of raspberries to vodka. Fortunately, they seem to have worked out well.

In other news, libgdata's API documentation is now available on library.gnome.org! Thanks to Frédéric Péters for getting this sorted out.

# End of the summer

It's come to the end of the summer, and the end of my internship with Collabora. They've enabled me to spend three months helping work on adding meta-contacts support to Empathy in the form of libfolks; something which I've thoroughly enjoyed. Thank you to all my friends and colleagues at Collabora for letting me do this!

Term starts at university for me again in the next few weeks, so I expect to disappear back into the world of degree-enabling work, but I hope to be able to poke my head up from my little hole every so often, and possibly even submit a patch or two.

# Git commit hooks

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 91

Warning: preg_replace(): The /e modifier is no longer supported, use preg_replace_callback instead in /homepages/3/d35174004/htdocs/tecnocode/wp-content/plugins/latex/latex.php on line 92

I recently wrote/extended a couple of git commit hooks which have turned out to be rather useful. Once is a fairly standard commit-msg hook to check the format of the first line of a commit message is either "Release version x.y.z", "[tag] Message" or "Bug 123456 — Title":

tags="core|atom|gd|media|build|docs|tests|calendar|contacts|documents|picasaweb|youtube"
test "" != "$(grep -P '^(Release version [0-9]+.[0-9]+.[0-9]+| [\S].+[\S]|Bug [0-9]+ — [\S].+[\S])$' "$1")" || { echo -e >&2 "First line of commit message should be in one of the following formats:\n * 'Bug 123456 — Title'\n * '[tag] Message'\ \n * 'Release version x.y.z'\nValid tags are:\n *${tags//|/\n * }"
exit 1
}

Just define the tags your project allows in the tags variable, separated only by pipes.

The other hook is a pre-commit hook to ensure any new API has a Since: tag if it's got a gtk-doc comment. It's implemented as a modification of the sample pre-commit hook, so here's the diff:

--- /home/philip/Downloads/4m8QcjYs.txt    2010-03-28 19:14:50.432440248 +0100
+++ pre-commit    2010-03-22 20:37:47.612794352 +0000
my $filename; my$reported_filename = "";
my $lineno; + my$in_gtk_doc_comment = 0;
+    my $used_since_tag = 0; sub bad_line { my ($why, $line) = @_; if (!$found_bad) {
@@ -64,6 +68,19 @@
if (/^([<>])\1{6} |^={7}$/) { bad_line("unresolved merge conflict",$_);
}
+        if (/^\s*\/\*\*$/) { +$in_gtk_doc_comment = 1;
+        $used_since_tag = 0; + } + if ($in_gtk_doc_comment && /^\s*\*\*\/$/) { +$in_gtk_doc_comment = 0;
+        if (!$used_since_tag) { + bad_line("new gtk-doc commented API without a Since: tag",$_);
+        }
+        }
+        if ($in_gtk_doc_comment && /\*\s+Since:\s+[0-9]+.[0-9]+.[0-9]+$/) {
+        $used_since_tag = 1; + } } } exit($found_bad);

It looks for the start of a gtk-doc comment block in any added code, and errors if it doesn't find a Since: tag before the end.

Hopefully these'll be useful to somebody. They've both turned out to be more useful to me than I'd hoped, so hopefully my commit messages make a little more sense now. The code for both of them is in the public domain.

# Introspectable libgdata

Now that full term at university has finished, I have a little free time (inbetween sleeping, doing all the holiday work, and that celebration thing that people seem to do) to spend on projects. Today, I got round to adding GObject introspection support to libgdata. I think some of the Makefile changes I made were a little hacky, but they seem to work. If anyone wants to use libgdata from an interpreted language which has GIR support, it should now be possible.

In university news, things have gone well this term, and I managed to (precariously) stay on top of the rolling mountain of work. I've now got two weeks' stay in Cambridge to help shepherd interviewees around for their application interviews before I go home and do Christmassy things.

It took me until about half way through the term to notice that I was actually walking past Collabora's UK office every morning (opposite King's College). It was quite a shock when I noticed. It was also a shock to see they weren't at the computer lab's recent careers fair. Perhaps missing a trick there?

# University happenings

One of the lovely Austrian trains.

It's the end of a busy summer and I've just stumbled over the finishing line with some (very) late patches to Totem for the 2.28 release. Let's hope it's a good one.

This horrendous timing on my behalf for getting around to doing these patches is mainly due to tacking an InterRail trip onto the end of my busiest summer ever. Ten days travelling around sunny Europe with friends went surprisingly well, with only one person attempting to rob us. The highlight of the trip had to be the Austrian train system: easily the best out of the ones we used (French, German, Austrian, Dutch and Belgian). Photos of the trip are up on my PicasaWeb account.

And now for something completely different: university! I've got just under two weeks left before I leave to start my BA in computer science at Gonville and Caius college, Cambridge. The pile of stuff to take with me is starting to grow, all my computers are reinstalled with Fedora (which should hopefully last for three years without needing too much time spent on keeping it going), and most of my former schoolmates have already left for their respective universities.

I don't know how much time I'll have for GNOME stuff — I'll have to see how the workload is when I get there. It is, however, at the top of my free time priority list, along with learning all the funny language Cambridge has for things, punting, debating and drinking Pimm's. OK, I was kidding about the last three.

# Red Hat and Bloodstock

Nibbs Carter of Saxon.

Just over a week ago, I finished my month's work experience at Red Hat UK, and I'm pleased to say it went well. I learnt lots about how Red Hat works, dived into the kernel for the first time (and worked on some kernel patches!), got an RHCT qualification, and generally had a good time with our resident frockney. Hopefully he's managed to clean his house up sufficiently after my departure.

Woo! Poster!

The reason for leaving Red Hat mid-week is so that I could go to Bloodstock! It was a brilliant weekend, with the highlights being Die Apokalyptischen Reiter, Saxon, Satyricon, Turisas and Amon Amarth. Photos are up on PicasaWeb.

While sorting out the photos of Bloodstock, I also went through all the photos I took while in Gran Canaria for GCDS, so they're also now up on PicasaWeb.

# libgdata 0.4.0 released

This blog seems to be an endless stream of release announcements, which is unfortunate. Here's another one!

libgdata 0.4.0 has just been released. This release brings support for PicasaWeb and Google Documents, courtesy of Richard Schwarting and Thibault Saunier, respectively. The core API is slowing tending towards becoming stable, and the changes to the core API in this release should (hopefully) be the last really disruptive ones.

In a desparate attempt to make this post more than just a release announcement, here's a little update on my work experience with Red Hat. Things are going well; I've spent a while doing hardware testing, and I'm now doing some code review in anticipation of being given something else interesting to do tomorrow.

# Back from GCDS

With GCDS winding down on Friday, I made my way home on Saturday (again, courtesy of those nice people at the GNOME Foundation), and got back sometime late in the evening, thankfully without Iberia-caused delays. The conference was good, and it was great to meet more of those interesting people from all over the planet. I even managed to get some work done, with Thibault Saunier's Google Documents branch for libgdata landing in master sometime in the next few days.

Next up: four weeks of work experience at Red Hat UK. I'm currently occupying some stranger's house in a foreign part of the country, ready for my first day in Farnborough tomorrow. Should be fun.