Política de ramificación en git

Al desarrollar software, y en especial al hacerlo en equipo, se hace fundamental utilizar un sistema de control de versiones. No voy a entrar en el detalle de porqué es importante, porque eso está más que cubierto en muchos sitios. Lo difícil es encontrar una manera de gestionar la utilización del repositorio y establecer unas reglas para la creación de ramas, commits, versiones y lanzamientos. Ahora que en la Universidad hemos comenzado un proyecto en el que se nos requiere la utilización de Git, y más concretamente en GitHub, nos hemos encontrado con que:

1.  La mayoría de la gente, al menos en mi Universidad, no saben utilizar control de versiones (lo que daría para hablar un buen rato).
2. Es muy difícil establecer unas reglas para que todo funcione bien y no liarse en exceso a la hora de utilizar Git.

Buscando por ahí se ve que, evidentemente, no hay un estándar como tal para este tipo de cosas, pero hay una serie de buenas prácticas, y una que tiene mucho éxito, y que me parece muy sensata, es esta propuesta, que aún no he encontrado bien explicada en español, así que eso voy a hacer, y ya estando en el tema más adelante, seguramente en otro post, hablaré un poco de la numeración de versiones.

La numeración de versiones es otro aspecto que, al no haber estándares y depender mucho del proyecto y de sus arquitectos y desarrolladores, acaba por ser un caos. ¿Una v1.0 es una versión final? ¿Una v1.0.1 es una versión nueva o solo un parche? ¿La v1.10 puede existir o después de la v1.9 se pasa a v2.0? ¿Utilizar x.y.z o x.y? ¿x.y.z.t? ¿Fechas en el nombre? ¿Build numbers? Hay muchísimas posibilidades, y a lo largo del tiempo con seguridad que nos encontraremos con todas ellas en un sitio y otro. Para los proyectos propios se hace necesario tomar una decisión sobre la política a seguir.

El resumen de todo lo que diré a continuación se encuentra en esta imagen, tomada del blog de Vincent Driessen, que habla de cinco ramificaciones a la hora de desarrollar, que me parecen lo más simple y sensato:

Visto así parece un poco abrumador, pero si vamos por partes vemos la lógica. En el post original está mucho más detallado, yo aquí solo quiero hacer un resumen general para poder referirme a él en el futuro.

GameRunner IV: Doble Buffer

Tras ver algunas de las funciones que aporta el Runner, ahora toca terminar su implementación viendo la parte más compleja de entender, aunque no tan difícil de implementar: el dibujado y actualizado de cada frame.

Ya dije que esta aplicación utiliza el patrón del Doble Buffer, y en la función draw() es donde hacemos uso de este patrón. Para explicarlo, tengo que extenderme un poco.

Los computadores son, en el fondo, bestias secuenciales. Lo bueno es que son capaces de romper las tareas más largas en pequeños pasos que se realizan uno tras otro a muchísima velocidad, pero secuencialmente. Sin embargo, nuestros usuarios necesitan ver que las cosas ocurren en pasos completos instantáneamente o ver mútliples tareas simultáneamente. Aunque con los multi-core esto es un poco menos cierto, siguen siendo pocas las tareas que se realizan realmente al mismo tiempo.

GameRunner III: El Runner

En la anterior parte definimos las funciones generales que tendrá el GameRunner con el que haremos algunos de los próximos proyectos. En esta última parte del tutorial crearemos el bucle en sí, y definiremos algunas cuestiones que determinan el funcionamiento del motor de juego: inicializar los elementos necesarios, funciones para dibujar el canvas, actualizarlo, arrancar y parar el juego, añadir eventos y unas cuantas cosas más.

Librerías y Frameworks JavaScript

Ya que he comentado algunos engines o motores para facilitar la vida a la hora de desarrollar juegos, creo que también es útil hablar un poco de otros tipos de frameworks de Javascript que pueden tener su utilidad a la hora de aproximarse a otro tipo de aplicaciones o, incluso, a acompañar y mejorar a esos motores.

Sin duda alguna el rey de los frameworks JS es jQuery. Es muy completo, muy bien mantenido, tiene unas cuantas variantes (siendo jQuery Mobile la más interesante), pero puede ser algo pesado o excesivo para algunos proyectos. Además, está ya más que bien presentado en multitud de lugares. Sin embargo, hay otra gran cantidad de frameworks menos «generalistas» y muchas librerías útiles, para tareas más específicas, que vale la pena comentar, como puede ser geolocalización, bootstrapping o minificación de código, entre otras muchas.

Lo fundamental es pensar: ¿qué necesito para mi aplicación? ¿Qué funcionalidades extra voy a necesitar facilitarme para poder centrarme solo en lo mío? Porque no hay que olvidar que los frameworks están para eso: para apoyar, ayudar a olvidarse de detalles de funcionamiento en general para poder pasar más tiempo desarrollando la funcionalidad propia, aquello que hará a tu aplicación única.

Hay una multitud de áreas que pueden cubrir diferentes librerías, es difícil decidirse por uno concreto, pero dentro de los que son más específicos sí que hay algunos que destacan más que otros, y trataré de centrarme un poco más en ellos.

Índice

1. Presentación

Engines JavaScript I: Crafty

Cuando estamos construyendo un juego basado en HTML5, es muy útil tener una estructura consistente en el código y unos patrones de diseño concretos para seguir a la hora de organizarlo. Un buen motor de juegos ayuda con esto y, sobre todo, te ahorra mucho tiempo al proveer de muchas funciones ya escritas, testeadas y probadas, como pueden ser los esquemas de control del juego. Además te da la solidez de una comunidad que la apoya y la mantiene en el tiempo, que te ayuda en casos de quedarte atascado o necesitar apoyo. Crafty, anteriormente conocido como CraftyJS, es un motor pequeño, simple y ligero que ayuda en esta tarea. Es además de código abierto y completamente gratuito, que no viene mal.

Pero, ¿qué es Crafty?

Crafty es una colección cohesiva de librerías Javascript que provee de un entorno de trabajo para construir juegos basados en el navegador utilizando tecnología web estándar. En otras palabras, es un motor de juego HTML5 basado en Javascript. Está diseñado para hacer simple el desarrollo de videojuegos con gráficos en 2D.