Will >> Will's blog

purpose: Will Kahn-Greene's blog of Miro, PyBlosxom, Python, GNU/Linux, random content, PyBlosxom, Miro, and other projects mixed in there ad hoc, half-baked, and with a twist of lemon
Page 1 of 5  >> (less recent)

Tue, 31 Dec 2013

Blog update: December 31st, 2013

A few weeks ago, a friend of mine started a site called Nethack-a-day. It's fantastic---a Nethack game with color commentary one turn at a time. If you like Nethack, but haven't seen it, you're missing out.

As he was setting it up, he was looking at various systems he could build it with. I sort of wanted to say, "Yo, just use Pyblosxom." because I was pretty familiar with it (I spent the better part of 9 years maintaining it) and I knew it did 80% of what he needed. But I hesitated because I've been on the fence about switching to something else for a while now.

Then I committed a critical mistake. I said, "You know, Pyblosxom would be great for this, but how about I fix a handful of things first that'll make it easier to deal with." A handful of things turned into a massive overhaul of Pyblosxom ripping out a lot of the technical debt that had been accruing for years, re-imagining some of the bits I was never happy with and tweaking some things just because it seemed like a good idea at the time.

Thus was born Douglas.

Douglas resembles many of the static site blog generator systems written in Python that exist. That suggests it was a dumb idea to go and write it, but it has three compelling aspects that I think made it worth my time:

  1. It's derived from a blog system I maintained and thought about for a long time, so it has all the sorts of things I would want in a static blog generator
  2. I can continue to say, "I've been using the same blog system since 2002." Sure, it's not exactly the same system, but it's not like I have to go rewrite/reformat entries I wrote in 2002.
  3. It has a nicer callback system that I think makes it more malleable when it doesn't do exactly what you want by default.

Right now it's in an alpha state: the test suite doesn't cover enough of the software; the docs are mediocre and in some cases are filled with outright lies; there are a handful of issues; and there's still a bunch of technical debt and some architectural decisions that sucked and are increasingly difficult to work around.

Regardless, about a month, 102 commits and 9980 insertions and 22828 deletions later, I'm now switching my blog over to my new system. And that's how I'm going to end 2013.

Thu, 11 Oct 2012

Blog update: October 11th, 2012

I spent the greater part of my free time over the last two weeks reworking my blog.

Before it ran on Pyblosxom as a CGI process (yes---a CGI process). It had accrued a decade of sediment, redirects, hacks, hacks on hacks, etc (yes---a decade). It was kind of messy and---worse---it really impaired my ability to blog easily. That sucked.

Now it runs on Pyblosxom, but it's statically rendered with a post-receive hook from a git repository. The work flow for blogging is a lot easier and I can test things out locally before pushing them live. I also ditched a bunch of silly things in the blog.

I also ditched comments. I might at some point switch to using something like talka.tv, but most of the time people were writing comments as a response or a reply to me---not intending to be part of a bigger discussion with other readers. Given that, I ditched comments. No sense in spending the time maintaining them if they don't really get used. Instead, email me.

Sat, 29 Jan 2011

Blog update

I updated my blog to use PyBlosxom from git master HEAD as well as updates to plugins that are now part of the PyBlosxom core. There have been a bunch of bugfixes, so my blog works a lot better now. I also abandoned a bunch of home-made plugins for their suped-up equivalents in PyBlosxom core.

I wrote a script that grabs my identi.ca dents and generates local entries for them. I figured most people probably don't follow me on identi.ca (which is a shame), so I'll bring it here.

Then I spent about 30 minutes tweaking the CSS to make the blog look a little better. It's not super, but it's good enough for now.

Thu, 04 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.

Fri, 02 Jan 2009

How to resize a virtual disk

I use VirtualBox OSE for virtualizing test environments for Miro development. I built a Windows XP vm a year ago and when I did it, I put it on a virtual disk that was 8 GB which turned out to be waaaay too small for my needs. It's non-trivial to build a Windows build environment for Miro so I really wanted to clone the partition to a new virtual disk that was a lot bigger, then resize the partition rather than create a new virtual disk and reinstall and set everything back up.

I pretty much did that this morning in a couple of hours.

First thing I did was download the LiveCD of Clonezilla (version 1.2.1-23) and the LiveCD of GParted (version 0.4.1-2).

Second thing I did was create a 25 GB virtual disk in VirtualBox.

Then I attached the new virtual disk to the winxp vm that I had. Thus it should show up as hdb.

I booted into the Clonezilla LiveCD, cloned the old virtual disk to the new one keeping the partition sizes the same and making sure to copy over the MBR, too.

I switched around the virtual disks attached to my winxp vm and booted into the new virtual disk--worked great!

I booted into the GParted LiveCD, launched qtparted and grew the NTFS partition so that it used the whole virtual disk.

Then I booted into the new virtual disk. It did an NTFS disk check on startup which I thought might indicate the process didn't work right. Disk check passed, Windows XP booted and everything worked as well as I expected it to.

Sat, 26 Apr 2008

Upgrading to MoinMoin 1.6

A couple of days ago, I did a dist-upgrade on my server which runs Debian. I'm not sure what version I had prior to the upgrade, but after the upgrade I'm at 1.6.2. The problem is that the wiki syntax is different, so my wiki data was mildly hosed. I ended up spending 45 minutes to an hour trying to figure out how to migrate the data.

The magic script is /usr/share/python-support/python-moinmoin/MoinMoin/script/moin.py . You need to run it like this:

$ ./moin.py --config-dir=/path/to/wikiconfig.py/dir/ migration data

The other problem I had is that I had no meta file in my data directory and so the moin.py script would die with a stack trace like this:

Traceback (most recent call last):
  File "./moin.py", line 24, in ?
    run()
  File "./moin.py", line 15, in run
    MoinScript().run(showtime=0)
  File "./../../MoinMoin/script/__init__.py", line 138, in run
    self.mainloop()
  File "./../../MoinMoin/script/__init__.py", line 251, in mainloop
    plugin_class(args[2:], self.options).run() # all starts again there
  File "./../../MoinMoin/script/__init__.py", line 138, in run
    self.mainloop()
  File "./../../MoinMoin/script/migration/data.py", line 44, in mainloop
    curr_rev = meta['data_format_revision']
  File "./../../MoinMoin/wikiutil.py", line 472, in __getitem__
    return dict.__getitem__(self, key)
KeyError: 'data_format_revision'

I assumed that I had some version of 1.5 previously and so I created a meta file with this in it:

data_format_revision: 01050800

After doing that, the moin.py script worked nicely and all my wiki data is in the correct syntax now.

Updated: 4/26/2008 - Fixed some grammar to make the meta file creation step clearer.

Sat, 19 Apr 2008

Hardy tips for resolution fixing when using it in a VirtualBox vm

I'm trying to get Ubuntu Hardy support for Miro. I installed Hardy Beta 1 in a virtual machine with VirtualBox. The install went fine. I had problems fixing the resolution, though.

Hardy starts off with an 800x600 resolution which is too small to run Miro. To fix it, you have to:

  1. run sudo displayconfig-gtk from a terminal
  2. click on the dropdown for models and choose LCD Panel 1024x768
  3. click on the Test button to make sure it works
  4. click on the OK button to apply that one change
  5. log off
  6. log on again

DON'T change the monitor AND the resolution of the screen at the same time. If you do that, you see no errors, no changes get made, and you'll spend a while scratching your head wondering what happened.

If all went well, you should see the resolution you were looking for.

Note that since Ubuntu Hardy is beta software, this could all change tomorrow.

Updated: 4/19/2008 - It looks like they took displayconfig-gtk out of the menus in the Hardy release candidate so I updated the instructions above.

Thu, 13 Dec 2007

Pretending to add new files with cvs

I was throwing together a patch for Firefox 3 and needed to add some files to CVS but I don't have add privs. If I don't add the files, then they don't show up in the diff. After a Google search, I bumped into fakeadd which tweaks the Entries file so that the new files show up in the diff. No clue if that's a good thing, but it certainly fixes the problem I was having.

Sat, 03 Nov 2007

Galcon in Gutsy

I had to install the following on a fresh Gutsy install to get Galcon working:

sudo apt-get install python2.4 libsdl-ttf2.0-0 libsdl-mixer1.2 \
    libsdl-image1.2

Figured I'd mention it here. I don't have a Galcon Forums account and don't really feel like creating one. If someone else has a Forums account, post the above in case other Gutsy-users are having problems.

Sun, 30 Sep 2007

MozRepl

I've been doing Firefox extension development and it's been going pretty slowly because it's hard for me to figure out what's going on when things are running (and I'm not wildly familiar with the things I'm working with).

After whining about how I wish there was a REPL for JavaScript, I did a Google search and came across MozRepl. It's helping a lot so far. I'm not spending hours hunting for object documentation anymore.

On an interesting note, you connect to MozRepl with telnet and it has a line-mode interface. Turns out that Lyntin (a mud client I worked on years ago) works fantastically for this. I would assume most mud clients would because at heart they're line-mode telnet clients with a bunch of features designed to remove repetition in common tasks and make it easier to skim large amounts of output quickly without having to read through all of it.

For example, say I was interested in skimming changes for the title attribute. I could do this:

#highlight {reverse,green} {title=*}

That will highlight lines with "title" in them from "title" onwards.