Hosting passenger apps on nginx is easy. If they don’t need any specific webserver config, though, it’s even easier.

server {
  listen 80;
  server_name *.com *.com.au *.net *.org;
  root /home/$host/current/public;
  passenger_enabled on;
}
  • This is particularly useful in a development environment - just set rails_env development in the server { } block, and ghost the domain to localhost.

  • You should deploy your app to a directory, and as a user, with the same name as the app’s root domain. (You should do this anyway, because it’s neat and consistent.)

  • Don’t forget to chown $host /home/$host/current/config/environment.rb, to run each app as its own user. (You should do this anyway, because it’s good security practice.)

  • You can’t use server_name * — you can only wildcard a domain prefix, not the whole thing.

posted : Friday, July 3rd, 2009

tags :

Running passenger for development is great, but if you’re hacking code within a plugin then it’s cumbersome to constantly touch tmp/restart.txt and refresh your browser, even if you use tou[UP] to pick the command from your history.

Using fish and some applescript, you can do it all from your terminal by hitting ⌥R.

function reload_webkit
  osascript -e 'tell application "WebKit" to do JavaScript \
    "window.location.reload()" in front document'
end

function restart_rails_app
  touch tmp/restart.txt
  reload_webkit
end

bind \er 'restart_rails_app >/dev/null'

posted : Thursday, July 2nd, 2009

tags :

This laptop doesn’t seem happy.

Exactly once per second it’s alternating between these two separate on-screen artefacts. The half-eaten Control Panel window is a remnant of the real window, which was closed a moment before the photo was taken.

toshiba_artefacts_1toshiba_artefacts_2

Moving the mouse or doing anything else that changes what’s actually on the screen (i.e. in the buffer, sans artefacts) causes them to flash a lot faster—it looks like once per frame.

The mouse pointer and other on-screen movement also “erases” the buffer, as shown in the first image, like dragging windows around over improperly refreshed areas of the screen did in the olden days.

It’s a Toshiba laptop running Vista.

posted : Wednesday, February 11th, 2009

tags :

I think the biggest news out of the Macworld keynote today was the announcement that the iTunes Store is now largely DRM-free, and completely so by March.

Steve Jobs wrote thoughts on music almost two years ago, which left quite an impression on me. Many were sceptical of Apple’s intent at the time, but Apple repeatedly put their money where their mouth was—first with EMI, then with several smaller labels, and today, with the lot. Top work, I say.

Conceding tiered pricing to the record companies, which Apple have been holding back on for some time, seems to be a small price to pay—especially since I imagine that the top price bracket will be occupied mostly by new releases and useless pop music.

Secondly, and this is why I think this is so important—we’re in a situation now where every major avenue you can purchase music through is DRM-free. That’s worth thinking about for a moment! CDs, the iTunes Store, and the Amazon MP3 store are all (or by the end of March, will be) totally DRM-free.

Here’s a thing: every major avenue you can purchase video through is DRM-encumbered. DVDs, Blu-Ray, Netflix, iTunes Store video.

So, what the hell? Video hasn’t caught up to audio yet? People think of video differently and will tolerate DRM? The movie industry thinks of it differently? Video is pirated more aggressively? Or maybe the left hand just doesn’t know what the right hand is doing?

I think it’s a couple of things, but I think this is a crucial difference: music has a certain permanence that movies and TV shows do not.

When I buy an album, I expect to listen to it lots of times—if I grow to truly love the album, maybe dozens or hundreds of times. But I can’t imagine watching even life changingly good movies more than a couple of times.

I’m probably biased because I live and breathe music and don’t care all that much about movies or TV (with notable exception), but I think that’s still a fairly major factor in the psychology of both the record companies and the listeners & viewers.

Whatever the reason, this is huge news. Hat tip to Apple for doing it live, hat tip to the record companies for coming to their senses, and genuflection to the artists whose music I love.

posted : Thursday, January 8th, 2009

tags :

At the Brisbane protests against the Australian Government’s proposed mandatory internet filter.

At the Brisbane protests against the Australian Government’s proposed mandatory internet filter.

posted : Saturday, December 13th, 2008

tags :

A common thing I do with git is push my changes to a remote repo, after first updating my project locally with all the changes others have pushed. But I always forget to update first, so the process usually goes—

  • push
  • rap my fingers on the table for five seconds while my laptop talks to github on the other side of the world
  • “oh crap I should have pulled first”
  • pull
  • update submodules
  • push
  • “hmm, what did I just push”
  • get a coffee (this step should have been first).

So, I made a little alias to handle it all for me, dropping in my new commits alias:

alias gitp='git pull &&
  git log ORIG_HEAD..HEAD \
    --pretty=format:"%Cblue%h%Creset %Cgreen%an%Creset %s" | cat &&
  echo &&
  git submodule update &&
  git log $(git config branch.master.remote)/master..master \
    --pretty=format:"%Cblue%h%Creset %Cgreen%an%Creset %s" | cat &&
  echo &&
  git push'

This alias pulls, lists the new commits, updates submodules, lists the commits that are about to be pushed, and then pushes them.

Since the log comes after the pull, it shows a list of the commits that were just pulled down along with a snippet of their commit message. I like this because it lets me see what everyone else has done in the last little while every time I hit the shared repo.

posted : Tuesday, December 2nd, 2008

tags :

A git merge, and hence also the merging stage of a git pull, sets ORIG_HEAD to the commit that HEAD pointed to before the merge. So the commits between these two points are the ones the most recent merge introduced.

git log ORIG_HEAD..HEAD \
  --pretty=format:"%Cblue%h%Creset %Cgreen%an%Creset %s"

posted : Tuesday, December 2nd, 2008

tags :

posted : Sunday, November 23rd, 2008

tags :

posted : Tuesday, November 4th, 2008

tags :

posted : Monday, November 3rd, 2008

tags :