On Wednesday the 20th, we had the 2nd edition of Open-Source Night in Tog. I think it went well. Once again there was about a dozen attendees, many of whom have never contributed to open-source before. A third of them were also in Tog for the first time. It might be too early to matter but there was also very little overlap with the audience from last time.

Talks

We started the evening with 2 talks, meant to be about 15 minutes long each. Mark started the evening telling us about open-source licences and the philosophy they encapsulate/were born from. Then I walked through how one would go about contributing to Django, basically clicking through the Django website and explaining different tasks the project needs help with, particularly for bug fixing contributions.

After this, we had 2 lightning talks that were meant to last 2 to 5 minutes, to give people a chance to talk about a project they contribute to and get people to join in. This time the talks were more about ideas, which is fine, but both also ran overtime, which is less cool. I'm not sure if either found additional contributors/would-be contributors out of it for the evening.

Hands-on

The second part of the evening, the part that should be hands-on, didn't go so well. After the talks (which lasted for 1h30 instead of 45mins) and a tour of the hackerspace for the new people, most continued chatting instead of sitting down and getting things done. This especially saddened me for the ones who had never contributed before. The goal of the event is to help newcomers get started contributing, when they have experienced people at hand to ask questions to.

Next time

I'm not sure how to improve this next time and help attendees get started actually doing stuff. Running overtime for the talks really hurt for the rest of the evening, which is already such a short time to accomplish something. An idea: after my talk I was asked "How long would it take for someone to start from nothing to being able to run the Django unit test suite?" and maybe this kind of well-defined, self-contained task would be good to help people get started. It's not a contribution yet, but it's a first, necessary step toward it (for code contributions in any case), and it could be fun to try and mix this with some sort of open badge.

Somewhat related announcement: open-source night won't happen on April 17th next month but probably on April 24th instead. Check the tog.ie calendar for confirmation. If you're interested in speaking on a topic relating to the life of open-source or a project in particular, please get in touch :)

On Wednesday, Tog hosted the first monthly Open-Source Night.

It's an event I'd been wanting to organise for a while, with an eye on it being hands-on and slanted toward helping interested people get started in open-source, but I wasn't sure what format would work best. I'm still not sure, but in the spirit of release early, release often, I thought I'd give it a shot for a few months and iterate.

For the first event, about a dozen people showed up. About 7-9 of them had already made some kind of contribution, most people had a clear idea of the project they wanted to contribute to for the evening, and 3 were hesitant and not sure what they wanted to do.

We started with 2 super short talks, an ill-prepared one from myself about what to do tonight: basically find the contributor's guidelines for the project you're interested in and speak to the person next to you for help, since we had such a skewed ratio of experienced contributors. Triona followed with a talk on what she planned to do in the evening with Free Penguin, an open-source sewing pattern for Tux plushes. The maintainer hasn't updated nor responded to emails in years, so it seems it will need to be forked in order to start improving the documentation. Open-source projects aren't all about code! :)

I directed the hesitant project-less people toward Cheryl and the Dreamwidth project, which has an excellent reputation for being friendly to newcomers. Even without an experienced contributor around, I thought figuring things out together would be a fun learning experience. It may not have been that effective though, people were interested and looked around but nothing got accomplished (perhaps that is to be expected for a first couple of hours getting acquainted with a project and open-source?). Then further efforts were thwarted by technical problems (bugzilla down). Cheryl's thoughts abut this is that it's difficult to get into a project one doesn't feel strongly about (a similar downside applies to projects discovered via OpenHatch, as someone else mentioned to me).

There were a couple of serendipitous meetings, like the person wanting to get started with Debian packaging who happened to be sitting besides a Debian Developer.

But overall, I think having encouraged people to come along already having a project in mind made it difficult to form groups and encourage collaboration, because people ended up working on the project they had planned to alone. It may not have been a great experience, particularly for people who didn't know anyone or hadn't been in Tog before.

I also need to become more familiar with projects who have good, specific non-programming-related tasks for newcomers. I had a general idea but wasted time trying to find the details. We had a graphic designer interested in either contributing his design skills, translating or participating in testing efforts but I wasn't able to quickly find a good "Here's a concrete task you can do now" for some of the better known projects. He did discover InkScape and became eager to learn it, so I hope to see him again in Tog in a few weeks for teaching an intro workshop to InkScape :-) (Thanks Borud!!)

Ideas on how to evolve the format for next time:

Choose one project and make it the main focus of the evening, at least at the start. Meaning only one presentation, that is a bit longer (ideally 20 minutes, max 30 -- we still need time to actually do stuff!) and give specific, step-by-step instructions on "this is where you go to find something to work on, this is how you choose a task" and afterwards have the people interested in working on the project do so together - several people to one task can work, to encourage learning together and avoid getting stuck. People are still welcome to work on whatever else they want to of course. This was suggested by Ulrich based on the recent Debian Bug Squashing Parties he attended.

Becky said there was an interest in a GitHub pair programming type of exercise. People upload code on GitHub they never touch again. Working on someone else's code with the help of the author could turn into an instructive experience. It would also be cool to see what a pull request looks like from both sides.

I think we can try both these things for next time, the GitHub pair programming could start after the presentation for people not interested in working on the highlighted project.

Now. The next step is to find a project to highlight and a willing contributor who'd like to present and guide, for the next session on March 20th. Ideas, volunteers? :)

Feedback and general thoughts on evolving the format are warmly welcome as well.

Are you an experienced open-source contributor interested in recruiting new people for your project?

Are you a fan of open-source who would be interested in contributing at any level but isn't sure how to?

Come to Tog's first Open-Source Night on February 20th!

These hands-on sessions aim to bring together experienced open-source contributors with people who would like to get started but aren’t sure where to start or would generally benefit from having someone to ask questions to.
[...]
Every month we will start with a couple of people speaking for 5-10 minutes, to introduce the project they are working on, what is the usual path for contributing and where they are currently looking for help. Then we will form groups and work on making a contribution for the rest of the evening.

I'm hoping to make this into a regular monthly event. The current plan is to try it for a few months and see what it becomes. This will heavily depends on who attends so, help me recruit lots of interested people from both side of the contributor spectrum in Dublin :)

The general view of open-source communities when standing at the edges is probably a vision of endless flames, strong personalities clashing, patches being ripped to shreds on mailing-lists, RTFMs, and the general need to have a thick skin when going in there or being crushed to pieces. The high-profile projects where one might think to contribute first like the Linux Kernel can have quite an intimidating culture, keeping lurkers looking out from stepping in.

I rarely read stories about the really friendly projects that do their best to mentor newcomers.

I'm currently mentoring for the OpenStack project as part of the Gnome Outreach Program for Women. Everyone I see talking to the interns, whether or not they're directly involved with or even aware of OPW, is helpful and makes the time to be friendly and answer questions ; what they see is new contributors interested in helping out and it's in their own interest and the project's to give a hand at the start, when it is most needed.

If you like open-source and sometimes think you'd like to contribute if you could: explore the community for the project(s) you're interested in. Most of them are really nice places to be. Have a look. Ask someone on IRC or on a mailing list for where to find directions on how to get started. Healthy communities are concerned about being welcoming and attracting new blood, because they know they need it to survive and be sustainable.

And if you're still hesitant about jumping in and have a specific question I might be able to help with, get in touch :)

I enjoy listening to Last.fm and recently decided it would be handier to control it from within my emacs session. Getting it to work didn't take too long but wasn't as straightforward as I hoped, mostly because it's easier to find documentation for older versions of emms (including on the official website) and the last.fm parts have been entirely rewritten recently. Anyhow! If you're in a rush, the short version is: find the latest version of the code and follow the documentation from the source itself!

What to install

From your package manager, using Debian here:

aptitude install emms mplayer2

Note, that installing mplayer instead worked fine on an Ubuntu machine.

Getting an API key

Search the documentation linked above to get more details. Basically, using the latest version of the Last.fm API requires a secret API key, which isn't a concept that works well with GPL software. To work around this, we request a personal API key, which we will add to our .emacs config file.

Request a key at Last.fm. The keys will be displayed on screen rather than sent to you, therefore write them down now. As far as I can tell the "app description" will only be seen by yourself, when you allow emms-lastfm-client to access your Last.fm account so don't worry too much about the description.

.emacs

Add the following to your config file:

(require 'emms-setup)
(emms-all)
(emms-default-players)
(setq emms-lastfm-client-username "myusername")
(setq emms-lastfm-client-api-key "myapikey")
(setq emms-lastfm-client-api-secret-key "mysecretkey")

Setting up emms-lastfm-client

Now, within emacs (taken straight from the docs!):

1. M-x emms-lastfm-client-user-authorization - this will open a web page, asking if you want to grant access to the app (with the name and description you gave it when requesting the API key)
2. M-x emms-lastfm-client-get-session - this is to store the authorisation key so you don't have to go through the authorisation process every time. If it doesn't work you might need to first create ~/.emacs.d/emms manually.

You're set! M-x emms-lastfm-client-play-similar-artists to select who to listen to :)

Useful tips

To stop the music: M-x emms-stop.

To remove the url display/track information:  M-x emms-mode-line-toggle (or -disable) and to remove the playing time information: M-x emms-playing-time-disable-display (they push the org messages too far out right!)

Other error messages

Some messages you may encounter along the way...

Contacting host: ws.audioscrobbler.com:80
progn: missing variables to generate handshake call

The documentation seems to suggest that setting a username is optional, but it's not. Make sure your .emacs contains your username in addition to the API key and secret key.

f: Don't know how to play track: (*track* (type . url) (name . "http://play.last.fm/user/1234567890abcdef0.mp3") (metadata))

emms uses an external program to play music, which is why you need to install mplayer or vlc.

I like micro-blogging, or well, I hang out on identi.ca anyway. I'd like to use it more but I have trouble keeping track when I add interesting-but-too-prolific people on my subscription list, or I sink when the occasional flamewar/"debate" erupts in a group I follow. I don't write a lot but I read, and I wanted the reading to be more efficient. The way I read identi.ca at the moment is:

• either through the web page, trying to find back the page where I last read a notice and then coming back slowly to the first page
• or on XMPP, where if something came up while I was disconnected I can receive a huge heap of messages when coming online even though I may only have a few minutes available to read, and there's no way to mark where I stop if I only read through some of the notices.

Hm... You'd think there's a nice software announcement coming after this but there isn't really. This was the problem I set out to fix a few months ago and here I want to show how I used the wonderful Balsamiq Mockups software to wireframe my interface before jumping into the code (there is code though. You may skip to the end if that's the only thing you care about.)

Balsamiq Mockups

I've been using this for 18 months or so, and I really like it. It enables me to make on screen, in a nice readable way, something I used to scribble on paper before. The end result is something nice to look at that I can work from, and if this is software built for someone else I can show them (without any recoil of horror!) and make sure this is what they have in mind and that I'm not forgetting something glaringly obvious.

Let's go back to the micro-blogging reader. The first thing to handle was the timeline.

The first time you use Balsamiq -- after the first 5 minutes where you will be amazed and clicking eveywhere (try it, they have a web demo on their site!) -- it will take a bit of time to learn where to find what, and what widgets exist. Soon enough though, you'll be making these nice wireframes about as fast as the crappy hand drawings.

You can have several mockups open in different tabs, which is useful when working on a sequence of screens or different parts of the same project.

As hinted at on that first image, Balsamiq provides widgets both for wireframing, as well as for annotations about the wireframe itself.

Here I use fancy arrows, and a post-it note. There are other elements like the curly braces from before or the round yellow numbers, to help call attention to differents part of the design. With the different containers and widgets you can easily mock up desktop, web and mobile apps. The font and general feel of the different elements is this way -- a bit unequal, not perfect -- to remind of hand drawing and avoid giving a slick, "finished" impression. It's still easy to make radical changes at this stage of the development, so that's the kind of discussions it should encourage (also, as opposed to say a realistic HTML mock-up, the customer/user is less likely to ask if it'll be done by next week since it looks nearly ready already!)

The third and last mock-up I made for the project was of the menu:

Nice and simple. Go give Balsamiq's web demo a try, you'll see how intuitive the interface is and then you'll remember it when you need it or wish for something similar. It's worth every penny ($79).

Now, what about Pinch, you ask? Well, the first attempt looked like this:

The wireframe was a very helpful guideline in remembering my goals and the big picture, to avoid getting lost in the details over and over again, though of course one should feel free to veer away when needed. On a touchscreen, a button with some text is a lot easier to click than just a small icon for instance. Also, the moving red line turned out to be a pain in the butt to figure out in pygtk so messages are simply greyed out and it's just as readable.

By the way, did anyone notice the glaring feature omission in the mockups? If not, maybe you're more of a spectator, like me...! I found out when attending an interesting talk wanting to share some good tidbit and... oops. There's no way to post a brand new message :) Ah well.

Pinch

The app ended up being named pinch due to... a thesaurus really, never mind. At the moment it's really read-only: you get your messages, you mark them as read or highlight the stuff you want to deal with later. You can remove messages you've read. No replying or writing anything though. I still consider it technically usable by other people as my name isn't hard-coded anymore, thus it's possible to set up the app for yourself ;)

The main reason development stalled is that using the app is dead slow and I'm not sure of the best way to deal with it, and I haven't made the time to research how to handle this on a phone. There's a lot of waiting around looking at nothing while the app needs to grab URLs from identi.ca and parse the XML. There are still a lot of interesting problems to solve (and I still need a nice reader-optimised micro-blogging tool dammit), so I should get back to it eventually.

In the spirit of the Myth of the Genius Programmer talk and other people saying the shame of sharing code goes away after a while, I decided to open up my GitHub repo (or perhaps it is happening because I haven't touched the code since June and forgot how terrible, terrible it is).

Resources or tips on making performance improvements for pygtk and/or Maemo apps would be so very welcome, if anyone has recommendations? :)

I'm back for more enabling! (Mwahaha) Seeing there was some interest in LaTeX, the very awesome Triona kindly offered to teach an evening workshop on the topic on September 21st, in Tog. Whether you're interested in starting out with LaTeX, or would like a refresher, join us! The registration information is available on Tog's blog.

- - -

Hello you! Do you know about something cool, relating to open-source or open culture or technology? Would you like to teach a workshop about it? Please get in touch!

Link: talk description and video

A lot of user questions for the Google Code project are along the lines of "how do I hide code until it's ready", "how can I wipe the history and start from scratch" and so on: they are about people's insecurities.

When you have elitism and anonymity, suddenly everyone is elite. There's a whole mythology that gets built around programming heroes (Torvalds, van Rossum, Walls).

There are no genius. The only thing this has created is a fear of showing mistakes. This insecurity inhibits progress, makes the process slower, brings lower quality and a lower bus factor.

Avoiding the trap

• Lose the ego
• Criticism is not evil: give and take it politely. You are not your code. People criticising your code are not out to get you.
• Embrace failure (just don't fail the same thing over and over!)

The speaker shared an interesting story (probably an aphorism?) of an executive that makes a mistake that costs his company 10 million dollars. The day after, he starts packing up his things and when the CEO summons him to his office, he's ready to hand in his resignation, saying there is no need to fire him. The CEO replies "Fire you? Why would I do that? I just spent 10 millions dollars training you!"

• Iterate quickly
• Practice is key
• Be a small fish, as in don't be the smartest person in your company. You'll learn much more and faster
• Be influenced. "Alpha" programmers think they know everything and won't ever listen -- you may find that you actually gain more influence, by being willing to be influenced!
• Be vulnerable, repeated vulnerability becomes a strength long term.

Tools

Tools won't solve sociological problems, but they may influence behaviours. Pay attention to the tools, they can influence culture and moral, for instance by encouraging "cave" behaviour where developers work on their own for a long time and dump a big chunk of code: it's bad for collaboration, reviewing, etc.

You don't need to hide a project until it's "ready." Simply don't advertise it. People may find you because they are looking for something like this.

Don't let people collaborate until it's too late: they may help with code reviews, or pointing out to you existing libraries you missed. If it's too late in the project, they have no possibility to drive, to be a strong part of the project and it's less likely they will contribute.

Certainly get a prototype ready, some running code and some design, but let it still be something that you're happy to step back on.

Conclusion

• Don't try to be a genius
• Collaborate early and often
• Pay attention to default behaviours (the ones encouraged by tools especially)
• Pay attention to timing

...and if you do all this, people will think you're a genius!

Some of the questions/responses

Make sure to write a manifesto with the direction you want for your project from early development, so there are no major clashes or misunderstandings later on when people get involved.

If you don't care about credit, wow will you go places. If someone "steals" your idea and they have more reach (e.g. more clout/connections), it's great! It means it's more likely the idea will be implemented, and you'll have more ideas anyway.

On influencing a new team you just joined with best/better practices: start by doing good work and building up a good reputation, then you get to pay it back on something you believe matters. You have to choose your battles, you can't step in front of every train (resistance to change is like a very fast train! Hard to stop.)

After a few months of owning a N900 finally came the itch to write an app for it -- using of course Python! The Maemo documentation is excellent, I'm only putting my notes down here for future reference.

First off, making sure to know which version of Maemo is on the phone: Settings -> About: Maemo 5.

Setting up

The documentation at http://maemo.org/development/ is truly excellent. Of interest to us to begin with is installing the SDK. The wiki has been kept up to date with tips and links to solutions of potential problems at the stage where you might encounter them, making any issue a non-event.

Note: It turns out that the SDK is optional to develop with Python. If you would prefer not to set this all up, you can simply move your Python files to the phone or write the code there directly. Personally I found having a full SDK on the laptop to be really handy to try things out quickly, and to tweak and understand what the final result will look like.

Getting started, every time

The SDK docs lists the various commands that may work for your distro and system specifics, which is awesome but can be a bit dense to read through and find again later on. Here's what I do on Debian unstable:

Xephyr :2 -host-cursor -screen 800x480x16 -dpi 96 -ac &

and:

/scratchbox/login
export DISPLAY=:2
af-sb-init.sh start

Important: Don't forget to run `af-sb-init.sh stop` at the end, or say, if you messed your Xephyr command and need to restart it -- you will need to stop this script before attempting to start the emulator environment again. Otherwise there will be D-Bus conflicts and things won't work.

Hello, world

After setting up the SDK, the documentation recommends you go learn about packaging next -- I kept that one for later, it's more interesting to build something first!

By following the documentation you can find the Hello world for Python, which does work on the phone with no hassle and without stopping by the SDK: Developer Guide -> Programming Environments -> PyMaemo quick start.

If you'd like to work in scratchbox (quicker turnaround!), you can go back to the Maemo SDK on your machine and follow again the instructions to set up a Python development environment.

Hello world, again

The same Python-related packages need to be installed into the dev environment, within scratchbox.

nano /etc/apt/sources.list
deb http://repository.maemo.org/extras-devel/ fremantle free non-free
apt-get update
apt-get install maemo-python-env (and qemacs :o))

Note that on the phone, you would install maemo-python-device-env (cf. Quick Start Guide), while when working in scratchbox  you should install maemo-python-env instead (cf.  Python support)

qemacs -nw hello.py
python2.5 hello.py

Make sure you're calling `python2.5` explicitly or the program will fail with "ImportError: No module named gtk". While working with Hildon I use this command instead, which you'll learn when doing the UI Tutorial.

run-standalone.sh python2.5 hello.py

Because of the various warnings messing up my scratchbox screen, I ended up using emacs from outside of scratchbox. The files you're working with are located at /scratchbox/users/<username>/home/<username>.

Once you can run the Hello world program, the next step is to go through the handy UI tutorial, which teaches a lot about Hildon and GTK.

I would also recommend installing the devhelp packages for:

• PyGTK (python-gtk2-doc),
• the PyGTK tutorial (python-gtk2-tutorial), and
• the hildon API (libhildon-1-doc) (also available online). The API reference is in C but after doing the tutorial it's easy enough to guess the Python names. Note that although it's still handy, the Debian package does not appear to be the very latest version, e.g. HildonSizeType isn't documented.

I'm really happy with that setup, and it's lovely to get a nice looking UI working so quickly and easily. This is reconciling me with GUI programming -- it looks nice and because of the small screen, there isn't a ton of repetitive boilerplate to write. I can't wait to be far along enough in that project, that I have an excuse to learn again about Debian packaging! :-)

I'm facilitating-slash-attending a day-long workshop on Dexy in Tog next Saturday, March 26th. Dexy is an open-source tool for code documentation. The workshop will be presented and led by Dexy creator Ana Nelson and promises to be both interesting and a ton of fun :-) Ana plans to make it very hands-on, an open-source project will be selected beforehand so that the documentation we create is useful and meaningful. I'm really looking forward to it!

You can learn more about this...

...on Tog's related blog post

...and on the event sign-up page.

The event is free and everybody is welcome! Please sign up beforehand though, as places are limited.

And on a related note, if you're around Dublin and an open-source contributor, and would like to prepare that kind of event for your project, please chat with me. I would love to have more of these workshops in Tog!

Another fantastic edition of FOSDEM is now finished. Many thanks to the organisers for another great job!

Amazingly, the Welcome talk managed to top off last year's FOSDEM dance, this time by making the audience contribute the music. I hope they do it again next year, it was kind of fun smashing hands on the wooden board (middle row, yep!)

Many stands, a ton of talks, even more people than last year. Some dev rooms remained closed because full for most of the conference, but surprisingly if one carefully planned which talks to attend and made sure to be there a little early, it was usually possible to get in and even grab a seat.

I'll post short summaries of some of the talks I attended. This year I took notes on my phone (my lovely lovely N900) for all talks but one. I also took more pictures, which is great (although the quality of the pictures isn't always). Looks like getting the phone out to snap a pic is less of an effort than having an actual camera to carry around, get out of the case etc.

This was my 3rd FOSDEM and this time I spent a bit more time on the social aspect, sometimes even skipping talks (gasp!) I cared a little bit less about to chat with interesting people. This is great, though it made the conference quite a bit more exhausting. Must balance better -- and find a nice hotel in a quieter neighbourhood.

Once again delighted with the experience. Until next year, FOSDEM! :)

As FOSDEM (woohoo \o/) draws closer and the likelihood of spending a lot of time in the airport doesn't change, I thought it was time to find out how to use my N900 as a modem or for "tethering" as I'm told the proper word is.

Some background:

• my laptop runs Debian Squeeze (unstable) -- the stable release is coming out this week-end by the way!
• my phone carrier is Meteor (Ireland) and I use their 3G/GPRS connection for data.

Tethering via the USB cable

The official Maemo webpage makes it all sound real simple but it didn't quite work this way for me. The wizard did not appear either on Debian or when I tried on Ubuntu 10.10. Although the phone did show up in Network Manager -> Wired networks, it only displayed as Disconnected and I couldn't find any option to set up a new 3G network.

After many failed attempts, this is the approach that worked for me. It requires wvdial. One annoyance: it works once, then I need to unplug and re-plug the phone.

Here's the wvdial information for Meteor Ireland:

APN: data.mymeteor.ie
Username: my
Password: meteor

Tethering via Bluetooth

Emboldened by my success I decided to follow the link to the Debian wiki on how to set up the same using Bluetooth. I was very disappointed to see they recommend using a KDE app even under Gnome, and when I looked at the number of dependencies it would bring I thought I'd take my chance the Gnome way.

...I'll skip on the embarrassing moments where I was thinking Gnome 3 wasn't set up yet to handle Bluetooth then found out the Bluetooth service was actually turned off... *cough* I used the Bluetooth applet to pair with the phone and followed the rest of the instructions on the wiki page, until the rfcomm command brought up the following error.

Can't connect RFCOMM socket: Connection refused

Using "sdptool browse <N900_MAC_ADDRESS>" revealed that I did not have the "Dial up networking service" running on the phone. You actually need to install an extra app, available in the repos first (application name is: Bluetooth Dial-Up Networking). I then followed these instructions on the Maemo wiki to set up rfcomm.conf, until "Restart the bluetooth stack" in the first section, and ta-dah! With "wvdial bluetooth" I can now start the connection via Bluetooth.

To be honest I'm sure this is a battery drain nightmare and I can't imagine tethering without the cable but heh! I learnt about several new tools and if I ever need it, it's there :-)

Final wvdial.conf, in all its mighty glory

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Baud = 460800
New PPPD = yes
ISDN = 0
New PPPD = yes
Phone = *99***1#
Username = "my"
Password = "meteor"
Init6= AT+CGDCONT=1,"IP","data.mymeteor.ie"

[Dialer usb]
Modem Type = USB Modem
Modem = /dev/ttyACM0

[Dialer bluetooth]
Modem = /dev/rfcomm0

   
 o/
/|
/ \

I will be attending FOSDEM again this year (weather and airline strikes permitting -- fingers crossed!). I'm also hoping to drop by the Gnome meetup on Saturday night and say hi to a few familiar faces.

Very much looking forward to it!

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 :-)

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.