Sofa Naranja ahora, con un 125% más de naranja

Adobe no entiende internet

Ayer se presentó en sociedad el rediseño de Twitter. Como todos los rediseños, a este habrá que acostumbrarse poco a poco. Pero hay un detalle al que va a ser difícil acostumbrarse: la tipografía. No sé en qué estarían pensando los Twit-boys, pero poner Lucida Grande como tipografía por defecto no ha sido una jugada brillante precisamente.

Como me consta que no soy el único que lo piensa, a los 20 minutos de ver el rediseño por primera vez publiqué un script para Greasemonkey (o Creammonkey si usas Safari):

Twitter Text Hack

Este script sustituye Lucida Grande por Arial, y tardé 2 minutos en escribirlo y unos 45 segundos en tenerlo publicado en userscripts.org (incluyendo el tiempo de registrarme en la web)

Comparemos esto con un problema similar que tuve con Fireworks. Como las guías no se pueden copiar y pegar, y es un auténtico coñazo hacer retículas a mano, creé una extensión (el ya conocido Reticulator).

Como el feedback que recibí fue bastante bueno, decidí compartir la extensión en el Adobe Exchange. Para ello, tuve que completar un tedioso proceso de registro de la extensión (que tuve que hacer dos veces porque la primera vez falló) y al final me obsequiaron con un bonito email que decía “Gracias, bla bla bla, tu extensión queda pendiente de revisión por nuestro equipo de QA… en breve estará disponible… bla bla bla…”

Eso fue hace 4 meses.

Ayer Adobe me envia un mail que dice:

Your recent upload to the Adobe Exchange was approved by our QA team and is now available for download

Estimada Adobe: estamos en el siglo XXI. Puedo poner a disposición de mil millones de personas un script instalable a través de internet en unos segundos. Puedo publicar en mi blog en minutos. Puedo tener millones de visitas a mi propio canal de televisión en horas… En este contexto, y en estos tiempos, “recent” podría ser, siendo muy flexibles, un par de días… tres o cuatro… una semana a lo sumo…

Pero 4 meses para compartir una extensión es una eternidad.

¿Quieren tener una gran comunidad de desarrolladores que compartan sus conocimientos y su código? Porque con este modus operandi dudo que lo estén consiguiendo…

Estimada Adobe, ponte las pilas…

Donando a proyectos Open Source

Una de las bases de internet tal y como hoy la conocemos es la filosofía Open Source. Compartir código y conocimiento a cambio de nada-material es, en mi opinión, una de las pequeñas revoluciones de nuestro tiempo.

Desde mis inicios en la web (hace ya muchísimo tiempo :) nunca ha dejado de sorprenderme la cantidad de tiempo que la gente está dispuesta a invertir en enseñar lo que sabe. Es una actitud inspiradora, y que me sigue motivando para compartir conocimiento, código, herramientas…

Pero los programadores también comen : )

Cuando te acostumbras a tener de forma instantánea casi cualquier herramienta imaginable en versión Open Source, es fácil olvidar el esfuerzo que supone idear, construir y mantener un proyecto así.

Por eso desde hace tiempo, cuando uso herramientas Open Source para mis proyectos comerciales siempre procuro donar un porcentaje de los beneficios a un proyecto Open Source (tradicionalmente, al que haya usado para ese proyecto)

Seguramente ningún fundador de un proyecto Open Source piense en hacerse rico con las donaciones. Pero todos agradecen poder tomarse un par de cervezas a la salud de sus usuarios :)

Y si no puedes contribuir económicamente, ayuda con los talentos que tienes. Puede que tu proyecto favorito necesite un icono, un diseño para su web, unos retoques de código…

Aquí va una pequeña selección de proyectos Open Source que me han ayudado este año, y a los que merece la pena echar una mano:

• DokuWiki
• nanoc
• famfamfam
• MTASC
• Locomotive
• jQuery
• Growl
• Adium

Y tu… ¿a quién vas a darle las gracias por hacer tu vida más fácil? ;)

Movimientos en sofanaranja.com

Estoy moviendo de servidor el blog, con la sana esperanza de que todo funcione mucho más rápido.

Sofá Naranja está alojado en Dreamhost, un proveedor con muchísimas ventajas. La velocidad no es una de ellas :)

Para intentar mejorar la situación, estoy probando Dreamhost Private Servers, y aparentemente el rendimiento ha mejorado mucho. Es una opción más económica que contratar un servidor dedicado virtual (estilo slicehost) y tiene la ventaja añadida de que no tienes que instalar nada (digamos que es como el clásico servidor compartido de toda la vida, pero con CPU y RAM garantizada como en un servidor dedicado virtual)

Aprovechando el cambio, he movido el blog a WordPress 2.3-RC1 y activado el plugin WP-Cache.

Con todo esto el blog va mucho más rápido que antes, pero es posible que veas algún error mientras se propagan las DNS del nuevo servidor.

Disculpen las molestias.

Es un mensaje del Departamento de Hosting, Tuneo y Otros Menesteres™

Elogio de la vagancia

Uno de los temas en los que hice mucho hincapié en el taller de ayer fue en las múltiples ventajas de ser extremadamente vago.

Como me parece un tema bastante interesante, quisiera extenderme un poco más en el asunto, que creo que se merece un post para él solo.

¿No es la vagancia una cualidad horrible?

Hombre… depende de cómo lo mires… Para estos casos siempre recurro a la misma cita, de un gran personaje con el que tengo la suerte de trabajar, Sergio Gil:

Para mí hay dos tipos de vagos, el vago bueno y el vago malo. Al vago bueno no le gusta trabajar, y hace cosas increíblemente ingeniosas para no tener que hacerlo.

Es decir… ser vago no implica necesariamente que no hagas bien tu trabajo. De hecho, muchas veces es justo lo contrario. Un buen vago hará su trabajo muy bien a la primera para no tener que repetirlo, y tan rápido como pueda para dedicar su tiempo a otros menesteres más interesantes.

¿Qué es, exactamente, ser “extremadamente vago”?

Es una habilidad que se resume en preguntarse constantemente “¿Podría yo hacer esto con menos esfuerzo?”

La vagancia extrema es el motor del progreso, la ciencia, y las herramientas de automatización de tareas.

Los ordenadores no se inventaron para pasarte 8 horas al día haciendo lo mismo mecánicamente. Se inventaron para pasarte 7 horas pensando cómo hacer tu tarea automáticamente y dejar que el ordenador la haga en 10 minutos. Y por supuesto, invertir los 50 minutos restantes en ver videos chalados en YouTube.

Automatiza, automatiza, automatiza…

Siempre que se habla de las maravillas de la informática moderna, invariablemente surge el tema de la automatización. Las macros de Office, las acciones de Photoshop, los comandos de Fireworks… todos destinados a permitirte trabajar mejor, más rápido… y menos, que es lo importante.

Sin embargo, una de las mayores ventajas de la automatización queda normalmente eclipsada por los cantos de sirena del aumento de la productividad: cuando automatizas, reduces la cantidad de errores.

Si todos los días tengo que hacer una tarea que se compone de 10 pasos, puedo certificar que me equivocaré en uno de ellos el 90% de las veces. Y además no será siempre el mismo.

Sin embargo, si creo un sistema automático que haga las 10 tareas bien y pongo un mínimo de cuidado en hacerlo “idiot-proof” (es decir, que si escribo el comando equivocado no borre todos mis datos) habré reducido enormemente la posibilidad de cagarla en alguno de los pasos.

Si además resulta que la tarea se ejecuta más rápido, accidentalmente he mejorado mi productividad. Pero lo importante es que duermo más tranquilo :)

Siempre se puede hacer mejor

Otro de los pilares del progreso humano es la revelación de que, trabajes como trabajes, seas lo eficaz que seas y automatices lo que automatices, siempre puedes ser aún más vago.

Y si piensas que no, es que eres un flojo :P

Taller de Maquetación Ágil con Ruby

El próximo 18 de septiembre, en el Aula de The Cocktail, impartiré un curso sobre “Maquetación Ágil con Ruby: nanoc y heel”

Si trabajas con Rails ya conocerás las ventajas que supone en tiempos y facilidad de desarrollo. Sin embargo, si tu trabajo consiste en maquetar o prototipar aplicaciones, tu trabajo empieza antes de que haya una aplicación Rails funcionando, y desarrollar una aplicación “de mentira” para poder montar tu HTML es matar moscas a cañonazos.

Para estos casos tenemos nanoc, un pequeño framework para la creación de sites estáticos en HTML. Con unas pequeñas mejoras (o sea, un poco de código en Ruby muy sencillito) convertiremos nanoc en el arma definitiva para el maquetador, y de paso nos aseguraremos de que nuestras plantillas de nanoc sean reutilizables en nuestra aplicación Rails.

Incluso si no piensas utilizar Rails en tu proyecto, y sólo necesitas entregar HTML estático, veremos como nanoc te sirve para ahorrar tiempo y mejorar la calidad de tu código, evitando errores y agilizando los procesos de depuración.

También hablaremos un poco de heel, un micro servidor web basado en Mongrel que te permitirá testear tu site sin tener que instalar Apache o Lighttpd.

El taller está orientado a maquetadores y diseñadores web y no es necesaria experiencia previa con Rails o Ruby (aunque si ya sabes algo, mejor que mejor)

Más información e inscripciones en el wiki del Aula The Cocktail