43N79W.com

I recently switched from using a cluster of Mongrels on my Rails staging server to using FastCGI on Apache 2 with mod_fcgid installed. One thing that bugged me is that my dispatch.fcgi file would trigger the infamous Application Error: Rails application failed to start properly if I did not hardcode the path to my Ruby interpreter in the shebang of the script (e.g., the first line of the file appearing like: #!/opt/local/bin/ruby). I prefer to use the env program (e.g., the first line of the file appearing like #!/usr/bin/env ruby) so that my scripts are (fairly) portable across platforms where interpreters are located in different locations.

Today, I tried to resolve the situation as it was causing wasted time while testing/deploying. I finally found the solution. But not without spending a considerable amount of time heading down numerous paths toward dead ends.

I realized very quickly that the problem was that the environment variables mod_fcgid had access to, specifically $PATH, were not set to what they needed to be. So I tried a number of ways to set the $PATH only to fail several times before stumbling on the solution that should have been obvious.

The solution lies in your Apache 2 configuration. You need to add the following line wherever you happen to configure your mod_fcgid installation (I happen to include a file called httpd-fcgi.conf but most people could get away with doing this in their httpd.conf):

DefaultInitEnv PATH your path goes here

In fact, you can set any environment variable that you want your FastCGI script to have access to by using this method. I've seen several people have this shebang issue while using Ruby or Python scripts with FastCGI and there have been several workarounds posted that involve rewriting the shebang for different deployment targets. But I'd rather not do that if I don't have to. This solution works if you can modify your Apache 2 configuration and means you don't have to worry about an annoying detail like the shebang but simply get on with actual development.

I had another flat tire today. Skip to the bottom if you just need information on the lug bolts BMW uses on the 2005 MINI Cooper. Or, read ahead to hear how difficult it was for me to find this information on the Internet! Anyways, as always, the tire pressure sensor indicator lit up before I knew anything was wrong. I carefully drove into a parking lot, took out the tire pressure gauge I carry in the trunk and measured 16 psi. Note to those of you who do not regularly check your tire pressures: the tire should measure 30 psi (when cool not after being driven) and it did not visibly look flat nor even low on air.

In any event, I put on the spare tire and drove the punctured tire to Canadian Tire to have it patched. As I was in a rush and needed my car, I told them I would leave while they repaired the wheel and come back later to put it on myself. But first I would need a torque wrench and an appropriate sized socket. I would also need to know the torque specifications for the lug bolts. I used Google to search for this information, but I guess I wasn't using the correct search queries, because I came up with nothing useful.

So here's the information (torque spec according to BMW Toronto's service advisor):

Finally! I have been working on an iPhone application with the company that one of my mentor's (I hope he'll let me call him that) started. We applied to the iPhone Developer Program a while back but were not accepted into the initial batch of developers. That could have been a blessing in disguise. We have learned a thing or two from watching some of the first application developers make mistakes with pricing, execution, and simply having to deal with Apple's SDK.

So I was excited to open an email notifying me that I am now a part of the program. I will shut up now. Apple takes their NDAs seriously and so do I! Let's just say that it is time for me to kick the project into high gear and get it up for sale on the App Store as soon as it is ready.