mamuso.net

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.

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):

require 'open-uri'
 
 class String
    def to_hash(seperation='&', assignment='=')
      hash = Hash.new
      self.split(seperation).each do |elemement|
        pieces = elemement.split(assignment)
        hash[pieces[0]] = pieces[1]
      end
      hash.delete_if { |key, value| value.nil? }
    end
 end
 
 
 def get_flv(url)
   getparams = nil
   open(url) {|f|
       getparams = f.base_uri.request_uri.split("?")[1]
   }
   unless getparams.nil?
     parameters = getparams.to_hash()
     url = "http://www.youtube.com/get_video.php?video_id=#{parameters['video_id']}&t=#{parameters['t']}"
   end  
   return url
 end

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

La primera vez que me encontré con blat habló del helper cycle.

Hoy haciendo una pruebecita lo he vuelto a usar, y me encanta que rails venga con estas tonterías de serie.

Así que cuando tengais que hacer una tablita y aplicarle un pijama (o hacer que elementos alternos tengan clases distintas):

 <tr class="<%= cycle("oscuro", "claro") %>">
      [... lo que sea]
 </tr>
 

Estoy de acuerdo con que 'el precio de la magia' (nando tm) a veces juega malas pasadas, y que a veces hay atajos que tocan las narices en cuestiones de rendimiento, pero esto es genial y rápidito.

... y con ella el upgrade/susto. Durante unas horas han habido gemas con errores en el aire. Yo he sido una víctima de la actualización. Una cosa que no funciona, un upgrade de una gema y cuando te quieres dar cuenta tienes la 1.2 con unos cuantos errores al compilar.

Hay que reconocer que en un tiempo razonable han puesto remedio a los fallitos.

Ahora con el cambio de versión nos vienen las revisiones de los métodos obsoletos a los que tendremos que ir perdiendo la costumbre. Y si no mirad el mensajito que me deja el log de una aplicación cuando encuentra algo:

 DEPRECATION WARNING: The :dependent => true option is deprecated and will be removed from Rails 2.0.  Please use :dependent => :destroy instead.  
 See http://www.rubyonrails.org/deprecation for details.
 

Imagino que no todos los 'deprecated' serán tan educados y que nos vamos a dar algún que otro cabezazo cuando algo falle y no esté documentado.

Actualmente la página a la que nos refiere el log está vacía, imagino que en los próximos días se irá llenando.

Reconoced que el mensajito que nos han puesto, Nothing lasts forever, tiene un puntito de cachondeo :D