If you’ve tried to use Machinist and autotest (part of ZenTest) you have probably seen this exception that prevented you from using it:
`method_missing': No sham defined for name
It’s discussed in the machinist Google Group as well.
It’s because of a wacky hack that’s part of Machinist that overrides Module.name so you can do
Sham.name, but ZenTest expects Module.name to do what it does normally.
I have a fix for this.
Continue reading “How to make Machinist and Autotest coexist”
Migrations are one of the best features of Rails. Although some folks prefer pure SQL rather than Rails migration DSL, I don’t know of anyone who dislikes the idea of a versioned schema that can evolve in a controlled and repeatable fashion.
But because the concept of database migrations is such a powerful one, it’s tempting to jam any old change that affects the database into a new migration and run
rake db:migrate to make it happen. I’ve been guilty of a bit of this in the past, and I’ve joined some projects that did other ugly things in migrations. In the process I’ve learned the hard way that there are some things you must never do in a migration or they will come back to haunt you later. Here they are.
Continue reading “Rails Migration Antipatterns and How To Fix Them”
Nokogiri on a standard installation of Leopard is complain-y about a couple of old libraries:
“HI. You’re using libxml2 version 2.6.16 which is over 4 years old and has plenty of bugs. We suggest that for maximum HTML/XML parsing pleasure, you upgrade your version of libxml2 and re-install nokogiri. If you like using libxml2 version 2.6.16, but don’t like this warning, please define the constant I_KNOW_I_AM_USING_AN_OLD_AND_BUGGY_VERSION_OF_LIBXML2 before requring nokogiri.”
Aaron Kalin figured out how to fix this if you’re installing nokogiri as a system gem, but I want to use Bundler and keep my system gems down to the bare minimum. I figured out how to do this under Bundler 0.8.5.
Continue reading “Making Bundler 0.8.5 install Nokogiri on Leopard with a newish libxml”
Rails provides some flexible and fairly short controller methods for responding with an HTTP error code. Given that controllers are complicated enough by nature, I’m always looking for ways to DRY them up and make the code easy to understand. So here are some controller methods that make it really easy to provide correct HTTP error responses to clients.
Continue reading “Tidier HTTP error responses in Rails controllers”
Rails controllers can get out of hand if you’re not very careful. Skinny Controller Fat Model is a great start. But what about handling errors? Isn’t it enough to just let Rails catch your exception and show a 500 Server Error page?
No, it’s not. Falling back on 500 Server Error for everything outside of the “happy path” through your code is sloppy coding.
Continue reading “Proper Error Handling in Rails Controllers”