José Valim and Aaron Patterson at RailsConf 2011 by @j3z_hh

This year me and José Valim had the pleasure of going to Baltimore, in the US, to one of the biggest Rails events of the world! RailsConf is definitely the best place to have the opportunity of meeting and talking to a lot of great Rubyists and Railers, and also attending their talks.

Not only that, we also participated (though briefly) in BohConf, the official RailsConf unconference, which was great and very well organized! The talks covered a myriad of topics, guided the exploration on some technologies and counted with the presence of the Ruby Mendicant University students. José Valim presented a tutorial on his own Elixir, showing how to build a chat server using some cool stuff that both Elixir and Erlang provide. The code used on the tutorial is available on Valim’s GitHub.

Also, José Valim presented a talk on the ongoing Rails refactoring, guiding through the SOLID Principles and the changes in rails’ own code. You can get the slides at his RailsConf page. While you’re at it, please rate and give your feedback if you watched it live!

In this edition of RailsConf, DHH presented the “assets revolution” part of Rails 3.1 and why CoffeeScript was adopted. It doesn’t matter if you’re into CoffeeScript or not, Rails now has amazing internals to deal with assets, raising them as “first-class citizens”. You can have this on the latest Release Candidate that was released last week. The keynote is available on Youtube.

Regarding Keynotes, RailsConf 2011 had amazing ones. I strongly recommend you to watch Eric Reies’ Lessons Learned, regarding delivering products and learning from your mistakes, from his upcoming book with the same title.

Tenderlove (or sometimes known as Aaron Patterson) presented a very good talk about database query caching and proposed a future Rails refactoring to restructure the rack middleware stack in order to make it better and faster. A must watch talk! Check it on Youtube: Aaron Patterson’s Double Dream Hands: So Intense! (fast forward to minute 40 or so for a surprise)!

The talks themselves were good, in general. Highlights, in my opinion, are:

• Aman Gupta’s Rails Performance Tools was the first time I saw Aman Gupta’s presentation live. Even though he got his slides from other conferences, I have to say I was very impressed. He really knows what he is talking about and the examples were very applicable to everyday’s work. You definitely should check it out.
• Jim Weirich and Matt Yoho’s Securing your rails application began slowly, showing easy-to-avoid security issues, but it picked up nicely, showing live examples on how to replicate the security issues described, very cool!
• Joe Ferris’ Testing the Impossible was a very good talk. At PlataformaTec we always discuss the best ways to test code and it was very nice to see someone else’s effort on the subject, I was able to confirm some ideas and learn new ones!
• Yehuda Katz’ Building Rails Apps For the Rick Client explained why Rails is much more than simple view helpers and then moved on to discuss API implementations. The proposed bulk api was particularly interesting and is a good example of a private protocol between the client (SproutCore) and server side (Rails) for advanced transactions and performance!

All in all, it was a great RailsConf! I had a blast, meeting people and having drinks at the parties was also one of the best parts of the conference! And what about you? What is your opinion about RailsConf, did you like it? Which were your favorite talks?

See you in 2012!

Tags: events, railsconf
Posted in English | 3 Comments »

I’m pleased to say that we released SimpleForm 1.4. Like the last version, this release had a lot of contributions from the community, closing bugs and adding some nice features. Here is a brief introduction to some of the new features:

Custom Form Builders

Now you can set a custom form builder that inherits from SimpleForm::FormBuilder:

class CustomBuilder < SimpleForm::FormBuilder
  def input(attribute_name, options={}, &block)
    options[:input_html].merge! :class => 'custom'
    super
  end
end

And use it straight in the simple_form_for helper, like the example below:

<%= simple_form_for(@user, :builder => CustomBuilder) do |f| %>
  <%= f.input :name %>
<% end %>

Custom Inputs

SimpleForm has many different inputs available in its source code. But, sometimes, depending on the business logic the application requires, we need to add new inputs to make our work easier. Before this version, you had to explicitly define your new input inside SimpleForm namespace for it to work. Furthermore, customizing existing SimpleForm inputs could only be achieved through monkey patching.

Inspired by a similar feature in the Formtastic gem, from now on you will be able to create new input types inside app/inputs folder in your application. The only restriction to create such inputs is that the class name must end with Input. See some examples:

# app/inputs/currency_input.rb
class CurrencyInput < SimpleForm::Inputs::StringInput
  def input
    "$ #{super}".html_safe
  end
end

And the usage:

f.input :money, :as => :currency

You can also redefine existing SimpleForm inputs by creating a new class with the same name. For instance, if you want to wrap date/time/datetime inputs in a div, you can do:

# app/inputs/date_time_input.rb
class DateTimeInput < SimpleForm::Inputs::DateTimeInput
  def input
    "<div>#{super}</div>".html_safe
  end
end

HTML 5

SimpleForm allows you to add many HTML 5 features to your applications, like placeholders, inline browser validations and more. The problem is: most browsers are still experimenting some HTML 5 features, and people started having lots of troubles with the automatic browser validation.

For this reason, SimpleForm now has an option to easily disable such form validations. You have to add this line to your SimpleForm initializer:

config.browser_validations = false

But, if HTML 5 is still not for you, you can disable all the HTML 5 stuff, by adding the configuration below to your initializer:

config.html5 = false

Notice that this option does not disable the `placeholder` component, because we believe this option is very well supported currently in mostly browsers. If you don’t want to use it as well, just remove it from the `components` option in your initializer.

More Helpers

In this version we also add two new form helpers to SimpleForm: input_field and full_error.

The full_error helper shows errors in an attribute prepending its human name. This can be used when you want to show errors on hidden fields, for instance. You can see how it works in this example:

f.full_error :token #=> <span class="error">Token is invalid</span>

The input_field helper renders only the input tag with all the facilities of SimpleForm’s input helper. It means no wrapper, error or hint will be rendered. A good example of using this helper is inside an input block:

<%= f.input :max_time, :as => :integer do %>
  <%= f.input_field :max_time, :as => :integer, :type => :range %>
  <%= content_tag :span, '1', :id => 'max_time_value' %>
<% end %>

It will render:

<div class="input integer required">
  <label class="integer required for="model_max_time">Max time <abbr title="required">*</abbr></label>
  <input class="numeric integer required" id="model_max_time" name="model[max_time]" required="required" size="50" type="range" />
  <span id="max_time_value">1</span>
</div>

Wrapping up

This version allows you to do more customizations in SimpleForm based on your applications needs. We encourage you to take a look at the CHANGELOG and also review the README to see what else is available and some more examples.

And please, check out SimpleForm contributors, we want to thank everyone who is helping us to improve SimpleForm.

Right now, we are working on Rails 3.1 compatibility for the next version. If you feel like helping us or just want to see a new feature, feel free to send us a pull request. And last, but not least, we look forward to know how SimpleForm is changing your life. Is it being helpful? How does it improve your applications? Don’t be shy, comments are welcome.

Tags: form, gems, html 5, open source, rails 3, simple_form
Posted in English | 2 Comments »

I’m pleased to say Elixir v0.2.0 is finally out. In case you missed, Elixir provides a charming syntax and method dispatching on top of Erlang VM. There is a CHANGELOG, but keep reading if you are interested in more details.

Assignments

When Elixir was first released, it followed the footsteps of Erlang when it came to assignments. This meant that a variable could not be assigned more than once:

x = 1
% This would raise an exception
x = 2

At first, I imagined this restriction was to avoid side effects but it actually has its roots in lambda-calculus. In Math, equations like x = x + 1 have no satisfiable solution. Does this mean multiple assignments are side effects free? It depends.

If you have global variables, multiple assignments can clearly introduce side effects. Two threads (or Erlang/Elixir processes) could try to modify the same global variable, leading to race conditions. Another situation where multiple assignments could introduce side effects is in closures. But only if closures are able to change their original binding, as in Ruby:

x = 1
(lambda { |y| x = y }).call(2)
x #=> 2

This could easily lead to race conditions if you are sharing a lambda between threads. Each time a thread executes the lambda, it could change the value of a variable, modifying the behavior of other threads that depend on it.

That said, in order to have sane multiple assignment in Elixir, we cannot have global variables nor mutable closures, but that is fine as we don’t have them in Erlang anyway. The following is then possible in Elixir v0.2.0:

x = 1
x = 2
x = x + 1

If you want to match with the value of x, you can use:

x = 1
% Now this raises an exception
~x = 2

Updating variables

Structures are immutable in Elixir. This adds an important syntax restriction that can be easily explained using some Ruby code:

class Person
  def name
    @name
  end
 
  def name(value)
    @name = value
  end
end
 
person = Person.new
person.name("José")
person.name #=> "José"

In the example above, we define a class called Person, initialize it and set the instance name. The name definition happens by changing the value of the instance variable @name. The code above is modifying the existing structure in place.

In Elixir, however, all structure are immutable. All modifications in one structure needs to necessarily create a new structure. This means that the instance variable assignment expression @name = value should actually return a new structure. As it would be awkward for such expression to return a new structure, it was disallowed in the first Elixir release. Particularly, if you wanted to update an structure, you had to use the update_ivar method. The code above would be written in Elixir as:

module Person
  def name
    @name
  end

  def name(value)
    update_ivar 'name, value
  end
end

person = #Person()
person.name("José")
person.name %=> "José"

This was explicitly a temporary workaround until Elixir provided a better syntax as assigning instance variables is a quite common task. Well, no more workarounds! In Elixir v0.2.0, you can assign instance variables using @() as follow:

module Person
  def name
    @name
  end

  def name(value)
    % Update the attribute given by the atom/symbol 'name
    @('name, value)
  end
end

Compilation and scripting mode

In its first release, Elixir was a completely scripted language. For performance, Elixir modules were compiled to Erlang VM right after its definition but this was affecting load time. The language runtime was taking 1.2 seconds to boot, as it had to parse and compile the basic modules in the standard library. Another issue with the scripting approach is that it would make hot code swapping impossible to implement.

Due to all these aspects, Elixir now has an explicit compilation time. The current release ships with elixirc available to compile files. With an explicit compilation step, Elixir now takes 0.2 seconds to boot and hot code swapping is possible (although needs to be better supported). Even more, Elixir now uses Erlang code server instead of its own, which also introduces the benefit of autoload. Modules are automatically autoloaded, without a need for explicit requires.

One nice aspect of Elixir compilation is that it depends on runtime. It allows us to have all the meta-programming benefits existent in Ruby (which allow you to go much beyond Erlang macros). For example, consider the file counter.ex below:

module Counter
  dict = { 'one: 1, 'two: 2, 'three: 3 }
  dict.each do (key, value)
    module_eval "def #{key}; #{value}; end"
  end
end

When we compile the file with elixirc counter.ex -o ., it will execute the code above and dynamically define the methods one, two and three which will return its respective integer values. The compiled Counter module would look exactly if it was defined as follows:

module Counter
  def one
    1
  end

  def two
    2
  end

  def three
    3
  end
end

You can verify it by running iex (interactive Elixir):

> Counter.one
1
> Counter.two
2
> Counter.three
3

In other words, the compilation step simply saves a snapshot of the module after all the code is executed. With all this benefits in mind, the official way to distribute Elixir code is through compiled code, enjoying both improved performance and autoload capabilities.

However, a scripting language proves to be very convenient in several occasions and it is also available in Elixir. It will run exactly as a compiled file, except modules will need to be parsed and compiled every time you run your script. You can read more about it in the README!

Other changes

There were also several smaller changes and contributions from other developers around the world. New modules were added to the standard library, new methods, and so forth. Also, Elixir had several improvements on performance and smaller ones are still to come in next releases. Finally, expect some new projects that depend on Elixir coming around the corner. Don’t forget to checkout the CHANGELOG.

If you want to join the Elixir boat, now is a great opportunity! Grab the README, try it out and starting hacking away!

Tags: elixir, hot code swap
Posted in English | 3 Comments »