He decidido mudarme de Zaragoza a Santiago de Compostela. No he tenido mucho tiempo que dedicarle al blog en cauterized, pero me gustaría comentaros un par de cosas:
Lo dicho: hasta que tenga casa y conexión en Santiago mis entradas serán sobre todo esporádicas. Suerte i ánimos a todos!!
De modo imperdonable había abandonado mi portátil a su suerte durante los últimos meses. He de admitir, avergonzado, que lo empleaba únicamente para leer algún documento. Pero hace unos días recordé que había salido una versión nueva de Debian, … y me tentó.
Volver a ver las pantallas de texto plano, navegadas por ncurses, la barra de resalte controlada por los cursores, grub, exim, less, vim, esos viejos conocidos que han vuelto. La instalación fue como la seda, ninguna pregunta cósmica ni duda existencial, los repositorios funcionaron de maravilla, los debs bajaron como un manso río.
Ver esa pantalla imposible de la carga del XServer, y el gdm, frío y eficaz, tan Unix.
Como el viajero que vuelve a su ciudad y se sorprende al ver que aún siendo la misma, ha cambiado. Nuevas caras, algunos conocidos algo más maduros, viejos compañeros que han sido abandonados en la orfandad de paquetes …
Podría seguir así toda la mañana, Debian no te deja tirado.
Escribo esta entrada desde el portátil, han vuelto las peleas con las fuentes del núcleo, los módulos de memoria y los mensajes de email a la cuenta redireccionada del root. ¿Quién podría decir que se podía echar esto de menos?
Cualquier lector de cómics normalillo en este país ha empezado leyendo mortadelos y filemones o cualquier cosa de la factoría Bruguera. No están mal, siguen la fórmula y son un tanto infantiles pero puedes leerte uno y no se te funde la sesera.
A partir de ahí cada lector se desarrolla individualmente: obra europea, asiática, americana, española, fanzines, web-comics, etc. Un montón de opciones donde elegir. He encontrado una tendencia a calificar el cómic americano como de producto patentado. Incluso aficionados al cómic francés y belga, grandes conocedores del género, consideran que todo el producto Yankee es uniforme. Y eso ya me huele más a la típica actitud los EEUU apestan y derivados de esta.
En los States existe el ciudadano medio, tal y como ocurre en el resto del planeta. Sin embargo también tienen una fuerte sociedad civil y autores inimitables, es decir, la cultura de los EEUU dista mucho del BicMac, el béisbol y el burrito de frijoles (al igual que la cultura española es algo más que la sangría, los toros y la paella). Hay un genuíno catálogo de autores que merecen la pena.
Recomiendo un link acerca de the Watchmen, que creo que es el cómic (americano) que más me ha gustado nunca. Es de hecho una obra tan importante que la propia wikipedia watchmen en la wikipedia le dedica un enlace. Por cierto, no aceptaré comentarios acerca de si Alan Moore es o no es americano, tened en cuenta que la editorial sigue siendo DC comics.
Evidentemente el cómic americano no murió en los 80, Frank Miller ha desarrollado una obra fantástica hasta la actualidad (nos falta ver la película tranquilamente). Petter Bagge, Robert Crumb y toda la panda han producido un buen montón de cómic que es un delito perderse.
En conclusión: cuidado con tomar la parte por el todo, Norteamérica produce algo más que best-sellers y morralla para adolescentes. ¡Ánimo buscando!
Muy pocos desarrollos parten de cero; lo normal es usar componentes de partida, bibliotecas, includes ajenos, linkar, etc. Si tienes la suerte de no contar con más de un candidato para hacer una determinada tarea ahí acaban tus problemas. En muchos casos el diseño del resto del soft se verá condicionado para girar alrededor de este componente único.
Pero, ¿qué pasa cuando tienes varias opciones? Tienes que elegir. Te da más libertad y más opciones, aparentemente todo genial. Pero luego, vas al barro, estás desarrollando y …
Síntomas: (escoger unos cuantos de la siguiente lista)
Causas:
No se ha comprendido para qué vale el componente específico. Estás usando un martillo para abrir una lata de sardinas.
Puede sonar jodido pero no es la primera vez que nos ha pasado. Aquí algunas soluciones preventivas:
Es fascinante cómo funcionan las entrevistas de trabajo y la selección de los currículums; últimamente he visto bastantes selecciones de personal (ya sabeis que los becarios son invisibles, como las sirvientas) y he oído hablar a algunos ejecutivos mientras hacían “la siega”.
En ningún caso miraron la formación académica salvo para descartar candidatos. Puede que suene a verdad de perogrullo pero si están buscando técnicos ni se os ocurra decir que sois superiores. En ese momento se oyen argumentos fascinantes como: …este tío seguro que tiene aspiraciones y se nos va… sí amiguitos el empleado ideal para la pequeña empresa es el que no quiere ascender y parece que ha llegado a su techo laboral, ¿irónico en estos tiempos de movilidad obligatoria, sí?
Seguro que alguna vez has ido a una entrevista, ¿te han hecho la típica pregunta de “dónde te ves en unos años”? Bien, recuerdo una ocasión en la que la mayor parte de los candidatos dijeron: “dirigiendo un pequeño grupo de devels”. ¿Sabéis qué ocurrió después? ¡Adivinaste! A tomar por saco: más aspiraciones y ganas de mejorar indebidas.
Pero todo mejora: he visto seleccionar a candidatas porque no hay ni una tía en la oficina y esto parece un campo de nabos. También como se descartaban candidatos por tener unas pruebas técnicas muy buenas (aspiraciones, otra vez).
Y así un sinfín de pequeñas locuras de gestión. La gente de recursos humanos es tan extraña, retorcida, malévola y cruel como la pintan en Dilbert. Así que nada de tomarse todas estas cosas demasiado en serio o acabaremos todos locos.
Una palabra de ánimo para terminar: todos esos cursos aparte de la carrera que nos hemos ido haciendo sirven y mucho.
Este jueves pasado, tuvimos un problema interesante con una biblioteca, replicantBody. Es una biblioteca que te facilita la vida a la hora de hacer animaciones por deformación de mallas con huesos, o lo que es lo mismo, haciendo skeletal animation.
Leímos la documentación y entendimos que esta biblioteca nos permitiría tener un control de grano fino de las animaciones, cuándo entraban, cuándo salían, etc. Integramos el paquete en el conjunto del código y continuamos avanzando en otras áreas ya que no teníamos planeado desarrollar animaciones específicas hasta un par de meses después. Estabamos seguros de que ReplicantBody nos sacaría las castañas del fuego.
Como ya estais adivinando esto no era así. O mejor dicho, si era realmente así, la documentación no explicaba claramente cómo funcionaba la biblioteca y qué resultados podíamos esperar de ella. En estos momentos andamos algo más cerca del plazo de entrega y tenemos que leer el código de la biblioteca para atajar el problema. Evidentemente trabajando con soft libre este es un error de principiante que se resume en un par de frases:
Escribir documentación es más rápido que programar.
.. pero sobre todo en:
¡Usa la fuente Luke!
En descargo de los muchachos de ReplicantBody, que están haciendo un trabajo magnífico, tengo que decir que su código está sobradamente comentado y es rápido de leer. Así que lo que podría haber sido un desastre catastrófico lo enderezaremos rapidito.
Todo marchaba bien, la mañana era fresca y un tanto nublada aunque estábamos en junio. Como siempre el edificio gris y angular nos recibía con indiferencia. Y es que así es la vida del becario: no puedes esperar ni gloria ni reconocimiento.
Tenía una misión sencilla, incorporar a la solución dos proyectos, comprobar su configuración y subirlo todo al CVS del equipo, tomarme un café y seguir con un par de features menores… como decía, todo marchaba bien.
Al cabo de una hora de compilaciones me doy cuenta de que la segunda biblioteca ReplicantBody exige la última versión del motor de render: OpenSceneGraph , miro preocupado el reloj, sé que OSG es un proyecto muy grande. Bajo el fuente y lanzo la compilación, pasa una hora y media y el motor de render se ha compilado: ¡bien! Recompilo el Replicant Body, ok muchos de los errores se han despejado. Sin embargo fallan los enganches con la DLL de Cal3d estoy pelín sorprendido porque aparentemente, tras toda la verborrea de STL el problema está con una:
std::string& foobar (int i) ;
Empiezo a temblar, esto huele a bibliotecas de templates, sigo investigando y recompilo el Cal3D, luego el RB ahora estoy seguro de haber hecho todas las compilaciones contra la misma versión de STL, … ¿ o no? … me levanto de la silla un rato … vuelvo …
Finalmente he comprobado algo interesante: todas las compilaciones han ocurrido contra una sección del disco donde no estaban las STLPort, así que el compilador ha optado por usar las STL por defecto de .Net, en mi caso eso significa dolor. La moraleja parece clara: nada de jugar con los directorios de bibliotecas o si lo haces, asegúrate de que el comportamiento por defecto del compilador te conviene. … 
PD: Espero que esto no acabe con mi mente… lamento esta entrada estúpida no me lo tengáis en cuenta ….
Tras la lectura del análisis de StarWars, la página de K. Brennan merecía una lectura más en profundidad. Tiene otra sección dedicada a la narración a la que pienso hacerle dos notas en esta categoría:
Lecciones de narración, bajo este nombre, Brennan agrupa la síntesis de su trabajo. Este texto, a diferencia del dedicado a StarWars es muy conciso. Resume la técnica en 18 leyes básicas que se deberían seguir para contar cualquier historia. En esta primera nota me gustaría destacar 2 de ellas:
Voy a poner un ejemplo que me ha llamado la atención: estoy pensando en la película “The ring” o bien ringu seguro que has visto una de las dos versiones. Porque hay dos versiones.
Sin pretender dármelas de intelectual de tercera yo ví primero la versión nipona (porque a mi chica le encantan las pelis de miedo japonesas, … a mi me dan miedo 
) Y me gustó, llevamos mucho tiempo viendo anime, leyendo manga y somos aficionados al cine de Takeshi Kitano. Es decir el entorno y el comportamiento de los personajes nos resultaba más o menos comprensible.
Piensa ahora en la segunda versión, es la misma historia es más que un remake es, literalmente una copia, un plagio, un pegote, un tru como un pú. Las pocas diferencias que hay: protagonista rubia, gente con ojos redondeados y entorno americano suburbial. Sin embargo la historia funcionó muy bien. Quiero creer que en parte el éxito se debió a la adaptación del entorno, haciendo que la parte del escenario fuese familiar para el espectador, y manteniendo el misterio maligno como algo externo, alienígena, desconocido.
De esta ley 7 no puedo poner grandes y verborreicos ejemplos. Me gustaría pensar que se explica por sí misma. Sólo en las biografías tenemos auténtico interés por la vida de los narradores (o narrados) El resto de las obras debe respetar absolutamente al lector.
Esta semana estoy preparando el siguiente requerimiento importante de mi proyecto: capacidad para generar entornos virtuales. Se trata de una idea absolutamente vaga, de la que se pueden sacar algunos requisitos base:
Muchos de estos requisitos plantean la necesidad de tener un control de colisiones en el código, lo que signfica … nuevas librerías … cómo me pone esa frase! Y es que Maxine, en este momento tiene 16 bibliotecas incorporadas desde la fuente 
Algunas de las bibliotecas posibles de control de colisiones son: Control de colisiones y física Existen bastantes bibliotecas especializadas en la gestión de colisiones con volúmenes primitivos, así que no sé si de entrada vamos a poder usar cualquiera de ellas.
Mi contacto inicial con este problema ha partido de un proyecto de animación por steering: openSteer del que ya he extraído el motor de simulación física. La versión del CVS tiene un excelente soporte para la gestión de obstáculos, pero tiene un inconveniente, abordan el problema como si de un escenario estático se tratase.
Iré anotando en esta bitácora las ideas que tenga, quizá pueda debatirlas luego con algún experto en el tema.
¿Alguna vez os habéis preguntado cómo se generan los paisajes artificiales por ordenador, ó bien quereis hacer uno propio? Esta biblioteca es un fantástico punto de arranque. Aporta el fondo matemático suficiente y un par de clases de utilidad. Todo bien empaquetado y listo para compilarlo. Como extra, puedes convertir los datos que generes de mapas de color a renders del Terragen.
Para una parte de mi proyecto actual, necesitábamos un generador de ruido de Perlin, tras buscar un poco encontramos libnoise. Este paquete GPL tiene una fantástica documentación llena de ejemplos que os recomiendo, tanto para aprender a usar la propia biblioteca como para averiguar qué demonios es el ruido coherente.
Si te gusta el diseño software atención al modo en el que se encadenan los distintos módulos de generación de valores, muy similar a un pipe y con un final realmente ingenioso.
Échale un ojo a la libería en su web:libnoise.