Pearware Blog : Archives for August 2006

Offsetting flight emissions

Sun, 20 Aug 2006 13:48:00 -0500

I’m flying back to Phoenix today, as part of my telecommuting agreement. Due to the fact that I’ll be flying frequently, I feel that I should do something to balance the impact on the environment of my flights. Flying burns a lot of fuel, and flying from Columbus, OH to Phoenix, AZ is certainly no exception. So, today, I’m purchasing a Flight TerraPass to offset the carbon emissions of my flights.

Ahh, the easy life

Mon, 14 Aug 2006 13:46:00 -0500

This is what my dog does while I work all day…

Error working with large YAML files

Sun, 13 Aug 2006 13:34:00 -0500

As part of my Application migration project, I need to pre-populate the new database with zip code data. The Rails Recipes book (very useful) has a nice recipe on extracting fixtures from live data. So, I’ve created a zips.yml file that contains all the zip code data that I can insert into the new database. However, when I try to load the fixture using this very cool rake task from Technoweenie, the YAML library throws the following exception: SystemStackError: stack level too deep.

It is possible to work-around the error by increasing the stack limit on the command-line. on Mac OSX (and probably Linux/Unix), the following command can be run before running the rake task: ulimit -s 32768. This increases the default stack limit to 32MB, which should be enough, unless the yaml file is really large, I suppose.

Does anyone know if somebody is working on fixing the YAML library to be nicer to the stack?

Rails Migrations - Dropping default constraint on column

Sun, 13 Aug 2006 13:31:00 -0500

I’m working on a project for a client to convert a website from PHP to Ruby on Rails. The database is also changing from Microsoft SQL Server to MySQL, along with several schema redesigns.

One thing I wanted to do to our new db, was change a foreign key column from NOT NULL DEFAULT 0 to allow nulls and remove the default. Currently, the organizations table has a record with ID = 0 to signify a blank organization. Users that do not belong to an organization, have a foreign key to that Zero-record. Well, a better way to represent that is for the foreign key column in users to simply be NULL and ditch the Zero-record in the organizations table.

I have created a Migration class to handle the schema change. However, it looks like I have to drop to SQL as there is not Migration way of doing this. Here’s what it looks like:

    execute 'ALTER TABLE users ALTER organization_id DROP DEFAULT'

I wanted to be able to handle this in the Migration-syntax, but I don’t think that’s possible. It would be nice to do something like:

    change_column :users, :organization_id, :integer, :default => :null, :null => true

Cool Google Maps flight simulator

Sun, 06 Aug 2006 13:07:00 -0500

Now this is a pretty cool idea!

Go There!

Rails redeploy issue resolved

Sun, 06 Aug 2006 11:25:00 -0500

I just redeployed a rails site for a client of mine, Real Idaho, using Capistrano and it didn’t work properly. I was able to resolve the issue, and here are the details in case this ever happens to you…

Running

$ rake deploy

gave the following output (some content suppressed):

...
transaction: commit
  * executing task restart
  * executing "/home/*****/apps/*****/current/script/process/reaper -d 'dispatch.fcgi'" 
    servers: ["216.118.83.207"]
    [216.118.83.207] executing command
 ** [out :: 216.118.83.207] bash: /home/*****/apps/*****/current/script/process/reaper: Permission denied
    command finished
rake aborted!
command "/home/******/apps/******/current/script/process/reaper -d 'dispatch.fcgi'" failed on 216.***.***.***

The problem is that the files in script/ and the dispatch.* files in public need to be executable, but when Capistrano pulls down the latest subversion code, it defaults those files to the permissions:

-rw-r--r--

which is just read/write.

In order to have subversion pull down the files with the correct, executable, permissions, you must run the following command on each executable file and commit them to subversion:

$ svn propset svn:executable

I found the following article, Subversion Primer for Rails projects, which has a nice script to automate the task of setting the necessary files as executable. Here’s the script:

$ svn propset svn:executable "*" `find script -type f | grep -v '.svn'` public/dispatch.*

Then, run

$ svn commit

to commit those changes to Subversion.

I think this should resolve the issue, but I haven’t redeployed yet, so I haven’t verified that this will really fix my deployment issue.

Solar Wi-Fi To Bring Net to Developing Countries

Fri, 04 Aug 2006 11:24:00 -0500

I think this is a very cool idea and one I am very glad to see happening. I really think efforts like this can be worldchanging, and do a lot to help people, especially children, in the developing world to have more opportunities. The project is Green WiFi and is founded by Bruce Baikie, former manager of strategic marketing and solutions for the telecommunications industry at Sun Microsystems, and Marc Pomerleau, currently a member of Sun Microsystem’s identity management marketing team. According to their site:

“GREEN-WiFi strives to apply smart, sustainable, communications technologies to help bridge the digital divide for children in the developing world. A solar-powered Wi-Fi grid network solution can be part of the answer.”

Here’s a link to the story on Slashdot.

Is your site really Web 2.0?

Thu, 03 Aug 2006 11:07:00 -0500

Now you can run your website through a handy-dandy Web 2.0 validator, to see if it really is Web 2.0. This site was put together by 30 Second Rule, a website design and development company in Phoenix that is active in the Ruby community. My blog’s score should be upped by writing this article! :)

Go to the Web 2.0 Validator