Seth Ladd's Blog

I am currently building a web application that makes heavy use of wizards and forms built with Ext JS . I am sending the form's values as JSON over to a Ruby on Rails server. Thanks to Rails 2.2.2, the JSON is automatically converted into an parameter hash. For a little background to the problem I am about to describe, HTML checkboxes are notoriously difficult to work with, because if the user does *not* check the box, then the browser will not send a value when the form is submitted. This makes it difficult to handle a state change from checked to unchecked. Rails makes this a bit easier because it will render both a hidden field with a value of "off" as well as the original checkbox. If the user checks the box, both values are sent but Rails will use the value from the checkbox (and not the hidden field). If the user does not check a box, only the hidden field's value is sent, which means the "off" value is sent. However, when using Ext JS to r

For the impatient: Go install the fast_xs gem if you use Builder in Rails. The long story: I was using New Relic RPM to watch Errorlytics , and noticed everything was humming along just fine, except... the Atom feed of new 404 errors was taking an extremely long time. Request times of 800ms were not uncommon. RPM told me that the view rendering was taking most of the time, which made sense because I had already ensured that all the queries were by index. Errorlytics uses the Atom Builder to construct the Atom feed, and generally I like it. However, I had my doubts after learning it was the bottleneck, and I was hoping I wouldn't have to rip it out and write the XML by hand. After a bit of Googling around, I was lucky enough to run across Speed up your feed generation in Rails . This post details the same issue, in that the Builder had some major performance issues. Thankfully, the author of that post did all the hard work. They learned that installing the fast_xs gem is the