Rajan Agaskar's blog
Interesting Things
- Ruby Hash is really, really, really fast
If you're building a data structure and you need it to be perfomant, Ruby Hash comes highly recommended from Steve Conover. If you're doing a dance and you need it to be awesome, I highly recommend the Robot. Or maybe the Cabbage Patch.
- Counter cache, fixtures, and invalid data
Invalid counter cache data can cause unexpected behavior. For example: size() returning a bad count or associations asserting they're empty when they aren't. In this case, the invalid counter cache data was caused by bad or missing fixture values, a situation that was not caught out by the debugger. With this in mind, it may be useful to resort to puts/p statements if you suspect the counter cache is the source of the problem.
- Count or Size methods may return incorrect values from associations or named scopes using GROUP BYs
When calling 'count', or 'size' on an association, Rails replaces the select of the actual query with a COUNT(*), and strips GROUP BY statements. This can cause the returned count to differ from the actual number of records. A simple (and expensive) workaround is to use .length, which will force the association to be loaded and then return its count. A better method is to pass a :select value to count which selects a COUNT(DISTINCT(foo)) where foo is the column you are grouping by. It is worth nothing that COUNTing DISTINCT records is much less of a performance hit then actually returning their values, so the resulting query is faster than you might expect.
- first and last on has_many associations
This has been previously mentioned in this space, but as we're on the topic of unexpected ActiveRecord behaviors, it's worth reiterating. If you have model Foo, which has many Bars, calling foo.bar.first will always go to the database. This means, for example, that the following statements will not have the expected result:
foo.bar.first.some_value = 'baz'
foo.bar.first.save
You would normally expect this to set some_value on foo.bar.first to 'baz' and then save it, but the foo.bar.first object that has some_value is blown away by the foo.bar.first.save statement, which again retrieves the first object from the database (and then saves it). last behaves in a similar manner. A workaround is to always load the results of first or last into an variable and then work with it. In other words:
my_foo = foo.bar.first
my_foo.some_value = 'baz'
my_foo.save
For a much more thorough treatment of this subject, please see Frederick Cheung's post First, foremost, and [0].
ActiveRecord::BaseWithoutTable is very handy for when you want ActiveRecord validatioons on a model that does not have a corresponding table (for example, a feedback form).
Interesting Things
- Net::HTTP is slow
Recommended alternatives: Curb, httpclient, rfuzz.
Please see Steve Conover's writeup for more details.
- Marshall Dump/Load encoding issues foiled by Base 64.
When storing to a string via marshal_dump, it can be handy to encode to Base 64 first. The same string -- once marshal-loaded and Base 64 decoded -- should be free of any encoding and/or escaping errors. Is there anything Base 64 can't do?*
* the answer I am looking for here is "win a knife fight against tigers."
Interesting Things
- Rails 2.2 Exception Notifier
Setting the Exception Notifier sender address outside the post load block in Rails 2.2 can cause long load times. Like, 6 minutes long. Why? GLOBAL WARMING! Which is to say we aren't sure, but it probably involves class pre-loading*.
* The natural corollary being, of course, that class pre-loading causes hurricanes.
Help
- Functional tests running slowly after upgrade to Rails 2.2
A project upgraded to Rails 2.2 which was previously able to complete its functional suite in under 300 seconds now takes a leisurely 6000 seconds to finish. Speculation about possible causes is welcomed. Meanwhile, I suspect ghosts.
UPDATE: apparently the functional tests were running slow due to memory swappage (the memory swappage, in turn, caused by ghosts, no doubt).
Interesting Things
- Rails 2.2 may break Selenium tests
Rails 2.2 continues its reign of terror by using 'secure' HTTP-only cookies by default that cannot be read or set via javascript. This can cause selenium tests that attempt to logout by deleting the client-side session cookie to fail. The fix is simple enough; add :session_http_only => false in the config.action_controller.session hash in environment.rb. Or, to simply turn it off for your testing environment (which means you'll still get the benefit of secure cookies in production), you can add ActionController::Base.session_options[:session_http_only] = false in your test.rb file. Alternatively, you can add explicit logout calls to your selenium tests, but expect these to add considerable time to your selenium suite.
- FixtureScenarios and slow test suites
A pivot installed FixtureScenarios on a project and found that the addition of the plugin alone (with no configured fixtures) doubled the time the project's test suites took to complete. FixtureScenarios are now dead to Adam. Dead!
- No Pivotal Breakfast tomorrow
Karen Tsui and Ling-Wen Chang tirelessly prepare the world-famous Pivotal breakfast each day and generally make the San Francisco office an awesome place to work. They're finally taking a much deserved break tomorrow, so now is a wonderful time to publicly recognize their much appreciated work. Thanks, and happy holidays!
Help
- Helper tests failing after Rails 2.2 upgrade.
A project was upgraded to run on Rails 2.2 and now has a handful of hate for helper tests. The tests in question use a stub Controller to generate a template and end up getting some nil variables. cache_classes is off. Suggestions welcome.
Interesting Things
- Pivotal Tracker Team Strength Reminder
If team members are out sick or on vacation, you can adjust your team strength settings by clicking on the blue icon at the end of the current iterations release marker. This will recalculate your current iteration velocity accordingly.
- 'flash' Partials
It is bad form to name your partials 'flash', because they attempt to populate a flash variable which has the nasty side effect of blowing away your notification array. Naming a partial 'phlash' produces no adverse effects outside of looking a little silly. 'shazzam' and 'booyakkasha' are also acceptable although somewhat less descriptive.
- Capistrano and Git
A default deploy with capistrano and git appears to prefer using the local working set instead of the configured repo (in this case, github). This may end up surprising you a great deal if you do a deploy from a machine that isn't an exact copy of HEAD. It was suggested that best practice is to deploy tags from a dedicated CI box rather than a development workstation.
- Ruby On Rails Noteworthy Applications
http://rubyonrails.org has a new design, and with it came a page of noteworthy apps running RoR. Are you a Pivotal client who'd like to see your site up there? Get in touch!