¿Cómo se organiza el flujo de trabajo de Erlang? Estoy aprendiendo algo de Erlang ahora y estoy usando Rebar, recompilando, reconstruyendo y reiniciando una versión completa (estoy tratando de mantener todo OTP'ish) después de cada edición. Estoy bastante seguro de que hay una manera más inteligente de hacer esto.Flujo de trabajo de Erlang
En eTorrent, estoy usando un pequeño truco que puede gustar:
Cuando se han construido una versión de desarrollo, puede ejecutar el comando make console que tiene la siguiente definición:
console:
dev/etorrent-dev/bin/etorrent console \
-pa ../../apps/etorrent/ebin
básicamente, usa el ebins de lanzamiento para la mayoría de las cosas, pero anula la aplicación ebin para estar afuera en el punto donde normalmente construyes el software. Ahora, ejecutando una consola, puede editar su código, ejecutar make (pulso una combinación de teclas en Emacs), corregir errores, ejecutar make nuevamente y así sucesivamente. Cuando esté satisfecho con su cambio, ingrese en la consola (shell de Erlang) y ejecute l(ModuleToLoad), en cuyo punto el sistema en ejecución obtiene el nuevo código inyectado. OTP recogerá automáticamente el cambio de código implementado en caliente y alterará los procesos. Básicamente, solo tienes que reiniciar bastante raramente cuando trabajas en el código.
En la actualidad, también tenemos pruebas, por lo que puede ejecutar make test en etorrent para ejecutar el marco de prueba en su código recién formado antes de la inyección si desea un poco más de garantía de que el nuevo código funciona.
Con Chicago jefe le acaba de golpear "Actualizar" en su navegador web:
Incluso si su objetivo no es el desarrollo web, podría ser una manera de aprender Erlang que es más divertido que su flujo de trabajo actual. CB imprime muy bien la compilación y los errores de tiempo de ejecución directamente en el navegador.
He estado usando Sync para evitar el bucle temido de edición/recompilación/reinicio. Busca cambios en los archivos de origen y luego vuelve a compilar y volver a cargar el módulo modificado. Imprime errores y advertencias en la consola y los envía a notify-send/growl si está disponible.
Es tan fácil como ejecutar sync:go().
Tome un vistazo a this rebar template para un mejor ejemplo.
Si está desarrollando en un clúster, otra gran característica es el "modo de parche" de sincronización. Con el "modo de parche" cada vez que la sincronización compila con éxito un módulo, envía el código compilado a cada nodo conectado al clúster y vuelve a cargar el módulo.
Para la recarga automática de archivos src con cada edición, puede probar el complemento automático en rebar3.
Recientemente me mudé a rebar3 y me resultó mucho más fácil trabajar en comparación con la barra de refuerzo.