RESTful Web Services

Publicado por blaxter - 11/05/08 a las 18:05

Portada de “RESTful Web Services”Hace ya un tiempo que me acabé este libro. Su tema principal son los servicios web en general y los acordes a los principios REST en particular.

El libro contiene una 400 páginas, las cuales podrían resumirse y condensarse en una cuarta parte sin problemas, pero el autor continuamente está dando ejemplos y situaciones para plasmar cada concepto que explica. Incluso tenemos implementado, mostrando todo el código, un servicio web completo (gracias en parte a la brevedad de ruby).

¿Qué nos podemos esperar después de leerlo? Comprender de una vez por todas qué es eso del REST, término que asiduamente es malinterpretado y se ha convertido en una de las palabras clave a mencionar para quedar como si entendieses del tema (ya si lo nombras junto con rails, j2ee y [algo] business eres el puto amo).

¿Cuáles son los contenidos? En una primera parte nos habla de los servicios web en general, algo que puede servir para poner en contexto a quien no comprenda o este al tanto de qué y cómo son realmente.

Justo a continuación se nos explica toda la teoría y conceptos relacionados con la arquitectura orientada a recursos (ROA), la base y propósito de todo libro. Luego tenemos una aplicación de estos conceptos, tanto a nivel de diseño como a nivel de implementación. Estos capítulos, totalmente prácticos, sirven para afianzar todo lo anteriormente explicado, pues en pocas páginas el autor diseña e implementa aplicaciones reales (diseña un servicio de mapas, e implementa un agregador tipo del.icio.us). Después tenemos explicaciones concretas de aspectos específicos que podría llegar a tomarse como una referencia para crear servicios web que será realmente útil para cuando volvamos a recurrir al libro en momentos concretos de dudas.

Finalmente se hacen unas comparaciones con los WS-*, para mi sorpresa, sin meterse mucho con ellos (y no será por oportunidades…), pero que después de haber leído todo lo anterior choca bastante como todavía pueden existir cosas tan increíblemente estúpidas y absurdas (¡y que encima todavía se usan!). Para concluir también tendremos el capítulo de rigor sobre ajax y sus implicaciones al usar servicios web rest (pues una aplicación ajax puede tomarse como un mero cliente de un servicio web) y un breve recorrido sobre frameworks existentes que tratan REST (rails en ruby, django en python y restlet en java).

Este es un libro que lo recomiendo encarecidamente a cualquiera que esté o vaya a crear aplicaciones Web (que a día de hoy es como decir a todo el mundo). Incluso para quien crea haber usado exitosamente REST. Pues dada su popularidad creciente, es un término que continuamente se está enseñando y usando erróneamente (me incluyo aquí el primero, y eso que mi pfc iba sobre eso). Ha sido uno de los libros más vendidos del 2007 (de desarrollo de software claro) y no ha recibido pocos elogios que digamos.

Every developer working with the Web needs to read this book

David Heinemeier Hansson, creador de Ruby on Rails

Simplemente, un libro magnifico.

Generando javascript con código ruby embebido en rails 2.x

Publicado por blaxter - 03/05/08 a las 16:05

Hay veces que es bastante útil y cómodo devolver en una petición código javascript para que sea ejecutado en el cliente (y actualice el interfaz del usuario o lo que tenga que hacer). En vez de realizar (1) Petición, (2) Generar datos, (3) recepción y procesamiento, (4) actualizar página; pasamos a (1) Petición, (2) generar código, (3) actualizar página. Es decir nos ahorramos el parseo, además nos ahorramos tener que cargar javascript (que procesa las respuestas) en el cliente y usando jquery/mootools/* se realiza todo el proceso de forma transparente (indicando en la petición ajax que esperamos recibir un script). Esta técnica será válida solo para pequeñas actualizaciones (que son mayoría) y principalmente para temas de interfaz (que suelen ser triviales), pues en definitiva el código que no se ve, es código difícil de mantener.

En Rails tenemos templates RJS que básicamente consiste en lo que acabo de comentar pero generando javascript con wrappers en vez de usar js sin más, algo que me parece absurdo, pero eso es otro tema. Para rails 1.2.x teníamos este maravilloso plugin de Dan Webb que te permite escribir javascript con ruby embebido en él, algo como:

<% @ids_to_modified.each do |id| %>
   $(‘#’ + <%= id %>).removeClass(‘<%= @class_to_remove %>’).highlightFade();
<% end %>

Desde Rails 2.x ya no es necesario el uso del plugin (en parte porque ya no va), pues podemos hacer esto mismo gracias al nuevo formato de las vistas.

Ahora todas las vistas tienen el formato nombre.formato.template_engine, por ejemplo lo típico sería algo como: nombre.html.erb. Pero, ¿por qué no tener plantillas como nombre.js.erb?. De esta forma tendremos, sin incorporar plugins ni nada, la funcionalidad antes comentada, generar javascript permitiendo ruby embebido (es decir, usando erb).

Para hacernos la vida algo más simple, vendría bien incorporar ciertas funciones y helpers. En tu application.rb, no estaría de más tener algo como:

def respond_with_js
    respond_to{|format| format.js }
end

Por lo que nuestras acciones que vayan a ser llamadas mediante xhr tendrán una pinta tal que:

def vote
   # hacer lo que sea…
   respond_with_js
end

Tenemos que tener en cuenta también, que el javascript generado debe de ser válido (por ejemplo escapar comillas en las cadenas, o similares). Para asegurarnos que algo es javascript válido, nada mejor que usar json por lo que podemos pillar prestado del plugin de MinusMOR su helper (y añadirlo a application_helper.rb)

def js(data)
  if data.respond_to? :to_json
    data.to_json
  else
    data.inspect.to_json
  end
end

Por lo que ahora podemos escribir cosas tal que:

$(‘div.cancel’).append(
    <%=js link_to(‘Cancelar’, :action => ‘cancel’) %>
);
# o
alert(<%=js error_message_for(@error) %>);

Finalmente, si queremos usar partial’s tendremos que añadir este helper para soportar el nuevo formato de las plantillas (gracias a mad.ly):

def partial(name, options={})
  old_format = self.template_format
  self.template_format = :html
  js render({ :partial => name }.merge(options))
ensure
  self.template_format = old_format
end

Fíjate que no estamos sobreescribiendo el render :partial típico, es un helper simplemente. Para usarlo tendríamos que hacer algo como:

$(’#some_div’).html(<%=partial ‘movie_information’, :object => @movie %>);

En definitiva una forma mucho más cómoda, potente y simple de generar javascript desde el lado del servidor. Aunque insisto en que solo se debería de usar esta táctica para cosas triviales y pequeñas.

Menú de apagado de Gnome en Ubuntu lento de narices

Publicado por blaxter - 28/04/08 a las 20:04

En la última versión de Ubuntu, 7.10 Gutsy, ya me empezaba a ir algo lento al pulsar para salir, apagar, reiniciar, etc… del sistema. Tardaba unos 5 segundos en mostrar la ventana con las opciones. Asumí que era así y no le he dado más importancia. Pero ahora, con la nueva versión, Ubuntu 8.04 Hardy Heron, este tiempo de espera se había incrementado a cerca de un minuto. Algo totalmente inaceptable (y realmente molesto).

Buscando un poco, descubro que es un bug reportado sobre la anterior versión. Éste se debe a tener desactivado en los programas de sesión (Sistema > Preferencias > Sesiones) el gestor de energía (gnome-power-manager), el cual lo desactivé en su tiempo porque no quería usar ninguna opción de hibernación, suspensión o similares. El caso es que si lo tienes desactivado, va a ser un suplicio salir de tu sesión (supongo que debido a un timeout al intentar preguntar a un servicio, gnome-power-manager, que está apagado), así que lo activamos y todo solucionado, la ventana de salir de la sesión saldrá al instante, como debe ser. Ves qué bien.

Comparando reales sin terminos naturales

Publicado por blaxter - 17/04/08 a las 20:04

Lo sé, el título no tiene mucho sentido, pero quería hacer una rima. Veamos una pequeña sesión en la consola de ruby

>> value = 69.99
=> 69.99
>> value * 100
=> 6999.0
>> value * 100 == 6999.0
=> false
>> a = value * 100
=> 6999.0
>> b = 6999.0
=> 6999.0
>> a.class == b.class && a.is_a?(Float)
=> true
>> print "#{a} es distinto a #{b} obviamente" unless a == b
6999.0 es distinto a 6999.0 obviamente
>> a.floor
=> 6998

Nada fuera de lo normal, ¿no?. ¿O si?.

Stargate: Continuum, ¡ya para reservar!

Publicado por blaxter - 11/04/08 a las 19:04

Stargate: Continuum, la segunda y última película sobre Stargate, rodada a la vez que la anterior, será estrenada el 29 de Julio de este año, es decir, en menos de 4 meses. En Amazon, desde hoy, ya es posible reservarla por un precio muy asequible que traducido a euros te saldrá, con gastos incluidos, por alrededor de 15€ (los cobran cuando la envían, así que si sigue bajando el dolar igual hasta nos la regalan).

Si The Ark of Thruth ha sido una especie de capítulo doble poniendo punto y final a la trama de la serie, Continuum debería de ser una película propia que aunque muestre rasgos de la saga, alguien ajeno a ella pueda verla igualmente. Además, disfrutaremos de la presencia de Richard Dean Anderson, aka MacGyver.

Erlang: software para un mundo concurrente

Publicado por blaxter - 10/04/08 a las 22:04

Desde hace muchos meses quería meterle mano a Erlang. Lenguaje de programación funcional, concurrente y dinámico. Cada vez es más latente la importancia de la concurrencia, en unos años lo raro será ver procesadores de un solo core, o sistemas de un único nodo.

Acabo de empezar (con calma, que solo suelo leer en el bus) el libro de Programming Erlang de Joe Armstrong, que dado que es de la editorial de Dave Thomas, The Pragmatic Bookshelf me da muy buenas vibraciones.

Traduciré uno de los párrafos inicial del libro que crea unas expectativas realmente interesantes sobre este lenguaje creado por Ericson hace 21 años:

Erlang es un lenguaje donde la concurrencia pertenece al lenguaje de programación y no al sistema operativo. Erlang hace fácil la programación paralela modelando el mundo como un conjunto de procesos paralelos que únicamente pueden interactuar entre si mediante intercambio de mensajes. En el mundo de Erlang, hay procesos paralelos, pero no bloqueos ni métodos de sincronización y tampoco posibilidad de corrupción de memoria compartida, ya que no hay memoria compartida.

Los programas en Erlang pueden estar formados desde miles a millones de procesos extremadamente ligeros que pueden ejecutarse en un solo procesador, en uno de varios núcleos o en una red de procesadores.

Ahí queda eso. No sé si luego podré usarlo en entornos del MundoReal™ tan fácilmente como otros lenguajes más conocidos, pero solo por ver su enfoque al tratar los problemas creo que valdrá la pena. Por ahora ya tengo el interprete instalado y su equivalente a CPAN, llamado cean. Instrucciones para dummies, como un servidor (o eso me dice Amazon), en Ubuntu 7.10:

$ sudo aptitude install erlang
$ wget http://cean.process-one.net/download/cean.tar.gz
$ tar xfz cean.tar.gz
$ sudo mv cean-1.3/ /usr/lib/erlang/lib/
$ erl
Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false]

Eshell V5.5.5  (abort with ^G)
1> cean:version().
"CEAN Erlang/OTP"

Creative Commons License Esta obra está bajo una licencia de Creative Commons.

Este blog funciona gracias a WordPress con el theme GimpStyle diseñado por Horacio Bella y adaptado por un servidor.
Feed entradas