"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".

Las aplicaciones web de los bancos

Me pregunto que clase de engendros programarán las aplicaciones web que ofrecen los bancos a sus clientes. Es realmente difícil hacerlo tan mal, en todos y cada uno de los aspectos, tanto el técnico como de usabilidad, diseño... funcionan realmente mal sea cual sea el navegador, funciones sin sentido, confusión absoluta para hacer una mísera transferencia... os animo a que entreis en la web de vuestro banco preferido y useis un poco firebug. Algo me dice que están programadas por grandes consultoras con grandes comerciales con grandes amigos y muchos expertos en tecnología.

Pero la cosa no queda ahí, lo peor es que no te dan un acceso a los datos de forma simple. Esto es, no puedes de forma simple tener los datos de, por ejemplo, los movimientos realizados. Tan difícil es tener un api web simple que los retorne?

Con la cantidad de pasta que todos los ciudadanos hemos regalado a los bancos bien podría el gobierno haberles obligado a hacer las cosas bien, porque digo yo, si para hacer negocio se necesita mover dinero y no tenemos una forma automática y homogenea de tener esos datos disponibles, como quieren que las empresas españolas automaticen, informaticen o se "adapten a la nueva realidad de las TIC", como dicen los ignorantes tecnológicos que hablan por nosotros las sandeces que sabe dios que asesor de su partido les ha comentado que queda bien porque se lo ha oído a vaya usted a saber que gurú.

railsrumble y la comunidad rails

Este fin de semana ha sido la railsrumble, un concurso donde hay que crear una aplicación web en 48 horas usando el framework web Ruby on rails.

No deja de ser una compo más, pero llama la atención la calidad, tanto en los diseños, como en la funcionalidad. 48 horas es muy poco tiempo para cualquier cosa, lo justo para centrarse en algo y hacer una cosa sencilla.

A pesar de eso lo que más valoro no es la calidad técnica de los trabajos, si no la calidad de la comunidad alrededor de rails. Solo hay que ver algunos detalles, por ejemplo la costumbre de compartir del código (no hay más que ver la cantidad de plugins para rails que hay en github), estar siempre tratando de mejorar, organizan conferencias de muchísima calidad (en españa tenemos conferencia rails, recomiendo ver las charlas) y un largo etcétera... incluso solo con ver el diseño de algunas web podrías decir si está el backend está hecho por gente de la comunidad RoR.

Decir que hay varias entradas españolas recogidas por @happywebcoder, varias de ellas están en la final:
- http://letsdecide.us/ código
- http://diversion.r09.railsrumble.com/ un especie de wiki al estilo github.
- http://triphq.net
- parlio. Reseña especial, porque además de haber hecho la aplicación en 48h, han intentado que tenga un uso final apuntando bien algo: acercar lo que hacen a los que votas a la gente de a pie. Me una pregunta: cómo se les tiene que haber quedado la cara a la gente que hace la web del parlamento vasco . El código en el github de probono (la asociación a la que han donado el código).

folding en vim

Hasta ahora no había usado el folding de vim porque me parecía un verdadero peñazo el crear los folds para el código en C/C++, sin embargo existe un modo de hacerlo tan simple que no puedo dejar de usarlo:

:set foldmethod=syntax

de esta forma se colapsa todo. Para abrir y cerrar tan fácil como:

- zO con 'O' de "open". Es mayúscula para que se abran los folds internos, si usas zo se abre el fold de primer nivel.
- zc con 'c' de close.

Hay miles de tutoriales de folding, pero creo que he puesto la forma más simple que se puede.

progit, libro de git libre

Hay dos o tres blogs que leo habitualmente de los cuales no me interesa para nada la tecnología, pero que están escritos por gente tan buena que merece la pena leerlos. Unos de ellos es el blog de github, y esta mañana me encuentro con que han liberado un libro sobre git.

El libro merece la pena para aprender git, aunque me da la impresión que es una amalgama de la estupenda guía git magic y el libro de la web oficial de git.

Dejando a un lado la parafernalia de la libertad, creative commons y otras hierbas, lo que hace el libro redondo es el último capítulo, git internals, donde explica, bien clarito, con 2 comandos básicos, como funcioan git por dentro. Asombra lo realmente simple que es.

Como me gusta saber como funcionan las cosas, he mirado el código fuente de git, pero no el actual, si no el primero publicado, git-0.01, donde se puede apreciar claramente todas las cosas que explica en el capítulo. Una pena que el capítulo no haga referencia a ese código.

Y ya que estaba metido en harina he buscado el primer código liberado de mercurial, mercurial-0.1, para ver si el sistema usado es el mismo. Me han llamado la atención dos cosas, la primera de ellas es que si ejecutas hg, el script principal, sin parámetros la aplicación te lanza la típica excepción... no comprueba los parámetros, la segunda es el propio "announce.txt". El código dista de ser ordenado y documentado, pero 4 años después ahí lo tienes..

Otra curiosidad, la primera release de git fue el 7 de abril, la primera de mercurial el 27 de mayo del mismo año (2005), 39kb de C frente a 6.2kb de python :).

¿Sabe tu madre lo que haces en tu trabajo?

Seguro que os habeis encontrado en la situación: una persona sin conocimientos técnicos, o muy básicos, os hace una pregunta, pongamos "qué significa el número ese, 8080, que hay detrás de esta dirección de esta web". Puedes ponerte a explicarle la pila de protocolos desde la capa física hasta http, tú lo sabes, sabes porque los desarrolladores usan a veces otros puertos, te sabes la teoría, cuando ves eso rápidamente viene a tu cabeza cosas como iptables, proxy_pass, accept, netcat, tomcat...

O la pregunta que nunca sabré responder: "hijo, qué haces en tu trabajo?", esa pregunta bien intencionada de las madres, donde ves que están poniendo todo el interés, lo hacen porque te quieren y no las puedes fallar. Pero lo siento amigo, vas a fallar, o dicho de otra forma, en tu cabeza sonará un EPIC FAIL! (y a continuación lo twitearás y 4 ó 5 ciber-amigotes se descojonarán)

Y ahora vamos a algo más serio, porque que tu madre sepa o no que eres un fan de java es poco relevante, pero que trates de explicarle algo a alguien, incluso si es técnico, y no te entienda me parece cuanto menos grave. Yo lo reconozco, me explico mal, hablo demasiado rápido y encima meto términos muy técnicos que la persona que escucha no tiene porque saber. Lo peor es que me doy cuenta y que la mayoría de personas que he tenido a mi alrededor con mi perfil padecían del mismo problema.

De quién es el problema, de nuestros compañeros de trabajo que no se esfuerzan o nuestra por no saber esquivar los terminos técnicos o condensar la información de forma clara? Siempre he pensado que el peso de la primera era mayor, pero a medida que pasa el tiempo y veo diferentes perspectivas, sobretodo de personas técnicas de lo que podríamos decir avanzada edad, me doy cuenta que es posible que al final simplificar es lo mejor para explicarle las cosas a tu compañero y lo mejor, para ti mismo.

Agroguia AR gana los premios 3M

Hace ya más de un año se me ocurrió, un sábado de mañana, que porque no mezclar un GPS con una webcam para mostrar información al agricultor sobre la imagen real en vez de solo representar en 2D los datos del GPS como venía haciendo en nuestro sistema de guiado agrícola.

De esa mañana surgió un prototipo hecho con python. Se lo enseñé a Jaime Gómez, mi tutor de proyecto y le gustó, entonces planteó la posibilidad de hacerlo un poco más en condiciones, así que hace 3 meses decidimos usar una webcam mejor, un GPS más rápido y grabar unos videos en un tractor tratando de verdad una tierra.

Así, junto a Pablo, un chaval al que llevo el proyecto fin de carrera a medias con Jaime, preparamos la documentación, grabamos el video y lo enviamos a los premios 3M. Ayer la organización nos dijo que lo hemos ganado en la categoría de industria. :)

Me llamaron de RNE para hacerme una entrevista (que no sé cuando emitirán, se me olvidó preguntar) y hay una reseña en el norte de castilla.

Son 6000€ (a pachas con hacienda, como no), pero lo más importante para mi es ver como una idea de una mañana puede llamar la atención y convertirse en algo real con "poco trabajo".

Dejo una imagen de la aplicación:

y mañana ya es viernes

No hay otra cosa en lo que los españoles no seamos más optimistas que en los hitos del fin de semana. Siempre están ahí, siempre hay una excusa para ser positivo, todos aportan para llegar bien al maldito viernes a las 15:00 (en el mejor de los casos).

Y es que ODIO, pero mucho, cuando un compañero de trabajo dice: "bueno, mañana ya es viernes", o "miercoles, en dos días fin de semana" o para remate "ya se termina el lunes en 3 días y un poco viernes", pero vamos más allá, marcamos milestones más cercanos, dentro del día: "en dos horas nos vamos", "ya solo quedan 30 minutos", "me tomo un café, leo el periódico y ya son las 11". Me pregunto que pasaría si la gente se marcara milestones tan cercanos y tan claros en su trabajo, quizás scrum naciera así :).

Entonces me pregunto yo, si para tí un 80% de la semana es sufrimiento, por qué cojones no dejas el trabajo y te buscas algo que te llene más? He tenido la suerte de estar en empresas en la gente tenía interés por su trabajo pero más suerte es haber estado en las que no lo tenían, porque así uno valora aún más hacer lo que le gusta y poder decir, por mucho que te pongan de gilipollas para arriba, "me gusta mi trabajo, cada día".

Está claro que el tiempo libre es lo mejor, pero igual que cuesta coger el coche para irte a la ciudad de al lado a cenar en tu tiempo libre, también cuesta esfuerzo tratar que cada día sea interesante en tu trabajo.

Por favor, si lees esto, acuerdate antes de decir delante de un compañero, pero sobretodo, de ti mismo "ya falta menos para el viernes" que quizás ese no sea el camino y que posiblemente estés creando un "mal ambiente" que al final irá contra ti.

Tecnología vs personas

A menudo me doy cuenta que algo es claramente mejor que otra cosa (tecnológicamente hablando), puede que en ciertos casos haya duda, pero hay casos en los que no hay lugar a duda, todos los argumentos se decantan a favor de cierta tecnología, pongo un ejemplo.

Imaginemos que tenemos código que vamos a mantener y tenemos que tomar una decisión: mantenerlo en carpetas y parches o tener un sistema como subversion/git/mercurial/etc. No hay duda (aunque linus tolvalds prefiere tener tar.gz antes que subversion), es obvio que tener un sistema de control de versiones es, de largo, una mejor solución.

Sin embargo qué pasa si el código está en una empresa con 50 programadores que nunca lo han usado y están acostumbrados a su sistema de tar.gz? La inercia de la gente es muy posible que pueda a todos los argumentos a favor de una tecnología mejor.

En The pargmatic programmer (capítulo 3, punto 17) ponen este caso como ejemplo y dicen (versión libre) "si estás en un lugar donde no usan control de versiones, no trates de hacer que los demás empiecen a usarlo, comienza usándolo y que los demás vean las bondades del sistema".

Igual que con el control de versiones hay miles de casos, lenguajes de programación, librerías, sistemas de gestión, correo electrónico... no basta con saber de tecnología hay que saber presentarla bien.

webs de alquileres

Esta semana he estado buscando vivienda en Pamplona y creo que no ha podido ser más traumático. Mi primer epic fail fue pensar que con internet lo tenía todo hecho, así que buscamos solo cosas por internet y después de una semana puedo asegurar que a las webs de alquiler les queda muchísimo por andar.

Aposté por los sitios web porque pensé que me podían dar mucha información (fotos, videos), comentarios de propietarios e inquilinos, situación exacta de la vivienda, casas parecidas, comparativas de precios por sector, etc, etc, pero cual ha sido mi sorpresa y todo han sido fallos, errores y problemas, enumero:
- primera cagada: las webs de alquileres están copadas por inmobiliarias. A ver, se supone que se trata de evitar un intermediario y lo que hacen es dejar meter por medio a sus competidores.
- Dejar poner viviendas con poca información, sin fotos, etc.
- No permitir interacción entre usuario/propietario de forma directa. Algunas tienen sitios de contacto, pero no es nada directo, mucho más lógico un pequeño hilo donde la gente les pregunte.
- No dar información de cuando se dio de alta el anuncio, última actulización, evolución de precio y comparativa con otros de su sector.
- No tener un sistema de puntos para valorar al inquilino y al propietario, de esta forma sería posible sabrer si el propietario es un payaso o el inquilino un jeta. Este punto es bastante delicado, pero si funciona en ebay...

La que más se acerca es idealista pero tiene, en comparación con otros sitios, menos viviendas. Me encanta la herramienta que tienen en sus "labs" para poder ver sobre el mapa los inmuebles. Se nota que los creadores de idealista son "familiares" de 11870.

En resumen, si una inmobiliaria cobra la mitad de una mensualidad por encontrarte casa, creo que si al usuario se le pone un precio lógico para usar la aplicación web. Por cierto, he dicho que estoy hasta las narices de servicios gratuítos? prefiero pagar y tener un buen servicio a tener un servicio mediocre.

cambio de trabajo

Me cambio de nuevo de empresa, mañana será mi último día en algor, la subcontrata de telefónica I+D donde he estado trabajando. 6 meses (y 1 día) es el tiempo que he estado aquí, realmente poco (aunque solo un pelo por debajo de mi media en una empresa).

Las razones de mi marcha son fundamentalmente 2:
- Yo no estoy hecho para estas empresas donde la productividad no es importante, donde no se aprecia al empleado y se trabaja con personas como carneros. Hay gente que le gusta esto, que aguanta o que no tiene otra salida, no es mi caso.
- Telefónica I+D, además de querer que me cambiase de empresa de forma unilateral, no creo que tuviese en mente mantenerme demasiado tiempo más en su plantilla de "personal ajeno". La cosa está muy negra, la forma de trabajar de estas empresas propicia que cuando se necesita aportar valor todo se desplome y telefónica I+D es la reina del lugar.

En general no me he adaptado bien a la forma de trabajar, no comprendo muchas de las cosas que se hacen, ni la gente me entiende a mi, tampoco comprendo como la subcontratación y dispersión de los integrantes de un proyecto es algo común.

Bueno, sea como fuere, yo me marcho de aquí con un regustillo agridulce. Por una parte ya conozco como funcionan estas empresas, he conocido a gente muy agradable, pero me doy cuenta que el futuro de parque tecnológico de boecillo no es muy largo tal como está ahora, ha llegado el momento de las empresas que aportan valor y son competitivas, y esas no están en boecillo (*).

Mi siguiente destino es Pamplona, me voy a una empresa que vende lo que hace, que gana dinero con ello y que compite. Espero aprender mucho y poder aportar lo que no he podido aportar aquí (seguramente la única espina que me queda clavada). Por lo menos me voy con el consuelo que ahora @lalangosta sabe que es trac, @Chiralilla conoce mercurial y @djgago sabe que los buenos sitios webs se hacen con python :)


(*) Seguramente habrá empresas que funcionen bien en boecillo, disculpas por adelantado, no he llegado a conocer ninguna.

Nuevo microblog: retales de código

Me fascina ver como hay gente que es capaz de sacar el máximo partido a unas cuantas líneas de código. Por eso he creado un microblog alojado en tumblr que me parece un servicio la mar de adecuando para estas cosas sobre pequeños trozos de código que hacen grandes cosas. Además los creadores tienen pinta de ser gente guay (usan mac, monitores gordotes, oficinas supermolonguis) :p. Por cierto, que interesante es ver como son las oficinas y como trabajan otros desarrolladores, pero eso es para otro post.

Otros microblogs que sigo, relativos a programación son, lines of code de LinkingPaths y commandliners mantenido, entre otros, por @rafacas.

Bueno, aquí os lo dejo: small pieces of code

Manual práctico para coger rotondas

Creo firmemente que la gente no sabe usar las rotondas adecuadamente y para ello voy a dar una serie de consejos, que nadie leerá, pero que quizás alguien encuentre en google y evite algún que otro accidente.

Primera y única norma: Una rotonda es exactamente lo mismo que una carretera, pero en curva

Esto es:
- Si estás en el carril interior y quieres coger una salida tienes primero que pasar al exterior y luego salir. Imaginemos que vamos por una autovía en el carril izquierdo, a nadie se le ocurriría salir desde ahí a la salida de golpe y obviamente el que circula por la derecha no se tiene ni que salir obligatoriamente, ni cederte el paso.
- Nadie te obliga a circular por ningún carril en concreto, sea cual sea la salida que vas a tomar
- Para permanecer en la rotonda no hay que dar ningún intermitente siempre que no hagas cambios de carril, de la misma forma que si mantienes el carril en la autovía no tienes que dar el intermitente.
- Si vas por el carril interior, alguien entra en la rotonda al carril exterior y le das, la culpa es tuya de la misma forma que si vas por la autovía por el carril izquierdo y le endiñas al que está en el carril derecho porque haces un cambio inadecuado de carril.

Y ahora unas normas de civismo:
- Si puedes facilitar la incorporación o salida de alguien, hazlo
- Si estás por el carril interior, necesitas salir y no puedes... da una vuelta más y no prepares la pirula, van a ser 10 segundos más
- Es posible que si vas a salir por la tercera o incluso segunda salida puedas ocupar el carril interior para usar los carriles y maximizar el tráfico de la rotonda.

Y por último normas para gente que viva en Salamanca (o en pueblos en los que no sepan conducir):
- Usa SIEMPRE el carril de dentro, los paquetes nunca lo usan y depende casi exclusivamente de ti el que te des la ostia
- Si dan el intermitente a la izquierda, tranquilo, en el 99% de los casos no se trata de un cambio de carril, quieren indicar que permanecen en la rotonda.
- Si sales al carril exterior y viene un paquete por el interior, sin intermitente indicando que se cambia al exterior, NO SALGAS, porque el paquete te pitará porque él precisamente quería salir por la siguiente.
- Si ves a un seat león, coche con letras chinas, lunas tintadas (alias follo en el coche porque no tengo casa), llantas brillantes, coches de color naranja o amarillo, con prominentes alerones o con varios tubos de escape en una rotonda, no te acerques, porque seguramente no sea capaz de dar la rotonda y accionar el intermitente a la vez.
- Si usas el carril izquierdo para adelantar, te pitarán porque no entienden que si respetas los límites de velocidad estás en tu derecho de quitarte a un paquete de encima.

** Este post está dedicado especialmente a la gente de Salamanca

hg-wiki

Hace un tiempo he empezado a usar mercurial para mis proyectos personales. Mercurial es un sistema de control de versiones, al igual que subversion, pero distribuído, esto es, no necesitamos un servidor central donde subir nuestro código. Esto tiene muchas ventajas, no me voy a poner a enumerarlas, para ello podeis ir a la respectiva página en la wikipedia.

No hace mucho mercurial se ha empezado a usar en el desarrollo de python y google code ha dado soporte para este lenguaje, lo cual me dice que pronto empezaremos a ver más y más proyectos usándolo. Veremos si hay guerra git-mercurial (git es otro sistema de control de versiones usado en el desarrollo del kernel de linux, entre otros), viven en paz o alguno de ellos muere. Git ha tomado mucha fuerza, sobretodo por el empuje en el desarrollo web y gracias a webs como gihub, pero eso es tema para otro post.

Es muy habitual que junto al código de tu proyecto tengas otras cosas igualmente importantes como scripts de compilación, deploys, documentación, notas, etc, que normalmente están también bajo control de versiones. Además, se suele tener un sistema de tracking de proyectos acompañado (o integrado) un wiki -que siempre termina manga por hombro-.

Pensé que estaría bien tener un wiki integrado en el repositorio, al igual que con el comando hgserve tienes un servidor web integrado que te permite ver la información de forma mucho más gráfica del repositorio, por qué no un wiki?. Haciendo una búsqueda no he encontrado nada para mercurial, sí para git.

Como hace pocos días me encontré juno, un mini-framework web muy coqueto y me puse manos a la obra para probarlo, así que he creado hg-wiki, una herramienta que permite tener un wiki integrado en tu repositorio mercurial. Es un wiki muy simple, pero tiene lo justo para tener la información ordenada y vistosa.

El proyecto está alojado en bitbucket, un servicio de alojamiento de proyectos mercurial. Si quieres echarlo un ojo y probarlo: hg-wiki

Un ejemplo de como queda la cosa, primer el texto, después la imagen del resultado:

= hg-wiki =
== introducción ==
//hg-wiki// es una pequeña aplicación web que implementa un wiki especialmente creado para sistemas distribuídos. Todas las páginas son almacenadas usando mercurial, de forma que se puede aprovechar todas las ventajas que aporta este sistema:
* permite trabajar //offline//
* se pueden mezclar, tagear las páginas de la wiki

== instalación ==
La instalación es simple, primero hay que instalar las siguientes dependencias:
* [[http://www.mercurial.org/|mercurial]]
* [[http://www.python.org/|python]]
* setup-tools, necesario para poder usar easy_install, la herramienta que permite instalar librerías de forma simple, igual que apt-get.

Lo siguiente es instalar las dependencias python:
* [[http://github.com/breily/juno/|juno]], un pequeño framework web, merece la pena echarle un vistazo
* creoleparser, permite convertir de wiki a html
Para instalar cualquiera de estos basta con ejecutar

{{{
easy_install juno
}}}

== funcionamiento ==

Si quieres empezar rápido ejecuta
{{{
python hg-wiki.py mywiki
}}}

Esto creará una carpeta llamada mywiki que no será otra cosa que un repositorio mercurial, por tanto se podrán ejecutar sobre él todos los comandos mercurial.

== créditos ==

autor: javi santana http://javisantana.com

gracias a los creadores de creoleparser, juno y github, de donde he ripeado miserablemente el css :)

El resultado:

(si encontrais familiar el estilo de la web, no es casualidad, el css lo he tomado del wiki de github, mis conocimientos web no llegan a tanto)

La sostenibilidad y otras cosas

No, no voy a ponerme a escribir que tenemos que cuidar el medio ambiente y hacer que nuestro ciclo sea sostenible, eso ya lo sabemos gracias a los anuncios de vehículos, material informático, alimentos, etc. No digo que no sea importante, pero hoy voy a hablar a nivel empresarial.

El otro día me comentaba una persona, en la típica conversación de bar, donde todo es sencillo, que era un pelín tonto, que debería estar moviendo nuestro pequeño negocio por todos lados, creciendo todo lo que pudiese y vendiendo lo que no está escrito. Era una persona que se dedicaba a la venta, así que es lógico que me tratara de dar unos buenos consejos.

Sin embargo, en estos momentos en los que me recomiendan crecer y moverme pienso en uno de mis objetivos, la sostenibilidad. Sería fácil aprovechar el "boom" y tratar de vender, quizás contratar gente, tratar de buscar inversión privada y crecer como la espuma, pero no sería sostenible y habría que empezar a despedir personas, tal y como están haciendo todas las empresas que no lo pensaron durante las vacas gordas. Creo que lo explican muy muy bien la gente de LinkingPaths en esta entrevista. Merece escuchar la entrevista completa, la primera parte sobre su filosofía y la segunda un poco más técnica (java vs ruby sin mojarse :P, git y sus proyectos).

Por otro lado, también le comentaba, que a mi no me interesaba ahora meterme en fregaos que no me gustan, yo estoy feliz con mi software, desarrollando cosas que tienen utilidad y haciendo lo que me da la real gana en el tiempo que me sobra (o que robo). La fábula del pescador y el empresario lo explican muy bien. Mi felicidad en este momento es hacer lo que quiera dentro de unos límites y no quiero la felicidad para dentro de unos años. Creo que no soy el único: de consultor a director de TI, Ángel Medinilla (punto 2) son dos buenos ejemplos.

Ya que estamos puestos, me marcho a trabajar a Pamplona el mes que viene :)

Como plancha un programador

Una persona normal, que no es del gremio metalúrgico-programador, para el noble arte del planchado de la ropa no piensa más que en coger la plancha, la tabla de planchar, la ropa y liarse a planchar y doblar.

Hoy he dicho a mi novia que planchaba yo en un intento de que no parezca que ella lo hace todo y hacerme creer por un instante que yo también participo en las labores domésticas (lo más lejos de la realidad). No tengo demasiada experiencia, así que me he planteado el problema como tantos otros:

Primer paso, preparación de herramientas y documentación
- preparación de tabla, la he tenido que nivelar para que no se moviese, es importante tener las herramientas a punto.
- enchufar plancha y comprobar los diferentes controles (temperatura y demás). He delegado (para que luego digan que los programadores no delegamos) en mi novia la tarea de llenarla con agua.
- He mirado en internet como doblar una camiseta de forma rápida para ahorrar tiempo. He encontrado como doblar camisetas de forma rápida con el estilo japonés.

Segundo paso, organizar el trabajo
- He analizado primero los riegos y he escogido lo más bloqueantes por orden de importancia: quemar una prenda y cansarme de planchar. Es fundamental no quemar una prenda, pero también lo es que me canse y deje las cosas sin planchar.
- Ordenar por prioridad las prendas que voy a planchar: primero he puesto una camiseta blanca sin mucho valor, por si quemo algo que no se pierda mucho. Después he ordenado la ropa dos criterios: el de "importancia que esté planchado" y por "interés necesario para plancharlo (aka dificultad)", por tanto lo primero camisas, segundo polos, tercero pantalones y después camisetas blancas (a excepción de la prueba con la primera).
- Planchar, pero marcando una deadline de tiempo de forma que cada prenda quedara lo mejor posible dentro de ese tiempo.
- Tiempo de I+D: Ya que tengo varias camisetas iguales he intentado alinearlas y plancharlas a la vez. Fracaso total, pero de eso se trata el I+D ¿no?

Último paso, preparación para producción
- Doblado de ropa, las camisas directamente a perchas y luego he apilado la ropa poniendo encima lo que más me interesa que se mantenga sin arrugas.
- Armario, esperar que la plancha se enfrie y recoger instrumental.

Es triste, pero así es como he pensado cada uno de los pasos para planchar.

Opinión HTC Touch 3G

Hace un mes o así que tengo la HTC touch 3G. La compré con el objetivo de portar agroguía a HTC ya que he visto que muchas personas están interesadas en tener un sistema de guiado gps en su Smartphone.

El móvil es más pequeño de lo que pensaba, pero sigue siendo un buen tochardo para llevar en el bolso, lo cual es un punto muy negativo, casi bloqueante dependiendo de gustos. Por suerte es "fino" y se lleva dentro del pantalón fácil. Es lento como el solo, no llega al nivel de un Nokia N80, pero lo es. Es poco usable a la hora de hacer fotos y para la mayoría de las cosas, la pantalla es bastante pequeña para navegar y el navegador opera que trae es un verdadero truñazo, el GPS es malísimo... sin embargo tiene cosas que son una gozada.

Tiene una gestión de las llamadas buenísima, almacena TODAS las llamadas que has recibido, fechas, tiempos, contactos, puedes guardar notas sobre los contactos, sobre las llamadas, etc. Esto resulta especialmente útil cuando tienes muchos contactos, sobretodo de clientes. Ahora tengo un pequeño CRM dentro del móvil, donde anoto que he hablado con cada cliente, si les he prometido el oro y el moro, si he negociado un precio, si se ha quejado y lo más importante, sé cuando me ha llamado y le he llamado. Esto además se eleva a la n-esima si usas el teléfono como algo asíncrono, siempre tengo el teléfono en silencio y miro las llamadas cuando me apetece. Además la batería dura mucho si solo lo usas como teléfono y la conexión para usarlo como módem 3G es bastante rápida (te da como opción cuando conectas el USB).

En resumen, si estás pensando en comprartelo y estás interesado en tener los contactos bien ordenados, cómpralo, de otra forma tirarás tu dinero.

Filtro paso bajo con python

Es muy común tener un señal con mucho ruido, si es de un GPS más aún y normalmente interesa que los movimientos sean suaves. Bien sabido es que con un filtro paso bajo podemos atenuar el ruido y hacer que todo sea suave y maravilloso.

Si además no tenemos que filtrar al vuelo, esto es, tenemos ya toda la señal bien guardadita en un array, es posible usar el truco de teleco viejo, utilizar la fft. ¿Cómo? pues símplemente haciendo la transformada discreta de la señal, quitando los armónicos más altos y haciendo la transformada inversa.

Aquí el código, todo gracias a numpy :)

from numpy import fft

def low_pass_filter(x, samples = 20):
  """ fft based brute force low pass filter """
   a = fft.rfft(x)
   tot = len(a)
   for x in xrange(tot-samples):
   a[samples + x] = 0.0
   return fft.irfft(a)


El código seguro que es mejorable, numpy tiene métodos para trabajar con arrays de forma eficiente, etc, pero funciona a las mil maravillas y permite un control bastante lógico, cuantos más samples de la fft no sean 0, mayor será la variación de la señal. Para que luego digan que lo que se aprende en la carrera no sirve de nada...

flojo, flojo, flojo

No he podido resistirme, lo pensaba tuitear, pero prefiero casi ponerlo en el blog.

Estaba yo en la cafetería tomando café -aumetando mi productividad en resumen- y en la mesa de al lado hay dos hombres, bien encorbatados y una mujer bien vestida (el símil de hombre acorbatado en mujer) y uno de los hombres, el que parecía más espabilado, con mayor entidad, con más responsabilidad, con más dinero, con la voz más ronca dice:

"""
al chaval lo tuvimos que apantallar.... era muy flojo... flojo, flojo, flojo... era técnico, para que me entendais...
"""

Es posible que sea un caso puntual, o que quizás haya sacado la conversación de contexto, pero me ha hecho muchísima gracia el comentario, el caso que me he echado una carcajada.

Voy a recurrir al sabio refranero español: "cría cuervos y te sacarán los ojos"