![[image]](http://mowser.com/img?url=http%3A%2F%2Fwww.rubyonrails.org%2Fimages%2Frails.png)
Rails and MySQL
The MySQL-dump blog posted on some observed rubyisms while evaluating a large ruby application. He highlights some potential problems with ActiveRecord that may come up, such as using “SELECT *”, character sets, unsigned integers, and constraints.
Taking expirations out of caching
It’s been said that the two last hard problems in programming are naming things and expiring caches. The first is going to be hard to sidestep entirely, but what if we could the second? Tobi arrived at a eureka moment for just that using Memcached and various kinds of caching. Instead of manually expiring things, just ask for a specific version, and let the caching engine take care of dumping that which isn’t used any more.
Read more on The Secret to Memcached.
Javascriptian REST
Eric Mill went ahead and created Jester, a library that lets you manipulate your Rails-style resources with javascript models. I think it’s great that we’re seeing implementations in other languages. This python port of Routes implements map.resources, can a python port of ActiveResource be far behind?
How to get more literal URLs and still use IDs
Obie walks through the technique for getting more search engine-friendly URLs and still retain the ease of use with auto-incrementing ids.
It’s the same technique we used on the new 37signals blog engine to get urls like http://www.37signals.com/svn/posts/247-calling-all-basecamp-customers-in-nyc-or-chicago.
The 247 is what Rails see and calling-all-basecamp-customers-in-nyc-or-chicago is what Google will focus on. Have your cake and eat it too!
Using custom mime types
So, you’ve started using Rails’ new mime type support with responds_to, but you were wondering how to add your own custom types? Luckily, Geoffrey Grosenbach (aka topfunky) is there to show you the way. His example involves registering an extension for .png, and generating a custom icon for an order in his shopping cart with some RMagick-fu. His example looks something like this:
Mime::Type.register "image/png", :png
# then in your controller action
def show
respond_to do |format|
format.html { }
format.png { }
end
end
Mime::Type.register will add the image/png mime type to the collection of mime types, bind it to the .png extension. It also creates a special Mime::Type instance at Mime::PNG. Check out the great post and the comments for more tips on caching and RMagick.
Note: After some investigation, I’ve found that using Geoff’s :format hack is not required on Rails 1.2 if you make the request with the :format parameter. Using routes like formatted_post_path(@post, :xml) will give you a path like ”/posts/1.xml”. Accessing that will write public/posts/1.xml, regardless of what the page_cache_extension is.
The Rails Way on premature extraction
Koz and Jamis has posted their first article on The Rails Way covering premature extraction. It’s a great way to start off the show of Rails learnings. Since it’s so easy to abstract and extract in Ruby, it’s ever so tempting to begin doing so before you have more than one instance to triangulate the best approach with.
Make your own rescue screens on edge
Mike Naberezny has a brief tutorial on how to make your own custom rescue screens for development mode when using Rails Edge. This way you can tailor the look of the rescue screens to your current application and display application specific rescue data. Neato.
Capistrano cheat sheet
David Pettifer has created a compact Capistrano cheat sheet in PDF format. It summarizes helper methods, pre-defined variables, standard tasks, capfile syntax, standard release directory structure, and more. So go ahead, download it!
(For those arriving late to the party, Capistrano is a utility for executing commands in parallel on multiple remote hosts. You can read all about it in the Capistrano manual.)
Unobtrusive Javascript Plugin
Dan Webb and Luke Redpath have release the latest version of their Unobtrusive Javascript Plugin for Rails. It solves several of the main problems people run into when working with unobtrusive javascript:
UJS attempts to solve this by taking defined behaviors in the view and creating a tailored javascript file for it. Smart conditional GET and page caching techniques can be used to save bandwidth and time.
All in all, it looks like Dan and Luke did an excellent job on the plugin. Anyone using it? How’s it working out for everyone?
Pound makes lighty and Mongrel play nice
With the rocket rise of Mongrel, we’ve seen a growing number of folks jump ship from lighttpd to Apache 2.2 because of mod_proxy_balancer. It’s great to see that Mongrel is putting Apache back on the map as a premiere Rails web server, but unless you desire Apache for other reasons, you certainly don’t have to jump ship.
The trouble with lighttpd is the state of its mod_proxy implementation, which leaves a lot to be desired when used as a balancer between multiple Mongrel backends. But because the whole Rails deployment stack is going straight HTTP, it’s surprisingly easy to rectify. All you need is to add a more capable load balancer to the mix and you’re golden.
One such balancer that has seen a lot of play lately is Pound (OS X install notes). It’s light, fast, and proven on mega sites. So here’s what you do if want to stay with lighttpd and still use Mongrel:
And bingo, you should now have a production-ready stack ready to take on the world. This is a pretty good outline of how we at 37signals intend to use Mongrel in production shortly.
You can also take pleasure in the fact that Jan Knesche is busy at work making the Pound crutch unnecessary. Over the Summer, he has promised to elevate mod_proxy to be on par with the competition, and this three-way stack should again become a two-way one.
Tips on how to improve application efficiency
Rails performance specialist Stefan Kaes, who writes extensively about optimizing Rails over at Rails Express has a lengthy article at the new InfoQ site called A Look at Common Performance Problems in Rails.
Kaes identifies various development practices that will slow down your Rails applications, such as repeating computations that only need to be run once and then cached. If you’ve located some slowness in your application, Kaes may have already identified some of the likely culprits.
A gentle reminder about pluralizations
Watching the RSS feed from the Ruby on Rails trac is a great way to keep up on what's happening in Rails development. If you're doing any development on the Ruby on Rails project it's required reading. Even if you just are using Rails for a web app, it's useful to keep up on what bugs people are reporting.
Lately I've noticed a slew of bugs being opened against the Inflector, the class in Rails that transforms words from one form to another: singular to plural, classname to tablename, etc. The bugs all complain that Inflector is getting a pluralization or singularization wrong. But this isn't a bug in Inflector, it is just an inherent limitation of how it works. But fear not, there is a better solution than opening a bug against the Inflector.
I guess this has been a constant thing over the history of Rails, but since it's still going on, it deserves a rehash.
New in Rails: Module#alias_method_chain
Though not an outward facing feature, changeset 4276 introduces a nice method to DRY up and encapsulate the common pattern of aliasing a method so that you can build behavior on top of it.
All over the internals of Rails you’ll find code like this in a module:
module Layout #:nodoc:
def self.included(base)
base.extend(ClassMethods)
base.class_eval do
alias_method :render_with_no_layout, :render
alias_method :render, :render_with_a_layout
# ... etc
This makes it so that when the module is included into the base class, it adds behavior onto some method in that class without the method having to be aware of the fact that it’s being enhanced. In this case, the render method of ActionController::Base is enhanced to wrap its output in a layout. The new Module#alias_method_chain wraps up this pattern into a single method call. The above example, once refactored to use Module#alias_method_chain, would simply be:
alias_method_chain :render, :layout
This will be used to refactor quite a bit of Rails internals which may not be of immediate relevance to what you do, but it serves as a nice example of the mechanisms Ruby provides for software organization. Small victories.
Use params, not @params
I still frequently see people in the #rubyonrails channel using @params in their code. For a while now @params has been deprecated in favor of simply params. For those who just skim these blog posts:
Use params, not @params
Why? When you use the params method, it allows for the implementation details of the parameter hash to be changed without breaking existing code. If the implementation of params changed you wouldn’t have to change your code at all because the single point of access for the parameters would just remain the params method. So, the details of what is happening behind the scenes don’t matter. If, though, you use the @params instance variable directly, you’ve broken encapsulation and consequently the ability for the implementation to be easily modified. Methods can be refactored, but instance variables can’t. Today the params method just wraps the @params instance variable, so still using @params works, but that’s not guaranteed to always remain the case.
Same goes for request, response, session, headers, template, cookies and flash.
Basically, a good rule of thumb here is don’t use an instance variable in your controller or view unless you created that instance variable.
Even the old @content_for_layout in the layout is deprecated in favor of just using yield in its place. Also content_for('some_fragment') is now accessed with yield :some_fragment rather than @content_for_some_fragment.
Writing Domain Specific Languages
If you’ve been in the Ruby community for any time, you will likely have heard about “Domain Specific Languages”. Rails uses the concept extensively with its macro style methods for setting up associations, callbacks and validations in models, as well as layouts and filters in controllers. Indeed, Ruby provides great support for creating your own DSLs. It may have become easier to spot domain specific languages, but how does one actually implement them?
Rails core team member Jamis Buck has taken the time to guide you toward understanding the fundamental mechanisms used to create domain specific languages. Get up to speed with his tutorial, Writing Domain Specific Languages, and you’ll be creating elegant abstractions sooner rather than later. What a treat.
