Skip to content

desarrollo

Integración continua: drone.io

Los servidores de integración continua se utilizan principalmente para garantizar que todo el código que se sube a los repositorios de un proyecto es correcto. Entendiendo como «correcto» que el nuevo código permite seguir compilando el proyecto sin errores y que pasa las pruebas automatizadas (tests unitarios, de integración, …)

Su funcionamiento es sencillo. Se componen de procesos que corren automáticamente y comprueban cada poco tiempo si ha habido cambios en los repositorios de código, aunque normalmente también admiten que se les programe para, por ejemplo, que se ejecuten a una determinada hora. Pero por lo general se configuran para que cuando se detecte un cambio se descarguen el código, lo compilen si es preciso, ejecuten las pruebas, y si todo fue correcto generen los binarios, empaquetados, o lo que requiera el lenguaje de programación utilizado y la configuración del proyecto.

El resultado de cada ejecución de cada proceso de un servidor de integración continua normalmente se puede consultar a través de una web que proporciona el propio software del servidor. De esta forma cualquiera puede ver si el código actual subido al repositorio compila antes de descargárselo a su máquina local.

Otras de las ventajas, cuando se trata con lenguajes de programación que tienen que compilarse, como C/C++ o Java por ejemplo, es que la generación del ejecutable o empaquetado se realiza siempre en una misma máquina, en un entorno estable y controlado, en vez de en la máquina de un desarrollador cualquiera del equipo.

Los proyectos de código abierto tradicionalmente se limitaban a ofrecer el código fuente y las instrucciones para su compilación en algún repositorio público gratuito, y dependiendo del lenguaje de programación y de las características del proyecto, los binarios y recursos resultantes para los sistemas operativos más extendidos que cada proyecto generaba según sus posibilidades, aunque no todos podían permitirse generar todo para todos los entornos.

Hoy en día, en el desarrollo de cualquier proyecto, medianamente serio, en cualquier empresa, también medianamente seria, los servidores de integración continua son, como se suele decir, un «must». Es decir, no se concibe el desarrollo de un proyecto sin ellos. Lo único que tiene que decidirse es que software utilizar, ya sea uno gratuito, como Jenkins, o uno comercial, como TeamCity, por poner un par de ejemplos.

Sin embargo, para los proyectos pequeños que algunos desarrollamos en casa y luego liberamos como código abierto esto no suele ser una opción. No tanto por la instalación y configuración del software del servidor, sino por el propio servidor. A la mayoría no nos resulta rentable invertir en la adquisición, mantenimiento y actualización de un servidor de integración continua propio. Afortunadamente, como ocurre con los repositorios gratuitos, también existen servidores de integración continua gratuitos.

Yo en particular estoy ahora utilizando drone.io, que permite utilizarlo de forma gratuita para tantos proyectos de código abierto como se quiera, aunque también tiene tarifas para repositorios privados. Yo lo utilizo principalmente porque tiene un buen soporte para Dart, el lenguaje que llevo utilizando para mis proyectos personales en los últimos años.

La configuración de los proyectos se realiza a través de una interface web muy clara y bien organizada. Los parámetros básicos que se tienen que indicar para cada proyecto son la url del repositorio, el lenguaje de programación (C/C++, Dart, Erlang, Go, Groovy, Haskell, Node, Java, PHP, Python, Ruby, Scala, …), las variables de entorno, y los comandos (Linux) a ejecutar para compilar el proyecto y ejecutar las pruebas.

Si el proyecto utiliza una base de datos, la configuración permite indicar el tipo de base de datos que se necesita para la ejecución de las pruebas (MySQL, PostgreSQL, MongoDB, Redis, Memcache, …) El servicio creará automáticamente una instancia de base de datos del tipo seleccionado para poder ejecutar las pruebas y la destruirá también de forma automática una vez acabadas. La url, usuario y password son siempre los mismos, y están perfectamente documentados en las páginas de ayuda de la propia web.

Otra característica interesante del servicio es que permite realizar deploys automáticos. Es decir, copiar el resultado de la compilación a otro servidor y desplegar la nueva versión si es preciso.

Por último, comentar que el servicio ofrece urls que se resuelven como imágenes y con las que se puede comprobar de un sólo vistazo el estado que se encuentra un proyecto:

La imagen muestra el resultado del último build, de color verde si se ejecutó con éxito, o de color rojo si falló. Pinchando sobre la imagen se accede a una página web donde se muestra el detalle de la ejecución de cada comando como si se tratara de una consola de línea de comandos.

Copiando repositorios de Google Code a GitHub

La primera vez que me planteé subir algo de código de forma abierta a Internet usé los repositorios de Google Code, y desde entonces hasta hoy he acumulado hasta 15 repositorios distintos correspondientes a otros tantos proyectos:

https://code.google.com/u/101388150953455772115/

Sin embargo, hoy en día el servicio más popular de este tipo es sin duda GitHub. Y hasta casi cierto punto se le puede considerar una especie de red social para desarrolladores. Llevaba un tiempo rondándome la idea de darle un tiento, y ayer por fin me di de alta y repliqué allí todos mis repositorios:

https://github.com/jcmellado?tab=repositories

Curiosamente en Google Code siempre he utilizado Subversion para el control de versiones, pero en GitHub he querido cambiar, honrando el nombre del servicio, y he utilizado git. Para mi no deja de ser un sistema de control de versiones u otro, no tengo preferencias en ese aspecto.

En un principio quería tener los dos servicios sincronizados, pero después de leer documentación y rebuscar un poco por Internet no he encontrado ninguna solución que me acabase de convencer al cien por cien. Aunque evidentemente mantener dos repositorios para un mismo proyecto no tiene sentido a menos que estén automáticamente sincronizados. De momento me he conformado con que GitHub sea una copia de Google Code y con el tiempo ya iré decidiendo como gestionar todo de la mejor manera posible.

Desde el punto de vista técnico, los pasos que he tenido que dar para crear los repositorios en git a partir de uno en Subversion (svn) están bien documentados en Internet, así que sólo he tenido que ir siguiendo el guión.

Primero crear un repositorio git en local haciendo referencia al repositorio svn:

git svn init https://.googlecode.com/svn/ --stdlayout

Después recuperar el contenido del repositorio svn:

git svn fetch

En mi caso no tengo ramas, ni quería mantener en git ninguna, ni siquiera la trunk de svn, así que la borré:

git branch -d -r trunk

Un pequeño problema con el que me encontré, es que al subir el historial de cambios de svn a git, mostraba mi dirección de correo electrónico en vez de mi nombre de usuario de GitHub. Afortunadamente encontré en Internet una instrucción para modificar todo el historial de cambios:

git filter-branch -f --env-filter
"GIT_AUTHOR_NAME=''; GIT_AUTHOR_EMAIL='';
GIT_COMMITTER_NAME=''; GIT_COMMITTER_EMAIL='';"
HEAD

El último paso es subir todo desde el repositorio local al repositorio real remoto en GitHub:

git remote add origin https://github.com//.git

git push -u origin master

Puede parecer mucho trabajo estar haciendo todo esto cada vez, pero en la práctica no actualizo tanto mis proyectos para como que sea un problema, y los repositorios en GitHub se pueden borrar y recrear completamente muy fácilmente.

Código fuente de juegos comerciales

En estos últimos días ha terminado de liberarse el código fuente de una serie de juegos «indies» bastantes populares: Aquaria, Gish, Penumbra Overture y Lugaru. Todo esto dentro de una iniciativa (ya finalizada) llamada «The Humble Indie Bundle (pay what you want)» que permitía a los usuarios pagar el precio que quisieran por estos juegos, además de World of Goo, para el que no se va a liberar los fuentes. Una campaña que si bien puede parecer arriesgada, ha conseguido recaudar 1.273.613 dólares, de los cuales el 30,85% (392.953 dólares) han sido destinados a Electronic Frontier Foundation y Child’s Play Charity.

Cada proyecto ha puesto los fuentes en un sitio distinto y con una licencia distinta. Aquaria lo ha colgado en un repositorio público con Mercurial y licencia GNU, Gish en un simple zip con licencia GPL, Penumbra Overture en un repositorio con git y licencia GNU, y Lugaru en otro repositorio también con Mercurial pero con licencia GPL2. Mucho que cotillear ahí dentro.

Lo bueno que tienen estos proyectos es que funcionan para las tres plataformas más extendidas actualmente: PC, Mac y Linux. Además de que son juegos de tipos completamente distintos. En 2D y 3D. Aunque naturalmente la idea no es que se compile el código y se haga el mismo juego con gráficos o sonidos distintos. Eso no tiene ningún sentido. Al menos no más allá de un homenaje al juego original. Lo que si puede servir es para que algunos programadores se fijen en como están resueltos algunos problemas que les impiden avanzar en sus proyectos. O tomar decisiones acerca de cuales librerías multiplataforma utilizar. Sobre todo cuanto se está empezando y no se tiene criterio para tomar este tipo de decisiones.

En cuanto al código en si mismo, me ha llamado la atención que Gish esté hecho en C, y no en C++ como el resto. Pero por lo demás no hay muchas sorpresas, ya que lógicamente usan SDL, OpenGL y OpenAL. Y sin ninguna capa de abstracción, o muy sencillas, en la mayoría de los casos, como era de esperar. Los ficheros de mayor peso son los que hacen la mayor parte del trabajo, y contienen en algunos casos métodos de bastantes cientos líneas de código, de miles en algunos casos. También hay código comentado, obsoleto, o con indicaciones del autor acerca de su propósito, normalmente para activar algunos procesos de depuración específicos. Para compilar contra una plataforma u otra se usan directivas #ifdef embebidas dentro de las clases en los puntos en los que fueron necesarios ponerlos. Penumbra tiene un motor separado, ya que es un proyecto más técnico que surgió a partir de unas demos tecnológicas, pero el resto son más programas «de una pieza» a los que se han ido añadido clases a medida que hacían falta.

Curiosamente, o no, el comentario de todos los programadores que han liberado su código es «ahí lo tenéis, pero no esperéis gran cosa». La mayoría se muestra orgullosa de que funcione y que fuera un éxito, pero a la hora de mostrar el código lo ven de otra forma. Que si es un lío. Que si es una mezcla de varios proyectos anteriores. Que si se hizo después de un par de copas. En fin … Supongo que esto pone el desarrollo de este tipo de software al nivel de la «artesanía» que sigue siendo hoy en la mayoría de los casos. Crear diseños sólidos, módulos debilmente acoplados, interfaces claras, y todo ese tipo de características que propugna la ingeniería del software es algo deseable, pero también muy dificil y costoso. Un programador trabajando por su cuenta en un proyecto personal puede permitirse el lujo de empezar la casa por el tejado y luego ir uniendo el resto de las partes. No sé a qué vienen tantos reparos. La mayoría del código que se produce hoy en día, y se produce una barbaridad, tiene que ser por fuerza mediocre. Ya es hora de que nos permitan sentirnos orgullosos de nuestro trabajo.

Google I/O 2010: Session Videos

Google I/O 2010En la web de la reciente Google I/O 2010 ya puede accederse a los vídeos individuales de cada una de las sesiones técnicas que se desarrollaron durante el evento.

Más concretamente, en la siguiente dirección:
http://code.google.com/intl/es-ES/events/io/2010/sessions.html

Los vídeos cubren las sesiones integras, de una hora de duración cada una, con un formato de 45 minutos de exposición y 15 de preguntas. Y teniendo en cuenta que hubo casi 100 de estas sesiones, pues la cantidad de información disponible es realmente grande.

Evidentemente las presentaciones son para promocionar productos y tecnologías de Google. Como Android por ejemplo, incluyendo un vídeo titulado «Writing real-time games for Android redux» que presenta un caso real de un juego desarrollado para esta plataforma. Desde aspectos puramente técnicos, hasta otros de tipo promocional y económico. O sea, como hacer un juego para que funcione en la mayoria de las plataformas existentes, que además vaya rápido (30 FPS), y que se venda bien. Eso sí, lo que no menciona por ningún lado es lo desesperadamente lento que va el emulador del SDK sobre un PC «normalito».

Sobre HTML5 hay unos cuantos vídeos, aunque la mayoria utilizados como excusa para promocionar Chrome, el navegador de Google. En «Developing With HTML5» pueden verse las palabras claves a seguir: el popular canvas (para acceder al área de dibujado), WebGL (la versión web de OpenGL), las etiquetas audio y video (de uso obvio), localStorage (para almacenar datos de forma local), Web SQL DB (para ejecutar queries SQL desde JavaScript), Worker Threads (para ejecutar hilos desde JavaScript), y unas cuantas cosas más, como mejoras en CSS (animaciones y drag and drop de forma nativa) o un sistema de notificaciones para alertar a los usuarios de un determinado evento.

En «GWT + HTML5 can do what?!» se explican detalles del «port» de Quake a HTML5 usando GWT. Muy técnica, y con un ritmo un poco lento, pero que diablos, ¡el Quake en un navegador!

El resto de vídeos están englobados dentro de servicios, productos y tecnologías como Google App Engine, Google Maps API (o cualquiera de las decenas de API de Google), Buzz o Wave, y más, mucho más.

Herramientas de Desarrollo de Aventuras Gráficas

Monkey IslandDespués de mi reciente experiencia con la segunda parte de Runaway, he estado mirando a ver que herramientas hay disponibles actualmente por Internet para la elaboración de aventuras gráficas. Este es un género de juegos que parece animar mucho a la gente a desarrollar editores propios. Posiblemente porque es un tipo de programa que causan una falsa sensación de «sencillez». Al fin y al cabo, vistos asi por encima, parecen constar tan sólo de un escenario 2D con objetos dibujados dentro del mismo, con un personaje que se mueve a golpe de ratón por un camino predefinido, una línea de textos, un inventario, y unas poquitas cosas más. Ni siquiera parece que haga falta que todo el conjunto se mueva a gran velocidad. Y razón no les falta a quienes dicen eso, pero del dicho al hecho hay un trecho.

Es el legado que dejó Scumm (Script Creation Utility for Maniac Mansion), la famosa herramienta de desarrollo de aventuras gráficas de Lucas. Desde su popularización, siempre ha parecido lógico pensar en que hacer una herramienta de «point&click» era el método ideal para crear este tipo de programas sin conocimientos técnicos previos. Aventuras gráficas para las masas. Y la verdad es que como programador he de confesar que no deja de tener su encanto pensar en ello. Aunque leer acerca de los problemas y soluciones que se plantean en la práctica durante la elaboración de una aventura gráfica sirve para ponerle a uno los pies en la tierra. Aunque eso nunca será impedimento para que unos y otros lo intenten, aunque sea sólo por el placer de intentarlo.

He encontrado bastantes programas por la red, aunque muchos de ellos proyectos personales que han quedado obsoletos y abandonados poco a poco con el paso del tiempo. Guiándome un poco por el aspecto de la web (hay que saber venderse) y las fechas de las últimas versiones publicadas (hay que actualizar con frecuencia) he estado ojeando las siguientes herramientas:

Wintermute (WME): Según reza en la portada de la web, el «Wintermute Engine Development Kit» es una herramienta para el desarrollo de aventuras en 2D y 2.5D (personajes 3D sobre fondos 2D). Así a bote pronto parece un programa que ha sabido adaptarse a los cambios tecnológicos y que ofrece algo bastante más allá del clásico 320×200 donde se anclaron otros. El editor de escenarios y el organizador de proyectos parecen tener la estructura lógica que uno espera que tengan este tipo de software hoy en dia: árbol de entidades, pestañas de propiedades, editores WYSIWYG, soporte para varios idiomas, … Se puede usar gratuitamente en proyectos comerciales, aunque se agradece una donación para continuar con el desarrollo.

Adventure Game Studio (AGS): En comparación con el anterior creo que lleva peor lo de la edad, aunque tiene una comunidad muy grande con un buen número de proyectos finalizados. La limitación a 800×600 llama bastante la atención cuando eliges la opción de crear un nuevo proyecto, así como la edición de paleta. Leyendo entre líneas se puede sobreenteder que están en contra del alarde técnico en favor de la calidad de la aventura. El editor parece bastante complejo de abarcar de una sola vez por el gran número de opciones que ofrece, aunque tiene detalles curiosos, como mostrarte el script equivalente al resultado de elegir determinadas opciones en los cuadros de diálogo. Pero lo mejor de todo es sin duda la opción «Make my game..»

Lassie Adventure Studio (LAS): Este producto está más orientado a obtener beneficios por parte del autor que el resto y tiene la peculiaridad de tener soporte para la distribución via web. Se presenta en dos versiones, una hecha en Flash que genera un fichero SWF que puede reproducirse desde la web o distribuirse como una aplicación independiente, y otra en la que sólo se puede trabajar desde dentro del propio entorno de Director (Adobe) y sólo tiene la opción de generar un fichero para su distribución independiente. Tiene una página de recursos bastante completa.

Adventure Game Authoring System (AGAST): Este realmente es un lenguaje de script, ya que el autor parecía estar más interesado en crear un compilador que un juego de editores. Quizás un proyecto demasiado personal.

Y por el camino me dejo muchas más: Visionaire, Adventure Maker, 3D Adventure Studio, … la lista es interminable.

Lo que parece una constante en los que merecen la pena es el soporte de algún tipo de lenguaje propio para la elaboración de scripts. Aunque curiosamente un verdadero producto «point&click» debería poder prescindir de ese tipo de aditamentos. Este tipo de «features» debería verse siempre como un valor añadido, orientado sólo hacia los desarrolladores avanzados que quieran poder hacer algo más que lo básico. Contemplar todos los posibles escenarios que puedan plantearse por adelantado es imposible.

De todas formas, como ya he dicho alguna que otra vez, el mayor problema de este tipo de programas para mi sigue siendo la elaboración del «contenido»: elaborar un guión que resulte interesante, crear unos personajes que estén coherentemente definidos, diseñar unos puzzles que resulten lógicos a la par que retadores, construir un universo visualmente atractivo, y además conseguir ponerlo todo junto para que se perciba como una única entidad: un juego.