|
1 | 1 |
|
2 | 2 | ##Contributing Guidelines |
3 | 3 |
|
4 | | -#####Acuerdo de sintaxis |
5 | 4 |
|
6 | | -#####Issues, ramas y nuevas funcionalidades |
| 5 | +¿Quiéres colaborar en el proyecto? **¡¡¡ Genial !!! :)** |
7 | 6 |
|
8 | | -#####Ejecución local |
| 7 | +Pero antes, vamos a explicar como arrancar la aplicación en un entorno local para que no encuentres problemas. |
9 | 8 |
|
10 | | -Para testear la aplicación es posible ejecutarla al completo en cualquier entorno local, para ello el único requisito previo será haber ejecutado el fichero de requisitos que descarga el SDK de GAE necesario para correr en modo desarrollador algunos de los servicios que la aplicación usa y ejecutar el lanzador **runAll.sh**. En caso de que quiera detenerse la ejecución y volver a lanzarse deberán de matarse los procesos en ejecución del servidor de desarrollo, con `` kill -9 <process PID> `` por ejemplo. |
11 | 9 |
|
12 | | -Si sólo se quiere lanzar la ejeución del BackEnd debe lanzarse el script **runBackEnd-StandAlone.sh**, con el que se lanzan los tres módulos. En este caso la detención del servidor de desarrollo detiene los tres módulos. |
| 10 | +####Desarrollo local |
| 11 | +------ |
| 12 | + |
| 13 | +*SMS de desarrolla en un entorno muy característico*, ya que en síntesis son 4 microservicios distribuidos en dos "aplicaciones" de Google App Engine, que además necesitan de un servidor de desarrollo específico que simula el ecosistema de GAE, asignando puertos a las aplicaciones, nombres de dominio y simulando (entre otras cosas) la base de datos NDB. |
| 14 | + |
| 15 | +######Requisitos iniciales |
| 16 | + |
| 17 | +Una vez clonado el proyecto **el primer paso** sería ejecutar el fichero ``requirement_bash.sh``, que descarga e instala todo lo necesario para trabajar. |
| 18 | + |
| 19 | +Es un sencillo script de bash que realiza descargas e instalaciones de forma desatendida, en su mayoría haciendo uso de la herramienta **apt-get**, si no tienes un sistema basado en debian puedes instalar manualmente todos las dependencias del proyecto, ve al fichero y revisa lo que se necesita. |
| 20 | + |
| 21 | +Entre otras cosas lo más importante que realiza el script es: |
| 22 | + |
| 23 | + 1. Descargar el SDK de GAE |
| 24 | + 2. Instalar MySQL |
| 25 | + 3. Instalar algunas herramientas como curl, pip y librerías de conexión. |
| 26 | + 4. Ejecutar los requirements de cada microservicio. |
| 27 | + |
| 28 | +En cada microservicio del BackEnd (en FrontEnd no lo necesita) existe un fichero que instala todas las dependencias de python necesarias en cada caso (que además deben ser instaladas en la carpeta lib de cada uno). |
| 29 | + |
| 30 | +Es fácil que por algún motivo se produzca algún error en la instalación desatendida, si es así revisa el paquete e intenta una instalación manual. |
| 31 | + |
| 32 | +######Desarrollando |
| 33 | + |
| 34 | +Una vez instalado todo lo necesario lo único que nesitarías sería ejecutar ``runAll.sh``, que primero arranca el FrontEnd y el BackEnd (usando respectivos scrips), arranca MySQL y aprovisiona el sistema con datos de muestra para que tengas usuarios de ejempo cargados. |
| 35 | +Como verás, la apliación web se lanza en http://localhost:8080/ y el servidor GAE en http://localhost:8082/ donde podrás ver el estado de la NDB y las instancias (los tres microservicios del backend). |
| 36 | + |
| 37 | +**et voilà !** ya puedes empezar a colaborar. |
| 38 | + |
| 39 | +Si por algún motivo no quieres levantar toda la aplicación puedes levantar solo el BackEnd ejecutando ``runBackEnd-StandAlone.hs`` |
| 40 | +Para detener la aplicación deberás matar los procesos del servidor de desarrollo y para ello lo más sencillo es usar ``kill -p <PID del proceso> `` aunque una manera más rádia es matando todo los procesos de python (si estás editanto con Atom te dará errores después) con ``kill -9 $(pidof python) ``. |
| 41 | + |
| 42 | +####Issues, ramas y nuevas funcionalidades |
| 43 | +------ |
| 44 | +Si no sabes por donde empezar puedes revisar el listado de [**issues**](https://github.com/ButterFlyDevs/StudentsManagementSystem/issues) del proyecto, creando nuevas o reparando y mejorando el código. |
| 45 | + |
| 46 | +Como verás en el repositorio, el ciclo de desarrollo tiene dos fases, es decir, consta de dos ramas, **master** y **develop**. |
| 47 | +La rama master será actualizada únicamente con las actualizaciones de código muy estables mientras que en develop iremos implementando las mejoras y nuevas características en testeo. |
| 48 | + |
| 49 | +Por eso lo ideal es ir trabajando en la rama **develop** y pasar los cambios a master cuando se considere una nueva release estable del proyecto. |
| 50 | +Además de esto, cuando se quiera añadir una nueva caracterísitca o móudulo mientras se reparan bugs o mejora el código en develop se crearía una raḿa con la característica, como muestra la figura (aunque no es estrictamente necesario). |
| 51 | + |
| 52 | + |
| 53 | + |
| 54 | +Para conocer más sobre el modelo de ramas pulsa [aquí](http://nvie.com/posts/a-successful-git-branching-model/). |
| 55 | +Si por otra parte quieres ayudar con la web el proyecto puedes trabajar en la rama **gp-pages** donde usamos jekyll para servir webs estáticas. |
| 56 | + |
| 57 | +####Acuerdo de sintaxis |
| 58 | + |
| 59 | +A la hora de implementar, preferimos usar una sintaxis similar a java para nombre compuestos, usando las primeras letras en mayúsculas en lugar de guiones bajos: preferimos funcionQueHaceAlgo() a funcion_que_hace_algo y los nombres largos de variables, funciones, clases, etc, a los cortos y crípticos. |
| 60 | +Además intentamos documentar los máximo posible el código para que se fácilmente entendible por cualquier desarrollador, sin importar en principio la extensión de las explicaciones. |
| 61 | + |
| 62 | +####Agradecimientos |
| 63 | + |
| 64 | +Gracias por contribuir con SMS, cualquier aporte por pequeño que sea siempre es interesante. |
| 65 | + |
| 66 | +> Juntos hacemos del Open Source comunidad. |
0 commit comments