Will's blog

purpose: Will Kahn-Greene's blog of Python, Linux, random content, PyBlosxom, Miro, and other projects mixed in there ad hoc, half-baked, and with a twist of lemon

[ home | blog home | recent activity | guestbook | plugins i'm using (19) ]

Page 1 of 21  >> (less recent)

Thu, 29 Apr 2010

Building templates for Quickly and new webber-app template

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.

[ tags: dev, python, ubuntu, web | category: /dev | Permalink | 2 comments ]

Wed, 10 Mar 2010

PyBlosxom status: 03/10/2010

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.

[ tags: dev, pyblosxom | category: /dev/pyblosxom | Permalink | 2 comments ]

Sat, 06 Feb 2010

endash and emdash in Sphinx

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?

[ tags: dev, python | category: /dev | Permalink | 2 comments ]

Fri, 05 Feb 2010

Thoughts on crowdsourcing development

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.

[ tags: dev, floss, gnome, miro, python, software, work | category: /dev | Permalink | 2 comments ]

Mon, 25 Jan 2010

Handling media keys in GNOME with Python

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.

[ tags: dev, gnome, miro, python, work | category: /dev | Permalink | 2 comments ]

Thu, 10 Sep 2009

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

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.

[ tags: dev, python | category: /dev/python | Permalink | 0 comments ]

Thu, 30 Jul 2009

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

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.

[ tags: python | category: /dev/python | Permalink | 0 comments ]

Tue, 23 Jun 2009

Adopted a line

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.

[ tags: miro, work | category: /dev | Permalink | 0 comments ]

Sat, 20 Jun 2009

When git-svn is painfully slow...

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).

[ tags: dev, miro | category: /dev | Permalink | 0 comments ]

Sat, 16 May 2009

PyBlosxom status: 05/16/2009

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.

[ tags: dev, pyblosxom, python | category: /dev/pyblosxom | Permalink | 1 comments ]

Page 1 of 21  >> (less recent)
pyblosxom::1.5rc2 20100803

All contents Copyright 1996 to 2010 Will Guaraldi Kahn-Greene.

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.