It's proven difficult to write up a summary of my experience as someone-who's-not-a-hardcore-open-source-contributor-yet-but-certainly-plans-on-becoming-one. There's an easy dialogue-killing answer to any anecdote I relate: "suck it up." I'm still trying to find a way to express all this though, because I'm sure there's something to learn from any newcomer's attempt to join a project, and also for my future self, when I'll be the one encouraging others to get involved with open-source and won't remember what it's like to stand on the edge, trying to understand how a community functions and how to find a space that fits you in there.

So. Two anecdotes on contributing to Sugar, then a description of the incredible level of confusion I've been experiencing looking at the development process overhaul, followed by some ponderings on "what's next" which I better follow up on in the future :)

Anecdote 1: Fixing a bug (InfoSlicer)

Sugar (and the XO!) had been on my radar for a while. Last summer I finally made the time to set up sugar-jhbuild on my laptop and start trying it out for myself. I was enthusiastic but despite the very good wiki I wasn't sure where I could make myself the most useful (Sugar core? Making a new activity? Fixing activity bugs?). I find fixing bugs to be a fantastic way to get familiar with a project and a code base, however I wasn't sure how to pick one because every ticket in bugs.sugarlabs.org is already assigned to someone. It wasn't obvious to me whether I was welcome to work on any or if there was some sort of "please may I work on this bug" process or if assigned people might be protective of their code (I've met a few virulent "It's my code/my bug!" people before, albeit mostly in college.) The sugar-love bugs were few.

Enters OSS BarCamp in September 2009, where I met Laura Cowen (thanks Jaime for pushing me to introduce myself!) who presented a lightning talk on a Sugar activity, InfoSlicer. Having met with a real person who was enthusiastic and sort of involved with Sugar, I thought I'd take a look at InfoSlicer. There was only one bug filed against it at the time, that quite seriously limited the capabilities of the activity. I set out to fix it. A few weeks later, I was attaching my patch to the ticket, discreetly sweating over the associated comment. Someone replied less than a day later, suggesting a different approach inspired after another activity I hadn't heard about and before I had come back from work that same day, the current maintainer had accepted my patch and also suggested another way to do it that we could work on together. I was double-elated and thanks to the "we" felt very welcome.

Unfortunately I hadn't enjoyed a lot working on the parsing code for InfoSlicer and despite promising myself I would update the activity with the new toolbar "soon" I didn't get back to it (yet, shall we say. I'd still like to do the toolbar thing sometime.)

Anecdote 2: Fixing bugs (Pippy)

'round the same time I had volunteered to show cool engineering things to a transition year (high school) student spending a few "work experience" days in my workplace. Although he was a bit older than the Sugar usual demographics, I gave him a usb stick with Sugar on it anyway: Sugar is cool and we all had unrealistic expectations of what a student could accomplish in a week. I thought perhaps he could get familiar with the project then investigate a bug. After he showed some curiosity about programming, I stirred him toward Pippy which he enjoyed greatly despite the occasional stracktraces some examples were invariably throwing up.

Most of these issues had already been reported so I thought, "I love Pippy, I'm gonna try to fix as many as I can." Along the way someone I know got a bit hyped up by my enthusiastic chanting of "Sugar Sugar Sugar" and had set out to fix a serious display bug in Pippy, #347, despite not being particularly fond of Python. I fixed a couple of other bugs, attached the patches to the relevant reports and hopped away, waiting for a review or update. Months went by. My friend lost interest. I began to pep myself up to ask about the Pippy maintainer on IRC. At the time I was trying to build up some confidence by getting my work accepted first before going about and expressing opinions or asking questions in public places (not the way people usually prefer things to be done in open-source, I realise.)

A series of coincidences happened and I suddenly was offered commit access to the Pippy repository (I mentioned that before.) Despite the best intentions, I wasn't comfortable pushing my patches to the mainline merely because I had the power to do so ; I find it preferable and better for patches to be looked at and approved by people who know what they're doing. Eventually I pushed #843 myself into the mainline, as Chris Ball kindly reviewed it as part of an email thread. I still didn't feel so good about it, managing the statuses in Trac was unclear (both status + resolution must be marked as fixed/resolved?) and the bug never ended up assigned to me (it looked like Trac's button would change both the status and assignee so I wasn't sure and then it was too late, I didn't want to revert the status back.) Basically, as I've stated before, I was still in dear need of a mentor, and I still didn't reach out. I fully understand and accept that this is my fault for not communicating well enough with the community.

Another bug I had worked on, I didn't fix correctly the first time around. When this was brought up I responded quickly, explaining where I thought the issue was and submitting a second patch a few days later. I won't be pushing this to mainline until someone else confirms it works, but I'm still happy with it because I proved (to myself, too) that in case of problems I am responsive and able to correct issues within a decent timeframe.

Meanwhile, I was also getting fidgety about #347 as without it, Pippy is impossible to use on my Eee and likely on other netbooks. Eventually I asked, still within the bug tracker, if people would mind if I pushed the current (working) patch to the mainline. Other unrelated requirements had come up in the bug report discussion, much less serious than does-not-work-at-all-unless-patch-is-applied so it felt fair to push the partial patch. Lots of people had popped up the first time around and subscribed to that bug, but there was no answer.

Not long after, someone submitted a duplicated patch to fix #347 as well as the other unaddressed aesthetic issues, using a new process still being defined. The patch got reviewed, no one mentioned the duplication (I didn't either) and soon after the patch was pushed to the mainline and the submitter became Pippy maintainer (yay! At least Pippy now has a more active maintainer, hopefully!)

It's great to see movement on the Pippy front but I felt so disheartened by the duplication of that patch that had been sitting there for 7 months and that I had to install manually on every stick I made for the past 7 months. I invested so much energy running in circles like a headless chicken, trying to do things right with my shiny commit access and waiting for feedback. I was very discouraged, the basic lesson being: I shouldn't have cared so much, especially when I knew I hadn't fully groked all the processes yet. This only (mostly?) happened because I did not reach out to the community through other channels than the bug tracker.

The new process

While I'm at it, I'd like to mention what's going through my mind with regard to development process changes that SugarLabs has been setting up lately. Sugar is basically moving toward a mailing-list only style of communication to submit patches and I've been endlessly confused since this started. I'm not sure it's the most inclusive process either though I understand the problems it's trying to solve -- mostly lack of code reviews as illustrated by anecdote #2 :)

I think it's more confusing than it used to be and makes the barrier to entry higher because as far as I can tell, now if I or anyone want to fix a bug:

• I go browse trac and find something interesting/that I care about to work on
• Now I also have to search through my inbox and patchwork (a new system I haven't totally figured out yet either, but it doesn't look any less confusing than my inbox with every patch/email thread thrown in there together) to see if the bug is already being worked on
• I need to join the mailing list to submit my patch (I'm assuming, but it's probably necessary if you want to be sure to get the answers) -- that's quite intimidating and a commitment for "just" a patch. The process should also be easy for passersby if you want people to stick around.

Reading the mailing list and the patches as they get submitted is also confusing because it's difficult to link a patch to a bug and understand the background/context. In most cases you'd have to go and dig it back up from the bug tracker.

I know people are working on it at the moment, so I will wait for the wiki to be updated with clear instructions on how to effectively use the new process and systems, as the wiki still only describes how to work with trac. For now I'm watching perplexedly and wondering if really, the mailing list will be the only way for people to contribute in the future? I worry that the new process is inspired from projects that focus on hardcore technical people (Linux kernel) rather than others that also welcome passionate beginners (Dreamwidth).

Other valid solutions were proposed to fix the patch review problem and I wish I had found the bug on re-creating a "patch need review" automatic weekly email so I could have tried to do my bit to help. Great Sugar contributors believe in the new process though, enough to invest their time setting it up and setting up the tools to make it work more conveniently. Now that I've finally written this post and digested what happened and where I messed up, I should be able to focus on how I can help the project with other contributions.

What now?

Step back, start from scratch with a clean state of mind. Probably stay away from code contributions for a bit. Talk with the community. Stop messing up brilliant opportunities when introduced to cool people by email ;) Be more pushy when it comes to asking for feedback.

Looking at the releases notes surrounding Fedora 13 and Mirabelle make me hopeful: the Sugar on a Stick (Mirabelle) wiki pages are awesome, vibrant with optimism and that sub-community within the community sounds like a great way into main Sugar. Quote from their wiki I love: "When you're stuck, and have spent more than 15 minutes trying to figure out what to do next [, email the mailing list / ask on IRC]." The weekly meetings where newcomers are welcome sound like a good idea as well, it gives some structure rather than let new people break into the main group on their own (or so I imagine, I wasn't able to attend the first meeting last Monday.)

XTerm control sequences are those sequences of characters that when typed into a terminal, can have all sort of cool side-effects. Try this one:

$ echo -e '\e[33;45mHello!'

If you're not too enthused about yellow and magenta (shame!) type in:

$ echo -e '\e[0m'

Many other neat things can be done with those control sequences, so I'm going to document here how to understand the documentation, so I don't have to figure it out from scratch again in the future. This could be summarised as, "read the introduction to the documentation before jumping in the middle" but I might not remember that either given enough time :o)

It all started with a Pippy bug I was trying to figure out, summarised for the interesting bits here:

# xterm magic! see http://rtfm.etla.org/xterm/ctlseq.html
import os, tty, termios
fd = os.open('/dev/tty', os.O_RDWR|os.O_APPEND)
tty.setraw(fd, termios.TCSANOW) # set to raw mode.
os.write(fd, '\x1B[18t') # write the 'query screen size' command
# (Removed: Code to parse response)

"\x1B[18t" is the bit that matters. I'm going to use the documentation linked in the code as a reference here, though there are other versions, some more recent, floating around the Internet.

Before skipping ahead and skimming around the document, there's a couple of crucially important pieces of information that must be read.

First one is:

Ps     A single (usually optional) numeric parameter, composed of one of more digits.
Pm     A multiple numeric parameter composed of any number of single numeric parameters, separated by ; character(s). Individual values for the parameters are listed with Ps.

Second bit is (even) weirder and hidden amidst other commands:

ESC [      CSI       0x9b       Control Sequence Introducer

The CSI abbreviation is used all over the paper and without that, well, it's much more difficult to understand.

Now looking again at \x1B[18t. \x1B means hexadecimal character 1B which in ASCII is "ESCAPE."

From what we just read we know that any command needs to be escaped by starting with ESC[ (represented by \e[ in our shell examples.) That's the "CSI" and it tells the terminal that what follows is to be interpreted as a control sequence.

Moving on, the stuff of interest to us here is under the header "Functions using CSI, ordered by the final character(s)". For the Pippy example, it's 't' and thus this one:

CSI Ps ; Ps ; Ps t      Window manipulation (from dtterm, as well as extensions). Valid values for the first (and any additional parameters) are: <snip values>

Looking at the long list of possible values, we find: "CSI 18 t" returns the size of the xterm window in pixels as: "CSI 4 ; height ; width t". End of mystery! Other "suffix t" commands can be played with to change the size of your terminal, $ echo -e '\e[;80;24t' to set things right again.

There's a shell script on that same site if you want to play around more, as well as the patch that was submitted to gnome-terminal to implement more control sequences in all its glorious hyerogliphic majesty (commented though :)).

I decided to try out Planet Venus over the week-end, a popular blog aggregation system. The end result is pretty neat, I really like how it works (though I must say it's the first blog aggregator I ever look into.)

The documentation very sensibly insists on running all the unit tests before doing anything, which is where I encountered a couple of issues. One was a malformed HTML docs page which I ignored, the other one looked a bit more serious, a parsing error.

======================================================================
ERROR: test_content_tag_soup (tests.test_reconstitute.ReconstituteTest)
----------------------------------------------------------------------
<...snip traceback...>
HTMLParseError: malformed start tag, at line 1, column 14

What didn't make a difference

• Running the tests using python 2.4, 2.5, 2.6
• Reinstalling python-libxml2 (already installed, reinstall inspired by Venus devel mailing list archives)
• Reinstalling python-beautifulsoup
• Installing python-libxslt1, python-xml, python-lxml

Trying to debug the exception a bit more closely, this looked like the usual BeautifulSoup issues that started occurring after the move to HTMLParser for Python 3.0 compatibility.

What worked, eventually

Warning: it's a hack :/ Some solutions suggest removing the python-beautifulsoup package, unfortunately I am unable to try this out as many things on my desktop depend on it.

This workaround posted on the mailing list for a similar problem did work for me though. It involves looking for "import BeautifulSoup" in planet/vendor/feedparser.py and removing the statement.

try:
    raise Exception # import BeautifulSoup
except:
    BeautifulSoup = None

I surface again, back from the land of studying and cramming. I decided to study for the SCJP (Sun Certified Java Programmer) exam, since that's what I spend my time doing at $dayjob (I might as well do it as best as I can!) Yesterday I passed the exam, yay!

I kinda like exams and certifications and courses in general (though if you'd asked me on Sunday I likely would have had something different to say!) They give a focus to my learning or simply give me the opportunity to look into a topic -- I'm interested in many many things and although I plan to learn about them all at some point, I can't learn everything at once. I was delighted when a JQuery course was organised in Tog earlier this year, it was the perfect opportunity to get a taste for it.

My usual process for learning a programming language usually starts like this:

• Do something. I first used Perl when I had a huge QIF export where I needed to change the dates from DD/MM/YY to MM/DD/YY. Or maybe it was the other way around.
• Or follow a tutorial to learn about it. Django looked so cool I had to try out their awesome, awesome tutorial.
• Sometimes I'll pick up a book on the topic if I see a good recommendation, like Learning Perl.

Very quickly though, I'll usually get interested in a problem or app and I'll drop the tutorials and books, simply using them as reference materials. It's the best way to learn, my practical knowledge expands but at the same time I'm likely to miss on things because I don't know they exist, or I don't realise I only have a partial understanding of a particular topic. In the end I only learn and see what I need for whatever task at hand, my knowledge can be fuzzy in places. I build a good feel for what's right and wrong but I don't necessarily understand precisely why. There could be a world of useful features I'm missing, especially if the new language has its own very specific quirks and shortcuts that don't always map one-to-one to other languages -- Perl comes to mind!

So that's why I enjoy studying for a certification or course, it gives me a different focus. Sometimes I even learn things that could end up being useful! ( ;) ) Some I'm sure will help me debug tough issues in the future, others I'll want to try out in my next project. I enjoy my new understanding of why some things work and why others don't.

Right now though, what I'm really looking forward to is having the time again to read other, non-Java related books!

If you're studying for the SCJP exam, this is the book.

The structure of the book is beautiful, although the chapters vary wildly in length. Every paragraph has bold, visible headings for easy navigation, there are side-bars of all sorts everywhere, the most useful being the "exam watch" which highlight some tricky parts of the exam. At the end of every chapter, there is a tremendously useful self-test section, broad enough to encompass most of the important concepts and exam tricks for that particular chapter.

The self-tests are fantastic to strengthen your knowledge, make the concepts and ideas stick and, very importantly, learn to watch out for the exam tricks and traps: missing semi-colons, missing exception handling (I find that one so nasty. From the mock exams, it seems most common in complex threading questions), instance variable read from static main(), discrete ++ increment of a final variable deep inside a loop...

Additionally, the book caters as much as possible to different styles of learning (and reading!), by repeating and summarising the same information in diagrams, exercises, tables, and full recaps with bullet points at the end of every chapter. It all gets very handy as the exam gets closer and you don't have time to dive in deeply anymore.

I liked the sparse "on the job" sidebars to highlight some of the differences between real life and the exam. The humour in the book doesn't distract and can make the reading flow more pleasantly, though if you're not interested in a topic nothing will help (file I/O in Java kills me... Perl, Perl, Perl!)

Form-wise, the book is big and thus cumbersome, but surprisingly light so not too painful to carry around. PDFs of every chapter are provided on the accompanying CD, though I wasn't impressed when trying them on a friend's Sony e-reader.

Note for Linux users: the quiz/mock exam software on the CD runs fine under Wine (the only one out of 3 SCJP training software products I tried! None of them written in Java, funnily enough.)