En los últimos meses he leído dos libros sobre desarrollo de software, en mi opinión, imprescindibles. Los dos son “de perogrullo”, dicen cosas de sentido común, cosas que a medida que programas te has ido dando cuenta, pero que muchas veces no eres capaz de condensar y plasmar tan bien como lo hacen en sendos libros.
El primero de ellos es “The pragmatic programmer”. Si eres cristiano debes leer la biblia, si programas en C++ debes leer effective and more effetive C++ y si eres programador __tienes__ que leer este libro. No voy a resumir el libro, ya hay muchas opiniones en internet acerca de él. Te recomiendo que leas algún que otro capítulo y verás que dice verdades como puños, tantas que es imposible llevarlas todas a cabo :)
El segundo de ellos es “getting real”, de 37signals , creadores de ror y cuyo blog (con curiosa url por cierto) es muy recomdable. Se puede leer online y pasa algo parecido que con el anterior, verdades como puños. En resumen habla un poco de como desarrollar de forma eficiente, pragmatismo puro en proyectos de desarrollo de software, sobretodo orientados a web, aunque muy válidos para cualquier proyecto no web e incluso no software. Ciertamente hay que tener una perspectiva un poco diferente, a mi me recuerda al equipo-A en la forma de trabajar :). El libro en si mismo refleja el pragmatismo (meta-pragmatismo), capítulos bien separados, fácil de leer y con ejemplos reales.
Son libros para tener de cabecera, para releer de vez en cuando, para tomar notas sobre ellos y para ir aplicando poco a poco. A medida que adquiero más experiencia desarrollando me voy dando cuenta que esos pasos ya los dieron los escritores de esos libros, los plasmaron y resumieron.
Ahora voy a ver si me leo “practices of an agile developer” que me ha recomendado félix.
PD: Se acabaron mis vacaciones … :)
Estoy y me voy de vacaciones, este año toca a la zona sur de portugal, a ver si consigo descansar y desconectar (topicazo donde los haya).
Este año ha sido duro, he tenido mucho trabajo, quizás mucho más del que realmente he podido abordar. Con perspectiva realmente las cosas han salido bien y muchas veces he hecho que problemas con no lo eran tanto, sobretodo con agroguía (sistema de guiado con GPS). A toro pasado todos somos manolete, es muy fácil ver ahora los errores que me cometido: afixiarme de trabajo por nada, correr cuando no era necesario, creer que lo importante era mucho más importante de lo debido, etc. Son cosas que con la experiencia se mejoran, además, por suerte es un error muy común (mal de muchos…) en las empresas.
El error más grande que he cometido, de largo, ha sido trabajar demasiado y estar a muchas más cosas de las que realmente puedo controlar. Durante estos últimas semanas he notado cierta quemazón, pero es algo que tenía que pasar, es un testigo de que algo no estoy haciendo bien y por suerte creo que me voy dando cuenta de los errores y voy corrigiendolos. Obviamente no toda la culpa es mía, pero las circunstancias empiezan a ser problema tuyo cuando no las sabes manejar como deben.
Son 15 días que voy a usar para directamente no pensar. Hace unas semanas hubiera dedicado estas vacaciones para hacer algo en agroguía o pensar sobre vaya usted a saber. Pero no, lo voy a dedicar a leer el libro que mi buen amigo Alberto me regaló y descansar a dos manos :D.
Cuando venga hará dos años que pusimos agroguía en funcionamiento, voy a prepararme un post resumen con todo lo que hemos hecho y lo que tengo pensado hacer.
Los decorators en python son tremendamente útiles, cada día veo cosas más interesantes creadas con decoratos. Últimamente sobretodo relacionadas con Django (me imagino que por su pronta 1.0), para temas de cachés.
Como python es bastante más lento que C++, cuando renderizo geometría estático con python la máquina tiende a morirse donde con c++ iría suavemente. Lo habitual en OpenGL es usar listas precompiladas para optimizar geometría estática, una especie de caché que deja en gpu los datos a renderizar.
tenemos el siguiente método:
def draw_complex_geometry():
glBegin(GL_QUADS);
for x in vertex:
….
glEnd();
Nada impide hacer el siguiente decorator:
def list_compiler(fn):
fn.__gl_compiled = -1;
def render():
if(fn.__gl_compiled < 0):
fn.__gl_compiled = glGenLists(1);
glNewList(fn.__gl_compiled,GL_COMPILE);
fn();
glEndList();
else:
glCallList(fn.__gl_compiled);
return render;
de esta forma decoramos el método:
@list_compiler
def draw_complex_geometry()…
De forma que la primera vez que se llame compilará ls lista opengl y las siguientes veces símplemente llamará a la geometría “cacheada”
Pensaba que twitter era una verdadera pérdida de tiempo, por ello me di de alta hace unas semanaspara ver si realmente era así. Después de este tiempo me he dado cuenta que efectivamente es una pérdida de tiempo monumental :).
He posteado unas 10 ó 12 veces, casi siempre sobre cosas personales y la verdad no tengo muy claro si a alguien le interesa. A quien puede interesar mi vida? acaso me importa a mi la vida de los demás? Realmente no sé si me sirve de algo, voy a continuar usándolo hasta que se normalice la vida, pasen vacaciones y demás, para ver si es realmente útil o aporta algo.
He tratado de escribirlo en inglés, de esa forma así practicaba, pero si ya me cuesta expresar en castellano lo que hago, en inglés ni me imagino…
De momento si quieres puedes seguirme
Hay veces que creo que el sentido común no debe funcionar bien, llevamos años viendo como versión tras versión de opengl no dejan de ser pequeños añadidos que antes de incluirse en el standard han funciona como extensiones (vertex buffers, shaders por ejemplo). Resulta que ahora sacan una versión más, con más de lo mismo, aunque bien es cierto que no era lo prometido, y la gente se echa encima de khronos, opengl se acaba, opengl se muere… claro, es normal, como no hay apenas líneas escritas en opengl, como hay tantas opciones en sistemas unix, en sistemas embebidos como iphone, pda, teléfonos móviles, consolas…
Es cierto que en windows cara a ser productivo DX no tiene rival, pero es que microsoft lo ha hecho bien (aunque recordemos los cambios de API en versiones de DX de hace unos años), no hay más que bajarse el framework xna.
Lo dicho, opengl se acaba lo mismo que cuando SGI quebró y si es que se va a acabar muriendo no creo que lo haga de la noche a la mañana.