In the shell, emacs is my editor of choice. However, it has one default behavior that has gotten in the way more often than it has helped -- automatic generation of backup files in the same directory as the original.

Emacs is great for making quick edits to files on the web server. But I don't want or need all those *~ files sitting around. The material is all in version control, so I can revert to any point in history already.

I went to the #emacs IRC channel on Freenode to ask about this, and was prompty handed a canned help message that led right to the solution to my problem: backup-directory-alist lets you specify a directory where backup files get saved.

A little googling yielded the following nice snippet from Sean B. Palmer which I prompty deployed in my .emacs file. Problem solved. Thanks, everyone!

;; Turn off the annoying default backup behaviour
(if (file-directory-p "~/.emacs.d/backup")
    (setq backup-directory-alist '(("." . "~/.emacs.d/backup")))
    (message "Directory does not exist: ~/.emacs.d/backup"))

I run my own mail server. I don't consider myself an especially skilled administrator, so I shouldn't point fingers. However, in recent weeks I've had the following experience more than once.

1. A delivery-failure message arrives from an unfamiliar host.
2. The (quoted) orginal message is nothing I ever sent.
3. The recipient is unfamiliar to me.
4. The "sender" of the original message is an email address I control, but not one I ever send mail with.
5. OK, so this is backscatter.
6. I email the postmaster suggesting they learn how to avoid sending it.
7. The message to the postmaster bounces back because of some server misconfiguration.

Argh! Nothing spoils the catharsis of a good complaint like a bounce.

I trust that most of these servers will disappear over time, given that they already are showing signs of neglect. So maybe that's the happy ending! A bit too deferred for me, though.

When I created dpaste, I tried to make it both a simple browser-based tool and a simple RESTful API. With very little work you could write a script that created a new paste item with a single POST.

Over the life of the site a few people have discovered and played with that "secret" API. I've now made it a bit more official. The new API has its own URL (versioned, even!) and is more tolerant of missing data, just like the web form.

The URL is http://dpaste.com/api/v1/. In a web browser you'll see just a terse line of instructions. Here's a one-line usage example for unixy people. It takes text on stdin and returns the URL of the newly created paste.

curl -si -F 'content=<-' http://dpaste.com/api/v1/ | grep ^Location: | colrm 1 10

Support disclaimer: Depending on your version of curl and your shell some of those options may need twiddling. But in a low-tech way it's kind of cool, isn't it? (Figuring out how to get curl to read stdin was a new one for me, so the novelty is high at the moment.)

Anyway, use and enjoy as you wish!

"I'm a PHP programmer and I want to check out this Django thing. What should I do?"

I've been seeing this kind of question pop up more and more, and I have a few answers.

First-hand experience as well as many conversations with developers online have led me to the same conclusion: the curious person behind such a question should be encouraged and assisted. (I'll call that person "Pat" for the rest of the post, for convenience and conscientious gender-neutrality.)

Every developer who has come to Python and Django from some other web app technology could write a detailed memoir, in the guise of advice, on how it all went. Many have. Pat should read one or two.

Then, while still working away in PHP-land, Pat should:

Learn mod_rewrite

If using PHP, Pat is very likely using Apache. Apache has an extremely handy module called mod_rewrite that allows Pat to slice up requested URLs and feed them to scripts in just the right way.

E.g. with a one-line rule Pat can tell Apache to turn a requested URL like http://example.com/people/paul/ into a call to people.php?name=paul behind the scenes. Users get clean, readable URLs, and Pat get to structure code as desired. These rules use regular expressions, but that's not the main reason I recommend mod_rewrite in this situation.

I recommend it because a good set of those rules can translate remarkably cleanly into a set of URL-handling rules for a Django site, known as a URLconf.

Separate business logic from presentation

PHP is at its root a templating language. A key to happy PHP development in my experience was keeping the templating part separate from the business logic part. E.g. a main script assembles all the data that the page will need, then includes a template that takes that data and displays it.

Django, like most other web frameworks, enforces this separation to great effect.

Use indentation

Like other languages with C-like syntax, PHP doesn't care how you indent your code. However, Python (famously) does. For curly-brace programming, I like the Whitesmiths style, which happens to be nearly identical to standard Python style when you eliminate the lines containing the braces.

Consistently-formatted code in any language is easier to work with than the alternative. By cleaning things up Pat can make things better for Pat right now (as well as for those who work with Pat's code), and be happy with Python tomorrow!

Standardize on a back-end admin tool

No matter what kind of sites Pat builds, it's likely to involve making back-end administration tools. They may be used for updating text content, or adding database entries, or changing settings used across the site.

Everybody gets tired of building these things over and over, and doing it really well isn't easy.

My advice to Pat is, as much as possible, to standardize on a back-end tool that can be used for all projects. This may be something home-grown, or a general-purpose open source tool like PHPMyAdmin and friends, or a customizable open source application built for this use. That way Pat spends more time on interesting application code, and Pat's clients get a more consistent experience.

One of Django's gems is its bundled admin application, designed to work with any Django application you create. It's pretty, capable, and highly configurable. Best of all, you never have to write or maintain it, because it's already there for you.

Learn Python

This one may seem obvious. However, I've seen a lot of people dive into Django with no previous Python knowledge and end up wanting more. It's not impossible to learn both at the same time, but it's not necessary or even efficient. Luckily, there are a lot of books on Python out there in addition to good free resources.

Python is good for more than Django, of course. It's an excellent general-purpose programming language that Pat will be happy to use for all sorts of things. Writing utility scripts and other little things in Python is a great way to get comfortable before building that killer social networking app you've been dreaming of.

There are connections between programming and my favorite ice cream.

In our new book on Django, I used the sentence "My favorite ice cream is Herrell's" in some example code where I needed text -- a tribute to my favorite local ice cream parlor.

Walking by Herrell's this afternoon, I saw Steve Herrell inside. Because I had a copy of my book with me, I decided I'd see if he wanted to take a quick look at the code snippet. He did. He took this odd testimonial with grace and good humor, and thanked me.

Then he surprised me by bringing up a connection between programming and his ice cream that I hadn't considered. Mixins.

In ice cream, mixins are chunks of good stuff like chopped up Heath Bars. Herrell is the man credited with inventing this practice. He did this in his first parlor, Steve's Ice Cream, in Boston (Somerville, actually) in the '70s.

In object-oriented programming, a mixin is a class used to add specific attributes or features to another class. Not so much a "parent" class as a clever uncle. Some sort of mixin funcionality is possible in any language with multiple inheritance, as far as I know.

What I didn't know until reading the Wikipedia article on mixins was that the programming term itself was inspired by Steve's Ice Cream! This adaptation of terminology was the handiwork of workers at Symbolics, a Lisp company headquartered in nearby Cambridge.

So, not only did today's little outing give me an excuse to get a dish of Key Lime Cardamom ice cream, it gave me a fun new bit of trivia as well.

This post is not about any of my usual software or hardware topics, but it still is nerdy.

The flashlight.

Parliament's classic song on the subject tells us that "everybody's got a little light under the sun." It's good to have a little light, especially when the sun isn't around. But some little lights are better than others.

The best thing that has happened to flashlights in recent years, especially little ones, is the rise of the LED. Compared to their predecessors, LED lamps are smaller, more efficient, more durable, and much longer burning.

My mainstay pocket flashlight for years was a "CMG Infinity Ultra". The dumb name was forgivable because of the overall greatness of this light. It's a little cylinder of machined aluminum with an AA battery inside and a bright white LED on the end. Sealed, waterproof, incredibly rugged, and 10 or 20 hours of light on a charge.

One day, after years of reliable service on camping trips and other adventures, it went dark. Via email I asked Gerber (who had bought CMG) what to do. In short, they said, "send it in." I did.

A couple weeks later I came home to an envelope from them containing a brand new replacement light in retail packaging. Very nice.

This particular style of light -- durable, simple, waterproof, LED, long hours on a rechargeable single cell -- is not easy to find. Big credit to Gerber for keeping it going and keeping me equipped.

It will surprise few that I have not yet given Apple $10 for the privilege of upgrading my iPod touch ("iPt") firmware from 1.1.5 to 2.x.

Update: A month after posting this, I took the plunge. Version 2.2 came with some nice little improvements. I still miss my shell, but at least I have an SSH app!

At first, I resisted out of attachment to the open source software I had installed via Cydia -- with no supported "upgrade" process per se, I would have had to reinstall all my packages manually. Then I saw that my core uses of the iPt (email, web browsing, audio, calendar, contacts) all used the Apple software, so I leaned toward the upgrade.

I tried to find out what I would actually be getting, besides the obvious access to the App Store. (I ruled out the App Store as a factor because I still wanted to go open source for third-party additions when the time came.) So I asked many people, online and in person, what benefits the upgrade offered besides the App Store. This was less than satisfying.

On average the answers boiled down to 1) "The App Store is awesome!", 2) "More stable!", and 3) "Fewer dropped calls!" Given that I wasn't asking about the App Store, have had no stability problems, and don't have an iPhone, this left me uninspired, and I decided to wait.

What am I waiting for? Not sure. Maybe a future 2.x version that delivers something that I want. Or Apple support for Cydia or similar. While I'm dreaming, I suppose I could wish for it to be free too.

During the 40 months or so of this blog's life I've worked to keep it focused on my technical and professional interests, not personal stories. That means that you are conveniently spared having to read the story behind the lack of posts here since late May. Summary: Things were bad, but are much better now.

So I'm now back in action, and sporadic posts should be forthcoming without another four-month wait. For those waiting on the book, rest assured that it's well under control, and closer than ever to being in your hands. Final details to come. But soon you'll be able to buy it, carry it to the cafe, and put it out on your table next to your laptop as a sign of your great savvy.

I just filed a ticket with the Google AppEngine project requesting the source to GoogleAppEngineLauncher, with the idea that this would make a very cool Django developer's aid on OS X -- much like Locomotive for Rails. Anybody else interested in this should go star it:

• http://code.google.com/p/googleappengine/issues/detail?id=386

Update: Cool. In less than 24 hours, 38 people have starred the issue, making it the 31st most-requested item and rising -- ahead of hot numbers like "Please add Tcl support". Sorry, Tcl.

At the Western Mass. Developers Group meeting this week I showed a few people some of the unixy fun you can have with a (jailbroken) iPod touch and the Cydia package manager. Cydia is a port of Debian's APT system to the iPhone platform -- i.e. it's a real package manager. It made it a snap to install Python, Mobile Terminal, Mobile Text Edit, Subversion, etc.

This is the toolset that has allowed me to even do some work on the book as I mentioned in my last post.

And while it has its limitations as a development environment, of course I did get Django running on it. Below are a couple screenshots of an example application from the book.

This is my kind of portable computer!