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.

Para ti, pequeño maquetador en proyectos rails :) En un proyecto normal las vistas tienen una jerarquía y están "donde deben de estar"™. El problema viene cuando la cosa se complica y hay partials compartidos, vistas que se reciclan y empiezan las particularidades.

Toda esa información está en el log. En mi caso uso este truquito cuando me tengo que centrar en solucionar sólo problemas en vistas y necesito ir al grano. Arrancamos el server de desarrollo con:

 	script/server | grep Render
 

o directamente sobre el log:

 	tail -f development.log | grep Render
 

De esta manera la salida que nos devuelve es más o menos así:

 	Rendering template within layouts/application
 	Rendering sessions/new
 	Completed in 0.01080 (92 reqs/sec) | Rendering: 0.00938 (86%) | DB: 0.00000 (0%) | 200 OK [http://0.0.0.0/login]
 

Y de esta forma localizamos la vistas a la primera :)

Mamá, los 404 no me dejan ver el bosque!

De vez en cuando llega la invasión de los 404. Normalmente son imágenes que no encuentra, y que puede ser por miles de motivos. Si la cantidad de errores es abusiva podemos hacer:

 	tail -f development.log | grep -v 404 | grep Render
 

Y ya está :)

Durante mis estudios de diseño industrial adquirí unos hábitos de observación sobre todo lo que es nuevo para mi. Cuando viajamos a otros países siempre que puedo visito supermercados para comparar productos y presentaciones, y de paso me divierto imaginando hábitos de consumo.

Otra cosa que me apasiona es el mobiliario urbano, tal vez por ser objetos que por definición condicionan la identidad de una ciudad, a los que no se les permite olvidar su faceta práctica. Forma, función y emoción a pie de calle. Infravalorados y olvidados porque ya son parte de nosotros.

Crear objetos durante una época de tu vida (con más o menos éxito) hace que hables de las cosas como si tuviesen alma, como si tuviesen mucho que contarnos y que mostrarnos. Y en este caso es así.

Interiorizamos conceptos de accesibilidad sin saberlo parados en un semáforo, con esos ruidos molestos que suceden cada vez que se pone en verde para los peatones. ¿No has tenido la tentación nunca de cerrar los ojos y tratar de cruzar? ¿Hacia dónde irías? ¿Tu oído está tan entrenado como para poder llegar al otro lado de la calle? Prometo que esta semana intentaré cruzar así La Castellana :)

En el último año, visitando Copenhague, descubrí este pequeño elemento pegado a los semáforos:

Es el cacharrito de los ruidos molestos, versión danesa. Como si fuese un danés de pro estuve ignorando toda la grandeza del elemento, mirando a lugares más interesantes.

Un semáforo interminablemente pesado me hizo caer en la cuenta de que estaba ante una pieza que transmitía mucha más información de la que parecía a simple vista, porque no había que mirarla, había que tocarla. Todo lo que usted necesita para orientarse en un semáforo.

• La barrita superior indica dirección. Está perpendicular al paso de cebra.
• Los dos pequeños realces del extremo nos indican que hay una mediana antes de llegar al otro extremo de la calle.

Muchísima información concentrada en un pequeño cachito metálico.

Ese tipo de dispositivos, a medio camino entre el diseño industrial y la señalética, se llaman señales peatonales accesibles (APS).

En Copenhague estos APS son muy usuales en el centro, en las afueras se van extendiendo bajo demanda de asociaciones de ciegos de Dinamarca.

Salgan ahí fuera y lleven cuidado, pero sobre todo lleven la curiosidad puesta.

Hoy he tenido un fin de jornada de los que renuevan las ganas de trabajar. Discutía con Jorge sobre técnicas de maquetación, sus aplicaciones y lo poco que sabemos de muchas cosas.

Estoy maquetando una cosita a base de ems y ha surgido un pequeño choque (de los buenos). En menos de 5 minotos hemos puesto nuestras cartas encima de la mesa: ¿tiene sentido usarlo? ¿realmente vale para algo? ¿es un esfuerzo extra? ¿tiene alguna implicación accesible? y así unas cuantas más.

La fiebre de los 'layouts crecientes' volvió a salir a la luz hace poquito, cuando Huge Inc. lanzó el rediseño de la web de ikea . Todo el mundo coincidió en el trabajazo que habían hecho con el layout, que crece a la perfección.

Tal vez el principal motivo para usar esta técnica fuese el dotar de un 'extra-ball' para resoluciones de pantallas grandes, o simplemente fuese un pequeño guiño técnico sin más. Y digo pequeño guiño porque después la implementación de las páginas de producto no crece igua de bien.

Vale, estamos de acuerdo en que en cuanto los navegadores implementen un buen zoom esto, probablemente, no tendrá sentido. Firefox 3 ya lo incorpora y previsiblemente cualquiera que salga a partir de ahora.

El caso es que sea cual sea la conclusión a la que hemos llegado Jorge y yo, que en este caso no importa, sales por la puerta teniendo la sensación de que trabajas desconectado de los que te rodean y con menos espíritu crítico del que debieras. Hoy me he reafirmado en que una conversación de apenas 10 minutos con alguien realmente interesante, y que probablemente se encuentre a menos de 3 minutos de ti, puede aportarte mucha más visión e ideas de lo que te imaginas.

Ya tengo propósito para los próximos meses :)

Composición:

Esta vago-receta necesita de un poquito de preparación. Debemos de instalar la gema w3c_validators. Una vez hecho eso necesitaremos copiar este cachito de código en un archivo Rakefile en la raiz de donde tengamos nuestras maquetas. Si ya tenemos un Rakefile sólo añadiremos la tarea:

 # # Massive html validation task
 # 
 # This rake task comes from the nanoc validation task (http://gist.github.com/8961)
 # Copy this Rakefile to the root of your htmls or add the task to your existing Rakefile 
 # and run:
 # 
 #   rake validate
 # 
 # and that's all :)
 
 task :validate do
 
   require 'w3c_validators'
   include W3CValidators
 
   desc "W3C validation of all the files of the current folder"
   task :validate do
     validate '.html'
     # add validate '.theextensionofyourhtml' to extend this task
   end
 
 
   private
   
   # Colorize your output :) 
   def colorize(text, color_code); "#{color_code}#{text}\e[0m"; end
   def red(text); colorize(text, "\e[31m"); end
   def green(text); colorize(text, "\e[32m"); end
 
   # Validation calling to the w3c_validators methods
   def validate ext
     @validator = (ext == ".css" ? CSSValidator.new : MarkupValidator.new )
 
     files(".", true, ext).each do |file|
       results = @validator.validate_file(file)
       if results.errors.length > 0
           results.errors.each do |err|
             puts "** #{file} => #{red(err)}"
           end
         else
           puts "** #{file} => #{green('Valid!')}"
         end
     end
 
   end
   
   # Stoled from nanoc :) (but with a lot of love)
   def files(dir, recursively, ext = '')
     glob = File.join([dir] + (recursively ? [ "**", "*#{ext}" ] : [ "*#{ext}" ]))
     Dir[glob].reject { |f| File.directory?(f) or f =~ /(~|\.orig|\.rej|\.bak)$/ }
   end
 end
 
  

La última versión y correcciones estarán siempre en este gist.

Si la extensión de los archivos a validar no es .html, no dude en variar la línea de la tarea donde se especifica la extensión o añada tantas líneas como sea necesario (esssto hay que mejorarlo)

Esta vago-receta no usa nanoc ni nada por el estilo. La podemos usar en cualquier carpeta llena de archivitos html.

Indicaciones:

Se indica su uso especialmente en todos aquellos casos en el que necesitemos validar el código y tengamos más de 3 htmls :)

Especialmente recomendable cuando más de un zángano guarrea sobre el código.

Posología:

Vaya hasta la carpeta raiz de su proyecto en un terminal y escriba rake validate tantas veces como sea deseable y usted obtendrá un ouput coloreadito super majo.

Cada validación tarda casi nada, pero cuando hay un buen puñado de htmls necesitamos un poquito de paciencia. Aunque bien mirado siempre es mejor que ir uno por uno.

Contraindicaciones y sobredosis:

Validar constantemente puede convertirte en un pequeño psicópata, úsalo con mesura ;)

Otras presentaciones:

Añadiendo en la tarea un validate ".css" conseguimos validar nuestros estilos. Funciona pero en hojas de estilo enormes saca cositas un poco raras.