En pocos días se celebrará el fibest en valladolid y para no romper las tradiciones he enviado el currículum. Como el año pasado ha tenido ya algún fruto, una empresa se ha interesado ya en mi currículum!… eso sí, no solo en el mío también en el de otras 50 personas. El señor que lo ha enviado empieza bien:
“””
Buenas tardes;
Con motivo de la séptima edición del “Foro de Empleo FIBEST 2006 Castilla y León”, hemos recibido tu Currículum Vitae por medio de la organización del evento, y una vez revisado, tu perfil nos ha suscitado interés por lo que nos gustaría que asistieras a la charla que tendrá lugar el miércoles 29, a las 16.00 horas, en la ETS de Ingeniería Industrial para conocernos más de cerca.
Muchas gracias por tu atención y esperamos vernos pronto
“””
Al leer esto te alegra el día, alguien se ha interesado en mi currículum, sin embargo al leer el campo To veo a un montón más de gente, qué poca delicadeza, podría haberlo puesto en el campo de copia oculta, así el mail hubiera tenido un efecto más atractivo para mi.
Se me viene a la cabeza el caso de los perros. Los perros son animales que realmente no valen para nada, me explico, raro es el caso en el que el perro se gana su pan (tal vez en el caso de los pastores), como por ejemplo lo hacen los caballos, los burros y otros animales. Ellos se ganan el pan sólamente con cariño, parece increíble, pero es así. Cuando llegas a casa te sale a saludar contento, se acerca a ti para que lo acaricies, en resumen, solo se limita a mostrar su cariño hacia ti, eso sí, de una forma muy efusiva. El hecho de leer ese mail hubiera tenido el mismo efecto, efecto perro, para mi y hubiera ido con ilusión y ganas, sin embargo el detalle de ver como un mail “personalizado” realmente no es así, me hace pensar si iré o no iré. El no ir puede suponer a la empresa no tener en sus filas a un empleado como yo :).
Como nota, el año pasado me llamaron de deloitte e hicieron una prueba de selección que nunca olvidaré :)
En mi PFC he usado OpenGLES para el render de los elementos en pantalla. Para el que no lo sepa, OpenGLES es una especificación de OpenGL para dispositivos embebidos (su propio nombre lo indica, OpenGL for Embedded Systems) y que permite hacer muchas de las cosas que hasta hace poco estabamos haciendo en PC, un poco antes de que llegaran los shaders, esto es, renderizando polígonos con texturas e iluminación :). Precisamente hace poco se ha anunciado OpenglES 2.0, un poco pronto a mi modo de ver, sobretodo porque apenas hay dispositivos que soporten OpenGLES1.1 por hardware.
Como decía, he usado OpenglES por varias razones: la primera de ellas ha sido por simplicidad, no me apetecía empezar a programarme un render por software para pocketpc y ninguno de los que vi me agradaron lo suficiente. La segunda y definitiva fue su rapidez, un buen amigo de mi época de IRC me comentó que él lo había usado para un concurso, el que por cierto ganó en la categoría de juegos.
Recientemente ATI ha sacao un chipset denominado Imageon (ver foto de juego corriendo sobre el)que soporta aceleración por hardware y, la verdad, me ha sorprendido mucho ver la cantidad de móviles que lo incorporan frente al número de PDA, apenas 5. En uno de los blogs que leo a través de planetacodigo, leo que el blogger en cuestión se va a comprar una PDA y que ha elegido una DELL axim 51v. Mirando las caracterísiticas y el precio, y comparándolas con los precios actuales, resulta que es un pedazo de cañon que, lógicamente, tiene aceleración por HW de gráficos 3D.
Predecir el futuro no es lo mío, pero viendo cómo está el percal de las últimas portátiles, con un 3D avanzado, es posible que de aquí a poco tiempo empecemos a ver juegos 3D en móviles o PDA’s y OpenGLES es una de las pocas opciones, y a mi modo de ver, una de las mejores. Lo interesante del tema es que apenas se modifica la forma en la que se programa para PC, lo poco que varía es que no hay glBegin/glEnd, solo vertex arrays, lo cual no es un problema, hay que usar fixed point debido a que los ppc no soportan punto flotante por hardware (aunque sí que lo emulan), con la peculiaridad de que tenemos nuevas funciones conocidas con parámetros de entrada en punto fijo, por ejemplo glScalex en vez de glScalef (aunque esta también se puede usar), y que algunas funciones desaparacen, por ejemplo glLineWidth, lo cual tampoco es gran problema.
Como referencia, se pueden seguir los tutoriales de Jacobo (descarga directa 6 megas), los tutoriales de grant games (online) y como no, la referencia en su web oficial. Un par de detalles para terminar, en los dos tutoriales te indican lo que tienes que hacer para poderlo compilar y si no tienes un dispositivo a mano hay versión de OpenglES para el emulador que viene con el entorno de desarrollo, del que puedes ver un screenshot en mi página de flickr.
Ahora mismo estoy documentando el diseño de clases que he usado para la aplicación y necesitaba generar los diagramas UML para ir explicando el tema. Es cierto que lo lógico hubiera sido partir de los diagramas UML y después generar el código, pero mi nivel personal no ha llegado aún al de empezar por el diseño en papel y seguir por el editor de código. Habitualmente siempre hago un pequeño diagrama de bloques donde más o menos indico qué y cómo, pero nunca hasta el nivel de detalle que exigiría UML.
Gracias a doxygen es posible generar diagramas la mar de chulos de la aplicación… bueno, debería decir gracias a doxygen y a graphviz. Basta con indicarle el path de graphviz a doxygen en el fichero de configuración y genera unos gráficos bastante interesantes. De por si la herramienta tiene cosas que habrá que ver si se le puede sacar más partido porque promete. Como ejemplo de grafo que genera pongo el que ha generado de la parte de la aplicación que renderiza en el PFC.

Por cierto, doxygen ya soporta python!
En estos días de agobio mental, solo se me ocurren más que gilipolleces. Últimamente recuerdo una conversación de un amigo con una tía:
Estando en una discoteca, se acerca a una tía:
Él: oye, ¿bailas?
Ella: No.
Él: pues entonces de follar ni hablamos
XDDDDDDDDDDDDDD
PD: he estado una tarde entera intentando ordenar una lista con std::list::sort y no ha sido posible gracias a que el _puto_ evc++4.0 no es capaz de entender una especialización de un template. He tenido que modificar std::list para que me permitiera hacerlo y eso quema.