Por si el título no lo deja claro, lo repito aquí: NetBeans se ha convertido desde hace unos meses en la opción a la hora de elegir un IDE para desarrollar aplicaciones Rails. Al menos ha sido nuestra elección y, por lo que puedo decir tras varios meses de trabajo, primero con las versiones beta y ahora con la release definitiva, creo que hemos acertado de pleno al abandonar nuestro querido Aptana RadRails y pasarnos a la “competencia”.

NetBeans proporciona un entorno de trabajo muy cómodo, manejable y potente, del que me gustaría destacar las siguientes características:

• Integración con SVN de serie
• Syntax highlight
• Autocompleción de tipos, variables, funciones, parámetros, columnas de BD, etc.
• plantillas inline à la Textmate (o casi, vale)
• Hints sobre posibles errores en el código
• Control de los generadores Rails y las tareas Rake desde el propio IDE
• Depuración de código Rails

Es una pequeña lista. Para obtener información más detallada sobre NetBeans podéis echarle un ojo a su propia página (el enlace está ahí atrás, donde dice “netbeans” :-P) o bien googlear un rato: hay un montón de gente ahí fuera encantados con este magnífico IDE para Rails.

De todos modos, por aquello de dejar salir mi lado negativo a pasear, antes de despedirme voy a comentar lo que menos me gusta de NetBeans en comparación con RadRails (es decir, Eclipse)

• La vista de sincronización de SVN. Prefiero la vista de los Eclipse, me da una noción más clara de qué ha cambiado (NetBeans muestra un listado plano de los ficheros con cambios, mientras que el plugin de Eclipse permite ver los ficheros en un árbol, colgando de sus carpetas padre)
• La gestión de las preferencias. En Eclipse se puede controlar casi cualquier aspecto del IDE, y encontrar cada preferencia es muy sencillo gracias al maravilloso sistema de búsqueda integrado en los diálogos de configuración. Por contra, encontrar en el NetBeans un determinado parámetro es una tarea de rastreo casi lineal hasta dar con ella que puede llegar a desesperar (por ejemplo, cambiar los atajos de teclado se convierte en un infierno)
• Por último, falta una opción (al menos yo no he conseguido encontrarla) que permita enlazar el editor de código con el árbol del proyecto. Se puede seleccionar el fichero que se está editando en el árbol del proyecto utilizando una combinación de teclas (ctrl+shift+1 si mal no recuerdo), pero a veces se hace tedioso. Aquí de nuevo gana el Eclipse, al permitir enlazar o desenlazar el editor y el árbol al libre albedrío del desarrollador, como debe ser.

Efectivamente, son tres pijadas. Y por eso mismo recomendamos NetBeans como IDE para Rails: porque los únicos argumentos que tenemos en contra no son argumentos, son pijadas.

(Y ya para terminar, una cita de la introducción a La lucha contra el demonio, de Stefan Zweig, a cuento de las comparaciones)

[…] la comparación enriquece, pues realza los valores, dando una serie de reflejos que, alrededor de las figuras, forman como un marco de profundidad en el espacio.

…podemos olvidarnos de algunas costumbres adquiridas con otras plataformas (léase J2EE o .NET) y aprovechar ciertas construcciones de Ruby que en un entorno multihilo sería problemático usar libremente. ¿A qué me refiero?, a variables de clase.

Las amigables variables de clase almacenan valores compartidos por todas las instancias de dicha clase, y a estas alturas todos deberíamos saber que si más de un hilo puede leer/modificar una de estas variables, tenemos que gestionar la concurrencia. No obstante, el caso de Rails es diferente. Podemos asegurar que cada instancia de nuestro servidor (normalmente un mongrel) sólo va a ejecutar un hilo por cada petición y por tanto podemos utilizar las variables de clase impunemente.

Supongamos, como ejemplo, una página que muestra varios valores monetarios sujetos a tipo de cambio. Supongamos el siguiente código que gestiona ésto (sin entrar a discutir si es adecuado o 100% correcto, que no lo es, ya lo sé, pero para ilustrar la idea vale).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58

class Currency
  TYPES = %w(euro dollar)

  attr_accessor :value

  def initialize(value)
    self.value = value
  end

  def to
    Exchange.new self
  end

  alias :in :to
end

class Dollar < Currency
  def to_s
    "#{value}$"
  end
end

class Euro < Currency
  def to_s
    "#{value}€"
  end
end

class Exchange
  cattr_accessor :rates

  def initialize(currency)
    @currency = currency
  end

  for currency in Currency::TYPES
    class_eval %{
      def #{currency}        
        rate = self.class.rates[:#{currency}][@currency.class.name.downcase]
        #{currency.classify}.new @currency.value * rate
      end
      
      alias :#{currency.pluralize} :#{currency}
    }
  end
end

class Fixnum
  for currency in Currency::TYPES
    class_eval %{
      def #{currency}
        #{currency.capitalize}.new self
      end
       
      alias :#{currency.pluralize} :#{currency}
    }
  end
end

De tal modo que, para cada petición sólo es necesario fijar una vez las tipos de cambio, usando para ello un before_filter …

1
2
3
4
5
6
7
8
9
10
11
12
13
14

def exchange_rates_set_before_filter

  # ... Lógica real para obtener los tipos de cambio ...

  Exchange.rates = HashWithIndifferentAccess.new({
    :dollar => {
      :dollar => 1,
      :euro => 1.49
    },
    :euro => {
      :euro => 1,
      :dollar => 0.67
    }
})

Y así poder escribir en nuestras vistas cosas sencillas y elegantes como:

1
2

1.dollar.in.euros #=> 0.67€
2.euros.in.dollars #=> 2.98$

Hacía ya mucho, mucho tiempo de mi último post, y David, el único de nosotros que parece lo suficientemente disciplinado como para escribir con alguna regularidad, había empezado a monopolizar este blog, así que aquí estamos de nuevo…

En general, los frameworks CSS consisten en una serie de ficheros CSS que han de ser enlazados por nuestras páginas y que proporcionan, entre otras cosas:

• Reseteo del navegador: los navegadores disponen de una hoja de estilos que define el estilo “por defecto” de las páginas que renderizan. Para evitar las diferencias entre navegadores y simplificar la tarea de desarrollar para múltiples navegadores se incluye una hoja de estilos que “anula” los estilos por defecto.
• Tipografía y estilos básicos: se fijan también algunos valores para la tipografía y algunos elementos HTML básicos (formularios, encabezados, párrafos, etc.).
• Layout o grid: a la hora de posicionar los elementos en pantalla, hay dos opciones: o bien utilizar una serie de layouts predefinidos por el framework, o bien posicionar elementos en un grid montado mediante CSS.
• Hacks o patches: para garantizar que todo se ve como debe en el IE o en otros navegadores.
• Plugins: algunos frameworks ofrecen la posibilidad de añadir plugins, que no son más que ficheros CSS adicionales y, ocasionalmente, imágenes de fondo, para crear determinados widgets como menús con tabs, formularios “chulos”, etc.

Existen multitud de frameworks CSS: Yahoo Grids CSS, Blueprint, Elements, Logicss, Schema, WYMstyle.

Nosotros hemos optado por YAML, y no porque su nombre nos suene rubyistico, que no somos de esos, sino porque, aparte del framework de Yahoo, es el que parece tener una documentación más amplia y, sobre todo, más útil (os la recomiendo como lectura, aunque no vayáis a usar el framework). Eso sí, también es de los que tiene un mayor número de ficheros y al principio resulta un poco complejo.

Como colofón, ya que parece que está de moda en este blog ponerse literarios, ahí va lo mío:

Car tout ce que je raconte, je l’ai vu; et si j’ai pu me tromper en le voyant, bien certainement je ne vous trompe point en vous le disant.

He dicho.