Hoy como cada año (de preferencia en octubre) me sentí con ganas de darle un poco de cariño a karel.js, sin embargo, como cada año, encontré que es una tarea sin pies ni cabeza.
Se me ocurre lo siguiente: hay que despiezar el repo en sus justos componentes:
- libkarel es python y este repo es karel.js, esto podría (debería) incluso ser un paquete en pypi
- cpp quizá hasta en un branch? ¿esto se está usando?
- manual ok, quizá su lugar si sea aquí, ¿que tal una carpeta
docs? ¿qué tal documentar en el readme dónde están publicados esos docs? ¿que tal publicar los logs en github pages automágicamente como una tarea de travis?
- cmd da la impresión de que la solución correcta es tener un paquete en npm llamado libkarel y que una aplicación de línea de comandos solo sea interfaz a esta biblioteca con las funciones.
Esta idea de tener una biblioteca con la parte interna de karel y que pueda ser importada por una aplicación de línea de comandos o por una GUI me es particularmente atractiva.
Solo son ideas para hacer mejor organizadas las cosas, simplificar el CI que viendo el travis-ci.yml es un desmadrito y hacer un poquito más ameno el desarrollo.
Hoy como cada año (de preferencia en octubre) me sentí con ganas de darle un poco de cariño a karel.js, sin embargo, como cada año, encontré que es una tarea sin pies ni cabeza.
Se me ocurre lo siguiente: hay que despiezar el repo en sus justos componentes:
docs? ¿qué tal documentar en el readme dónde están publicados esos docs? ¿que tal publicar los logs en github pages automágicamente como una tarea de travis?Esta idea de tener una biblioteca con la parte interna de karel y que pueda ser importada por una aplicación de línea de comandos o por una GUI me es particularmente atractiva.
Solo son ideas para hacer mejor organizadas las cosas, simplificar el CI que viendo el
travis-ci.ymles un desmadrito y hacer un poquito más ameno el desarrollo.