Reboot 8 is happening on June 1st and 2nd in Copenhagen and the conference is looking for a handful of cool demos to play part in the conference. The organizers have asked me to encourage the Rails community to participate. So if you have a cool application, commercial or open source, that you’d like to show to the world, checkout the Demo page on the Reboot wiki.
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
ActionController::Baseis enhanced to wrap its output in a layout.
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.
You can get more details and signup to be notified when it is available at the Rails In a Nushell site.
The Signal vs Noise Job Board is a new alternative for finding good programmers and designers to work on Rails projects (among other things). It puts your job pitch in front of the tens of thousands of people reading the Signal vs Noise weblog. It comes at a price of $250 for a posting of 500 words visible for 30 days.
CNET, Fleck, and NYTimes.com are all using it to advertise developers with Ruby and Rails experience. If you’re just looking for programming positions, you can subscribe to the RSS for the programming section.
As you might have noticed from the URLs, this job site is using the new Simply Restful plugin. Our playground for RESTful living on Rails.
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:
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
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
The first is a one day course in New York City on April 29th taught by Matt Pelletier and Francis Hwang, the founder of the NYC Ruby user group, humanist and author of, among other things, Lafcadio and MockFS. Francis has been building websites in Ruby for over 4 years now. Up until recently he was the primary developer for http://rhizome.org/. You can sign up here for $395.
For those on the other side of the pond, they are also offering a three day course in London , May 5 – 7 taught also by Matt as well as Dr. David Black of Ruby for Rails fame. That one is £1200 GBP and you can sign up here.
Of late the ActiveRecord association code has been getting a lot of love. One of the high profile additions are polymorphic associations which turned into one of the big features of the 1.1 release. Amongst all the commotion, some may not have noticed that there is an enhanced way to do many to many associations other than with
For some time people have been skipping out on
has_and_belongs_to_many in favor of setting up two
has_many associations so that they get the benefits of a full join model and what that brings with it. With 1.1’s new
:through association option, a two way
has_many just got even sweeter. So if there are two ways to do a many to many relationship, what are the differences, and which approach should you take?
Josh Susser has been digging deep into the association code lately and has emerged from the thicket with a point by point comparison of
has_many :through, a dance-off if you will, between the two approaches. This would be a good time to add him to your RSS reader if you haven’t already.
Jobster is buying into Rails big time. Over the next few months they are looking to hire no fewer than 10 developers. Those over in the Getting Real camp may cringe at the idea of bulking up your team so quickly, but Jobster CEO Jason Goldberg aims to keep things small and nimble:
One of the cool things we have done at jobster
(we think) is to foster small teams which take on big projects in rapid
cycles. Rails makes that possible. With 12 more devs, for instance, we
would spin up 4 significant projects.
So far Rails has indeed proven to be a great fit.
A team of three engineers tasked with prototyping a compelling consumer
product in one month. They where given complete freedom to do what they
wanted, and to build on top of whatever technology they chose. They chose
ruby on rails, completed a successful prototype that will be pushed to our
live site shortly. It was so successful that rails will be the technology
that all our new consumer features will be built on.
Maybe being on one of these teams sounds like a good fit for you. Check out what they are looking for.
The wait is over for the next killer Rails application. Fluxiom has launched! Digital asset management just got a lot sexier.
You may have seen its demo video which has been floating around since last December. Developed by wollzelle with none other than Thomas Fuchs, aka Mr. Scriptaculous, at the helm, it brings a native desktop app feel to your web browser. Those building Rails applications these days may be familiar with all the swanky effects Thomas has been putting together. Turns out he’s had a few tricks up his sleeve. Fluxiom not only helps collect, manage and access your assets, it does it with style.
We await a bevy of great extractions Thomas ;)
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.