It is common in Rails 3.0 applications that you want to provide default views for a group of controllers. Let’s say you have a bunch of controllers inside the Admin namespace and you would like each action to fallback to a default template. So if you are rendering the index action for Admin::PostsController and “app/views/admin/posts/index.html.*” is not available, it should then render “app/views/admin/defaults/index.html”.

There are several ways to implement this feature at the controller level. It mainly relies on trying to render the original template and then rescue ActionView::MissingTemplate. If this error is rescued, you then render the default one. However, there is a considerable performance overhead in this approach as it needs to pass through the rendering and template lookup stack twice.

Luckily, since Rails 3.0, we have a new abstraction called resolvers that holds the logic to find a template. I explain comprehensively how resolvers work and their API in my book Crafting Rails Applications. So here I would just show the basics to get this functionality working.
First, we need to define a DefaultResolver, it could be done inside the lib directory:

class MyResolver < ::ActionView::FileSystemResolver
  def initialize
    super("app/views")
  end
 
  def find_templates(name, prefix, partial, details)
    super(name, "admin/defaults", partial, details)
  end
end

Our new resolver simply inherits from ActionView::FileSystemResolver and does two changes: Overrides the initialize method so the view path defaults to “app/views” inside our application and overrides find_templates. The find_templates method receives the template name, a prefix (i.e. the controller path), a boolean marking if the template is a partial or not and a hash of details. In the example above, we simply ignore the prefix given and hardcode it to “admin/defaults”.

Now, assuming that all controllers inside the Admin namespace inherit from an Admin::ApplicationController, we can add default views to all of them by adding the following line:

class Admin::ApplicationController < ActionController::Base
  append_view_path MyResolver.new
end

And we are done! The view_paths holds a list of paths and/or resolvers that the controller will look for templates until one is found. If none is found, an ActionView::MissingTemplate is raised. Since we used append_view_paths, our resolver was added after the “app/views” path, used by default in all controllers.

As you may have guessed, resolvers are a powerful abstraction that allows you to retrieve templates from anywhere, including the database, which is the example given in Crafting Rails Applications.

Finally, template inheritance was a feature recently added to Rails master (upcoming Rails 3.1), so you won’t need to create your custom resolver as above. There is a good wrap up about this feature in Rails Edge.

Tags: crafting rails applications, rails 3, rails 3.1, resolvers, template inheritance
Posted in English | 3 Comments »

Elixir is a new language we are building that targets the Erlang VM. Based on our strong Ruby background, we were asked several times and finally decided to write a blog post about why Rubists should play with Elixir. Granted that some of Elixir’s syntax and features comes from Ruby, however Elixir is definitely closer to Erlang than anything else. Single assignment variables, immutability, easy communication between processes, lists, tuples, binaries and OTP behaviors are all available in Elixir. Therefore, you will be able to learn a lot by using Elixir, here are the things I have enjoyed the most learning:

Pattern matching

Pattern matching is one of the features I enjoy the most in functional programming. They provide an easy to extract information from a data structure. For instance, in Elixir, you would write:

[first, second] = [1,2]
first % => 1
second % => 2

You could definitely write something similar using Ruby assignment operator, but the gain in pattern matching comes from the fact you can use them in method signatures and, if a method signature does not match one specific pattern, the next method is tried. For instance, here is a method that iterates through a list of strings and print them:

module Printer
  % This pattern matches a list with at least one element.
  % The first element of the list is assigned to h, the remaining
  % is assigned to tail.
  def print([head|tail])
    IO.puts head
    print(tail) % Recursively calls print with the tail
  end

  % Eventually the list will be empty and the method above
  % won't match, causing this one to match instead.
  def print([])
    % Do nothing, we are done printing items
  end
end

Printer.print ["foo", "bar", "baz"]

Another cool example is a recursive method that checks if a list is a prefix of another list:

module Prefix
  % Iterate both lists. Check if the first element is equal then call itself again.
  % If the first element (i) is not equal, it won't match this method.
  def is?([i|prefix], [i|list]) is?(prefix, list); end

  % If the prefix is empty, is because everything matched, so return true.
  def is?([], _list) true; end

  % Else, return false
  def is?(_prefix, _list); false; end
end

Prefix.is?([1,2,3], [1,2,3,4,5]) % => true
Prefix.is?([0,1,2], [1,2,3,4,5]) % => false

Finally, pattern matching allows us to easily have key-value args, one of the features planned to Ruby 2.0. This examples comes straight from Elixir code (notice that symbols in Elixir start with a single quote instead of colon):

module Record
  def retrieve(name, 'from: file)
    % Implementation ...
  end
end

The fact that neither Elixir nor Erlang provides conditional loops like while forces you to think differently and use pattern matching in different occasions. Thinking differently about a problem that you are frequently solving in Ruby and coming up with a completely different solution is in general a very insightful and enjoying process.

Also, notice that both Elixir and Erlang do tail call optimization, so the methods above will perform nicely while you could get huge stack traces if you implemented such methods in Ruby in a similar fashion.

Single assignment variables and immutability

What I haven’t showed in the example above is that variables in Erlang are single assignment, therefore, the following will raise an error:

[first, second] = [1,2]
first = 10

The above raises a bad match error because, since a value was already assigned to first, the second expressions first = 10 is actually comparing 1 to 10, which obviously fails. The fact variables are assigned just once is what allows us to implement our prefix method above, ensuring the value assigned to i matches in both lists.

Also, both in Elixir and Erlang, objects/data structures cannot be modified in place. They are immutable. Every modification generates a new object/data structure. Immutability removes the shared state internal to the language (you still have shared state if you have to do external operations) and play a key role on Erlang’s and Elixir’s concurrency.

Personally, I have found immutability to be a blessing and a curse at the same time. Mutability is not commonly an issue when working with Rails applications, but while working on Rails itself and other gems, we need to be frequently thinking about mutability. Sometimes you pass an object (like a hash or an array) to a method that modifies it in place and then you have to spend some time tracking how that new element ended up in your object.

When working in Elixir, since everything is immutable, I don’t need to worry about such cases and yes, it feels good! It feels like going from C to Java and then I suddenly don’t need to worry about memory management. However, such benefit comes with an obvious downside that some code just becomes more verbose.

To show this downside, consider a possible create action for PostsController similar to Rails, but where we have rewritten it to consider both immutability and single assignment variables:

def create
  post0 = Post.new(params[:post])
  post1 = post0.set(:published, false)
  post2 = post1.save

  if post2.persisted?
    redirect_to post2
  else
    render :new
  end
end

In such cases, the ORM could likely provided better APIs, but that is a pattern that would repeat over and over again. For instance, modifying the response cookies would require an explicit change in the response object:

response1 = response.cookies.set "tracker_code", "123456"

In any case, just working with a language that provides immutability and single assignment variables is worth the experience. You will learn a lot by trying it out that I could ever mention in a blog post. As pattern matching, it frequently forces you to handle problems through a different perspective which is extremely challenging and rewarding.

UPDATE: As some pointed out in the comments, Elixir can remove single assignment and still play properly with Erlang’s foundations. For this reason, Elixir now allows you to assign to the same variable more than once and has more flexible rules related to the variable scope (similar to Ruby) when compared to Erlang.

Communication between processes

Pattern matching, single assignment variables and immutability provides a good foundation for communication between processes. If you are interested to learn more about this one and see all these things working together, watch the screencast from previous week!

A different Object Model

Elixir has a different Object Model from Ruby. The Object Model is prototype-based like Javascript, in the sense there are no classes, but it is also different from Javascript and Self in the sense an object can still dictate how its children is going to look like, not necessarily being an exact copy from the parent. There is plenty more information about it Elixir’s README, including some other cool features like real private methods (maybe it will also be included in Ruby 2.0?) and local method calls.

You can always learn a lot by using other Object Models and this tip is not restricted only to Elixir. For instance, if you are not familiar with Javascript’s Object Model or other prototype based languages, I recommend you to learn it now!

Just learn

As I mentioned in the screencast and in the README, contributing to Elixir is quite easy because both the Standard Library and tests are written in Elixir itself. Now, imagine that you had to implement something like Ruby’s Set in Elixir. You would not learn about Ruby’s Set more, but also think about the best structure to use, which algorithm would be the best to update the Set and what would be a good API to access those objects.

Besides, there are other basic tools that are required in any language, like packaging system, documentation parser and test libraries that are currently missing in Elixir and you could be the one to implement it!

Wrapping up

I hope I have convinced you to try out Elixir. You can learn much more about the language itself by checking out its README.

Finally, if you need some inspiration to do crazy things, I recommend the Forking Ruby talk by Dave Thomas. As he said, we love Ruby and we are not moving away from it anytime soon, but forking it or trying out new things is a great way to improve the language and its ecosystem, and I hope Elixir helps you think more about that.

Tags: elixir, erlang, ruby
Posted in English | 14 Comments »

Erik DeBill has put two interesting benchmarks on his blog. The first one compares the performance of different Ruby implementations in Rails development mode while the second compares their performance in Rails boot time. If you haven’t read them yet, please do it now.

Benchmarking code is an important practice, but it can be misleading if you fail to understand the root causes that lead to the different results.

Performance in development mode

In the first blog post, it is guessed that the root case for having slow requests in development is because Rails eager loads all models and controllers for each request:

Now, what I’d really like is a way to avoid recompiling everything every time. If I could have Rails recompile just the model or controller I’m working on and skip all the others, that’d be grand. I’ve taken a couple stabs at it, but I haven’t succeeded yet.

This is wrong! Rails, in development, only loads the model and the controller you are using in that specific request. This is very easy to verify if you create a new application, scaffold two resources and add a puts self.name in their class definition. If you access one controller, it will only load the model explicitly referenced in that controller. Even the model associations try to be lazy in that aspect, always loading the minimum it can.

So you may ask, why Rails is getting so slow after adding more scaffolds?

It happens because Rails 3.0 includes all helpers by default in your ApplicationController. So at the beginning of each request, Rails needs to load all helpers. Loading a helper in development mode is slow because ActiveSupport::Dependencies needs to track which dependencies were added when a file is loaded. This tracking basically happens by checking which constants were added invoking Object.constants before and after the file was loaded. Tracking these constants take more than 50% of the time in the request, mainly because invoking Object.constants is slow.

In other words, the main reason for an implementation to perform better in the benchmarks showed in the blog post is if it can calculate Object.constants faster. Those results do not mean at all that an implementation is more suitable than other for Rails development. In order to have real results, we would need a real application that is not made of 1000 scaffold (or, in this case, 1000 helpers).

In any case, if the root cause is in loading all helpers, how can we make it better? There are a few things:

1) Obviously, the problem can be fixed by having less helper files. Since Rails scaffold automatically generates helper files, it is common that applications have a bunch of empty helpers. Get rid of them. If you prefer you can even turn off the automatic generation of helpers in scaffold by adding the following to your application configuration:

config.generators.helper = false

2) If you simply don’t want to include all helpers, there is a method called clear_helpers that you could invoke in your ApplicationController. This method won’t fix the problem because it is invoked too late, after all the helpers were already loaded. So you get the feature, but not the performance improvement.

3) Rails master (upcoming Rails 3.1) has a configuration option that allows you to effectively turn these helpers off getting both the feature and the performance improvement:

config.action_controller.include_all_helpers = false

Boot performance

The second blog post shows how Rails boot time performs in different implementations. Since it was not made explicit in which environment those benchmarks were executed, I will assume it happened on development.

At the end of the second blog post, it tries to associate the performance of booting Rails in development with the amount of code inside the app. However, when you boot an application in development, no model, controller or helper is loaded at all unless you explicitly access them in an initializer or in your routes file. Once again, you can check that by adding some puts to your classes.

So, you may ask one more time, what makes booting up so slow?

Rails 3 has a new router that can match paths very fast, but in order to do so, it needs to compile each route into a regular expression and that takes some time (although it could probably be made faster). And it is exactly the routes compilation that is slow on boot time. We can easily reproduce it by adding the following to our router:

Foo::Application.routes.draw do
  1000.times do |index|
    resources :"posts#{index}"
  end
end

This took 55 seconds on my machine using REE which is quite close to the value that he showed on his benchmark.

Again, benchmarking code is important, but more important is to correctly interpret the results. In his example, it is likely that most of Rails booting time is spent on compiling the routes and the benchmark just shows how good different Ruby implementations are in handling all these regular expressions.

Wrapping up

Much more interesting benchmarks for Rails boot time would actually be performed in production environment, which actually has to load all the code inside the app folder and compile the routes file. Regardless, developers starting new applications should always be skeptical about choosing a Ruby implementation based on other application’s benchmarks.

When starting out a new application, any Ruby implementation should suit you just fine unless you have a stronger constraint (like Java integration). Once your application starts to grow and you want to evaluate how well it performs in different implementations, you should do your own benchmarks and see how it goes. In any case, don’t jump into conclusions. If you need to investigate deeper, each implementation has its own sets of benchmarking and profiling tools that may help you really understand what is actually slow and how to improve it.

I also want to thank ruby-prof authors and maintainers, for such an amazing tool, and Yehuda Katz, who helped me profile a demo Rails application in order to write this detailed response.

And you? Have you done benchmarks in your applications and found any interesting data you would like to share?

Tags: benchmark, rails
Posted in English | 7 Comments »

Note: Devise 1.1.6 broke compatibility with Rails versions prior to 3.0.4, this has been fixed on Devise 1.1.7.

Devise 1.1.6 has just been released and it follows Rails 3.0.4 release. Rails 3.0.4 changes how CSRF works and adds a new method called handle_unverified_request that should be properly overridden by authentication frameworks. Devise 1.1.6 implements this method and others small security fixes.

If you have updated to Rails 3.0.4, you must update to Devise 1.1.6. Those using Devise 1.2.rc should use master for awhile, another RC is coming soon. For more information, check out the CHANGELOG.

Devise 1.0.10 was also released with the same fixes for Rails 2.3.11.

Tags: devise, security fix
Posted in English | Comments Off

When I first got into Ruby and Rails development, I was impressed about how everything worked. A few lines of code and so much got done. At that time, if I was reading a book or blog post that said: “just do X and Y will automagically work”. I would gladly accept those instructions.

However, after a while, I wanted to understand how it really worked from the inside, so I started reading the source code from different plugins, including Rails itself. Accusing magic to be the reason for that 200 lines of code to “just work” didn’t feel right anymore.

Turns out, I was not the only one with this feeling. I have been into a few big conferences this year and asked people outside the Rails community what they think about it. And, for my surprise, some of them mentioned that “there is too much magic going on”.

We have been victims of myths before, as the famous “Rails can’t scale” one, and we strongly fought back. But what about the “there is too much magic going on”? Is it myth? Who is there to blame?

Yes, it is a myth and we (the Rails community) are the ones to blame for spreading it.

I have already seen people explaining how “has_many :comments” works as magic: “it magically guesses the columns from your database”. Well, a more appropriate description for that would be “Convention over Configuration”. Rails uses a set of conventions so it can properly build your associations without you having to specify all tables and columns.

Heck, I also did my part in the past. There was a time that Inherited Resources’ README was filled by words like “magic” and  “automagically”. Just recently, I replaced all this occurencies with more detailed explanations of how it really works.

The question is: isn’t it about time for us to start fighting against the “magic” myth?

When I improved Inherited Resources’ README, the benefits were clear in my head. People using Inherited Resources would write better code and be more productive because they understood it better. And, as consequence, they would be able to troubleshoot issues easily or even contribute back. This is clearly a win-win situation.

At the beginning of this year (or more specifically February, 2010) I started to put a lot of effort in writing and understanding Rails 3 architecture. Or as some people would (wrongly) say: I started to unveil the magic. After some time, it was clear that I could write better and faster code and that a lot of people could benefit from this knowledge as well.

Now, 10 months later, I am happy to say that the beta version of my book Crafting Rails Applications is out to spread what I have learned about Rails and its applications. Rails is a framework that allows us to write web applications and an advanced Rails book should consequently be about crafting them.

Crafting Rails Applications guides you through seven different tutorials, each of them using test-driven development to build a new Rails extension or application that solves common problems through the new Rails 3 APIs. You will understand how the Rails rendering stack works and customize it to read templates from the database while you learn how to mimic Active Record behavior, like validations, in any other object. You will find out how to write faster, leaner controllers, and you’ll learn how to mix Sinatra applications into your Rails apps, so you can choose the most appropriate tool for the job. In addition, you will improve your productivity by customizing generators and responders.

From the book cover:

Rails 3 is a huge step forward. You can now easily extend the framework, change its behavior, and replace whole components to bend it to your will, all without messy hacks. This pioneering book is the first resource that deep dives into the new Rails 3 APIs and shows you how use them to write better web applications and make your day-to-day work with Rails more productive.

My goal is that Crafting Rails Applications increases the Rails community thirst for knowledge, that “magic” is no longer enough to describe any part of Rails or its ecosystem.

The benefits are clear: leaner code, faster applications and a well-grounded Rails community. Check what people are saying or get a copy on Pragmatic Programmers web site.

Tags: crafting rails applications
Posted in English | 16 Comments »

There is a vulnerability in Devise source code that allows someone to steal your session through session fixation attacks.

Who is affected?

This vulnerability is present in all Devise versions, in both 1.0 and 1.1 branches. However, you are only affected if you are using a Active Record ou Memcached or other server persistent session store. Projects using cookie stores (Rails default) are not affected.

If you are using Devise defaults which requires the user a password to update his account, it is unlikely the target account can be stolen, however the attacker will be able to normally perform actions in the website.

Releases

To fix this vulnerability, we released Devise 1.0.9 for Rails 2.3.x applications and Devise 1.1.4 for Rails 3.x.

In another note, Devise 1.2.rc was also released, which includes this security fix and Omniauth support. Check the CHANGELOG for more information.

Credit

Thanks to Olivier Dembour and Stephen Touset for reporting the vulnerability.

Tags: devise, security fix
Posted in English | 2 Comments »