When writing Crafting Rails Applications, I knew exactly which parts from Rails I wanted to talk about. However, I didn’t want the book to simply describe how everything works, I actually wanted everyone to build something useful from each part of Rails.

One of the hardest areas to come up with an useful tool as example was the template handlers. Template handlers are responsible for template compilation and the canonical examples are: ERb and Haml. Obviously, creating something like ERb or Haml from scratch would require a lot of code beyond the Rails integration so it wasn’t an option. On the other hand, tools that simply render rdoc or markdown templates would be too simple and there are already plenty of gems doing the same out there.

So I started playing with some options. The first one was something like Why’s Markaby but that would still require a good amount of code (albeit much less than ERb). Next, I have played with something called YERb (YAML + ERb) which was an interesting hack but too slow to be of any use. I was almost planning to remove the chapter about template handlers when it finally came to me the idea of markerb: markdown + erb (in the book, we did a wordplay and called merb). While the idea was simple and easy to implement, it had a great use case: multipart templates.

With Markerb, you can create one template for ActionMailer and it will be delivered both as text and HTML. So there is no need to maintain two templates. You write it in markdown, which is delivered as text, but also rendered to be delivered as HTML. Recently, I have crafted Markerb in its own gem so everyone can use it.

How to use?

The usage is quite simple. Assuming you have a notifier as below:

class Notifier < ActionMailer::Base
  def contact(recipient)
    @recipient = recipient
    mail(:to => @recipient, :from => "john.doe@example.com") do |format|
      format.text
      format.html
    end
  end
end

If you create a template at app/views/notifier/contact.markerb:

Multipart templates **rock**, right <%= @recipient %>?!

It will generate two parts, one in text and another in HTML when delivered. And that is it! Before we finish, here are a few things you might need to know:

• The “contact.markerb” template should not have a format in its name. Adding a format would make it unavailable to be rendered in different formats;
• The order of the parts matter. It is important for e-mail clients that you call format.text before you call format.html;
• Notice you can normally use ERb inside the template.

If you are interested in how Markerb, template handlers and other part of Rails work, check out Crafting Rails Applications. We also hope to add a generator to Devise that will optionally copy all views as Markerb templates to your application.

And you? Do you have any use cases for Markerb? Do you have any other interesting template handlers you would like to share?

Tags: crafting rails applications, markerb, rails
Posted in English | Comments Off

I am happy to announce the fastest and most complete Elixir version yet was just released. In case you don’t remember, Elixir is a programming language implemented on top of the Erlang VM with charming syntax, method dispatching and metaprogramming awesomeness. By running on the Erlang VM, Elixir provides a good alternative to build robust and concurrent systems.

The version v0.3.0 released today provides improvements to the standard library, enhanced method dispatching, anonymous methods and some performance optimizations. You can learn more by taking a look at the changelog.

Most of the improvements on this release came as requirements from Frankie. Frankie is a Sinatra like clone running on Elixir and works as follows:

module MyApp
  mixin Frankie::App
 
  get "/hello_world", def
    "Hello World"
  end
end
 
Frankie.run 'mochiweb, MyApp

In Ruby, Sinatra uses instance_eval to evaluate the block in the application instance context. As we don’t (and won’t) have instance_eval in Elixir, we can achieve the same functionality with anonymous methods. Anonymous methods are the same as regular methods except they don’t need a name. Frankie keeps a reference to the method which later is invoked with MyApp instance.

The performance improvements were also targeted to Frankie. When running on Elixir v0.2.0, Frankie can handle 5500req/s on my machine, but on version v0.3.0, it reaches 9000req/s. You can find more information and a comparison with other Sinatra-like libraries on this gist.

Finally, Elixir built-in test suite called ExUnit now runs test cases in parallel for faster results, the methods respond_to?, eval and remove_ivar were added and a new module called Timer, equivalent to Erlang’s timer, was added in order to provide better benchmarking tools.

What is next?

There is still a lot to be done in Elixir and I feel that releases are getting stable enough for more people to jump in and start having fun! If you want to help (yes!), there are several ways to improve the language, here are a few:

• Help organizing the documentation. The README is quite complete but people complain that it would be better if it was organized into sections. The README would then be just a quick start guide;
• If web development is your thing, you can help us by improving ExBridge and Frankie;
• Build something cool, share it with us and send bug reports.

Most of all, now we also have an IRC channel on freenode called #elixir-lang where you can hangout, discuss, give feedback and ask questions. You can start now by joining and following the first steps in the README. So, what are you waiting for?

Tags: elixir, frankie, sinatra
Posted in English | 1 Comment »