zerosum dirt(nap)

Starting this blog entry to document any possible gotchas I experience on my upgrade to OS X 10.5. So far everything has been relatively clean. My only problem as of this writing has been with SSH and MacPorts. I have SSH installed via MacPorts and I noticed when doing any SVN+SSH operations, I was getting the following error:

percent_expand: NULL replacement
svn: Connection closed unexpectedly

Hmm, looks like Leopard is expanding some SSH environmental variable to NULL. An easy fix is to add the following line to your ~/.ssh/config:

IdentityFile ~/.ssh/id_rsa

This overrides the default search for your private key, and therefore you don’t get the percent_expand error. If anyone has more information about this particular issue, please let me know. Thanks!

• FreeBSD 7.0 is is going to own scaling. Srsly. RC1 should be available this week.
• Rails 2.0 RC1 is here. Have you fixed those deprecation warnings in 1.2.5 yet?
• Heroku is coming next week. Holy crap those screencasts are cool. So the future of building and hosting webapps looks a lot like Seaside, eh?
• More Heroku coverage and commentary by Giles Bowkett.
• The Great Merb Speedup. Keep your eyes peeled for 0.4.1, things in this camp keep getting better and better.
• Interesting critique of OpenSocial from Tim O'Reilly.
• Google's OpenSocial API Blog, because it's the new hotness.
• Using OpenSocial with Ruby on Rails, because hey, you're curious, right?

If you ever need to drop a pid from a Ruby process it’s dead simple:

File.open('myapp.pid', 'w') { |f| f.write(Process.pid) }

Now you can use Monit to keep Sinatra alive, for instance ;-). Monit is great for monitoring UN*X processes and keeping them running under ideal conditions, and that means it’s great for Mongrel, and anything that runs through Mongrel. Monit can even check the memory consumption of your application and restart it if it seems to be leaking. Not that that ever happens, of course.

Any post about Git pretty much mandates the use of some lame pun in the title, and this blog entry is no exception. For those of you who are as-of-yet unfamiliar with it, Git is a distributed version control system created by Linus Torvalds. It's been around and usable for about a year now, but I'd only been peripherally aware of it until recently.

In the past I've just used it to check out and occaisionally toy with the latest Rubinius sources but now that the Offtrac project is using it, it finally looks like I'm going to have to start familiarizing myself with it beyond installation and cloning a remote repository. If that sounds negative it isn't meant to be; I enjoy being forced to learn new things every once in a while. Srsly.

[To be honest I'm still relatively happy with Subversion, but hey, when I started using Subversion I was still at least relatively happy with CVS too. No wait, scratch that, I hated CVS.]

Anyway, for those of you out there like me who are just getting acquainted with Git and particularly those who are stumbling over the implications of the distributed part of distributed version control, Carl Worth has written a useful getting started guide that you should definitely check out. Of course there's the official user guide too.

In practice, normal usage really isn't as different as it seems, and the concept of a distributed repository is a truly powerful one. Everyone has commit access to their own local branch, which means most operations are fast, and the centralized who-gets-commit-rights question becomes a total non-issue. That's very very cool. Oh, and no .svn folders littered in every folder is another nicety. The jury's still out for me as of right now, which is to say I'm not rushing to switch all my existing Subversion projects over just yet. But I have to say, I'm very intrigued so far.

So a few months back I started using nginx on my staging server, front-ending for Mongrel, and just recently I've stated migrating some production stuff over to it. It's pretty great as a lightweight Apache replacement. Incredibly simple syntax, very quick and close to the bone. Most of my production stuff still runs on Apache, but that may soon be changing. I also finally made the leap to Capistrano 2.0. Loving the new namespaced task hierarchy.

Anyway, here's a simple alternative maintenance page recipe for Capistrano's deploy:web:disable target and the corresponding Nginx config to make use of it. In case you're unfamiliar with it, the disable web task basically redirects all requests to a maintenance page until deploy:web:enable is run, which returns things to normal. This recipe assumes you've created your own (static) maintenance.html page in public/maintenance.html and that it makes use of existing stylesheets and images -- meaning that you don't want to rewrite those requests.

in config/deploy.rb:

namespace :deploy do
  desc "Disable requests to the app, show maintenance page"
  web.task :disable, :roles => :web do
    run "cp #{current_path}/public/maintenance.html  #{shared_path}/system/maintenance.html"
  end

  desc "Re-enable the web server by deleting any maintenance file"
  web.task :enable, :roles => :web do
    run "rm #{shared_path}/system/maintenance.html"
  end
end

in nginx.conf (within your server block definition):

# allow requests for images, js, css, and icons to go through
# even if cap has been used to disable the site
if ($request_filename ~* /(images|javascripts|stylehseets)/) { break; }
if ($request_filename ~* .ico$) { break; }

# for cap's deploy:web:disable task
if (-f $document_root/system/maintenance.html) {
    rewrite ^(.*)$ /system/maintenance.html last;
    break;
}

FreeBSD 6.2 was released this morning. Lots of bugfixes and new features, including official support for binary updates with freebsd-update. Cvsup away!