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.
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.
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 ... :)
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.
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:
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"
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
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.
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.
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...
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
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
7.28.2008
demovibes live
Nueva entrega recopilatoria de música scener esta vez remezclada
. La intro y la versión de fr08 me gustan mucho. Muy bueno también este otro de intros de 4kb, esta vez hecho por un español :).
Aprovecho para poner un enlace a las producciones de la euskal de este año, grande ASD.
. La intro y la versión de fr08 me gustan mucho. Muy bueno también este otro de intros de 4kb, esta vez hecho por un español :).
Aprovecho para poner un enlace a las producciones de la euskal de este año, grande ASD.
7.27.2008
El trabajo desde casa
Leo un artículo en el que dicen que google recomienda el trabajo desde casa y la verdad es que no puedo estar más de acuerdo, aunque con matices.
He vivido el trabajo desde casa desde varios frentes, con un jefe trabajando desde casa, con otros empleados trabajando desde casa y como trabajador desde casa :).
En general el tele-trabajo me parece mala idea como solución total, esto es, no funciona para nada si el trabajador está siempre fuera o si no trabaja en algo bastante aislado. Se producen malentendidos por IM, no tienes visión global cuando curras desde casa, no "sientes" como están las cosas y, lo peor, no tienes ningún tipo de actividad social (Cada día valoro más la parte social del programador).
Sin embargo, cuando estás en casa no tienes interrupciones de otros compañeros, estás muy centrado en tu trabajo, puedes emplear el tiempo de desplazamiento en dormir más, relajarme desyunando con el beneficio que esto aporta.
Yo apostaría por un perfil mixto, esto es, el empleado sabe cuando tiene que estar realizando una tarea de diseño y codificación muy concreta que requiere de concentración y cuando necesita estar gestionando tareas con otros compañeros. De hecho, 37signals recomiendan en getting real (una muy buena lectura, un día lo comento), al menos, trabajar 4 horas al día cada empleado por separado.
El problema es que el empleado debe ser muy serio, profesional y responsable ya que es muy fácil entretenerte "oliendo rosas", pero si sabe lo que tiene que hacer y cuando, son todo ventajas: La empresa gana productividad, el empleado gana tiempo (y dinero) y además el empleado siente que la empresa confía en él, lo cual es un plus de moral.
He vivido el trabajo desde casa desde varios frentes, con un jefe trabajando desde casa, con otros empleados trabajando desde casa y como trabajador desde casa :).
En general el tele-trabajo me parece mala idea como solución total, esto es, no funciona para nada si el trabajador está siempre fuera o si no trabaja en algo bastante aislado. Se producen malentendidos por IM, no tienes visión global cuando curras desde casa, no "sientes" como están las cosas y, lo peor, no tienes ningún tipo de actividad social (Cada día valoro más la parte social del programador).
Sin embargo, cuando estás en casa no tienes interrupciones de otros compañeros, estás muy centrado en tu trabajo, puedes emplear el tiempo de desplazamiento en dormir más, relajarme desyunando con el beneficio que esto aporta.
Yo apostaría por un perfil mixto, esto es, el empleado sabe cuando tiene que estar realizando una tarea de diseño y codificación muy concreta que requiere de concentración y cuando necesita estar gestionando tareas con otros compañeros. De hecho, 37signals recomiendan en getting real (una muy buena lectura, un día lo comento), al menos, trabajar 4 horas al día cada empleado por separado.
El problema es que el empleado debe ser muy serio, profesional y responsable ya que es muy fácil entretenerte "oliendo rosas", pero si sabe lo que tiene que hacer y cuando, son todo ventajas: La empresa gana productividad, el empleado gana tiempo (y dinero) y además el empleado siente que la empresa confía en él, lo cual es un plus de moral.
Fin de semana de descanso
Ayer estuve a ver kung fu panda, sesión de las 20:30, gran error, todo repleto de padres con niños esperando encontrarse una película de dibujos animados al uso. En España aún pensamos que una película de "dibujos animados" es necesariamente para niños.
La película me gustó bastante, quizás porque tengo alguna noción de como se hace y puedo valorar, aunque sea muy poco, el trabajo que lleva. Además, los comentarios de la tortuga son muy sabios :)
En una parte de la película un personaje le dice a otro "no lo sabes todo" y una de las niñas de atrás hizo una pregunta a su padre que me dejó pensativo:
"papa, qué es no saberlo todo?"
pregunta profunda y recursiva a su vez.
Aún estoy pensando por qué algunos se ven reflejados en el panda...
La película me gustó bastante, quizás porque tengo alguna noción de como se hace y puedo valorar, aunque sea muy poco, el trabajo que lleva. Además, los comentarios de la tortuga son muy sabios :)
En una parte de la película un personaje le dice a otro "no lo sabes todo" y una de las niñas de atrás hizo una pregunta a su padre que me dejó pensativo:
"papa, qué es no saberlo todo?"
pregunta profunda y recursiva a su vez.
Aún estoy pensando por qué algunos se ven reflejados en el panda...
7.24.2008
por que no me gusta java
Hace poco me decía una persona que por qué no me gustaba nada java y que pusiese las razones por las cuales no me gusta. Ahí voy.
Antes de empezar a programar en java había programado en C++ y en python y siempre pensé que java sería de un estilo a python, sobretodo debido a su fama de productivo. Además, siempre crei que el típico mito de lentitud en ejecución y el consumo de memoria no eran más que topicazos.
Lo cierto es que java es lento y chupa memoria, pero no menos que otros lenguajes dinámicos (la palma se la lleva ruby), pero no es por eso por lo que no me gusta. No me gusta porque es PESADO y ABURRIDO.
Estoy aburrido de tener una jerarquía de clases de 20 niveles para leer una petición HTTP de un servidor o de 6 ó 7 para leer un puñetero fichero. Lo que yo quiero leer es el fichero y punto, no quiero 500 líneas de traza cuando tengo un pete, quiero que me diga lo que ha pasado y punto, quiero crear una lista e iterarla, tener un hash de listas, tener un hash de listas de sets con unicodes e iterarlo sin tener que pararme a pensar en las declaraciones, quiero serializar sin tener que complicarme la vida con jerarquías, en resumen, quiero trabajar sin tener burocracia de por medio, sólamente poner lo que tengo en la cabeza y ya.
A pesar de eso hay que reconocer a java muchas cosas, las facilidades que da para hacer test unitarios, code coverage, rendimientos, consumos de memoria, etc, la calidad de los editores (eclipse se sale), que haya una empresa detrás manteniendo el API (esto lo considero muy muy importante), los servidores de aplicaciones, las herramientas como maven para resolver dependencias... la verdad es que se pueden hacer cosas muy buenas, por ejemplo hudson, todo un ejemplo de aplicación bien hecha, sencilla de usar, potente, extensible, con un interfaz rest claro. Si yo tuviese que hacer una aplicación con java, elegiría hacer una tan buena como esta. Además me gusta su dinamismo, en cuanto a que puedes llegar y cargar una clase según te plazca. No es tan potente como python o ruby, pero sí más que C++.
En resumen, lo bueno que tiene java no es el lenguaje, son las herramientas, empresas y en general todo el back-stage, que sinceramente es mucho, pero considero más importante que el desarrollador tenga "feeling" (vaya palabra mas estúpida) con lo que usa a tener que estar malgastando el tiempo en iterar una lista.
Antes de empezar a programar en java había programado en C++ y en python y siempre pensé que java sería de un estilo a python, sobretodo debido a su fama de productivo. Además, siempre crei que el típico mito de lentitud en ejecución y el consumo de memoria no eran más que topicazos.
Lo cierto es que java es lento y chupa memoria, pero no menos que otros lenguajes dinámicos (la palma se la lleva ruby), pero no es por eso por lo que no me gusta. No me gusta porque es PESADO y ABURRIDO.
Estoy aburrido de tener una jerarquía de clases de 20 niveles para leer una petición HTTP de un servidor o de 6 ó 7 para leer un puñetero fichero. Lo que yo quiero leer es el fichero y punto, no quiero 500 líneas de traza cuando tengo un pete, quiero que me diga lo que ha pasado y punto, quiero crear una lista e iterarla, tener un hash de listas, tener un hash de listas de sets con unicodes e iterarlo sin tener que pararme a pensar en las declaraciones, quiero serializar sin tener que complicarme la vida con jerarquías, en resumen, quiero trabajar sin tener burocracia de por medio, sólamente poner lo que tengo en la cabeza y ya.
A pesar de eso hay que reconocer a java muchas cosas, las facilidades que da para hacer test unitarios, code coverage, rendimientos, consumos de memoria, etc, la calidad de los editores (eclipse se sale), que haya una empresa detrás manteniendo el API (esto lo considero muy muy importante), los servidores de aplicaciones, las herramientas como maven para resolver dependencias... la verdad es que se pueden hacer cosas muy buenas, por ejemplo hudson, todo un ejemplo de aplicación bien hecha, sencilla de usar, potente, extensible, con un interfaz rest claro. Si yo tuviese que hacer una aplicación con java, elegiría hacer una tan buena como esta. Además me gusta su dinamismo, en cuanto a que puedes llegar y cargar una clase según te plazca. No es tan potente como python o ruby, pero sí más que C++.
En resumen, lo bueno que tiene java no es el lenguaje, son las herramientas, empresas y en general todo el back-stage, que sinceramente es mucho, pero considero más importante que el desarrollador tenga "feeling" (vaya palabra mas estúpida) con lo que usa a tener que estar malgastando el tiempo en iterar una lista.
7.23.2008
Los proyectos software son como cocinar un plato
- Salen mejor si los haces a fuego lento
- Conviene probarlos cada poco tiempo
- A veces hay que echarles un poco de sal
- Cuantas más veces lo haces mejor te sale, pero si lo haces muchas veces terminan por no gustar
- si te descuidas se quema y sabe mal
- Si lo sacas antes del horno estará crudo
- La receta debe evolucionar añadiendo nuevos ingredientes y quitando otros
- A nadie le gusta fregar lo ensuciado preparandolo
- Es mucho más fácil criticarlo que mejorarlo.
- Todo plato debe ir acompañado
- Y como no, después de comer lo cocinado debe haber postre y siesta :)
- Conviene probarlos cada poco tiempo
- A veces hay que echarles un poco de sal
- Cuantas más veces lo haces mejor te sale, pero si lo haces muchas veces terminan por no gustar
- si te descuidas se quema y sabe mal
- Si lo sacas antes del horno estará crudo
- La receta debe evolucionar añadiendo nuevos ingredientes y quitando otros
- A nadie le gusta fregar lo ensuciado preparandolo
- Es mucho más fácil criticarlo que mejorarlo.
- Todo plato debe ir acompañado
- Y como no, después de comer lo cocinado debe haber postre y siesta :)
7.17.2008
asserts en release
Tradicionalmente se ha dicho que los assert deben eliminarse en la compilación para release. La razón es la de siempre, la velocidad. Pongamos que en un bucle hacemos una comprobación:
for(int i = 0; i < len; ++i)
{
ASSERT(array[i] != NULL);
array[i]->method();
}
Es cierto que cada vuelta hará la comprobación y eso puede resultar caro computacionalmente (aunque en este caso con la predicción de saltos no habría agujeros en el pipeline para un funcionamiento normal). Este es un ejemplo simple, pero puede complicarse lo que se quiera.
Ahora, si miramos desde otro punto de vista, puede que no resulte tan caro. Si piensas el tiempo que te tiras buscando un error que se podría haber solucionado en poco tiempo viendo el rastro de asserts, seguro que no es tan caro.
Es cierto que en lenguajes como java, python, etc tienes los "stacktraces" que son un buen debugger, pero en C++ no es tan fácil y hay que andar con cuidado, sobretodo con punteros no válidos. Trabajando en un entorno de PC es fácil hacer debug, el entorno de desarrollo de lo pone en bandeja, ya que para cualquier pete enseguida te saca la típica ventana preguntándote si deseas debugear. En entornos como windows ce, donde no avisa al usar un puntero inválido, prácticamente es obligatorio poner unos cuantos asserts al comienzo de cada método.
En resumen, deja los assert en release :)
for(int i = 0; i < len; ++i)
{
ASSERT(array[i] != NULL);
array[i]->method();
}
Es cierto que cada vuelta hará la comprobación y eso puede resultar caro computacionalmente (aunque en este caso con la predicción de saltos no habría agujeros en el pipeline para un funcionamiento normal). Este es un ejemplo simple, pero puede complicarse lo que se quiera.
Ahora, si miramos desde otro punto de vista, puede que no resulte tan caro. Si piensas el tiempo que te tiras buscando un error que se podría haber solucionado en poco tiempo viendo el rastro de asserts, seguro que no es tan caro.
Es cierto que en lenguajes como java, python, etc tienes los "stacktraces" que son un buen debugger, pero en C++ no es tan fácil y hay que andar con cuidado, sobretodo con punteros no válidos. Trabajando en un entorno de PC es fácil hacer debug, el entorno de desarrollo de lo pone en bandeja, ya que para cualquier pete enseguida te saca la típica ventana preguntándote si deseas debugear. En entornos como windows ce, donde no avisa al usar un puntero inválido, prácticamente es obligatorio poner unos cuantos asserts al comienzo de cada método.
En resumen, deja los assert en release :)
7.14.2008
Cuanto daño ha hecho char*
Estoy remodelando una parte de agroguía y ya puestos estoy internacionalizando la aplicación. Lógicamente, cuando te pones a hacer las cosas, o las haces bien o no las haces, así que he empezado a tirar del hilo, eliminando todo lo no unicode que hubiese referente a mensajes de usuario.
Si ahora mismo tuviese que dar clase a cualquira sobre cualquier lenguaje de programación, lo primero que le explicaría es que hace unos años no se usaba unicode, se usaba una arcaica codificación llamada ASCII y que como mucho les llegaba para el alfabeto inglés. Bien es cierto que ascii sigue presente, pero menudo infierno.
Tengo unas 12 frases que internacionalizar, pero se está conviertiendo en un infierno, en parte por mi poca práctica, en parte porque nada estaba preparado para ello.
PD: es curioso, pero sin unicode el título de este post no podría haberse escrito correctamente :)
Si ahora mismo tuviese que dar clase a cualquira sobre cualquier lenguaje de programación, lo primero que le explicaría es que hace unos años no se usaba unicode, se usaba una arcaica codificación llamada ASCII y que como mucho les llegaba para el alfabeto inglés. Bien es cierto que ascii sigue presente, pero menudo infierno.
Tengo unas 12 frases que internacionalizar, pero se está conviertiendo en un infierno, en parte por mi poca práctica, en parte porque nada estaba preparado para ello.
PD: es curioso, pero sin unicode el título de este post no podría haberse escrito correctamente :)
7.11.2008
Stadium
Hoy toca autobombo, unkasoft ha presentado Stadium, un juego tipo track'n'field en el que solo necesitas un par de botones para jugar. En Unkasoft tenemos la mala costumbre de dar poca publicidad a lo que hacemos, ya sea por razones de secretismo absoluto, cosa que nunca entenderé o símplemente porque no tenemos tiempo *sic*, pero esta vez parece que hemos espabilado (pero poco)
El juego ha sido creado por Alberto Gonzalez (le conocerán de otros juegos como runaway2) como programador principal, diseño de Hugo Lanchares y diseño del apartado gráfico por Juanma Zarza. Ha participado más gente, pero esos fundamentalmente.
El juego es muy divertido, menudos piques hemos tenido en unkasoft (por cierto soy el puto rey en salto de longitud, 11 metros y pico), está muy bien equilibrado, tiene diferentes juegos que plantean varios retos, no solo es macharar el teclado. El apartado gráfico me parece muy apropiado, muy retro, todo se ve perfectamente y con buen acabado (como todo lo que hace juanma).
Otros análisis del juego por juanma y hugo y página de lanzamiento, compatibilidades y video in-game.
Personalmente las cosas que más me han gustado han sido los iconos de los botones, el confeti de cuano ganas (deberíamos publicar el códido del confeti :), la jugabilidad incluso en BASURAS como motorola V3, compatibilidad con blackberry de lo cual tenemos un poco de culpa félix y yo.
Cosas que me gustarían:
- Sabiendo como está el percal de mensajes a móviles, quizás debería haberse financiado la cosa con la publicidad in-game.
- Un making-off
- Multijugador bluetooth, aunque tiene un modo multi con el propio móvil.
- Ranking online. IMPERDONABLE. Teniendo infraestructura y experiencia con otros juegos (que no cito porque no sé si por condición de empleado puedo, juaz) me parece, sencillamente, un error grave ya que realmente habría incurrido en poco coste y la calidad hubiese sido mucho mayor.
NOTA: las opiniones que expreso en este blog NO son el calidad de trabajdor de unkasoft, son complemtamente personales.
7.06.2008
Meme de desarrollo de software
He visto en el blog de charles petzold un meme acerca de desarrollo de software, al cual recuerdo de cuando yo empezaba a programar algo en windows.
Me he tomado la libertad de tomar el meme, traducir las preguntas(así que puede haber errores) y lanzarlo:
- Cuántos años tenías cuando empezate a programar
Justo en primero de carrera, tendría entre 17 y 18, aunque aún tardaría un año y pico más en tener un PC propio :).
- Cómo empezaste a programar
Con las prácticas de programación de la carrera, aunque aún recuerdo haber tecleado algún programa en un spectrum.
- Cual fue el primer lenguaje que usaste
Si no recuerdo mal ensamblador del 8086, aunque casi a la par que C
- Cual fue el primer programa real que programaste
Real, real, que yo recuerde, quizás algún pequeño juego 2D.
- Qué lenguajes has usado desde que empezaste a programar
asm x86 y motorola 68000, C, C++, java (PUAG), python, C#, VB(S) y seguramente algún pinito en otros lenguajes como perl, ruby, shell y otros, aunque realmente solo considero que sé usar en condiciones C, C++ y python.
- Cual fue tu primera experiencia profesional
Fue en una empresa del metal (realmente fue un "compañero del metal"), comencé de grabador de datos e implementé un verdadero caos en VBS y python que terminó por funcionar. Me sentí orgulloso del trabajo, la verdad.
- Si tú hubieras sabido lo que sabes ahora cuando empezaste a programar, hubieras empezado a hacerlo?
Pregunta difícil. Si es a nivel personal, no dudaría, SI, es algo divertido y que plantea retos. Profesionalmente, lo dudo, quizás si dentro de unos años, pero ahora no. Trabajo mal pagado, mal considerado, poco comprendido y en que se requieren mucho más años para empezar en comparación con otros trabajos que he realizado. No pasa un mes sin que piense en irme a hacer otra cosa, aunque quizás no sepa... :_(
- Si tuvieras que decir una sola cosa de las que has aprendido a lo largo de los años a un nuevo programador, qué le dirías:
Le diría dos, Trabaja duro y nunca hagas caso a los que ten consejos.
- Qué es lo más divertido que has programado?
Pues no sé si algún que otro proyecto 3D en lo personal y en lo profesional me gustó mucho un trabajo que hice para controlar pivots, que por cierto aún no he terminado y aún no me han pagado. La relación hardware y software me ha llamado la atención siempre, quizás por ello he disfrutado mucho con agroguía, aunque últimamente no tanto.
- A quién le pasas el meme:
A todos los de mi trabajo: félix, JM, Antonio, Carlos, Jaime, Edu, Alberto y Alfredo (a ver si se anima el blog de unkasoft y nos quitamos un poco de presión), elvis (enhorabuena por el artículo en shaderx), vicente (anímate a mostrarte al mundo :P), a la gente de planet statos (venga zaelsius, aunque quieras ser project manager...).
Me he tomado la libertad de tomar el meme, traducir las preguntas(así que puede haber errores) y lanzarlo:
- Cuántos años tenías cuando empezate a programar
Justo en primero de carrera, tendría entre 17 y 18, aunque aún tardaría un año y pico más en tener un PC propio :).
- Cómo empezaste a programar
Con las prácticas de programación de la carrera, aunque aún recuerdo haber tecleado algún programa en un spectrum.
- Cual fue el primer lenguaje que usaste
Si no recuerdo mal ensamblador del 8086, aunque casi a la par que C
- Cual fue el primer programa real que programaste
Real, real, que yo recuerde, quizás algún pequeño juego 2D.
- Qué lenguajes has usado desde que empezaste a programar
asm x86 y motorola 68000, C, C++, java (PUAG), python, C#, VB(S) y seguramente algún pinito en otros lenguajes como perl, ruby, shell y otros, aunque realmente solo considero que sé usar en condiciones C, C++ y python.
- Cual fue tu primera experiencia profesional
Fue en una empresa del metal (realmente fue un "compañero del metal"), comencé de grabador de datos e implementé un verdadero caos en VBS y python que terminó por funcionar. Me sentí orgulloso del trabajo, la verdad.
- Si tú hubieras sabido lo que sabes ahora cuando empezaste a programar, hubieras empezado a hacerlo?
Pregunta difícil. Si es a nivel personal, no dudaría, SI, es algo divertido y que plantea retos. Profesionalmente, lo dudo, quizás si dentro de unos años, pero ahora no. Trabajo mal pagado, mal considerado, poco comprendido y en que se requieren mucho más años para empezar en comparación con otros trabajos que he realizado. No pasa un mes sin que piense en irme a hacer otra cosa, aunque quizás no sepa... :_(
- Si tuvieras que decir una sola cosa de las que has aprendido a lo largo de los años a un nuevo programador, qué le dirías:
Le diría dos, Trabaja duro y nunca hagas caso a los que ten consejos.
- Qué es lo más divertido que has programado?
Pues no sé si algún que otro proyecto 3D en lo personal y en lo profesional me gustó mucho un trabajo que hice para controlar pivots, que por cierto aún no he terminado y aún no me han pagado. La relación hardware y software me ha llamado la atención siempre, quizás por ello he disfrutado mucho con agroguía, aunque últimamente no tanto.
- A quién le pasas el meme:
A todos los de mi trabajo: félix, JM, Antonio, Carlos, Jaime, Edu, Alberto y Alfredo (a ver si se anima el blog de unkasoft y nos quitamos un poco de presión), elvis (enhorabuena por el artículo en shaderx), vicente (anímate a mostrarte al mundo :P), a la gente de planet statos (venga zaelsius, aunque quieras ser project manager...).
Suscribirse a:
Entradas (Atom)