https://github.com/lausuper/Robotica
- NodeJS
- Git
La guia de instalación de nodejs en el readme del proyecto esta desactualizada. Es necesario que instalen la ultima version para su distribucion de Linux o sistema operativo que vayan a utilizar, sin utilizar los repositorios oficiales de su distribucion, ya que a veces estos se encuentran desactualizados.
Pasos:
- Clonan el proyecto: git clone https://github.com/lausuper/Robotica
- Se situan en el directorio y ejecutan npm install para instalar todas las dependencias de desarrollo necesarias.
- Se ejecuta bower install para instalar todas las dependencias del front-end necesarias.
Las dependencias que se instalaran con npm se encuentran en package.json y bower.json para las de bower. Ambos son administradores de paquetes, generalmente utilizados para diversos propositos que de vez en cuando se cruzan. Con npm instalamos las dependencias de las herramientas para generar el código HTML (ej: gulp) y con bower las dependencias que serán utilizadas por el front-end (ej: jquery).
Ejecutar gulp build.
Es posible tambien utilizar gulp serve para levantar un servidor HTML rapido y acceder al contenido generado.
Gulp es una herramienta que consiste de un pipeline donde se aplican diversas tareas a los archivos o datos que pasan por el mismo. Las tareas pueden incluir la compresion del codigo HTML y JS, entre otras. El resultado final de gulp es el HTML listo para ser servido en la nueva carpeta dist creada.
Todos los archivos HTML, JS o imagenes, seran procesados por gulp automaticamente e incluidos en la carpeta final creada.
El proyecto tiene un directorio raíz, donde se encuentran:
- Las tareas que realizara gulp para construir el HTML (gulp-tasks).
- Algunos programas de ejemplo para el robot (sample-programs).
- El codigo del simulador y del IDE (src).
- Libraries que no pudieron ser descargadas con algun gestor de paquetes (third-party).
La aplicacion consiste en una pagina principal que contiene el simulador y el IDE con los bloques necesarios para mover el robot.
Los menu's u opciones de la aplicacion se ven mediante modals.
Cada vista o componente, es decir, tanto el home como los modals tiene su propio "modulo" (home tiene su home.js), y sera el encargado de cargar su HTML y ejecutar el JS pertinente al mismo.
La programacion por bloques está implementada utilizando Blockly. En /src/app/home/blockly/ se puede encontrar:
- El html del toolbox, es decir, el html que define que bloques estaran disponibles y en qué orden.
- El archivo JS que define los bloques creados para manipular el robot. Dado un conjunto de bloques, Blockly genera (traduce tanto el codigo necesario para ejecutar el simulador (código JS) como codigo Arduino. Tambien genera archivos XML que permiten guardar y cargar bloques para usar en otro momento.
El simulador es un juego hecho con MelonJS.
En /src/game/ se puede encontrar:
- El directorio data que contiene las sprites (imágenes) utilizadas en el juego y los mapas.
- El directorio js que contiene:
* Entidades de MelonJS, entre ellas el código que contiene el comportamiento del robot.
- Plugins propios y modificados para simular los sensores o debugguear.
- Las screens que son las escenas (cargando, jugando) del juego.
- Y el game.js que es el archivo que carga el juego.
La entidad correspondiente al robot contiene un loop (update) que interpreta las instrucciones guardadas en un arreglo de instrucciones que es llenado cuando se hace click en play en la aplicación.
Se utilizan los issues para registrar trabajos por hacer o bugs en la aplicacion.
Pasos a seguir:
- Antes de comenzar a trabajar en un issue, es necesario crear una nueva branch (desde el branch dev) para trabajar sobre el mismo.
- Una vez que los cambios hayan sido realizados, se pushea el branch que luego sera utilizado para crear un nuevo pull request. Bajo la pestaña de branches, es posible visualizar las branches del repositorio. Al lado de nuestra branch se encuentra el boton para crear una nueva pull request.
- Se identifica en la pull request los cambios realizados y se espera a la revision de otro desarrollador.
- Una vez que los demas colaboradores probaron en el branch los cambios y no encontraron errores, se realiza un merge.
Se utiliza siempre la branch master para el ultimo release estable. La branch dev se utiliza para desarrollo y sera mergeada una vez que se cosidere estable.