Novedades en RailsConf2006

Este fin de semana pasado ha tenido lugar la Railsconf 2006, donde se han dado cita las eminencias más preclaras del mundo Rails. Si no has estado allí, no eres nadie. O bien eres español.

<p>Tras leerme no pocas bitácoras &#8211; puede decirse, como era de esperar, que esta ha sido una conferencia <em>blogueada</em> en vivo y en directo -, ha habido dos presentaciones que me han llamado la atención (lo cual no es difícil porque está todo el mundo <em>blogueando</em> sobre ellas) y que creo que merece la pena irles echando un vistazo y tenerlas en el radar en el corto plazo.</p>

        <!--more-->

        <p>He echado en falta alguna presentación acerca de Armageddon, la supuesta implementación tipo <a href="http://es.wikipedia.org/wiki/Comet">Comet</a> basada en Rails de la que ha venido hablando <span class="caps">DHH</span>.  Supongo que otra vez será, de momento pasaremos a lo que <em>sí</em> que vendrá en un futuro próximo.</p>


<h3>Streamlined</h3>


<p>El <em>scaffolding</em> (que a mi me gusta llamar <em>andamiaje</em>) es una de las lucecitas de colores que trae Rails y que sirve para ganar adeptos.  Sin embargo las interfaces generadas de esta manera aunque son funcionales no son para nada atractivas.  De hecho hasta ahora una de los síntomas de la madurez de un desarrollador Rails es que ha dejado de usar la generación de <em>scaffolds</em>.</p>


<p>Hasta ahora.  <a href="http://streamlined.relevancellc.com/">Streamlined</a> promete hacer que esto sea cosa del pasado, gestionado de una vez por todas los layouts, y las relaciones entre diferentes entidades de nuestros modelos: por ejemplo, el andamiaje por defecto no hace mucho caso a las relaciones <code>has_one</code>, <code>belongs_to</code> y <code>has_and_belongs_to</code> (El <a href="http://www.sobrerailes.com/articles/2006/02/27/generador-de-scaffolds-con-ajax">generador <span class="caps">AJAX</span></a> disponible como plugin mejora bastante el aspecto, pero no aborda el problema de las relaciones en nuestros modelos)</p>


<p>Traduzco directamente de la bitácora de sus creadores:</p>


<blockquote>
    <p>La idea del scaffolding no es el problema; lo es la implementación. Las compañías que tienen muchos proyectos internos con tiempos de entrega muy ajustados (&#8220;empresariales&#8221;, me atrevería a decir) necesitan despreocuparse de la misma tarea cada vez que crean una nueva aplicación.  En concreto, la maquetación, la gestión de relaciones, las características de añadir, actualizar, y borrar, buscar y ordenar, etcétera.  Es el tipo de tarea en la que los equipos de desarrollo gastan miles de horas aplicación tras aplicación, incluso tratándose del mismo equipo trabajando en la misma compañía.</p>
</blockquote>


<h3>ActiveResource</h3>


<p>ActiveResource es la nueva criatura de <span class="caps">DHH</span> y <a href="http://dev.rubyonrails.org/changeset/4492">aquí podeis ver sus primeros pasos</a></p>


<p>Al parecer, <span class="caps">DHH</span> ha tenido una epifanía de la cual ha salido convencido de que la interfaz ideal de cualquier <span class="caps">API</span> es <acronym title="Create, Read, Update, Delete">CRUD</acronym>. Y cuando dice que es ideal no es que se deban implementar <em>al menos</em> esas operaciones, es que se deben implementar también <em>a lo sumo</em>.</p>


<p><span class="caps">DHH</span> hace notar la similitud de los <em>verbos</em> HTTP (POST, <span class="caps">GET</span>, PUT, <span class="caps">DELETE</span>) con las operaciones <span class="caps">CRUD</span>, así pues se pregunta si el <em>verbo</em> usado en el protocolo no podría usarse para indicar a nuestra aplicación la <em>acción</em> a realizar. (Es decir, invocar el método <span class="caps">HTTP PUT</span> sobre la <span class="caps">URI</span> <code>/blog/15</code> debería ser equivalente a lo que normalmente se hace con la <span class="caps">URL</span> <code>/blog/update/15</code>)  David piensa que este es el camino a seguir aunque por ahora los navegadores no den demasiado soporte a los verbos <span class="caps">PUT</span> y <span class="caps">DELETE</span> y haya que recurrir a <em>hacks</em> especialmente sospechosos como usar campos ocultos en formularios.</p>


<p>Todo esto no es nuevo, y se viene conociendo como interfaz <span class="caps">REST</span>, <a href="http://es.wikipedia.org/wiki/Representational_State_Transfer">cuya definición en la Wikipedia es esta</a></p>


<p>Así, según <span class="caps">DHH</span>, cualquier concepto en nuestra aplicación debería poder verse como un recurso con un interfaz <span class="caps">CRUD</span>/REST, y <strong>esa es precisamente la intención de ActiveResource</strong>: permitirnos con la misma facilidad con que consumimos registros de una BD usando ActiveRecord el consumir recursos publicados con una interfaz <span class="caps">REST</span> (y, según parece, incluso publicarlos nosotros mismos)  Me suena todo esto bastante a la <em>bala de plata</em> que prometían <span class="caps">CORBA</span> y <span class="caps">SOAP</span> algun tiempo atrás.  En este último caso, ActiveResource se puede ver como una alternativa a ActionWebService.</p>