Mis Tags > rails

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!

Esta semana hemos abierto al público iwannagothere.net. Es un servicio pensando para viajeros desde el punto de vista activo y pasivo. Puedes compartir tus lugares y consejos sacados de tu experiencia viajera, o bien generar tu ruta a partir del contenido que ya hayan dado de alta otros viajeros.

La idea partió de María, y ella os explica mejor que yo de dónde ha surgido la idea y cómo nos hemos metido en este lío. Es el primer desarrollo grande fuera de the cocktail que hago con ella y ha sido tremendamente enriquecedor.

En la parte de desarrollo el que ha partido la pana ha sido Blat. Cualquier cosa que diga sobre él se queda corta.

En estos proyectos personales donde se barajan ilusiones pero no dinero es imprescindible poder ser totalmente transparente con tus compañeros para que puedan saltar de 'servilletas en los bares' a realidades más o menos ambiciosas.

Lo que sabemos: El proyecto se nos ha ido haciendo muy grande durante el proceso de creación. De hecho ha sido largo y con miles de pequeñas batallas sobre cómo hacer esto o aquello.

Finalmente, sabiendo que no está todo hilado y que tenemos casi tanto camino por recorrer como el que ya hemos recorrido, hemos sacado una beta. Somos conscientes de que tiene miles de carencias a todos los niveles, pero es la única manera de empezar en este tipo de proyectos. Además las críticas del entorno, de la gente que escribe sobre el proyecto y de la que escribe en el proyecto son muy útiles unas veces para descubrir dónde te has equivocado y otras para confirmar lo que ya sabías.

Esto significa que durante los próximos meses iwanna se irá transformando y mejorando para hacer la experiencia de uso mucho más agradable.

Lo que nos gustaría: Puestos a mirar alto nos gustaría llegar a ser una guía de viajes completa, muy completa.

El componente social se convierte en algo importante, pero tal vez no apto para los colonizadores de amigos en redes sociales. En iwanna no tiene sentido entrar, añadir y esperar. Para que la aplicación empiece a ser útil y se puedan crear rutas interesantes un buen puñado de usuarios tiene que haber contribuido con información.

Postear no es fácil si se busca aquella información que te hubiese gustado encontrarte en una guía, con toda la carga subjetiva que eso supone.

Sólo tras unos meses de rodaje y mucho trabajo sabremos si funciona o sólo ha sido una bonita experiencia.

A título totalmente personal. Sé que tenemos muchos puntos tangentes con otros proyectos y que las comparaciones son inevitables. Hemos querido construir por encima de todo una guía de viajes colaborativa, no un directorio de empresas, no un lugar donde la gente cuente sus viajes como una experiencia global. Nuestra primera tarea es resaltar nuestras diferencias y eso nos va a ayudar a evolucionar como servicio.

Esperamos veros por nuestra iwanna :)

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.