Welcome!

I’m a software professional with 10 years experience spanning the full development life cycle–especially requirements analysis and database development. I’ve worked for small startups, large corporations, and government entities. My current interest is developing web applications with Ruby on Rails and related tools (MySQL, CSS, nginx/Passenger, Capistrano, Shoulda, git).

I collaborate with graphic designers to create solutions for business owners' websites. I also support general business computing needs.

Confused by broken local gem

I’m writing a script that uses the mysql gem, and was stumped by the fact that I could instantiate a Mysql object, but could not execute certain methods on it (no such method errors). After outputting the $LOAD_PATH, I saw that the script was loading a broken gem from my local .gem directory. If I recall, the first time I did a “gem install mysql”, but did not have the ruby-dev package install, so it failed to compile. I realized at the same time I should have “sudo gem install mysql”, which installs at /var/lib/gems (on Ubuntu). I should have cleaned things up the first time around, but now I have a ~/.gem file to prevent installation of local gems.

Parsing diacritics in Ruby

I have a multi-language text file that has some characters like á, é, í, ó, ú. I need to parse it well enough to load into a database and got some results I didn’t expect:

irb(main):001:0> 'perdú'.match /\b.*\b/
=> #<MatchData "perd">

Hmm. I was really hoping for:

=> #<MatchData "perdú">

Some quick research finds that characters with diacritics are stored in two bytes rather than one, hence this behavior. This is only a problem with Ruby 1.8.7, as Ruby 1.9 handles Unicode natively. You may or may not have to set the encoding explicitly:

# encoding: utf-8

… and specify your regex explicitly:

/pattern/u

SSL, nginx, passenger

I added some personalization features to a Ruby-on-Rails site and needed SSL for logging in and changing passwords. The steps I took were:

• Install the ssl_requirement gem.
• Update the controllers to use SSL where appropriate (documented with the gem).
• Update the passenger gem.
• Run passenger’s installer.
• Use the advanced mode in order to compile nginx with the SSL module.
• Update nginx configuration to serve SSL on port 443.
• Purchase and install SSL certificate.

It was fairly painless.  Only one minor bugaboo:  You must run the passenger installer after updating the passenger gem, always.  The HelperServer in the passenger gem folder is compiled by the installer as well.  I got a bit stuck when nginx wouldn’t start right after I updated the passenger gem, but the nginx error log had a descriptive message.

Git submodules in Capistrano

So, I’d added a module to my project by cloning it from github, and when I pushed it, the folder (on my Github’s’ project page) had a green arrow indicator. This means the folder contains a submodule.

Instead of pushing the cloned files, we’re going to create a pointer to the plugin so other copies of the repo will checkout the module from its own repo. If you deploy using Capistrano, you’ll have to make a small adjustment to make sure that happens. In your Capistrano config/deploy.rb file, put:

set :git_enable_submodules, true

And in RAILS_ROOT, put this in your .gitmodules file:

[submodule "vendor/plugins/awesome_nested_set"]
	path = vendor/plugins/awesome_nested_set
	url = git://github.com/collectiveidea/awesome_nested_set.git

When you run “cap deploy”, in addition to performing a “git pull”, Capistrano will also run a “git submodule init && git submodule update && git submodule sync.”

jQueryUI Autocomplete versus auto_complete

I recently decided to upgrade the aging auto_complete plugin with jQueryUI’s Autocomplete widget.

It was mostly smooth sailing, but I had a bit of trouble getting the styling to look correct. jQueryUI was appending the Autocomplete results to the end of the html body, instead of after the text input where the user types his search query. This behavior seemed to contradict the documentation, so I submitted a bug report. It turns out this is intended behavior to account for the fact that IE does not recognize z-index, but the search results must obviously appear on top of all other page elements.

Fortunately, you can easily modify the default behavior of the search event and append it where you want it. I probably broke IE6 support, but if Google can drop it, why not?