This also looks like the death of the “I’m feeling lucky” button. I never thought about it, but it cost Google quite a bit of advertising revenue—$110 million according to a 2007 Marketplace interview.

The weather was perfectly clear and uncharacteristically calm and I got the chance to take some long exposures of the stars (I’ve been wanting to do that for so long!). A few actually turned out decent:

Facing south; Milky Way visible through the center of the sky

South again at a wider-angle; Jupiter is that bright spot above the cabin

Looking north over Lake Traverse; light pollution from a small town

We spent a lot of time looking through Jeff’s telescope and imagers (I’m really fighting the urge to go out an buy one!). It was so dark and clear the Alex was even able to pick out the Andromeda galaxy with his naked eye. I really hope to return soon and do some more exploring.

Photos in this post © Christian Dinger—all rights reserved.

• Green Day - Know Your Enemy
• Green Day - Horseshoes and Handgrenades
• U2 - I’ll Go Crazy If I Don’t Go Crazy Tonight
• Bob Dylan - It’s All Good
• Bob Dylan - Beyond Here Lies Nothin’
• Iron and Wine - Love Vigilantes
• Discovery - Orange Shirt

Ahh…

I should point out that these scripts assume you’re running Mac OS X 10.5 with Developer Tools installed. Both scripts use the osx/cocoa library to interact with iTunes.

veto

the veto script pulls the track title that iTunes is currently streaming and appends it to ~/.itunes_vetoes_songs.

#!/usr/bin/env ruby -w

require 'osx/cocoa'
include OSX
OSX.require_framework 'ScriptingBridge'

itunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")
`echo "#{itunes.currentStreamTitle}" >> ~/.itunes_vetoed_songs`

veto_watcher

veto_watcher runs in the background and looks for vetoes songs to appear the iTunes stream. When they do, it turns down the volume and spares your ears. When the vetoed track is done, the volume goes back up. Note: this should return the volume to it’s previous setting, but the instance variable kept breaking, so it just goes back up to 100% — careful!

#!/usr/bin/env ruby -w

# start a new thread
pid = fork do

  require 'osx/cocoa'
  include OSX
  OSX.require_framework 'ScriptingBridge'

  @itunes = SBApplication.applicationWithBundleIdentifier_("com.apple.iTunes")

  def itunes_is_running?
    return !`ps -A -o comm | grep iTunes.app`.empty?
  end

  def mute
    @itunes.soundVolume = 0 if @itunes.soundVolume > 0
  end

  def unmute
    @itunes.soundVolume = 100 if @itunes.soundVolume == 0
  end

  def check_for_veto
    vetoes = `cat ~/.itunes_vetoed_songs`.split("\n")

    if vetoes.index(@itunes.currentStreamTitle)
      mute
    elsif @itunes.soundVolume == 0
      unmute
    end
  end

  # main loop: check for a veto every 5 seconds
  loop do
    check_for_veto if itunes_is_running?
    sleep(5)
  end

end

Process.detach(pid)

I have the veto_watcher script start up when I log in and I’ve set up a Quicksilver trigger to run the veto script. What’s up now, Bono?

Our team recently launched a large website in Drupal that uses many home-grown modules. I discovered that with certain modules, the execution order is very important; especially authentication modules. We’d developed a module that interacts with the University’s single sign-on service and automatically creates or loads a Drupal user.

Order matters

Everything worked perfectly in testing except 403 handling. Specifically, when an unauthenticated user encounters a page that requires authentication or a certain role (via the privacy by role module), the user would expect to be routed to the single sign-on form, authenticate, and then be returned to the resource they originally requested. This wasn’t happening. The user would click a protected link, login, and then encounter the default 403 page: ‘Access Denied.’ The giveaway was that if you refreshed the page, the protected page would appear. After hours of debugging, I discovered that it was indeed the execution order. Our authentication module was being executed after the node load.

System.weight

Some Googling revealed the nearly undocumented ‘weight’ column in the system table. This column allows you to control the order/priority in which modules are executed. Most module will default to 0. To increase the priority, decrease the weight; to decrease the priority, increase the weight. With 90% of our modules at 0, and, assuming that we’d always want authentication to run first (even before the Node module), we set its weight to -1. This caused the authentication to fire before the node load and successfully load the requested page.

Have you seen this error in your Rails application? Do you hate it as much as I do? I’ve spent the past two days troubleshooting this and I finally found a solution. It’s ugly and hacky, but it appears to be working.

There are actually quite a few posts out there regarding this error and they all get down to the root problem: the LD_LIBRARY_PATH environment variable is not available to the Apache user (www-data in this case). Most solutions I’ve found involve setting this variable in /etc/bash.bashrc or /etc/profile to make the variable available to all users. This fixed part of the problem for me, but it was still failing when executed from Apache via Passenger.

The “solution”

The hacktastic solution was to modify the /etc/init.d/apache2 startup script and explicitly set the LD_LIBRARY_PATH variable when Apache is started. Specifically, change

ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin"

to

ENV="env -i LANG=C PATH=/usr/local/bin:/usr/bin:/bin LD_LIBRARY_PATH=/opt/oracle/instantclient"

Note that this solution assumes you’re using the Oracle InstantClient; if you’re using the full Oracle client, you may try setting the ORACLE_HOME path instead of LD_LIBRARY_PATH.

I hope this helps somebody!

I created www.kamuskecil.com today during lunch as I ate last night’s leftovers in my cube. It’s a stupid-simple, no-frills Indonesian-English dictionary. I’ve been sitting on this data for years now and once had a grand vision for it, but let’s face it; it’s just a dictionary. And, I really only expect one user — myself. So if you ever need to know the definition of kamus, give it a try.

Because git’s built-in hooks system is only available client-side, this is set to run via a cron task. One could implement some sort of push system pretty easily with client-side hooks, but the hook scripts would have to be distributed to each of the developers. That seems like a pain. This script is meant to be executed on the server that holds your git repositories.

gitrss.rb

gitrss.rb takes one argument: the path to the repository.

repository_path = $*[0]

git_history = `cd #{repository_path} && git log --max-count=10 --name-status`
entries = git_history.split("\ncommit ")

rss = "<?xml version="1.0" encoding="UTF-8" ?>
  <rss version="2.0">

  <channel>
  <title>your_repository commits</title>
  <description>Git commits to your_repository</description>
  <link>http://example.com/your_respository.xml</link>
  <lastBuildDate>#{Time.now}</lastBuildDate>
  <pubDate>#{Time.now}</pubDate>
"

entries.each do |entry|
  guid = entry.gsub(/^.*commit /ms, '').gsub(/\n.*$/ms, '')
  author_name = entry.gsub(/^.*Author: /ms, '').gsub(/ <.*$/ms, '')
  date = entry.gsub(/^.*Date: +/ms, '').gsub(/\n.*$/ms, '')
  comments = entry.gsub(/^.*Date[^\n]*/ms, '')

  rss += "
    <item>
      <title>Commit by #{author_name}</title>
      <description>#{author_name} made a commit on #{date}</description>
      <content><![CDATA[
        <h2>#{author_name}</h2>
        <p>#{date}</p>
        <pre>#{comments}</pre>
      ]]></content>
      <link></link>
      <guid isPermaLink="false">#{guid}</guid>
      <pubDate>#{date}</pubDate>
    </item>"
end 

rss += "
  </channel>
</rss>"

puts rss

cron

The gitrss.rb script only outputs the RSS XML; we’ll have to redirect the output in cron. Here’s an example cron task that runs this every 30 minutes:

*/30 * * * * root ruby /var/git/gitrss.rb /var/git/your_repository.git > /var/www/your_repository.xml

This cron task will run the gitrss.rb script every 30 minutes and redirect its output to a file called your_repository.xml

This year our team name was “Don’t forget the pickles”. I’m sure it means something to someone. I liked the name we used last year, “The science of winning”. Much cockier.

This year was another victory (fourth consecutive year!). We trailed in fourth place until the last 30 minutes and finally won in a lightning round tie breaker. Good times.

My ‘sconny friends: team “Don’t forget the pickles”; 14 Mar 2009.