Sobre el papel Google Website Optimizer parece una herramienta de marketing estupenda. Nos permite definir unos objetivos y probar distintos contenidos o alternativas de una misma página para ver qué funciona mejor. El problema es que para ponerlo en marcha hacen falta dos ingenieros de caminos algunos conocimientos técnicos.

Tras seleccionar los objetivos google nos da huellas javascript para poner en cabeceras, pies, rodear secciones... Esta página da verdadero pavor la primera vez que la ves. No es de extrañar que antes de asustarte pregunte si lo vas a instalar tú o vas a contar con un equipo técnico para instalarlo.

Como miré en mis cajones y no encontré ningún 'web team' me imaginé que esto iba a tener que acabar probándolo en mis propias carnes, así que pensé ¿que haría McGiver?, o mejor, alguien más vago ¿qué haría Porras?. Evidentemente algo que me quitase de trabajar más de una vez en esto.

Buscando lo que había hecho por ahí encontré este plugin, que incorporaba unos helpers monísimos pero no me valía por tres cositas:

• GWO es para usarlo una temporadita, decidir qué contenido es el que nos da mejor rendimiento y olvidarlo. Así que si puedo evitar modificar la aplicación mejor.
• Tengo que incluir scripts concretos en páginas concretas. Si todas mis páginas comparten layout y quiero tener varios experimentos activos al mismo tiempo me toca montar la fiesta del 'elsif' o alguna similar, y... si puedo evitar modificar la aplicación mejor.
• Si esto del GWO al final es buena idea, que parece que sí, van a querer usarlo en más sitios, y si yo o cualquiera de los agraciados podemos evitar modificar las aplicaciones... mejor!

Así que lo descarté y traté de construir algo que cumpliese con todo lo anterior.

Y de la vagancia más absoluta ha salido la primera versión de gwo_on_rails, un pequeñisimo plugin que te permite integrar este servicio tirando de un triste (pero bonito) yaml.

Está por limpiar, refactorizar y podar, amen de hacer tests más robustos, pero la realidad es que simplifica bastante el trabajo y ya está funcionando en un site en producción, en una home, a las mil maravillas sin modificar para nada la aplicación: instalar y rellenar el fichero de configuración.

¿Se puede pedir más? seguro que sí, hay partes que seguro se pueden resolver de formas más eficientes y otras que se a ciencia cierta que son un poquito matar moscas a cañonazos, así que cualquier sugerencia para mejorar el plugin será recibida con los brazos abiertos.

Hace ya más de un añito que unvlog salió a la luz y durante todo este tiempo hemos ido añadiendo soporte para más servicios de video a la criatura.

Como cualquier 'equipo A' que se precie teníamos un plan: sólo integraríamos servicios que tuviesen API. Pero un día implementas el primero que no la tiene, después ves que la estructura inicial la podías haber planteado de otro modo... y a la vuelta de un año tienes un montón de código esparcido por controladores, modelos y módulos que necesita orden.

De este 'barrer la casa' ha salido el plugin acts_as_unvlogable que permite sacar de varios servicios de video, más o menos populares, una información básica a partir de la url.

Por ejemplo. Si tenemos este preciosos video de vimeo: http://vimeo.com/1766353 podemos averiguar su título, conseguir un thumbnail, la url del embed, el html necesario para embeberlo y la url del flv así de fácil:

 
 video = UnvlogIt.new("http://vimeo.com/1766353")
 video.title
 # => "Nice Clean White"
 
 video.thumbnail
 # => "http://images.vimeo.com/ [...] /141150563_506.jpg"
 
 video.embed_url
 # =>  "http://vimeo.com/moog [...] how_portrait=1"
 
 video.embed_html(400, 300)
 # => " object width='400' height='300' [...] /object"
 
 video.flv
 # =>  "http://www.vimeo.com/ [...] /video.flv"
 
 

La elección de estos datos y no otros es porque nostros utilizamos en la aplicación, y porque es el minimo común en todos los servicios.

Para saber cómo instalarlo, conocer todos los métodos y en general para tener información totalmente actualizada te recomiendo que le eches un vistazo a la página del plugin.

El plugin tiene dos dependencias, youtube-g y hpricot.

En esta versión del plugin los servicios soportados son:

• Youtube
• Google video
• Vimeo
• Flickr (videos)
• Metacafe
• Dailymotion
• Collegehumor
• Blip.tv
• Myspace
• Ted Talks
• 11870.com
• Qik
• Marca.tv
• Dalealplay

Estamos abiertos a incluir muchísimos más, no os cortéis en pedir! Además todos los que vayamos integrando en unvlog, acabarán en el plugin.

La intención es mantener el plugin vivo y hacerlo evolucionar, así que si lo usáis en una aplicación y encontráis cualquier fallo o deja de funcionar algún servicio o tenéis alguna idea para hacerlo más útil nos gustaría que nos lo contases en nuestro sistema de soporte.

Hoy hemos hecho un import masivo de imágenes a una web, y han quedado así, tan bonitas con todos sus tamaños bien buestos gracias a attachment_fu (vía RMagick).

Cuando he ido a la web a comprobar qué tal quedaba todo me he dado cuenta de que los thumbnails generados descargaban lentitos, así que por pura casualidad me dió por mirar el tamaño de cada imagencita de 50x50 pixeletes de nada.

Mmmm.... 60kb!!!! WTF!!!!

Vale, tranquilidad... es un error... voy a mirar mi importación en local que seguro que está mejor.

Pues mira no, está igual :)

La primera solución, y la más obvia, es la de tocar la calidad de la imagen en la importación en rmagick, de hecho <a href="http://sobrerailes.com/">Lupión</a> me envió este post donde incluso te hablan de tocar la imagen de forma selectiva en función del thumbnail.

Así que nada... toco mi métodito en attachment_fu y le casco una calidad de 70 y... ya está!!

Reimportamos mientras me tomo un cafetito y... ale, ha terminado. Esto no puede haber salido mal, pero por si las moscas voy a ver qué ocupa la misma image de 50x50.

Aha... 45kb... mecagoen!!!!!

Antes de sacar el hacha vamos a ver qué puede tener esa imagen. Command + i y...

Aha... así que este thumbnail se ha hecho con una nikon :)

El caso es que RMagick al manipular una imagen no nos elimina ni los posibles comentarios y notas que pueda tener la imagen, ni ninguno de sus perfiles, ni exif... vamos, que se viene con todos los metadatos puestos. En una imagen mediana o grande tal vez esos Kbs de más no molesten, pero en cositas tan pequeñas yo prefiero eficiencia a sobreinformación.

Podemos ser mucho más selectivos, pero por lo general el comando strip! es nuestro amigo :) De este modo en vendor/plugins/attachment_fu/lib/technoweenie/attachment_fu/processors/rmagick_processor.rb, en el método resize_image, retocamos esta linea:

 self.temp_path = write_to_temp_file(img.to_blob)
 

Por esto:

 img.strip!
 self.temp_path = write_to_temp_file(img.to_blob {self.quality = 70})
 

Lo de la calidad es opcional, RMagick usa por defecto el 75% de calidad, que es válida para un montón de casos.

Así que volvemos a lanzar la importación... 3... 2... 1... y a ver. Esta vez no nos esperamos a que acabe :) Et voilà! Su imagen de 4Kb!

Cosa fina!

Aquí el posteador tardío :)

Algunos de los sospechosos habituales, lease Álvaro Ortiz, Fernando Blat, Keko y un servidor, hicimos equipo para el pasado Rails Rumble y por fin llevamos a cabo Tagueame.

El concepto es fácil, taguear personas :) Como este es un post que viene del pasado ya lo han explicado mis compañeros estupendamente aquí, aquí o aquí. Así que yo sólo voy a decir que el reto de hacer una aplicación en un par de días, sin horarios extremos es refrescante.

Además, que yo tenga controlado, hay dos equipos más de rails hispano: ostraka y cahiers.

Quedaron listas para calificación 130 aplicaciones y todavía hoy se puede votar con un sistema aleatorio bastante curioso.

Actualización: Esta técnica ya no funciona, tal vez me anime a actualizarlo. Mientras tanto puedes destripar acts as unvlogable :)

Hola de nuevo! Vuelvo a la carga tras mi temporada de barbecho digital bloguero en la que he hecho en the cocktail cosas tan divertidas y bonitas como la web de mtv españa. Qué voy a decir yo que no haya dicho álvaro.

Ahora a divertirme. Jugando con la api de youtube vemos que podemos conseguir lo básico para poder tirar de su información con nuestra aplicación. Tenemos una gema que nos hace la vida más fácil.

Lo único que no nos devuelve la api de youtube directamente es la url del flv que va a cargar su player. No es que nos valga para muchas cosas, pero en casos concretos nos puede interesar (nah, nada de detalles).

Pongamos el caso de la url este video. La anatomía de la url (http://www.youtube.com/watch?v=0xaX7ZfX054) nos da la id del video, y incluso sin tirar de la gema sabremos que la url del player es http://www.youtube.com/v/0xaX7ZfX054.

La url directa al flv no es tan intuitiva de construir.

http://www.youtube.com/get_video.php?video_id=la sabemos&t=token de youtube a averiguar

Así que con un poquito de ruby (y definiendo un método string.to_hash):

Así con una simple llamada a get_flv('http://www.youtube.com/v/0xaX7ZfX054') nos devolverá la url al flv.

A disfrutar!

Hace MUCHO que comencé a andar con smupf, cuando todavía era una buena idea. Como toda buena idea pedía a gritos una ejecución rápida e imperfecta impulsada por una buena dosis de ilusión, pero fue a parar conmigo (uno no elige a sus padres) y se fué atascando en sucesivos bucles de refinado y reescritura.

El proyecto se basa (basaba más bien) en la creación de un interfaz para el blogueo de mapas tomando como base google maps y como público aquellos que nunca tocarán una línea de su api. He perdido muchas horas definiendo la interacción, y una cantidad vergonzosa de tiempo desarrollando adelante y atrás, empollando apis e incorporando ideas.

Y el perfeccionismo mató a la idea.

Ahora existe la opción de 'mis mapas', que lejos de quedarse en un pequeño servicio, va creciendo en funcionalidad a pasos agigantados, así que la posibilidad de bloguear un mapa desde el propio google es cuestión de tiempo, y es totalmente imbatible.

Duele un poquito decidir que quieres dejar de hacer una cosa a la que le has dedicado tantísimo tiempo y de la que has hablado a la gente que te importa, pero es necesario cerrar los viejos proyectos antes de afrontar los nuevos.

Esta decisión se me hace un poquito más dramática porque la he tomado mientras terminaba de crear una cuentas de prueba para los sospechosos habituales (esos que me importan) y que iban a ser convenientemente enviadas esta semana.

Acaba de subir la revisión 779 al repositorio, y ahí quedará para recordarme que la próxima vez debo de ser más rápido.

De todo esto queda una bonita experiencia, un camino de aprendizaje que no siempre ha sido fácil y un plugin para rails :)

Si te gusta jugar con rails y nunca has probado hpricot (del siempre genial y bizarro whytheluckystiff) te lo recomiendo. En mi caso lo había probado un par de veces, pero para funciones muy básicas.

En este caso vamos a jugar con la opción que tiene para 'arreglar' inputs de html que vengan un poco escacharraillos ¿quién no se ha dejado un div sin cerrar? Pues esta gema nos va a ayudar a dejar el código limpito de verdad.

No descubro nada que no esté en la documentación, pero es que me ha parecido genial.

Cojamos el código a parsear, bien desde un archivo:

doc = Hpricot(open("tudocumento.html"))
 

Bien desde una variable:

doc = Hpricot(param[:mivariable])
 

Tenemos dos opciones. No toques mi código, sólo cierra lo que esté abierto:

doc = Hpricot(mivariable_o_documento) { |f| Hpricot f, :fixup_tags => true }
 

O bien cierra todo lo que esté abierto, y además convierte mi código en xhtml estricto:

doc = Hpricot(mivariable_o_documento) { |f| Hpricot f, :xhtml_strict => true }
 

Problemas, los hay. Cuando te enfrentas a un código (pegado desde word, por ejemplo) con 300 niveles de anidación no es capaz de decir más que 'too much stack levels'. Evidentemente no es el ejemplo más común, para código normal hecho por gente normal y con unos niveles de errores incluso algo bestia funciona.

Me queda comprobar cuánto consume realmente. Es mucho más ligero que otros parsers de html para rails, pero cuando da el 'stack levels' se come tu máquina y la del vecino. Imagino que se podrá controlar pero todavía no se como.

Ahora, para trabajos sencillo es ideal.

Dos cositas que estoy revisando a ratitos libres:

• La librería de ruby para youtube, áltamente recomendable para los amantes de las apis.
• GeoKit, un plugin para todo lo que tiene que ver con geocodificación. Esta paginita de ejemplos ayuda a comprender la potencia del plugin.

P.D. El blog en estos momentos no se termina de ver bien... ¿por qué? pues por la máxima esa de la casa del herrero y las cucharas de palo :D