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! 
Mad props to fellow OpenRain’r Marc Chung for an excellent AWS presentation at this months Phoenix Rails meeting. Follow-up links..
Great job, Marc!
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…
Register here. Fresh from my inbox…
We never spent a ton of time on the OpenRain homepage, so we decided to shake it up today in response to user feedback. I wanted to make our proposition clearer while keeping the existing brief one-page style, and add some awesome sauce yet stay business friendly. Check it.
As usual, a significant percentage of the development time was spent figuring out a combination of hacks to make IE6/7 render as close to “normal” as possible. Below is a screenshot of how FireFox, Safari and IE6 (from left to right) lay out the floating divs and images after a couple hours of IE-specific work. Three stupidity points are awarded to IE for the following reasons..
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!
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 Makefilemake
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 1Gem 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!
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
Here’s an easy way to validate that you’re always rendering well-formed HTML in an ordinary Rails application. I’ve written and verified this on Rails 2.0.1…
The talk I gave at yesterday’s Phoenix Rails meeting will be featured in Rubyology Podcast #48, courtesy of Chris Matthieu. Thanks for the effort and kind words! The Mugr.com demo portion at the end got cut out unfortunately, but the meat of the technical discussion is available for your listening pleasure.
Slides: Keynote PDF