Jajaja, lo sabía, sabía que algo no estaba funcionando bien. Acabo de recibir una carta de renault diciendome que tengo que ir a reprogramar la centralita de mi megane (releo es post y eché gasoil a 0.88) debido a que la anterior programación no solventaba los problemas que trabaja de corregir… :).
Para renault es una GRAN CAGADA, me imagino los gastos: por cada motor dCi vendido en un determinado periodo de tiempo han tenido que enviar una carta certificada a la persona (y buscarla si el coche ha cambiado de propietario), horas de ingeniero para corregir el problema, horas de calidad, horas de taller (que son cobradas a cojón de ovispo), malestar del comprador y eso por no hablar de los motores quemados a cuenta del problema.
He hablado ya algunas veces de los bugs que surgen en producción y lo importante de la trazabilidad. Punto negativo para renault por cometer un error el diseño del vehículo (cosas de industriales) que al final tiene que venir a corregir un trozo de software y otro punto negativo por el control de calidad que pasó la anterior reprogramación. Pero un buen punto positivo porque mantienen una trazabilidad bastante decente. Sería delito que las punteras en este tipo de cosas no lo hicieran, aún así es de agradecer.
Por cierto, desde renault no se han dignado a contestarme al correo que les envié solicitándoles que, por dios, mejorasen el mapeo acelerador -> inyección. He encontrado algunos circuítuos basados en filtros y aplificadores que corrigen ese problemas, pero tampoco es cuestión de meter electrónica si es posible modificarlo por software. Daré de nuevo la chapa con el tema a ver si consigo que me lo reprogramen con los parámetros que yo quiero.
Estoy leyendo el libro “práctica de la inteligencia emocional”, una referencia según la gente que parece que sabe del tema. En uno de los capítulos hacen referencia a la toma de decisiones, como actúan las diferentes partes del cerebro, como se reaciona en diversas situaciones (estrés, tranquilidad, etc) y en qué forma las tomamos. En resumen habla de dos formas, una de ellas meditada y consciente y otra de ellas inconsciente.
La primera de ellas viene a ser las decisiones en las que razonamos en base a lo que vemos y la segunda es en base a un tick, al sexto sentido o como lo quiera que se llame. Cuantas veces me ha pasado que “algo” me decía que no debía hacer algo, finalmente lo hice razonando la decisión y al final la mangué. El libro da explicación a esto: el cerebro, subconcientemente, es capaz de dar resultados a tomas de decisiones muy rápidamente en base a la experiencia vivida anteriormente.
Actualmente estoy dentro de una implantación de CMM2, en la cual me han indicado que tenía que dar una serie de patrones para esblecer el tamaño y complejidad de una tarea dentro del proyecto del que soy responsable (en realidad soy juez y parte :P), de esta forma, gracias a estas medidas y la experiencia acumulada a lo largo del tiempo en diferentes tareas se pueda extrapolar el tiempo en una futura tarea.
Realmente esto es bonito, da igual quien esté que si alguien planifica una tarea, el tiempo se podrá estimar, con un ratio de error, toda la maquinaria funcionará perfectamente en base al conocimiento plasmado en tablas de datos, sobre tiempos, complejidades, tamaños y demás.
Lo cierto es que mi cerebro ya hace eso, cuando alguien me pregunta “oye, cuánto crees que tardarás en hacer tal cosa”, mi cerebro ya sabe qué preguntas debo hacer, por donde pueden venir los problemas y cuando tiempo puedo tardar. Y lo mejor, a medida que pasa el tiempo lo hago mejor e incluso me dice el tiempo que podría tardar otra persona. Mi cerebro está tomando decisiones sin que yo tenga que pensar, mi sexto sentido programadoril (R) me dice lo que está pasando cual sentido aracnido a espiderman, de ahí la introducción de este post.
Esto no es tan bonito cara a una empresa, si el fulano encargado de hacer esas estimaciones se va, la empresa se queda en bragas, así que quizás un modelo híbrido sea lo mejor, sobretodo para pequeñas empresas, aunque en este caso, y como opinión personal, me vale más la opinión de una persona con experiencia que mil hojas de excel y mucho más en entornos con cambios rápidos de requisitos.
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”
