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 ... :)
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...).
6.30.2008
El problema del feedback
Últimamente estoy un poco obsesionado con el feedback y no en especial con la información que me llega, que eso es tema para otro post, si no por la información que soy capaz de usar de forma adecuada.
Parto de la premisa de que no soy una persona tipo seguramente para nada de lo que desarrollo y es muy posible que lo que para ti sea la feature del siglo, para los demás sea algo que está ahí, pero que le importa muy poco.
Recientemente me ha pasado. He creado una herramienta para exportación de datos de agroguía al PC, de forma que en google earth puedes ver los trabajos realizados. Para mi la feature mola la leche, pero a los agricultores parece importarles muy poco. Lógico, ya que no suelen usar el PC para hacer este tipo de cosas (salvo excepciones), así que era de esperar.
¿Es una __cagada__ o una pérdida de tiempo? pues posiblemente comercialmente lo sea, por lo menos en este momento. Podría haber invertido ese tiempo en una feature más solicitada? seguro que sí y además seguro que gracias a esa feautre podría haber vendido más, pero y lo importante que es estar contento con lo que haces? y el feedback que puedo obtener de esos datos? Como dice Steve Jobs, espero poder algún día unir puntos hacia atrás. También opino, aunque sea una osadía nisiquiera comparar mi afirmación con la suya, que tarde o temprano todo lo que has aprendido/hecho servirá para algo.
Me voy a dar un paseo por el campo a darme feedback y despejarme un poco, se encuentra cosas curiosas:
- Un conejo a 2 metros de mi, con lo asustadizos que son:
- Hay cosas curiosas, cosas que todos los días ves y nunca te paras a pensar. Últimamente me ha dado por los pivots de riego... en esta foto se ve perfectamente como las bocas de más lejos echan más agua sobre el cultivo, parece lógico si piensas el área que cubre cada una sabiendo que al proporción de agua debe ser constante (o no, imaginemos que tenemos mapas ed rendimiento...)
Parto de la premisa de que no soy una persona tipo seguramente para nada de lo que desarrollo y es muy posible que lo que para ti sea la feature del siglo, para los demás sea algo que está ahí, pero que le importa muy poco.
Recientemente me ha pasado. He creado una herramienta para exportación de datos de agroguía al PC, de forma que en google earth puedes ver los trabajos realizados. Para mi la feature mola la leche, pero a los agricultores parece importarles muy poco. Lógico, ya que no suelen usar el PC para hacer este tipo de cosas (salvo excepciones), así que era de esperar.
¿Es una __cagada__ o una pérdida de tiempo? pues posiblemente comercialmente lo sea, por lo menos en este momento. Podría haber invertido ese tiempo en una feature más solicitada? seguro que sí y además seguro que gracias a esa feautre podría haber vendido más, pero y lo importante que es estar contento con lo que haces? y el feedback que puedo obtener de esos datos? Como dice Steve Jobs, espero poder algún día unir puntos hacia atrás. También opino, aunque sea una osadía nisiquiera comparar mi afirmación con la suya, que tarde o temprano todo lo que has aprendido/hecho servirá para algo.
Me voy a dar un paseo por el campo a darme feedback y despejarme un poco, se encuentra cosas curiosas:
- Un conejo a 2 metros de mi, con lo asustadizos que son:
- Hay cosas curiosas, cosas que todos los días ves y nunca te paras a pensar. Últimamente me ha dado por los pivots de riego... en esta foto se ve perfectamente como las bocas de más lejos echan más agua sobre el cultivo, parece lógico si piensas el área que cubre cada una sabiendo que al proporción de agua debe ser constante (o no, imaginemos que tenemos mapas ed rendimiento...)
6.28.2008
Modales en autovía
Este post se sale complemtamente de la temática ya de por si difusa de este mi blog. Paso un buen rato cada día al volante, todo por autovía, y me canso de ver subnormalidades sin parar. Estas normas son "normas no escritas" (aunque quizás deberían estarlo), pero son de sentido común, y cualquier persona al volante en una autovía debería conocerlas, allá van:
- Si vas a 150 es TU problema, no me pidas paso ni me pites si estoy en el carril izquierdo a velocidad legal. Habitualmente suelen ser conductores de, o coches de alta gama, o coches con cierta "estamina". Esto nos ha pasado muchas veces a todos, llega el típico fulano a toda leche y nos pide paso cuando estamos a medio adelantamiento de un camión.
- No voy a correr más porque te pegues más. Es causa de lo anterior, hay gente que se pega en tu culo y se cree que son capaces de reaccionar en 3 metros.
- El intermitenten izquierdo sirve para: desplazarse del carril derecho al izquierdo, pero NUNCA para permanecer en el izquierdo. Si permaneces en el izquierdo con el intermitente izquierdo puesto indicas al de delante que quieres adelantarle.
- POR FAVOR, SEAMOS DINÁMICOS EN LOS ADELANTAMIENTOS: Por mucho que salgas al carril izquierdo 500 metros antes de llegar al camión no pienso quedarme a 90 en el carril derecho. Hay mucha gente que se pone a adelantarte justo cuando llegas detrás del camión, con lo cual te toca pasar a de 120 a 90. Es facilísimo pisar un poco más para adelantar antes o incluso levantar un poco para dejar pasar. Otro caso es cuando hay una cola de camiones, suficientemente distanciados y una persona se queda en el carril izquierdo... por qué no te metes al carril derecho, los demás procurarán no dejarte metid ahí.
- Que tu coche sea potente me da igual, si me salgo al carril izquierdo para dejar que te incorpores en la autovía, déjate adelantar y luego ya acelerarás. No hagas la puñeta de acelerar y adelantar por el carril derecho.
- Trata de no joder con la velocidad: hay gente que pasa de 90 a 120, luego 140, frena... hay otros que aceleran cuando llegas a su altura (qué te hace pensar que si antes estaba a 3km y ahora a 50metros vas más rápido que yo?), aceleran cuando te adelantan y luego se ponen a ir más despacio. Vale, para los coches que no tengan control de velocidad no es tan fácil o por circunstancias debes ir más despacio, pero me he encontrado con casos de ir adelantándonos 100km sin yo tocar en control de velocidad (y creedme que es preciso, aunque tenga un poco de sesgo)
- No salgas a 60km/h a la autovía. NO ME JODAS, pisa al coche por una vez en tu vida y sal a una velocidad decente, por tu seguridad. He visto verdaderos animales saliendo a la autovía a 50km con coches de 140cv. Con un coche de 100cv en un carril de aceleración normal puedes llegar a salir a 130-140km/h, así que pisale que el coche no se rompe.
- No me voy a picar. No voy a echar carreritas por la autovía, así que cuando me adelantes no me mires amenazante, no me des ráfagas ni me pites. Si eres tan tonto de dar 3/4 de rotonda por el carril derecho y te he adelantado, espabila y aprende a coger las rotondas. Es muy común que, sobretodo los makis, se piquen poque les pases en las rotondas.
y un extra para los salmantinos:
- Las rotondas tienen DOS carriles
- PARA QUEDARME EN LA ROTONDA NO DOY EL INTERMITENTE IZQUIERDO. sí, señores, la gente de salamanca para indicar que no va a salir de la rotonda da el intermintente izquierdo. Yo que el 90% de las veces voy por el interior, no sé si es que se quedan en la rotonda o es que se cambian al carril del centro. ODIO profundamente estas normas "de facto" que la gente sigue como ovejas... va un subnormal, lo hace un día y todos a hacerlo. Sé que hay gente que hace la tijera y se va del carril central hacia fuera de la rotonda, pero qué le vamos a hacer.
- Si vas a 150 es TU problema, no me pidas paso ni me pites si estoy en el carril izquierdo a velocidad legal. Habitualmente suelen ser conductores de, o coches de alta gama, o coches con cierta "estamina". Esto nos ha pasado muchas veces a todos, llega el típico fulano a toda leche y nos pide paso cuando estamos a medio adelantamiento de un camión.
- No voy a correr más porque te pegues más. Es causa de lo anterior, hay gente que se pega en tu culo y se cree que son capaces de reaccionar en 3 metros.
- El intermitenten izquierdo sirve para: desplazarse del carril derecho al izquierdo, pero NUNCA para permanecer en el izquierdo. Si permaneces en el izquierdo con el intermitente izquierdo puesto indicas al de delante que quieres adelantarle.
- POR FAVOR, SEAMOS DINÁMICOS EN LOS ADELANTAMIENTOS: Por mucho que salgas al carril izquierdo 500 metros antes de llegar al camión no pienso quedarme a 90 en el carril derecho. Hay mucha gente que se pone a adelantarte justo cuando llegas detrás del camión, con lo cual te toca pasar a de 120 a 90. Es facilísimo pisar un poco más para adelantar antes o incluso levantar un poco para dejar pasar. Otro caso es cuando hay una cola de camiones, suficientemente distanciados y una persona se queda en el carril izquierdo... por qué no te metes al carril derecho, los demás procurarán no dejarte metid ahí.
- Que tu coche sea potente me da igual, si me salgo al carril izquierdo para dejar que te incorpores en la autovía, déjate adelantar y luego ya acelerarás. No hagas la puñeta de acelerar y adelantar por el carril derecho.
- Trata de no joder con la velocidad: hay gente que pasa de 90 a 120, luego 140, frena... hay otros que aceleran cuando llegas a su altura (qué te hace pensar que si antes estaba a 3km y ahora a 50metros vas más rápido que yo?), aceleran cuando te adelantan y luego se ponen a ir más despacio. Vale, para los coches que no tengan control de velocidad no es tan fácil o por circunstancias debes ir más despacio, pero me he encontrado con casos de ir adelantándonos 100km sin yo tocar en control de velocidad (y creedme que es preciso, aunque tenga un poco de sesgo)
- No salgas a 60km/h a la autovía. NO ME JODAS, pisa al coche por una vez en tu vida y sal a una velocidad decente, por tu seguridad. He visto verdaderos animales saliendo a la autovía a 50km con coches de 140cv. Con un coche de 100cv en un carril de aceleración normal puedes llegar a salir a 130-140km/h, así que pisale que el coche no se rompe.
- No me voy a picar. No voy a echar carreritas por la autovía, así que cuando me adelantes no me mires amenazante, no me des ráfagas ni me pites. Si eres tan tonto de dar 3/4 de rotonda por el carril derecho y te he adelantado, espabila y aprende a coger las rotondas. Es muy común que, sobretodo los makis, se piquen poque les pases en las rotondas.
y un extra para los salmantinos:
- Las rotondas tienen DOS carriles
- PARA QUEDARME EN LA ROTONDA NO DOY EL INTERMITENTE IZQUIERDO. sí, señores, la gente de salamanca para indicar que no va a salir de la rotonda da el intermintente izquierdo. Yo que el 90% de las veces voy por el interior, no sé si es que se quedan en la rotonda o es que se cambian al carril del centro. ODIO profundamente estas normas "de facto" que la gente sigue como ovejas... va un subnormal, lo hace un día y todos a hacerlo. Sé que hay gente que hace la tijera y se va del carril central hacia fuera de la rotonda, pero qué le vamos a hacer.
6.20.2008
Aprendiendo a negociar
Cuando te enfrentas a algo nuevo, además de la sensación de que no tienes ni puta idea, intentas aplicar el sentido común: "a ver si yo vendo esto a tanto y ellos lo quieren vender a tanto podría intentar vender a esto para ganar X". Pero una vez has terminado de pensar eso dices: "y si lo vendo demasiado caro y si es demasiado barato y me pillo los dedos...". Realmente no tengo nada con qué comparar, no tengo esa percepción interna de por donde van los tiros. Me pueden preguntar cuanto tardaría en programar un sistema que hiciese tal y cual, y más o menos puedo dar una estimación en base a mi experiencia y conicimiento, incluso si no supiese nada, podría irme a sitios donde puedo encontrar información.
Sin embargo aquí estoy perdido, nisiquiera sé donde buscar información ni conozco a nadie que sepa del tema, es más, nisiquiera sé si hay una profesión que se dedique a negociar (tal vez un comercial? uff!).
El caso es que tengo ahora mismo dos peticiones para distribuir agroguía internacionalmente (jaja, qué bien queda) y realmente __estoy muy perdido__. De todas formas, como agroguía es mi "plan B", si pierdo tampoco he perdido mucho y si gano a lo mejor me puedo compar un coche para hombres como buen hombre de negocios, como si fuera un comercial y eso siendo un tecnicucho :). Me hace gracia, me imagino la cara que se les quedaría a la otra parte si supieran que el que está al otro lado es un chaval de 26 años que no tiene ni zorra. A lo mejor lo saben e intentan aprovecharse... Hay tantas pregunas que me parece hasta divertido.
De momento aquí lo estamos haciendo bien, creo que somos los únicos aquí que vendemos por internet, así que eso es ya un paso... estoy preparando además la nueva web de agroguia, no es gran cosa, pero mejora bastante la actual.
¿Alguna sugerencia/experiencia?
Sin embargo aquí estoy perdido, nisiquiera sé donde buscar información ni conozco a nadie que sepa del tema, es más, nisiquiera sé si hay una profesión que se dedique a negociar (tal vez un comercial? uff!).
El caso es que tengo ahora mismo dos peticiones para distribuir agroguía internacionalmente (jaja, qué bien queda) y realmente __estoy muy perdido__. De todas formas, como agroguía es mi "plan B", si pierdo tampoco he perdido mucho y si gano a lo mejor me puedo compar un coche para hombres como buen hombre de negocios, como si fuera un comercial y eso siendo un tecnicucho :). Me hace gracia, me imagino la cara que se les quedaría a la otra parte si supieran que el que está al otro lado es un chaval de 26 años que no tiene ni zorra. A lo mejor lo saben e intentan aprovecharse... Hay tantas pregunas que me parece hasta divertido.
De momento aquí lo estamos haciendo bien, creo que somos los únicos aquí que vendemos por internet, así que eso es ya un paso... estoy preparando además la nueva web de agroguia, no es gran cosa, pero mejora bastante la actual.
¿Alguna sugerencia/experiencia?
6.19.2008
a vueltas con el software de mi coche
Sigo dándole vueltas a la reprogramación que hicieron en mi megane el otro día. La reprogramación solucionaba un problema en el que a causa del sobrecalentamiento de "algo" del aire frio (me imagino que serán los disipadores de calor, viva el ciclo ese del frio calor) ardía "alguna parte" y esta a su vez la correa de la distribución, con la consecuente avería. A priori no debía de tocar para nada la inyección de gasoil, símplemente tendrían que parar el compresor del aire acondicionado para evitar sobrecalentamiento, sin embargo el mapeo de input del acelerador a la inyección de carburante ha cambiado, ahora hay un lag, sobretodo en primera, que me molesta muchísimo.
He hablado con el taller oficial para ver si podían reprogramarme el sistema con el anterior mapeo y no es posible, por tanto he enviado un par de correos a renault... no voy a conseguir nada, pero igual que a mi me gusta recibir feedback (que no bugs, eso no le gusta a nadie) del software que hago, estaría bien que los que programan las centralitas sepan que me tienen hasta el gorro :).
He hablado con el taller oficial para ver si podían reprogramarme el sistema con el anterior mapeo y no es posible, por tanto he enviado un par de correos a renault... no voy a conseguir nada, pero igual que a mi me gusta recibir feedback (que no bugs, eso no le gusta a nadie) del software que hago, estaría bien que los que programan las centralitas sepan que me tienen hasta el gorro :).
6.11.2008
horas de la jornada laboral
Cuántas horas son necesarias, o mejor dicho, óptimas en la jordana laboral de un desarrollador? Desde que he escuchado en la radio algo sobre jornadas de 65 horas semanales (no pongo links porque lo he escuchado y tampoco lo he dado mucha importancia) me hago esa pregunta.
Personalmente tengo tendencia a trabajar de más, me da la impresión que ya es vicio, aunque sí que me doy cuenta que al final del día, delante del monitor, me cuesta mucho escribir código o pensar cosas relacionadas. Cuanto realmente soy productivo de verdad? mi opinión es que puedo llegar a ser productivo unas 4 horas al día como máximo, esto es, centrado en lo que estoy haciendo, con toda la atención en ello y con cierto "gusto" por ello, lo que ahora llaman, "estar en flujo"
Me pregunto, sería mejor tener una jornada laboral de menos horas? cuántos bugs o fallos se cometen por culpa de no estar "en flujo"? cuántos se cometen cuando lo estás? mi opinión es que 8 horas son una burrada, aunque no todo es estar programando, la jornada laboral se compone de:
- trabajo productivo directo, que es hacer trabajo *real*.
- indirecto, que es estar aprendiendo cosas nuevas, leyendo documentación, libros, etc
- trabajo que no "sirve para nada", esto es, el de gestión y digo que no sirve de nada porque no añade nada al trabajo final, es algo que está ahí y es necesario, pero si no necesitasemos ese tiempo no pasaría nada. Aquí incluyes la formación a otras personas, etc.
- descanso: cada X tiempo es necesario parar
Es difícil calcular, pero por ejemplo, cuando hay jordana continua de 7 horas, mi vida mejora enteros y creo que mi producción aumenta a pesar de trabajar una hora menos.
¿Es proporcional la producción al número de horas?
Aunque hay muchas cosas que aumentan la productividad, pero eso es tema de otro post.
Personalmente tengo tendencia a trabajar de más, me da la impresión que ya es vicio, aunque sí que me doy cuenta que al final del día, delante del monitor, me cuesta mucho escribir código o pensar cosas relacionadas. Cuanto realmente soy productivo de verdad? mi opinión es que puedo llegar a ser productivo unas 4 horas al día como máximo, esto es, centrado en lo que estoy haciendo, con toda la atención en ello y con cierto "gusto" por ello, lo que ahora llaman, "estar en flujo"
Me pregunto, sería mejor tener una jornada laboral de menos horas? cuántos bugs o fallos se cometen por culpa de no estar "en flujo"? cuántos se cometen cuando lo estás? mi opinión es que 8 horas son una burrada, aunque no todo es estar programando, la jornada laboral se compone de:
- trabajo productivo directo, que es hacer trabajo *real*.
- indirecto, que es estar aprendiendo cosas nuevas, leyendo documentación, libros, etc
- trabajo que no "sirve para nada", esto es, el de gestión y digo que no sirve de nada porque no añade nada al trabajo final, es algo que está ahí y es necesario, pero si no necesitasemos ese tiempo no pasaría nada. Aquí incluyes la formación a otras personas, etc.
- descanso: cada X tiempo es necesario parar
Es difícil calcular, pero por ejemplo, cuando hay jordana continua de 7 horas, mi vida mejora enteros y creo que mi producción aumenta a pesar de trabajar una hora menos.
¿Es proporcional la producción al número de horas?
Aunque hay muchas cosas que aumentan la productividad, pero eso es tema de otro post.
6.09.2008
El trabajo en equipo
Estaba yo viendo el siguiente video:
Y pensaba cuantas personas hay ahí funcionando, ya no solo haciendo la música, que con eso bastaría, pero es que además está sonido, iluminación, cámaras, realizador... etc, etc, todo perfectamente coordinado y sincronizado.
No todo sale bien, el de sonido al principio le pone el retorno de audio muy alto y la jode los oidos a la cantante, de ahí que la mujer se apresure a bajarlo en la pecata amarilla que lleva dentro del bolso, el realizador la caga en el plano en el que mike oldfield se está peleando con la bufanda, etc, pero en general todo va perfecto, todo sigue, la cantante continúa cantando, el realizador da un plano para que no sea vea como toca la petaca, mike oldfield la caga con la guitarra pero sale del aprieto de puta madre (ver el comentario de un tal "richaxes" en youtube).
No sé la cantidad de personas que estarán trabajando ahí, pero me asombra ver como se pueden coordinar. Desarrollando software formas un equipo de 3 personas y ya la has liado, ya necesitas por lo menos un coordinador para que la cosa marche. Me da un poco de vergüenza, la verdad, sobretodo teniendo en cuenta que, por ejemplo, la cámara de atrás, esa que va volando por encima mike oldfield requiere de 3 personas para controlarla, pero ahí están, dando buenos planos, coordinados con otros tantos cámaras, el realizador, la canción...
Cuanto nos queda por aprender en el desarrollo de software, quizás cuando llevemos años y años haciendo lo mismo podamos ser tan buenos :).
Y pensaba cuantas personas hay ahí funcionando, ya no solo haciendo la música, que con eso bastaría, pero es que además está sonido, iluminación, cámaras, realizador... etc, etc, todo perfectamente coordinado y sincronizado.
No todo sale bien, el de sonido al principio le pone el retorno de audio muy alto y la jode los oidos a la cantante, de ahí que la mujer se apresure a bajarlo en la pecata amarilla que lleva dentro del bolso, el realizador la caga en el plano en el que mike oldfield se está peleando con la bufanda, etc, pero en general todo va perfecto, todo sigue, la cantante continúa cantando, el realizador da un plano para que no sea vea como toca la petaca, mike oldfield la caga con la guitarra pero sale del aprieto de puta madre (ver el comentario de un tal "richaxes" en youtube).
No sé la cantidad de personas que estarán trabajando ahí, pero me asombra ver como se pueden coordinar. Desarrollando software formas un equipo de 3 personas y ya la has liado, ya necesitas por lo menos un coordinador para que la cosa marche. Me da un poco de vergüenza, la verdad, sobretodo teniendo en cuenta que, por ejemplo, la cámara de atrás, esa que va volando por encima mike oldfield requiere de 3 personas para controlarla, pero ahí están, dando buenos planos, coordinados con otros tantos cámaras, el realizador, la canción...
Cuanto nos queda por aprender en el desarrollo de software, quizás cuando llevemos años y años haciendo lo mismo podamos ser tan buenos :).
6.08.2008
RTS procedural
Estaba viendo los resultados de la compo de Tigsource sobre juegos con contenido procedural y bajandome los más llamativos me encuentro con Dyson. Se trata de un juego de estrategia, donde hay una serie de asteroides que tenemos que colonizar con una especie de moscas. En cada asteroide plantamos una serie de árboles (L-tree claro está) que nos permiten generar más moscas. Para colonizar un asterisco asteroide hay que enviar una cantidad suficiente de moscas... el juego no deja de ser lo mismo que todos los RTS actuales, una serie de recursos para generar unidades y conquistar más recursos.
El juego es simple, pero muy adictivo, además el apartado gráfico cumple perfectamente, da gusto ver como se mueven las moscas como un fluido cuando tienes más de 100. Merece la pena probarlo.
A ver si sacan los resultados y pruebo los mejores juegos porque en la compo hay demasiados juegos para probarlos todos.
El juego es simple, pero muy adictivo, además el apartado gráfico cumple perfectamente, da gusto ver como se mueven las moscas como un fluido cuando tienes más de 100. Merece la pena probarlo.
A ver si sacan los resultados y pruebo los mejores juegos porque en la compo hay demasiados juegos para probarlos todos.
6.04.2008
Metodologías: ¿sí o no?
Llevo un tiempo leyendo algunos libros y artículos sobre metodologías además de estar dentro de un proceso de adaptación a CMM2. La gestión de proyectos es compleja, por lo menos desde mi visión actual con más bien escasa experiencia, y aún no tengo muy claras las cosas.
Resulta que el objetivo del desarrollo es tener algo tangible, algo que se pueda usar, que sea útil y en el que cuanta menos burocracia haya mejor. Esto es aplicable no solo al desarrollo de software, si no a cualquier proyecto, pero yo no sé que pasa que en todos los proyectos/negocios que veo al final se consume más tiempo en burocracia que en desarrollo.
Si tienes una empresa de 100 empleados parece lógico que la burocracia aumente, sobretodo porque con 100 empleados tienes mucha probabilidad de que tengas a mucha gente no muy buena en su trabajo, poco motivada, etc. Es normal que se tengan que marcar unas reglas estrictas de funcionamiento.
Me planteo si de verdad usar metodologías muy severas aporta algo a proyectos dinámicos, los cuales se adaptan de forma rápida a las necesidades o si estoy confundido y es necesario un control muy cerrado para llevar un proyecto a cabo con una calidad profesional.
Al final creo que el camino se hace al andar, que las metodologías describen los procesos que se han ido mejorando a lo largo del tiempo y que de verdad han demostrado que funcionan después de probar variantes, ver el resultado y sobretodo cargarla. Al final si el equipo es bueno y estila buenas prácticas la metodología aparece sola.
Me recuerda a una frase que leía en una bodega de un familiar: "una buen vino puede arreglar una mala comida y uno malo estropear una buena"
Resulta que el objetivo del desarrollo es tener algo tangible, algo que se pueda usar, que sea útil y en el que cuanta menos burocracia haya mejor. Esto es aplicable no solo al desarrollo de software, si no a cualquier proyecto, pero yo no sé que pasa que en todos los proyectos/negocios que veo al final se consume más tiempo en burocracia que en desarrollo.
Si tienes una empresa de 100 empleados parece lógico que la burocracia aumente, sobretodo porque con 100 empleados tienes mucha probabilidad de que tengas a mucha gente no muy buena en su trabajo, poco motivada, etc. Es normal que se tengan que marcar unas reglas estrictas de funcionamiento.
Me planteo si de verdad usar metodologías muy severas aporta algo a proyectos dinámicos, los cuales se adaptan de forma rápida a las necesidades o si estoy confundido y es necesario un control muy cerrado para llevar un proyecto a cabo con una calidad profesional.
Al final creo que el camino se hace al andar, que las metodologías describen los procesos que se han ido mejorando a lo largo del tiempo y que de verdad han demostrado que funcionan después de probar variantes, ver el resultado y sobretodo cargarla. Al final si el equipo es bueno y estila buenas prácticas la metodología aparece sola.
Me recuerda a una frase que leía en una bodega de un familiar: "una buen vino puede arreglar una mala comida y uno malo estropear una buena"
5.29.2008
Bugs en la centralita de mi coche
Cuando hablamos de un bug en una aplicación para dibujar hablamos de una pequeña putada, llega grafista, dibuja un logotipo de muerte y tras 3 horas intenta grabar y la aplicación casca. No pasa nada, el grafista pierde 3 horas de su vida, se cabrea y listo. Si hablamos de un software que se ejecuta en un hardware que controla un vehículo, un avión o un sistema donde se hacen transacciones bancarias la cosa cambia. Un error puede matar a una persona que circula en su vehículo y pierde los frenos.
Dada el impacto que puede producir un error en un software de estas características cabe pensar que los desarrolladores de estas aplicaciones estén muy formados y que las pruebas de calidad que pasen sean muy minuciosas.
Hace unos días me llegó una carta certificada de Renault, indicándome que tenía que llevar mi coche a un concesionario oficial para hacerme una reprogramación por peligro de "bloqueo del motor durante su utilización". No creo que después de 50mil kilómetros me vaya a petar el motor, aunque quien sabe. En resumen, me ha cambiado el software que controla la inyección de carburante, que suena importante.
Me imagino que el software de inyección irá en un hardware aparte que el ordenador de a bordo, el cual me estima mi consumo instantáneo, medio, etc. Bien, después de este reinicio ahora el coche no calcula bien el consumo medio, lo que me hace pensar que el software de mi ordenador de a bordo no se ha enterado de la reprogramación del software de inyección y por tanto sigue teniendo "algunos" datos antiguos y algunos otros nuevos. En resumen, mi consumo medio es 0.1 litros/100km (al precio del gasoil es una ganga).
Pero bueno, es un caso muy raro, se puede tolerar, sin embargo hay otro problema que me da más que pensar: 2000 kilómetros antes de cambiar el aceite me avisa y justo cuando llega ese aviso el ordenador curiosamente corrige otro bug, este es de la máquina de estados que controla lo que se muestra en pantalla. Cuando me ha avisado siempre vuelve a la pantalla a la que estaba después de usar el regulador. Cuando pongo el regulador en la pantalla me muestra la velocidad y en su funcionamiento normal se queda fijo, sin embargo, como digo, después del aviso vuelve a mostrarme lo que tenía. Esto me dice dos cosas:
1.- Los que prueban y programan no saben el comportamiento que debe tener, de otra forma se hubiesen dado cuenta de lo que tenía que pasar.
2.- No usan ningún tipo de test y si lo hacen no tienen un informe de cobertura de test. En caso de que lo usaran podría haber detectado rápidamente que el caso de funcionamiento con aviso de ir al taller estaba testeado. Un artículo referente a esto en el blog de testing de google.
No quiero ni decir nada acerca de algún que otro código que he visto que controla ciertas transacciones con tarjetas de crédito, ahora me da miedo real pagar con tarjeta de crédito.
Para cuando un coche donde dejen el código fuente abierto y cada uno podamos programarnos nuestro software a medida ? :D Hay gente que hace hacks (con arduino por cierto), pero no lo veo muy claro
pd: la imagen está tomada de la wikipedia en inglés
5.22.2008
Manual rápido de programación con GPS
Hace tiempo que tenía ganas de poner un post de este tipo, así que vamos allá. Pongamos que no sabes lo que es GPS y quieres hacer una aplicación que necesite saber donde estás, estás en el sitio correcto, voy a tratar de enumerar lo que necesitas saber de forma clara y concisa:
- Qué es GPS: es un sistema que permite saber en qué posición del globo estás situado
- En qué se basa: Hay una serie de satélites orbitando que emiten señales, el receptor las interpreta y gracias a triangulación determina tu posición
- Necesito saber triangular: no, el receptor hace todo por tí, olvida a doppler, trigonometría, etc :)
- qué información da el GPS: te da la posición gracias a la latitud y longitud, esto es, lo hace en coordenadas polares. Además el GPS da mucho más información...
- Cómo me da la información el GPS: usa NMEA, un protocolo de texto separado por comas donde viene la información bien clarita.
- Cómo recojo la información del GPS: pues normalmente a través de puerto serie... "pero mi receptor GPS es bluetooth", no te preocupes, tu bluetooth se comportará como un puerto serie.
- Cómo uso la información desde mi aplicación: abres el puerto y vas leyendo linea a linea los datos NMEA, extraes la información y la usas, por ejemplo, para poner un punto en un mapa.
- Las coordenadas polares no son útiles para mi: lógico, estamos acostumbrados a trabajar en coordenadas cartesianas (el plano XY de toda la vida). Alguien ya pensó en eso e inventó UTM, que no es más que un sistema para proyectar latitud y longitud a nuestro querido plano castesiano. En resumen, al final tendremos X e Y y con eso es muy fácil empezar a trabajar
- Ya, dicho así es fácil, pero cómo lo hago en la realidad?. Lo primero es tener un GPS, por ejemplo , como mi pc no tiene puerto serie uso un conversor USB->serie. De esta forma ya puedo acceder al GPS... cómo? pues con python y los siguientes pasos:
- instalo python
- instalo Python for Windows extensions si estoy en windows
- instalo pyserial que nos da acceso al pueto serie.
- instalo pygps: este hará el trabajo de interpretar NMEA y proyectar a UTM por nosotros
- abro el editor y programo:
import serial;
from threading import Thread;
from NMEA import NMEA;
from LatLongUTMconversion import LLtoUTM;
class GPSPosition(Thread):
def __init__(self, callback):
Thread.__init__(self);
#serial conf
s = serial.Serial()
s.baudrate = 4800
s.port = "COM1"
s.open();
self.serial = s
self.nmea = NMEA();
self.callback = callback
self._run = 1;
self.start();
def end(self):
self._run = 0;
def run(self):
while self._run:
nmea_data = self.serial.readline();
self.nmea.handle_line(nmea_data);
zone, easting, northing = LLtoUTM(23, self.nmea.lat, self.nmea.lon)
self.pos = (easting, northing);
self.callback(self.nmea.lat, self.nmea.lon, self.pos, self.nmea.mode > 0);
if __name__ == '__main__':
def position(lat, lon, pos, valid_pos):
if(valid_pos):
print "current position", pos, "lat: ", lat, " lon:", lon;
else:
print "invalid position
gps = GPSPosition(position);
ejecuto:
- qué es posición inválida? Pues resulta que un GPS no sabe su posición nada más conectarse, necesita un tiempo (que depende de muchas cosas) para tener una posición válida.
- Lo hago y no me funciona: sal a la calle porque en casa el GPS no es capaz de coger señal de satélite dentro de casa!!
- No me da bien la posición: Lo habitual son 10 metros de error como mucho, normalmente está entre los 2 o 3 metros.
- Lo hago pero me oscilan las posiciones: en GPS es bueno pero milagros no hace.
Fin, espero no haberme dejado nada.
- Qué es GPS: es un sistema que permite saber en qué posición del globo estás situado
- En qué se basa: Hay una serie de satélites orbitando que emiten señales, el receptor las interpreta y gracias a triangulación determina tu posición
- Necesito saber triangular: no, el receptor hace todo por tí, olvida a doppler, trigonometría, etc :)
- qué información da el GPS: te da la posición gracias a la latitud y longitud, esto es, lo hace en coordenadas polares. Además el GPS da mucho más información...
- Cómo me da la información el GPS: usa NMEA, un protocolo de texto separado por comas donde viene la información bien clarita.
- Cómo recojo la información del GPS: pues normalmente a través de puerto serie... "pero mi receptor GPS es bluetooth", no te preocupes, tu bluetooth se comportará como un puerto serie.
- Cómo uso la información desde mi aplicación: abres el puerto y vas leyendo linea a linea los datos NMEA, extraes la información y la usas, por ejemplo, para poner un punto en un mapa.
- Las coordenadas polares no son útiles para mi: lógico, estamos acostumbrados a trabajar en coordenadas cartesianas (el plano XY de toda la vida). Alguien ya pensó en eso e inventó UTM, que no es más que un sistema para proyectar latitud y longitud a nuestro querido plano castesiano. En resumen, al final tendremos X e Y y con eso es muy fácil empezar a trabajar
- Ya, dicho así es fácil, pero cómo lo hago en la realidad?. Lo primero es tener un GPS, por ejemplo , como mi pc no tiene puerto serie uso un conversor USB->serie. De esta forma ya puedo acceder al GPS... cómo? pues con python y los siguientes pasos:
- instalo python
- instalo Python for Windows extensions si estoy en windows
- instalo pyserial que nos da acceso al pueto serie.
- instalo pygps: este hará el trabajo de interpretar NMEA y proyectar a UTM por nosotros
- abro el editor y programo:
import serial;
from threading import Thread;
from NMEA import NMEA;
from LatLongUTMconversion import LLtoUTM;
class GPSPosition(Thread):
def __init__(self, callback):
Thread.__init__(self);
#serial conf
s = serial.Serial()
s.baudrate = 4800
s.port = "COM1"
s.open();
self.serial = s
self.nmea = NMEA();
self.callback = callback
self._run = 1;
self.start();
def end(self):
self._run = 0;
def run(self):
while self._run:
nmea_data = self.serial.readline();
self.nmea.handle_line(nmea_data);
zone, easting, northing = LLtoUTM(23, self.nmea.lat, self.nmea.lon)
self.pos = (easting, northing);
self.callback(self.nmea.lat, self.nmea.lon, self.pos, self.nmea.mode > 0);
if __name__ == '__main__':
def position(lat, lon, pos, valid_pos):
if(valid_pos):
print "current position", pos, "lat: ", lat, " lon:", lon;
else:
print "invalid position
gps = GPSPosition(position);
ejecuto:
C:\temp>c:\Python25\python gps.py
invalid position
invalid position
current position: 314418.53, 4575413.58 lat: 41.31 lon: -5.22
current position: 314418.53, 4575413.58 lat: 41.31 lon: -5.22
current position: 314418.80, 4575413.20 lat: 41.31 lon: -5.22
- qué es posición inválida? Pues resulta que un GPS no sabe su posición nada más conectarse, necesita un tiempo (que depende de muchas cosas) para tener una posición válida.
- Lo hago y no me funciona: sal a la calle porque en casa el GPS no es capaz de coger señal de satélite dentro de casa!!
- No me da bien la posición: Lo habitual son 10 metros de error como mucho, normalmente está entre los 2 o 3 metros.
- Lo hago pero me oscilan las posiciones: en GPS es bueno pero milagros no hace.
Fin, espero no haberme dejado nada.
5.21.2008
falta de profesionalidad
Todos los días empresas nos prestan una serie de servicios a cambio de un dinero, sea de forma directa, voy a un bar, pido un café y pago al camarero, o de forma indirecta, voy por una autovía que se financia con los impuestos que pago. Detrás de esas empresas y servicios hay gente, personas y el trabajo de esas personas es lo que al final te llega: el camarero me sirve el café, el ingeniero diseña la carretera y el operario la cubre con asfalto, etc.
El problema es que en una empresa hay gente profesional y gente que no lo es y es es la diferencia entre que no te enteres de que te están prestando un servicio a estar quemado e indefenso.
Para mi un profesional _no_ es una persona que tenga mucha experiencia o conocimientos en un área o que haga muy bien tal o cual cosa, para mi ser un profesional es ser serio en el trabajo, cumplir con los plazos, tratar de mejorar cada día, hacer frente a los problemas y, sobretodo, hacerse responsable cuando las cosas no se hacen bien.
Últimamente veo como la profesionalidad cada vez es menor: los servicios técnicos pasan de ti cuando hay un problema, el fontanero tarda 4 días en venir a repararte el agua caliente, acuerdas un plazo y luego no se cumple, etc, etc... y lo peor, cobran con un verdadero profesional. Estoy harto de ver gente que está en su trabajo viendo pasar el tiempo para que lleguen las 3 de la tarde y saliendo del paso como pueden y con el menor esfuerzo posible, lo veo cada día.
Da gusto ver a una persona que es profesional, que le gusta su trabajo y que se preocupa, y aunque me cobre más, lo pago con gusto, solo por el hecho de que sé que ese dinero va para alguien que lo merece y por otro lado porque así estoy participando en una "selección natural".
No me extraña que las empresas cada vez busquen gente con "perfiles horizontales", ser serio es algo básico y la carencia de esa característa es mucho más problemática que la de conocimientos técnicos. Sabes que una persona profesional que tiene una responsabilidad va a esforzarse (o apechugar) para sacarlo, independientemente de si sus conocimientos sean bajos en esa materia. Saber J2EE, hibernate, structs, blablabla tiene un precio, poder confiar en que alguien va a tener algo en la fecha, sea lo que sea, no.
El problema es que en una empresa hay gente profesional y gente que no lo es y es es la diferencia entre que no te enteres de que te están prestando un servicio a estar quemado e indefenso.
Para mi un profesional _no_ es una persona que tenga mucha experiencia o conocimientos en un área o que haga muy bien tal o cual cosa, para mi ser un profesional es ser serio en el trabajo, cumplir con los plazos, tratar de mejorar cada día, hacer frente a los problemas y, sobretodo, hacerse responsable cuando las cosas no se hacen bien.
Últimamente veo como la profesionalidad cada vez es menor: los servicios técnicos pasan de ti cuando hay un problema, el fontanero tarda 4 días en venir a repararte el agua caliente, acuerdas un plazo y luego no se cumple, etc, etc... y lo peor, cobran con un verdadero profesional. Estoy harto de ver gente que está en su trabajo viendo pasar el tiempo para que lleguen las 3 de la tarde y saliendo del paso como pueden y con el menor esfuerzo posible, lo veo cada día.
Da gusto ver a una persona que es profesional, que le gusta su trabajo y que se preocupa, y aunque me cobre más, lo pago con gusto, solo por el hecho de que sé que ese dinero va para alguien que lo merece y por otro lado porque así estoy participando en una "selección natural".
No me extraña que las empresas cada vez busquen gente con "perfiles horizontales", ser serio es algo básico y la carencia de esa característa es mucho más problemática que la de conocimientos técnicos. Sabes que una persona profesional que tiene una responsabilidad va a esforzarse (o apechugar) para sacarlo, independientemente de si sus conocimientos sean bajos en esa materia. Saber J2EE, hibernate, structs, blablabla tiene un precio, poder confiar en que alguien va a tener algo en la fecha, sea lo que sea, no.
5.18.2008
intento de augmented reality
"Para quien tiene un martillo todo son clavos".
Esta mañana me he levantado pronto y como no tenía sueño y nada que hacer productivo en todo el día, he pensado en hacer algo con mi webcam (tranquilos, no salgo en ningún momento :). Hace unos días vi como con un gps, una webcam y una brújula gracias a google earth conseguían poner una capa por encima de la realidad con información la ubicación de diferentes cosas. El proyecto estaba hecho sobre android, en el enlace hay un video muy interesante. Tambien hace relativamente poco vi como un navegador proyectaba información sobre el parabrisas que indicaba qué calle debías coger (no encuentro el link). Con lo cual me planteé por qué no podría hacer lo mismo para agroguía, que el agricultor mirase la cámara y viese por donde había ya pasado superpuesto con la realidad.
En esta mañana he hecho un prototipo de augmented reality de forma que en la pantalla del PC se mostrase información de por donde ya había pasado mostrando la visión en ese momento del conductor unido a un capa generada que se lo indicase.
He cogido la webcam, un GPS, python y opengl y he preparado un prototipo. He colocado la webcam arriba en el coche (ver foto) junto al GPS de forma que a medida que el GPS me da información de posición con OpenGL renderizo las zonas por las que ya se ha pasado justo con la cámara en ese lugar.
La prueba no ha quedado demasiado mal teniendo en cuenta que es un prototipo rápido, un video:
Problemas:
- La resolución de la cámara es malísima.
- El GPS lleva retardo, de ahí que no estén sincronizados
- No he calibrado la cámara adecuadamente, la he puesto a ojo, un fov e inclinación más o menos parecida a la de la webcam
Mañana voy a probar con un GPS de 5hz y con menos retardo, además intentaré ajustar mejor la cámara.
Esta mañana me he levantado pronto y como no tenía sueño y nada que hacer productivo en todo el día, he pensado en hacer algo con mi webcam (tranquilos, no salgo en ningún momento :). Hace unos días vi como con un gps, una webcam y una brújula gracias a google earth conseguían poner una capa por encima de la realidad con información la ubicación de diferentes cosas. El proyecto estaba hecho sobre android, en el enlace hay un video muy interesante. Tambien hace relativamente poco vi como un navegador proyectaba información sobre el parabrisas que indicaba qué calle debías coger (no encuentro el link). Con lo cual me planteé por qué no podría hacer lo mismo para agroguía, que el agricultor mirase la cámara y viese por donde había ya pasado superpuesto con la realidad.
En esta mañana he hecho un prototipo de augmented reality de forma que en la pantalla del PC se mostrase información de por donde ya había pasado mostrando la visión en ese momento del conductor unido a un capa generada que se lo indicase.
He cogido la webcam, un GPS, python y opengl y he preparado un prototipo. He colocado la webcam arriba en el coche (ver foto) junto al GPS de forma que a medida que el GPS me da información de posición con OpenGL renderizo las zonas por las que ya se ha pasado justo con la cámara en ese lugar.
La prueba no ha quedado demasiado mal teniendo en cuenta que es un prototipo rápido, un video:
Problemas:
- La resolución de la cámara es malísima.
- El GPS lleva retardo, de ahí que no estén sincronizados
- No he calibrado la cámara adecuadamente, la he puesto a ojo, un fov e inclinación más o menos parecida a la de la webcam
Mañana voy a probar con un GPS de 5hz y con menos retardo, además intentaré ajustar mejor la cámara.
5.11.2008
Cube modeling challenge
Este fin de semana están haciendo un concurso de modelado solo con cubos. A priori parece que con pocos cubos no se puede hacer demasiado, sin embargo merece la pena entrar y ver las imágenes.
Por mi parte me he animado y he hecho una (lo primero que "modelo" en mi vida)
si, es triste y oscura.
Por mi parte me he animado y he hecho una (lo primero que "modelo" en mi vida)
si, es triste y oscura.
5.04.2008
cosas que pasan: MGS mobile
Me bajo metal gear acid mobile, la versión 3D para probarla en mi móvil y así saber si los shots que había visto hace ya meses eran verdad y el juego prometía tanto, lo paso al móvil y después de defraudarme miserablemente (por ahora, no me gustan los juegos por turnos) me dispongo a decompilarlo para ver un poco qué hacían.
ejecuto:
"""
C:\temp\metal_gear_acid_mobile_3d_n70\src>java -cp jode.jar;C:\WTK22\lib\cldcapi10.jar;C:\WTK22\lib\midpapi20.jar;C:\SonyEricsson\JavaME_SDK_CLDC\PC_Emulation\WTK2\lib\mobile3d.jar;C:\WTK22\lib\mmapi.jar jode.decompiler.Main --dest src meta l_gear_acid_mobile_3d_n70.jar
"""
y cual es mi sorpresa que no está ofuscado!. Ahí está, el código del juego completito, salvo métodos que están, parece ofuscados, todo el resto de cosas se pueden ver perfectamente. Ahi está, todo el código de 3D, su A* (ver AStarSearchpor ejemplo), la animación a la antigua usanza (quake2 style pero sin interpolar) de Snake (ver JSR184_LoadSnake).
Soy fan de decompilar juegos para móvil, es divertidísimo intentar saber qué están haciendo sin ver ni una sola variable (normalmente todo se llama 'a') o ver los formatos de fichero que usan o como cargan las imágenes. Por ahora lo que más he visto ha sido lo de empaquetar recursos y "xorear" parte de los datos, "swapear" el comienzo y fin del fichero (ves cosas como "GNP" de la cabecera de los png)... aunque luego tienes casos como gameloft del cual aún no he conseguido ver como lo hacen, es demasiado difícil de descifrar para un rato.
Si algo bueno tiene java (de lo poco) es que se puede decompilar y mirar dentro.
ejecuto:
"""
C:\temp\metal_gear_acid_mobile_3d_n70\src>java -cp jode.jar;C:\WTK22\lib\cldcapi10.jar;C:\WTK22\lib\midpapi20.jar;C:\SonyEricsson\JavaME_SDK_CLDC\PC_Emulation\WTK2\lib\mobile3d.jar;C:\WTK22\lib\mmapi.jar jode.decompiler.Main --dest src meta l_gear_acid_mobile_3d_n70.jar
"""
y cual es mi sorpresa que no está ofuscado!. Ahí está, el código del juego completito, salvo métodos que están, parece ofuscados, todo el resto de cosas se pueden ver perfectamente. Ahi está, todo el código de 3D, su A* (ver AStarSearchpor ejemplo), la animación a la antigua usanza (quake2 style pero sin interpolar) de Snake (ver JSR184_LoadSnake).
Soy fan de decompilar juegos para móvil, es divertidísimo intentar saber qué están haciendo sin ver ni una sola variable (normalmente todo se llama 'a') o ver los formatos de fichero que usan o como cargan las imágenes. Por ahora lo que más he visto ha sido lo de empaquetar recursos y "xorear" parte de los datos, "swapear" el comienzo y fin del fichero (ves cosas como "GNP" de la cabecera de los png)... aunque luego tienes casos como gameloft del cual aún no he conseguido ver como lo hacen, es demasiado difícil de descifrar para un rato.
Si algo bueno tiene java (de lo poco) es que se puede decompilar y mirar dentro.
5.02.2008
KML y la privacidad
Este post pretender ser dos cosas: primero un pequeño manual de como hacer un servidor de KML con python y cherrypy y segundo demostrar qué se puede hacer para recibir feedback indiscriminado usando lo anterior.
Conocimientos previos:
- cherrypy es un API que permite implementar una aplicación web en dos patadas
- KML es un formato usando principalmente por Google Earth que sirve como contenedor de información geográfica, puntos de interés, etc, etc
KML no deja de ser un xml (*sic*) en el cual cabe de todo puntos, líneas, elementos 3D, animaciones y lo que nos interesa, conexiones a un servidor para obtener datos enumrados anteriormente. De esta forma es posible indicarle en un enlace que vaya a un servidor a buscar datos. Hay un pequeño pero efectivo tutorial en la página del api de google earth.
Tomando ese ejemplo creamos el servidor con cherrypy:
import cherrypy
class Root:
def get_kml(self, latitude, longitude):
kml = (
'<?xml version="1.0" encoding="UTF-8"?>\n'
'<kml xmlns="http://earth.google.com/kml/2.2">\n'
'<Placemark>\n'
'<name>Random Placemark</name>\n'
'<Point>\n'
'<coordinates>%f,%f</coordinates>\n'
'</Point>\n'
'</Placemark>\n'
'</kml>'
) %(longitude, latitude)
return kml
def index(self, directory="."):
cherrypy.response.headers["Content-Type"] = "application/vnd.google-earth.kml+xml"
return self.get_kml(-3.332565,42.600353);
index.exposed = True
if __name__ == '__main__':
root = Root()
cherrypy.quickstart(root);
El tema web no me va, pero estaba interesado en saber como va este tema en python. Me da la impresión que aún está por detrás de Ruby. He estado mirando turbogears y la verdad me ha gustado.
En el tutorial ponen un ejemplo de KML que se conecta a un servidor, podríamos cambiar la sentencia Link por lo siguiente:
<link>
<href>http://localhost:8080/</href>
</link>
De esta forma al cargar ese fichero en google earth se conectaría al servidor y bajaría kml.
Ahora la segunda parte: qué pasa si ese kml es generado por una aplicación y el usuario lo carga en su google earth. Pongamos, por ejemplo, un software de guiado para maquinaria agrícola, en el cual después de haber trabajado se puede guardar ese trabajo a KML para poder verlo más tarde en el PC. Pongamos que ese software escribe algo así dentro del fichero kml:
Gracias al número de licencia conoces al usuario y con latitud y longitud conoces la localización de sus parcelas. Eso por no hablar que con unos pocos bytes se puede enviar _de todo_. Tiene su parte mala, pero también su parte buena, se le pueden dar bastantes usos.
Por cierto, y no digo que tenga algo que ver, ya he implementado el writer para kml de agroguía :):
Conocimientos previos:
- cherrypy es un API que permite implementar una aplicación web en dos patadas
- KML es un formato usando principalmente por Google Earth que sirve como contenedor de información geográfica, puntos de interés, etc, etc
KML no deja de ser un xml (*sic*) en el cual cabe de todo puntos, líneas, elementos 3D, animaciones y lo que nos interesa, conexiones a un servidor para obtener datos enumrados anteriormente. De esta forma es posible indicarle en un enlace que vaya a un servidor a buscar datos. Hay un pequeño pero efectivo tutorial en la página del api de google earth.
Tomando ese ejemplo creamos el servidor con cherrypy:
import cherrypy
class Root:
def get_kml(self, latitude, longitude):
kml = (
'<?xml version="1.0" encoding="UTF-8"?>\n'
'<kml xmlns="http://earth.google.com/kml/2.2">\n'
'<Placemark>\n'
'<name>Random Placemark</name>\n'
'<Point>\n'
'<coordinates>%f,%f</coordinates>\n'
'</Point>\n'
'</Placemark>\n'
'</kml>'
) %(longitude, latitude)
return kml
def index(self, directory="."):
cherrypy.response.headers["Content-Type"] = "application/vnd.google-earth.kml+xml"
return self.get_kml(-3.332565,42.600353);
index.exposed = True
if __name__ == '__main__':
root = Root()
cherrypy.quickstart(root);
El tema web no me va, pero estaba interesado en saber como va este tema en python. Me da la impresión que aún está por detrás de Ruby. He estado mirando turbogears y la verdad me ha gustado.
En el tutorial ponen un ejemplo de KML que se conecta a un servidor, podríamos cambiar la sentencia Link por lo siguiente:
<link>
<href>http://localhost:8080/</href>
</link>
De esta forma al cargar ese fichero en google earth se conectaría al servidor y bajaría kml.
Ahora la segunda parte: qué pasa si ese kml es generado por una aplicación y el usuario lo carga en su google earth. Pongamos, por ejemplo, un software de guiado para maquinaria agrícola, en el cual después de haber trabajado se puede guardar ese trabajo a KML para poder verlo más tarde en el PC. Pongamos que ese software escribe algo así dentro del fichero kml:
<link>
<href>http://servidor.com/?license_no=1234&lat=-3.332565&lon=42.600353</href>
</link>
Gracias al número de licencia conoces al usuario y con latitud y longitud conoces la localización de sus parcelas. Eso por no hablar que con unos pocos bytes se puede enviar _de todo_. Tiene su parte mala, pero también su parte buena, se le pueden dar bastantes usos.
Por cierto, y no digo que tenga algo que ver, ya he implementado el writer para kml de agroguía :):
4.27.2008
partes de un negocio: El negociador
Mañana he quedado con una empresa Argentina que está interesada en agroguía. Veremos a ver por donde salimos :).
4.24.2008
Python, generators y pipes
Para rematar el artículo del otro día sobre generators en python conviene leerse este otro sobre Pipelined Python que no deja de ser syntactic sugar (como diría alguno), pero queda la mar de c00l.
4.21.2008
Partes de un negocio: cuando te caen piedras encima
Hoy me ha pasado una cosa muy curiosa. Hace cosa de unos meses le vendí un sistema de guiado a una persona, cercana a mi pueblo y que llevaba tiempo detrás de ello. Después de meses intentando que le rebajase el precio y tras repetirle mil veces que es precio único, accedió a comprarmelo al precio original. Se hizo una factura desglosando los conceptos y pasó al circuíto habitual (esto es, a pachas con hacienda)
Hoy me llama completamente fuera de si, insultándome y llamándome estafador ¿?. En cosa de dos minutos ha dijo todos los improperios que conocía y alguno más, tras lo cual colgó. En ese momento te preguntas, ¿realmente le habré estafado? porque lo mismo no me he dado cuenta y no le he enviado el sistema... pero es que fui yo con mis propias manos a instalarlo.
Lógicamente estaba fuera de sí, en persona parecía una persona amable, así que minutos después le llamé para intentar aclarar las cosas. En esa llamada ya me insultó menos :), aunque mantenía que le había estafado 40€, con pocos argumentos, la verdad. Suerte de facturas, mañana he quedado con él para enseñarle la factura, ver qué ha pasado y dar la cara, cosa que cada vez tengo que hacer más, para bien o para mal.
Obviamente, lo primero que espero mañana son unas disculpas, si no es así daré por finalizada la relación con esta persona y listo. Ahora pasa que por un individuo encolerado puede que el boca a boca que tanto nos ha ayudado hasta ahora deje de funcionar tan bien como lo ha hecho. No me preocupa mucho, pero molesta que a pesar de esforzarte en hacer las cosas lo mejor posible haya gente que lo pague con malos modos y amenazas.
Cada día tengo más claro que la mayoría de las veces, ante situaciones de este tipo lo mejor es dar la callada por respuesta y mantenerse firme, sobretodo cuando se sabe con cierto grado de seguridad que se tiene la razón. Es muy común la creencia de que "montando el pollo" puedes solcionar algo que no puedes usando argumentos... como dice un refrán que yo me sé: "ante el vicio de pedir ... la virtud de no dar" (como me gusta el refranero)
Hoy me llama completamente fuera de si, insultándome y llamándome estafador ¿?. En cosa de dos minutos ha dijo todos los improperios que conocía y alguno más, tras lo cual colgó. En ese momento te preguntas, ¿realmente le habré estafado? porque lo mismo no me he dado cuenta y no le he enviado el sistema... pero es que fui yo con mis propias manos a instalarlo.
Lógicamente estaba fuera de sí, en persona parecía una persona amable, así que minutos después le llamé para intentar aclarar las cosas. En esa llamada ya me insultó menos :), aunque mantenía que le había estafado 40€, con pocos argumentos, la verdad. Suerte de facturas, mañana he quedado con él para enseñarle la factura, ver qué ha pasado y dar la cara, cosa que cada vez tengo que hacer más, para bien o para mal.
Obviamente, lo primero que espero mañana son unas disculpas, si no es así daré por finalizada la relación con esta persona y listo. Ahora pasa que por un individuo encolerado puede que el boca a boca que tanto nos ha ayudado hasta ahora deje de funcionar tan bien como lo ha hecho. No me preocupa mucho, pero molesta que a pesar de esforzarte en hacer las cosas lo mejor posible haya gente que lo pague con malos modos y amenazas.
Cada día tengo más claro que la mayoría de las veces, ante situaciones de este tipo lo mejor es dar la callada por respuesta y mantenerse firme, sobretodo cuando se sabe con cierto grado de seguridad que se tiene la razón. Es muy común la creencia de que "montando el pollo" puedes solcionar algo que no puedes usando argumentos... como dice un refrán que yo me sé: "ante el vicio de pedir ... la virtud de no dar" (como me gusta el refranero)
4.20.2008
¿qué responderías a esta pregunta?
Hace un tiempo hablando con el padre de unos amigos, que se puede considerar como el típico emprendedor nato (y además con éxito), sobre las entrevistas de trabajo, me dijo que él al final de cada entrevista de trabajo hacía una pregunta al candidato:
""" ¿ por qué crees que mereces más este puesto que el resto de personas ? """
Suena a pregunta trampa, mi impresión es que no tiene una respuesta válida absoluta, seguramente dependa del entrevistador. Le pregunté que qué esperaba que le respondiesen y me dijo que no esperaba nada, que solo lo usaba para ver la reacción del individuo.
¿qué responderías? ¿qué responderías sin parecer prepotente? ¿y sin parecer que no tienes ni idea? :)
""" ¿ por qué crees que mereces más este puesto que el resto de personas ? """
Suena a pregunta trampa, mi impresión es que no tiene una respuesta válida absoluta, seguramente dependa del entrevistador. Le pregunté que qué esperaba que le respondiesen y me dijo que no esperaba nada, que solo lo usaba para ver la reacción del individuo.
¿qué responderías? ¿qué responderías sin parecer prepotente? ¿y sin parecer que no tienes ni idea? :)
4.17.2008
generators en python
A través de planet python veo una presentación sobre el uso de generators en python. Explica desde lo más básico hasta frikadas insospechadas, merece la pena leerlo, muy ameno e instructivo. No sé, la verdad, si tendrá mucha utilidad real para casos más complejos, pero ahí queda.
4.14.2008
¿Nos viene bien la crisis?
Asisto con curiosidad a la llegada de la esperada crisis, las inmobiliarias cierran las puertas (eso sí, con los bolsillos hasta arriba) y todo el mundo a la espera de ver que pasa.
Entre cifras de IPC, paro y PIB ya se empiezan a escuchar cosas de sentido común, tenemos que ponernos las pilas en tecnología y no depender tanto de la contrucción. Y ojo, no lo digo yo, lo dicen los analistas políticos (esos de las tertulias todo serias de la radio) e incuso los propios políticos. Es tarde, ya la hemos cagado, pero más vale tarde que nunca, llevamos tiempo viendo como el sector va mejorando, se ven mejoras sueldos (algunos informáticos incluso llevan coches de primera mano :), se valoran más algunos puestos, imagino que el dinero que ha salido de la construcción ha ido migrando a otros sectores.
Esperemos que no haya otra burbuja .com (esta se llamaría, burbuja 2.0 o burbuja social) y nos, hablando en plata, joda vivos. Sea como sea algo positivo seguro que sacamos, porque no creo que podamos estar peor de lo que hemos estado.
Entre cifras de IPC, paro y PIB ya se empiezan a escuchar cosas de sentido común, tenemos que ponernos las pilas en tecnología y no depender tanto de la contrucción. Y ojo, no lo digo yo, lo dicen los analistas políticos (esos de las tertulias todo serias de la radio) e incuso los propios políticos. Es tarde, ya la hemos cagado, pero más vale tarde que nunca, llevamos tiempo viendo como el sector va mejorando, se ven mejoras sueldos (algunos informáticos incluso llevan coches de primera mano :), se valoran más algunos puestos, imagino que el dinero que ha salido de la construcción ha ido migrando a otros sectores.
Esperemos que no haya otra burbuja .com (esta se llamaría, burbuja 2.0 o burbuja social) y nos, hablando en plata, joda vivos. Sea como sea algo positivo seguro que sacamos, porque no creo que podamos estar peor de lo que hemos estado.
4.13.2008
El peligro de las 100 tareas
Toda la vida he creído en los refranes populares, son la experiencia plasmada en frases contundentes y fáciles de recordar. Quien no ha oido alguna vez lo de "perro ladrador...", "más vale pájaro en mano..." y lo mejor (o peor, según se mire) quien no se ha tenido que aplicar algunos de ellos más de una vez.
El refrán de hoy es "el que mucho abarca, poco aprieta". Cada vez que reviso los feeds a los que esoy suscrito encuentro todos los días varios temas por los cuales estoy interesado, cada uno diferente, sin ir más lejor en esta misma tarde he encontrado varias cosas interesantes, para empezar un una serie de utilidades para la gestión de ramas en subversion(a raíz de leer este meme) o un hilo interesantísimo sobre gps diferencial usando GPS de bajo coste en gpspassion, el uso que hacen los agricultores de agroguía y como están creados los niveles del starfox64 ... :).
(viva blender):
(ha quedado chula la foto):
Total, que al final he mirado 4 ó 5 cosas, pero tengo la sensación de que no he sacado nada en claro, nada más que he curioseado. Me gustaría dejar a un lado algunas de las cosas, pero no puedo!!. Mirando hacia atrás (que bonita es la trazabilidad) me doy cuenta que mejoro en cada uno de los aspectos, pero mi rendimiento es menor porque me cargo de más tareas (será por aquello de los cambios de contexto).
Conclusión: qué importante es tener claro lo que uno quiere (y puede) hacer y cuanto de bien tiene poder escribirlo para aclarar las ideas.
El refrán de hoy es "el que mucho abarca, poco aprieta". Cada vez que reviso los feeds a los que esoy suscrito encuentro todos los días varios temas por los cuales estoy interesado, cada uno diferente, sin ir más lejor en esta misma tarde he encontrado varias cosas interesantes, para empezar un una serie de utilidades para la gestión de ramas en subversion(a raíz de leer este meme) o un hilo interesantísimo sobre gps diferencial usando GPS de bajo coste en gpspassion, el uso que hacen los agricultores de agroguía y como están creados los niveles del starfox64 ... :).
(viva blender):
(ha quedado chula la foto):
Total, que al final he mirado 4 ó 5 cosas, pero tengo la sensación de que no he sacado nada en claro, nada más que he curioseado. Me gustaría dejar a un lado algunas de las cosas, pero no puedo!!. Mirando hacia atrás (que bonita es la trazabilidad) me doy cuenta que mejoro en cada uno de los aspectos, pero mi rendimiento es menor porque me cargo de más tareas (será por aquello de los cambios de contexto).
Conclusión: qué importante es tener claro lo que uno quiere (y puede) hacer y cuanto de bien tiene poder escribirlo para aclarar las ideas.
4.05.2008
El infinito no es demasiado grande
Cuando desarrollas por narices tienes que poner un límite, por desgracia aún no tenemos máquinas con memoria infinita (aunque en pyro digan lo contrario :P). En agroguía había puesto un límite de área de 128x128km, espacio, a priori, mucho más que suficiente para cualquier agricultor, incluso para agricultores en argentina que tienen grandes extensiones.
Ayer me llamó un agricultor comentándome que tenía problemas y después de hacerle unas cuantas preguntas le pregunté que cuanto había andado desde que inició el programa, la respuesta soprendente (era jueves):
""" pues lleva encendido desde el jueves pasado, entonces habré andado unos 200km"""
Esto es todo un record, 1 semana el software cogiendo un dato por segundo y aún no había cascado.
Moraleja: nunca creas que el límite supeior es suficientemente grande.
Ayer me llamó un agricultor comentándome que tenía problemas y después de hacerle unas cuantas preguntas le pregunté que cuanto había andado desde que inició el programa, la respuesta soprendente (era jueves):
""" pues lleva encendido desde el jueves pasado, entonces habré andado unos 200km"""
Esto es todo un record, 1 semana el software cogiendo un dato por segundo y aún no había cascado.
Moraleja: nunca creas que el límite supeior es suficientemente grande.
4.01.2008
Diseño de un motor 3D moderno
Sé que muchos de los que leeis estas líneas tambien lo haceis con codepixel (y si no es un buen momento para empezar). El caso que han empezado con una serie de artículos sobre el diseño de un motor 3D moderno y no podía dejar pasar la ocasión de linkar, por lo interesante del artículo y por la calidad de los 3 autores.
No me gusta poner post de solo links, pero creo que este merece la pena. De momento ya han publicado el primero de una serie, y es una pequeña introducción que en resumen ha dejado claro que el modelo de datos debe ser bueno (como en toda aplicación). Estaré atento al resto de artículos.
No me gusta poner post de solo links, pero creo que este merece la pena. De momento ya han publicado el primero de una serie, y es una pequeña introducción que en resumen ha dejado claro que el modelo de datos debe ser bueno (como en toda aplicación). Estaré atento al resto de artículos.
3.30.2008
Re: Advergaming: Amor y odio
Leo en el blog de juanma zarza (aka mrkoala) una reflexión bastante interesante acerca del advergaming y su fama entre el público en general.
Y es que es muy raro que nadie se fije en uno de esos juegos "cutres" que publicitan una marca se vean en ninguna parte. Es cierto que hay mucha mierda y es cierto que muchos juegos móvil no tienen suficiente calidad. Eso sí, vemos a diario rumores sobre posibles juegos de EA o de gameloft (veer anaitgames, por poner un ejemplo) que sí, son unas super potencias en cuanto a juegos para móvil, pero que en mi opinión están super-valoradas, y pongo un ejemplo.[Y no quiero no hablar de la calidad de muchos de los juegos de nintendo DS (sobretodo) que se analizan...]
El ejemplo es uno de los últimos juegos de unkasoft en el que he participado directamente, que nadie conoce, pero que ya está por ahí. Se trata de una promoción llamada idrinks para diferentes bebidas alcohólicas. Bien, el juego está desarrollado en unos 8 días reales (en medio estuvo la navidad), esto es, desde 0 se crea un juego, gráficos, código y música... y todo eso para 450 móviles. Ahora pregunto, tiene eso menos mérito que crear un juegazo en 8 meses como hace gameloft? en 8 meses el equipo de unkasoft (en los juegos todos ponemos nuestro grano de arena) ha creado unos juegos de una calidad muy alta para los tiempos de desarrollo en los que nos movemos. Es tanta la diferencia?
¿Qué pasa? pues que somos así, tanto los que crean las noticias, como quienes las escriben. Muy poco se han preocupado los blogs o portales de noticias españolas por unkasoft (y otras muchas que trabajan en la sombra), a pesar de que los juegos que se hagan sean de una calidad altísima (sobretodo últimamente) incluso con licencias de películas que han estado en taquilla (rec, donkey xote), etc, etc. Eso sí, unkasoft tampoco puede/quiere/tiene tiempo de darle un poco más de bombo y publicitar un poco más los juegos que hace... a veces los NDA hacen un flaco favor a una empresa.
Me queda el consuelo de ver como cada día vamos mejorando nuestros juegos (a algunos puedes jugar gratis en unkasoft gamespace), sobretodo viendo los bocetos y desarrollos que tenemos actualmente en recamara.
Más vale pájaro en mano que ciento volando: Menos rumores de iphone y más noticias de verdad.
Y es que es muy raro que nadie se fije en uno de esos juegos "cutres" que publicitan una marca se vean en ninguna parte. Es cierto que hay mucha mierda y es cierto que muchos juegos móvil no tienen suficiente calidad. Eso sí, vemos a diario rumores sobre posibles juegos de EA o de gameloft (veer anaitgames, por poner un ejemplo) que sí, son unas super potencias en cuanto a juegos para móvil, pero que en mi opinión están super-valoradas, y pongo un ejemplo.[Y no quiero no hablar de la calidad de muchos de los juegos de nintendo DS (sobretodo) que se analizan...]
El ejemplo es uno de los últimos juegos de unkasoft en el que he participado directamente, que nadie conoce, pero que ya está por ahí. Se trata de una promoción llamada idrinks para diferentes bebidas alcohólicas. Bien, el juego está desarrollado en unos 8 días reales (en medio estuvo la navidad), esto es, desde 0 se crea un juego, gráficos, código y música... y todo eso para 450 móviles. Ahora pregunto, tiene eso menos mérito que crear un juegazo en 8 meses como hace gameloft? en 8 meses el equipo de unkasoft (en los juegos todos ponemos nuestro grano de arena) ha creado unos juegos de una calidad muy alta para los tiempos de desarrollo en los que nos movemos. Es tanta la diferencia?
¿Qué pasa? pues que somos así, tanto los que crean las noticias, como quienes las escriben. Muy poco se han preocupado los blogs o portales de noticias españolas por unkasoft (y otras muchas que trabajan en la sombra), a pesar de que los juegos que se hagan sean de una calidad altísima (sobretodo últimamente) incluso con licencias de películas que han estado en taquilla (rec, donkey xote), etc, etc. Eso sí, unkasoft tampoco puede/quiere/tiene tiempo de darle un poco más de bombo y publicitar un poco más los juegos que hace... a veces los NDA hacen un flaco favor a una empresa.
Me queda el consuelo de ver como cada día vamos mejorando nuestros juegos (a algunos puedes jugar gratis en unkasoft gamespace), sobretodo viendo los bocetos y desarrollos que tenemos actualmente en recamara.
Más vale pájaro en mano que ciento volando: Menos rumores de iphone y más noticias de verdad.
3.29.2008
Serializando en C++: implementación quick and dirty
Si hay una cosa que me molesta es tener que repetir código o funcionalidad. Cuando estás programando te das cuenta que a veces hay partes de funcionalidad que hacen más o menos lo mismo.
Hay veces que tienes que implementar algo y cuando lo haces por gusto pues puedes pararte a implementar un mega sistema de serialización que te mueres, pero cuando tienes que hacer algo que sabes que no va a salir de ahí nunca te da igual la orientación a objetos. Esta es una lucha que siempre he tenido con mucha gente, el sobrediseño, el sobre*, es decir, la tendencia a tener que aplicar los patronos existentes, la necesidad de usar una metología o un paradigma concreto, pero eso es otra historia.
Necesitaba guardar y cargar datos y no me apetecía andar modificando el loader cada vez que modificase el writer... así que (formato patrocinado por vim):
#include
<stdio.h>
class A
{
public:
int a;
int b;
float c;
typedef unsigned int (*serialize_t)(void*, unsigned int, unsigned int, FILE* f);
void Save(FILE* f)
{
Serialize(f, (serialize_t)fwrite);
}
void Load(FILE* f)
{
Serialize(f, fread);
}
virtual void Serialize(FILE* f, serialize_t ser)
{
#define SER(x) ser(&(x), sizeof(x), 1, f)
SER(a);
SER(b);
SER(c);
}
};
int main()
{
const char* fn = "test.bin";
FILE* f = fopen(fn, "wb");
A a;
a.a = 11;
a.b = 22;
a.c = 33.33f;
a.Save(f);
fclose(f);
A c;
f = fopen(fn, "rb");
c.Load(f);
printf("a: %d, b %d, c %f\n", c.a, c.b,c.c);
fclose(f);
return 0;
}
guarro, poco elegante, rompe todos los paradigmas, pero rápido, funcional y efectivo :D
Hay veces que tienes que implementar algo y cuando lo haces por gusto pues puedes pararte a implementar un mega sistema de serialización que te mueres, pero cuando tienes que hacer algo que sabes que no va a salir de ahí nunca te da igual la orientación a objetos. Esta es una lucha que siempre he tenido con mucha gente, el sobrediseño, el sobre*, es decir, la tendencia a tener que aplicar los patronos existentes, la necesidad de usar una metología o un paradigma concreto, pero eso es otra historia.
Necesitaba guardar y cargar datos y no me apetecía andar modificando el loader cada vez que modificase el writer... así que (formato patrocinado por vim):
#include
<stdio.h>
class A
{
public:
int a;
int b;
float c;
typedef unsigned int (*serialize_t)(void*, unsigned int, unsigned int, FILE* f);
void Save(FILE* f)
{
Serialize(f, (serialize_t)fwrite);
}
void Load(FILE* f)
{
Serialize(f, fread);
}
virtual void Serialize(FILE* f, serialize_t ser)
{
#define SER(x) ser(&(x), sizeof(x), 1, f)
SER(a);
SER(b);
SER(c);
}
};
int main()
{
const char* fn = "test.bin";
FILE* f = fopen(fn, "wb");
A a;
a.a = 11;
a.b = 22;
a.c = 33.33f;
a.Save(f);
fclose(f);
A c;
f = fopen(fn, "rb");
c.Load(f);
printf("a: %d, b %d, c %f\n", c.a, c.b,c.c);
fclose(f);
return 0;
}
guarro, poco elegante, rompe todos los paradigmas, pero rápido, funcional y efectivo :D
3.26.2008
agroguía 2.0
Sí, ahora que estamos con la fiebre de la 2.0, de la web social, de facebook, de twitter y de todas esas cosas para las que todavía no he encontrado utilidad, resulta que ahora los usuarios de agroguía generan y suben su propio contenido a la web.
Nosotros frecuentemente subimos videos para tener a la gente interesada y "enganchada" en cierto modo. Hay uqe tener en cuenta que el target de usuarios de esta aplicación no soy muy dados a las nuevas tecnologías (aunque más de lo que se cree y me creía debo decir. Resulta que buscando un poco por youtube sobre sistemas similares me encuentro con que un cliente nuestro se ha grabado en video usando agroguía y lo ha subido... :).
Estyo terminando algunas de las nuevas features de agroguía, en unos días subiré unos videos mostrando como funcionan... eso siempre que sea capaz de hablar despacio, no hay nada peor que grabarse y comprobar que lo que te han repetido durante años es verdad, hablo a toda leche, me como palabras y me explico mal :).
Ya lo estoy viendo, de aquí a un año los agricultores subiendo sus parcelas, con sus tiempos, sus rendimientos, intentando estar en el top10 :)
Nosotros frecuentemente subimos videos para tener a la gente interesada y "enganchada" en cierto modo. Hay uqe tener en cuenta que el target de usuarios de esta aplicación no soy muy dados a las nuevas tecnologías (aunque más de lo que se cree y me creía debo decir. Resulta que buscando un poco por youtube sobre sistemas similares me encuentro con que un cliente nuestro se ha grabado en video usando agroguía y lo ha subido... :).
Estyo terminando algunas de las nuevas features de agroguía, en unos días subiré unos videos mostrando como funcionan... eso siempre que sea capaz de hablar despacio, no hay nada peor que grabarse y comprobar que lo que te han repetido durante años es verdad, hablo a toda leche, me como palabras y me explico mal :).
Ya lo estoy viendo, de aquí a un año los agricultores subiendo sus parcelas, con sus tiempos, sus rendimientos, intentando estar en el top10 :)
3.23.2008
clase transaccional en python
Después de unas "largas" vacaciones sin tocar el pc (apenas recuerdo donde están las teclas :) apetece leerse algún buen artículo, como por ejemplo uno de clases transaccionales en python.
Interesante artículo por varios motivos:
- La propia clase, personalmente creo que puede ser bastante útil, luego pongo un ejemplo
- El uso de introspection (o reflexion o como quiera que se llame) en python. Simple y efectivo
- La explicación, paso a paso, y el código final con sus test unitarios.
Este es el típico ejemplo de pequeña clase que se complica y que termina siendo un verdadero infierno si no se tienen claros los contratos. Personalmente he tenido muy malas experiencias con clases en teoría simples, pero que dado su uso intensivo terminan por matar una aplicación. Por ejemplo, una clase tan simple como un vector, que en resumen no dejan de ser 4 métodos, es usada en todo el código, seguramente por varias personas que no tendrán ni idea de como está implementada (con razón), de la cual se pueden sacar unas cuantas "condiciones de contorno" que pueden hacer que la aplicación fracase estrepitosamente ya que cada persona puede decir: "es que yo pensé que funcionaba así"
En cuanto a la clase transaccional, se me ocurre un uso muy práctico. Estamos acostumbrados a ver diálogos wizards y configururaciones en todas las aplicaciones. El usuario cambia valores, toquetea y al final pulsa sobre 'Ok' o sobre 'Cancel'. El planteamiento de la lógica del diálogo podría ser el siguiente:
- al comienzo del diálogo se hace una copia de los datos.
- se modifica la copia en función de los eventos de usuario
- si el usuario acepta, se vuelcan los cambios que están en la copia en los datos originales.
Queda mucho más elegante el siguiente funcionamiento:
- se modifican los datos (que implementan el modelo transacional) en función de los eventos de usuario.
- si el usuario cancela se hace rollback.
Pero es que además, con este modelo tenemos solucionado el típico undo que tantos quebraderos de cabeza da de forma "transparente" (de hecho implementa el típico patron memento). Si unes esto a una serialización como dios manda ya tienes solucionado medio modelo de datos de la aplicación :).
Eso sí, la clase tiene varios problemas, por lo menos dos que yo vea:
- si hay atributos muy pesados en 4 commits te has zumbado unos megas de ram y estos lenguajes dinámicos no son precisamente ahorradores en este aspecto
- a poco mal que hagas el modelo de datos habrá variables que no te interese, perdón, que no deban guardar el estado. Pasa exactamente lo mismo que con la serialización.
Interesante artículo por varios motivos:
- La propia clase, personalmente creo que puede ser bastante útil, luego pongo un ejemplo
- El uso de introspection (o reflexion o como quiera que se llame) en python. Simple y efectivo
- La explicación, paso a paso, y el código final con sus test unitarios.
Este es el típico ejemplo de pequeña clase que se complica y que termina siendo un verdadero infierno si no se tienen claros los contratos. Personalmente he tenido muy malas experiencias con clases en teoría simples, pero que dado su uso intensivo terminan por matar una aplicación. Por ejemplo, una clase tan simple como un vector, que en resumen no dejan de ser 4 métodos, es usada en todo el código, seguramente por varias personas que no tendrán ni idea de como está implementada (con razón), de la cual se pueden sacar unas cuantas "condiciones de contorno" que pueden hacer que la aplicación fracase estrepitosamente ya que cada persona puede decir: "es que yo pensé que funcionaba así"
En cuanto a la clase transaccional, se me ocurre un uso muy práctico. Estamos acostumbrados a ver diálogos wizards y configururaciones en todas las aplicaciones. El usuario cambia valores, toquetea y al final pulsa sobre 'Ok' o sobre 'Cancel'. El planteamiento de la lógica del diálogo podría ser el siguiente:
- al comienzo del diálogo se hace una copia de los datos.
- se modifica la copia en función de los eventos de usuario
- si el usuario acepta, se vuelcan los cambios que están en la copia en los datos originales.
Queda mucho más elegante el siguiente funcionamiento:
- se modifican los datos (que implementan el modelo transacional) en función de los eventos de usuario.
- si el usuario cancela se hace rollback.
Pero es que además, con este modelo tenemos solucionado el típico undo que tantos quebraderos de cabeza da de forma "transparente" (de hecho implementa el típico patron memento). Si unes esto a una serialización como dios manda ya tienes solucionado medio modelo de datos de la aplicación :).
Eso sí, la clase tiene varios problemas, por lo menos dos que yo vea:
- si hay atributos muy pesados en 4 commits te has zumbado unos megas de ram y estos lenguajes dinámicos no son precisamente ahorradores en este aspecto
- a poco mal que hagas el modelo de datos habrá variables que no te interese, perdón, que no deban guardar el estado. Pasa exactamente lo mismo que con la serialización.
3.12.2008
Los aerogeneradores como faros
Lo bueno que tiene hacer de comercial es que a veces te encuentras con cosas curiosas. Resulta que el otro día fui a Barruelos del Valle (google maps) y curiosamente el agricultor interesado era el alcalde del pueblo. Charlando con él acerca de algunos temas técnicos, salió el tema de los aeorgeneradores aprovechando que al lado había un parque eólico y le pregunté para qué servían esas luces que tienen en la parte superior.
Resulta que cada molino tiene una luz que parpadea periódicamente y la verdad es que incluso a plena luz del día ya se veía con claridad. El chico me comentó que de noche era un verdadero infierno, que se hacía de día cada medio segundo... No me lo creía hasta que he podido comprobar que desde mi pueblo, a unos 50kms, (y más lejos) puedo ver las luces. Si pasas por la A-62 o la A-6 lo podrás ver desde bastante lejos.
Otra cosa que me llamó la atención es que las luces de los aerogeneradores están sincronizadas. Lógicamente nadie se gasta dinero en sincronizar las luces para nada. Según me comentaron, estas luces se usan como faros para loa aviones. Cada parque eolico tiene un periodo diferente, de forma que viendo los periodos es posible "triangular" y saber donde se está.
Una curiosidad técnica y un martirio para los habitantes cercanos al parque.
Resulta que cada molino tiene una luz que parpadea periódicamente y la verdad es que incluso a plena luz del día ya se veía con claridad. El chico me comentó que de noche era un verdadero infierno, que se hacía de día cada medio segundo... No me lo creía hasta que he podido comprobar que desde mi pueblo, a unos 50kms, (y más lejos) puedo ver las luces. Si pasas por la A-62 o la A-6 lo podrás ver desde bastante lejos.
Otra cosa que me llamó la atención es que las luces de los aerogeneradores están sincronizadas. Lógicamente nadie se gasta dinero en sincronizar las luces para nada. Según me comentaron, estas luces se usan como faros para loa aviones. Cada parque eolico tiene un periodo diferente, de forma que viendo los periodos es posible "triangular" y saber donde se está.
Una curiosidad técnica y un martirio para los habitantes cercanos al parque.
Suscribirse a:
Entradas (Atom)