Monthly Archives: December 2006

Fonts and Planning with Emacs 23

Lately I’ve become enamoured with Emacs planner-mode which allows me to use Emacs to maintain task lists and schedule information in a psuedo-wiki-like environment (courtesy of Emacs Muse). In particular I’ve been using the planner-timeclock to track what projects get my attention and when. Of course its not 100% accurate — I still often forget to “clock in” when starting to work on something — but I think I’ll be able to get some useful information from it.

This weekend, however, I managed to screw up the fonts in Emacs. They were never great, but I’d managed to get them to a state where they didn’t kill my eyes or take up half the screen. As I started to poke at the problem this morning, I ran across the prospect of using Emacs with XFT fonts. More poking and I found a source for .debs of updated emacs-snapshot packages. Your mileage may vary, but I found, like other people in the comments thread, that the dapper packages actually work better on Edgy than the edgy ones. So after installing the packages I had lovely anti-aliased font support, but alas, planner-mode broke. So to save anyone else in this situation (ha!) some grief, you need to grab planner and muse from source when using them with Emacs 23 on Ubuntu 6.10. The “latest” tarball links in the Emacs Wiki work.

date:2006-12-18 08:50:43
wordpress_id:465
layout:post
slug:fonts-and-planning-with-emacs-23
comments:
category:geek

Deploying Python Code: Support Services

Just over a month ago I blogged about my first experience with zc.buildout. For those that don’t remember (shame on you!), zc.buildout is a Python tool developed by Jim Fulton of Zope fame for constructing software installations. “Buildouts”, if you will. The attraction to this over, say, just distutils or just setuptools is that you can go from a bare-bones Python installation and source code checkout (or tar-ball) to a fully functional application, with dependencies and the trimmings, in a predictable, sane way. The fact that dependencies are installed in a local folder makes this especially appealing for deploying code on hosts where you don’t have write access to site-packages. But enough re-hashing my last zc.buildout post.

As I mentioned in my previous post, I’ve been using zc.buildout mostly to deploy the web applications that power Creative Commons’ web services These are written using CherryPy, and were previously invoked as simple CGI scripts. However, as usage grew, we needed to move them to independent processes, which Apache proxied to using mod_rewrite. zc.buildout provided a great way to generate the wrapper script for running that process, but early this week we ran into a problem: we didn’t have a good way to detect if the process died for some reason and needed to be restarted.

I decided that a simple approach was best for the initial go-round, and wrote a small shell script that looks at the pid file, checks if it’s still running and if not starts the process. Put this in a cron job that runs every 10 minutes or so, and you have a poor man’s watchdog:sup:1 <#fn8f2bac94-0bf0-492d-94de-4243a89c40c9>`_`. After writing two of these, I realized that this is something that should really be automated as part of my software installation: I always want to have a “am I up?” check script available, and so my first custom zc.buildout recipe, ``build_script, is born.

build_script is a recipe that takes a template file, fills in values using Python string formatting and marks it as executable. It has one template included, paster-check that we’re using to check on a paster process, and you can use templates that are part of the egg itself or are part of your codebase (via the template_dir setting).

You can find the code for build_script itself in Creative Commons’ subversion repository (web view), and an example of how we’re using it for our web services is here.

Suggestions, comments, questions all welcome, as are additional templates that might be useful to include in the egg itself.

1I’m sure there’s a better, more robust way to do this, but this is where we’re comfortable on the down time v. implementation time continuum. That said, if someone knows of an easy, more robust way, of course I’d like to hear about it.

date:2006-12-15 17:00:12
wordpress_id:464
layout:post
slug:deploying-python-code-support-services
comments:
category:development