SunnyConf is a single-track, one day conference taking place Sept. 25th in Phoenix. There will be 8 speakers and a keynote, as well as lightning talks. There will also be time after the conference set aside for hacking. We’ve managed to pull together a great group of rubyists to share their knowledge. The speakers include:

• Jeremy Ashkenas (Keynote)
• Les Hill & Jim Remsik of HashRocket
• Charles Nutter
• Blake Mizerany
• and more!

You can find all of the date, time and location information in the widget to the right. You can also visit the official SunnyConf website or just jump straight over to Eventbrite to register for SunnyConf.

Late September is a great time to visit Phoenix! If you live nearby (e.g., Southern California, Nevada, Utah, Colorado, New Mexico, etc.) then we’re only a short drive, and an even shorter flight, away. If you’re outside of that area, we have a major international airport, and plane tickets should be pretty cheap

I encourage you to come out to Arizona in September to learn, hack and meet other rubyists. I hope to see you at the conference!

Now, try executing the following in IE:

What would you expect to be the value of link.innerHTML? Turns out that it is the same as the href value, ‘http://flatterline.com’. It seems that, on IE only, if the inner HTML of an anchor tag looks like a URL, then upon replacing the href, it will also replace the inner HTML. Try the same experiment, but with link text that does not look like a URL:

Inspecting the innerHTML value will show that it was not replaced.

This is a browser level quirk, so using a JavaScript library won’t save from this unless your library has specifically made a special case for this. I originally saw this when using jQuery and thought it might be a problem with the jQuery framework.

I think the best workaround here is that when modifying an anchor tag with JavaScript, set attributes first, then set the link text.

What do you think? Have a different workaround or solution?

I was able to track it down to the use of position: relative on these particular elements. If I added position: relative to other elements, they would also appear to be fixed. I proceed to try relative positioning on surrounding elements, but it was only at the body level that all elements behaved as they should.

Armed with these clues, I was able to find a post by Emil Stenström that documented the existence of this bug in IE6 and IE7 beta 2. He has a great explanation about how to recreate it. His suggestion was to add relative positioning to the body tag, but the real problem, as he explained, was the use of auto margin to center the body element.

Seeing as how this was an embeddable widget, I didn’t really want to have the widget affect any elements outside of itself. So I opted to advise the embedding page to add a centered div around their content and remove the centering on the body tag. This corrected the problem and, once again, all was right in the world.

Or was it?

Essentially, with honeypot captchas you add fields into public facing forms that you expect to not be filled in, then you hide them through CSS (or other means). Since spam bots don’t usually apply CSS styles, the fields are visible to them, yet styled away for normal users. And we all know how spam bots love to fill in whatever fields they find… When the form is submitted, you simply check for these honeypot captcha fields to have values. If they do, then you stop processing the request and return as if everything completed a-okay.

I used this technique on a site several years ago and meant to package it into a gem. This weekend, I finally checked that off my todo list! Now, I’d like your feedback on whether this is useful and what I can do to make it better. Feel free to fork the repository and mess with the code. If you add a feature, please send me a pull request. Thanks!

You can find the repository here: Honeypot Captcha on Github.

References

• Honeypot Captcha by Phil Haack
• Stopping spambots with hashes and honeypots

Company.find(:first, :conditions => [
  "state = :state AND name = :name AND division = :division AND created_at > :some_date",
  { :state => :approved, :name => 'Flatterline', :division => 'First', :some_date => '2009-02-27' }
])

This is also very handy when you have the same value for multiple parameters, since it will replace all matching bind variables with the value (e.g., the current time).

Event.find(:first, :conditions => [
  "state = :state AND starts_at <= :now AND ends_at >= :now",
  { :state => :active, :now => Time.zone.now }
])

References

• ActiveRecord::Base API documentation

So now, you can indicate which scenarios should pass and which are still be worked on, then run them separately if you like. Simply add some meta-data to your scenarios like this:

This will tag the scenario as a test that should work. If you have a work-in-progress, simply tag with @wip.

Read about some other ridiculously awesome cucumber and webrat features on the thoughtbot blog.

Strangely, though, Rails does not have an inflection that deals with the singularization of these words correctly. From the command line, try singularizing the word “business”:

While this seems like a contrived situation, it’s actually not as hard to hit as you’d think (e.g., common code that needs to singularize the incoming argument). I saw this while using Acl9, a role-based authorization system for Rails…

Here’s a quick fix that you can add to your config/initializers/inflections.rb:

You can read more about how this won’t be fixed in this ticket.

Here's what you do to patch Rack:

You should now be back in business. Hopefully it won't be too long before an update is released for Rack that includes the patch.

Happy uploading!

References

• Rails Ticket #2497: Rack in Rails 2.3.2 throws fatal error with small uploads
• Rack commit log: Fix multipart uploads on 1.9
• Ruby NYC: paperclip triggering a “invalid byte sequence in US-ASCII” ruby 1.9 rails 2.3

The plugin code in question had two named scopes: one for the visible objects and one for the non-visible. The system uses a timestamp to determine if an object is visible or not, so part of the conditions of these named scopes was to check if the object had been marked as not visible earlier than the current time.

So, you see the problem, right?

Since this code is contained within the plugin, it will be evaluated once in production mode, meaning that the time will remain whatever it was when the plugin was loaded. This will cause the strange behavior that we saw. By using a lambda, we can ensure that the code is evaluated every time it is run and not just once.

Note the use of double curly braces. The outer is for the lambda and the inner if for the hash. This is necessary for this code to work correctly.

Thanks to Chris Chandler for helping me to figure this out.

Have you seen similar strange behavior in your Rails plugins?