Mis Tags > rubyonrails

Hoy es día de trastear con APIs, y he pensado que podía retomar una vieja idea de furilo(tm) y jugar un poco con la de bloglines.

Se trata de mostrar tu nivel de desconexión con la realidad en base a los posts que te quedan por leer en bloglines y aplicar un baremo. Ya que hemos empezado con el post de furilo, pues tomaremos la proporción que él planteaba: 787 items pendientes = 65% de desconexión, por lo que 1210 serían el 100%.

Podríamos hacerlo sin instalar absolutamente nada, simplemente deberíamos de tratar lo que devuelve el rpc, pero para facilitar el trabajo usaremos la gema Bloglines4R 0.1.0, que tiene poquitos métodos pero los suficientes para hacer lo que queremos. De hecho es una de las cosas más básicas que se pueden hacer.

• Conseguimos los posts pendientes de leer
• Operamos para obtener el porcentaje de desconexión
• Et voilà

 class BloglinesController < ApplicationController
 
   require 'bloglines'
 
   def desconector
     
     maximo = 1210
     
     begin
       
       bloglines = Bloglines::WebServices.new(:user => params[:id])
       post_pendientes = bloglines.update
       desconexion = (post_pendientes*100)/maximo
       @resultado = "Estoy al #{desconexion.to_s}% de desconexion"
     
     rescue Exception => e
       
       @resultado =  e 
     
     end
   
   end
 
 end
 

El manejo de excepciones en este caso no es más que recoger si el usuario existe o no (ni lo traduzco en este caso)

Podéis probarlo aquí mismo entrando a http://mamuso.net/bloglines/desconector/tuemail@debloglines.com. Si funciona a la velocidad de la tortuga coja es porque dreamhost es lento hasta decir basta (pero barato, eso sí).

Un host en condiciones, unos test (que el personal se me echa encima si no), un formateo en javascript para poder incrustarlo en cualquier blog de forma fácil, y servicio hecho :)

Yo estoy varios días desatendiendo mi bloglines así que según el script Estoy al 218% de desconexion. Así que voy a ponerme al día ya!

Ya ha pasado un tiempecito desde que me decidí a trabajar de forma más profunda con rails. Me tiré un tiempo tonteando con rails y pasé por la fase de alucinar con el scaffold y las aplicaciones en 15 minutos, pero mi día a día estaba muy enfocado a php y no le presté demasiada atención. Fue en la introducción que hicieron blat y álvaro donde me enganché y probé a hacer cosas más grandes basándome en rails. Ahora es casi mi ocupación principal.

En todo este poquito tiempo he ido disfrutando de los detalles que hacen más fácil el trabajo cada día. Los que más me gustan:

• Modelo - Vista - Controlador: Es una forma de trabajar muy cómoda, y se ha hablado hasta la saciedad de ella, pero la verdad es que cuando pasas de trabajar en php a rails cuesta quitarse el vicio de meter casi toda la lógica en la vista.
• ActiveRecord: Sin duda es una de las características de rails que más me ha cambiado la vida. En php hacer un simple CRUD es un mini infierno según la cantidad de campos que tengas en la base de datos. Y no te quiero contar nada cuando hay una modificación de la base de datos.
• Layouts: ActionView ofrece una gestión de layouts estupenda que nos permite trabajar con una sencillez extrema. Es tontísimo, pero de eso se trata :).
• El render de partials: Como estructura o como patrón de repetición dentro de una página los partials nos permiten ser un poquito más DRY.
• Observers: Podemos desencadenar mil acciones sólo con cambiar un objeto y todo de forma natural.
• Se basa en ruby: No soy un experto de ruby, de hecho todavía ando peleándome con el gran tocho en mis ratos muertos, pero es verdad que casi todo se puede escribir de una forma super natural. Y no queda ahí la cosa, el código es de lo más escuálido comparado con (por ejemplo) php. Escribimos menos código, por tanto cometemos menos errores, por tanto… (no me acuerdo cómo seguía la cadena, preguntádselo a Sergio) Ruby mola, no?
• Extender a base de plugins: La manera en la que rails maneja los plugins facilita mucho la vida a la hora de añadir funcionalidad a un proyecto: desde una autentificación hasta geocodificación.
• Desarrollar en local: Sin saber demasiado puedes crear tu propio entorno de desarrollo local. Si no sabes o no quieres instalar un server específico y configurarlo siempre puedes tirar de WEBrick que viene de serie.
• Con AJAX de serie: Viene con multitud de helpers que permiten integrar AJAX en tu aplicación casi sin escribir una sola línea de javascript. El más popular es el linktoremote.
• Todo es como yo te lo digo… o no: En rails todo se puede redefinir. Por poner un ejemplo, yo tuve que retocar la clase CGI para que interactuase como necesitaba con flash y no supuso ningún trauma.

Vamos… que me gusta rails.

Llevo unos días jugando con liquid y me parece una herramienta bastante flexible. Liquid es un motor de vistas para rails con la particularidad de usar un lenguaje extensible con mucha facilidad, de esta manera podemos limitar y controlar el código que se va a insertar en la maqueta.

¿Tiene sentido? Sí cuando no queremos que nadie introduzca en una vista código ‘no deseado’.

El famoso mephisto viene con liquid de serie y es un ejemplo de cómo se usa este plugin: instalamos una aplicación de la que (salvo rarísimas excepciones) no vamos a tocar nada del código de la aplicación y podemos editar y personalizar paquetes de vistas con el marcado de liquid.

Por mi parte creo que el uso de este tipo de plantillas tiene sentido sólo en casos concretos, por ejemplo:

• Cuando estemos desarrollando una aplicación en la que el cliente se encarga de modificar las vistas
• Cuando un gran número de usuarios usan una misma aplicación y tienen la posibilidad de editar sus plantillas (¿un sistema de blogs tal vez?)
• Cuando el maquetador no sepa nada de rails o la maquetación sea un departamento estanco dentro del equipo de trabajo (recordemos que un maquetador no tiene la necesidad de saber programar todo lo que caiga en sus manos, aunque para esto hay todo tipo de opiniones)

Recordemos también que el precio que pagamos por esto es tener que definir muchos métodos que finalmente se acabarán usando en la maqueta. Existen ampliaciones de liquid para mephisto que podemos tomar como base si nos hace falta crear un método y no sabemos por dónde empezar.

En definitiva liquid puede merecer la pena siempre y cuando se vaya a hacer un uso realmente justificado de él, si no creo que exige mucho para conseguir resultados.

Existen en rails otras extensiones (o sustituciones) de las vistas propias de ActionView, como puede ser MasterView o las subplantillas Markaby, pero decidir la adopción de cualquier opción distinta a ActionView nunca va a ser tarea fácil.

Estoy enamorado de los observers. Son muy básicos, casi de 'primero de rails', pero la verdad es que evitan muchísimo trabajo y son ante todo muy DRY.

En rails el observer es una clase más de ActiveRecord. El concepto no es nada novedoso: es un trigger que actúa cuando el objeto al que vigilamos cambia, a modo de callback. Sus usos son variados, pero me quedo con dos muy típicos pero muy útiles.

Por ejemplo, enviar un correo informativo cuando el estado de una solicitud ha cambiado, sacado de la misma página de rails.

   class SolicitudObserver < ActiveRecord::Observer
     def after_save(solicitud)
       Notifications.deliver_status("admin@do.com", "Se ha cambiado el estado de la solicitud", status)
     end
   end
 

Y el que más me gusta: hacer el trabajo sucio una sola vez. Ampliando el ejemplo anterior, imaginemos que hay que desencadenar varios cambios cada vez que uno hace un cambio en esa solicitud, o simplemente que tenemos un modelo desnormalizado de datos que nos obliga a mantener una tabla cada vez que algo cambia (y además nos manda el mail :) ). Pues nada más fácil.

   class SolicitudObserver < ActiveRecord::Observer
     def after_save(solicitud)
       addons = SolicitudAddons.find(solicitud.id)
       addons.updated = Time.now
       addons.status = solicitud.status
       addons.otrapropiedad = loquesea
       addons.save
 
       Notifications.deliver_status("admin@do.com", "Se ha cambiado el estado de la solicitud", status)
     end
   end
 

Así no tendremos que pensar que en cada acción que modifique el modelo de solicitudes hay que cambiar datos en otras tablas.

Se que es una chorradilla, pero me parece fascinante poder desencadenar esas cascadas solo con un pequeño cambio :)

Construir un feed de cualquier contenido en rails (a la MVC y sin addons) es una tarea relativamente fácil. El problema muchas veces viene del desconocimiento de las características concretas de los feeds.

El otro día Sergio sacó el tema de feedtools, una gema para tratamiento de feeds (tanto creación como parseo) de la que había oído hablar pero de la que no había hecho uso.

Con feedtools podemos formar documentos RSS, atom o cdf de forma sencilla sin tener que mirar muchas especificaciones. Simplemente conociendo la anatomía básica de un feed nos basta.

El funcionamiento es sencillo, con una consulta obtenemos todos los post/artículos/noticias que nos hacen falta para la construcción. Y ahora de esta forma tan simple formamos el feed.

 feed = FeedTools::Feed.new
 feed.title = "Título del feed"
 feed.author.name = "Si procede"
 feed.link = "aquí el link"
 
 @misresultados.each do |bloque|
   item = FeedTools::FeedItem.new
 
   item.title = bloque.mititlulo
   item.id = bloque.miid
   item.link = bloque.enlace
   item.content = bloque.cuerpodelenlace
   item.updated = bloque.fecha
   item.summary = bloque.resumen
   item.author.name = bloque.autor
   item.author.href = bloque.urldelautor
 
   feed.items << item
 end
 
 xml = feed.build_xml("atom", 1.0)
 

Tengo que reconocer que yo lo compliqué un poquito más, pero llegó Sergio con las 'rebajas del código' y lo dejó en este cachito enano.

Si lo que queremos hacer es crear el feed como estático y no actualizarlo bajo petición existe la posibilidad de hacerlo con feedupdater, y no parece difícil.

Para cualquier dudilla, a la api!

Para el que no pudiese ir a la conferenciarails o estuviese en alguna de las otras conferencias simultaneas dejo aquí las slides del Case Study: historiascepsa.com (algunas no valen de nada sin explicación :D).

Durante las próximas semanas colgaré algunas aplis de muestra para que podais trastear todo lo que tratamos pero más a nivel de código. No serán partes de la aplicación que se ha usado para cepsa, pero tienen la misma filosofía y la misma base.

Qué quereis que os diga... hoy soy un poco más feliz (y no sólo por trabajar on Rails). En la conferencia se respiraba un aire genial, y además desde mi punto de vista (siempre muy personal) fue un auténtico éxito, si cuando empezó a moverse el evento por las listas hubiesen dicho que iban a asistir más de 160 personas seguramente nadie se lo hubiese creido.

Se hablaron de temas realmente interesantes dentro y fuera de las ponencias, y sobre todo se notaba que existía el espíritu crítico, que en el fondo es el germen necesario para que las cosas salgan adelante.

Dentro de las ponencias hubieron unas cuantas que me encantaron, pero permitidme que no sea totalmente imparcial, porque la conferencia de Sergio me enamoró (de hecho yo tuve la suerte de verla dos veces, una en pase VIP), hasta compré el programming ruby, que menos mal que no lo venden al peso.

Blat por partida doble y María lo hicieron genial, y abordaron temas realmente prácticos. Pero si queríais pasión no teníais más que ver a Nando y a Álvaro hablando de la coctelera... precioso.

¿Y todo esto ha valido para algo? Pues tendríamos que verlo sobre algún ejemplo práctico. A la conferencia vinieron 3 amigos, phperos por necesidad, y que nunca jamás habían tocado RoR. Con la energía que les transmitieron los ponentes y todas las características que pudieron descubrir en los dos días, han decidido comenzar a trabajar con Rails. Sólo por cosas como esta, seguro que ha merecido la pena.

Si no fuiste tal vez quieras ver alguna de las fotos en la pool que han abierto en flickr, o bien podeis ir a ver el set de Joshua, que le han quedado geniales. Además dentro de unos días los materiales estarán colgados en la página de la conferencia, y muchos de los ponentes ya lo están haciendo en sus respectivos blogs.

Esto se iba a llamar "Tonteando un rato con rflickr", pero creo que va a ser una serie de posts con cositas curiosas sobre esta gema de rails.

Casi todos los que nos hemos puesto manos a la obra con rails hemos visto los famosos screencasts. A mi el de flickr me enamoró por lo sencillo que parece todo. Hace poquito necesité hacer una cosa bastante específica para una pruebecilla en rails y decidí investigar más a fondo la API de Flickr y su uso desde rails.

¿Por qué rFlickr? Pues porque tiene muchas más opciones para interactuar con la API, no sólo la de recoger fotos.

Antes de empezar:

Necesitarás una API key, hazte con ella.

Para una lista completa de lo que puede hacer rflickr te recomiendo que mires su documentación. Si no la tienes a mano mira en GemJack.

Al lio!

Bueno, lo primero que tenemos que hacer es ver cómo construye flickr la ruta al buddyicon.

Analizando la URL vemos 3 partes, de las cuales necesitamos averiguar 2:

• El iconserver, en este caso el 25.
• El user_id, en este caso el 59629307@N00.

El último número (1127666687) todavía no se lo que es, pero ya lo averiguaré, en este caso no nos hace falta para sacar el buddy.

Tenemos que partir de conocer al menos un dato del usuario. Los más usuales son el nombre de usuario o el email.

Si partimos del nombre de usuario la manera de obtener el buddy sería la siguiente:

  API_KEY = "xxx"
   SECRET_KEY = "xxx"
     flickr = Flickr.new(nil, API_KEY, SECRET_KEY)
     flickr.auth_mode = false
     usuario = flickr.people.findByUsername("nombre_de_ususario")
     datos_usuario = flickr.people.getInfo(usuario.nsid)
     @buddyicon = "http://static.flickr.com/"+datos_usuario.iconserver.to_s+"/buddyicons/"+datos_usuario.nsid+".jpg"