El pasado miércoles 25, como evento enmarcado en las VII jornadas de Software Libre organizadas por el GPUL, Asís y David impartieron un taller de Ruby on Rails. El objetivo del mismo fue dar una visión global del framework mediante la creación de una pequeña aplicación de ejemplo.

Agradecemos al GPUL la invitación para participar en estas jornadas que nos permiten compartir nuestras experiencias y conseguir que cada vez más gente sepa que Ruby on Rails existe, funciona y que hay empresas utilizando esta tecnología en proyectos reales. Agradecemos también el interés mostrado por los asistentes y el alto grado de participación de los mismos.

En cuanto nuestra agenda nos lo permita, colgaremos en la sección de charlas de Trabe el material correspondiente a este taller. La charla fué grabada en video por parte de la gente del GPUL, por lo que suponemos que en algún momento estará disponible para su descarga. Avisaremos cuando tengamos constancia de ello.

El sábado pasado, trabajando en el taller sobre Ruby on Rails, nos encontramos con la siguiente situación, que se repite a menudo, al menos en nuestro caso: dos personas están buscando información en Internet sobre un mismo tema y, cuando una de ellas encuentra alguna página de interés, quiere compartir la url con la otra persona. Las dos se encuentran en la misma sala, a escasos metros, pero compartir la dichosa url es… tedioso cuando menos. Hay varias opciones, pero todas requieren algún “esfuerzo” extra:

• Se puede copiar y pegar la url en una ventana de IM, pero normalmente mientras trabajamos no estamos conectados, así que antes hay que hacer login y luego abrir una conversación y pegar la url. Demasiado trabajo.
• Se puede enviar la url por correo… sin comentarios.
• Se puede bookmarkear en un servicio online á la del.icio.us, pero ¿qué sentido tiene ese bookmark cuando la mayor parte de las veces su interés es pasajero? Además, para acceder al bookmark habría que conectarse antes a la página de bookmarks del que comparte.
• Se puede, por último, utilizar un servicio de clipping de urls. En este caso el problema está en que todavía tenemos que comunicar la url “clipeada” y esta varía de una a otra ocasión.

Así que decidimos montar FYPurl, que es un sencillísimo servicio que permite a cualquier persona “fypear” una url ¿Y cómo se traduce esto de “fypear”? Pues bien, cualquier usuario de FYPurl dispone de una url de la forma http://fypurl.com/nombre_del_usuario que puede apuntar a cualquier otra url. La acción de establecer la url a la que apunta el usuario se denomina “fypear”. La url del usaurio es su “fypurl”. Y, del mismo modo que se “fypea”, se puede “desfypear” la “fypurl”. Fyp.

Este sencillo mecanismo, combinado con un par de bookmarklets para el navegador (los “fypexpress”), permiten compartir rápidamente una url con cualquier persona que conozca nuestro nombre de usuario. Para mantener la sencillez, la “fypurl” es pública (no así las acciones de “fypear” y “desfypear”), así que hay que tener cuidado con lo que se “fypea”.

Espearamos que sea de utilidad para alguien. Para nosotros lo es.

Hoy podemos adelantar un poco más acerca del taller sobre Ruby on Rails del próximo miércoles.

El planning expuesto en el post anterior sigue vigente, pero ahora podemos dar algunos detalles más:

• La introducción teórica va a ser realmente breve: una transparencia para Ruby y dos para Rails. Todo lo demás se verá en la demostración práctica.
• La aplicación desarrollada será una lista de tareas, como habíamos dicho. Para desarrollarla utilizaremos el IDE RadRails integrado en un Eclipse (hay una distribución EasyEclipse con todo lo necesario ya montado). Por comodidad usaremos SQLite para el almacenamiento de datos.
• El taller práctico se dividirá en dos partes: la primera se centrará en los conceptos básicos del desarrollo con Rails y seguirá este guión
  • Crearemos la aplicación Rails
  • Generaremos el modelo para las tareas
  • Crearemos una migration para ese modelo
  • Utilizaremos el scaffold automático de vistas para introducir algunos datos y para generar un código básico que retocaremos después
  • Añadiremos el modelo de usuarios
  • Modificaremos la aplicación para poder asignar tareas a usuarios

Durante esta primera parte intentaremos tocar todos los temas posibles: generadores, migrations, ActiveRecord, relaciones entre modelos, validación de datos, vistas, helpers, ...

Por ahora, “hasta aquí puedo leer”. Tan pronto como esté lista la segunda parte, pondremos más información en este mismo post.

SIGO LEYENDO

Bien, esto está listo. La segunda parte se centrará en cuestiones más “efectistas”. Veremos cómo

• Modificar el modelo de las tareas para poder marcarlas como “hechas”
• Crear una acción a la que llamar mediante AJAX para marcar una tarea como “hecha”
• Usar plantillas RJS para visualizar los resultados de la llamada AJAX
• Usar las facilidades de Rails para realizar efectos con script.aculo.us
• Modificar un helper del framework
• Crear un feed RSS

Y esto es todo. El próximo miércoles veremos hasta dónde somos capaces de llegar.

Nos vemos en las jornadas.

El próximo miércoles día 25, a eso de las 19:00 de la tarde, David Barral y un servidor daremos un taller de iniciación al desarrollo con Ruby On Rails como parte de las VII jornadas de Software Libre organizadas por el GPUL. Lo que pretendemos es dar una introducción a Ruby on Rails aprovechando las experiencias acumuladas en este último año de desarrollo “profesional” con el framework.

Para aquellos de vosotros que estéis interesados en asistir, deciros que, si los planes no cambian de aquí al miércoles, nuestra idea es desarrollar una aplicación web para gestionar una lista de tareas. Puede que no sea algo muy original, pero al menos nos permitirá presentar los conceptos más básicos de Ruby on Rails, y que los asistentes que estén menos familiarizados con los frameworks de desarrollo web sigan con más facilidad el taller.

• Breve introducción al lenguaje de programación Ruby
• Introducción (teórica, pero poco) a Rails
• Desarrollo de la aplicación (modelo, controlador y vistas)
• Rails (algo más) avanzado (AJAX, RJS, plugins, etc.)

Los dos primeros puntos son teóricos, pero serán ligeros: sólo están ahí para poder entender lo que sigue. El grueso del taller será el tercer punto, el desarrollo de la aplicación en cuestión. Y por último, siempre en función del tiempo que sobre y la voluntad de la audiencia, introduciremos conceptos más avanzados. Esto es todo. Si no hay novedades, nos vemos el próximo miércoles en la FIC.

Este post tiene dos finalidades: apuntar un detalle de Rails para que nunca más se me olvide y quejarme(en vano) ya que, a veces, Rails tiene cosas que me resulta dificil entender como es el caso que nos ocupa. Veamos el siguiente fragmento de una inocente migration.

def self.up
  add_column 'users', 'energy', :integer, :null => false, :default => 0 
  signup_energy = 20

  User.find(:all).each do |u|
    u.update_attribute('energy', signup_energy)
  end
end

Parece lógico pensar que la energía de los usuarios al finalizar la migration será 20. Craso error. La nergía es 0, el valor por defecto. La razón es que la clase User está inicializada antes de la ejecución de add_column y por tanto en el momento de actualizar el atributo con update_attribute no existe un campo energy. SI hubiesemos escrito algo como…

User.find(:all).each do |u|
  u.energy =  signup_energy
  u.save
end

...obtendríamos una simpatica excepción. No hay problema, miramos la documentación de Migration y nos encontramos con un apartado que habla de esto y nos indica que debemos invocar el método reset_column_information para poder actualizar los accessors de las diferentes propiedades de la clase.

User.reset_column_information
User.find(:all).each { |u|  u.update_attribute('energy', signup_energy) }

Todo esto está muy bien, pero a mi me asalta una duda. Si esto es así, por qué demonios no se invoca esa función cuando se modifica una columna de una tabla de forma transparente al programador.

En fin. Es lo que hay.