Every single post on the entire My Digital Life mass blog site is not a technology post.  In fact, at the moment, I'd say less than 5% are.  Please remove your silly blanket membership in "Technology" on Amatomu simply because you are on the Intarwebs.

The Management

After converting 70+% of a project at work from Django to TurboGears over a week and a bit, and starting at rewriting an existing TurboGears project of mine to Pylons, quite a few things have interested me about the exercises.

Standard disclaimer about this just being my personal feelings and not some scientific test applies.  I've used TurboGears (90% own projects) a lot longer than I've used Django and Pylons, and I've used Django (50% work projects) a little bit more than I've used Pylons (only own projects so far).  I also prefer tea to coffee, tcsh to bash, and winter to summer.

... 

Oh, okay, it's not that bad.  So long as you don't have too many add-ons installed.  But, you know, as a "developer" that has to debug other people's broken web stuff, you need those add-ons.  And, you know, they're actually quite nice.

Anyway, running the same set of add-ons on Firefox for development and plain browsing is not working out.

Of course, none of this is rocket science, or even new, so everybody else probably knows anyway.

I now have one "firefox -P default" icon and one "firefox -P development" icon on my panel, and browsing is fast again (I'd totally forgotten quite how fast) and development is still featureful.

(And, I guess, if you're into that sort of stuff, you can use a totally different profile for your House erotica fanfic writing persona and another for your respectable normal persona.)

I've been spending a lot of time looking at Pylons lately.  Over the past few months, I've noticed an increase of interest in it, and an increase in activity around it.  Not least of this activity is in the creation of documentation on the Pylons-related spaces on the Python Web Documentation Project.

While there are still many little niggles about Pylons (like, for example, deciding on the correct way to set up your database connectivity), it's great that that so much of it is being documented - there's recipes for setting up SQLAlchemy with Pylons, and doing unit tests with SQLAlchemy and Pylons, and also a quick whistle-stop tour of SQLAlchemy for people arriving at Pylons before encountering SQLAlchemy.

The Pylons Cookbook is starting to look really impressive - with lots of deployment information, as well as background informational and conceptual information, recipes for common tasks, and so forth.  And there's even some discussion of some of the more advanced and of not-particularly-framework-specific stuff - like on how one can create your own template for paster create, or use entry points to create and handle plugins.

Anyway, not part of the documentation project (yet), Mike Orr's Pylons Execution Analysis of a Pylons application.  From deployment (installating the packages, using paster make-config and paster setup-app) through Paste Script, Paste Deploy, and into the Pylons framework and your own application, it is an invaluable introduction to what happens when.