Programación y flujo de trabajo en Emacs
Llevo un tiempo ocupado en proyectos personales y apenas saco tiempo para escribir. He hablado ya sobre el proyecto de MUD que empecé aquellos aburridos días de confinamiento y que continúo con él. Como ya expliqué, lo comencé con otra persona sólo por el ánimo de aprender un poco de erlang y ahora lo estoy continuando yo solo. De hecho, me decidí a hablar sobre el proyecto porque cuando hablo de uno que tenga entre manos se convierte en vaporware casi automáticamente, dos o tres entradas de blog después. Sin embargo, el presente proyecto, de nombre provisional erlmud, continúa con buena salud y casi se ha convertido en una obsesión. Hay cien mil detalles que atar y mejorar, cada vez más comandos que soportar y parece no tener fin.
Cuando me quedé solo decidí utilizar del revés el criterio que veníamos siguiendo con anterioridad: pasitos pequeños, pequeños avances haciendo cada vez más grandes las capacidades del proyecto. Así comenzamos con un programa básico de erlang que levantaba un servidor escuchando un puerto, al que se podían conectar los clientes e interactuar con él. Se implementaron varios comandos sencillos, que no necesitaban muchas complicaciones de interpretación por parte del programa y, poco a poco, se consiguió que entendiera comandos más complejos que implicaban una acción que afectaba a varios objetos. La filosofía que habíamos seguido era la de «pasitos cortos y medidos», cosas que parecían sencillas de implementar. Pero, al quedarme solo, decidí que el tema era aprender. Total, el mundo no necesita otro MUD y no tengo inconveniente en abandonar el proyecto si me estanco, así que la pregunta que me hacía era: «¿Qué puede estancarme?». La respuesta a esa pregunta fue la implementación de varios comandos que pensé que sobrepasarían mis capacidades de programación o, por ejemplo, el cambiar cómo el sistema almacena y maneja los datos. En vista de que no termino de atascarme con esa filosofía, estoy valorando el dar el salto definitivo. Si éste no me atasca tampoco, es posible que quizá, después de todo, el proyecto no acabe en vaporware. De momento, todo está hecho en un modo erlang básico... ¿por qué no pasarlo al framework que proporciona erlang para aplicaciones concurrentes: OTP?
De hecho, es un rediseño tan drástico que creo que será más conveniente comenzar proyecto desde cero y así: volviendo a la práctica de los «pasitos cortos y medidos» levantar otro proyecto más sólido, aprendiendo de paso el framework OTP, mejorando las cosas que se pudieron hacer mejor en el proyecto inicial.
Flujo de trabajo
Hace poco, alguien me preguntó cómo es mi flujo de trabajo cuando programo y, como una cosa es contarlo y otra verlo, he hecho una captura de pantalla de cómo voy trabajando:
De todas formas lo cuento detalladamente para que no queden dudas.
En el vídeo se aprecia que trabajo con Emacs en una consola en modo texto. Ya he contado por aquí que utilizo KiTTy. Normalmente lo hago a pantalla completa, pero en el vídeo está reducido a una ventana para que sea más manejable el resultado de la captura. En la consola trabajo con varias pestañas, la primera de ellas dedicada a Emacs y luego voy abriendo y cerrando, según necesito, otras.
Cuando hago alguna modificación en el código y quiero probarlo, como
se puede apreciar en el vídeo, utilizo la combinación de teclas de
compilar de Projectile: C-c p c. Normalmente configurado a
ejecutar make, sin embargo, en el Makefile hice una opción que
compila y lanza el programa. Así que esa combinación de teclas, está
llamando a make run. Cuando lo lanzo, me abre un buffer de
compilación y si hay algún error, lo muestra. Desde ese buffer se
puede ir navegando por los errores para poder solucionarlos y volver a
compilar.
Si todo ha ido bien, la aplicación está funcionando y me paso a otra pestaña donde hacer las pruebas del comando. Para el ejemplo, he utilizado dos conexiones y mostrado algunos de lo comandos que soporta el sistema. No tiene mucho más misterio, quizá lo que más guerra me dio fue la parte de programar las salidas y que comprendiera tanto los movimientos por nombre ─ir a sitio─, como los movimientos por puntos cardinales ─norte, sur, etc─, implicando un cambio en la estructura de los datos y el parser de comandos. El anuncio de «eventos» que ocurren ─entrada y salida de personajes en la sala, etc─, fue una de esas cosas que pensé que me iban a bloquear y que se resolvió en apenas un par de ratos; aunque también tuve que convertir la lista de conexiones en un diccionario que asociaba la conexión con el PJ.
¿Por qué utilizo el modo texto? Pues básicamente, porque el proyecto
corre en modo texto en una terminal telnet, aunque en este caso esté
utilizando netcat. Con ello no necesito cambiar de ventana ni de
escritorio, ni de nada. Una combinación de teclas me cambia de pestaña
o crea una nueva, ejecuto los comandos que necesito, la puede dividir
y todo sin salir del editor en el infinito bucle de «compilar, probar,
modificar, compilar...»
Conclusión
Es sólo una muestra de cómo programo. Para otras funciones suelo
utilizar el modo gráfico, por ejemplo cuando utilizo elfeed para
leer las rss, o para escribir este artículo. Sin embargo, para
programar en el proyecto en el que estoy trabajando con erlang
encuentro más fluido el trabajo en modo texto combinando las
capacidades y potencialidades de Emacs y KiTTy.
¿Eso es mejor para todo el mundo? Pues supongo que cada uno tiene sus
manías y sus gustos. Algunos sustituirán KiTTy por una consola con
tmux o screen, otros sustituirán Emacs por su editor favorito.
Esas son mis manías y mis gustos. Supongo que es mejorable, según qué
punto de vista, pero de momento a mí me sirve y me encuentro cómodo.
Paso horas sin tocar el ratón y con los dedos en las teclas sin que
nada me distraiga.
Comentarios