Installing The MySQL Ruby Gem When Using The Official MySQL .dmg

If you installed MySQL using the official .dmg package provided by MySQL AB/Sun and are trying to install the native MySQL gem, you’ll need to pass a bunch of flags to the gem install process to get the thing to compile. Try this..

sudo gem install mysql — –with-mysql-config=/usr/local/mysql/bin/mysql_config

..if you still have issues (check your /opt/local/lib/ruby/gems/<ruby_ver>/gems/mysql-<gem_ver>/mkmf.log file), try this instead..

sudo gem install mysql — –with-mysql-dir=/usr/local/mysql –with-mysql-include=/usr/local/mysql/include/ –with-mysql-lib=/usr/local/mysql/lib/ –with-mysql-config=/usr/local/mysql/bin/mysql_config

Run `sudo gem install mysql` and definitely recheck the log file again as the gem install process sometimes reports false positives even if native components fail to install.

Debugging JavaScript With Safari

I usually use FireBug and other FireFox-based tools for troubleshooting JavaScript issues, but never found a solid way to approach it in Safari, my primary browser. It turns out that the nightly builds of WebKit (Safari’s core) also come with a great utility called Drosera.app, which allows you to attach to a running WebKit process and get funky with a JavaScript console.

w00t l00ps! drosera.png

Rails 2.0: selenium-on-rails routes.rb fix

When I updated a few projects to Rails 2.0 last year, selenium-on-rails stopped working … some issue with routing and the lame way selenium-on-rails adds its routes. I didn’t spend the time to figure out exactly what the routing problem was, but did manage to hack a quick fix into routes.rb. This feels like the Wrong Way for an ultimate fix but it at least solves the immediate problem. Shove these rules into your routes.rb and the /selenium path should start resolving again…

Continue reading Rails 2.0: selenium-on-rails routes.rb fix

Rails 2.0: Gmail SMTP With ActionMailer

Marc just checked in a nifty little Rails 2.0 plugin to the OpenRain public subversion repository which encapsulates the voodoo required to use a Gmail SMTP server with an otherwise ordinary ActionMailer configuration. Gmail requires TLS security, which is why this is useful. Grab the plugin for your Gmail-mooching Rails 2.0 site, here.

Note: I previously wrote about how to do this for Rails 1.2.x here.

Update (2008.06.25): Broken download link fixed!

 

Ruby Troubleshooting: Hpricot On OS X Leopard

If you upgraded to Leopard, you may be getting this nasty error when trying to install Hpricot, which is required by other popular gems such as mechanize..

preston$ sudo gem install mechanize
Password: ********

Bulk updating Gem source index for: http://gems.rubyforge.org
Install required dependency hpricot? [Yn]
Select which gem to install for your platform (i686-darwin8.10.3)
1. hpricot 0.6 (mswin32)
2. hpricot 0.6 (jruby)
3. hpricot 0.6 (ruby)
4. hpricot 0.5 (ruby)
5. hpricot 0.5 (mswin32)
6. Skip this gem
7. Cancel installation
> 3
Building native extensions. This could take a while…
ERROR: While executing gem … (Gem::Installer::ExtensionBuildError)
ERROR: Failed to build gem native extension.

ruby extconf.rb install mechanize
checking for main() in -lc… no
creating Makefile

make
gcc -I. -I. -I/opt/local/lib/ruby/1.8/i686-darwin8.10.3 -I. -I/opt/local/include -fno-common -O2 -fno-common -pipe -fno-common -c hpricot_scan.c
cc -dynamic -bundle -undefined suppress -flat_namespace -L/opt/local/lib -L”/opt/local/lib” -o hpricot_scan.bundle hpricot_scan.o -lruby -lpthread -ldl -lobjc
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libpthread.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libdl.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libobjc.dylib load command 9 unknown cmd field
/usr/bin/ld: /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libSystem.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0
/usr/bin/ld: /usr/lib/libSystem.B.dylib unknown flags (type) of section 6 (__TEXT,__dof_plockstat) in load command 0
collect2: ld returned 1 exit status
make: *** [hpricot_scan.bundle] Error 1

Gem files will remain installed in /opt/local/lib/ruby/gems/1.8/gems/hpricot-0.6 for inspection.
Results logged to /opt/local/lib/ruby/gems/1.8/gems/hpricot-0.6/ext/hpricot_scan/gem_make.out

The issue is that Xcode 3 must be upgraded as well; Hpricot’s native components cannot be built with the older Tiger development tools on Leopard. After installing Xcode 3 from either your Leopard DVD or Apple Developer Connection, run the install again…

preston$ sudo gem install mechanize

Install required dependency hpricot? [Yn] Y
Select which gem to install for your platform (i686-darwin8.10.3)
1. hpricot 0.6 (mswin32)
2. hpricot 0.6 (jruby)
3. hpricot 0.6 (ruby)
4. hpricot 0.5 (ruby)
5. hpricot 0.5 (mswin32)
6. Skip this gem
7. Cancel installation
> 3
Building native extensions. This could take a while…
Successfully installed mechanize-0.6.11
Successfully installed hpricot-0.6
Installing ri documentation for mechanize-0.6.11…
Installing ri documentation for hpricot-0.6…
Installing RDoc documentation for mechanize-0.6.11…
Installing RDoc documentation for hpricot-0.6…

Success!

Rails 2.0: Validations Without Extending ActiveRecord::Base

In more “enterprisey” web stacks (such as Java with Hibernate and Spring MVC), it’s straightforward to design a validatable form whose contents do not correspond directly — if at all — to a persistent OR/M class: such as may happen in an ecommerce site where you’re collecting payment information but can only store some of it in the database for legal reasons. Just create a MVC-level view object using your framework-specific validation mechanism, and translate to/from the relevant OR/M classes as necessary in the controller.

This scenario isn’t always straightforward to handle in Rails since the stack layers are smooshed together. In Rails 1.2.x, you could use (some) validations in your non-persistent PORO objects by extending ActiveRecord::Base and overriding the initializer to skip the databases-related stuff. Alas, this hack does not seem to work in Rails 2.0, but I have a solution which, in my brief testing, seems to work better than the aforementioned Rails 1.2 hack.

Here’s how I used ActiveRecord::Validations in one of my view-only classes in a Rails 2.0.2 application without needing a dummy table in the database or ActiveRecord::Base.


require 'active_record/validations'

class Card

# Define your arbitrary PORO attributes.
attr_accessor :number
attr_accessor :expiration_month
attr_accessor :expiration_year
attr_accessor :verification_value

# For the ActiveRecord::Errors object.
attr_accessor :errors

def initialize(opts = {})

# Create an Errors object, which is required by validations and to use some view methods.
@errors = ActiveRecord::Errors.new(self)

end

# Dummy stub to make validtions happy.
def save
end

# Dummy stub to make validtions happy.
def save!
end

# Dummy stub to make validtions happy.
def new_record?

false

end

# Dummy stub to make validtions happy.
def update_attribute
end

# Mix in that validation goodness!
include ActiveRecord::Validations

# Use validations.
validates_presence_of :number
validates_presence_of :expiration_month
validates_presence_of :expiration_year
validates_presence_of :verification_value

end