Hm... Starting to get the feeling this is the catch-all exception for Django, considering the wide range of scenarios in which people slam themselves against this error. (Although it's more frequent when using psycopg2, I hear.)

InternalError: current transaction is aborted, commands ignored until end of transaction block

This time, I was trying to restore a postgresql backup and that's all Django would give me locally. Turns out the users don't match between the servers, so no permissions were granted to anyone on the newly created database (\c <database>, \dp). GRANT ALL on every table, and my restore worked handsomely. (Edit: This command helps. A lot.)

(For another take on this error, see this previous post.)

FOSDEM is over, and all I can say right now is that I bought way too many tee-shirts (awesome :D and still not enough!). Got most of them in girl size which is great, albeit some of the sizings were a bit messed up (I had to buy a FSF shirt in size L. Granted I did buy it on the last day, perhaps the waffles are to blame ;)). I'll post my notes on some of the sessions in the coming days, really disappointed to have missed the ending keynote by GKH on writing your first kernel patch but I was concerned about missing my plane -- turns out I shouldn't have worried. Will be watching out for the video recording of that one!

I barely took any pictures at FOSDEM this year, so I'm going to steal (with credit!) pictures from various Flickr streams.

Saturday morning began with the customary welcome keynote, with a little twist for the FOSDEM dance (heh!). Wireless was up and running well before 12.00, which was a nice surprise.

(Picture credit: itkovian, Creative Commons "Attribution-Non-Commercial-Share Alike 2.0 Generic", taken from Flickr)

Promoting open-source methods in large companies

The first keynote was on promoting open-source methods in large companies. Not using slides made it quite hard to follow, that made me realise how slide stacks help with understanding the structure of a talk, what was said when there is noise around, or just remember/understand where we're at after being distracted and having zoned out for a couple of minutes... (and let's be honest that's always going to happen!)

Brooks Davis described his journey getting open-source adopted internally. It was more in the sense of having people open-source their projects within the company than anything larger, although quite a lot of open-source projects were used to achieve that (Apache, PostgreSQL, trac...) He started from quite far since he had to sell people on the concept of version control itself to begin with! (I empathise with that, it's very hard to make devs who are not familiar with it  use version control tools to their full potential. For instance I keep having to remind my team that it's ok to delete a now-unused file or big chunk of code because we can find it again if we need to. Dead files and dead code just make maintenance more painful.) The policy they set out for their internal open-source repository was that ALL projects had to be ENTIRELY open-source (can't keep any section secret.)

The barriers to adoption were mostly driven by fear:

• Fear of misuse: People need to trust their colleagues! (This is actually an interesting point. The speaker works with space-related software so I'm guessing there's quite a lot of IP and other trade secrets in their software. I wonder how they ensure and/or convince management that no employee would sell them out to the competition. I understand how the policy is tremendously useful to avoid duplication, foster collaboration between internal projects and just make sure part of the project doesn't disappear or get lost with a single developer. It's possible the speaker talked about this and I missed it though, the keynote should have been recorded... I guess this point includes "trust your employees" as well.)
• Misplaced sense of ownership, with people believing "this is MY code" when actually, this is the COMPANY code!
• Credit: Although the open-source community is quite good at it, within a company people tend not to be so good at giving credit where it's due (although they are learning, according to the speaker!)
• Another concern was that "people will like it and then they will modify it and make it better," quite a confusing complaint

The positive points of this approach and policy are that:

• anyone can access the code in the public repository, rather than have it exist on only the one guy's laptop, that has to be hunted down when someone wants to reuse the code or needs it for another project
• there is a snowball effect once people start using the system

Along the way a few lessons were learnt and changes were made accordingly:

• The "everything must be open and available" policy was relaxed a bit to accommodate for NDA, work by contractors, etc. A project must submit an application to justify such security requirements, to be reviewed and approved (many teams believe their project require such mechanism when really, it doesn't)
• Moved from mod_python to wsgi (easier to manage)
• Performance: They bought more RAM to handle the multiple Python instances (1/project), and thanks to WSGI have the project sleep when not accessed (they still have issues with the internal search crawler though, as it means every project page gets accessed within a few seconds!)

The barriers to adoption by development teams are:

• Team isolation, each team kinda works in its own island
• People don't know it exists
• People think it's a heavy-weight project involving lots of paperwork (e.g. fill 6 forms to make a change)

There was a bit of talk on distributed version control. He finds it interesting but as his people are just getting used to the concept of centralised version control it might be a bit early. There is also the issue of backing up the projects, because the distributed nature of those tools could mean that people revert to only having a copy on their own machine. He's interested to see how people in open-source deal with this, and hopefully learn from it.

They are working on a few improvements to trac that they aim to contribute back (e.g. seeing tickets for multiple projects on the one screen.)

In the end I was a bit disappointed by the talk, because it focused so much on implementation (which is cool, I love hearing about this kind of stuff but I already had this with Ship It!. I know I want it.) when I was hoping for more strategies on how to help management and developers see the benefits of open-source. I'm interested in understanding how to get it adopted internally, how to bring change. Someone in the audience actually asked kind of a similar question, asking how he got management to pressure one particular internal project to use the new tools (mentioned during the talk.) I think the answer was along the lines of if the company spends a couple of millions a year on a project or another, they're interested in seeing it reused and easily available internally. Which doesn't really help us, but I guess if he has support from management to begin with it's just difficult to answer.

Evil on the Internet

The second morning keynote was about Evil on the Internet. The poor speaker, Richard Clayton, was severely booed at the beginning when the Windows screen showed up as people struggled to get Windows to play nice with the projector, but once he started with his talk it was most excellent because presented in such a funny way. Apparently the only thing bad guys have to do all day is design very nice and sleek looking websites, while trying to screw people over every possible way. To me the highlight of the talk was the job ad for Millenium Inc., a phishing company (though it doesn't present itself as such, for obvious reasons.) Their vacancies page advertises for a lot of positions, most them "not currently available" ...except for one. They are looking for a "payment processing assistant." Your job would consist of receiving payments from their clients onto your bank account, that you then take out and send on to Millenium through Western Union. Very nice. When the bank realises the money was moved onto your account through fraud it will take it away, and you'll be left with no recourse because Western Union will never ever refund any money you send using their services. There were many other examples, and there's more on his blog.

There were quite a few talks about Gnome, I'm going to highlight here 3 of them.

Gnome Bugsquad

The first talk was about bug triaging in Gnome. I can't believe there are only 5 active bug triagers in the project (as in, people fully focused on cleaning up the bug database). Tobias Mueller, the happy and dynamic speaker, made a good job explaining why this is such an important task, as the bug tracker is basically a window to the world. This is what people will be confronted with when they try to interact with the project, and having unanswered bugs lingering around doesn't give a very good impression.

In itself, bug triaging is a great entry point into the project because it doesn't require in-depth knowledge and it brings you closer to the community as you get to know the developers by name, so it's a good way to get involved, learn more about Gnome and help out.

The way triaging work:

• There are bugs. People find them and complain about them in the bug tracker.
• We need to understand and get all the necessary information for the developer to be able to fix it.
• So the status of the bug needs to be kept accurate (more on that later)
• And bug triagers can identify severe issues, such as bugs that come back often or many times so we can inform the adequate people.

I love that quote: "Bug triaging is about making people happy." We want our users to be happy, Gnome is about the people in the end!

Some other happy mottos:

"Be nice, be friendly, be happy."

"Answer early, answer often."

There are several ways to get in touch, through IRC, the mailing list, they're trying to hold bug days but currently lack the manpower to do so. They have a triage guide that is apparently so awesome even the KDE guys use it! :D Here's a link, I have to carve out time to read it.

After showing us some tools to find duplicate bugs and what sort of information to ask for, Toby walked us through the different statuses and how to use them, like what to do if you can't get information from the bug reporter after 6 weeks (the assumption is that this is not a problem anymore so resolve the bug), or if you're triaging a bug from more than 2 releases ago (resolve it as obsolete). Some statuses are reserved for the module maintainers. It's all summarised in a shiny diagram available on the wiki. When you start out you actually can't modify the status yourself, so you should add a comment explaining why you think the status should be updated and someone with the Power on #bugs will change it for you. Quickly enough, once you've shown you understand how this works, you can ask for the ability to change statuses yourself.

The final statement was that they need people and it's a good way to start if you want to get involved, it's not too hard for beginners and it doesn't cost too much time or requires that much knowledge. And you get to know the people and projects.

To get started:

1. Create a Bugzilla account,
2. Read the wiki,
3. Ask questions on IRC,
4. Get started. You can't do anything yet, so write it in the comments,
5. If it all makes sense ask for access to do it yourself.

At the end, he asked who he convinced, I think he should have asked who would consider contributing to bug triaging, that's less commitment while still showing interest :) I joined the ML while he was speaking but I didn't raise my hand when he asked, because my way of doing things is to lurk for a while and then see if/how I can fit something in my schedule, rather than making promises I will break. We'll see how that one goes! I'd love to get more involved with Gnome.

Adding plugins to your Gnome apps

Steve Frécinaux talked to us about libpeas, a framework being developed to make plugin development within Gnome applications easier and more consistent across applications.

Building a plug-in API is very, very hard, and having dissimilar APIs makes it harder -- that is, if you write a plugin for Nautilus, you will have to relearn from scratch to build a plugin for gedit. There's a heavily duplicated code base as well, as most projects seem to have taken the gedit plugin framework as a basis, but it's all slightly different because of bug fixes and fitting their own special needs that are not transmitted upstream.

Libpeas aims to fix all this. Plugins are good because they enable the main codebase to remain simple and clean while allowing for lots of additional functionality.

The goals are:

• Ease of use: the framework should be minimalist with little boilerplate code
• Extensible: different applications have different needs, not every project is like gedit
• Lightweigth: it should only load what you use, e.g. not load python if it's not needed by any plugin

Plugins can be written in C, Python, or Javascript.

A plugin is what you install, which can consist of one or more extension. An extension is the implementation of an extension point (hooks). So plugins can register extensions with several extensions points within the application.

The speaker walked us through the different principles of plugins vs extensions, and finally showed us the steps to follow to make your applicable extensible and create hooks.

I can't find a page for the project on the Gnome wiki though, which is not cool :/

Gnome Development Tools: High-Level Debugging and the Misha Research IDE

To be honest I'm not sure this was particularly Gnome-specific, although it WAS written using Gtk tools :) Nick Papoylias introduced us to a new genre of IDE, based on the premise that debugging hasn't really evolved in the past 20 years when really, there are many ways it could be used besides stepping line-by-line through a program after encountering a problem. Debuggers can be integrated to different phases of the development life cycle, and there are many ideas that academia has put forward that are slow to be adopted, if at all (reverse debugging just made it into the latest gdb for instance).

He admitted that they didn't respect every Gnome UI guideline but as they were experimenting with a new approach to IDE and programming workflow, it made sense to experiment with a different UI as well to save space. The interface felt really busy but I'm not particularly worried about that, that's how IDE tend to be by nature.

They are adding new things to rethink the debugging workflow, that work together with the symbol debugger (gdb).

• Syntax parser: Navigate code in terms of structures, loop iteration, functions -- not only line by line
• Data visualisation
• General purpose extension language: Python
• Reverse debugging

It supports stepping through the syntactic structure while having a up-to-date data visualisation. This is a very nice way to see what is happening as we run through the code, he showed an example of variable insertion in a Binary Search Tree and it was amazing to see the tree be updated for every iteration of the loop. That'd be a much faster way to catch silly little bugs that tend to creep up as you develop (so you can catch them even before writing lengthy unit tests).

The presentation ended by showing us what the extension language could do and wow. Was that impressive. You can use Python functions to call your C code, for both simple and elaborate calls. The Python code directly calls C functions with no intervention from the developer. And through the debugging console we can visualise what's going on (e.g. the tree that is created through Python).

Additionally, if you create a main.py in your project, you can attach callbacks buttons to the IDE. This is really cool. He had it call a plotting application to display random results in a graph and check the distribution or whatever. It was really impressive.

So Python can be used to make inter-language calls, import external libraries, add functionality to the IDE, and call C programs directly. Check out the project website.

On Wednesday, I will be teaching a small group of teenagers how to program, using Python. I'm both extremely enthusiastic about this, and scared out of my mind. As the day actually approaches, my mood tends to oscillate toward the latter more often :)

I have prepared some material... I think enough for the first session. But really, I don't know. I think the pace of the first lessons is ok, but then I wonder if it's too boring. I have prepared some cool examples that progressively grow out of the concepts we learn, but then I wonder if it's too much at once, or if I'm stretching the examples too much. Will this be entertaining enough to hold the attention of 7 teenagers for a couple of hours?

I know this will be an excellent learning experience for me. I'm very familiar with the material so I'm not concerned about this, although it will be a curse at first while I try to remember what it's like to learn all those concepts for the first time. I'm more concerned about being able to find different, good metaphors to explain the same concept in different ways. That's where I fell short last time I tried to teach someone. I wonder if there's a course somewhere that teaches how to think like that :) I am very motivated to learn, and while I do so, I will try my best to at least not turn  these people off programming forever...!! (No pressure.) I suspect there are some things about teaching, that you can only learn while doing it. Don't take my word for it just yet, though ;)

Any tip, advice, suggestion or word of encouragement very much appreciated! I will post the material I'm using after Wednesday, once I get a better idea of what actually fits in one session.

Armed with my laptop and some notes, which I had spent the previous evening annotating then annotating the annotations, I stepped into the room where I was to teach my 7 (actually 6) students the basics of programming and Python.

The short version is, I think it went well. There is obviously so, so much room for improvement and I'm very motivated to work on the stuff that went less well. But all things considered, I did my best and nothing went horribly wrong. Thanks to those that took the time to post comments with advice or to send me encouraging emails! I really appreciate it.

I enjoyed the most helping and having conversations with students one-on-one while they were working through the exercises, compared to the bit at the beginning where I explained what Linux and open-source was about, and what we were going to do (I was using a conversational style but still, no one would answer my questions). Once I was making rounds checking individually if everyone was doing ok, people weren't afraid to ask me questions and I like that, although it could just be that I was working with some really cool kids :)

A few of the points to improve on I took from that day:

I completely underestimated how long it would take us to get through the simple concepts. I thought I would run out of material well before the end of my 3 hours time slot but we didn't go through half of it. And thinking back on it, I probably should have spend more time on the very first concepts, and insist on the "details" like say indentation. Thankfully I get another chance to get it right when we meet again in 3 weeks :)

Something I absolutely need to fix for next time is the quantity of exercises. I need many, many more, and particularly for the simple stuff which I hadn't prepared at all. Examples are good and necessary to get started, but exercises are best. They're great for me as well to see what's causing problems or confusing students, because that stuff is so familiar to me, it's hard to realise what goes through the head of someone to whom the concept is shiny new.

Another thing I found difficult and need to improve on is managing students needing more time and personal attention, because after a while I feel like I'm letting the others down. Having more exercises would also help alleviate this, I think, because at least other students would be able to keep busy and get more comfortable with the material, rather than wait for me to give them more things to do (my failure again here, obviously).

Overall most students seemed to be having fun, and some were curious enough to ask me what we were going to do next time. I hope they do show up for the next session and give me a chance to explain again the concepts I wasn't clear enough on this time.

My main TODO for the next session: have about 20.000 exercises that use print / variable / user input / if statements (or 20 at least, to begin with ;)). Any idea, input or pointers to resources, as simple as they might seem, are very welcome! I think I will prepare some silly on-screen questions as well, particularly to drill in how variables work.

This blog post by a teacher who's migrating his school IT system to an open-source infrastructure just came up on the Ubuntu-ie mailing list. It's happening in Northern Ireland but still goes on the list of "Irish schools using open-source" :)

That's really cool. The comments promise a follow-up post, I hope it will include advice on how the author got not only the students but also the school staff to be excited about the migration. That seems to be a major pain point within the case studies I've come across.

I heartily recommend this book to anyone who wants to take control of their career, cares about their career, or is unhappy about where they currently are. Change and remarkable careers, like anything else, don't just happen to you, you have to work hard (and have fun!) to make them happen.This book gives you ways to achieve that, while having fun and staying true to yourself.

I really enjoyed reading it, it helped me structure and articulate my thoughts better around some ideas I hold on career development. I found it to be very encouraging, in nudging or kicking the reader's ass to be more active in building one's career consciously (honing a sense of business, mentoring, automating, personal brand...) and watching out for the traps along the way (over-specialisation, obsolescence, office politics and perception...). The format is really good as well: a multitude of very short chapters, usually 2 to 4 pages long thus perfect for a quick, self-contained read whenever you have a few minutes, with plenty of time afterward to mull over the ideas brought up.

Every chapter ends with an "Act on it" section which gives you tips, food for thought and calls to action related to the chapter contents. I always have a problem with (good) books that contain this kind of list, because if I wait to actually have/make the time to do what they ask me to do, I never finish reading them. I usually deal with this by reading the book from start to finish once, then (hopefully) giving it another read slower, later on, taking the time to follow through the action items. This was my first read. I still got quite a lot out of it: a few book references, new cool ideas to explore and a sense of confidence and reinforcement when this confirmed or fleshed out some of my beliefs and the path I have set onto. 

The book is divided into 5 sections: Choosing your market, investing in your product (that's you, by the way ;)), executing, marketing and maintaining your edge. There are a few essays by other people inserted here and there that offer refreshing point of views, real-life examples or case studies.

The book can be bought from the publisher in addition to any good bookstore. I really enjoy the Pragmatic Bookshelf books and they sometime have cool promotional offers, so I tend to get the books from them directly and recommend it to people. :) There are a few chapter extracts as well.

I went to Limerick this week-end to attend the SkyNet/Ubuntu talks. It was good fun, I enjoy so much walking around UL campus and corridors, basking in old memories of when I was just settling in Ireland and was learning so much, all the time :)

The first talk was mostly about selling up Microsoft cloud services, which felt a bit surreal for a mostly open-source audience. I suspect the organisers didn't highlight enough that this particular afternoon of talks was slanted toward Ubuntu and open-source in general, so we definitely weren't the best audience. It's very strange to hear that the cost of computing is coming down at last, then being told that no, it's impractical for businesses to try to switch to free alternatives like OpenOffice, while at the same time mentioning that there won't be any more compatibility issues between .doc and .docx since Microsoft is dropping support for Office 2003 and businesses are forced to upgrade to Office 2007. How does this match the necessity for companies to look at ways to reduce costs, or not being willing to look at compatible alternatives (since they already managed compatibility issues for .doc/.docx issues)?

The second talk was about Google Summer of Code, by the very dynamic Jimmy O'Regan. He insisted a lot on the importance and impact that having a designated mentor has on a new contributor. I'm struggling myself to get involved with open-source communities at the moment (as opposed to projects in themselves), so that's something that's very interesting to think about, and see if perhaps it could be adapted in a scalable way to lower the barrier to involvement for new contributors outside of GSoC.

Right before the lunch break, the folks from Tog had a talk on setting up your own hackerspace. I'm not sure at all we've ironed out all the issues with our own space in Dublin, but it'd certainly be very cool for other cities around Ireland to set up their own so we can all learn from each other's experience, within the Irish culture. I didn't know about the Hackerspaces design patterns, I definitely have some reading to do on that. The main point to take away from the talk IMO: "Try and work on the fun stuff." :)

Matt Zimmerman, CEO of Canonical, gave an interesting talk on the conflicts between managing a community and managing a company, where transparency sometimes is just not possible for legal reasons, and the lessons Canonical learnt and is learning along the way. They're still figuring out the best practices. I like the "anything that could be public, should be" policy, as opposed to the "anything that hasn't been explicitly okayed cannot be talked about" from most other companies. Canonical folks work to earn their commit rights like the rest of the community, they're not granted automatically. Canonical is not doing too bad for transparency because it's grown organically from people working from home so when they need to talk, they do it on Freenode publicly. That's interesting to me because I'm sure I read somewhere (can't remember where though) that one of the problems with the OLPC project was actually having offices, because whether or not you mean to you end up talking about projects, issues and decisions and it looks to the community as if you're working behind closed doors without involving them. 

Laura Cza talked about the Ubuntu community, all the ways to get involved and also everything that is going on in Ireland relating to Ubuntu and open-source events. I really look forward to the Free/Open/Global Jam in March! I was a bit spoiled for the talk as I had already read through the slides from the first version of the presentation a couple of weeks back :)

Finally the day ended with a talk on CouchDB, by a presenter who should win some sort of prize for very realistic impressions of heads exploding in the audience not only once but twice. I'm going to have to give a try to CouchDB soon. I probably need to hear a couple more talks about it before I really start getting my mind around the concepts and the "why and when should I use it" (till then I'm doing quite fine with my PostgreSQL adventures!).