Python y miniframeworks web

He empezado a colaborar con web.ontuts, una blog sobre tutoriales de programación web, con un pequeño artículo sobre juno, un pequeño framework web hecho en python muy útil para pequeños servicios.

Aquí está:
mini-aplicaciones web con python y juno

Lo que debería haber en todas las empresas de software de España

En todas y cada una de las empresas de software de España debería haber un cartel, bien grande, donde todos pudiesen leerlo, con la siguiente frase

“El verdadero progreso es el que pone la tecnología al alcance de todos”

De un tal henry ford.

vía voolive visto en microsiervos.

integración continua en 100 líneas de código

Actualmente estoy trabajando con un embebido con linux, la potencia de la placa es bastante limitada y a la hora de compilar una aplicación mediana el sistema demasiado. Como tengo varias placas decidí montar un servidor de integración continua en uno de ellos usando compilación distribuída con distcc. La forma de trabajar es la siguiente:

- programo haciendo mis commits en local (usando git)
- cuando necesito probar mi código en el embebido hago “git push ci” de forma que ci es un remote parecido a ssh://user@ciserver/home/ci/project.
- Este repositorio tiene un post-recieve-hook que lanza una petición al servidor de integración continua, este compila (distribuido, con distcc) y si la compilación va bien lanza un “build_pass” que usando rsync hace deploy en la máquina de pruebas.

Parece muy complicado, pero realmente es poca la configuración que se necesita, casi todo va sobre ssh.

Sentía la necesidad imperiosa de tener un servidor de integración continua pequeño y manejable, así que decidí hacer uno :).

Con juno, un miniframework web que permite en dos patadas tener una pequeña aplicación web.

Si quereis probarlo o ver el código, el código está en github: cipy, servidor de integración continua.

Funciona bien, realmente no hace demasiado, pero basta. Solo soporte un proyecto, pero no hay problema para lanzar varias instancias, cada una en un puerto diferente, apuntando ngnix ( o tu servidor web favorito) con un “proxy pass” a cada una con un “location” diferente.

Si realmente quieres un servidor de integración continua potente puedes usar hudson.

Un shot:

"Making of" de cubyshot

Este año he presentado un pequeño juego a artfutura, en realidad hemos presentado, ya que wonder es el creador de la música. Se trata de un juego mata-mata, hecho exclusivamente con cubos, procedural y en <96kb.

Antes de nada el video y los links, después la miga.

cubyshot from javisantana on Vimeo.

codigo fuente: cubyshot en github
exe: cubyshot (ojo, si tienes antivirus es posible que te de un toque por la auto-descompresión del ejecutable). Puedes compilarlo con el visual c++ express.

El juego lo empecé allá por enero y en unas tardes saqué un pequeño prototipo (video). Partí del framework de 4kb de iq (muy bueno aunque no sea para una 4kb) y sobre él empecé a trabajar basándome sobretodo en los juegos de kenta cho, aunque luego lo deje hasta retomarlo hace un par de semanas más o menos.

El código es bastante simple (a pesar del sprint de los últimos dos días antes de art futura está bastante limpio), está en C, aunque está “orientado a objectos” conlos típicos punteros a funciones. Hay partes que me gustaría destacar:

- Todo está sobre el objeto actor_t, cualquier cosa que se mueva “implementa” ese interfaz, de forma que con un pool de objetos y unas pocas funciones tienes todo moviendose. La separación entre controlador y vista es, creo yo, bastante clara :).

- La mayoría de las animaciones son fijas, esto es, son una función matemática. normalmente basada en sin/cos. Por ejemplo el movimiento de los enemigos finales es:

a->pos[0] = 10.0f*perlin2d(a->time*0.001f, a->time*0.001f)*sinf(a->time*0.4f);
a->pos[1] = 14.0f + 3.0f*sinf(a->time*0.4f);

Esto da bastante libertad, porque siempre hay una fórmula matemática que más o menos se ajusta a lo que quieres. El mago de esto es iñigo quilez, te aconsejo que leas el making of de elevated.

- Para la mayoría de elementos en la pantalla no hay posiciones prefijadas, símplemente se situan en posiciones aleatorias, lo único que varía es el seed, dicho de otra forma, es el ADN de cada objeto.

- Casi ningún movimiento es directo, casi todos los movimientos de objectos están filtrado paso bajo, por ejemplo, el cambio del color del escenario.

- He usado fixed timestep, de esa forma simplifica mucho la lógica, no tienes que preocuparte del dt.

- Los efectos de sonido son sintetizados (puedes leer un tutorial que escribí hace años de como está hecho) y la música (XM) se reproduce con minifmod. La música se lleva el 80% del peso del exe :).

- Los enemigos finales están calculados proceduralmente con un efecto mirror. De hecho si arrancas el juego y no comienzas, cada 20 segundos más o menos se genera una nave nueva. Entre una nave y otra solo varía la semilla de números aleatorios. Para generarlas me he basado en invader fractal.

- Curiosidades. El código de la ciudad procedural (video) está en el código pero no me ha dado tiempo a usarlo… y parte de las ñapas de inicialización de direct sound están tomadas del código fuente del quake1 :)

Partes de las que no estoy contento son la generación de los enemigos, apenas hay variabilidad, la dificultad, el poco uso que le di a la paleta (fundamental en juegos con gráficos de coder), no haber preparado un objeto timer, etc, etc.

Todo se andará.

El software y sus productos

Hace dos días hablaba con el director comercial de una empresa y me comentaba su opinión acerca de la rentabilidad de las empresas de software y sobre los técnicos.

Me dijo algunas cosas que me llegaron muy dentro:

- Las empresas de software no saben “hacer producto”. Y esto es una realidad como un templo, tan grande como que en todas las empresas que he estado ninguna ha ganado dinero vendiendo productos, salvo la primera, que no era de software :). Vendiendo servicios sí, pero productos nada. Él lo achacaba a la falta de visión que tiene el técnico del cliente y la cantidad de empresas de software que han nacido a la sobra de subvenciones, otro par de verdades como chalets con piscina y jardín.

- Es imposible medir el rendimiento de un programador. En su empresa nunca se había hecho software, sin embargo se habían tenido que poner manos a la obra para poder vender un servicio. Medir el rendimiento de un comercial es muy “simple”, si hay ventas y cuantas. De un programador, cómo se mide el rendimiento? cómo sabes si un programador es bueno o es malo? cómo mides su trabajo? Me cuesta a mi responder a eso, no quiero ni pensar a una persona no técnica. Y es que de un programador que se centre en resolver un problema a otro que se vaya por las ramas hay días y días de desarrollo.

Aclara bastante las ideas escuchar el análisis de una persona que ve el desarrollo de software desde lejos, a pesar de que sea un comercial :P. Por lo menos este no era de los de “sí a todo”, “MI equipo por 1000€ menos” o “con dos semanas MI equipo tiene más que suficiente”.