CRAZ8

Lisa and I are members of a team of people that do Microsoft Puzzlehunt whenever it comes around (a little more frequently that once a year). Over the weekend we did Puzzlehunt 9. This year, we were 31st out of 62 teams.

We seem to be solving about the same number of puzzles every year, but we keep slipping back in the overall classification. Every other team seems to be getting better!

This time, we ate too much bad food, stayed up way too late, and tried to work on complex things without enough sleep.

We did have a good time!

I have a Rails app that uses lighttpd. My app has a bunch of routes setup to handle incoming requests. Lighttpd has a set of re-write rules to convert the incoming request into calls into dispatch.fcgi. This is the default configuration.

One thing that hadn’t been made very clear to me until I went looking for it is that the lighttpd re-write rules are no longer necessary.

To get the requests into my Rails app, all I need to do is define dispatch.fcgi as my 404 handler, and any request that doesn’t exist in the file system will be handled by my Rails app.

This is fully documented here but as I said, it wasn’t obvious to me until I needed to fix it!

We have a medium size Big Green Egg Currently, it contains about 10lbs of pork butt, smoking at about 250F (a little warm, but I’m working on it). After about 16-18 hours, this cheap piece of meat will be fantasic!

With a little of Lisa’s BBQ sauce, this is a food item that people fight over at our parties.

The Big Green Egg makes this process very easy. The thing lights up really easily, retains heat really well and will go at 200-250F on a single load of charcoal for 14-18 hours. Its almost foolproof.

My development environment is Windows. My production environment will be some form of Linux. I have a Debian server setup to test production issues. I have started playing with SwitchTower to deploy my production environment.

Once I’d set the whole thing up, SwitchTower almost worked first time. I eventually found the two reasons it didn’t work first time:

• The dispatch.fcgi file was not marked executable when checked out of subversion
• The dispatch.fcgi file needed to be editted and saved on the Debian system before lighttpd would run the file. It turns out that the end-of-line character is important for executable script files.

So, how to solve this? A quick search through the subversion documentation found two items:

• svn:executable – sets the file to executable on those file systems that support it.
• svn:eol-style – value of native tells subversion to use the appropriate end-of-line characters for the current OS.

Adding these two properties to my Rails scripts (dispatch.fcgi and everything in the script directory) and all is well with my SwitchTower processing.

I spent a bunch of time getting some code running on a Debian configuration last night. Mostly, the instructions from the bougy man are pretty good, but I ran into a few issues that weren’t covered there.

1. Debian Ruby package seems to suck. It looks like this is common knowledge, but still a pain. I had to build the Ruby code from scratch. Source downloads can be got from ruby-lang.org

2. You need to build FastCGI. This code can be got from fastcgi.com

3. The gems code is now up at version 0.8.11, so substitute those numbers in the RailsOnDebian instructions to get the latest.

4. The GEM for FastCGI may not be correct. You may need to build this yourself. I had another problem, so I may not have needed to do this.

5. My development environment is Windows. So when Rails generated my code, the script thing at the top of all the script files was generated as #c:/ruby…. which clearly won’t work on any form of Unix system. It took me 4 hours to work out that the reason mod_fastcgi in lighttpd was reporting ‘no such file or directory’ on my dispatch.fcgi file was not because it couldn’t find dispatch.fcgi, but because the first line was *#c:/ruby….”. Once I fixed this, all was well in my world once again.

Now I’m going to try to get SwitchTower running on this configuration.

I was reading this article on The Post Money Value blog, when I saw a link to Ask Leo.

Strangly, I purchased a house from Leo and his wife back in 1997.

The common measure of the size of the trunk of a car is the golf bag – how many golf bags can fit in the trunk.

If you’re from a certain group of people, your common measurement may be – how many bodies can you fit?

At a recent party, someone wanted to know how big the Z8 trunk is. Since we didn’t have any golf bags available, we used the second form of measurement.

I’ve changed my sidebar and my Typo theme (the old one sucked on IE 6), but I can’t get Typo to display the newly updated home page correctly, even after manually clearing the cache files from the disk.

Weird. Perhaps this new post will cause the home page to update correctly?

Resolved – Typo generates static files for caching purposes. I’d cleared out the public/articles directory, but I missed the public/index.html file. There is a bug here still, since adding a new article should have caused that file to be re-generated.

I’m running Damage Control 0.5.0.1404 This code has some stubbed out code that can be used to have a build update your Ambient Orb when the build is complete.

Since I have my fancy new ambient project on rubyforge, I decided to flesh out this stub code to update my orb on build completion.

This code replaces the content of the ambient_orb.rb file in the lib/damagecontrol/publisher directory:

require 'damagecontrol/publisher/base'
require 'ambient'

module DamageControl
  module Publisher
    class AmbientOrb < Base
      register self
      attr_accessor :enabled

      ann :description => "Ambient Orb ID"
      attr_accessor :orb_id

      def initialize
        @orb_id = ""
      end

      def name
        "Ambient Orb"
      end    

      def publish(build)
          color = :green
          color = :red if build.status_message == 'Failed'
          Log.info("Set Orb #{@orb_id} to #{color}")

      begin
          Ambient::Orb.new(:id => @orb_id,  :color => color).update 
      rescue 
          Log.warn("Error updating Ambient Orb")
      end
      end
    end
  end
end

The file can be downloaded from here: ambient_orb.rb

The Problem:

I’m setting up a Damage Control server to run tests for my Rails app when the code gets checked in. The default rake task causes the test database to be cloned from the development database. My Damage Control server has no development database, so the whole thing is broken.

Searching the web, this problem is mentioned on Patrick Lenz’s blog but I can find nothing on how to make this work.

Delving into the Rails tasks, the simplest hook place I can see is in the :clone_structure_to_test and :clone_schema_to_test tasks. Each of these has a pre-requisite to perform a dump of the development database before loading that dump file into the test database. If only I could stop the dump from taking place, and use the checked in schema files, my problem would be solved.

It seems that Rake doesn’t have methods to remove pre-requisites from an existing task. Luckily, in ruby-land, I can re-open the required class and add that functionality!

module Rake
  class Task
    def remove_prerequisite(task_name)
      name = task_name.to_s
      @prerequisites.delete(name)
    end
  end
end

To ensure that the rake command (with no parameters) still works on my dev machines, I leave the default task alone and add a new one called dc_build. I’ll tell my Damage Control server to use the command ‘rake dc_build’ and all will be well.

Here’s my dc_build task:

desc "DamageControl build task"
task :dc_build do

  # For the DC build, adjust the pre-requisites to stop the development db dump
  Rake::Task.lookup(:clone_structure_to_test).remove_prerequisite(:db_structure_dump)
  Rake::Task.lookup(:clone_schema_to_test).remove_prerequisite(:db_schema_dump)

  Rake::Task[:default].invoke
end

I put this all in a file called dc.rake in my lib/tasks directory and now I can run my Damage Control without needing a development database.