[Desarrollo] Ideas de desarrollo

[binary-sequence]

Ideas de desarrollo

Objetivos:

• Facilidad de de uso de pilasweb-engine para usuarios que sepan usar pilas-engine.
• Presentar en partes separables la librería del entorno IDE. Un usuario puede querer usar sólo la librería incluyéndola en una etiqueta <script> en su página web.
• La librería debe poder actuar sobre un canvas de html5 independientemente del layout o de los demás elementos de la página en la que el usuario pretenda incluirla.
• Intentar que pilasweb-engine sólo tenga front-end para poder aprovechar la rama gh-pages de github como alojamiento y servidor de la aplicación. La API sería un subdirectorio doc/ en la rama gh-pages.

Nota: Iré colocando en comentarios los resultados de mis pruebas.

Diseñar para tres escenarios:

1. Desarrollo de pilasweb
   • CoffeeScript
   • Precompilación con node.js.
   • RequireJS + optimizer.
   • Su formato final es pilasweb-engine-0.0.min.js.
2. Uso de pilasweb (Asistente, intérprete, cargador de ejemplos, generar juego, etc)
   • Jade
   • Stylus
   • CoffeeScript
   • Precompilación con node.js.
   • RequireJS + optimization.
   • Su formato final es pilasweb-engine-ide-0.0.min.html
   • El usuario podría programar en CoffeeScript, Python o, JavaScript. Precompilados y ejecutados en tiempo real.
   • Preferible compilación en cliente. (CoffeeScript Core compiler, skulpt)
   • o, si no fuese posible, compilación con node.js: Necesaria conexión a internet y un servidor node.js.
3. Distribución de juego
   • Genera empaquetado del juego programado listo para ejecutar en local (sin necesidad de conexión a internet).
   • Su formato final _nombre_de_usuario-nombre_dejuego.zip.
   • Contiene _nombre_de_usuario-nombre_dejuego.html (css + js + pilasweb-engine-0.0-min.js)

     Layout html5 responsive (Mobile first).

   • Aplicación web (IDE) apta para uso en dispositivos móviles.
   • Editor táctil para facilitar la escritura de código en pantallas táctiles.

     Trasladar la estructura del repositorio pilas a pilasweb.

   • Crear, en la medida de lo posible, el código fuente de pilasweb-engine con semejanza al código fuente de pilas-engine.

[binary-sequence]

Estoy haciendo las pruebas en un repositorio que he hecho en github. -> https://github.com/binary-sequence/test_CoffeeScript-pilasweb

• CoffeeScript implementa una forma de generar clases. No es necesario usar el constructor Class de MooTools.
• jsduck no puede generar la documentación a partir de ficheros '.coffee' porque CoffeeScript usa palabras clave que jsduck interpreta como errores. Si se hace jsduck sobre los ficheros '.js' generados con coffee, el código fuente que aparece en la documentación es el de JavaScript. Esto me ha llevado a pensar ¿y si se documentan los dos?
  • Se podría forzar la documentación de coffee jugando con los comentarios de CoffeeScript/JS; pasando a jsduck una versión con el código CS comentado a JS y, pasando a coffee una versión con los comentarios tipo JS comentados a coffee. ( Uso de comando sed ).
• Requirejs optimizer (minification). La minificación se ha conseguido con éxito; un sólo fichero js contiene toda la librería + requirejs + librerías externas. Así, sólo es necesaria una etiqueta <script src="pilasweb-engine-0.0.min.js"></script>. En el código de usuario, para asegurarse de que ha cargado pilas, se usa require(["init"], function(pilas) { // Código de usuario... } ( Podría ser necesario usar el evento onload dentro de ésta. ).

[hugoruscitti]

Wow, interesante.... hace unas horas que estoy mirando la implementación en coffee y está impecable... concuerdo con todas las ideas, me parece muy bueno el enfoque. Y el make funciona perfecto :)

¿Te parece si movemos el código actual de pilasweb a un branch y dejamos master para esta nueva versión con coffee?. Te puedo agregar como admin del repositorio.

Yo puedo agregar algunos tests para esta nueva versión y que se vean en travis y en la portada de github: https://travis-ci.org/hugoruscitti/pilas

Sobre la documentación, ¿docoo nos queda chico?, lo usé una vez en un proyecto y me gustó bastante:

http://jashkenas.github.com/docco/

También puedo implementar la física básica de box2d, ¿que te parece?

[binary-sequence]

Rama/Branch master y pilasweb en coffee

Me parece perfecto usar la rama master para la nueva versión con coffee. Estaba esperando que dieses el visto bueno.

¿Cuál es la utilidad de travis-ci?

He visitado su página web, pero sigo sin entender su utilidad.

Docco

Cuando encontré el problema de JsDuck+Coffee, busqué otros sistemas de documentación. El único que encontré para coffee era docco. La propia documentación de docco dice estar hecha con docco y, no me gustó el estilo. Así que, antes de adoptar un nuevo sistema de documentación, prefería agotar las posibilidades con JsDuck, que es el que habías elegido desde el principio. He conseguido una forma de documentar con JsDuck el código coffee usando caracteres de comentarios y el comando sed para formatear las líneas de texto. Puedes verla en la rama/branch jsduck del repositorio de prueba. ¿Te parece un buen "precio a pagar" por tener la documentación con JsDuck o nos pasamos a docco?

[binary-sequence]

Librería vs IDE

¿Hacemos los dos en el mismo repositorio en carpetas separadas o, hacemos que la librería sea un submódulo del IDE?

[hugoruscitti]

Genial !!!, entonces hoy mismo por la noche configuro bien el repositorio, así convertimos la rama master a la nueva versión de coffee :)

Travis-ci ayuda a ejecutar todos los tests del proyecto, por ejemplo si hiciéramos código de prueba con phantomjs, travis-ci podría encargarse de correr todos los tests cuando hacemos un push en github.

http://metaskills.net/mocha-phantomjs/ http://phantomjs.org/

Generalmente la suite de tests se prepara para correr de forma local, y travis-ci ayuda a ejecutarlo de forma remota. Si te parece buena idea, yo podría colocar una nueva regla en el archivo Makefile para probarlo.

Con respecto a la documentación, jsduck me gusta mucho, intentaría tratar de usarlo en primer lugar a ver cómo nos resulta, siempre me gustó el feature de editor que trae jsduck.

Sobre librería o IDE, me gusta la idea de separarlo en dos, imagino que separarlo en dos nos puede permitir usar un repositorio (IDE) como anfitrión para nuevos usuarios, tenerlo en gitpages o heroku, que siempre se pueda ingresar en una web y verlo funcionando. Y el otro repositorio, el de librería, sería mas conveniente para programar el core de pilas y para los programadores que lo quieran usar en sus juegos.

Hoy por la noche hago los cambios, mil gracias !!!