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

Documentación del taller de Maquetación Ágil

Ante todo, gracias a todos por asistir :)

Ya está disponible la documentación del taller en http://nanoc.jottit.com y el PDF de la presentación (que en realidad no sirve para nada, pero por si a alguien le hace ilusión :)

La documentación del taller es un “work in progress”. Si tienes dudas, sugerencias, quieres ampliarla con algún plugin que hayas escrito o compartir tus experiencias con nanoc, envíame un mail a ale {arrobilla} bomberstudios {punto} com y las iré añadiendo al wiki.

De nuevo agradecer la asistencia (y que no se durmieran :) al montón de gente que vino. Así da gusto impartir clases ;)

Un par de concursos de diseño

Vaya por delante que no soy muy partidario de los concursos de diseño, ni del “diseño de muestra”, ni de “enviar un par de propuestas de diseño con el presupuesto” (para una explicación más sesuda, recomiendo una visita a no-spec.com :)

Dicho esto, ahora mismo están en marcha un par de concursos que creo que merecen la pena, por dos motivos diferentes.

El primero, porque es para un proyecto/producto Open Source que hace más fácil la vida de muchos programadores (y de muchos vagos profesionales, yo incluido): el Ruby Logo Contest

Y el segundo porque muy pocas veces he visto un concurso con un briefing tan detallado, una explicación tan clara de lo que necesitan y tanta información sobre el contexto en que se va a usar el diseño: el Open Logo Project 1.6

Ruby Logo Contest

Es bastante loable que un proyecto Open Source tenga un Equipo de Identidad Visual y publique un Kit de Logo con licencia Creative Commons.

Lo que no es tan loable es el escaso briefing del concurso (atención):

We need an official Ruby logo to promote Ruby, so we open a contest to select it.

Así que aquí va mi personal interpretación del asunto…

Ruby tiene una imagen bastante potente (para ser un lenguaje de programación, claro). Casi todo el que sepa algo del mundillo asocia un diamante rojo con Ruby.

ruby_logo_128.png

El problema del logo de Ruby (sospecho) es que, a medida que su uso se ha extendido en el ámbito empresarial, se han ido descubriendo sus limitaciones (demasiado recargado, poco “enterprise”, no transmite cualidades del lenguaje o atributos de la marca…)

Esto, unido al pequeño caos de imaginería para congresos, libros, charlas, frameworks… provocan que la imagen de Ruby aparezca fragmentada y no exista la conciencia colectiva de “ESTO es el logo de Ruby”

En mi opinión, lo que Ruby necesita (y para lo que convoca el concurso) es una imagen de marca / “sello de garantía”, al estilo del “Made for iPod” de Apple

made_for_ipod_logo.jpg

o del “Certified for Vista” de Microsoft

certified-for-vista-label.png

Algo que además de ser su logo pueda usarse en un cartel de la RailsConf junto a la lista de patrocinadores, o como un sello de calidad en un libro, o…

El plazo termina el 1 de Octubre de 2007, y el premio es de ¥100.000 (unos 640 euros, al cambio de hoy)

Open Logo Project 1.6

SpreadShirt es una de las mayores “tiendas de tiendas” de Europa. Están especializados en la fabricación y distribución de productos textiles (i.e: hacen camisetas :) y desde hace tiempo son el partner logístico de La Fraise

Con un curriculum así, uno podría pensar que están capacitados para contratar a un buen diseñador/estudio, hacerle el encargo, mandarle el briefing, reunirse, retocar propuestas…

Pero si hay algo que SpreadShirt ha aprendido ayudando a montañas de diseñadores a vender sus diseños en camisetas es que el mundo está lleno de gente muy buena a la que no conocen.

Si acabas de terminar tus estudios, o tienes poca experiencia, o te aburre tu trabajo y te sobra tiempo, o te seducen los premios del concurso (mal motivo, en mi opinión :) el concurso de SpreadShirt tiene dos cualidades que lo hacen muy interesante:

  • El briefing es muy bueno. Mucho mejor que el briefing standard del mundo real. Échale un ojo para ver cómo tendría que ser la especificación de un trabajo, tanto si vas a participar como si no. Además del briefing, puedes consultar un extracto del informe de investigación de mercado de SpreadShirt (y el informe completo, una vez lo publiquen oficialmente)
  • El proceso de revisión de diseños es abierto. Puedes ver qué están haciendo otros participantes, criticar sus diseños y (lo más interesante) recibir críticas del tuyo. La crítica de diseño es lo más difícil de este trabajo, tanto si la haces como si la recibes. Y por eso los buenos directores de arte cobran lo que cobran :)

El plazo termina el 14 de Octubre de 2007, y los premios no te dejarán indiferente si te gusta esta profesión :)

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