Gaston Garcia

Bocetos y textos sobre desarrollo y la vida

Sep 5, 2013

Hacks y apps para mejorar el desarrollo

Desk

A lo largo de los años he ido acumulando pequeños hacks, amor por algunos apps y unos cuantos scripts que hacen que la vida como desarrollador sea más fácil y en algunos casos mucho más chiva.

Aquí va una lista breve de cosas que creo que vale la pena probar y usar.

Vim

Aunque sea un editor de texto que tiene una curva de aprendizaje muy dura Vim es una herramienta invaluable. Le abre a uno los ojos a que la computación está para usarse. Los shortcuts que tiene son mágicos y poderosos. Mil veces por encima de cualquier otro editor. Vim hace que uno desarrolle una impaciencia terrible a editores de textos estúpidos y lentos.

La otra gran ventaja de aprender a usar Vim es que en caso de que se requiera uno puede editar cualquier texto desde cualquier terminal (cosa que es cada día más común a causa del auge de Git, Compass, Sass, Ruby, Node y el resto de las herramientas de desarrollo que requieren la terminal).

Yo recomiendo usar Macvim si usan Mac.

Para aprender a usarlo está VimCasts.

Git

Hace como 6 años un amigo fiebre del Version Control me recomendó aprender a usar Git. No le hice caso.

Luego hace como 3 años tuve que aprender. Fue frustrante y complicado.

Hoy en día lo uso a diario incontables veces al día. Aún sigue siendo frustrante y complicado de vez en cuando. Pero no hay vuelta atrás.

Git abre las puertas a tener control de versiones y a poder publicar los proyectos en la nube con facilidad.

Boilerplates de proyectos

En "The Pragmatic Programmer" Andy Hunt y Dave Thomas introducen el principio DRY: Don't Repeat Yourself. Esto va más allá de no repetir código y de reintentar la rueda. Por ejemplo, muchas veces repetimos las mimas acciones cientos de veces cada vez que vamos a iniciar un proyecto web o un set de scripts.

Yo antes mantenía versiones de folders con "proyectos web" vacíos, listos para iniciar a trabajar. Toda la estructura y los documentos básicos de todos mis proyectos los mantenía ordenados para peder hacer copy/paste y dar inicio en minutos en lugar de horas (o días).

Ahora mantengo los mismos tipos de boilerplates pero en repositorios privados en Bitbucket.

Iniciar un proyecto es tan sencillo como escribir:

git clone mi-proyecto-en-bitbucket

Además de que el equipo con el que trabajo puede mejorar y mantener los boilerplates actualizados.

Usar un timer

Muy a menudo uso un reloj en cuenta regresiva para trabajar. Trabajo en sets de 10 minutos (con descansos de 2 minutos), o en sets de 25 minutos (con descansos de 5 minutos).

No siempre lo hago, pero aprender a trabajar contra el reloj ayuda a evitar distracciones y a producir resultados más rápidamente.

La técnica es conocida como Timeboxing. Otro link que explica esta técnica es Run a Dash de Merlin Mann.

Mi contador favorito es Minuteur. Me permite hacer sets en cuenta regresiva y también contabilizar mi tiempo de trabajo en un cronometro normal. Minuteur también me deja agregarle el costo de mi hora en sus preferencias. Eso me deja saber fácilmente cuanto he invertido en tiempo/dinero en un proyecto.

Aprender a escribir en el teclado

Sonará absurdo decirlo, pero es absolutamente obligatorio para cualquier desarrollador aprender a escribir rápidamente en el teclado.

Si usted tiene la maña de ver el teclado para escribir, cambie. Si usted le ha dado pereza aprender, aprenda.

La forma más fácil de aprender es la siguiente: Pinte encima de las teclas de forma que ya no le sirva de nada ver el teclado. Si no quiere pintar su teclado, póngales una calca encima, o haga algo. Su mente desarrollará rápidamente una memoria de dónde están ubicados los caracteres que necesita. Después de dos semanas ya va a ser un experto.

Mi más reciente test dice que escribo a 71 palabras por minuto. Para alguien que usa SublimeText por varias horas cada día, esto es útil.

Tomar café

Obvio.

May 5, 2013

El fin de la era de Wordpress. Al menos para mí.

Hoy tuve que trabajar por 5 horas seguidas en un sitio web construido con Wordpress. Hace ya casi 3 meses no usaba Wordpress, con la excepción de dar mantenimiento breve a algunos sitios viejos. Hoy decidí que a menos de que me vea obligado a hacerlo por alguna razón especial no lo vuelvo a usar.

Wordpress es obviamente una plataforma genial. Wikipedia dice que el 14.7% de el primer millón de sitios más populares del mundo usan Wordpress. Yo no hice ninguno de los más populares, pero he hecho varias decenas de sitios web con Wordpress. Lo respeto y estoy agradecido con todo lo que me ha permitido hacer. Pero ya está bueno.

Aquí las razones por las que voy a dejar de usarlo:

El viejo método de trabajar online

Conectarme a un FTP, subir folders, bajar folders, editar "en caliente" en el servidor, etc. Así se venía trabajando desde hace 10 años y muchos lo siguen haciendo hoy en día. Pero hace ya 2 años tuve la oportunidad de estar involucrado en el primer proyecto donde colaboré con un equipo vía GIT. De aquí a que inventen algo mejor, así seguiré haciéndolo.

Hoy en día se considera un workflow normal y eficiente trabajar localmente (por lo general desde una Mac), mantener control de versiones por medio de GIT y publicar online desde la terminal. Nuestra laptop nos sirve de "ambiente" local que replica el ambiente del servidor. La ventaja de esto es que podemos utilizar nuestro editor de texto, los Developer Tools y por lo general algún sistema de auto-refresh y auto-save para desarrollar de una mejor forma. Mejores herramientas no garantizan un mejor trabajo, pero sin duda malas herramientas fomentan un peor trabajo y una inversión más grande de tiempo.

El mito del Content Management

Todos hemos vendido a algún cliente la idea de que "vas a poder administrar todo el contenido vos". Eso no lo decimos con la intención de mentir, pero en cierto sentido es mentira.

  1. Casi nunca el 100% del sitio web es administrable por el cliente. Eso genera relaciones de dependencia y frustra al cliente que se imaginó que iba a controlar todo su sitio web.

  2. La mayoría de los clientes no quieren de verdad administrar todo el contenido de su sitio. Algunas veces solo quieren poder actualizar unos pequeños espacios de contenido.

  3. La interfaz por más genial que sea siguen siendo lo que quedó de una aplicación creada originalmente para blogear. Ahora resulta que pretendemos administrar un periódico completo desde esa cajita de texto. No es tan fácil.

  4. Customizar WP no es tan fácil. Lo hemos tenido que hacer por tantos años que nos hemos vuelto muy buenos en lograr lo que queremos con WP, pero la verdad es que no es tan obvio ni tan fácil lograrlo.

Si el proyecto es relativamente complejo (es decir más que un blog o un sitio semi-estático) se vuelve un dolor de bolas. Si el proyecto es muy complejo es de volverse loco.

Porque puedo

Como mencioné al inicio, a menos de que me vea obligado a usarlo, no pienso usar Wordpress más.

Que usaré

Como mencioné en el episodio #3 de Onda Corta, creo que la mayoría de los sitios web pequeños podrían ser sitios estáticos que no requieren de un CMS para correr.

Creo que en un futuro cercano, con las herramientas correctas un sitio web pequeño para una empresa o negocio se puede desarrollar de la siguiente forma: Jade templates + Sass + Node para procesar algún formulario. Todo esto publicado online en algún servicio en la nube como Heroku.

Para sitios que requieran algún tipo de administración de contenido pienso seguir usando Squarespace. Squarespace provee una plataforma realmente alternativa. El panel de administración de contenido sí fue pensado para que el usuario común pueda agregar, editar o quitar todo tipo de contenido (yo por ejemplo estoy administrando el 100% del Podcast desde el control panel). Es muy amistoso para el usuario y los templates son de primera.

Si alguien se siente atrevido y quiere ponerse en el rol de desarrollador, puede activar el "developer mode" y trabajar directamente con JSON y un Templating Language. Squarespace además sabe que el developer moderno no quiere usar un FTP y Php para trabajar. Todo se hace utilizando JSON, Templates y GIT, una belleza.

¿Y para los blogs?

Creo que para tener un blog sobran recursos mucho más sencillos de usar para el usuario promedio (que no sea un geek) y herramientas mucho más atractivas que WP para los geeks.

Para cualquier no geek yo diría que usen Tumblr.

Para los geeks yo diría que pueden usar Jekyll con el contenido hospedado en Github.

Este blog está corriendo sobre Scriptogr.am. Me gusta porque me permite escribir en Markdown y publicar documentos que tengo en mi cuenta de Dropbox. El app sincroniza los posts de mi Dropbox y los publica online. Una solución moderna a el viejo arte de blogear.

Así que por el momento y mientras pueda: ¡gracias Wordpress! Sayonara.