Will's blog

Tim threw together a vagrant setup for Kitsune based on what Alex did in November. I went to give it a try but I'm using vagrant 0.8.10 and it died.

Important part of the error message was:

/var/lib/gems/1.8/gems/net-ssh-2.1.4/lib/net/ssh/key_factory.rb:38:in
`read': Permission denied - /var/lib/gems/1.8/gems/vagrant-0.8.10/keys/vagrant
(Errno::EACCES)

Issue is documented at https://github.com/mitchellh/vagrant/issues/235.

My fix was to do this:

saturn /var/lib/gems/1.8/gems/vagrant-0.8.10/keys> ls -al
total 24
drwxr-xr-x  2 root root 4096 Jan 11 20:00 .
drwxr-xr-x 10 root root 4096 Jan 11 20:00 ..
-rw-r--r--  1 root root  821 Jan 11 20:00 README.md
-rw-------  1 root root 1675 Jan 11 20:00 vagrant
-rw-r--r--  1 root root 1464 Jan 11 20:00 vagrant.ppk
-rw-r--r--  1 root root  409 Jan 11 20:00 vagrant.pub
saturn /var/lib/gems/1.8/gems/vagrant-0.8.10/keys> sudo chmod 644 vagrant
saturn /var/lib/gems/1.8/gems/vagrant-0.8.10/keys>

That fixed it for me. Figured I'd document it so that I could find it again when I bumped into it again.

While I was writing up the release blog post, I figured out that I've probably been working on Pyblosxom 1.5 on and off for the last three years or so. That's pretty intense---I knew I'd been working on it for a while, but I didn't realize how long it actually was.

The last year or so of development has been fun. There's a pretty consistent contingent of friendly folks who hang out on #pyblosxom. I really appreciate their humoring me with my period, "Pyblosxom 1.5 is almost done! I just have to ..." announcements.

Details of the release are in the release blog post. If you've been waiting to upgrade, this is a good version to upgrade to.

Going forward, I'm going to take a hiatus from Pyblosxom development. I've got a bunch of other projects that I've been ignoring for a while that really need some attention. I'll continue to review patches, help out on #pyblosxom and the mailing lists, and I'll push out future releases, but I won't be doing any major development for a while.

Mediagoblin has monthly project meetings. One of the things I wanted to automate was meeting reminders that gets sent x days in advance, contain the link to the Meetings page in the wiki, and specify the date and time of the next meeting. I figure if we automate it, it's one less thing we have to think about---it just happens.

To do this, I decided to write phil. For the most part, it's sort of a throw-away project, but it was so small that I decided to go through a complete project development cycle with it and make sure it had all the bits a mature Python project should have: proper packaging, license, configuration, tests, project infrastructure, ...

I think it took about 10 hours over the course of 2 weeks. I was learning the icalendar library and python-dateutil and also figuring out exactly what I wanted it to do as I went along. For a small project like this, that's fine. For a larger project, I'd prefer to spend more time researching and designing ahead of time.

It was nice to "take a vacation" and put all the other projects I normally work on on hold to throw something together from scratch.

• Github page: https://github.com/willkg/phil
• PyPI page: http://pypi.python.org/pypi/phil

Carl put up a Pledgie campaign for raising $4,600 to cover the costs for videoing PyGotham 2011.

For $4,600, we're getting a lot of bang for our buck. Amongst other things:

• video that will last long after the conference done by a seasoned video crew that does video for PyCon, DjangoCon, and other conferences
• transcriptions of select talks

PyGotham 2011 is only a couple of weeks away. They have a pretty great speaker line-up. My manager is going to talk about Moving Fast with Django covering deployment pipelines!

Your help funding video for this conference makes a big difference! Please donate!

I was having a hard time with "fatal: early EOFs" messages when doing a git fetch in my cygwin session on my Windows dev box. Found good solution at stackoverflow: run the following:

% git config --add core.compression -1

That fixed it for me. Writing a blog entry about it so I have this fix forever.

Quickly is an application that makes it easier to start new software development projects by filling in a lot of the skeletal structure from a set of templates. I've read about it a bunch on Jono's blog in the context of his push for "opportunistic developers".

Chris Webber and I have been throwing together web applications most of which have the same basic structure: WebOb, Jinja2, simplejson, and routes with some glue and stuff in between.

I spent some time building a Quickly template for this structure. The results of this are at http://gitorious.org/quickly-webber-app.

It was kind of a pain in the ass. There's no docmentation that I could find on creating templates for Quickly, so I had to look through the ubuntu-project template and read through the Quickly code. Even then, I bumped into a few gotchas.

1. the command scripts are run as scripts and not imported as Python modules
2. commands cripts must be executable, otherwise Quickly silently skips them when building its commands list
3. probably better to develop the template in your ~/quickly-templates/ directory rather than as a project and schlepping things in and out like I did

I was using the Quickly that comes with Ubuntu Karmic which is 0.2.6. Ubuntu Lucid has a newer version, but I didn't want to fiddle with trying to get it to install on Karmic given that it's got dependencies that aren't readily available in Karmic.

After talking with Chris, he suggested I redo it with Paste templates. There's a good explanation at http://pylonshq.com/docs/en/0.9.7/advanced_pylons/creating_paste_templates/. It'd be interesting to see if I could build a set of templates that works with both Quickly and Paste.

Anyhow, the project is there if it's interesting to anyone. Email me or comment below if you have questions, comments, concerns, whatever.

Update 5/2/2010 - Didier (Quickly dev) says there is documentation for creating templates at http://www.didrocks.fr/index.php/post/Build-your-application-quickly-with-Quickly%3A-Inside-Quickly-part-6.

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, window):
        self.app = "Miro"
        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(
            self.app, 0, dbus_interface='org.gnome.SettingsDaemon.MediaKeys')

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

        window.connect("focus-in-event", self.on_window_focus)

    def handle_mediakey(self, application, *mmkeys):
        if application != self.app:
            return
        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 on_window_focus(self, window):
        self.bus_object.GrabMediaPlayerKeys(
            self.app, 0, dbus_interface='org.gnome.SettingsDaemon.MediaKeys')
        return False

def get_media_key_handler(window):
    """
    Creates and returns a MediaKeyHandler or returns None if such a thing
    is not available on this platform.

    :param window: a Gtk.Window instance
    """
    try:
        return MediaKeyHandler(window)
    except dbus.DBusException:
        logging.exception("cannot load MediaKeyHandler")

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

November 5th, 2010 - Fixed a bug in the code.
November 9th, 2010 - Tweaked the code to re-assert key handling on focus.