Programación ágil con Ruby on Rails

Transcripción

1 REDES Programación ágil con Ruby on Rails DABNE TECNOLOGÍAS DE LA INFORMACIÓN Conflicto de intereses en un escenario conocido: el cliente presiona para conseguir cambios en la aplicación que se está desarrollando: desde su punto de vista los cambios son aspectos obvios, poca cosa. El desarrollador se resiste a aceptar esos cambios: es tirar por la borda trabajo ya realizado. El comercial también se resiste: cambios significa más tiempo, y más tiempo significa menos dinero. Estas tensiones, inevitables, se atenúan si disponemos de metodologías de desarrollo menos rígidas y de estructuras de soporte para la programación más productivas. Ruby on Rails es una de esas estructuras de soporte. La escusa, los encuentros digitales La aplicación que vamos a desarrollar a lo largo del artículo sirve para gestionar encuentros digitales. Como es sabido, los encuentros digitales se organizan en sitios web, y permiten a los visitantes formular preguntas que, en un día y hora señalados, serán respondidas por un única persona, habitualmente famosa. Finalizado el encuentro, la lista de preguntas y respuestas queda disponible para su posterior lectura. Por regla general las preguntas son filtradas o moderadas, según su pertinencia, y solo pueden ser respondidas por el famoso/a en cuestión. Pero nuestra aplicación será mucho más sencilla: cualquier usuario podrá crear, modificar o elimar encuentros y preguntas (véanse las figuras 1, 2 y 3). Entonces qué sentido tiene un artículo que ilustre el desarrollo de una aplicación que no tiene nada del otro mundo? Figura 1. La aplicación muestra la lista de encuentros, con la posibilidad de modificar o eliminar los encuentros creados, y de añadir uno nuevo. Figura 2. La vista de un encuentro muestra las preguntas y sus respuestas, si las hay, con la posiblidad de modificar o eliminar preguntas, y de añadir una nueva. Figura 3. El añadido de una pregunta no muestra una vista muy elaborada pero cuántos minutos hemos empleado para conseguir que esta aplicación sea funcional? El objetivo, la programación ágil En la actualidad, conviven distintos paradigmas del desarrollo de aplicaciones. Algunas veces, la 54

2 Programación ágil con Ruby on Rails REDES especificación es lo más importante, y ceñirse a los requisitos es lo que conducirá al éxito del proyecto. Si los planos son muy detallados, es posible seguirlos al milímetro. Pero otras veces el usuario o promotor de la aplicación solo tiene una idea vaga de lo que quiere. Parte de nuestro trabajo consistirá en mostrarle posibilidades, opciones. En este caso, estamos ante un proceso imprevisible, que exige empezar a construir sin tener los planos. Qué hacer? Las métodologías ágiles vienen en nuestra ayuda. En lugar de hacer reuniones para hablar de cómo será la aplicación, dediquemos ese tiempo a construir un prototipo funcional que podamos mostrar en acción al cliente, y sobre el que plantear modificaciones y mejoras. En principio, como idea, esto está muy bien. Pero cómo hacerlo sin que el presupuesto se dispare? Ciertamente, uno de los inconvenientes de las metodologías ágiles es que son caras. El otro es que el cliente debe implicarse como parte del equipo de desarrollo. Por eso, las métodologías ágiles no siempre son adecuadas pero, incluso cuando lo son, para que sean operativas es necesario disponer de estructuras de soporte a la programación. Ruby on Rails es una de esas estructuras de soporte. El instrumento, Ruby on Rails Ruby on Rails (RoR) es una estructura de soporte (framework) para la programación web desarrollada en lenguaje Ruby. Ruby es un lenguaje de script, multiplataforma, orientado a objetos. Y todo ello es software libre. Ruby fue diseñado para un desarrollo rápido y sencillo: sencillo por fuera pero complejo por dentro. El lector encontrará en la edición 149 de Sólo Programadores un artículo de introducción a Ruby on Rails, con indicaciones para instalarlo. El artículo puede consultarse en la web de Dabne: Damos por supuesto que el lector ya tiene instalado Ruby on Rails, por lo que nos ponemos manos a la obra en la creación de la aplicación. No es preciso conocer Ruby para seguir el artículo. Más bien al revés, si Ruby on Rails convence, Ruby ya se aprerá. Primer paso, crear la aplicación Para crear la aplicación, (véase figura 4) abrimos InstantRails.exe, menú principal (botón Figura 4. Creación de la aplicación encuentrosdigitales. Figura 5. Cambio de directorio encuentrosdigitales. I ), opción Rails Applications.... Pulsamos en el botón Create New Rails App... y en la consola que se abre ejecutamos: rails encuentrosdigitales El listado 1 muestra la lista de directorios que se generan al crear la aplicación. Entramos en el directorio recien creado (véase figura 5): cd encuentrosdigitales/ Ahí podemos ver la estructura de directorios y ficheros creada por Rails para nuestra nueva aplicación, tal como se muestra en el listado 2. Nota: Si por algún motivo hemos cerrado InstanRails y queremos retomar el trabajo, al volver a abrir InstantRails se debe pulsar en el menú principal (icono I ), opción Rails Applications y luego Open Ruby Console Window. Con esto tenemos el esqueleto de nuestra aplicación Rails, en el que todo tiene un sitio predefinido. Al principio esta estructuración puede parecer un engorro, pero luego se agradece el no tener que pensar dónde hay que poner cada fichero. El código de nuestra aplicación irá dentro de app, los ficheros estáticos (css, imágenes, javascripts, etc.) irán en public, la configuración de la base de datos en config, etc. Rails viene con un servidor web incorporado que podemos usar mientras desarrollamos. Se trata de Mongrel. Para arrancar la aplicación con Mongrel, desde InstantRails, menú principal (botón I ), Rails Applications, Creación de LISTADO 1 la aplicación create create app/controllers create app/helpers create app/models create app/views/layouts create config/environments create components create db create doc create lib create lib/tasks create log create public/images create public/javascripts create public/stylesheets create script/performance create script/process create test/fixtures create test/functional create test/integration create test/mocks/development create test/mocks/test create test/unit create vor create vor/plugins create tmp/sessions create tmp/sockets create tmp/cache create tmp/pids create Rakefile create README create app/controllers/application.rb create app/helpers/application_helper.rb create test/test_helper.rb create config/database.yml create config/routes.rb create public/.htaccess create config/boot.rb create config/environment.rb create config/environments/production.rb create config/environments/development.rb create config/environments/test.rb create script/about create script/breakpointer create script/console create script/destroy create script/generate create script/performance/benchmarker create script/performance/profiler create script/process/reaper create script/process/spawner create script/process/inspector create script/runner create script/server create script/plugin create public/dispatch.rb create public/dispatch.cgi create public/dispatch.fcgi create public/404.html create public/500.html create public/index.html create public/favicon.ico create public/robots.txt create public/images/rails.png create public/javascripts/prototype.js create public/javascripts/effects.js create public/javascripts/dragdrop.js create public/javascripts/controls.js create public/javascripts/application.js create doc/readme_for_app create log/server.log create log/production.log create log/development.log create log/test.log 55

3 REDES Estructura de LISTADO 2 la aplicación. README Rakefile app controllers ` application.rb helpers ` application_helper.rb models ` views ` layouts components config boot.rb database.yml environment.rb environments development.rb production.rb ` test.rb ` routes.rb db doc ` README_FOR_APP lib ` tasks log development.log production.log server.log ` test.log public 404.html 500.html dispatch.cgi dispatch.fcgi dispatch.rb favicon.ico images ` rails.png index.html javascripts application.js controls.js dragdrop.js effects.js ` prototype.js robots.txt ` stylesheets script about breakpointer console destroy generate performance benchmarker ` profiler plugin process inspector reaper ` spawner runner ` server test fixtures functional integration mocks development ` test test_helper.rb ` unit tmp cache pids sessions ` sockets ` vor ` plugins Figura 6. Inicio de la aplicación con el servidor web Mongrel. Manage Rails Applications..., seleccionar encuentrosdigitales y pulsar en Start with Mongrel (véase figura 6). Se abrirá una consola donde aparecerán los logs y el mensaje de que pulsando Ctrl+C se cierra Mongrel. Ahora, si vamos al navegador y tecleamos en la barra de direcciones veremos una página de bienvenida de Rails, donde nos explica cuáles son los siguientes pasos que deberemos dar (véase figura 7). Segundo paso, crear la base de datos Figura 7. La aplicación en acción. Creamos una base de datos para el desarrollo y un usuario asociado para acceder a ella. En este caso usaremos MySQL pero podemos usar otras como SQLite o Postgres. El set de caracteres de la base de datos será utf8. Para ello, en el directorio InstantRails, ejecutamos las sentencias que se muestran en el listado 3. (Es preciso estar en una consola de Ruby, que se pude abir desde el menú principal de InstantRails, opción Rails Applications, Open Ruby Console Window. Observemos que el directorio actual será InstantRails/rails_app, por lo que habrá que moverse al directorio superior). En realidad deberíamos crear tres bases de datos, una para cada entorno de ejecución de Rails: desarrollo (development), pruebas (test) y producción (production). Rails incorpora el concepto de entornos para representar las etapas del ciclo de vida de una aplicación. El entorno se especifica en la variable de entorno RAILS_ENV. Cada entorno tiene su propia base de datos para no interferir con los demás. En desarrollo se recargan todas las clases cada vez que se produce una llamada a una acción, con lo que siempre se tienen cargados los últimos cambios realizados, evitando tener que reiniciar la aplicación. En producción se cargan las clases una sola vez buscando la eficiencia. En desarrollo la aplicación va mucho más lenta pero es más cómoda para el programador. En el entorno de pruebas se cargan todos los datos de pruebas en la base de datos para cada prueba que se ejecuta, indepizando así los resultados de unas y otras. Por este motivo hay que tener una base de datos aparte para pruebas, puesto que si no perderíamos todos los datos que tuviesemos en la base de datos cada vez que ejecutásemos las pruebas. Cuando Rails genera un nuevo proyecto crea un fichero llamado database.yml en el directorio config con secciones para configurar cada una de las tres bases de datos. Como Rails destruye todos los datos en la base de datos de pruebas cada vez que se ejecuta un test, hay que tener cuidado de no poner la misma configuración en la de pruebas que en las otras. Editamos el fichero config/database.yml (véase listado 4) y modificamos los datos de conexión a las bases de datos que acabamos de crear. (El directorio debe ser InstantRails/rails_apps/encuentrosdigitales/config/ ). Además, añadimos una línea para indicarle a Rails que el set de caracteres de la base de datos es UTF8. Dado que por defecto los ficheros que genera Rails están en utf8 esto es lo más recomable. Nota sobre la edición de ficheros: Como es natural, los ficheros se pueden editar con cualquier editor, pero es muy recomable que se guarden con la codificación UTF-8. El bloc de notas de Windows tiene una opción para ello. Más convención y menos configuración Ruby on Rails está construido siguio el patrón Modelo-Vista-Controlador (MVC). MVC es un patrón de diseño usado para separar el modelo de datos de la aplicación, la interfaz de usuario y la lógica de control en tres capas diferentes con unas mínimas depencias entre ellas: 56

4 Programación ágil con Ruby on Rails REDES LISTADO 3 Creación de la bd de desarrollo cd mysql mysql -u root CREATE DATABASE encuentrosdigitales_development CHARACTER SET utf8; GRANT ALL PRIVILEGES ON encuentrosdigitales_development.* TO usuario@localhost IDENTIFIED BY solop ; exit El controlador es el componente que recibe la petición del navegador y ejecuta la acción especificada por el usuario. El modelo es la capa de datos que se usa, generalmente desde el controlador, para leer, añadir, modificar o borrar datos almacenados, por ejemplo, en una base de datos relacional. La vista es la representación de los datos que el usuario ve en su pantalla. ActiveRecord es el sistema de mapeo objetorelacional en Rails, la M en el patrón MVC. La responsabilidad del modelo en el paradigma MVC es ocuparse de la gestión del almacenamiento de los datos de la aplicación. Sin embargo, ActiveRecord es más que una simple librería para ejecutar queries SQL: automáticamente mapea tablas de la base datos con clases en la aplicación Rails, crea métodos públicos para todos los campos de la base de datos y añade muchos otros métodos útiles para acceder los datos de la base de datos. Además, Rails hace suposiciones sobre los nombres de las cosas. Por ejemplo, el nombre del modelo es singular y la tabla que contiene los datos de ese modelo tiene el mismo nombre pero en plural. Si por alguna razón no nos gusta que sea así es fácil decirle a Rails que lo haga de otra forma. Si creamos un scaffold a partir de un modelo el controlador trá el nombre del modelo pero en plural. (Un scaffold es un andamio para nuestra aplicación. Es código generado para realizar las operaciones básicas, como crear, editar y borrar registros, con nuestros modelos. Podríamos crear las tablas de nuestra base de datos directamente con comandos SQL, pero Rails tiene un sistema muy bueno, e indepiente del gestor de base de datos que usemos, para definir la estructura de nuestra base de datos, escribiéndola en Ruby en los ficheros de migraciones y hacio que un adaptador la convierta a la sintaxis adecuada para nuestro gestor de base de datos. Además, de esta forma también podemos mantener un histórico de los cambios que vamos hacio en la base de datos y podemos avanzar o retroceder a la versión LISTADO 4 development: adapter: mysql database: encuentrosdigitales_development username: usuario password: solop host: localhost encoding: utf8 # Warning: The database defined as test will be erased and # re-generated from your development database when you run rake. # Do not set this db to the same as development or production. test: adapter: mysql database: encuentrosdigitales_test username: usuario password: solop host: localhost encoding: utf8 production: adapter: mysql database: encuentrosdigitales_production username: usuario password: solop host: localhost encoding: utf8 LISTADO 5 exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/encuentro.rb create test/unit/encuentro_test.rb create test/fixtures/encuentros.yml create db/migrate create db/migrate/001_create_encuentros.rb que queramos fácilmente. También facilita el despliegue en múltiples servidores de bases de datos, si la aplicación llega a tener esas dimensiones. Las migraciones se pueden generar indepientemente o al crear cada modelo. Tercer paso, crear el modelo Empezamos con nuestra aplicación generando un modelo llamado Encuentro (en una consola de Ruby, directorio encuentrosdigitales : ruby script/generate model Encuentro La salida será como se muestra en el listado 5. La salida del comando de generación del modelo será como se muestra en el listado 5. Como podemos ver en la última línea, Rails crea automáticamente una migración para este modelo. Ahí es donde definimos los database.yml ruby script/generate model Encuentro campos que va a tener nuestra tabla en la base de datos. El número 001 al principio del nombre del fichero indica que es la primera migración de esta aplicación. Cuarto paso, crear la migración Una migración tiene que implementar los métodos self.up y self.down, que son creados automáticamente al generar la migración. El código que hay en self.up es lo que se ejecuta al migrar la base de datos a una versión superior, y el código en self.down cuando migramos a una versión inferior. En nuestra primera migración creamos una tabla llamada encuentros y añadimos columnas/campos para el nombre y la descripción del encuentro. En self.down simplemente borramos la tabla creada, para el caso de que queramos volver a la versión 0, en la que la base de datos está vacía. 57

5 REDES Editamos el fichero db/migrate/001_create_encuentros.rb y añadimos los campos que se muestran en el listado 6. Si ponemos las columnas created_at y updated_at con tipo datetime o timestamp en nuestra tabla, Rails se encargará de rellenarlas automáticamente con los valores correctos. Todas la tablas usadas por ActiveRecord (excepto las tablas join) tienen que tener un campo de clave primaria llamado id. No lo especificamos en el código de la migración porque Rails lo crea automáticamente a menos que le indiquemos lo contrario (con la opción :id => false al crear la tabla). Para ver una descripción completa de las opciones disponibles en las migraciones, se puede recurrir a la documentación disponible en Migration.html. Ahora ejecutamos la tarea de migración de la base de datos, para que Rails se encargue de crear los campos que hemos especificado (en el directorio encuentros digitales ): rake db:migrate LISTADO 6 class CreateEncuentros < ActiveRecord::Migration def self.up create_table :encuentros do t t.column :nombre, :string t.column :descripcion, :text t.column :created_at, :datetime t.column :updated_at, :datetime def self.down drop_table :encuentros 001_create_encuentros.rb La salida del comando se muestra en la figura 8. Rails usa el entorno de desarrollo por defecto, con lo que los cambios se han hecho en nuestra base de datos de desarrollo. Si queremos que se produzcan en otra base de datos podemos especificar el entorno usando la variable RAILS_ENV en el comando rake: rake db:migrate RAILS_ENV=production Rails también ha creado automáticamente una tabla llamada schema_info. Esta tabla tiene sólo un campo, version, cuyo valor indica cuál es el número de migración actual. Los scripts de migración usan este dato para saber qué migraciones tienen que ejecutar para poner todo al día. Además, la migración crea un fichero llamado db/schema.rb, con el mismo formato Figura 9. Creación del scaffold para el modelo. que los ficheros de migración, que describe ruby script/generate scaffold Encuentro el estado actual de la base de datos en su La salida del comando puede verse en la totalidad. Los scripts de migración mantienen este fichero al día, con lo que no se Ahora editamos el fichero config/routes.rb figura 9. debería editar a mano. (directorio encuentrosdigitales ) para que por defecto vaya al controlador encuentros, añadio, como se muestra en la figura 10, la Quinto paso, crear el scaffold siguiente línea (alerta porque antes de la coma hay dos comillas simples y no una doble): map.connect, :controller => encuentros Como se ha mencionado anteriormente, un scaffold es un andamiaje de nuestra aplicación. Es código generado para realizar las operaciones básicas (crear, editar y borrar registros) con nuestros modelos. Generamos un scaffold para este modelo: El fichero routes.rb contiene las reglas para el manejo de las URL, quitándole esta responsabilidad al servidor web. Aplicando el principio de más convención y menos configuración, Rails realiza una serie de mapeos convecionales entre la vista y el controlador. Lo que queremos conseguir con la línea anterior es que cualquier petición de nuestra aplicación se dirija al controlador encuentros. Sexto paso, personalizar la vista Figura 8. Migración del modelo. Eliminamos el fichero public/index.html, que es donde está la página de bienvenida a Rails que veíamos antes, y vamos a 58

6 Programación ágil con Ruby on Rails REDES Figura 10. Asignando el control encuentros con edit, desde una consola, a la antigua usanza. LISTADO 7 en el navegador. Vemos la aplicación básica que ha creado el scaffold (véase figura 11). Lo que genera el scaffold es el punto de partida. Ahora habrá que irlo modificando hasta que nuestra aplicación tenga el aspecto deseado. app/views/layout/encuentros.rhtml <!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN > <html xmlns= xml:lang= es lang= es > <head> <meta http-equiv= content-type content= text/html;charset=utf-8 /> <title>encuentros digitales</title> <%= stylesheet_link_tag scaffold %> </head> <body> <div id= cabecera > <h1><%= link_to Encuentros digitales, :controller => encuentros %></h1> </div> <p style= color: green ><%= flash[:notice] %></p> <! Content start > <%= yield %> <! Content > <div id= pie > </div> </body> </html> LISTADO 9 Los layouts se usan en Rails para poner en un solo directorio el contenido común a todas las vistas, como son la cabecera de la página y el pie. Editamos app/views/layout/encuentros.rhtml para añadirle una cabecera y algunas otras Figura 11. La aplicación, tal como la ha creado el scaffold. LISTADO 8 public/stylesheets/ scaffold.css #cabecera { background-color: lightblue; padding: 20px; } cosillas (véase listado 7). Así tenemos una plantilla general para todas las acciones, en la que ponemos el código común a todas las vistas. Luego con la llamada a yield incluimos el contenido concreto de la vista correspondiente a la acción actual, que es lo que se encuentra en cada uno de los ficheros rhtml que hay en app/views/encuentros/. Como queremos que esta plantilla sea para toda la aplicación, no sólo para este controlador renombramos el fichero encuentros.rhtml como application.rhtml. Así se aplicará a todos los controladores que no tengan su layout específico (un fichero con nombre modelo_en_plural.rhtml en el directorio app/views/layouts/ ). Añadimos estilos para la cabecera en public/stylesheets/scaffold.css, como se muestra en el listado 8. Esta parte ya depe de las habilidades gráficas de cada uno y no entra dentro del objetivo de este artículo, así que lo dejaremos tirando a feote. Cambiamos la vista del listado de encuentros, que está en app/views/encuentros/list.rhtml, para que se vea más clara, como se muestra en el listado 9. app/views/encuentros/list.rhtml <% for encuentro %> <p> <%= link_to encuentro.nombre, :action => show, :id => encuentro %> <%= link_to image_tag( edit.gif ), :action => edit, :id => encuentro %> <%= link_to image_tag( delete.gif ), { :action => destroy, :id => encuentro }, :confirm => Seguro?, :method => :post %> <br> <%= encuentro.descripcion %> </p> <% %> <%= link_to Anterior, { :page } %> <%= link_to Siguiente, { :page } %> <p> <%= link_to Nuevo encuentro, :action => new %> </p> 59

7 REDES Como se puede ver hemos puesto imágenes en lugar de textos en los enlaces para las acciones de editar y borrar, con lo que ahora hay que poner en el directorio public/images los ficheros edit.gif y delete.gif correspondientes. En Internet hay multitud de iconos gratis e incluso libres que podemos usar, y además el lector puede encontrar estos ficheros en el cd-rom. Ahora vamos a editar la vista de creación de nuevo encuentro, para quitarle al formulario los campos correspondientes a las marcas de tiempo de creación y actualización, ya que Rails se encarga de rellenarlos automáticamente. Editamos app/views/encuentros/new.rhtml y app/views/encuentros/edit.rhtml para poner los textos en castellano, como se muestra en los listados 10 y 11. Como podemos observar, los campos del formulario no están en ninguno de estos ficheros y en su lugar tenemos una línea: <%= rer :partial => form %> Esto lo que hace es incluir el contenido del fichero _form.rhtml en ese punto, de forma que se pueden reutilizar trozos de código en las vistas. En este caso, ya que el LISTADO 12 LISTADO 13 LISTADO 11 <h1>edición del encuentro</h1> <% form_tag :action => update, :id do %> <%= rer :partial => form %> <%= submit_tag Editar %> <% %> formulario es el mismo para las dos acciones, está contenido en un partial que se incluye desde sus vistas. Obsérvese que el nombre de fichero de un partial lleva un guión bajo delante, mientras que en la llamada desde la vista sólo se pone el nombre, sin extensión y sin guión. Del fichero app/views/encuentros/ _form.rhtml borramos las líneas que se muestran en el listado 12 y lo dejamos como se muestra en el listado 13. app/views/encuentros/edit.rhtml <%= link_to Mostrat, :action => show, :id %> <%= link_to Volver, :action => list %> app/views/encuentros/_form.rhtml, final <%= error_messages_for encuentro %> <! [form:encuentro] > <p><label for= encuentro_nombre >Nombre</label><br/> <%= text_field encuentro, nombre, :size => 70 %></p> <p><label for= encuentro_descripcion >Descripción</label><br/> <%= text_area encuentro, descripcion, :cols => 80, :rows => 5 %></p> <! [eoform:encuentro] > LISTADO 14 class Encuentro < ActiveRecord::Base validates_presence_of :nombre validates_length_of :nombre, :maximum => 255 LISTADO 10 <h1>nuevo encuentro</h1> app/views/encuentros/_form.rhtml, borrar <p><label for= encuentro_created_at >Created at</label><br/> <%= datetime_select encuentro, created_at %></p> <p><label for= encuentro_updated_at >Updated at</label><br/> <%= datetime_select encuentro, updated_at %></p> <% form_tag :action => create do %> <%= rer :partial => form %> <%= submit_tag Crear %> <% %> <%= link_to Volver, :action => list %> app/models/encuentro.rb app/views/encuentros/new.rhtml Séptimo paso, pulir Con esto ya podemos crear, modificar y borrar encuentros, pero quedan algunas cosas por pulir. Por ejemplo, podríamos crear un encuentro con todos los campos vacíos (menos el id que crea automáticamente Rails), pero eso es algo que no queremos. Para evitar eso tenemos algo muy potente en los modelos, que son las validaciones. Con un par de líneas podemos hacer que nuestro modelo no acepte campos vacíos, o que compruebe la longitud de los textos. En nuestro ejemplo queremos que todo encuentro tenga un nombre y que ese nombre no exceda de los 255 caracteres, que es el tamaño por defecto del string que hemos puesto antes al definir los campos de la tabla encuentros en la migración. Eso lo conseguimos añadio en app/models/encuentro.rb las dos líneas que, en el listado 14, se muestran en negrita. Ahora, si intentamos crear un encuentro con el nombre vacío nos saldrá un error que nos explica qué ha pasado y nos vuelve a pedir los datos. De vuelta al paso tres Nuestra aplicación tiene encuentros pero no tiene preguntas. Creamos el modelo Pregunta (véase figura 12): ruby script/generate model Pregunta La salida del comando se muestra en el listado 15. Y al paso cuatro Figura 12. ruby script/generate model Pregunta. Editamos la migración db/migrate/002_create_preguntas.rb, añadio las líneas que en el listado 16 se muestran en negrita. Cada pregunta pertenece a un encuentro, por lo 60

8 Programación ágil con Ruby on Rails REDES LISTADO 15 exists app/models/ exists test/unit/ exists test/fixtures/ create app/models/pregunta.rb create test/unit/pregunta_test.rb create test/fixtures/preguntas.yml exists db/migrate create db/migrate/002_create_preguntas.rb LISTADO 16 class CreatePreguntas < ActiveRecord::Migration def self.up create_table :preguntas do t t.column :pregunta, :text t.column :respuesta, :text t.column :encuentro_id, :integer t.column :created_at, :datetime t.column :updated_at, :datetime def self.down drop_table :preguntas Figura 13. Ejecución de la migración. que ponemos una referencia al encuentro correspondiente. Ejecutamos la migración (véase figura 13): rake db:migrate Y al paso cinco Creamos el scaffold, respondio n a la pregunta overwrite public/stylesheets/scaffold.css? [Ynaqd] (véase figura 14): ruby script/generate scaffold Pregunta Cuando pregunte si sobreescribir el fichero public/stylesheets/scaffold.css decimos que no porque lo hemos modificado antes para incluir los estilos de la cabecera y si lo sobreescribimos perderíamos dichos cambios. ruby script/generate model Pregunta db/migrate/002_create_preguntas.rb app/models/pregunta.rb, como se muestra en las líneas en negrita de los listados 17 y 18. De esta manera, nos aseguramos de que se rellene el campo pregunta y el encuentro al que pertenece la pregunta. Después de todo esto, si vamos a y creamos una nueva pregunta vemos que no hay forma de relacionarla con un encuentro. Para eso editamos el fichero app/views/preguntas/_form.rhtml y añadimos el campo al formulario, agregando las dos líneas que en el listado 19 se muestran en negrita. Como en las vistas no debe ir nada de la lógica de la aplicación, la función que genera la lista de encuentros para el desplegable la ponemos en app/helpers/preguntas_helper.rb, como se muestra en el listado 20. Al generar el scaffold de un modelo se crea un fichero llamado modelo_helper.rb en app/helpers, donde podemos poner las funciones auxiliares que necesitemos usar en nuestras vistas. Si hace falta que una de estas funciones o helpers sea accesible desde las vistas de varios modelos hay que ponerla en application_helper.rb. Los helpers son útiles para mantener las vistas limpias y fáciles de leer. Las vistas no deberían contener lógica compleja. Si la hay, ésta se debería refactorizar y moverla a un helper. Los métodos de la clase helper se pueden llamar desde la vista. Ahora vamos a modificar la vista app/views/encuentros/show.rhtml para que se vean todas las preguntas asociadas a ese encuentro, como se muestra en el listado 21. Después de cada pregunta ponemos un icono con un enlace para editar la pregunta y añadirle una respuesta y otro para borrar la pregunta. Para que al editar la respuesta y darle a guardar vuelva a la pantalla anterior, modificamos la redirección en el método update del controlador ( app/controllers/preguntas_controller.rb), sustituyo la línea redirect_to por la que se muestra en negrita en el listado 22. En el mismo fichero, en el método destroy, también sustituimos la línea redirect_to por la que en el listado 23 se muestra en negrita. Para no perder el encuentro al que pertenecía la pregunta lo guardamos en una variable e. Siguio en el mismo fichero (app/controllers/preguntas_controller.rb), para que al pinchar en Añadir pregunta aparezca seleccio- Saltamos el paso seis También se ha generado un layout para este controlador, pero como queremos que use el general tenemos que borrar el fichero app/views/layouts/preguntas.rhtml. Y seguimos por el paso siete, pulir Añadimos las relaciones y las validaciones a los modelos en app/models/encuentro.rb y Figura 14. Creación de scaffold para el modelo. 61

9 REDES LISTADO 17 class Encuentro < ActiveRecord::Base has_many :preguntas validates_presence_of :nombre validates_length_of :nombre, :maximum => 255 LISTADO 18 class Pregunta < ActiveRecord::Base belongs_to :encuentro validates_presence_of :pregunta, :encuentro_id nado el encuentro desde el que hemos pinchado añadimos un parámetro :encuentro_id al enlace y en el método new lo asignamos al objeto pregunta, como se muestra en la línea en negrita del listado 23. De nuevo en el mismo fichero, para que al crear la pregunta vuelva a la pantalla del encuentro, no a la lista general de todas las preguntas modificamos la redirección en el método create, como como se muestra en la línea en negrita del listado 24. Ya que estamos editando el controlador podemos aprovechar y cambiar los textos en inglés por unos en castellano: flash[:notice] = Pregunta creada correctamente. flash[:notice] = Pregunta actualizada correctamente. Conclusiones LISTADO 21 LISTADO 22 app/models/encuentro.rb app/models/pregunta.rb En este momento del desarrollo de la aplicación, el lector puede manejar encuentros digitales y, para cada encuentro, preguntas. Es cierto que en vista de los encuentros los mensajes se han puesto en LISTADO 19 LISTADO 20 module PreguntasHelper def encuentros Encuentro.find(:all).collect { p [ p.nombre, p.id ] } def = Pregunta.find(params[:id]) flash[:notice] = Pregunta actualizada correctamente. redirect_to :controller => encuentros, :action => show, :id else rer :action => edit español y se han eliminado los campos Created at y Updated at, cosa que no se ha hecho con las preguntas, así que esta sería una buena manera de seguir pulio la aplicación. Por motivos de espacio y de simplicidad se ha omitido la validación de usuarios, pero el objetivo no es tanto desarrollar una aplicación como mostrar la manera de desarrollarla, al estilo Ruby on Rails. Con RoR, en cuestión de minutos disponemos de una aplicación operativa que empezamos a pulir, y que vamos mejorando mientras el tiempo app/views/preguntas/_form.rhtml <%= error_messages_for pregunta %> <! [form:pregunta] > <p><label for= pregunta_encuentro_id >Encuentro</label><br/> <%= select pregunta, encuentro_id, encuentros %></p> <p><label for= pregunta_pregunta >Pregunta</label><br/> <%= text_area pregunta, pregunta, :cols => 80, :rows => 5 %></p> <p><label for= pregunta_respuesta >Respuesta</label><br/> <%= text_area pregunta, respuesta, :cols => 80, :rows => 5 %></p> <! [eoform:pregunta] > app/helpers/preguntas_helper.rb app/views/encuentros/show.rhtml %></h2> %></p> <h3>preguntas: </h3> <ul> <% for p %> <li> <strong><%= p.pregunta %></strong> <%= link_to image_tag( edit.gif ), :controller => preguntas, :action => edit, :id => p %> <%= link_to image_tag( delete.gif ), {:controller => preguntas, :action => destroy, :id => p }, :confirm => Seguro?, :method => :post %> <br> <%= p.respuesta %> </li> <% %> </ul> <%= link_to Añadir una pregunta, :controller => preguntas, :action => new, :encuentro_id %> app/controllers/preguntas_controller.rb, update 62

10 Programación ágil con Ruby on Rails REDES y el presupuesto lo permiten. Desde la experiencia de dabne.net, Ruby on Rails aporta la posibilidad concreta y material de desarrollar según metodologías ágiles que integran los cambios en la especificación no como un escollo o un paso atrás sino como algo inherente al proceso de comunicación en el que comerciales, técnicos, clientes y usuarios estamos implicados. LISTADO 22 LISTADO 23 def = = params[:encuentro_id] app/controllers/preguntas_controller.rb, destroy def destroy p = Pregunta.find(params[:id]) e = p.encuentro p.destroy redirect_to :controller => encuentros, :action => show, :id => e app/controllers/preguntas_controller.rb, new LISTADO 24 def = Pregunta.new(params[:pregunta]) flash[:notice] = Pregunta was successfully created. redirect_to :controller => encuentros, :action => show, :id else rer :action => new Conferencia Hispana Rails 2007 Durante el próximo mes de noviembre se celebrará en Madrid la II Conferencia Hispana Rails ( De entre las propuestas de ponencia recibidas hasta el momento destacamos estas: APIs de Identidad y Rails Introducción en el mundo de las APIs más populares de la red como Flickr, Last.fm/Audiscrobbler o GoogleMaps. APIs Rest y proxificación Introducción a las APIs Rest y qué pueden aportar a nuestras aplicaciones. BDD y rspec Además del desarrollo guiado por tests, existe otro paradigma que va un paso más allá de éste: el desarrollo orientado a comportamiento. Caché en Rails Mecanismos para introducir caché en las diferentes capas por las que transcurre la resolución de una petición. Camping, el microframework Para qué podríamos querer usar Camping y cómo hacerlo. app/controllers/preguntas_controller.rb, create Cómo programar una araña web con Rails Taller práctico en el que se explicará cómo construir desde cero una araña web. Flickr con Rails Taller práctico para construir una interfaz interactiva con el servicio Flickr. Integración de Rails en el escritorio con Slingshot Slingshot es la alternativa Open Source propuesta por Joyent a los recientes desarrollos de Microsoft y Adobe para integrar aplicaciones web en el escritorio usando Ruby on Rails. Inteligencia artificial aplicada a la publicidad con Ruby Cómo utilizar la inteligencia artificial en Ruby on Rails para optimizar automáticamente la publicidad de una aplicación. Introducción a RubyStack Presentación y demostración de RubyStack, una distribucion integrada Open Source de Ruby on Rails. JRuby on Rails: Agilidad en la empresa JRuby on Rails proporciona la agilidad de Rails sobre servidores y aplicaciones Java. La internacionalización sí es posible Aunque Rails no tiene soporte incorporado para la internacionalización, hay muchas opciones para abrir las puertas de una aplicación a audiencias más grandes. Más allá del testing Vale. Tests. Sabes que los necesitas, sabes que tienes que hacerlos. Pero, por dónde empezar? Qué tal especificar el comportamiento de tu aplicación en forma de tests? Phobos: scripting de servidor para plataforma Java Phobos es un en entorno de aplicaciones ligero con el rimiento, escalabilidad y fiabilidad de la plataforma Java. Programa en Rails como si jugases con Lego Cómo funcionan los plugins de Rails y cómo podemos crear nuestros propios plug-ins. Proyectos de bajo coste con limitaciones severas de tiempo y recursos Existen aplicaciones cuyo desarrollo se plantea con una limitación de tiempo y recursos severa. Rails nos ayuda. Rails against the machine Cómo crear entornos virtuales clonables para el despliegue de aplicaciones Rails con Capistrano 2 y XEN. Rails desde el código Bajaremos a las entrañas de Rails y echaremos un vistazo a la implementacion del framework. Rails para torpes como yo Es difícil transmitir qué es Ruby on Rails y qué significa que nos guste y que estemos felices por programar en este lenguaje. Rails y Globalize: un tren con destinos internacionales Cómo Globalize puede enseñar a tu aplicación Rails monolingüe a aprer idiomas. Seguridad web en aplicaciones Rails Un repaso a la seguridad web y a algunas de las vulnerabilidades más comunes. Tractis, un enfoque técnico Con un enfoque lo más técnico posible, comentaremos cómo trabajamos y qué herramientas usamos. Unión de MXML con Rails Se tratará la unión del lenguaje MXML usado por la plataforma Flex con el framework Rails para conseguir una aplicación de las que Adobe denomina RIA. 63