Verbos HTTP

Típicamente, se conocen del protocolo HTTP dos verbos: GET y POST. GET es el que se utiliza para pedir un contenido a un servidor web. Por ejemplo: GET http://jrom.net/ nos mandará el contenido de la URL pedida. También podemos añadir parámetros usando el verbo GET: GET http://jrom.net/?s=rails, en este caso, el servidor recibe que queremos la URL http://jrom.net/ pero con la variable s=rails.

El otro verbo conocido es POST. Normalmente se utiliza en los formularios mandan datos al servidor.

Sin embargo, hay más verbos HTTP que normalmente no se usan. Para poder usar una arquitectura REST, necesitaremos usar (además de GET y POST) los verbos PUT y DELETE. Estos ni siquiera son soportados por los navegadores corrientes, por lo que hay que simular que usamos esos verbos al hacer un enlace para un navegador, aunque sí que puede usar cuándo se nos use como webservice.

REST - CRUD

REST se puede ver cómo un sistema CRUD (Crear, leer, actualizar y eliminar) proyectado al protocolo HTTP. Podemos usar un verbo HTTP por cada acción CRUD:

• GET: Read, mostrar un objeto
• DELETE: Delete, eliminar un objeto
• PUT: Update, actualizar un objeto
• POST: Create, crear un objeto

$ ruby -v     

ruby 1.8.6 (2007-09-24 patchlevel 111) [universal-darwin9.0]

$ gem -v

1.1.1

$

Ahora, sólo hace falta escribir

$ gem install rails --include-dependencies

Y tendremos Rails instalado. Vamos a crear nuestra primera aplicación Rails:

$ rails hello_world_rails
      create
      create  app/controllers
      create  app/helpers
      create  app/models
      create  app/views/layouts
      create  config/environments
      [...]
      create  log/server.log
      create  log/production.log
      create  log/development.log
      create  log/test.log
$ cd hello_world_rails/

El comando rails <nombreaplicacion> en realidad lo único que hace es crear un directorio de nombre “nombreaplicacion” y llenarlo con el esqueleto de una aplicación Rails:

• app: El directorio donde mas lineas escribiremos, ahí es dónde va el código de nuestra aplicación.
• config: Se configura la base de datos, las rutas y parámetros para cada entorno de ejecución (development, test y production)
• db: Es donde tendremos los ficheros de migraciones de la base de datos, y si usas sqlite, también tendrás la base de datos ahí.
• doc: Por defecto está vacío, pero puedes generar ahí la API de Rails, o la API de tu propia aplicación con el comando rake.
• lib: Código Ruby que queramos tener accesible desde cualquier código de nuestra aplicación
• log: …
• public: Directorio que el servidor web servirá, es dónde se encuentra el dispatcher, y el contenido estático (css, imágenes, js, …)
• script: Código de Rails con los scripts que usaremos constantemente para generar más código
• test: Directorio dónde colocaremos el código de nuestros tests para probar la aplicación
• tmp: …
• vendor: Inicialmente vacío, pero ahí es dónde irán a parar los plugins que instalemos, y si queremos, podemos incrustar todo el código de rails para no tener que depender de la versión de rails que haya en nuestra máquina, e incluso, hacerle modificaciones

$ script/server
=> Booting Mongrel (use ’script/server webrick’ to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment…
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.4 available at 0.0.0.0:3000
** Use CTRL-C to stop.

$ script/generate scaffold Producto nombre:string descripcion:text precio:integer 

[...]

$ rake db:migrate

(in /Users/jordi/rails/hello_world_rails)
== 1 CreateProductos: migrating ===============================================
– create_table(:productos)
   -> 0.0038s
== 1 CreateProductos: migrated (0.0040s) ======================================

$ script/server

[...]

Casi cualquier proyecto de software, por pequeño que sea, requiere la intervención de más de un desarrollador. Todos los que hayamos participado en un proyecto dónde más de una persona colabora en un mismo código, nos hemos encontrado con los mismos problemas: ¿Quién tiene la versión buena? ¿Sobre qué código debo aplicar este cambio? ¿Has hecho cambios esta semana en el fichero tal?

La solución: Control de versiones

Se trata de tener una herramienta que gestione todos los cambios que sufre un determinado archivo por un determinado usuario. A eso lo llamamos Control de versiones. Hay una copia en un servidor que es dónde todos los desarrolladores deben acudir para empezar a trabajar (el repositorio). Entonces, el desarrollador parte de esa versión, hace los cambios que tiene que hacer, y sube sus cambios al servidor. Ha creado una nueva versión de los documentos que ha modificado (una revisión). Si otro desarrollador quiere trabajar en ese mismo fichero, observará que alguien ha efectuado cambios antes que él, y si ya tenia una revisión del código, se bajará los cambios hechos por su compañero para actualizar su versión local (la copia de trabajo).

Ventajas de usar un sistema de control de versiones

Usar un sistema de control de versiones nos proporciona muchas ventajas:

• Poder en todo momento ver cuál es la versión más actual del proyecto, quien y cuándo la ha subido.
•  Comparar cualquier par de versiones, dónde vemos todas las partes añadidas, modificadas o eliminadas de los ficheros entre las dos versiones. 
• Volver atrás en el tiempo a una versión que funcionaba, si los cambios que hemos hecho no nos han llevado por el buen camino. 
• Crear distintas ramas del proyecto, para que sigan caminos separados a partir de un punto. 
• Etiquetar distintas revisiones que representan una versión oficial del proyecto (para indicar que la revisión 4283 coincide con la versión del proyecto 2.4.0, la etiquetaremos por ejemplo: 2_4_0).

Sistemas de control de versiones populares

Ruby on Rails es un framework para desarrollar aplicaciones web que usan bases de datos. Esa seria la definición estricta que aparece en la web oficial de Ruby on Rails.

Yo definiría RoR cómo la solución a los problemas de casi cualquier desarrollador de aplicaciones web. RoR permite construir tu aplicación web consumiendo el 98% de tu esfuerzo en la propia aplicación, dejando que el resto simplemente funcione.

Ruby on rails es una herramienta creada por desarrolladores de aplicaciones web para desarrolladores de aplicaciones web. Y además es Open Source!

Rails vs el resto

Rails ofrece una arquitectura MVC (Modelo-Vista-Controlador), que nos separa el código de la interfície (Vista), la lógica de control (Controlador) y los datos (Modelo).

También destaca una potente herramienta de generación de código “por defecto”: el scaffolding. Gracias al scaffolding podemos crear un código básico para un recurso (por ejemplo: posts, personas, facturas, paginas, …) que nos permite crear, editar, mostrar y borrar instancias de ese recurso sin tener que escribir ni una sola línea de ruby. Partiendo de ese código crearemos el resto de nuestra aplicación.

En definitiva, la gran distinción de Ruby on Rails es que nos permite crear aplicaciones web en muy poco tiempo, con un código muy limpio, modular, reutilizable y con facilidades para escalar.