mamuso.net

Attachment_fu, RMagick y cintas de video

2008-12-04T02:38:40+00:00

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!

Tag me baby

2008-10-29T09:36:37+00:00

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.

Vago-receta: localizar vistas en un proyecto rails

2008-09-17T14:30:22+00:00

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

Tocar la información

2008-09-12T00:52:12+00:00

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.

Trabajar con conexión

2008-10-25T22:21:26+00:00

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

Vago-receta: validado masivo de tu html

2008-09-07T18:50:52+00:00

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.

El día a día con nanoc

2008-10-25T22:24:13+00:00

Hace bastante tiempo intentamos usar nanoc para maquetar proyectos más o menos grandes. Era una versión muy decente, pero que necesitaba madurar. Al mismo tiempo exploramos algún otro mini framework similar como staticmatic, pero estaba todavía menos cocido.

Desde la versión 2 de nanoc el framework se ha convertido en algo bastante sólido, pero además es open souce, es extensible, el código está documentadísimo y su uso también. Si hace mucho que lo probaste tal vez deberías darle una segunda oportunidad.

Vaaale

Está claro, hay métodos más sencillos de hacer html, y que requieren menos conocimientos técnicos, quién no se acuerda de home site.

Tampoco hace falta ser ingeniero aeronáutico para manejar esto. Con tener ruby y rubygems es suficiente para instalarlo y comenzar a trabajar, y hasta ahí llegamos todos.

"Envíeme las maquetas a..."

El clásico include de php nos permite reutilizar gran parte de nuestro código, incluso introducir lógica en nuestra maquetación, nada nuevo. Pero si el sistema nos obliga a tener configurado un host o no funciona si no es bajo un servidor con unas características determinadas (más o menos comunes, eso da igual) sólo nos sirve a nosotros y a nuestro entorno de trabajo cercano.

Con nanoc tenemos las mismas ventajas pero su output es siempre html independiente del framework, de manera que podemos enviar el directorio de salida a cualquiera y lo podrá ver sin obligarle a configurarse nada, como en los viejos tiempos :)

Si son 4 comandos!

Tanto keko como Jose han hablado ya de las maravillas del tutorial de nanoc2 que escribe y actualiza el gran Ale y que nació del tallercito de maquetación ágil que vivimos hace ya casi un año.

No te voy a contar nada que no puedas ver en el tutorial de Ale o en la documentación oficial, de hecho sólo estoy rascando la superficie un poquito.

nanoc create_site nombredelsite para crear un proyecto nuevo. Tienes muchísimas posibles combinaciones, pero los valores por defecto nos permiten trabajar estupendamente.
nanoc create_layout nombredellayout. Hay un layout por defecto con el que puedes trabajar. Aquí el concepto de layout es también el de partial. Puedes incluir un layout que contenga, por ejemplo, la cabecera de nuestro site en el layout por defeto llamándolo <%= render 'cabecera' %>.
nanoc create_page nombredelapagina para crear las páginas. Cada página tiene un yaml en el que le podemos definir filtros, variables a usar...
nanoc compile hace lo necesario para juntar layout, páginas, lógica, etc... y meterlo en la carpeta de salida que hayamos definido.

Para no tener que estar compilando el proyecto a cada cambio (sí, yo también soy de los que cambia dos divs y tiene que recargar la página) existe el comando nanoc autocompile, que nos lanza un servidor, por defecto en el puerto 3000, y cada vez que entramos a http://0.0.0.0:3000/nombredelapagina recompila esa página. Este comando no funciona bien en windows al menos en esta versión, puedes ver el html generado, pero muestra las imágenes como corruptas.

Vamos, que son 4 comandos! A cambio tenemos un proyecto mucho más sostenible y hemos reducido al mínimo el impacto de los cambios sobre la maqueta.

Hay varios comandos más, pero con estos ya podrías crearte un site majísimo. ¿Merecería la pena construir una aplicación de ejemplo complejita por entregas?

Big, bigger, biggest

Lo mejor de todo es que podemos dejar nanoc como está e ir extendiendo nuestra aplicación. Lo podemos hacer a base de plugins, que son archivos .rb situados en el directorio lib o bien con rake tasks, en el directorio tasks.

Así que el límite está en tu imaginación, en tu dominio de ruby y tu experiencia con rake.

Por poner un ejemplo. Sería maravilloso que en un proyecto enorme, antes de entregar, tuviésemos una manera de validar de golpe todas las maquetas (y bola extra css).

Lo más fácil sería crear una tareita rake que analizase nuestro output por nosotros. Si copias este validate.rake (*) en tu directorio tasks podrías ir a la raiz de tu proyecto y correr rake validate. En un momentito tooooodo validado :)

(*) en el momento que escribo esto el gist de la tarea rake está fallando, así que puedes verlo aquí.

Esta y otras tareas y plugins las trataremos de colgar (y mantener) en nuestro gist, por si encontráis alguna cosilla que os resulte útil.

Si todavía tienes dudas instálalo, trastea un poquito con cosas nada comprometidas y si no encuentras respuesta a tus dudas siempre puedes unirte a la lista de nanoc en castellano.

Maquetar para desarrollo

2008-10-25T22:05:17+00:00

Desde hace meses he ido incorporando de manera bastante natural a mi rutina de maquetación pequeños detalles que ayudan a que el engranaje entre la maqueta y la implementación en un proyecto web sea un poquito más sencillo. La mayoría son obviedades, sentido común fácil de incorporar a nuestro día a día.

Muchos de estos "vicios" los heredé de Álvaro y María y otros los he ido incorporando a base de trabajo y de integrar html en desarrollo, pero sobre todo a base de equivocarme mucho, que también es necesario.

Esto es lo que a mi me funciona, es más que probable que no descubras nada nuevo:

Comentar y tabular:

Un código bien tabulado siempre es más legible independientemente del lenguaje que estemos escribiendo. Si la maquetación se hace en equipo siempre está bien llegar a un acuerdo sobre el tipo de tabulación que se va a usar. Yo me encuentro cómodo con 4 espacios, pero es cuestión de gustos.

Es muy útil marcar con un comentario el final de los divs principales para siempre tener localizado dónde se cierra.

 
     <div id="content">
 
         ...
 
     </div><!-- #content -->

Tampoco está de más marcar con un comentario el comienzo y fin de bloques específicos, por ejemplo:  o

Es la manera más fácil de no volvernos locos al abrir nuestro trabajo cuando ya no lo tengamos fresco.

Primero el marcado, después el estilo:

No hablo de escribirte todo el html de la página que vayas a maquetar, pero es muy fácil identificar los bloques que van a funcionar como unidad.

Pon el esfuerzo en escribir un html limpio y semántico en lugar de ir saltando entre la hoja de estilo y el html desde el principio. A mi esto me da muy buen resultado, pero hay quien prefiere ver una evolución más gradual mientras trabaja.

Mantén limpio tu html y hereda:

Todos hemos pasado una fase de 'classitis' :) Un uso correcto de la herencia nos evita este problema. Al integrar el html la mayoría de los desarrolladores son cuidadosos, pero un código limpio les facilita bastante las cosas, reduce el margen de error y es más sostenible.

Un ejemplo podría ser este:

 
 	<ul id="menu">
 	   <li><a href="#">01</a></li>
 	   <li class="active"><a href="#">02</a></li>
 	   <li><a href="#">03</a></li>
 	   <li><a href="#">04</a></li>
 	   <li><a href="#">05</a></li>
 	</ul>

Marcando la clase en el li en lugar de en el enlace podemos actuar sobre dos elementos para componer nuestro estilo 'active'.

Menos no siempre es más:

Se que mucha gente está a favor de poner únicamente el html necesario, ni más ni menos. Yo estoy totalmente de acuerdo siempre y cuando sepamos a ciencia cierta que un cambio en una estructura del html dentro de unos meses no va a generarnos más dolores de cabeza de los necesarios.

Con toda la cautela del mundo, a veces un div de más rodeando un bloque de contenido nos da el juego suficiente para cosas tan básicas como ajustar detalles entre distintos navegadores. Siempre es más fácil añadir un poquito más de CSS que destripar una aplicación en producción.

Aclaro que no hablo más que de un poquito, un elemento para ajustar padding, para dar un sobrefondo en un momento determinado, etc, no estoy justificando un chorro de sobre-html que se pega con la filosofía de mantener el código lo más limpio posible.

Establece algún criterio de calidad:

En todas las fases de un proyecto deberían de haber reglas de control que nos ayudasen a asegurar que nuestro trabajo sea lo suficientemente bueno. El criterio de calidad más usual en el caso de la maquetación es el de validar tanto html como CSS.

Que un código valide no significa que esté bien, pero sí que no se nos ha olvidado cerrar ninguna etiqueta.

Esto nos lleva a otro criterio más, que es probar nuestro trabajo en los navegadores que exija la ruta del proyecto, que por lo general suelen ser 4 - 5.

Yo además, siempre que es posible paso trozos complicados de código a compañeros de trabajo o de fatigas para tener siempre una segunda opinion, que normalmente no es objetiva, pero que nos aporta un punto crítico.

Usa convenciones:

Usar patrones en esquemas básicos que se repiten a lo largo de todo un site nos facilita el trabajo a nosotros y a los integradores.

El ejemplo más fácil de explicar sería el de marcar el elemento activo en un menú. Normalmente tenemos una navegación principal y una secundaria al menos. Pues podríamos convenir que los menús siempre son listas, y que el elemento activo se va a marcar en el li con una clase 'active'.

Minimiza el impacto de los cambios:

Quiérete a ti y a los que te rodean y utiliza todos los medios que tienes a tu alcance para no perder ni tu código ni tu tiempo.

Mete todo tu código en un control de versiones. Da igual el que sea, el que más fácil te resulte o el que menos infraestructura vaya a requerir. Los más famositos son subversion, csv y últimamente está muy e moda git. Dedicale un ratito a aprender los 4 comandos básicos y nunca vuelvas a perder un solo archivo.

Utiliza herramientas que te ayuden a hacer el trabajo mecánico. Todos hemos recibido un cambio en la cabecera en un proyecto en el que ya hay 50 maquetas ya hechas :) Si hacemos un reemplazo masivo corremos el riesgo de cambiar lo que no debemos. Si hacemos el cambio en una sola maqueta y avisamos de dónde está el cambio vía mail / viva voz / paloma mensajera corremos el riesgo totalmente innecesario de que el que finalmente va a trabajar con las maquetas no reciba el recado.

Cualquier método que nos permita trabajar con el concepto de 'include' nos puede valer, pero los más útiles son los que generan html estático. Una buena solución si no le tienes miedo a programar un poquito sería nanoc, que además está bastante documentado.

Intercambia conocimientos:

Habla con la gente que trabaja contigo, intercambia opiniones, trata de conocer sus problemas a la hora de afrontar lo que tú les vas a enviar porque es la mejor manera de que todo salga bien.

Discute con otra gente tus métodos. Hace unos días tuvimos una pequeña reunión varios compañeros para poner en común formas de trabajar y surgieron temas interesantísimos que no salen de ninguna otra manera.

Todos los puntos anteriores son matizables, incluso algunos totalmente prescindibles, pero son un buen comienzo :)

Tallercito de APIs OMF

2008-09-04T13:31:01+00:00

Mañana por la tarde nos vamos a reunir en el aula de the cocktail para hablar sobre web, móviles y APIs. La idea es hacer una breve introducción a las posibilidades que nos dan las APIs de open movilforum, nada extenso, ver un poquito de código sobre unos ejemplos muy básicos para hacernos a una idea de que es fácil jugar.

Teniendo en cuenta que hay gente apuntada al curso que tiene que ya ha hecho cositas con estas y otras APIs creo que lo más enriquecedor sería abrir un debate entre todos los asistentes sobre modelos de interacción entre móvil y aplicaciones (web o no), patrones, qué es útil y qué no.

Y justo después... fiesta unvlog!!

Todavía estás a tiempo de apuntarte.

de viaje con iwannagothere.net

2008-07-29T03:31:54+00:00

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

Fiesta unvlog!!

2008-06-18T10:11:23+00:00

Peroperopero que requetebonico es que los usuarios de unvlog.com nos hayan organizado una fiesta!!! Si me diesen un céntimo cada vez que digo en "sólo por esto ya ha merecido la pena hacer unvlog" sería un hombre rico, pero me conformo con ser un hombre feliz.

No sólo se han currado el organizar la fiesta, sino que además han hecho videoconvocatorias. Por aquí la de isabl + xurde:

Y por aquí el gran gorriti.

Así que nos vemos el 3 de julio en Sideral Club, en Madrid!

Taller sobre la API de 11870.com

2008-04-23T15:28:18+00:00

Seguro que ya todos conocéis 11870 y que tienen una API fantástica y llena de posibilidades. La documentación lo pone todo MUY sencillito, pero seguro que te falta un empujón para ponerte a jugar.

La oportunidad de quitarte la pereza de encima viene en forma de taller en sus oficinas (Virgen de los Peligros 3, 3º izquierda). Será mañana jueves 24 de abril a las 19:30.

Tienes que confimarles asistencia :) Nos vemos allí!

unvlog.com

2008-02-24T12:20:38+00:00

Hoy es un día de esos en los que sueltas al mundo algo en lo que has puesto mucha ilusión, y la verdad estoy muy contento :)

Hace un puñao de meses alberto puso este twitt. En un par de días blat, alberto y yo estábamos en un bar (donde se forjan los proyectos de verdad) hablando de esto. Alberto tenía una idea, y nosotros podíamos construirla.

Y así al final cada uno hemos puesto nuestro pequeño granito de arena, pasando por épocas buenas, malas e incluso un agosto hemos ido haciendo unvlog. A todo este esfuerzo se han unido las ilustraciones de dos señores estupendos como son dani (arriba) y puño (abajo). He de decir que todo el mundo flipa con las ilustraciones (tweet) y no es para menos.

Hace muy poquito empezamos con las cuentas para amiguitos, y fue cuando empezamos a notar que todo el cariño que se había puesto en el proyecto venía de vuelta cuando gente que te importa y a la que respetas habla maravillas (me dejo tweets, lo se).

Como colofón a tanta felicidad el viernes presentamos a la criatura en sociedad. Esperemos que nos acojan con el mismo cariño que todos los que ya habitan vuestro unvlog.

Youtube, dame el flv!! (con ruby)

2007-11-06T08:17:27+00:00

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!

Se busca!

2007-11-06T08:03:46+00:00

En the cocktail estamos buscando programadores de rails. Estamos trabajando en proyectos realmente interesantes para nuestros clientes, y siempre tenemos proyectos propios, como esta nuestra coctelera :)

Echadle un vistazo a nuestra página de empleo y si tu perfil encaja (más o menos) con lo que pedimos ya estáis enviándonos el curriculum!! Y si no encaja envíalo igual, siempre estamos abiertos a conocer a personas interesantes.

Nunca es fácil matar a tu propio proyecto

2007-11-06T08:03:26+00:00

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

Related_articles, un plugin para mephisto.

2007-11-06T07:49:20+00:00

Bueno, aunque sólo sea para justificar el tiempo que llevo sin escribir por aquí, lo hago con algo más o menos consistente :)

He hecho un plugin para el sistema de blogs mephisto. El plugin funciona poniendo en relación artículos por medio de sus tags. Esta funcionalidad (tontísima) es bastante útil si eres más o menos disciplinado con los tags de tu blog.

Por defecto saca los últimos 5 artículos que tengan 2 (o más) tags coincidentes, pero estos parámetros se pueden configurar.

En próximos días lo pondré en un repositorio de plugins (o al menos público), pero para eso hacen falta pulir dos cositas:

Hacer los tests de rigor (para lo que necesito engañar a blat)
Solucionar el caso en el que no hayan artículos relacionados.

Mientras tanto lo podéis ver en acción en madeonvinyl.

A pesar de todo, si alguien con mephisto lo quiere probar que me de un silbidito que se lo paso.

Creando mapas sobre Google Maps

2007-11-06T07:45:11+00:00

Hoy me he dado cuenta que google maps ha incorporado la pestaña 'Mis mapas', y la verdad es que la aplicación está bastante bien (quién mejor que ellos).

Se parece bastante a lo que pretendía ser el always procrastinated smupf (hijos, ahora volveré a tratar de centrarme y reconducirlo).

Que google permita hacer mapas con la pedazo de api que tiene por detrás, y con las posibilidades que nos permite aplicando un poquito de imaginación, no sorprende (pronto saldrá el experimentos que hicimos para el taller de apis, vease imagen).

Lo que me sorprende es que usen 'tu' en cursiva :)

Razón 3489 para plantearme comprar una moto

2007-11-06T07:43:27+00:00

Si del punto A al punto B andando tardas X, el tiempo que tardas en metro debería de ser al menos sensiblemente inferior, sobre todo si es viernes por la tarde y hay 3 personas en el metro.

Posteado desde MarsEdit.