Problem is, most of these sources do not mention how to use virtualenv, but the cool kids don’t install their packages into the global site-packages directory. So I put some scripts together for your enjoyment.

I assume that you’ve put your django app somewhere convenient, and that you have a virtualenv containing its packages (including django itself).

1. manage.py

You want to set up this file so it adds the virtualenv’s site-packages path to its site-packages: site.addsitedir('path/to/mysite-env/lib/python2.6/site-packages'). Note that you need to point directly to the site-packages dir inside the virtualenv, not only the main virtualenv dir. For obvious reasons, this line needs to come before the django-provided from django... import, because you can’t import django files if Python doesn’t know where they are.

2. settings.py

The lighttpd setup will result in mysite.fcgi showing up in all your URLs, unless you set FORCE_SCRIPT_NAME correctly. If your django app is supposed to live right at the root of your domain, set this to the empty string, for example.

3. django-servers.sh

This is an initscript (for Debian, but you can modify it to work with most distros, I presume). Copy it to /etc/init.d, adjust the settings on top (and possibly other places, depending on your setup), then start the Django fastcgi servers. Note that you need to have the flup package installed in your virtualenv.

4. lighttpd-vhost.conf

Set up your lighttpd vhost pretty much like the Django documentation suggests. Match up the host and port with the settings from your init script. By using mod_alias for the media and admin media paths, you’ll have lighttpd serve them instead of passing them on to Django as well.

That’s it! You’ve deployed your first Django application on lighttpd. If you have any questions or suggestions, feel free to comment here or fork my code.

You can look at all the scripts together over on github or download them in a package.

Hi. I just noticed that your site looks like it has a few code problems at the very bottom of your site’s page. I’m not sure if everybody is getting this same problem when browsing your blog? I am employing a totally different browser than most people, referred to as Opera, so that is what might be causing it? I just wanted to make sure you know. Thanks for posting some great postings and I’ll try to return back with a completely different browser to check things out!

(emphasis: mine)

Not only does my blog display just fine in Opera (yes, I checked), I get even more bogus comments at times claiming that my blog looks horrible in Firefox, of all browsers. Dear spammers, now you’re just making fools of yourselves.

The main thing identifying this kind of comment as spam (other than the bogus claim that my blog doesn’t render correctly in non-Internet-Explorer browsers) is the URL these comments come with. Usually, they promise a “free” iPod, MacBook, car, house, airplane or ride to the moon (exaggeration: mine).

I wonder how many bloggers actually publish these, thinking it’s well-meant advice.

Photo credit: “Spam” CC by-sa licensed by twicepics on flickr

So, me being a geek and all, I quite naturally wanted to integrate the two and wrote a little AppleScript that asks the user for a bugzilla.mozilla.org bug number, obtains its bug title, and makes a new to-do item for it in Things’ Inbox folder.

The script is available as a gist on github. Click here to download it.

If you look at the code, you’ll notice that I went ahead and embedded some Python code to the script to do the heavy lifting. The problem with AppleScript is not only that it has a hideous syntax, it also completely lacks a standard library for things like downloading websites and regex-parsing strings. Let’s look at it a little closer:

set bugtitle to do shell script "echo \"" & bugzilla_url & "\" | /usr/bin/env python -c \"
import re
import sys
import urllib2
bug = urllib2.urlopen(sys.stdin.read())
title = re.search('<title>([^<]+)</title>', bug.read()).group(1)
title = title.replace('&ndash;', '-')
print title
\""

• set bugtitle to do shellscript "" means, assign whatever this shell expression returns to the variable bugtitle. This way, we just need to print our final result to stdout and keep using it in AppleScript.
• echo \"" & bugzilla_url & "\" | /usr/bin/env python feeds some input data into the Python script through stdin. We read that a few lines later with sys.stdin.read(). Another method, especially for more than one input values, would be command-line parameters, all the way at the end of the Python block (after the source code).
• Finally, in python -c \"mycode\" the -c marks an inline code block to be executed by the Python interpreter. Other languages, such as Perl, PHP, or Ruby, have similar operating modes, so you can use those as well.

If you want to install the Things-Bugzilla AppleScript, make sure to download the entire Gist as it also contains an install script for your convenience.

“Lance Albertson, architect and systems administrator at the Oregon State University Open Source Lab, uses a sys admin staff of 18-21-year-old undergrads to manage servers for some high-profile, open-source projects (Linux Master Kernel, Linux Foundation, Apache Software Foundation, and Drupal to name a few). In this Q&A, Albertson talks about the challenges of using young sys admins and the lab’s plans to move from Cfengine to Puppet for systems management.”

(via slashdot).

I must say, the work I’ve seen student sys admins do at the OSL is outstanding, and I’ve met some of the sharpest people there I’ve ever worked with. Glad to hear they are still going strong.

Thanks for the link, Justin!

Submodules are basically the same thing in the “git” world.

And since git can talk to subversion repositories with git svn, we should be able to specify a third-party SVN repository as a submodule in our own git repository, right? Sadly the answer is currently: No.

Here is a workaround that I have been using to at least achieve a similar effect, while keeping both SVN and git happy. This assumes that you have a local git repository that is also available somewhere else “up-stream” (such as github), and you want to import an external SVN repository into your source tree.

1: Add a tracking branch for SVN

Add a section referring to your desired SVN repository to your .git/config file:

(...)
[svn-remote "product-details"]
    url = http://svn.mozilla.org/libs
    fetch = product-details:refs/remotes/product-details-svn

Note that in the fetch line, the part before the colon refers to the branch you want to check out of SVN (for example: trunk), and the part after that will be our local remote branch location, i.e. product-details-svn will be our remote branch name.

Now, fetch the remote data from SVN, specifying a revision range unless you want to check out the entire history of that repository:

git svn fetch product-details -r59506:HEAD

git will check out the remote branch.

2: clone the tracking branch locally

Now we have a checked-out SVN tracking branch, but to use it as a submodule, we must make a real git repository from it — a branch of our current repository will keep everything in one place and work as well. So let’s check out the tracking branch into a new branch:

git checkout -b product-details-git product-details-svn

As git status can confirm, you’ll now have (at least) two branches: master and product-details-git.

3: Import the branch as a submodule

Now let’s make the new branch available upstream:

git push --all

After that’s been pushed, we can import the new branch as a submodule where we want it in the tree:

git checkout master
git submodule add -b product-details-git ../reponame.git my/submodules/dir/product-details

Note that ../reponame.git refers to the up-stream repository’s name, and -b ... defines the name of the branch we’ve created earlier. Git will check out your remote repository and point to the right branch automatically.

Don’t forget to git commit and you’re done!

Updating from SVN

Updating the “external” from SVN is unfortunately a tedious three-step process . First, fetch changes from SVN:

git svn fetch product-details

Second, merge these changes into your local git branch and push the changes up-stream:

git checkout product-details-git
git merge product-details-svn
git push origin HEAD

And finally, update the submodule and “pin it” at the newer revision:

git checkout master
cd my/submodules/dir/product-details
git pull origin product-details-git
cd ..
git add product-details
git commit -m 'updating product details'

Improvements?

This post is as much a set of instructions as it is a call for improvements. If you have an easier way to do this, or if you know how to speed up or simplify any of this, a comment to this post would be very much appreciated!

• Select a new persona from the Personas Gallery.
• More than 75% of Add-ons work. Test your favorites!
• Try watching a video in full screen mode.
• Have you seen websites using WOFF fonts?
• Kick the tires with improved JavaScript performance, browser responsiveness, and startup time.
• See the release notes for more details.

Go check it out.

As you probably know when reading this article, you push all uncommitted changes to the remote svn repository by typing git svn dcommit. This will take your last, say, five commits, push them to SVN, and mark them locally as committed. But what if you only want to dcommit some of your changes?

(If you don’t need explanations, jump straight to the summary).

Step 1 (optional): Reorder commits

I am not going to go into a lot of detail on interactive rebasing (git rebase -i), but to start off, make sure your commits are ordered, so that the ones you do want to commit to SVN are before the ones you do not want to push up-stream for now. Example: If in the following history, you want to commit all changes but a023fea, you want to rebase your commits so a023fea is last:

In git rebase -i HEAD~4, change…

pick 07c26c5 some de L10n
pick a023fea adding free-text messages to localizer dashboards
pick 8597f47 adding featured collections as l10n category
pick 19f3df3 making existing localizer pages work with amo2009 layout

… to…

pick 07c26c5 some de L10n
pick 8597f47 adding featured collections as l10n category
pick 19f3df3 making existing localizer pages work with amo2009 layout
pick a023fea adding free-text messages to localizer dashboards

Make sure to resolve any merging problems that might occur due to the reordering.

Step 2: Step in between commits

To only push the desired commits to svn, execute another git rebase -i and mark the last desired commit for editing (by changing pick to edit):

pick 07c26c5 some de L10n
pick 8597f47 adding featured collections as l10n category
edit 19f3df3 making existing localizer pages work with amo2009 layout
pick a023fea adding free-text messages to localizer dashboards

When exiting the editor, git will drop you off after the marked commit, but before the one you don’t want, as a quick look at git log can tell you.

Step 3: dcommit desired changes

After making sure this is really what you want, just execute git svn dcommit as usual and watch git push all desired changes to SVN, while omitting the rest.

Step 4: Fast-forward to HEAD

When the dcommit is done, remember we are still in the middle of a rebase, so just run git rebase --continue to fast-forward to the HEAD of your branch. Again, a quick look at git log can reassure you that only the changes you wanted to have been pushed to SVN.

Success!

Summary: Quick cheat sheet

Here’s a quick cheat sheet for you (and me) to come back to in case you forget:

• Reorder commits (git rebase -i HEAD~4) so that the undesired ones are after the ones you want to push
• In your commit history, jump right after the last wanted commit by marking it for editing in git rebase -i
• git svn dcommit
• git rebase --continue

I wonder if their pink fail-unicorn is somehow related to the similarly colored (but less angry) Django Pony. A distant relative, maybe — especially since the “original” Django pony was, in fact, a unicorn.

(Before someone is urged to remind me, yes, to my knowledge, github is written in ruby, not Python/Django.)

This update eliminates the noise made by the optical disk drive during system startup and wake from sleep on MacBook computers.

Wow. As long as I’ve been using a Mac, the sweep-sweep noise has been characteristical for a Mac startup sound, reminiscent of the floppy drive seek sound computers made when they still came with floppy drives (yes, dear children, I am that old).

I wonder what this was for in the first place. Maybe to find out reliably if there is a disc in the drive already? <crystal ball>Possibly, the operating system did not check again and just relied on the hardware status flag being set correctly on startup, and if it was wrong, evil things could happen?</crystal ball> And now, almost suddenly, the Mac engineers found out that it is unnecessary altogether? The wonders of Snow Leopard.

What comes next? Removing the gong on boot to avoid Mac-obsessed college kids from making fools of themselves during lectures?

Today, I had enough, and after a little more googling, I stumbled across a comment in a macosxhints article mentioning Bluetooth settings: Apparently, there’s a setting for letting bluetooth devices power your Mac up from sleep. As I have a bluetooth-based wireless Mac keyboard, I tried out switching that setting off — and long story short, it seems to have worked.

If you have the same problem, uncheck the following box in System Settings / Bluetooth / Advanced Settings to give it a shot:

Happy zombie-Mac killing!