I just got home back from Berlin, where I participated in my first HackFest.

First day, first impressions

I was about 6 hours late for the first day, mostly due to weather related delays at Dublin Airport. I would have been a little late anyway (not enough days off left to fly in on Wednesday), but once there I quickly realised how beneficial it would have been to arrive a day early, attend the Welcome Dinner, and get to know people (at least names!) before trying to work with them. Lesson learnt for next time.

The first day was mostly discussions and planning what should be done, and toward the end assigning tasks to people for the following days. The whole HackFest thing is very focused, that first day was a lot of nerdy discussions except with a focus on getting things done (and thus not much patience for staying off topic). People were also careful not to make decisions for the whole community.

During most discussions, a few people were dominating/leading the conversation, which I wondered a little about at times. Some voices sometimes got ignored because someone louder started speaking or answering a question over them.

Being late meant that when a couple of topics I have an interest in came up, I didn't have yet a good enough grasp of the group dynamics to be able to chime in (my fault for being late and not speaking up anyhow). For instance someone mentioned the idea of a "Kid's corner" in the documentation for school students to learn about Gnome development. That's a topic dear to my heart, and what an awesome idea! There was no time to work on it during the HackFest but in case the idea surfaces up again I hope I will be around to listen in and participate.

In the end, the main plan became to work on a catalogue of "cool" demos to show and teach about different aspects of the platform -- first applications at a level a little bit above "Hello, World", for developers to try and expand on with their own cool ideas (the licence for the code in the documentation will allow for this, of course). Some people worked on other cool stuff.

The HackFest continues

I kinda messed up day #2. I can't help with writing code examples because I wouldn't know how to do most of them yet, and I haven't internalised best practices in Gnome Development either. So I kinda hid instead (I still had a good time! But I felt bad for not contributing enough).

I could have helped with writing, but it turns out most people wrote at fine to awesome levels all on their own already :) That left me with trying out tutorials and reviewing them with the fresh shiny eyes of a newcomer to the platform, which required the tutorials to be written first.

From day #3 I started jumping on people as they entered the office and constantly asking "Do you have anything you'd like me to look at?" so people knew to send things my way. Turns out some libraries (like libgda or webkit) couldn't build this week due to changes in gtk3 and I ended the day with Gnome Shell not starting on my machine, GStreamer behaving in the strangest way and also a better knowledge of Jhbuild ("Erm, could someone with a few minutes help me understand a Jhbuild issue?" - " *laugh* You do realise the maintainer is sitting besides you, right?"). Things merrily continued till the end of the last day, and I managed to test and review several tutorials and increase my knowledge of GStreamer, Javascript-the-Gnome-way, Clutter and Gtk, as well as learn about Mallard (the real question being, MAllard or mallARD?), glühwein, and how to say croissant in German (that's "croissant").

Sometimes someone would bring up a topic of conversation (intro to Mallard, what to include in the platform overview, how to revamp developer.gnome.org, ...) and people would assemble around the table, maybe use the projector and discuss what direction to take.

People did a beautiful job with the demo examples I got to test. They are simple, well explained, quick to try out and you do learn a lot when you go through them, while usually still getting a hint that there is more awesomeness to find if you dig further into Gnome. Most of the problems I encountered won't be problems when people run the examples on a stable Gnome 3 system in the future, as opposed to an active/fluid development version within a sandbox. I kinda failed at being a good representative of Python-as-a-first-class-citizen though: no example was completed in the Python language over the 4 days! C, Vala and Javascript will be nicely represented though.

People are very much "Work hard, Play hard" in a hackfest environment. Thanks to our Openismus hosts we got to work in a nice office, be introduced to lovely restaurants and visit a Christmas market among other things. People would go out at night and then come back to the office around 10 or 11pm and work longer into the night. I never stayed that late (happier working in the morning, as strange as it may be for a hacker).

As with my GUADEC experience, the Gnome folks are an incredibly nice bunch, very welcoming. An interested newcomer dropped by unannounced on Sunday and was taken under someone's wing to work on documentation tasks, mentor within arm reach.

I suspect it might have been a tad too early for me to attend a hackfest though (considering my lack of experience with the community and in general), even though I came here as one of the main targets for this documentation effort -- the Hobbyist, happy Gnome user and eager wannabe contributor. I'm still glad I attended and jätte-happy with my experience, and I hope my comments and feedback on the examples were helpful. Perhaps that is something I can keep helping with.

It's the first Malcolm Gladwell book I read and I'm well impressed. It's a pleasant read that challenges various preconceptions. It does seem heavily based on anecdotes but I think the people used as examples illustrate the points made well enough. The overall style of the book often reminded me of "Freakonomics" -- if you didn't like the style you probably won't like this one either.

The thesis of the book is that there is more than "hard work" and/or "being smart" to becoming an outlier in any field. People who make it big were also given incredible opportunities to learn and put in their 10,000 hours of training before they could shine. They worked hard for sure, but most of the time when and where you're born matters just as much. "Genius" and mastery aren't necessarily innate and don't matter as much as many people like to think either.

The second section of the book talks about cultural legacies and is fairly interesting as well, showing the impact on domains ranging from plane crashes to maths & reading ability to local feuds. As someone who's been living in a fairly different culture than my home country's for a few years now, I enjoyed reading chapters that clarified some of the things I've experienced but could not explain (like the effect of the "power distance index" on human interactions).

It's a light read that I have no problems recommending. I'm going to get "Blink" from the same author next.

I'm after "spring" cleaning a little the website. A bit of CSS here, updating some Django code there, adding a couple of icons and creating new pages. It's a bit sad how short the "Speaking & Writing" page ended up being! A clear path for improvement in 2011.

In other news I got myself a N900 \o/ I can now handle email while stuck on the bus, yay. I would have posted a picture, but I applied the protector film so poorly that I can't take a picture without weird reflections. Ah well. Here's a picture from Nokia themselves, who are much better photographers than I am :-)

Eek! Looking through my old drafts I can't believe I forgot to post this. I was waiting for the LWN link to become available to all -- but I guess it's never too late to share the awesome.

Article: GUADEC: Banshee project reaches out for contributors (LWN)

This is the summary of a very good talk, "Inside the Banshee Awesome Factory" from last GUADEC, describing a number of things that the Banshee project does to attract, welcome and nurture new contributors. For instance, they make sure to make plugin development fun, by automating away the boilerplate code -- kinda similar to starting a new project in Django (I wonder if that's something Sugar could use, to create new Activities...) Every contribution is equally appreciated, including the "typo" fixes that many people would start with. They're not afraid to welcome people with little programming knowledge, and walk them through how easy it is to fix a bug or add a new feature. I suspect this works fantastically to also attract good people who are not overly confident in their skills. The speaker wasn't scared to live-demo how easy it is to add a new feature, particularly if it's similar to something existing -- actually he was a very good speaker, if you have the time you might want to catch the video of the talk itself (day 3, Paris room, 10:15-11:00).

A very cool stat I forgot about, that's in the article: in the last 2 years and a half of development, Banshee has averaged one new contributor every week. That is awesome! It's worth looking into what it is they're doing right.

Here's an interesting article, "Cheating in Computer Science", that was recently posted on the IAEP mailing list. It's quite short and the problems it describes are worth mulling over:

• Why do we call "cheating" what will later in life be called "collaborating" and be a critical quality for success?
• Why do our education systems focus so hard on having students learn something in a specific intricate way that facilitates grading, rather than on the best way to learn the right thing?

I quite like the author's idea of changing the game, to reduce the motivation for cheating and encourage learning instead of simply working harder at punishing cheaters.

On a more practical note, he describes how he changed his way of teaching programming from the usual writing of a program from scratch without talking to anyone or reusing any code, to the following:

"Instead I give them programs that work and ask them to change their behavior. I give them programs that do not work and ask them to repair them. I give them programs and ask them to decompose them. I give them executables and ask them for source, un-commented source and ask for the comments, description, or specification."

I love this! Added to my stash of exercises-to-prepare for my next teaching adventure. Which should happen in January, by the way :-)