Tengo que reconocer que soy bastante ignorante en todo lo relacionado tanto con Ruby como con el popular framework Ruby on Rails (RoR para los amigos y los fans de los acrónimos). Por lo tanto no tenía ni idea que instalar y utilizar Rails en ordenadores Mac fuera una tarea poco menos que homérica. Pero parece que es así ya que uno de los miembros del equipo del core de Rails ha iniciado una petición en Kickstarter para recaudar dinero para poder desarrollar una app de fácil instalación en máquinas con OS X… si, de esas que arrastras a la carpeta /applications y et voilà, todo listo.

El desarrollador en cuestión se llama Yehuda Katz y la suma de dinero que pide para poder meterse en faena es de 25000 dólares. El plazo para conseguir el parné es hasta el 12 de Mayo pero lo cierto es que le va a sobrar tiempo (y seguramente recaude mucho más) ya que a día de hoy ya van más de 20000 dólares recaudados. Por lo tanto parece que dentro de poco la vida para los railseros maqueros va a ser un poco más sencilla.

Como siempre en Kickstarter las donaciones tienen su correspondiente contraprestación, que en este caso van desde una carta de agradecimiento y una pegatina para las aportaciones más pequeñas hasta un logo bien grande de sponsor para aquellos que aporten 10 de los grandes (siempre he querido utilizar esta expresión) o más.

Amigos, el crowdfunding es el futúro, hacedme caso, almas cándidas…

Vía | Kickstarter
En Genbeta Dev | Si el crowdfunding le sirve a Tim Schafer, lo mismo te puede servir a tí

El verano en Madrid es para la piscina, las terrazas y, si eres desarrollador rails, para la Conferencia Rails. Del 13 al 15 de Julio (es decir, la semana que viene) se celebrará en el Florida Park del Parque del Retiro (un sitio muy flamenco) la susodicha Conferencia Rails, una cita ineludible para los desarrolladores rails y en el que habrá gran número de charlas y talleres a cargo de ponentes nacionales e internacionales, auténticas estrellas del medio, desde la gente de The Cocktail o Aentos hasta figuras como Sven Fuchs o Julian Fischer.

Programación funcional con ruby, Node.js, aplicaciones móviles, migraciones a ruby, Ruby in Rails, MongoDB o Coffeescript son solamente algunos de los temas que se tocarán durante estos tres días y lo mejor de todo es que todavía puedes registrarte y asistir… aunque si de verdad te interesara, deberías estar inscrito desde hace semanas, claro.

Un evento desde luego muy interesante y que viene a potenciar la escasa oferta para desarrolladores que propone la capital española cuando el solano empieza a pegar con justicia en los meses estivales.

Fuente | Conferencia Rails

Ahora que Rails 3.1 ha alcanzado ya la Release Candidate, y que la publicación de la versión final es inminente, qué mejor momento para retomar aquella lista de nuevas características que nos trae esta nueva edición del famoso framework para desarrollar aplicaciones web en Ruby.

No te pierdas tampoco la primera parte de este especial.

Migraciones reversibles más sencillas

Siguiendo la metodología DRY (“Don’t Repeat Yourself”), la definición de ciertas migraciones para cambiar el esquema de nuestra base de datos pasa a ser más sencilla, de modo que no sea necesario repetir instrucciones en los dos bloques de la migración (el de ejecución de la misma y el de deshacer los cambios) cuando éstas puedan ser fácilmente deducidas.

Esto significa que podremos especificar los cambios deseados en una tabla en un nuevo método change, y Rails se encargará de crear los métodos up y down por nosotros. Por cierto, estos últimos pasan a ser métodos de instancia, en lugar de métodos de clase. Si Rails encuentra ciertos comandos en el método change que no puede deshacer (por ejemplo, si se ejecuta un remove_column que elimina una columna de la tabla, y añadirla al deshacer no sería suficiente dado que se habría perdido la información que ésta contenía al ejecutar la migración), entonces se lanza una excepción ActiveRecord::IrreversibleMigration.

Por ejemplo, donde antes escribíamos algo como:

  class CreateTasks < ActiveRecord::Migration
    def self.up
      create_table :tasks do |t|
        t.string :title
        t.boolean :completed
        t.text :description
        t.timestamps
      end
    end


    def self.down
      drop_table :tasks
    end

Ahora escribiríamos simplemente:

  class CreateTasks < ActiveRecord::Migration
    def change
      create_table :tasks do |t|
        t.string :title
        t.boolean :completed
        t.text :description
        t.timestamps
      end
    end

Identity Map en ActiveRecord

Una de las características que más me gusta de DataMapper (un ORM bastante chulo y, hasta la introducción de Arel en Rails, con mejor sintaxis que ActiveRecord a mi parecer) es precisamente Identity Map. Esta característica sencillamente mantiene un hash con todas las instancias que se han hecho de una determinada clase que hereda de ActiveRecord, de modo que sólo exista en memoria una representación en forma de objeto en Ruby de un registro de la tabla en particular.

¿Por qué esto es importante? Porque hasta ahora, si instancias un objeto ActiveRecord, y llamas por ejemplo a un método que nuevamente instancia otro objeto el cual representa al mismo registro de la base de datos, y este último realiza un cambio en alguno de sus atributos, dicho cambio no se ve reflejado en el primero, porque ocupan espacios en memoria diferentes (a todos los efectos, son dos instancias distintas que representan a un mismo registro).

Para verlo más claro con código. En ActiveRecord sin Identity Map, se cumple que:

  post1_instance_1 = Post.find(1) # => #<Post id: 1, title: “Rails 3.1”>
  post1_instance_2 = Post.find(1) # => #<Post id: 1, title: “Rails 3.1”>


  # Parece que son la misma instancia, porque ActiveRecord redefine el método de comparación
  # y lo que hace es comprobar que los valores de los atributos sean iguales.
  post1_instance_1 == post1_instance_2 # => true

  # Pero verdaderamente, son instancias diferentes
  post1_instance_1.object_id == post1_instance_2.object_id # => false

Esto tiene una segunda consecuencia, y es que aunque dos consultas devuelvan instancias de registros repetidos para los que ya teníamos objetos en memoria, éstos se volvían a instanciar ocupando su propio espacio, devorando de forma aún mayor los recursos de memoria de la máquina, y obligando a la aplicación a consultar siempre los valores de la base de datos cuando se quiere instanciar un objeto.

Gracias a Identity Map, ActiveRecord consume menos memoria, es más rápido, y cada registro tiene una representación única en forma de objeto Ruby, de modo que cualquier cambio en el mismo sea consistente. No obstante, esta característica no estará habilitada por defecto debido a algunos problemas aún existentes con la instanciación de objetos a través de asociaciones.

Engines que pueden ser montados en una ruta determinada

Rails::Engine ha sido mejorado aún más, y ahora es posible montar una aplicación organizada en forma de engine en una ruta de una aplicación Rails. Estoy seguro de que esto mejorará aún más las posibilidades de reutilización de código y funcionalidades entre aplicaciones.

Por ejemplo, ahora podemos tener un engine que proporciona la funcionalidad de un blog, y montarlo en nuestra aplicación bajo la ruta “/blog” añadiendo en nuestro fichero routes.rb:

  Rails.application.routes.draw do
    mount Blog::Engine => “/blog”
  end

Mejoras en la utilización de las cabeceras HTTP para caché

A partir de esta release, Rack::Cache será parte del core del framework, y se espera que sustituya a la caché de páginas en un futuro (la cual podría quedar relegada a un plugin). Las ventajas de Rack::Cache para la obtención condicional del contenido de una página son evidentes: Con la utilización de las cabeceras HTTP Expires, Cache-Control, Last-Modified y ETag, es posible indicar de diferentes formas la validez de un determinado contenido, y evitar tener que enviar de nuevo toda la página cuando ésta es la misma que el navegador tiene en su caché, incluso aunque la misma se encuentre cacheada en forma de HTML y sólo haya que enviar su contenido sin tener que regenerarlo.

Evidentemente, esto permite ahorrar un mayor ancho de banda, y atender así más peticiones por segundo desde nuestra instancia de la aplicación.

Serializers personalizados

Si antes querías convertir un Hash, un Array, o cualquier otra instancia de un objeto Ruby en un objeto YAML, para poder serializarlo y guardarlo en un atributo de tipo text en la base de datos, sólo tenías que usar el método serialize de ActiveRecord::Base. Pero, ¿y si preferías guardar el valor en algún otro formato, uno que te permitiese guardar su valor en una forma que te facilitase futuras consultas en la base de datos, o que sencillamente ofusque un poco los datos? Tenías que construir una serie de métodos en tu modelo para asignar y leer los valores cada vez.

Ahora puedes dejar la mayor parte del trabajo a ActiveRecord, utilizando el mismo método serialize, pero especificando como parámetro un objeto que responda a los métodos load y dump, donde definir el algoritmo a utilizar para convertir el objeto en cuestión a texto y para generarlo de nuevo a partir del valor serializado. Por ejemplo:

  class Post < ActiveRecord::Base
    class CommaSeparatedList
      def load(text)
        return unless text
        text.split(”,”)
      end


      def dump(text)
        text.join(”,”)
      end
    end

    serialize :tags, CommaSeparatedList.new
  end

  post = Post.create(:tags => [“rails”, “ruby”])
  # INSERT INTO “posts” (“tags”, “created_at”) VALUES (‘rails,ruby’)

Más información | Rails 3.1 Release Candidate

El gestor de contenidos Refinery CMS ha alcanzado hace poco la release 1.0. Este gestor de contenidos escrito en Ruby on Rails era inicialmente un proyecto de software propietario, pero liberó su código hace ya dos años, y desde entonces ha sido mantenido bastante al día, aprovechando las características de las últimas versiones de Rails. Es por ello que se ha convertido en uno de los CMS más populares de entre los escritos con este framework de desarrollo web.

El proyecto goza de estupenda salud, gracias a los 138 colaboradores que durante su vida han ayudado a perfeccionarlo. Hoy soporta ya 25 idiomas de serie, y existen numerosos módulos para extender aún más su funcionalidad. Los numerosos sitios web que corren gracias a él avalan el reconocimiento obtenido.

Más información | Anuncio de la release 1.0 de Refinery CMS
Código fuente | GitHub

Seguimos con los especiales acerca de cuáles son las herramientas imprescindibles a la hora de embarcarte en un proyecto con tu lenguaje y/o framework preferido. En esta ocasión, os voy a describir las que yo considero más importantes para desarrollar aplicaciones en Ruby on Rails. Aunque estoy seguro que hay muchas otras que se os ocurren, así que os invito a que comentéis vuestras preferencias.

El editor o IDE

¿Usar un editor ligero, o un IDE que lo abarque todo? El eterno dilema. Yo la verdad es que soy de los que prefieren un editor más o menos sencillo, pero que sea fácilmente extensible a través de plugins. Mi elección ha sido desde hace mucho tiempo TextMate, un editor del que ya os hablé en su día.

No obstante, existen un buen número de IDEs para programar con Ruby on Rails que funcionan realmente bien, y que se pueden convertir fácilmente en tu centro de mando de todo el proyecto, gracias a su integración con sistemas de control de versiones, visor de base de datos, etc.

Uno de los IDEs más conocidos es RubyMine. Si bien no es gratuito (salvo que sea usado para proyectos de software libre), su precio no es descomunal, partiendo de 58 euros la versión para un desarrollador individual. A cambio de este dinero, se nos ofrece un entorno con un editor que permite el autocompletado de código, herramientas de ayuda para la refactorización, análisis de código al vuelo, visor del esquema de los modelos, soporte para Bundler o RVM, depurador, soporte para diversos sistemas de control de versiones… En definitiva, toda una navaja suiza. Está disponible para Windows, Mac OS X y Linux.

El otro IDE popular para programar en Ruby es NetBeans, que aunque es más conocido como un entorno para Java, existen unos módulos oficiales que permiten utilizarlo para este otro lenguaje. De nuevo, nos ofrece herramientas de ayuda a la refactorización, inferencia de tipos, navegación rápida entre ficheros relacionados, parseo de código mientras se escribe para detectar errores de sintaxis, y un largo etcétera.

El intérprete

Lógicamente, necesitamos una versión del intérprete de Ruby para poder trabajar. En los proyectos nuevos, ya no tiene tanto sentido utilizar la versión 1.8.x del intérprete oficial, y lo recomendable suele ser trabajar directamente con la versión 1.9.2 del mismo. No obstante, además de los intérpretes oficiales, existen muchos otros igualmente válidos, algunos de los cuales bastante potentes, y siempre que las librerías y gems que vayamos a utilizar en nuestro proyecto sean compatibles con estos, no existe ninguna traba para usarlos.

El intérprete oficial (también llamado CRuby) se puede descargar en sus diferentes versiones desde la página oficial del lenguaje, aunque si utilizas Linux seguramente te sea más fácil utilizar los paquetes que te proporcione tu distribución. Algunos de estos intérpretes alternativos a CRuby son: JRuby, Rubinius, Ruby Enterprise Edition, y otros muchos que aún tienen algunos problemas de compatibilidad con librerías habituales.

Si tuviera que mencionar un favorito de entre los alternativos, ese sería JRuby, ya que no sólo su rendimiento es espectacular, sino que además permite la ejecución de aplicaciones Rails en entornos donde sólo tienen cabida servidores de aplicaciones en entornos Java como pudiera ser GlassFish. Esto permite que puedas colocar tu aplicación Rails en servidores de empresas que ya están siendo usados para servir otras aplicaciones escritas en Java sin tener que cambiar mucho el entorno del servidor.

Si además deseas poder trabajar con varios intérpretes simultáneamente desde tu máquina, te aconsejo que le eches un buen vistazo a Ruby Version Manager (RVM). Aunque tengo intención de dedicarle un artículo por separado en breve.

Software de virtualización

Aunque a menudo Rails se utiliza como backend web de ciertas aplicaciones, es más habitual que sea usado para programar una aplicación web completa, incluido el frontend. Y claro, cualquier aplicación web que se precie ha de probarse bien en diversos navegadores, no sólo el que tengas en tu máquina. Es por ello que el uso de un software de virtualización se vuelve imprescindible.

Yo trabajo con Mac, pero dado que he de probar el renderizado de las vistas en Internet Explorer, he de instalarme una máquina virtual para poder tener Windows en ella con este navegador, que no existe para otras plataformas. Es más, lo normal es tener más de una máquina virtual, cada una con una versión diferente del navegador, para realizar las pruebas con un entorno lo más fiel posible a aquel que utilizará el usuario. Si trabajas en Windows, necesitarás poder probarlo en Safari. Si trabajas en Linux, puede que necesites probar tu aplicación en los dos navegadores anteriormente mencionados. En definitiva, seguramente necesites un software de virtualización.

De entre los más famosos, se encuentra VirtualBox (que ahora pertenece a Oracle), el cual corre en todas las plataformas y es gratuito. Aunque también puedes usar Parallels, una de las opciones preferidas si trabajas con Mac, o VMWare, un clásico del mundo de la virtualización que no defrauda.

ImageMagick

Es muy habitual que tu aplicación web necesite poder manipular imágenes subidas por los usuarios. Y aquí la navaja suiza suele ser ImageMagick, un software que permite hacer recortes, giros, redimensionados, adiciones de texto superpuesto, y decenas de otros efectos, a imágenes que estén en casi cualquier formato. Si bien lo normal es utilizar una gema de Ruby que facilite estas operaciones utilizando un DSL sencillo, estas gemas suelen luego traducir las especificaciones de tamaños y cambios de proporción que hayamos escrito en comandos que utilizan las herramientas ImageMagick. Así que es casi obligatorio tenerlas instaladas.

Firebug

Aunque he de decir que últimamente utilizo más las herramientas para desarrolladores de Chrome, la herramienta favorita para obtener resultados similares es sin duda Firebug. Gracias a esta extensión para Firefox, podrás inspeccionar el DOM, realizar cambios en el mismo, echar un vistazo a las peticiones HTTP realizadas, depurar código Javascript, analizar el rendimiento de tu aplicación, y otras muchas actividades realmente útiles durante el desarrollo. Imprescindible.

Cliente de base de datos

Si bien podemos operar con la base de datos desde línea de comandos, probablemente existan muchas operaciones (especialmente de consulta) que sería más cómodo realizarlas desde una interfaz gráfica más amigable. Si trabajas con MySQL y estás en Mac, te recomiendo que descargues Sequel Pro. Es una aplicación muy cuidada, y con la que podrás manipular a tu antojo cualquier aspecto de tu base de datos. Si prefieres tener una solución web, que corre en todas las plataformas, entonces te recomiendo phpMyAdmin, desde el cual podrás igualmente hacer la mayoría de las operaciones entrando con cualquier navegador.

Servidor de integración continua

Es realmente sano hacer que los tests escritos para tu aplicación se corran de forma automática cada vez que subes algo al repositorio de control de versiones. Para este propósito, mi preferido es Integrity, un servidor muy ligero pero no por ello menos potente escrito en Sinatra.

Organizador de tareas

Es necesario que llevemos un control de las tareas que hemos realizado, estamos realizando o pensamos realizar, así como que marquemos unos objetivos a corto plazo y registremos cualquier tipo de notas relacionadas con las tareas o bugs que nos sirvan de base de conocimiento. Para todo esto, y para organizar el trabajo en equipo, lo mejor es utilizar un servicio online que encaje con vuestra forma de trabajar. En este caso, mis preferencias se decantan por Pivotal Tracker, un servicio web de gestión de tareas online que encaja perfectamente con la filosofía de trabajo SCRUM. Pero si prefieres un entorno más clásico de tickets, milestones y cosas así, o si sencillamente prefieres poder instalar la herramienta de gestión en tu servidor, Redmine es probablemente tu mejor opción. Y como está escrita en Ruby on Rails, siempre puedes extenderla fácilmente para ir adaptándola a tus necesidades.

Conclusión

Estas son algunas de las herramientas que utilizo a diario, y que se han convertido en parte imprescindible de mi trabajo. Espero que te resulten útiles para empezar. Y si ya trabajas con Ruby on Rails, esperamos que nos cuentes cuáles son tus preferidas.

La nueva versión de Ruby on Rails está cada vez más cerca, y son muchas las novedades que nos trae. Así que me he decidido a recopilarlas y a enumerar algunas de las que considero más interesantes para que os vayáis haciendo una idea.

Debido a que estas novedades son muy numerosas, y para no escribir un artículo excesivamente largo, trataré de recoger las que más han llamado mi atención en al menos un par de posts.

Si quieres ir disfrutando ya de la primera beta, así como probar algunos de los cambios que paso a comentaros a continuación, podéis instalarla utilizando Rubygems mediante el comando:

  $ gem install rails —pre

Os aconsejo utilizar Ruby Version Manager (rvm) para poder tener instaladas varios entornos, y así no comprometer vuestro trabajo diario con Rails. Al igual que las versiones anteriores más recientes de Rails, el framework es perfectamente compatible con la versión 1.9.2 de Ruby, con lo que recomiendo encarecidamente su uso (¿todavía no usas Ruby 1.9.2 en tu entorno de producción?):

  $ bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)
  $ rvm install 1.9.2
  $ rvm 1.9.2@rails31 —create
  $ gem install rails —pre

jQuery pasa a ser la librería oficial

Pues sí, jQuery pasa a desbancar a Prototype y scriptaculous como las librerías de Javascript por defecto. He de decir que no me sorprende, pues la mayoría de los desarrolladores Rails que conozco usan ya esta librería para casi todos sus proyectos. Por supuesto, es muy sencillo usar otra si no te convence, pero ya sabemos que Rails se caracteriza por ser “opinionated software”, así que es normal que haya siempre una favorita.

Para mayor comodidad, la comunidad ha preparado un par de gemas que podemos añadir a nuestro fichero Gemfile, proveyendo así a nuestro proyecto de los ficheros necesarios correspondientes a estas librerías. En concreto, jquery-rails y prototype-rails. Es de esperar que aparezcan otras con el tiempo. Si quieres indicar la librería deseada desde el mismo momento en que creas el esqueleto de tu aplicación, puedes hacerlo utilizando el parámetro “-j”, seguido del nombre de la librería (“jquery” o “prototype”).

SASS incluido en Gemfile por defecto

SASS, o “Syntactically Awesome Stylesheets”, es una herramienta que merece ser nombrada en un artículo por separado. No obstante, resumiré que nos sirve para facilitar la escritura de nuestras hojas de estilo, permitiendo incluir en ellas reglas anidadas, variables, módulos que definen funciones que a su vez definen un conjunto de estilos, condiciones, bucles… En definitiva, nos permite eliminar código redundante en las CSS, simplificándolo bastante, de modo que sean más sencillas de mantener. SASS se encargará luego de convertir esos ficheros en hojas de estilo convencionales, que son las únicas que entiende el navegador.

Pues bien, en Rails 3.1 la gem para la integración de esta herramienta con nuestro proyecto viene incluida por defecto en el fichero Gemfile de dependencias.

Coffeescript de serie

Poco he de añadir a este hecho que ya fue comentado por mi compañero Toni el mes pasado. Pero consideré necesario incluirlo de nuevo en este artículo, para recordarlo. Si aún no has probado Coffeescript, te recomiendo enormemente que lo hagas, pues hará que tu código Javascript se reduzca a unas pocas líneas al mismo tiempo que disfrutarás de una sintaxis más parecida a Ruby para escribir código del frontend de tu aplicación.

Hojas de estilo y ficheros javascript fuera de public

Pues sí, a partir de ahora el lugar preferido para almacenar estos ficheros es en app/assets/stylesheets y app/assets/javascripts, respectivamente. Además, se utilizan nombres de fichero parecidos a las vistas, donde una primera extensión del fichero indica el formato de éste (ej: “js” o “css”), y una segunda extensión sirve para indicar el motor que se utilizará para generar este formato a partir del fichero original (por ejemplo, “coffee” para convertir un fichero escrito con Coffeescript en Javascript). En el directorio public sólo se almacenarían los ficheros ya procesados, los cuales además serían unidos para formar un único fichero Javascript y un único fichero CSS para toda la aplicación, gracias a Sprockets.

Preferencia por la sintaxis de Ruby 1.9

Los generadores de código de Rails 3.1 van a comenzar a usar sintaxis de Ruby 1.9 cuando estés usando esta versión del intérprete del lenguaje. Esto significa que los hashes por ejemplo van a empezar a escribirse de forma similar a los hashes escritos en JSON, que es la forma preferida de escribir un hash con Ruby 1.9:

  redirect_to posts_path, notice: “El post ha sido creado correctamente.”

Mejor salida para la ejecución de tests

Los resultados de la ejecución de los tests son ahora más claros con la inclusión de la gema turn, la cual utiliza un formato de salida a color para destacar mejor los tests que pasan y los tests fallidos, y en lugar de marcar simplemente los tests válidos como puntos y los tests erróneos o fallidos con los caracteres E y F, los describe cada uno en una línea utilizando el nombre del método definido en el fichero de tests (sustituyendo símbolos de subrayado por espacios), e incluyendo por cada uno de ellos el tiempo de ejecución.

Nuevos Rack en la pila de aplicaciones middleware por defecto

La utilización de aplicaciones Rack para tratar diferentes funcionalidades en cada petición se generaliza, con la inclusión de las siguientes al stack por defecto: Rack::Etag, Rack::ConditionalGet, Rack::Cache.

Soporte para streaming

Gracias a la inclusión de ActionController::Streaming, ahora se pueden responder a determinadas acciones mediante HTTP Streaming, si el servidor web lo soporta. Para activarlo en ciertas acciones de tus controladores, puedes incluir una llamada al método de clase “stream” con unos parámetros cuya sintaxis recuerda a la de los filtros de controladores. Por ejemplo:

  class PostsController < ActionController::Base
    stream :only => :index
  end

Definición de atributos accesibles según ciertas condiciones

¿Cansado de especificar tus propios métodos de actualización de atributos en tus modelos porque update_attributes no te basta, al querer diferentes comportamientos según el rol del usuario que esté realizando el cambio, o según se den ciertas condiciones? Con Rails 3.1, puedes proteger la actualización de diferentes atributos según el rol que se utilice durante dicha operación. Por ejemplo:

  class Post < ActiveRecord::Base
    attr_accessible :title, :published_at, :as => :admin
  end


  Post.new(params[:post], :as => :admin)

Más información | The Changelogs for Rails 3.1 Beta 1

A día de hoy, existen numerosas gemas de Ruby para realizar tareas realmente dispares. Y es que el número de éstas ha aumentado considerablemente en los últimos años, proveyendo a los desarrolladores de todo un pequeño universo de librerías útiles con las que facilitarles el trabajo. En este breve especial, voy a tratar de describir algunas de las gemas que considero imprescindible conocer, pues cubren algunas de las funcionalidades más habituales que solemos encontrar en forma de requisitos en muchas aplicaciones, de modo que podamos integrarlas en nuestra aplicación escrita en Ruby on Rails para cumplir sobradamente estas necesidades.

Carrierwave

Esta gema escrita por Jonas Nicklas nos sirve para añadir a nuestra aplicación la posibilidad de almacenar y procesar ficheros subidos por nuestros usuarios. Si bien han existido numerosos plugins para realizar esta misma función anteriormente (attachment_fu, paperclip, y otros), esta gema utiliza una separación de código bastante limpia, guardando cada uploader como una clase propia donde podemos especificar reglas concretas para manipular esos ficheros que nos adjuntan.

Se integra con cualquier aplicación Rack, de modo que podemos utilizarla tanto con Ruby on Rails, como con cualquier otro framework basado en este adaptador (Sinatra, Merb, Camping…). Además, es capaz de utilizar proveedores de almacenamiento como Amazon S3, Google Storage, Rackspace Cloud Files, y otros, de modo que los ficheros entrantes, una vez procesados, puedan ser guardados utilizando alguno de estos servicios. Al tratarse de módulos separados, es fácil extender la gema para agregar cualquier otro servicio de almacenamiento.

También permite utilizar RMagick, ImageScience o MiniMagick cuando los ficheros a tratar sean imágenes, de modo que podamos hacer recortes, escalados, y cualquier otro efecto sobre la imagen que soporte la librería que hayamos elegido. Nuevamente, esta funcionalidad se agrega en forma de módulo, de modo que podemos crearnos el nuestro propio para realizar cualquier otro tipo de manipulación deseada y que no esté soportada (ej: extracción de texto de un PDF, parseo de un archivo separado por comas, etc).

Su código se puede encontrar en Github.

Kaminari

Gracias a esta gema de Akira Matsuda, la paginación de objetos se torna sencilla y elegante. Nuevamente, existen muchas otras opciones perfectamente válidas, siendo la más conocida will_paginate. Pero esta gema aprovecha la posibilidad de definir scopes en ORMs como ActiveRecord, Mongoid o Mongomapper, de modo que su código se torna más sencillo, y la personalización del aspecto del paginador es bastante más elegante. De hecho, esta personalización visual es extensible en forma de themes, de modo que ya empiezan a aparecer algunas gemas con dichos themes para adoptar el aspecto de paginadores como los de GitHub, Google, etc.

La paginación no se limita a instancias devueltas por nuestro ORM favorito, sino que podemos paginar también arrays utilizando un wrapper:

  Kaminari.paginate_array(my_array_object).page(params[:page]).per(10)

Su código se puede encontrar en Github.

OmniAuth

Gemas para tratar el problema de la autentificación de usuarios hay muchas, aunque yo sigo más la costumbre de crear mi propio sistema de registro y autentificación de usuarios, ya que es una tarea relativamente sencilla y que permite luego un mayor grado de personalización (tratar de adaptar el comportamiento de gemas como Devise se puede tornar complicado).

Pero empieza a ser muy habitual que necesitemos permitir la autentificación mediante cuentas de otras plataformas como Facebook, Twitter, Google Apps, y otros. Y aquí es donde viene a ayudarnos OmniAuth.

Con esta gema elaborada por los chicos de Intridea, y habitualmente agregando tan sólo un nuevo controlador por cada servicio para crear la sesión, así como la carga de un middleware, podemos habilitar la posibilidad de que el usuario se autentifique usando su cuenta en ese servicio, así como obtener toda clase de información relativa al usuario que se ha logueado (nombre y apellidos, nick, email, etc; los datos proporcionados dependen del servicio utilizado).

Así que ya no hay excusa para añadir esta posibilidad a tu aplicación Rails. El código de la gema se puede encontrar en GitHub.

Ancestry

¿Necesitas añadir una jerarquía a tus modelos? Esta gema viene a tu rescate. Los resultados son similares a otros plugins como acts_as_tree, pero gracias a la gema de Stefan Kroes, el almacenamiento de la jerarquía es bastante eficiente, puesto que se guarda en cada instancia en forma de ruta de ids desde el objeto padre hasta la propia instancia (por ejemplo, “12/83” indica que el objeto actual tiene como padre al objeto con id 83, que a su vez tiene como padre al objeto con id 12), de modo que utilizando búsquedas de texto en este path se pueden obtener fácilmente elementos como los objetos raíz (aquellos cuyo path no contiene nada), los hijos de un objeto (aquellos que tienen en el path la subcadena con el id del padre seguida de una barra), etc.

La cantidad de métodos para moverse a través del árbol, así como comprobadores de condiciones (si el nodo tiene hijos, si es el único hijo, etc) es verdaderamente amplia. La forma en que los objetos que quedan huérfanos son tratados es personalizable. En general, una gema muy sencilla de usar, y que proporciona la funcionalidad de organización de las instancias de tu modelo en forma de árbol con una solución elegante y eficiente.

Su código en GitHub.

aasm

Por último, no quisiera dejarme a una gema de Scott Barron que nos permitirá construir una máquina de estados en nuestro modelo, de modo que podamos definir en ellos un conjunto de estados y de transiciones permisibles entre los mismos. Así, podemos separar nuestras instancias en dichos estados, y asegurarnos de que cuando cambien de un estado a otro, se ejecuten determinadas acciones definidas en nuestro modelo. También nos permite impedir que un modelo cambie de un estado a otro si no le está permitido. Es ideal para controlar cosas como el workflow de un objeto que representa un documento, tarea, etc.

Su código en GitHub.

Conclusiones

En posteriores posts, os hablaré de algunas de mis gemas favoritas en otras tareas como el testeo unitario. Mientras tanto, os pregunto: ¿Cuáles son vuestras otras gemas favoritas?

Como ya hemos comentado en alguna que otra ocasión, los programadores, maquetadores y desarrolladores en general no somos máquinas sino seres humanos que, en algún momento, podemos tener lapsus de memoria o no estar del todo seguros de la sintaxis de nuestro código. Es por ello que cada vez proliferan más las chuletas de lenguajes de programación (cheat sheets en el idioma de Shakespeare por si eres un hipster y tal). Si, como las que nos hacíamos en la carrera (negaré ante mis profesores haber escrito esto) pero en plan fino. Aquí os enlazamos unas cuantas, la mayoría en pdf o en formato de imagen para que las puedas descargar e imprimir fácilmente:

• HTML 5
• jQuery 1.3
• PHP
• Objective-C
• CSS 3
• Python
• Ruby on Rails
• Struts 2

Si la cosa gusta, pues habrá más entregas de estas proteínicas chuletas. Ricas, ricas y con fundamento.

JavaScript, ese lenguaje que hasta hace poco parecía de juguete para hacer el chorras en nuestras webs (poner nieve cayendo en Navidad, poner el cursor en crosshair al pasar por un enlace, esas cosas), tras pasar por la adolescencia de AJAX hoy en día pretende llegar a la adultez y ponerse el traje de lenguaje serio. Cada vez surgen más herramientas por y para JavaScript, para extenderlo y llevarlo a otros ámbitos. Sobre todo desde la aparición de Node.js, se discute cada vez más entre círculos desarrolladoriles si JavaScript es una basura de lenguaje o simplemente un incomprendido que bien usado tiene mucho potencial.

En los 90 y principios de los 00 la sintaxis «basada» (marcando las distancias) en Java de JavaScript lo mismo era lo más, pero hoy en día con sintaxis minimalistas llenas de syntactic sugar en pleno apogeo, como las de Python y Ruby, tanto paréntesis y tanto corchete tiene un aspecto bastante farragoso. Ahí es donde entra CoffeeScript, una sintaxis alternativa muy limpia que compila directamente a JavaScript.

Es una delicia ver el código de ejemplo en la página oficial, convirtiendo por ejemplo lo que en JavaScript sería esto:

var countdown, num;
countdown = (function() {
  var _results;
  _results = [];
  for (num = 10; num >= 1; num—) {
    _results.push(num);
  }
  return _results;
})();

En esto:

countdown = (num for num in [10..1])

Pues bien, la próxima versión de Ruby on Rails, la 3.1, parece que incluirá CoffeeScript por defecto. Esto supone un importante empujón para el proyecto, ya que antes había que compilar cada uno de los archivos en CoffeeScript que usáramos para poder incluirlos como JavaScript en nuestro proyecto, algo más engorroso que sencillamente escribir código y ponerlo a funcionar como en JavaScript nativo. Ahora, al estar integrado en Rails, y siempre, claro está, que hagamos uso de este framework, escribir en CoffeeScript será tan directo como en JavaScript nativo, y definitivamente mucho más cómodo.

De momento todo esto se sabe por un commit en el repositorio GitHub de Rails, donde por cierto en los comentarios se ha armado una buena por alguna razón. Por lo visto ha sentado mal que se incluya Coffee por defecto, aun cuando si no se quiere usar siempre se tendrá el JavaScript puro y duro (bueno, si se le puede llamar «puro y duro» a JavaScript).

En definitiva, una buena oportunidad para adoptar este nuevo lenguaje que pinta tan interesante.

Vía | Commit en GitHub de Rails
Más información | CoffeeScript

Dentro del amplio mundo del desarrollo de aplicaciones web hoy en día nos encontramos con un gran número de lenguajes con sus respectivos frameworks. Lejos ya de los años en los que Java, PHP o ASP se posicionaban como únicas opciones con monstruos como Struts, Zend o .Net, lenguajes como Perl, Python o Ruby se han ganado un espacio entre estos gigantes.

Gracias al inconmensurable trabajo de Yukihiro Matsumoto “Matz”, creador de Ruby, podemos disfrutar de un lenguaje muy natural, flexible y por que no, agradable para el desarrollador (personalmente fue una de las cosas que me hizo dar el salto de Java y PHP a Ruby, disfrutar programando). Matz liberó la primera versión de Ruby en 1995 pero no fue hasta 2006 cuando alcanzo su punto de esplendor, ayudado por la publicación en 2005 de la primera versión de Ruby on Rails.

Ruby es simple en apariencia, pero complejo por dentro, como el cuerpo humano. (Matz)

Nacimiento de un framework de futuro

Creado por David Heinemeier Hansson, como parte de su trabajo en 37signals.com en el proyecto Basecamp (gestor de proyectos SaaS que nosotros mismos usamos en el día a día). Gracias a Rails fue como tope con Ruby y con la ferviente comunidad que lo arropa. En aquella época mediados del 2006 fue cuando probé por primera vez Rails (versión 1.1.2) tras haber leído parte de una tesis de Michel Barbosa, un estudiante de la Universidad Erasmus de Rotterdam, que acaba de publicarla y que lleva como título: “Delivery of the Key Adoption Factors and Key Characteristics of Companies Using Ruby on Rails”.

En ella se encuentra el dato de que el 92% de la empresas que cambiaron sus framework de desarrollo web a Rails fue por que ¡disfrutaban desarrollando! No me le creí y decidí probarlo, sólo me hicieron falta dos comandos para darme cuenta de las maravillas que me esperaban:

• MCV aun que discutible en algunos casos, cada vez mejor definido.
• Scaffolding para crear modelos, vistas y controladores de una tacada.
• Convención de nombre muy cómoda y sencilla
• Fuera XML hola YAML
• DRY, REST y CRUD se incorporan al vocabulario del framework como una filosofía.
• Toda la potencia de Ruby (sencillez, clases abiertas, metaprogramación …)
• Una comunidad increíble creando gemas y plugins para casi todo.
• Testing integrado con el proyecto desde un inicio
• Flexibilidad para configurar y extender la gran mayoría de los objetos al vuelo

• ... no podía parar

Un poco de requisitos

Cualquier aplicación desarrollada en Rails corre en varios servidores web y es compatible con la mayoría de sistemas gestores de bases de datos (aun que el wrapper para Oracle es un poco infernal, funciona también :P). Apache y NGiNX son las principales opciones como servidores usando Phusion Passenger (aka mod_rails) como conector. A partir de ahí podemos darle mil vueltas, Mongrel, un cluster de estos, Lighttpd con FastCGI, Mongrels + Nginx…

Por dónde empiezo

Uno de los primeros pasas es empezar por al propia página de Ruby y visitar Tryruby donde podréis probar la sintaxis de Ruby ver como funciona para comprender los primeros pasos con Rails. The Ruby Way es una buena referencia para dar los siguientes pasos. Antes de que os deis cuentas estaréis programando de forma muy natural y espero que disfrutéis tanto que lo hacemos muchos ya.

Una vez que conocemos la sintaxis básica de Ruby es el momento de atacar a Rails. Una de las formas (y para mi la más divertida) de dar los primeros pasos es con Rails for zombies un site que os guiará a través de una serie de tutoriales donde explican las diferentes partes del framework y como trabajar con ellos (gratis claro).

Si ya te has enganchado después de un breve paso por The Walking Dead del mundo Rails es el momento de empezar a cacharrear. Ryan Bates (@rbates) es el creador de RailsCasts.org, en el momento que escribo este artículo va por el número #260… #260 motivos para probar y romper cosas, screencast desde un nivel básico hasta el uso de herramientas de benchmarking para sacar el mayor partido a os desarrollos.

Para arrancar ya con el código en nuestra máquina lo mejor es acudir a http://rubyonrails.org/download

Cómo no, IDEs

Como todo lenguaje Ruby tiene sus entornos de desarrollo, y tenemos bastante donde elegir. Los que más se usan actualmente es TextMate, Vim, Emacs, RadRails (basado en Eclipse, Netbeans o RubyMine.

Ahora mismo existe una corriente que está con Vim y otros que nos mantenemos fieles a TextMate (fuera de Mac, en entornos Linux su primo hermano es GMate, una adaptación de GEdit con extensiones que hacen que se parezca mucho a TextMate). Fuera de OSX o Linux, las principales opciones son RadRails y Netbeans.

Tanto en TextMate como en Vim después de llevar trabajando un tiempo con cada uno de ellos ya habréis ajustado Snippets, macros y acciones a vuestro gusto. Mi consejo es probar cada uno de ellos y desarrollar con el que os encontréis más cómodos.

El clásico blog en 15 minutos

Creo que todos a la hora de empezar con Rails hemos hecho este proyecto. A día de hoy hay cientos de blogs que tienen el artículo listo para su lectura, yo os dejo un enlace al vídeo paso a paso# para que lo probéis por vosotros mismos.

Los mitos sobre Rails

Para hablar de los mitos que existen sobre Rails necesitaría otro post aparte, pero lo resumiré de forma rápida, *Rails sí escala, como cualquier otra aplicación en cualquier otro lenguaje, eso dependerá de factores como el diseño de la aplicación, arquitectura escogida etc…

El otro y bastante sonado es que es duro de desplegar a producción. Como todos si eres fan de usar FTPs y volcados… Capistrano + Git (por ejemplo Github) y tras un setup no muy largo (no más de una hora la primera vez que montas uno) podrás hacer despliegues a golpe de un comando y pocos segundos.

Algunos mitos más son:

• Rails falla con frecuencia
• Rails es difícil por culpa de Ruby (obvio si no aprendes el lenguaje)
• Rails solo funciona con Prototype (con la 3.1 jQuery será la librería JS por defecto)
• Rails es poco maduro

• Rails no está echo hecho para el mundo Enterprise (más bien creo que es al revés)

Comunidad hispana

Dentro de los podcast podemos destacar el podcast de RailsHispano.

Podría seguir escribiendo bondades sobre Rails y Ruby pero lo mejor es que probéis por vosotros mismos. Espero poder tener la oportunidad de volver a escribir algo más técnico sobre Rails en este gran proyecto como es Genbeta Dev ya que junto con Rails las metodologías ágiles como SCRUM, Kanban, XP van muy ligadas a Rails y sería bueno hablar sobre ello.

Pablo Formoso Estrada socio fundador de SoftwhipserSL, empresa dedica al desarrollo RoR y dispositivos móviles (iOS y Android), lleva en el mundo de las programación desde los 14 años. Ponente en la Euruko 2009 y colaborador con El Correo Gallego en algunas entrevistas tecnológicas. Ahora a sus 27 se define como amante de las metodologías ágiles y movilidad. A finales de año espera junto con su socio en Softwhisper poder sacar producto propio.

Twitter: @pabloformoso