jovoto development blog

In my spare time, I listen to a whole slew of netcasts. When I am at home, I listen to these on my Crapbook, so I can use a handly little piece of Applescript whipped up by Randal Schwartz that passes the current track from iTunes to QuickTime, adjusting the playback speed to 1.5 times the normal speed.

I found netcasts to be a very pleasant distraction from the horrible music usually played at the gym. Unfortunately my portable MP3 player doesn't let me adjust the playback speed, so I need to adjust it in the MP3 files themselves. The following script does just that.

require 'rubygems'
require 'rbosa'

RATIO = 1.5
target_dir = "/tmp/#{$0}/#{Time.now}"
`mkdir -p "#{target_dir}"`
iTunes = OSA.app('iTunes')
iTunes.selection.each {|track| `cp "#{track.location}" "#{target_dir}"`}
%x(
  cd "#{target_dir}"
  for f in *
  do sox -t mp3 "$f" "$f.wav" tempo #{RATIO}
  lame "$f.wav" "$f@#{RATIO}.mp3"
  rm "$f" "$f.wav"
  done
  open .
)

First I select the tracks I want to convert in iTunes, then I invoke this script. When applied to 10 or more tracks, the processing done by sox and lame can easily take a few minutes, so I added the call to open ., which opens a Finder window with the converted files as soon as everything is done, so I can grab them and move them to my MP3 player.

When a program tells me that there is a new version available, I usually get that new version and put it on a shared directory on our file server, so anyone else can take it from there, enjoy a quicker install and save some precious bandwidth. Recently I fired up VirtualBox on a box that I didn't use for a while, so it complained about being outdated.

What bugs me about these situations is that downloading a package like VirtualBox takes a few minutes and that's, at least in my opinion, a pretty annoying time span. It's not enough to reasonably do anything else, but enough to think about how to get rid of these breaks. This time I used these few minutes to come up with an idea, which resulted in the following piece of Ruby.

require 'open-uri'

TARGET = '/some/place/to/store/the/files'
packages = {
  :virtual_box => lambda do
    latest = open('http://download.virtualbox.org/virtualbox/LATEST.TXT').read.chomp
    index = open("http://download.virtualbox.org/virtualbox/#{latest}").read
    index.
      scan(/VirtualBox.+?OSX.dmg|virtualbox.+?Ubuntu_jaunty_i386.deb/).
      uniq.select {|filename| !File.exists? "#{TARGET}/#{filename}"}.
      map {|filename| "http://download.virtualbox.org/virtualbox/#{latest}/#{filename}"}
  end,
  :firefox => lambda do
    %w(mac win32).map do |platform|
      %w(2.0 3.0 3.5).map do |series|
        index = `lynx -dump ftp://ftp.mozilla.org/pub/firefox/releases/latest-#{series}/#{platform}/en-US/`
        index.
          scan(/Firefox .+?(?:exe|dmg)/).
          uniq.select {|filename| !File.exists? "#{TARGET}/#{filename}"}.
          map {|filename| "ftp://ftp.mozilla.org/pub/firefox/releases/latest-#{series}/#{platform}/en-US/#{filename}"}
      end
    end.flatten
  end
}

packages.each do |name, url_fetcher|
  puts "fetching urls for '#{name}'"
  url_fetcher.call.each do |url|
    `wget -P #{TARGET} '#{url}'`
  end
end

Writing the code to fetch VirtualBox was too easy to stop there, so I added a block for Firefox. mozilla.org didn't respond to open, so I lynxed instead. I put this script on our file server, pointed TARGET to the directory we usually put setup files in and created a cronjob to run it once every night. So whenever I need the latest version of VirtualBox or Firefox, there's a good chance it's already in local network range.

I recently noticed something a bit weird when looking at the output of git log. There were a bunch of commits with the same commit message in a short period of time. My team mate's idea was to change something on the staging server, sitting together with a non-developer, trying to find the right way to display something. As he didn't have a dump of the staging server's database up-to-date enough for his purposes, he found a commit-push-deploy-loop to be the easiest way to go. Modifying the files directly on the server might have been an option, but that requires a login to that box, which isn't always what you want.

A brief look at cap -T reveals that Capistrano is capable of just what's needed in that case. cap deploy:upload lets you move your local versions of some files to the remote side. No need to commit, let alone deploy.