8.31.2008

Se acabaron las vacaciones, conclusiones

Sí, este es el típico post del típico trabajador de la tecla que termina sus vacaciones...

Fundamentalmente he dividido el periodo en dos, el primero de ellos lo he pasado en un hotel-spa situado en Sesimbra (Portugal), unos 30 km al sur de Lisboa. El sitio muy bonito, una playa para pasear con el agua helada, pegando a un parque natural y con muy buena comida. Ya había estado de gira por Portugal, pero no ha dejado de sorprenderme la ausencia de radares fijos en autovía, las patatas hasta en la sopa y alguna que otra cosa. Una semana en la que creo que he hecho eso que denominan desconectar, esto es, no me he llevado el PC, PDA, ni he usado la wifi del móvil.

La segunda semana he estado en mi pueblo, pintando y adecentando mi habitación. Increíble lo difícil que puede ser hacer tareas manuales tan aparentemente simples como pasar un rodillo o tapar los agujeros provocados por mis antiguos posters. Ha sido un duro golpe quitar los posters de sega rally y tomb raider.

En resumen, lo de las vacaciones está muy bien, pero creo que soy animal de costumbres, me gusta más modificar mi rutina que cambiarla por completo. Me he dado cuenta de bastantes cosas:

- No hacer nada es una parte muy importante de la vida. Hacía tiempo que no me sentía bien sin estar haciendo nada.
- Me da igual estar al día. El día que llegué puse como leídos todos los post en mi bloglines, borré todos los correos no importantes (listas de correo, etc) y no ha pasado nada. Es más, he borrado la mayoría de los feeds a los que estaba suscrito... menudo peso de encima me he quitado de encima. Jo-der, que agusto
- Trabajo demasiado, es más, malgasto mi tiempo trabajando :)

Y no, no he recargado las pilas

8.25.2008

más reprogramaciones de centralita

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.

planificación inconsciente en desarrollo de software

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.




8.24.2008

Mis últimas lecturas

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 ... :)

8.16.2008

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.

8.13.2008

Caché Opengl con Python

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"

twitter

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

8.12.2008

opengl 3.0

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.

8.11.2008

software de lujo

Leo que una aplicación, i'm rich, para iphone que valía 1000$ ha vendido 8 copias (y la han retirando de appstore).

Cuando uno lee esto se plantea, pero somos gilipollas? como es posible que alguien compre algo que no tiene ninguna utilidad... y entonces tu cerebro te pega una torta con ejemplos como los anillos, pulseras, ropa, perfumes. Jode, pero es es el mundo real, la gente paga más por llevar cosas que hace posiblemente lo mismo que otras, más caras y que les distinguen de los demás.

Al final va a resultar cierto que es preferible hacer un software malo y venderlo a 3000$ (alguien caerá), que hacerlo bueno y vender muchas copias.

8.07.2008

Especialistas en Software

En dos años comprando PDAs Acer hemos tenido unoas 8 ó 9 rotas, algunas por que vinieron con problemas en la táctil, de batería... problemas menores. El servicio técnico de Acer para PDA ha funcionado muy muy bien, salvo un solo problema con una pda que nos devolvieron sin arreglar, lo demás como la seda, incluso en 3 ocasiones nos han devuelto una PDA nueva.

Lo gracioso del tema no es que hayan funcionado bien, que ya de por si merecía un post, lo que me hace gracia son las recomendaciones que envían en forma te nota:



Ya me jodería comprarte una PDA para usarla como navegador, gastarte 160€ en tu copia de TOMTOM y que te digan que no uses el software porque estropea la PDA por sobrecarga. Aparte, el detalle de la cinta aislante es a tener en cuenta... :)

Siempre me han comentado que el servicio técnico de Acer era muy malo, cosa de la que no puedo estar más en desacuerdo para PDA. Una lástima que ya no fabriquen...

8.04.2008

beauty XML con VIM

Estamos trabajando con unos servicios REST que devuelven la respuesta en xml (en realidad atom) y es un verdadero coñazo leer las respuestas que retorna el servidor ya que el XML no está ni formateado, nisiquiera tiene saltos de linea, en resumen todo apelotonado.

Para ello he optado por crear un pequeño script para vim que no es perfecto pero soluciona la papeleta de forma eficiente:

map <F6> :%s/>\s*</>\r</g<CR>ggVG=

EN resumen, busca ocurrencias de ...>(espacios)<... y mete un \r entre ellas. Luego selecciona todo el texto (gg va al comienzo, V pasa a modo "selección lineas" y G lleva el cursor al final seleccionando todo), para al final reformatear con el bestialmente-util comando "=" de vim

Ahora para ver la respuesta del servidor basta con hacer:

wget http://server/v1/resources/ -qO- | vim - y pulsar F6 a continuación