Una de las cosas interesantes del desarrollo es ver como trabajan los demás. Es difícil sentarte al lado de un desarrollador y no aprender ese pequeño truco o herramienta, siempre hay algún detalle que te puede servir o que puedes aportar, así que voy a comentar las que uso a diario y me hacen la vida más fácil.
Fundamentalmente uso Linux y OSX, aunque prácticamente uso las mismas herramientas en ambos. Aparte de las que todos conocemos, grep, ls, cp, mv… mis favoritas son las siguientes:
- vim: lo uso como único editor. No sé si será el mejor, pero usar el mismo editor para todo tipo de fichero es realmente eficiente.
- tmux: es una herramienta que permite tener varias terminales virtuales dentro de una. Es similar a GNU screen. Permite además conmutar rápidamente entre terminales (ctrl-b + NUM o ctrl-b + l), partir la pantalla vertical y horizontalmente (muy útil por si ejecutas un comando y quieres ver la salida de un tail -f).
- ack-grep: es un grep con esteroides, te saca las búsquedas coloreadas, ignora las carpetas .git .svn y demás especiales. Fundamental si eres programador
- git svn: es una parte de git, pero es tan útil para trabajar contra servidores subversion… :)
- gitk y gitg en linux, gitx en osx: son herramientas gráficas para ver las historia de un repo git, la mar de útiles cuando quieres ver los commit, hacer diffs y demás.
- rsync: espectacular herramienta para sincronizar ficheros entre carpetas, sobretodo entre diferentes máquinas.
- curl: para hacer peticiones web, permite hacer test, revisar las cabeceras (con -I, confieso que no puedo evitar echar un ojo a las cabeceras de los servidores web)
- ab (apache benchmark), para ir teniendo idea de las reqs/s, tiempo de respuesta, etc que tiene la applicación web.
- fabric: es una herramienta para automatizar tareas en servidores y permite hacer cosas un poco más complejas que con un simple ssh. Junto con bash y rsync automatizar es un gusto :P.
- firebug y web developer tools de chrome
- ipython: consola python con esteorides
Últimamente estoy probando vagrant (para gestionar máquinas virtuales), cada día trato de hacer músculo con vim, usar más los trucos de bash…
Cada año que pasa esto de platearse unos objetivos me lo creo menos, pero todo sea por hacer el ejercicio mental. El año 2010 ha sido realmente malo, así que esperemos superarlo. Al tema:
- Recuperar la ilusión por desarrollar. He perdido mucha de la ilusión que tenía, no me encuentro muy motivado, no sé si es por los proyectos, porque me hago mayor, cada vez me cuesta más aprender cosas nuevas interesantes, no veo que mi trabajo sea efectivo y sirva para algo. Tal vez esto sea cuestión de tiempo, de encontrar un proyecto interesante o es que quizás haya llegado la hora de cambiar de “negocio”
- Mejorar mi inglés de una vez por todas. No necesita demasiada explicación.
Hace hoy 9 años me operaron de corazón. Era un problema congénito que en palabras textuales del médico “lo resolvía con una mano atada a la espalda” a pesar de que ya era un caso grave (de hecho mi parte derecha del corazón es más grande de lo normal).
Momentos antes de entrar a darme una sesión de rayos X un día antes de la operación, miré por la ventana del hospital y me pegó un “flasazo” de cordura: “y si mañana estiro las punteras en la operación?”. Por suerte (*) estuve dentro del 99% de pacientes que salen vivos y coleando.
Sin embargo, ese momento se quedó bien fijado en mi cabeza y evolucionó a peor, tuve unos meses en los que pensé que aquello no podía haber ido tan bien como los médicos decían y que tal vez el parche que me pusieron se soltaría y moriría el día menos pensado.
Los meses que aquella idea peregrina duraron (el tiempo dio la razón a los médicos) han sido, con mucho, los meses más felices de mi vida.
Y este post es para leermelo cuando tenga que tomar alguna decisión importante y piense: “mejor me quedo como estoy”.
(*) en realidad no fue suerte, fue gracias al trabajo de mucha gente durante años y posiblemente de muchos muertos con el mismo problema que yo.
Cuando mi familia decidio que yo tenia que estudiar una carrera universitaria decidieron que yo debia a ir a una de esas residencias universitarias. No,
no de esas que estas pensando donde la juerga es asignatura troncal,
era mas bien de esas aburridas donde te semiobligan a hacer lo que realmente debes hacer.
Una de las condiciones para entrar y permanecer en ella era hacer 5 minutos de reflexion en la capilla. Visto asi daba algo mas que miedo,
la palabra secta se podia leer en mi cara cuando me lo comentarom, pero bueno,
el resto de cosas estaba bien, asi que tragamos. Tampoco me llegaba el aire al cuello, no habia muchos mas sitios donde las novatadas estuviesen prohibidas.
anyos despues, habiendo reflexionado durante todos los dias durante 3 anyos, me doy cuenta que aqeullos minutos en los que parabas, mientras contabas los segundos para irte, eran un ejercicio realmente bueno. En esos minutos podia organizar el dia, pensar sobre las metedura de pata y en general sobre cosas que ahora no tengo tiempo de pararme a pensar.
Ahora es cuando deberia darme la vuelta y dar las gracias por aquello,tal vez lo haga.
pd: escrito desde el kindle,siento las tildes y enyes.
Cuando comencé a crear agroguía, hace ya casi 5 años, tuve la suerte de tener claro lo que quería resolver, y digo suerte porque la mayoría de proyectos de tecnología que veo a mi alrededor no tienen casi nunca claro a donde quieren llegar (esto es tema para otro post). El primer paso para resolver un problema es tener claro el problema. Dicho esto desarrollé una aplicación que resolvía un solo problema, sin ningún tipo de funcionalidad añadida.
Esto tiene sus cosas buenas y sus cosas malas. Si desarrollas un producto y lo vendes vas a tener que escuchar muchas veces “el software de la competencia hace X e Y, el tuyo no”, te van a aconsejar miles de veces, de personas que saben y que no saben que deberías hacer tal o cual funcionalidad que será un éxito en el número de ventas. Normalmente la gente te agradece mucho más el hecho de que mantengas la aplicación simple a lo que protesta por no tener tal o cual cosa, que, aunque lo veas como fundamental para tu negocio, normalmente se puede pasar sin ello si el producto te resuelve tu problema principal. Somos así de tontos.
Sin embargo pasa el tiempo y ves como mucha gente te solicita cosas muy concretas que te encajan. Pero la cuestión aquí no es que encajen porque un señor muy listo haya sacado su bola de cristal y haya pensando cierta funcionalidad que los usuarios necesitarán, ni encajan porque tenga claro que voy a vender mucho más por ello, si no que lo hace porque en parte me siento en deuda con la información que la gente me está dando (esta es otra cosa que cuando cuento a la gente cercana no entienden “esto es un negocio, javi”).
Ves que encaja y la desarrollas, pero entonces piensas en los usuarios de tu producto y te dices: “no voy a joder a esta gente ahora que ya se ha acostumbrado a usar el producto”. Así que hace un tiempo decidí dos cosas:
- nunca cambiaría el “camino corto”, esto es, la forma de usar la aplicación para resolver el problema original.
- nunca añadiría funcionalidad que entorpeciese la resolución del problema original, esta siempre debe ser “opcional”.
En resumen, de las releases de agroguía nunca se ha tocado el planteamiento original de empezar a funcionar dando a un solo botón, ni como se interpretan los datos, eso sí, se ha añadido funcionalidad, pero siempre opcional (de hecho un tiempo la vendimos aparte), el cliente si se actualizaba iba a seguir funcionando exactamente igual pero si quería podía usar las características añadidas. También tengo que destacar que las releases de agroguía no suelen ser para añadir funcionalidad, si no para mejorar la que hay.
Escribo este post ahora como “autocastigo”. La última release que tenía planeada de agroguía rompía una de esas reglas, no de forma muy importante en mi opinión, pero que tras las primeras pruebas con gente real resultó no ser la mejor idea.
Son cosas como estas las que te recuerdan lo importante que es seguir una filosofía.
