Programador Web Freelance - Ruby on Rails, Software Libre, GNU/Linux

Boris, la araña volcánica, la película:

…este es el vídeo de la charla sobre web spidering que dirigí el año pasado en Volcanica. El sonido no es muy bueno porque había ruido de fondo de la sala de al lado pero se agradece de todos modos!

También están disponibles las presentaciones para su descarga: introduccion_ruby_on_rails y ruby-web_spidering.

Puedes ver los vídeos de todo Volcanica 2007 en su web.

Este año cambiaré de tema y hablaré sólo de Ruby.

attachment_fu es seguramente el plugin de subida de adjuntos más usado actualmente en el mundillo Rails, aunque seguido bastante de cerca por el nuevo y también recomendable paperclip.

Un comportamiento que no me gusta de attachment_fu es que tras cada actualización del modelo, regenera el conjunto de thumbnails. Está bien que tras la creación de la foto procese la imagen para generar todos sus thumbnails, pero no me parece buena idea que si simplemente quieres actualizar cualquier otro dato del modelo, se vuelva a regenerar el conjunto de thumbnails.

Por ejemplo, si tienes un modelo Foto con todos los campos de attachment_fu pero además un campo título… cada vez que actualices la foto aunque sólo sea para cambiarle el título, se volverá a procesar la imagen para generar los thumbnails, dándole carga innecesaria al servidor.

Afortunadamente esto es código libre y fácil de entender así que mirando el fichero attachment_fu.rb, podemos encontrar esta línea que es la que hace que tras cada .save del modelo se procese el adjunto:

basta con cambiarla a esto:

para que sólo lo haga tras la creación del adjunto, y no en sucesivas actualizaciones.

Sería interesante mirarlo más en profundidad para que sí lo haga en caso de que le estemos pasando un nuevo fichero de imagen, pero por el momento me vale para mis propósitos… y de todos modos quizá es hora de irse cambiando a paperclip, que por lo que tengo entendido, no tiene este comportamiento… aunque tampoco es del todo cómodo porque he leído que para regenerar los thumbnails en paperclip es necesario lanzar una tarea rake.

Tras largos meses de intensa actividad haciendo malabarismos entre varios proyectos, llegó al fin el momento de la pausa veraniega. ¡Me marcho de vacaciones hasta el 8 de septiembre!

Aprovecharé para descansar, montar en bici, dar largos paseos, descubrir alguna ciudad nueva si me lo permite Ryanair y, por qué no, estudiar alguno de esos libros de Ruby que compré en su día y tan buena pinta tienen.

Nos vemos a la vuelta! Que descanséis también vosotros!

El año pasado dí un par de charlas sobre Rails en el evento Volcanica, y para la edición de este año (19, 20 y 21 de septiembre) me apetece centrarme más en Ruby…

Estas son mis propuestas para este año, una sobre introducción a Ruby y otra sobre Shoes, el toolkit para aplicaciones de escritorio con Ruby que me está divirtiendo tantísimo últimamente.

####################
1.- Programación en Ruby
####################

Ruby es un lenguaje de programación dinámico y de código abierto enfocado en la simplicidad y productividad, entre cuyos principios de diseño está el maximizar la felicidad del programador haciéndole la vida más fácil.

En este taller daremos un repaso a la sintaxis de Ruby, con ejemplos prácticos de programación y de uso de algunas de las librerías más interesantes de que dispone el lenguaje.

http://www.ruby-lang.org/es/about/

###############################
2.- Shoes, programación gráfica con Ruby
###############################

El lenguaje de programación Ruby no está limitado al desarrollo web y scripts de mantenimiento, sino que puede ser empleado también para la programación de aplicaciones de escritorio con interfaz gráfica basada en ventanas.

Shoes es un toolkit que nos permite programar aplicaciones de ventanas multiplataforma con muy pocas líneas de código, empleando Ruby. Además sus capacidades para gráficos, animaciones, y audio nos permiten programar juegos y demos.

Las posibilidades de Shoes y la sencillez de su sintaxis lo hace muy apropiado para enseñar a programar a niños, así como a los adultos que echamos de menos los años dorados del ZX Spectrum

http://code.whytheluckystiff.net/shoes
http://www.the-shoebox.org/

Más información sobre el evento Volcanica en:

http://www.volcanica.cat

Tras leer esta idea de Albert Coronado para convertir moneda con Google y PHP, se me ha ocurrido probar a hacer lo mismo con Ruby, y este es el resultado:

require 'open-uri'

class ConversorMonedaGoogle

  def self.euro_a_dolar
    google = open("http://google.es/search?q=1+Euro+to+%24").read
    pos_euro = google.index("1 Euro = ")
    pos_dolar = google.index("US$")

    google[pos_euro+9 .. pos_dolar-2]
  end

end

# Llamada de prueba...
puts "El euro está hoy a #{ConversorMonedaGoogle.euro_a_dolar} dólares según Google"

Básicamente, usamos la librería estándar open-uri para leer los resultados de buscar en Google “1 Euro to $”, y después buscamos el resultado mirando en el HTML devuelto como si fuera lo que es, simplemente una cadena de texto.

Como apunta Albert, hay que tener en cuenta que para usar esto en serio tendríamos que hacer cache del resultado, apuntarlo en base de datos, lo que sea, pero no estar consultando continuamente a Google porque sería muy lento.

Pero como idea, es divertido y además lo podemos extender a otras conversiones que nos proporciona Google

A raíz del artículo “4 simple steps to detect & fix slow rails requests” he descubierto un plugin muy interesante para detectar cuellos de botella en las consultas a MySQL desde nuestras aplicaciones Rails.

Se trata de query-reviewer, que se encarga de mostrarnos avisos directamente con una capa flotante en el navegador, cuando estamos en modo de desarrollo. El plugin analiza las consultas realizadas y nos indica si todo va bien, o muestra los avisos de que hay cosas que se podrían mejorar, por qué y cómo.

Tras un rato examinando los avisos generados y siguiendo sus consejos para añadir índices a las tablas y contadores a algunas asociaciones en los modelos, he incrementado por 3 la velocidad de respuesta de algunas de las partes de mis aplicaciones.

Aunque este año hemos tardado un poco en arrancar, el equipo de organización de la Conferencia Rails estamos de nuevo a la carga organizando el evento.

Ya nos puedes enviar tus propuestas de charlas, tanto si son ponencias técnicas como casos de éxito (qué mejor ocasión para promocionar tu nueva app)…

Toda la información actualizada en el blog oficial, www.conferenciarails.org y en nuestro canal de twitter, twitter.com/conferenciaror

Exception Notifier es un plugin muy recomendable para recibir notificaciones por email de los errores de tus aplicaciones rails en producción, con todo detalle de lo que ocurrió. Lo considero imprescindible en todas mis aplicaciones. Amaia tiene un excelente tutorial sobre Exception Notifier.

Por otro lado, si tu aplicación maneja mucho envío de emails, es recomendable usar algún sistema de colas para el envío de correos. Ar_mailer es una gema genial para esto, que permite delegar el envío de correos a un demonio de manera que los mails se apuntan en una tabla y el demonio los va leyendo de ésta para enviarlos en background.

Peeeeerooo… resulta que tras instalar ar_mailer, dejé de recibir las notificaciones de exception_notifier. Out-of-the-box ambos sistemas son incompatibles, con lo que en caso de ocurrir una excepción en la aplicación, cuando exception_notifier intenta enviar un email, no se entiende bien con ar_mailer y no se llega a producir el envío, dando un error 500.

Afortunadamente, googleando un poco encontré la solución. Basta con añadir esta línea al fichero config/initializers/exception_notifier.rb para que no no se use ARMailer para el envío de notificaciones sino que lo haga directamente (en lugar de a través de activerecord como se hace con ARMailer). En mi caso uso SMTP, pero también podría valer :sendmail.

ExceptionNotifier.delivery_method = :smtp

La semana pasada completé la reescritura de PageRankAlert.com y tras unos días funcionando en el nuevo servidor (slicehost, antes estaba en dreamhost), y unas pocas pruebas, la doy por inaugurada

Se trata de una limpieza de códigos y reescritura para sentar la base a las nuevas funcionalidades que tengo en mente y comenzaréis a ver en los próximos días.

Por el momento poca cosa nueva aparte de que ahora el PageRank se calcula en tiempo real (te devuelve el valor en el instante), y que además el bot notifica a través de Twitter, y un par de veces por día va contando las novedades:

http://twitter.com/pagerankalert

Y tú, ¿ya tienes tu lista de monitorización de PageRank para tus webs?

Gmail, al igual que Google Apps for Domains, se puede usar como servidor de correo saliente (SMTP) para nuestras aplicaciones Rails. Lo único es que como requiere autenticación TLS, no vale con usar simplemente “smtp.gmail.com” como servidor de correo saliente.

El plugin action_mailer_tls resuelve el problema rápidamente:

script/plugin install http://code.openrain.com/rails/action_mailer_tls/

Una vez instalado, en la carpeta /vendor/plugins/action_mailer_tls/sample encontrarás dos ficheros. Copia smtp_gmail.rb dentro de tu carpeta /config/initializers, y copia mailer.yml.sample a tu carpeta /config, renombrándolo a mailer.yml. Finalmente, edita este fichero para usar el user_name y password de la cuenta de correo de Gmail que quieras usar… reinicia el servidor y… ya puedes enviar correos a través de Gmail desde tu aplicación!

Más información en el blog de Daniel Fischer y en el README del plugin.