I’ll talk about why we use Ruby on Rails in ASPgems as our favorite development tool. At the same table, experts in Drupal, Code Igniter, Zend Framework, Sun J2EE and .Net will explain the reasons of their choice. It will be an interesting session and I’m sure we will find several points in common between the different frameworks enforcing the idea that development paradigms are changing.

Another member of ASPgems, Agustín, will have a session on Ruby On Rails the next day.

I find exciting this new orientation of SIMO, providing with technical content apart of the software products that get presented every year.

It’s good for the fair to take this step further and it’s good for us to be able to expose our point of view about new techniques in software development that will allow to get closer to the reality of web development, in contrast with the rigid architectures and procedures which have been leading the software industry for so long.

searchwords: simo, conference, ruby on rails, frameworks, comparative

The url for Eclipse’s update manager is http://update.aptana.com/update/rails/beta/3.2

If you are still not using any IDE for your Ruby on Rails development, I would recommend to take a look at RadRails. Even if Eclipse is a bit heavy, in a modern computer that shouldn’t be a problem. My typical set of running applications when developing is Eclipse 3.3 with RadRails, one or two Mysql instances, FireFox, Thunderbird, Pidgin, Winamp, Notepad++, Console2, Kerio PF and AVG. Very often I have Skype, Emule and OpenOffice started too and even some IE for UI testing purposes. And of course all the ordinary services windows XP needs.

All of the above runs in a vanilla laptop with 2 Gigas of RAM bought over a year ago. Well, I can say everything works smoothly. My previous laptop was fairly old (over 4 years) and had “only” one giga. In that box sometimes I could feel Eclipse/RadRails were heavier than I would like. But not anymore.

Of course there are other IDEs and I’m sure they have their own sweet spots, but so far I haven’t seem anything to make me think of changing. I use Eclipse because I’ve been working with it for Java development since years and I feel pretty comfortable, because it has an overwhelming amount of plugins for almost anything, because it’s Open Source and multiplatform, and because it supports development in many programming languages. I have used it professionally for writing Java, JavaScript, ASP, HTML, CSS, PHP, C++ and Ruby.

Some of my favorite features of Eclipse/RadRails are navigating between classes with a single click, searching for classes or resources comfortably, database and subversion integration, graphical debugging, Rails servers management, code refactoring and assistance when writing Ruby, HTML, CSS or JavaScript.

Apart of that, there are plenty of details that make my every day much easier than with a plain text editor and the command line, which I use less every day (and surprisingly not missing it… much)

Since we are here already and since I just delivered the fourth out of nine chapters, I think I can already announce I’ve been writing a book about RadRails during the last months.

Starting with a conversation at the rubyonrails-talk list I got the opportunity to write it and even if at the beginning I hesitated a bit because it would take much of my free time, I finally gave in to my curiosity about the process of writing a technical book. If anything goes as by the schedule, I should be finishing it by early 2008.

The likely title is “RoR Made Easy with Aptana Radrails” and the publishing house behind it is Packt Publishing

searchwords: RadRails, Aptana, Eclipse, PacktPublishing, javier ramirez, book

There is no bad weather, just bad clothing.

It’s one of those sentences if they are not true I should make everything in my hand for they to be.

Well, there is this very useful FF extension to start the search from the last point where you clicked with your mouse. If you click inside a frame and you hit Ctrl+F, your search will start from that point. Really handy!

The url for this beauty is Find in Frame Hack

searchwords: Firefox, DevBoi, extensiones, documentación, ruby on rails, documentation, search in frame

I just used it for reading HTML from a web, and convert it to XML automatically closing any open stand-alone tags like <br>, or forgotten open pairs like <span> or <tr>. Then I can access the HTML directly as I would use an XML and even using XPATH.

Example in a real-life script

require 'open-uri'
require 'htree'

#First I will get the contents from a web page
str_xml = ''
open("http://formatinternet.wordpress.com",  'User-Agent'=>"Ruby/#{RUBY_VERSION}")
  { |file| str_xml = file.read }

#now we parse with HTree so we will get a valid XHTML accessible through a rexml document.
parsed_xml = HTree.parse(str_xml).to_rexml
#and now we can get all the div inside the html
a_divs = parsed_xml.elements.to_a('//div')

searchwords: malformed XML, malformed HTML, parser, htree

You can also watch it online here

searchwords: XML, REXML, SimpleXML, to_xml, rxml, xml builder, SAX, STAX, push parser, pull parser, DOM

When we use rails helpers, the information submitted via ajax is serialized by using the “serialize” function in prototype.js. This function makes a call to the standard javascript function “encodeURIComponent”. Finally, this function makes an encoding by converting from the original charset of the page to UTF-8 and then escaping the characters.

As a result, any ajax call we are making through prototype.js will reach the server with the params in UTF-8. Once we know this, the way to deal with this is just converting each of the params to our desired target encoding. For doing this, we can use Iconv.

If you want to avoid converting each param individually, we can just convert everything in the Rails params object. Of course we will run the conversion only when we are receiving a petition via ajax.

What I have made is defining a new method ‘iconv’ for the Hash class (ruby rocks!). I will simply iterate the children of the hash and their children (suppose they support the iconv method), converting all the found strings to the target encoding. The code for this is

class Hash
  #converts the encoding of all the values in the (can be nested) hash,by using iconv
  def iconv(c_to,c_from,obj_iconv=nil)
    obj_iconv = obj_iconv || Iconv.new(c_to,c_from )
    self.each do |key,value|
      next if value.blank?
      if value.is_a? String
        self[key] = obj_iconv.iconv(value)
      elsif value.respond_to? 'iconv'
        self[key] = value.iconv(c_to,c_from,obj_iconv)
      end
    end
    return self
  end
end

This will convert all descendant (direct or nor) strings in a Hash. That will be usually everything you need, but should you need to define the same functionality for Arrays or other collections it would be trivial to re-open those classes and adding an ‘iconv’ method just like the one above.

Now everything we need is definind a filter for our actions in which all we will write is

  params.iconv('iso-8859-1','utf-8') if request.xhr?

…and they coded in their own language happily ever after

searchwords: charset, utf-8, iso-8859-1, iconv, prototype.js, javascript, encodeURIComponent, ajax

Rails makes easy to work with UTF-8, but sometimes you just need to work against a legacy database and UTF-8 is not an option. In Rails, if we want to use ISO-8859-1 we can do so by stating the charset in our html code (in the layout) and by adding a controller filter such as

def set_charset
  @headers['Content-Type'] = "text/html; charset=ISO-8859-1"  unless request.xhr?
end

The reason for the unless condition is because if we try to set a content-type of html to an ajax response we will get an error.

If we try this in our application, everything will look fine. No more strange characters and apparently everything is going fine… untill we happen to use ajax.

As I said before, in an ajax response we cannot set html as the content-type; but if we don’t state any type, the browser will just use the default one, so we will be getting strange chars again.

The solution? Just use a content-type of “text/javascript” with the right encoding in your ajax responses. This will tell the browser to treat the response as a javascript with the desired charset.

The modified controller for having a working encoding both for ajax and non-ajax responses would be:

def set_charset
  str_type = request.xhr? ? 'javascript' : 'html'
  @headers['Content-Type'] = "text/#{str_type}; charset=ISO-8859-1"
end

Now we can see all our content, either direct http or through ajax with the right encoding.

… the bad news will come if we want to use ajax for sending content back to the server… but don’t worry too much because I’ll tell you how to fix it in another post.

searchwords: charset, utf-8, iso-8859-1, iconv, prototype.js, javascript, encodeURIComponent, ajax

On the other side, Sun took positions some weeks ago by hiring the development team of JRuby and focusing towards Java and ruby/rails speaking in a natural way.

Clearly dynamic languages have a lot to say and they are going to hold an important role in the next ego-wars between the big companues… with a bit of luck maybe we’ll all win something

As you probably know, Ruby on Rails is one of the most exciting web-oriented development platforms.

With about 30 sessions and some parallel activities, this conference is a perfect starting point for an initial contact with this technology and a meeting point between professionals in the Spanish-speaking Rails community.

We will be live streaming all the sessions in the main hall and we’ll be having a remote Q&A session with David Heinemeier Hansson

The official website is http://2006.conferenciarails.org/