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.

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.

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.

the command scripts are run as scripts and not imported as Python
modules

commands cripts must be executable, otherwise Quickly silently
skips them when building its commands list

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.

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?

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.

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.