Will's blog

PyBlosxom 1.5 rc1 was released a month or so ago. Since then I haven't had much time to finish things up.

Spaetz kindly did the work to move PyBlosxom source code from svn on SourceForge to git on Gitorious. The plan is to move development to Gitorious and the web-site, documentation, bug-tracking, and things like that to a site on my server bluesock.org.

This enables people to fork PyBlosxom trivially and make the changes they need to make to get PyBlosxom working for them. This will result in more experimentation and work being done and reduce the problem of me and my decision making being a bottle neck in future PyBlosxom development.

The other big change that's happening partially in the PyBlosxom 1.5 timeframe and partially in future versions is the ecology for plugins. Previously, I ignored them and spent my time on PyBlosxom core stuff. Ryan was maintaining the plugins, but the infrastructure we had for plugin maintenance sucked. Going forward, plugins will fall into two categories:

• Maintained plugins will be in the plugins/ directory of the pyblosxom tarball. These plugins will have unit tests and will be versioned alongside PyBlosxom.
• Plugins maintained by other people will be indexed on the website in a registry, but one that will suck less than the current plugin registry.

The plugins that are currently in the contributed plugins pack will be split into those two groups.

PyBlosxom 1.5 is waiting on some more documentation changes, some more plugins work, and now some project infrastructure changes. I'll probably do another release candidate soon and suggest people start using that.

If you're interested in helping out, come hang out on IRC on freenode.net in the #pyblosxom channel. The conversations have been interesting over the last couple of months and have been instrumental in work getting done.

PyBlosxom uses Sphinx for documentation now. I was having problems with using -- for em-dash and it not showing up like an em-dash in the HTML output.

The docutils FAQ says to use the actual unicode character for emdash. I don't really want to do that because I'm not sure about what happens when the source files are opened up by a non-unicode-friendly text editor.

Turns out that doesn't matter because Sphinx allows -- for en-dash and --- for em-dash. Is this something that should get added to the Sphinx documentation?

Today I read You can't crowdsource software. The title sums up what it's about.

I've had this experience with Miro. We occassionally get patches from non-PCF people but most of the work is done by PCF developers. We've spent a lot of time and effort over the last few years on getting more code contributors and reducing the barriers to entry. We haven't had much success.

However, there's a lot of other "stuff" that goes into developing an application and the article only focuses on code. Some of this "stuff" can be successfully crowdsourced without a lot of effort. For example, Miro crowdsources all of our strings translation work through Launchpad.

I work on another project called PyBlosxom. We have a core group of developers (right now this is me) who do the bulk of the core code work. I do some plugin work, but the bulk of the plugin work is done by users of PyBlosxom many of whom have never touched the core code. For PyBlosxom, plugin development is crowdsourced.

The article suggests that it's a waste of time to help bring new contributors come up to speed and contribute because they often don't contribute much. That conclusion really concerns me. How can we get more people helping out if we're not working on getting people to help out?

Jono Bacon wrote an article titled Project Awesome Opportunity which talks about a few projects that are reducing the barriers to contributing and making it a lot easier. It's very Launchpad-centric, though.

OpenHatch is a startup working on building the next generation of contributors and connecting contributors to projects that need help. They're wrestling with how to effectively fix these problems, but without tying the fix to a project development silo (e.g. Launchpad, GitHub, ...). I think that's really important.

I think systems like these will reduce the effort in getting contributors and make it easier to crowdsource code contribution.

And if you, dear reader, are looking for a project to help out on that's written in Python and need someone to mentor you, let me know.

February 5th, 2010: I should clarify I think the article is fine. I don't think the conclusion that code contribution doesn't crowdsource well is poorly formed or anything like that. Just that the implications suck.

Spent a while figuring out how to get Miro to handle media keys in Gnome. My current understanding (and this could be entirely wrong) is that as of 2.18, Gnome handles the multimedia keys. In order for your application to respond to multimedia keys, you have to connect to the signal through dbus.

My biggest problem is that my web searching revealed a lot of bugs, but no documentation. I did finally find Handling multimedia keys in GNOME 2.18 and then worked out the rest. I still have no clue where to find the documentation for it.

Here's what I got working:

import logging
import dbus

from miro import app

class MediaKeyHandler(object):
    def __init__(self):
        self.bus = dbus.Bus(dbus.Bus.TYPE_SESSION)
        self.bus_object = self.bus.get_object(
            'org.gnome.SettingsDaemon', '/org/gnome/SettingsDaemon/MediaKeys')

        self.bus_object.GrabMediaPlayerKeys(
            "Miro", 0, dbus_interface='org.gnome.SettingsDaemon.MediaKeys')

        self.bus_object.connect_to_signal(
            'MediaPlayerKeyPressed', self.handle_mediakey)

    def handle_mediakey(self, *mmkeys):
        for key in mmkeys:
            if key == "Play":
                app.widgetapp.on_play_clicked()
            elif key == "Stop":
                app.widgetapp.on_stop_clicked()
            elif key == "Next":
                app.widgetapp.on_forward_clicked()
            elif key == "Previous":
                app.widgetapp.on_previous_clicked()

def get_media_key_handler():
    try:
        return MediaKeyHandler()
    except dbus.DBusException:
        logging.exception("cannot load MediaKeyHandler")

If you see problems with this, let me know so I can ammend the code.

I use a four space indent which causes problems when indenting if statements that span multiple lines. For example:

if (a
    and b
    and c):
    if_block_here

The problem is caused because if is two characters and therefor if ( is four characters--which matches the four space indent. I end up with code where I can't easily distinguish if statement from the if block.

After talking about it with Paul and Chris and working out what the specifics of the problem are, I decided to use double parens. The above with double-parens looks like this:

if ((a
     and b
     and c)):
    if_block_here

That satisfies PEP-8, doesn't change the semantics, and fixes my problem. It is a little goofy to use double parens, but it's a good enough fix until I get around to fiddling with the code that does automatic indentation in python-mode.

I'd be interested in other ideas that don't involve using \ at the end of lines if they're out there.

I was reviewing something and learned that Python saves the original sys.stdin, sys.stdout, and sys.stderr as sys.__stdin__, sys.__stdout__, and sys.__stderr__ respectively. That's pretty handy to know. Works in at least Python 2.5 and up--I didn't test earlier versions.

I adopted a line of Miro code today. Her name is Zowwee Kahn-Greene. She's pretty cute. :)

If you want to adopt-a-line, you can do so at the Miro Adoption Center.

When I upgraded from Intrepid to Jaunty, I noticed that git svn things were painfully slow. I had looked into this before, but couldn't remember how I found the answer or what it was. After skimming through thousands of lines of IRC logs, I re-rediscovered what I discovered the first time.

  rm -rf .git/svn
  git svn rebase --all

I found it at this site (oebfare.com).

I finished up some additional work and I'm at a testing stage for PyBlosxom. I want to do some more testing and some documentation then it'll be ready for testing releases.

Also, I spent a couple of minutes upgrading my blog to use 1.5 in trunk. Bumped into bunch of weird issues with the comments plugin, but otherwise it was really smooth.

Participatory Culture Foundation is the non-profit organization I work for working to build a distribution system for video and audio on the Internet that has no bottlenecks, no filter points, uses open standards, and Free Software.

Most of the software that we write is written in Python. Miro, an Internet video player, is written in Python and runs on a variety of platforms. Miro Guide and Miro LocalTV are both systems that are written in Python using Django. Miro Fullscreen is written in Python using Clutter.

Python has made it possible for a very very small group of us to tackle such a large project with very limited resources.

Earlier this week, we launched our Adopt a Line of Code, a fundraising campaign to help us fund the work we're doing. No one has ever done a fundraising campaign like this before. We think it could be a good model for other Open Source and Free Software projects to raise funds.

Take a moment to check out the Adoption Center and adopt your very own line of code! Support us in our work to make video open for everyone.