Posts tagged: TIPS

Last year a client asked for help moving his website to a new host from XO.com. The tricky part was that his 200 pages of content were locked into an obsolescent proprietary tool called “Site Builder” that offered no exporting options. The file format was a flatfile that looked like this:

#Page-Type "html"
#UID "1000"
#Access-PublicRead "on"
#Access-PublicWrite "off"
#Page-Links-Style "links_outline.nhtml"
#addbrs "off"
#hidenav "off"
#HTML ...

The file structure went like this: a parent directory named nss-objects; child directories bearing page names (or slugs, really); and inside each, an empty directory named !data and a text file named !object with the page content as described above. Weird. (I suppose every proprietary one-off system is weird in its own way, so there’s nothing to be gained from dwelling on the specifics, but at least including them in the post raises the chances that somebody who actually needs this thing and searches for it will find it.)

For larger web projects I’ve moved almost exclusively to Django, but PHP is still handy. Recently I wanted to quickly (really quickly) make a flat-heirarchy site with dynamic pages, with clean urls like example.com/foo and example.com/bar.

I could do this with several directories containing index.php files, but I want to use the Google Maps API on several of these pages, and the separate directories would entail separate Google Maps API access keys – a pain.

People are always going on about how it “only” takes twenty minutes or whatever to knock together some little application. Screencasts don’t count, unless they are screencasts of somebody who hasn’t done any preparation. But damn, I just built a trouble-ticket system in Django in twenty minutes. Really. Of course, I already had a running install, this is just something I added. But it was instantly useful. I assigned four tickets to myself and now I can go have dinner.

Working on a couple Django projects in tandem has me tuning my approach to using the built-in development server. I thought I’d share some of the techniques I’m using.

Here are the commands I’m going to talk about. If you understand it all from these lines, you’re done!

screen -S projectname
./manage.py runserver |& tee -a logs/devserver.log
^A ^D
tail -f logs/devserver.log
screen -r projectname
screen -list

Using screen

screen -S projectname

The GNU screen command is incredibly useful for all kinds of things, including longish-running processes that need to be checked and tweaked and stopped and started – like your Django development server. (Read more about screen if this is new to you.)

The title of this post is a joke, but one you’re only likely to get if you actually use one of these services: in the attention economy of link-sharing, titles that pit one thing against another tend to rise higher. (Maybe this validates the old Wired Magazine guideline of “no conflict, no story” – or maybe it proves the easiest way to get attention is to antagonize.)

Over the past few months I’ve played with both Digg and Reddit as ways to discover new and interesting stuff, and wanted to post some notes for the hypothetical reader who is even farther behind this particular curve than I am.

I avoid XML as much as possible, but once in a while I’ve had a project where I thought about making an ad-hoc XML dialect. I’m going to file away Tim Bray’s recent blog posting to keep me out of trouble during those moments of temptation. His advice boils down to this: If you are tempted to make a new XML dialect, instead try fitting it into one of what he calls the the “big five”:

I’m an Emacs man myself. I’ve never really used vim at all, and I use vi only for crontabs and commit messages. I’ve always grasped in the abstract the potential advantages of its modal editing, but that’s as far as it ever went.

Jonathan McPherson’s site has a great introduction to using vim that opened my eyes. His explanations of vim’s features offer just the right amount of detail. Most importantly he explains why particular commands are a good idea. Not explaining that is one of the classic failings of manpages – and I suspect that the vi manpage is the beginning and end of many users’ attempts to learn it. They learn about insert mode, command mode, loading and saving files, and that’s about it. Luckily, those just happen to be the prerequisites for McPherson’s tutorial. Clever fellow.