I move between a couple different computers regularly: my old 12" PowerBook and the 15" MacBook Pro my job provides me with. Like all multi-computer users I periodically bump up against the challenges of what files (and versions) are where, especially when there’s work in progress.
To further complicate things, I also have an extra laptop running Ubuntu. And sometimes I just SSH to my web server from somebody else’s machine.
Among the many anti-spam measures on my mail server – which help me reject 5000 spam attempts per day – is SPF. SPF allows domain name owners to specify which mail servers are allowed to send its mail. That makes it an excellent way to detect address forgeries, a favorite spammer tool.
One of the early questions raised about SPF was: won’t spammers just buy their own domains and set up their own SPF records that say it’s all OK? You can read the answer in the SPF FAQ, but the short version is: Yes, they will, but it won’t give them a free pass.
A significant difference between developing Django sites versus static-HTML-based approaches (among which I count PHP and the like) is that static files, aka “media”, live in a dedicated spot.
Sometimes you need a piece of static content to be available at a specific URL outside your media root. robots.txt for example. This can be done in pure Django (i.e. without even touching your Apache configuration), and is especially nice if your robots.txt content is short. The example below serves a basic “keep out” configuration.
If you use Django’s admin application, you’re familiar with its “Recent Actions” sidebar. It gives a simple summary of your latest edits, including clickable links to the relevant objects (not any ones you deleted, naturally, but ones you added or changed).
It’s probably not something you look at very often, unless you do such intensive work in the admin that you lose track of things.
Django stores that log data (via the admin’s LogEntry model) for all admin users, a fact which has caused me to repeatedly daydream about writing a custom view or two to display it. In other words, I’d like to let superusers browse all object editing history. Because sometimes you need to answer questions like “When was that changed?” and/or “Who changed it?”
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 already revert to any point in history.