Dev (old posts, page 21)

phil 1.0 released!

, | Tweet this

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.

Help fund PyGotham 2011 video!

, | Tweet this

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!

Git in cygwin: fatal: early EOFs

, | Tweet this

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.

Building templates for Quickly and new webber-app template

, | Tweet this

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 status: 03/10/2010

, | Tweet this

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.

endash and emdash in Sphinx

, | Tweet this

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?

Thoughts on crowdsourcing development

, | Tweet this

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.

Handling media keys in GNOME with Python

, | Tweet this

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.

Indentation for if in python when using emacs and python-mode

, | Tweet this

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.

Useful things to know--stdin, stdout, and stderr

, | Tweet this

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.