Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Considerar un refactor grande para mejorar la mantenibilidad #119

Open
categulario opened this issue Mar 24, 2019 · 4 comments
Open

Considerar un refactor grande para mejorar la mantenibilidad #119

categulario opened this issue Mar 24, 2019 · 4 comments

Comments

@categulario
Copy link
Contributor

Hace ya varios meses que http://karel.categulario.tk está funcionando bastante bien. He portado las partes importantes de este karel y aunque faltan algunos detalles creo que ese podría ser el karel fácil de mantener que ha hecho falta todo este tiempo. Está hecho en vue, las cosas están en módulos y componentes, las dependencias se han reducido o externalizado a npm. Algunas características del karel anterior están re-pensadas u omitidas, es una buena oportunidad para tomar mejores decisiones por aquí y por allá. Incluslo la documentación es fácil de escribir para ese karel (usé sphinx).

El código fuente está en https://gitlab.com/categulario/karel-vue

@lhchavez
Copy link
Member

hubiera sido bueno que nos hubieras involucrado antes de empezar, porque a a ser difícil dejar karel.js (la implementación oficial) en favor de otra, aunque existan buenos argumentos a favor.

puedes ver mejor cómo ir portando las cosas de este repo poco a poco?

@lhchavez lhchavez changed the title Y si vamos agarrando el nuevo karel? Considerar un refactor grande para mejorar la mantenibilidad Mar 24, 2019
@categulario
Copy link
Contributor Author

si lo pensé, pero sinceramente los escalones que hay que subir no son todos suficientemente pequeños para decir "se puede hacer poco a poco". Lo intenté, en serio, llevo años pensando cómo contribuir a este repo(véase mi último commit de hace mil años) y los mismos años topándome con pared aquí y creo que no soy el único topándose con pared dicho sea de paso (véase que nadie contribuye nada por lo difícil que es). No tengo el conocimiento que tu tienes en la burocracia involucrada en cambiar la implementación de karel así que no veo desde aquí por qué sería tan complicado.

Habiendo aclarado ese punto, lo que tengo en ese repo tiene repensada la interfaz, el intérprete es exactamente el mismo (¿ya viste que tienes commits ahí?) y lo podemos modularizar tanto como sea necesario. Imagino por ejemplo tener más bien un repositorio para un módulo javascript npm-instalable que contenga solamente el intérprete, para ser usado ya sea por una interfaz como por una versión de línea de comandos. Ya sabes que el tiempo de todos es finito, y regresar a este repo es toparse con un muro que prefiero destruir y volver a construir (pro tip: ya lo hice) que ver dónde se va parchando poco a poco.

@lhchavez
Copy link
Member

ok, si todo lo que interactúa con el compilador/intérprete es idéntico eso elimina muchas barreras.

de igual forma hay que mantener a todos los stakeholders informados, porque hay más gente que depende de esto. aunque sea bueno el cambio, es un cambio y a la gente le asusta eso.

te late si continuamos la discusión en #kareljs en el slack? hay que pensar en un plan de migración mejor que "tirar y volver a construir" entre todos.

@categulario
Copy link
Contributor Author

tendremos que hacer esto de la invitación de nuevo, no se que pedo con mis credenciales de slack.

categulario [at] gmail [dot] com

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants