Igual que han hecho mis ex-compañeros de trabajo juanma y félix (NSFW) voy a hacer un pequeño resumen de mi año 2008.
Lo primero es empezar viendo si los objetivos que me propuse a principio de año han sido superados:
- mejorar mi inglés: lo he mejorado, aunque no todo lo que quisiera, creo que este va a ser mi año del inglés! Se puede decir que objetivo no superado :/
- aprender a decir que no. Pues no, sigo siendo igual de pánfilo.
- aprender a descansar: difícil, pero creo que lo estoy consiguiendo, soy capaz de relajarme y no pensar en trabajar, por lo menos durante un tiempo razonable.
- seguir mejorando agroguía: lo he hecho y además estoy muy orgulloso y contento de como está funcionando, aunque empiezo a notar cierto desgaste en mi ánimo.
- gestión de proyectos y demás: he aprendido mucho, sobretodo lo que NO hay que hacer :).
En resumen, no he cumplido casi ningún objetivo de los que me había planteado, pero es tán difícil planificar un año...
En este año he aprendido muchas cosas, sobretodo a nivel profesional; he alcanzado suficiente madurez como para llevar un proyecto a nivel técnico con solvencia. Después de mi experiencia con diferentes proyectos desde diferentes roles (desde responsable, hasta rambo) creo que la cosa ha ido muy muy bien a pesar de haber sufrido en mis carnes lo que significaba la frustración y la desazón en ciertos momentos del año.
También he cambiado de trabajo, creo que ha sido una buena decisión el cambiar de aires y ver otras cosas, aunque sólamente a la larga lo sabré, quizás en el resumen del año 2009.
A nivel personal se puede decir que ha ido bien, aunque he pasado ciertamente alguna mala época, quizás por el exceso de trabajo desde varios frentes y por la estupidez del que no ve más allá de 3 palmos. En esta última etapa del año estoy dejando a un lado el trabajo y todo lo relacionado y estoy tratando de recuperar el tiempo perdido con algunas personas (aunque me cuesta a veces). Por otro lado he cerrado una larga cuenta pendiente, he conseguido que mi madre tenga un poco más cerca lo que se merece :D.
Hay cosas que me marcarán de este año, por ejemplo mi trabajo en unkasoft, lo asombrado que me he quedado con el trabajo de juanma, ciertas cosas que he comprendido de las relaciones humanas, el artículo de los generators en python, la cantidad de partido que se le puede dar a una idea muy simple con un poco de trabajo, algunas canciones, toda la filosofía softwaril que he predicado y alguna que otra bobada que he hecho, como fundirme un pastón en un coche nuevo y aficionarme al twitter XD (pobre megane).
12.23.2008
Mensaje a movistar
Hoy a las 16:02 he recibido un sms con una promoción sobre roaming -debo ser un usuario potencial- y estoy ya hasta los mismísimos.
El que avisa no es traidor:
"Movistar: Un solo mensaje más con publicidad indiscriminada (spam) y me cambio de compañía"
No va a servir de nada, en menos de 24 horas tendré otro mensaje con alguna promoción de puntos o quizás un ofertón para comprar el iphone. Pero así por lo menos me desfogo.
El que avisa no es traidor:
"Movistar: Un solo mensaje más con publicidad indiscriminada (spam) y me cambio de compañía"
No va a servir de nada, en menos de 24 horas tendré otro mensaje con alguna promoción de puntos o quizás un ofertón para comprar el iphone. Pero así por lo menos me desfogo.
12.17.2008
La importancia de las demos
Me comentaba un compañero de trabajo acerca de las demos en el mundo del software. He visto de todo en este tema, demos para que el cliente esté contento, demos porque los jefes están quemados, demos para tener las cosas claras, para todos los gustos.
¿Son las demos positivias? en mi opinión sí, por varias razones:
- Hasta que no tienes algo cerrado no ves todos los detalles, de esta forma te obliga a cerrar partes que a priori no son -parecen- importantes (documentación, instalaciones, etc)
- Da al programador un feedback sobre si las cosas están donde deben estar y sin necesidad de que nadie la pruebe. Es muy común estar desarrollando meses y cuando te quieres poner a funcionar no es posible proque es demasiado complejo, hay muchos problemas y termina llevando demasiado tiempo hacer andar a la bestia.
- No te entretienes "oliendo rosas". Tienes que hacer algo, el objetivo está claro, así que dedicas tus esfuerzos a hacerlo y no te preocupes en cosas que a menudo no importan. ¿Quién no ha visto a gente preocupándose por el rendimiento cuando su aplicación no tiene ni un solo usuario?
Pero las demos tienes sus cosas malas:
- El desarrollo orientado a demo: avanzar el desarrollo a base de demos, que no tiene porque ser malo, pero lo es cuando las demos modifican el desarrollo completamente y no hacen más que ensuciar y desviar el desarrollo.
- La demo orientada a contentar a alguien: Muy común, el inversor de turno quiere ver como su dinero no se desperdicia y se le pone entre los huevos que "sus curritos" enseñen el trabajo, cuando él quiere y como el quiere. Esta es una situación que la persona que está encargada debe evitar.
En resumen, creo que los que programamos aplaciones deberíamos ser un poco más pragmáticos y tener claro que lo que cada línea que escribimos debe resutlar útil en un plazo razonable. Nada mejor que una demo para demostrarlo, ¿o no? ¿Haz demos y enseña cosas!
¿Son las demos positivias? en mi opinión sí, por varias razones:
- Hasta que no tienes algo cerrado no ves todos los detalles, de esta forma te obliga a cerrar partes que a priori no son -parecen- importantes (documentación, instalaciones, etc)
- Da al programador un feedback sobre si las cosas están donde deben estar y sin necesidad de que nadie la pruebe. Es muy común estar desarrollando meses y cuando te quieres poner a funcionar no es posible proque es demasiado complejo, hay muchos problemas y termina llevando demasiado tiempo hacer andar a la bestia.
- No te entretienes "oliendo rosas". Tienes que hacer algo, el objetivo está claro, así que dedicas tus esfuerzos a hacerlo y no te preocupes en cosas que a menudo no importan. ¿Quién no ha visto a gente preocupándose por el rendimiento cuando su aplicación no tiene ni un solo usuario?
Pero las demos tienes sus cosas malas:
- El desarrollo orientado a demo: avanzar el desarrollo a base de demos, que no tiene porque ser malo, pero lo es cuando las demos modifican el desarrollo completamente y no hacen más que ensuciar y desviar el desarrollo.
- La demo orientada a contentar a alguien: Muy común, el inversor de turno quiere ver como su dinero no se desperdicia y se le pone entre los huevos que "sus curritos" enseñen el trabajo, cuando él quiere y como el quiere. Esta es una situación que la persona que está encargada debe evitar.
En resumen, creo que los que programamos aplaciones deberíamos ser un poco más pragmáticos y tener claro que lo que cada línea que escribimos debe resutlar útil en un plazo razonable. Nada mejor que una demo para demostrarlo, ¿o no? ¿Haz demos y enseña cosas!
12.15.2008
Buenas prácticas en el uso de subversion
Aparte de saber manejar subversion, conviene saber una serie de normas básicas a seguir que facilitan bastante la vida del programador sobretodo a futuro. El futuro se puede definir como el momento en el que necesitas saber que hiciste pero no te acuerdas :).
Al grano:
- Cada commit con su tema: Intenta no mezclar código con ficheros de datos o ficheros de proyecto. Es preferible hacer muchos commits con pocas cosas que ahorrarte medio minuto en no mirar lo que tienes y subirlo todo de una vez.
- Dios los cría y ellos se juntan. Si una serie de ficheros tienen que ver con un determinado tema, por ejemplo una corrección de bug, súbelos en el mismo commit. Esto es muy útil por si luego quieres mezclar esa revisión a otra rama para corregir el bug.
- Pon comentario en todos los commits: sobra decir que comentarios del tipo "commit", "subido" no son descriptivos y no ayudan :).
- Haz TAGS. Tags para todo, cuando envíes una demo, cuando saques una release, cuando termine el año. Los tags son gratis, así que úsalos y meta-etiquetalos bien.
- Automatiza la creación de tags con cada release. Puedes usar un script parecido a este:
Además, si lo haces así podrás automatizar otras muchas cosas, como por ejemplo obtener los binarios de una release en concreto (con svn export). Puedes usar otras cosas como make, rake o lo que te de la gana.
Son unas pocas normas, aplicables a cualquier sistema de control de versiones, pero si se aplican bien mejoran mucho el uso de subversion.
Al grano:
- Cada commit con su tema: Intenta no mezclar código con ficheros de datos o ficheros de proyecto. Es preferible hacer muchos commits con pocas cosas que ahorrarte medio minuto en no mirar lo que tienes y subirlo todo de una vez.
- Dios los cría y ellos se juntan. Si una serie de ficheros tienen que ver con un determinado tema, por ejemplo una corrección de bug, súbelos en el mismo commit. Esto es muy útil por si luego quieres mezclar esa revisión a otra rama para corregir el bug.
- Pon comentario en todos los commits: sobra decir que comentarios del tipo "commit", "subido" no son descriptivos y no ayudan :).
- Haz TAGS. Tags para todo, cuando envíes una demo, cuando saques una release, cuando termine el año. Los tags son gratis, así que úsalos y meta-etiquetalos bien.
- Automatiza la creación de tags con cada release. Puedes usar un script parecido a este:
import subprocess;
SVN = 'svn'
SERVER = 'svn://localhost/agroguia/TAGS/'
version = open("scripts/instalation/version.txt").read().split(':')[-1].strip();
cmd = [SVN, 'copy', '.', SERVER + version , '-m', '"released version '+ version + '"'];
print " ".join(cmd);
subprocess.call(cmd);
Además, si lo haces así podrás automatizar otras muchas cosas, como por ejemplo obtener los binarios de una release en concreto (con svn export). Puedes usar otras cosas como make, rake o lo que te de la gana.
Son unas pocas normas, aplicables a cualquier sistema de control de versiones, pero si se aplican bien mejoran mucho el uso de subversion.
12.08.2008
Mi primera semana
Bien, ya ha pasado mi primera semana larga en mi nuevo trabajo. La verdad que tengo sentimientos encontrados, por un lado técnicos y por otro personales.
Ya sabía que en unkasoft el nivel técnico era muy bueno, pero después de una semana lo he corroborado: el nivel técnico es muy bueno :). Tengo suerte porque en mi proyecto estoy con gente de bastante nivel, sin embargo, por lo general, el nivel técnico de mi empresa no es especialmente alto, entre otras cosas porque creo que la gente no tiene demasiada pasión. Espero que me confunda en este punto :).
Por otro lado, el aspecto personal ha mejorado muchísimo. La libertad de horarios, el descanso de media mañana, en no tener que hacerme 130km, salir una hora antes, la jornada intensiva de los viernes, el tener un proyecto claro (claro está que estoy en el proyecto, aunque no está tan claro) y sobretodo, el tener plazos dentro del sentido común (y dentro de lo que cabe en un proyecto de i+d). Esta semana he estado la mar de tranquilo, hasta he adelgazado :D, a ver si seguimos así.
Esto me hace ver, y cada día que masa más, que el peso de lo personal es mucho mayor que el peso de los conocimientos, por mucho que me pese.
Ya sabía que en unkasoft el nivel técnico era muy bueno, pero después de una semana lo he corroborado: el nivel técnico es muy bueno :). Tengo suerte porque en mi proyecto estoy con gente de bastante nivel, sin embargo, por lo general, el nivel técnico de mi empresa no es especialmente alto, entre otras cosas porque creo que la gente no tiene demasiada pasión. Espero que me confunda en este punto :).
Por otro lado, el aspecto personal ha mejorado muchísimo. La libertad de horarios, el descanso de media mañana, en no tener que hacerme 130km, salir una hora antes, la jornada intensiva de los viernes, el tener un proyecto claro (claro está que estoy en el proyecto, aunque no está tan claro) y sobretodo, el tener plazos dentro del sentido común (y dentro de lo que cabe en un proyecto de i+d). Esta semana he estado la mar de tranquilo, hasta he adelgazado :D, a ver si seguimos así.
Esto me hace ver, y cada día que masa más, que el peso de lo personal es mucho mayor que el peso de los conocimientos, por mucho que me pese.
12.02.2008
Me gusta
- ver cosas como http://2dboy.com/2008/12/01/world-of-goo-dissected
- darme cuenta de algo que alguien hace bien pero que parece fácil
- poder aplicar conocimientos de un campo a otro completamente diferente
- cuando con poco se hace mucho...
- ...y además se pueden hacer más cosas para las que originalmente estaba planteado
- cuando los planes salen bien
- darme cuenta de algo que alguien hace bien pero que parece fácil
- poder aplicar conocimientos de un campo a otro completamente diferente
- cuando con poco se hace mucho...
- ...y además se pueden hacer más cosas para las que originalmente estaba planteado
- cuando los planes salen bien
11.29.2008
Hasta luego Unkasoft
Sí, hace más o menos un mes tomé la decisión de dejar Unkasoft. Ahora estoy trabajando en Alten (en boecillo) en un proyecto de telefonica i+d sobre temas linux (realmente no sé si puedo decir más, no recuerdo haber firmado ningún NDA). Ya comentaré en otro post mis primeras impresiones que son muchas y variadas.
La decisión ha sido difícil para mi ya que, dejando a un lado el apartado laboral, he estado muy agusto con la gente allí. Es, de largo, la empresa donde mejor he estado con la gente, el nivel técnico que he visto ha sido muy bueno en todos los sentidos. Las razones de mi marcha no son realmente muy importantes ahora y no dudaría en recomendar a cualquier persona trabajar en Unkasoft.
Solo puedo dar las gracias a todas las personas con las que he trabajado allí: juanma(aka koala), jorjo, edu (dale caña y hazte un blog), flopez, jm, antonio, alberto, alfredo, jaime, hugo, carlingas, sheila, pablo, tony, laura, guilles, isa, isma y los que ya no están, fifo, rodi, fernando, juan y chusma. Quizás me olvide de alguien, que me perdone.
Un placer, nos encontraremos seguro más adelante :)
La decisión ha sido difícil para mi ya que, dejando a un lado el apartado laboral, he estado muy agusto con la gente allí. Es, de largo, la empresa donde mejor he estado con la gente, el nivel técnico que he visto ha sido muy bueno en todos los sentidos. Las razones de mi marcha no son realmente muy importantes ahora y no dudaría en recomendar a cualquier persona trabajar en Unkasoft.
Solo puedo dar las gracias a todas las personas con las que he trabajado allí: juanma(aka koala), jorjo, edu (dale caña y hazte un blog), flopez, jm, antonio, alberto, alfredo, jaime, hugo, carlingas, sheila, pablo, tony, laura, guilles, isa, isma y los que ya no están, fifo, rodi, fernando, juan y chusma. Quizás me olvide de alguien, que me perdone.
Un placer, nos encontraremos seguro más adelante :)
11.16.2008
La decoración es importante
De informatica |
Me las regaló mi novia en mi cumpleaños...
En el pack vienen un montón, si tengo que pegar todas mi madre me echa de casa.
Nos vamos al Congreso de desarrolladores de videojuegos
Juanma Zarza, compañero de Unkasoft, y un servidor nos vamos al congreso de desarrolladores de videojuegos.
Cierto es que, aún trabajando en unkasoft, estoy un poco alejado del mundo del videojuego, pero no quita para que me siga insteresando mucho el mundillo.
Nos vemos allí, estaremos el jueves, viernes y volveremos el sábado por la mañana.
Cierto es que, aún trabajando en unkasoft, estoy un poco alejado del mundo del videojuego, pero no quita para que me siga insteresando mucho el mundillo.
Nos vemos allí, estaremos el jueves, viernes y volveremos el sábado por la mañana.
11.11.2008
Dos recortes interesantes
Leía "El semanal", suplemento del grupo Vocento -les cito porque me dieron de comer una temporada- una entrevista a "Salvador Macip", que no lo conocía y sigo sin conocer, pero me llamó la atención por aquello de una entrevista a un técnico en un medio generalista, que ya sabemos todos que se estila poco.
En la entrevista decía cosas tales como (perdonad la mala calidad):
Es algo que ya me molesta mucho, la gente (me incluyo) por lo general hace caso a quien no debe.
Y luego al final de la entrevista:
Que puestas a huevo las preguntas y que bien respondidas.
(reproduzco sin consentimiento, como debe ser)
En la entrevista decía cosas tales como (perdonad la mala calidad):
Es algo que ya me molesta mucho, la gente (me incluyo) por lo general hace caso a quien no debe.
Y luego al final de la entrevista:
Que puestas a huevo las preguntas y que bien respondidas.
(reproduzco sin consentimiento, como debe ser)
11.09.2008
Mi opinión sobre la huelga de los informáticos
- La gente buena seguirá siendo buena con o sin título, papel o documento (y la mala igual eh?)
- Me parece muy bien que los informáticos se quejen y hagan huelga, es un paso más para que la gente sepa que _no_ es un trabajo poco cualificado. Lo del tema del título, atribuciones etcétera me parece una soplapollez, pero que la gente su movilice no.
- Me parece muy bien que los informáticos se quejen y hagan huelga, es un paso más para que la gente sepa que _no_ es un trabajo poco cualificado. Lo del tema del título, atribuciones etcétera me parece una soplapollez, pero que la gente su movilice no.
11.06.2008
Agroguía se va a Madrid a conferenciar
El próximo 25 de noviembre estaremos en Madrid en las VII jornadas de aplicaciones geomáticas en ingeniería. Vamos a presentar como hacemos usamos google earth con agroguía, nada realmente muy novedoso y además, intentando sorprender un poco, una pequeña aplicación web en la que he trabajado alguna que otra noche suelta.
Como digo no es algo novedoso, pero creo que el tracking web sí es ingenioso y bastante interesante, a ver si gusta. Me estoy pensando en si poder ofrecerlo también a los agricultores, sería un valor añadido muy interesante y ahora que parece que llegan las tarifas semiplanas de datos desde móvil puede ser adelantarse un paso. Solo decir que google serán todo lo evil que querais, pero las cosas que hacen las hacen cojonudamente: google maps se sale y los "deploys" en google app engine han dejado de ser un problema para ser un gusto.
Os dejo el programa, estamos el mismo día que John Deere y New Holland.
Como digo no es algo novedoso, pero creo que el tracking web sí es ingenioso y bastante interesante, a ver si gusta. Me estoy pensando en si poder ofrecerlo también a los agricultores, sería un valor añadido muy interesante y ahora que parece que llegan las tarifas semiplanas de datos desde móvil puede ser adelantarse un paso. Solo decir que google serán todo lo evil que querais, pero las cosas que hacen las hacen cojonudamente: google maps se sale y los "deploys" en google app engine han dejado de ser un problema para ser un gusto.
Os dejo el programa, estamos el mismo día que John Deere y New Holland.
11.03.2008
Internet atonta al programador
Y quien diga que no es que no ha trabajado sin internet :). Este fin de semana he pasado dos días completos (unas 7 horas cada día) trabajando completamente desconectado, sin ningún tipo de acceso a internet, sólamente a las fuentes de documentación que tenía en local (que son man y poco más).
Me encontré con varios problemas, entre ellos configurar un samba. Quería compartir ficheros entre un centos virtualizado y windows. Con internet en dos minutos de google tendría los comandos precisos para hacerlo, sin pensar tendría el problema resuelto. Esto a veces es bueno, pero no deja de ser pan para hoy y hambre para mañana. Esto es extrapolable casi a cualquier cosa.
Por no hablar que mi productividad aumentó enteros, ya no solo porque no me despisté con correos varios, atractivas webs, descriptivos tuits (quieres ser mi fologüer?) si no porque estaba yo solo, centrado en la tarea. Ya lo dicen 37signals en su libro getting real, "People need uninterrupted time to get things done". Es una realidad como un templo, cuanta productividad ganaría una empresa si fomentase esta política. En absolutamente todas las empresas en las que he estado he sufrido y he provocado interrupciones constantes. Es ciertamente difícil mantener esto con la disposición de las oficinas de desarrollo de software. Me hace pensar si no estaremos haciendo las cosas un poco mal :)
Me encontré con varios problemas, entre ellos configurar un samba. Quería compartir ficheros entre un centos virtualizado y windows. Con internet en dos minutos de google tendría los comandos precisos para hacerlo, sin pensar tendría el problema resuelto. Esto a veces es bueno, pero no deja de ser pan para hoy y hambre para mañana. Esto es extrapolable casi a cualquier cosa.
Por no hablar que mi productividad aumentó enteros, ya no solo porque no me despisté con correos varios, atractivas webs, descriptivos tuits (quieres ser mi fologüer?) si no porque estaba yo solo, centrado en la tarea. Ya lo dicen 37signals en su libro getting real, "People need uninterrupted time to get things done". Es una realidad como un templo, cuanta productividad ganaría una empresa si fomentase esta política. En absolutamente todas las empresas en las que he estado he sufrido y he provocado interrupciones constantes. Es ciertamente difícil mantener esto con la disposición de las oficinas de desarrollo de software. Me hace pensar si no estaremos haciendo las cosas un poco mal :)
10.30.2008
Usabilidad al poder
Me llama hoy un agricultor, de Sevilla, bastante majo el señor, comentándome que había tenido un problema con nuestro sistema de guiado agrícola GPS, poca cosa. Ya de paso le pregunté qué tal le había ido y demás.
Resulta que me dijo que quería sembrar una parcela de varias cosas, quería medir la mitad de la parcela para dejar mitad y mitad. Se le ocurrió poner un ancho de trabajo de 200 y pico metros y trazar una línea por la linde para saber luego donde estaba la mitad. La idea es muy buena, aunque agorguía puede hacer medidas de ese tipo sin recurrir a estos trucos.
En principio yo pensé que había pinchado sobre el campo de texto donde se mete el ancho, había sacado el teclado y había puesto 200 y picos metros sin embargo durante la conversación va y me dice: "todavía tengo el dedo dolorido de ponerle los 200 metros". Resulta que puse dos botones para ajustar el ancho, de 10 en 10 centímetros y el agricultor se había subido los 200 y tantos metros con los botones... más 2000 pulsaciones.
Moraleja: está claro que esos botones no son útiles tal cual están debería poderse mantener pulsado y subir a velocidad creciente. Qué importante es la usabilidad en el software y cuantos beneficios aporta al software que el programador tenga feedback directo.
En estos días estoy dándole vueltas a una pequeña web (ya diré para qué en pocos días) y aunque soy yo quien la va a usar no me hago una idea de como la voy a usar y que me va a ser más útil. Optaré por la solución de darle vueltas e ir iterando... le estoy cogiendo el gusto a javascript y css.
Resulta que me dijo que quería sembrar una parcela de varias cosas, quería medir la mitad de la parcela para dejar mitad y mitad. Se le ocurrió poner un ancho de trabajo de 200 y pico metros y trazar una línea por la linde para saber luego donde estaba la mitad. La idea es muy buena, aunque agorguía puede hacer medidas de ese tipo sin recurrir a estos trucos.
En principio yo pensé que había pinchado sobre el campo de texto donde se mete el ancho, había sacado el teclado y había puesto 200 y picos metros sin embargo durante la conversación va y me dice: "todavía tengo el dedo dolorido de ponerle los 200 metros". Resulta que puse dos botones para ajustar el ancho, de 10 en 10 centímetros y el agricultor se había subido los 200 y tantos metros con los botones... más 2000 pulsaciones.
Moraleja: está claro que esos botones no son útiles tal cual están debería poderse mantener pulsado y subir a velocidad creciente. Qué importante es la usabilidad en el software y cuantos beneficios aporta al software que el programador tenga feedback directo.
En estos días estoy dándole vueltas a una pequeña web (ya diré para qué en pocos días) y aunque soy yo quien la va a usar no me hago una idea de como la voy a usar y que me va a ser más útil. Optaré por la solución de darle vueltas e ir iterando... le estoy cogiendo el gusto a javascript y css.
10.29.2008
10.24.2008
Soy un iluso
No me cabe la menor duda, soy un iluso y además un cuadriculado. Ayer comentaba lo poco meditadas, por ser suave, que eran las compras que hacían algunas personas. Un comentario me abría los ojos, resulta que la gente cuando compra, no solo lo hace pensando en el rendimiento económico que pueda obtener.
Mi planteamiento es demasiado matemático. Recuerdo aquellos ejecicios de física donde no había rozamiento, todo era en el vacío, despreciabas la masa de ciertos elementos, etc, todo salía a la perfección. Así es como pienso yo, sin rozamiento pero desgraciadamente hay rozamiento y otras muchas cosas. Todo el mundo lo hace así, se venden coches ecológicos (subvencionados por el gobierno), ariel usa anuncios retros que aluden a la infancia de las mujeres para que compren su detergente, BMW usa dos focos delanteros en forma de aro... a quien le importan los datos pudiendo aportar al medioambiente y ser solidario o que me conozcan como javi el del BMW?
Reconozco que es inevitable, yo mismo caigo dentro de ese círculo, aunque trato de hacer las cosas con el máximo razonamiento posible. En cualquier caso quizás cambie la forma de presentar las cosas, pero en ningún caso engañando, mi conciencia tranquila vale mucho más que eso (veremos si digo lo mismo el día que tenga bocas que alimentar :).
Mi planteamiento es demasiado matemático. Recuerdo aquellos ejecicios de física donde no había rozamiento, todo era en el vacío, despreciabas la masa de ciertos elementos, etc, todo salía a la perfección. Así es como pienso yo, sin rozamiento pero desgraciadamente hay rozamiento y otras muchas cosas. Todo el mundo lo hace así, se venden coches ecológicos (subvencionados por el gobierno), ariel usa anuncios retros que aluden a la infancia de las mujeres para que compren su detergente, BMW usa dos focos delanteros en forma de aro... a quien le importan los datos pudiendo aportar al medioambiente y ser solidario o que me conozcan como javi el del BMW?
Reconozco que es inevitable, yo mismo caigo dentro de ese círculo, aunque trato de hacer las cosas con el máximo razonamiento posible. En cualquier caso quizás cambie la forma de presentar las cosas, pero en ningún caso engañando, mi conciencia tranquila vale mucho más que eso (veremos si digo lo mismo el día que tenga bocas que alimentar :).
10.23.2008
Hola, soy un cliente pero no me digas la verdad
La situación es la siguiente: Un agricultor llama para preguntar puer nuestro sistema de guiado agrícola GPS y hace las preguntas pertinentes sobre precios, características, plazos de entrega, garantías, etc. Normal, lo que cualquier haría. Sin embargo hay un indicador sobre la calidad de un sistema de guiado GPS, la precisión, viene a ser algo así como la potencia en un coche, hay muchas cosas importantes en un coche, pero normalmente suelen matizar especialmente los caballos del motor. Siempre siempre me preguntan por la precisión del sistema y yo siempre siempre les digo la verdad, y esto es lo que me dicen los estudios sobre GPS que he realizado. Podrán estar mejor o peor, pero hay una base donde fundamentarme.
El caso es que hoy nos llama un agricultor, pregunta por la precisión, le decimos lo que hay y dice: "prefería que me hubieses mentido". JA!, es normal, cuando habla con personas que venden otros sistemas siempre les dicen "nuestro sistema da 20cms de precisión". Lo he comprobado, da igual el GPS que instalen, siempre te dicen lo mismo y la gente se queda tan contenta. A mi estas cosas me preocupan, para empezar porque yo sé que los GPS, salvo que te gastes un pastizal, NUNCA están en 20cms de precisión el 90% del tiempo, pero más me preocupa saber que la gente prefiere que le mientas a tener que tomar una decisión. Me niego a mentir para hacer una venta más.
Un detalle importante es el marketing que hay sobre el tema de la precisión, podría haber sido con cualquier otro tema, pero los agricultores exigen que el sistema de guiado GPS que llevan en su tractor tenga una precisión altísima, mucha más de la que necesitan y, lo peor, mucha más de la que podrán conseguir, ya que para tenerla necesitas que todo el sistema sea acorde.
El caso es que hoy nos llama un agricultor, pregunta por la precisión, le decimos lo que hay y dice: "prefería que me hubieses mentido". JA!, es normal, cuando habla con personas que venden otros sistemas siempre les dicen "nuestro sistema da 20cms de precisión". Lo he comprobado, da igual el GPS que instalen, siempre te dicen lo mismo y la gente se queda tan contenta. A mi estas cosas me preocupan, para empezar porque yo sé que los GPS, salvo que te gastes un pastizal, NUNCA están en 20cms de precisión el 90% del tiempo, pero más me preocupa saber que la gente prefiere que le mientas a tener que tomar una decisión. Me niego a mentir para hacer una venta más.
Un detalle importante es el marketing que hay sobre el tema de la precisión, podría haber sido con cualquier otro tema, pero los agricultores exigen que el sistema de guiado GPS que llevan en su tractor tenga una precisión altísima, mucha más de la que necesitan y, lo peor, mucha más de la que podrán conseguir, ya que para tenerla necesitas que todo el sistema sea acorde.
10.19.2008
Proponiento un PFC
Acabo de terminar de redactar una propuesta de proyecto fin de carrera. La docencia nunca me ha interesado demasiado, pero la idea de poder usar el tiempo para hacer pruebas y estudiar lo que te de la gana me resulta realmente interesante. En este caso solo participaré asesorando técnicamente.
El proyecto como no podía ser de otra forma trata sobre agricultura, no es más que hacer un estudio y unas pruebas un poco decentes sobre un tema que empecé hace unos meses: agumented reality aplicado en agricultura.
Es posible que nunca tenga una aplicación real, pero quien sabe, hay cosechadoras guiadas con visión artificial, tractores guiados por GPS y acelerómetros. Además, que coño, es que todo tiene que valer para algo? :)
Realmente tengo ilusión con este pequeño reto, une varias de las cosas que tecnológicamente más me interesan, entre ellas el 3D y el mundo GPS.
El proyecto como no podía ser de otra forma trata sobre agricultura, no es más que hacer un estudio y unas pruebas un poco decentes sobre un tema que empecé hace unos meses: agumented reality aplicado en agricultura.
Es posible que nunca tenga una aplicación real, pero quien sabe, hay cosechadoras guiadas con visión artificial, tractores guiados por GPS y acelerómetros. Además, que coño, es que todo tiene que valer para algo? :)
Realmente tengo ilusión con este pequeño reto, une varias de las cosas que tecnológicamente más me interesan, entre ellas el 3D y el mundo GPS.
10.16.2008
Se habla de agroguía
El otro día cual fue mi sorpresa que linking paths, una empresa dedicada al desarrollo web con una filosofía un tanto diferente, dedicaba un post a agroguía, nuestro sistema de guiado GPS para el tractor.
Es reconfortante que hablen de ti, pero más lo es si lo hace gente que sigues de hace tiempo y que consideras que hacen las cosas bien. Me encanta el pragmatismo que transmiten, creo que muchos deberíamos aprender mucho de ellos. Muy a lo 37signals, de hecho ellos también tienen un getting real, vivir del software.
Lo dicho, hay algunos días que este tipo de cosas vienen bien. Gracias
Es reconfortante que hablen de ti, pero más lo es si lo hace gente que sigues de hace tiempo y que consideras que hacen las cosas bien. Me encanta el pragmatismo que transmiten, creo que muchos deberíamos aprender mucho de ellos. Muy a lo 37signals, de hecho ellos también tienen un getting real, vivir del software.
Lo dicho, hay algunos días que este tipo de cosas vienen bien. Gracias
10.14.2008
El valor añadido y los beneficios
Si vendes algo material y eres intermediario, es realmente fácil ganar dinero sin ton ni son. Basta aprovecharse de la ignorancia del comprador para poner el precio que nos de la gana a, por ejemplo, una pieza de repuesto o similar.
Con agroguía, nuestro sistema de guiado agrícola GPS para el tractor, tenemos ese caso. A veces nos piden dos unidades de algo o se rompe cualquier cosa. Sería muy fácil incrementar al triple o más el precio de los productos que compramos en una tienda cualquiera, sin embargo, yo realmente no estoy aportando ningún valor añadido, esto es, no he creado ese producto, me sentaría mal cobrar una pasta por algo en lo que yo no he aportado nada. Lógicamente el tiempo invertido debes cobrarlo, pero no mucho más, ya que de otra forma estarías engañando al cliente.
Últimamente siempre que hago algo profesionalmente me hago la siguiente preguntas:
- ¿aporto yo valor añadido a lo que estoy haciendo?
- ¿alguien dispuesto a dar dinero por esto que estoy haciendo?
Si lo que hago no aporta nada automáticamente pienso en otra cosa que hacer. Creo que no soy el único que pienso así, pero creo que mucha otra gente le da igual y a mi me molesta mucho que siempre la primera parte de la cadena es la que menos pasta se lleva. Qué poco valorado está el producir.
Con agroguía, nuestro sistema de guiado agrícola GPS para el tractor, tenemos ese caso. A veces nos piden dos unidades de algo o se rompe cualquier cosa. Sería muy fácil incrementar al triple o más el precio de los productos que compramos en una tienda cualquiera, sin embargo, yo realmente no estoy aportando ningún valor añadido, esto es, no he creado ese producto, me sentaría mal cobrar una pasta por algo en lo que yo no he aportado nada. Lógicamente el tiempo invertido debes cobrarlo, pero no mucho más, ya que de otra forma estarías engañando al cliente.
Últimamente siempre que hago algo profesionalmente me hago la siguiente preguntas:
- ¿aporto yo valor añadido a lo que estoy haciendo?
- ¿alguien dispuesto a dar dinero por esto que estoy haciendo?
Si lo que hago no aporta nada automáticamente pienso en otra cosa que hacer. Creo que no soy el único que pienso así, pero creo que mucha otra gente le da igual y a mi me molesta mucho que siempre la primera parte de la cadena es la que menos pasta se lleva. Qué poco valorado está el producir.
10.09.2008
Viene el lobo amigos
Ya viene la crisis, ya está aquí, tenía que pasar. La gente está un poco acojonada, no es para menos, pero yo estoy muy poco preocupado.
Realmente estoy más intrigado que preocupado, lógicamente no quiero que todo se vaya al carajo, vivo en un entorno del que dependo en mayor o menor medida, pero la sensación que tengo es otra. Tengo ganas de que vengan las cosas, tengo ganas de ver como salimos de esta, sé que los buenos salen de -casi- todo y esta es una forma de demostrar que eres bueno.
Desde hace unos años tengo la mala costumbre de ser competitivo, aunque muchas veces sepa que no puedo estar a cierta altura, lo soy y trabajo como un burro, muchas veces en contra de mi mismo. Por eso creo que este es un momento en el que se debe demostrar que tienes capacidad para resolver los problemas y estar un paso por delante de los demás. Espero que esta crisis haga que mucha purrela empresarial se vaya a otro lado, es posible que haya lesiones, pero purgará.
Por eso cuando félix me dice que tiene una hipoteca y que la cosa está muy mal me hace gracia, un fulano trabajador y con nivel no debe tener miedo... :).
Realmente estoy más intrigado que preocupado, lógicamente no quiero que todo se vaya al carajo, vivo en un entorno del que dependo en mayor o menor medida, pero la sensación que tengo es otra. Tengo ganas de que vengan las cosas, tengo ganas de ver como salimos de esta, sé que los buenos salen de -casi- todo y esta es una forma de demostrar que eres bueno.
Desde hace unos años tengo la mala costumbre de ser competitivo, aunque muchas veces sepa que no puedo estar a cierta altura, lo soy y trabajo como un burro, muchas veces en contra de mi mismo. Por eso creo que este es un momento en el que se debe demostrar que tienes capacidad para resolver los problemas y estar un paso por delante de los demás. Espero que esta crisis haga que mucha purrela empresarial se vaya a otro lado, es posible que haya lesiones, pero purgará.
Por eso cuando félix me dice que tiene una hipoteca y que la cosa está muy mal me hace gracia, un fulano trabajador y con nivel no debe tener miedo... :).
10.07.2008
Me estreno como videocaster
Es curioso, hablo tan mal como creía y me explico aún peor. No hay nada como grabarse para tener un feedback rápido.
El caso es que voy a intentar grabar una serie de videos explicando como funciona nuestro sistema de guiado agrícola GPS.
Cosas que debo mejorar:
- preparar la exposición
- hablar más despacio
- no meter tantos helpers :)
Bueno, pues si quereis poner un sistema de guiado GPS en un tractor, ya sabeis como arrancarlo:
- arrancando agroguía
Alguna sugerencia? espero que alguna sí, no os paseis eh?
El caso es que voy a intentar grabar una serie de videos explicando como funciona nuestro sistema de guiado agrícola GPS.
Cosas que debo mejorar:
- preparar la exposición
- hablar más despacio
- no meter tantos helpers :)
Bueno, pues si quereis poner un sistema de guiado GPS en un tractor, ya sabeis como arrancarlo:
- arrancando agroguía
Alguna sugerencia? espero que alguna sí, no os paseis eh?
10.06.2008
partnership
Palabrostio, inglesotada como la catedral de Salamanca, típica palabra de "neogocios" que suena como subbuffer... muchas veces me quedo un poco asombrado de los términes tan estupendos que se llevan ahora... a haber hecho un transacción comercial, a veces nisiquiera eso, lo llaman partnership, a ir a una reunión y hablar con gente lo llaman networking.
En fin, no es el tema que quería tratar, pero tiene bastante que ver. Hace unos días el CEO de agroterra, nos escribía en la web (nuestra web de sistemas de guiado GPS para tractor - lo siento pero tengo que subir gps + tractor como sea-). Realmente te alegra, el CEO del portal más grande de agricultura de España, agroterra.com, te escribe en el blog para darte apoyo. Ya había leído de Jesús Martinez en el blog de Carlos Blanco, pero en ningún momento se me había pasado por la cabeza contactar con nadie para absolutamente nada y mucho menos con el ceo de agroterra (del que soy usuario de sus foros).
Realmente tengo poco de comercial, networker o como lo quieran llamar, sé que tener contactos es fundamental si quieres hacer dinero, ir a eventos, tener "partnerships" con empresas del sector, etc. En media hora que me pongo a darle vueltas, 4 búsquedas por internet y se me ocurren posibles negocios que tienen que ver con el GPS en la agricultura. Ya solo pensar en la trazabilidad, en la publicidad y en otras muchísimas cosas que se pueden hacer solo con saber las posiciones en cada momento de la maquinaria, es mucho más que un GPS agrícola (lo siento de nuevo). En breve voy a empezar a ofrecer a los agricultores un pequeño de sistema de tracking de sus labores por web, tranquilamente podría ponerme en contacto con un desarrollador de sistemas de trazabilidad para ser un complemento más. Técnicamente somos muy buenos, así que integrar nuestro sistema con supone problemas, todo lo contrario. Y es que en España ser bueno técnicamente es un valor, porque se ve cada cosa...
Me hago la pregunta a mi mismo: por qué si ganas dinero suficiente para mantenerte trabajando unas horas semanales no te dedicas a expandirte e intentar hacer negocio de verdad?. La primera respuesta que me viene a la cabeza es que me faltan cojones ... :), aunque si me faltan posiblemente sea porque no me veo. Antes pensaba que yo no podría hacer labor comercial, pero a medida que pasa el tiempo me doy cuenta como con tiempo y esfuerzo es posible ser buen comercial -quizás algún día-, igual que ser buen técnico. En el fondo todos somos comerciales, todos tenemos que vender algo. Tengo claro que no tengo miedo, creo firmemente en el potencial del esfuerzo y del trabajo bien hecho. Sin embargo el trabajo como técnico me gusta, disfruto y no me gustaría perder de la vista mis proyectos. El dinero el "networkin" y el "parnesi" no dan la felicidad :)
En fin, no es el tema que quería tratar, pero tiene bastante que ver. Hace unos días el CEO de agroterra, nos escribía en la web (nuestra web de sistemas de guiado GPS para tractor - lo siento pero tengo que subir gps + tractor como sea-). Realmente te alegra, el CEO del portal más grande de agricultura de España, agroterra.com, te escribe en el blog para darte apoyo. Ya había leído de Jesús Martinez en el blog de Carlos Blanco, pero en ningún momento se me había pasado por la cabeza contactar con nadie para absolutamente nada y mucho menos con el ceo de agroterra (del que soy usuario de sus foros).
Realmente tengo poco de comercial, networker o como lo quieran llamar, sé que tener contactos es fundamental si quieres hacer dinero, ir a eventos, tener "partnerships" con empresas del sector, etc. En media hora que me pongo a darle vueltas, 4 búsquedas por internet y se me ocurren posibles negocios que tienen que ver con el GPS en la agricultura. Ya solo pensar en la trazabilidad, en la publicidad y en otras muchísimas cosas que se pueden hacer solo con saber las posiciones en cada momento de la maquinaria, es mucho más que un GPS agrícola (lo siento de nuevo). En breve voy a empezar a ofrecer a los agricultores un pequeño de sistema de tracking de sus labores por web, tranquilamente podría ponerme en contacto con un desarrollador de sistemas de trazabilidad para ser un complemento más. Técnicamente somos muy buenos, así que integrar nuestro sistema con supone problemas, todo lo contrario. Y es que en España ser bueno técnicamente es un valor, porque se ve cada cosa...
Me hago la pregunta a mi mismo: por qué si ganas dinero suficiente para mantenerte trabajando unas horas semanales no te dedicas a expandirte e intentar hacer negocio de verdad?. La primera respuesta que me viene a la cabeza es que me faltan cojones ... :), aunque si me faltan posiblemente sea porque no me veo. Antes pensaba que yo no podría hacer labor comercial, pero a medida que pasa el tiempo me doy cuenta como con tiempo y esfuerzo es posible ser buen comercial -quizás algún día-, igual que ser buen técnico. En el fondo todos somos comerciales, todos tenemos que vender algo. Tengo claro que no tengo miedo, creo firmemente en el potencial del esfuerzo y del trabajo bien hecho. Sin embargo el trabajo como técnico me gusta, disfruto y no me gustaría perder de la vista mis proyectos. El dinero el "networkin" y el "parnesi" no dan la felicidad :)
10.04.2008
Negociando: el correo electrónico no sirve para nada
Así de claro, cuando tienes un negocio en el mundo real, esto es, que usas un soporte online para publicitar, mostrar y promocionar tu producto, la gente que contacta por correo electrónico, en su mayoría, no está interesada.
En este tiempo hemos recibido más de 100 correos, casi todos preguntan lo mismo y solo uno ha comprado el producto finalmente. Es un ratio suficientemente bajo como para tenerlo demasiado en cuenta. Tampoco quiero decir que se deba dejar de un lado los correos que llegan, pero tampoco hay que martarse a contestarlo con detalle, con un pdf del producto es mucho más que suficiente.
La gente que realmente está interesada llama por teléfono. El correo es un medio muy útil, pero no percibes como es la persona, sientes que realmente hay alguien detrás de la web, puedes ver las respuestas cuando no hay tiempo para meditarlas...
El otro día, cuando recibí un correo diciendome que quería comprar el producto, lo siguiente que hicimos fue contactar con él por teléfono. Resulta curioso que uses el correo como medio de contacto principal y luego recurras al teléfono para hablar con la persona. No cabe duda que responde a las mismos estímulos que tiene la gente que llama. En casa del herrero cuchillo de palo.
En este tiempo hemos recibido más de 100 correos, casi todos preguntan lo mismo y solo uno ha comprado el producto finalmente. Es un ratio suficientemente bajo como para tenerlo demasiado en cuenta. Tampoco quiero decir que se deba dejar de un lado los correos que llegan, pero tampoco hay que martarse a contestarlo con detalle, con un pdf del producto es mucho más que suficiente.
La gente que realmente está interesada llama por teléfono. El correo es un medio muy útil, pero no percibes como es la persona, sientes que realmente hay alguien detrás de la web, puedes ver las respuestas cuando no hay tiempo para meditarlas...
El otro día, cuando recibí un correo diciendome que quería comprar el producto, lo siguiente que hicimos fue contactar con él por teléfono. Resulta curioso que uses el correo como medio de contacto principal y luego recurras al teléfono para hablar con la persona. No cabe duda que responde a las mismos estímulos que tiene la gente que llama. En casa del herrero cuchillo de palo.
9.30.2008
Mensaje a los diseñadores de hardware HP
¿En qué pensaban cuando diseñaron la PDA ipaq 214? Teniendo en cuenta que la mayoría de la gente va a comprarla como agenda, para usar su software de navegación favorita, etc, por qué coño no incluisteis un puerto serie? ¿qué protocolo creeis que usan los GPS?
Hay decisiones que nunca entenderé.
Hay decisiones que nunca entenderé.
9.16.2008
De menos a más
La programación web no ha sido lo mio, aunque tengo que reconocer que cada día me atrae más, no tanto la parte front end, el interfaz de usuario, javascripts, html y tecnologías varias, si no la parte de servicio.
Para llevar un tracking de los usuarios de demos agroguía implementé un sistema de tracking muy rudimentario, la herramienta enviaba -de alguna forma, no voy a revelar el secreto, aunque si sigues el blog sabrás como- datos a un servicio web (http más bien). Cuando planeé el servicio estaba pensado para funcionar, siempre y cuando no hubiese accesos recurrentes.
Con ese requisito, hice un script cgi en dos minutos que me ha funcionado hasta hace una semana. Desde hace una semana tengo una cantidad razonable de peticiones al server, las justas para que haya posibilidad de accesos múltiples al mismo tiempo, de forma que los datos se han corrompido.
La pregunta es la siguiente: hubiera merecido la pena hacer el servicio bien desde el principio o es preferible trabajar dos veces?.
Los puristas responderían sin dudarlo: "deberías haber hecho las cosas bien y planificarlo para el futuro", los pragmáticos hubieran hecho lo que yo hice :). Si analizas bien la aplicación te das cuenta que la probabilidad de accesos recurrentes era bajísima y la probabilidad de perder los datos muy baja (teniendo en cuenta los backups del server) y el valor de los datos bajo, con lo cual no merecía la pena.
Vale, pero ahora te toca hacer lo que no hiciste hace tiempo, con lo cual si lo hubieras hecho hace un tiempo ahora no tendrías problemas. FALSO, porque con esa herramienta de dos minutos que ha funcionado a modo de test he aprendido ciertas cosas -el know how famoso- que ahora voy a tener en cuenta. Esa es la principal razón de no intentar hacer todo desde el principio, cosa que he visto repetida cientos de veces en diferentes entornos empresariales.
Moraleja: "no trates de correr antes de aprender a andar"
Para llevar un tracking de los usuarios de demos agroguía implementé un sistema de tracking muy rudimentario, la herramienta enviaba -de alguna forma, no voy a revelar el secreto, aunque si sigues el blog sabrás como- datos a un servicio web (http más bien). Cuando planeé el servicio estaba pensado para funcionar, siempre y cuando no hubiese accesos recurrentes.
Con ese requisito, hice un script cgi en dos minutos que me ha funcionado hasta hace una semana. Desde hace una semana tengo una cantidad razonable de peticiones al server, las justas para que haya posibilidad de accesos múltiples al mismo tiempo, de forma que los datos se han corrompido.
La pregunta es la siguiente: hubiera merecido la pena hacer el servicio bien desde el principio o es preferible trabajar dos veces?.
Los puristas responderían sin dudarlo: "deberías haber hecho las cosas bien y planificarlo para el futuro", los pragmáticos hubieran hecho lo que yo hice :). Si analizas bien la aplicación te das cuenta que la probabilidad de accesos recurrentes era bajísima y la probabilidad de perder los datos muy baja (teniendo en cuenta los backups del server) y el valor de los datos bajo, con lo cual no merecía la pena.
Vale, pero ahora te toca hacer lo que no hiciste hace tiempo, con lo cual si lo hubieras hecho hace un tiempo ahora no tendrías problemas. FALSO, porque con esa herramienta de dos minutos que ha funcionado a modo de test he aprendido ciertas cosas -el know how famoso- que ahora voy a tener en cuenta. Esa es la principal razón de no intentar hacer todo desde el principio, cosa que he visto repetida cientos de veces en diferentes entornos empresariales.
Moraleja: "no trates de correr antes de aprender a andar"
9.13.2008
¿dónde están los técnicos?
Llevo ya algún tiempo siguiendo blogs personales de gente que se dedica a negocios en internet como por ejemplo Carlos Blanco, Rodolfo Carpintier y Alejandro Suárez Sánchez-Ocaña, Me gusta seguirlos porque saben del tema, saben transimitirlo bien y además lo hacen desde una visión cercana. Es fácil ver posts personales, de sus vacaciones, etc, que a priori no tienen mucho que ver con su profesión, pero que resultan también interesantes porque te pone un poco en el contexto de la vida del blogger en cuestión.
Pero hay una cosa que me mata y me molesta profundamente, y es la poca consideración, atención, protagonismo, llámalo como quieras, que dan a las personas de la parte técnica, a la producción real del producto. Casi siempre los elogios, comentarios positivos son a los que han puesto el dinero, los que han dirigido el desarrollo, los que han vendido, etc, a los que no quito mérito, pero es que al igual que sin ellos no habría nada, sin nosotros los técnicos, tampoco lo habría. Somos los productores de la materia prima, ¿por qué siempre los primeros de la cadena somos los peor considerados?.
Pongamos un ejemplo, hace poco se presentaba yes.fm, del cual Alejando Suárez es socio fundador, y no hace demasiado tiempo enumeraba al equipo de yes.fm. Bien, ni un solo técnico, mínimo creo yo, una reseña al director técnico o similar. Se lo recriminé en un comentario, al cual me respondió que haría un post sobre ello, el cual aún estoy esperando, y no soy el único (lee los comentarios del post). Admito que se lo han currando mucho en cuanto a la parte de marketing, etc, tiene pinta de ser algo bueno, pero es que creo que es un proyecto técnicamente también muy ambiciosos, digno de reseña.
Cierto es que hay pequeñas reseñas, por ejemplo Rodolfo hizo un par de post este verano, en los cuales participé sobre el tema de los programadores y técnicos varios:
- hablando de programadores. En este post se demuestra que la visión de un técnico no deja de ser enigmática, llena de topicazos, en resumen, no se sabe muy bien de que va nuestro trabajo y los problemas que tenemos.
- participación de un programador
- Respuestas a los anteriores post
Es de agradecer, pero hay que decir que esta serie de post no dejaron de ser una reflexiones en voz alta y en una época en la que el autor del blog estaba experimentando.
Esto me hace pensar algunas cosas. Cuando yo hablo con mi madre, sin apenas formación técnica, ella sabe o tiene idea de lo que hace un arquitecto, un albañil, un alicatador, fontanero, electricista. Sabe quien es más cualificado, quien cobra más y quien menos, etc... sin embargo un día la pregunté que si sabía a lo que me dedicaba. No lo sabía, pero es que tampoco sabía muy bien qué hacía un ingeniero de telecomunicación ni un ingeniero informático. Falta formación en ese aspecto y lo que me preocupa es que no solo a mi madre, que no es dueña de ninguna empresa (aunque es una buena gestora :), si no a gente que demuestran su buen hacer en internet y que debería saber tratar y conocer a un equipo técnico. Pero es que hay muchos otros indicadores, por ejemplo, no tener un convenio laboral adaptado y razonable (que daría para un post aparte), la poca, poquísima estima social, la inconprensible forma de trabajar, etc, etc.
En mi corta, pero intensa, trayectoria profesional, NUNCA un inversor ha venido a conocerme a ver como trabaja el equipo técnico. Ya no hablo de una auditoría técnica, hablo de ver si el equipo está motivado, si tienen gusto por el trabajo, en resumen, ver a las personas, a las que por ahora llaman RECURSOS (qué poca sensibilidad y que falta de respeto).
Es cuestión de tiempo, que tendrá que pasar hasta que la gente del sector y la sociedad se vaya dando cuenta y adquiera un poco de sentido común tecnológico.
A ver cuantos me vienen ahora diciendo que lo que hago yo en España, lo hacen en Rumanía por un cuarto de lo que cobro yo. Y además trabajan el triple, se quejan menos y hacen las cosas más rápido. Total, somos unos obreritos (no obreros, con todo el respeto hacia mis compañeros del metal).
Pero hay una cosa que me mata y me molesta profundamente, y es la poca consideración, atención, protagonismo, llámalo como quieras, que dan a las personas de la parte técnica, a la producción real del producto. Casi siempre los elogios, comentarios positivos son a los que han puesto el dinero, los que han dirigido el desarrollo, los que han vendido, etc, a los que no quito mérito, pero es que al igual que sin ellos no habría nada, sin nosotros los técnicos, tampoco lo habría. Somos los productores de la materia prima, ¿por qué siempre los primeros de la cadena somos los peor considerados?.
Pongamos un ejemplo, hace poco se presentaba yes.fm, del cual Alejando Suárez es socio fundador, y no hace demasiado tiempo enumeraba al equipo de yes.fm. Bien, ni un solo técnico, mínimo creo yo, una reseña al director técnico o similar. Se lo recriminé en un comentario, al cual me respondió que haría un post sobre ello, el cual aún estoy esperando, y no soy el único (lee los comentarios del post). Admito que se lo han currando mucho en cuanto a la parte de marketing, etc, tiene pinta de ser algo bueno, pero es que creo que es un proyecto técnicamente también muy ambiciosos, digno de reseña.
Cierto es que hay pequeñas reseñas, por ejemplo Rodolfo hizo un par de post este verano, en los cuales participé sobre el tema de los programadores y técnicos varios:
- hablando de programadores. En este post se demuestra que la visión de un técnico no deja de ser enigmática, llena de topicazos, en resumen, no se sabe muy bien de que va nuestro trabajo y los problemas que tenemos.
- participación de un programador
- Respuestas a los anteriores post
Es de agradecer, pero hay que decir que esta serie de post no dejaron de ser una reflexiones en voz alta y en una época en la que el autor del blog estaba experimentando.
Esto me hace pensar algunas cosas. Cuando yo hablo con mi madre, sin apenas formación técnica, ella sabe o tiene idea de lo que hace un arquitecto, un albañil, un alicatador, fontanero, electricista. Sabe quien es más cualificado, quien cobra más y quien menos, etc... sin embargo un día la pregunté que si sabía a lo que me dedicaba. No lo sabía, pero es que tampoco sabía muy bien qué hacía un ingeniero de telecomunicación ni un ingeniero informático. Falta formación en ese aspecto y lo que me preocupa es que no solo a mi madre, que no es dueña de ninguna empresa (aunque es una buena gestora :), si no a gente que demuestran su buen hacer en internet y que debería saber tratar y conocer a un equipo técnico. Pero es que hay muchos otros indicadores, por ejemplo, no tener un convenio laboral adaptado y razonable (que daría para un post aparte), la poca, poquísima estima social, la inconprensible forma de trabajar, etc, etc.
En mi corta, pero intensa, trayectoria profesional, NUNCA un inversor ha venido a conocerme a ver como trabaja el equipo técnico. Ya no hablo de una auditoría técnica, hablo de ver si el equipo está motivado, si tienen gusto por el trabajo, en resumen, ver a las personas, a las que por ahora llaman RECURSOS (qué poca sensibilidad y que falta de respeto).
Es cuestión de tiempo, que tendrá que pasar hasta que la gente del sector y la sociedad se vaya dando cuenta y adquiera un poco de sentido común tecnológico.
A ver cuantos me vienen ahora diciendo que lo que hago yo en España, lo hacen en Rumanía por un cuarto de lo que cobro yo. Y además trabajan el triple, se quejan menos y hacen las cosas más rápido. Total, somos unos obreritos (no obreros, con todo el respeto hacia mis compañeros del metal).
Etiquetas:
cultura informatica,
programacion
9.10.2008
dos años de agroguía
Parece que fue ayer cuando la primera persona nos llamó para interesarse por agroguía y ya han pasado dos años. Quien nos iba a decir que esos carteles que pusimos tímidamente iban a captar la atención de alguien...
Para el que no esté al tanto, agroguía es un sistema de guiado GPS para la agricultura, esto es, permite al agricultor en todo momento que zonas ha tratado y cuales no. Parece de perogrullo, pero no es fácil saber por donde has pasado en un terreno con una superfie considerable o mantener una distancia constante a una línea imaginaria.
Ya he escrito bastante acerca de como nos han ido las cosas, los problemas que hemos tenido, anecdotas, casi siempre visto desde el punto de vista de un desarrollador. La verdad que estoy satisfecho, creo que todo ha salido muy bien, pero sobretodo me gusta la idea de que todo lo hemos hecho nosotros: la aplicación, la comercialización, el soporte - que importante es que el desarrollador de soporte al cliente - , al web, la forma de hacer las cosas. Seguramente las hayamos hecho ni medio bien, la gente nos ha criticado hasta la saciedad por no acceder a que lo comercialicen terceros, he llegado hasta a recibir descalificaciones personales, quizas _un poco_ motivada por mi opinión del sector "comercial" (ojo, entrecomillado, nadie se ofenda).
En resumen:
- hemos estado en ferias
- Nos han publicado artículos en varias revistas, que recuerde, además en mapping, tierras y alguna que otra publicación más. La mayor parte de la culpa la tiene Jaime Gómez.
- Hemos visto cosas curiosas, por ejemplo el agricultor que nos preguntó que donde se compraba el líquido naranja, alguna que otra foto, agricultores 2.0.
- Ya hemos llegado al break event ... jaja
- Podemos decir que facturamos, hacienda nos roba lo mismo que a todo el mundo y ahora ya comprendemos a la gente que anda buscando facturas como locos. Puedo afirmar que el negocio da para vivir bien 3 personas, a pesar de los impuestos. Y eso, aunque suene mal lo que voy a escribir, sin lamerle el culo a nadie, aunque eso sí, con ayuda de mucha buena gente.
- Personalmente me ha permitido durante este tiempo poder hacer lo que realmente me ha dado la gana. He programado cuando he querido, he investigado, he hecho las pruebas que he querido. Este es quizás el punto más importante para mi y que precisamente estoy empezando a valorar en su justa medida. Incluso las características que he implementado por puro placer han gustado mucho, en contra de mi pronóstico, y venden.
Se aproxima la tercera temporada y por lo que veo viene muy muy bien. Este año ha habido muy buena cosecha, ha subido el precio de la materia prima y los agricultores no han notado demasiado la subida del carburante (la notarán este periodo). Aún no tienes tu GPS agricola (perdonad, pero google se tiene que enterar también)
Para el que no esté al tanto, agroguía es un sistema de guiado GPS para la agricultura, esto es, permite al agricultor en todo momento que zonas ha tratado y cuales no. Parece de perogrullo, pero no es fácil saber por donde has pasado en un terreno con una superfie considerable o mantener una distancia constante a una línea imaginaria.
Ya he escrito bastante acerca de como nos han ido las cosas, los problemas que hemos tenido, anecdotas, casi siempre visto desde el punto de vista de un desarrollador. La verdad que estoy satisfecho, creo que todo ha salido muy bien, pero sobretodo me gusta la idea de que todo lo hemos hecho nosotros: la aplicación, la comercialización, el soporte - que importante es que el desarrollador de soporte al cliente - , al web, la forma de hacer las cosas. Seguramente las hayamos hecho ni medio bien, la gente nos ha criticado hasta la saciedad por no acceder a que lo comercialicen terceros, he llegado hasta a recibir descalificaciones personales, quizas _un poco_ motivada por mi opinión del sector "comercial" (ojo, entrecomillado, nadie se ofenda).
En resumen:
- hemos estado en ferias
- Nos han publicado artículos en varias revistas, que recuerde, además en mapping, tierras y alguna que otra publicación más. La mayor parte de la culpa la tiene Jaime Gómez.
- Hemos visto cosas curiosas, por ejemplo el agricultor que nos preguntó que donde se compraba el líquido naranja, alguna que otra foto, agricultores 2.0.
- Ya hemos llegado al break event ... jaja
- Podemos decir que facturamos, hacienda nos roba lo mismo que a todo el mundo y ahora ya comprendemos a la gente que anda buscando facturas como locos. Puedo afirmar que el negocio da para vivir bien 3 personas, a pesar de los impuestos. Y eso, aunque suene mal lo que voy a escribir, sin lamerle el culo a nadie, aunque eso sí, con ayuda de mucha buena gente.
- Personalmente me ha permitido durante este tiempo poder hacer lo que realmente me ha dado la gana. He programado cuando he querido, he investigado, he hecho las pruebas que he querido. Este es quizás el punto más importante para mi y que precisamente estoy empezando a valorar en su justa medida. Incluso las características que he implementado por puro placer han gustado mucho, en contra de mi pronóstico, y venden.
Se aproxima la tercera temporada y por lo que veo viene muy muy bien. Este año ha habido muy buena cosecha, ha subido el precio de la materia prima y los agricultores no han notado demasiado la subida del carburante (la notarán este periodo). Aún no tienes tu GPS agricola (perdonad, pero google se tiene que enterar también)
9.09.2008
mejor poco y bien que mucho y mal
No hace demasiado hacía referencia al libro de 37signals getting real y cada día que pasa creo que estoy más de acuerdo don ellos. Estaba buscando en el índice del libro un capítulo que ilustrase lo que quiero decir, pero es que creo que todo el libro ilustra lo que quiero decir. Quizás el que mejor lo tiene es "Get something real up and running quickly", esto es, haz algo que funcione.
Cada día que pasa estoy más convencido que el software _necesita_ un proceso de maduración. Mi abuelo hace vino y se tira todo el santo año cuidando el majuelo, poda las parras, las alumbra (1), las injerta (2), ara el majuelo con un arado especial (menos ancho de lo normal), va a menudo a ver que tal va, pone sistemas para que los pájaros con se coman las uvas (por ejemplo los típicos CD's), se pelea con el vecino para que no ponga panales de abejas, lo protege de los paseantes que quieren comerse las uvas cuando esté madura... luego lo vendimia, lo lleva al lagar (3) o la prensa, primero pisa la uva (de ahí sale el mosto más dulce), luego la prensa y mete en los cubetos. Tras varios meses en el que el mosto fermenta y se convierte en vino mi abuelo está pendiente de que nadie entre en la bodega ya que se puede afixiar (el proceso de creación del alcohol es así) ¡¡el vino ya se puede tomar!!
Sin embargo, a pesar de haber trabajado mucho, mi abuelo no queda conforme con su vino, sabe que debe meterlo en botellas de cristal, ponerle unos buenos corchos, etiquetarlas convenientemente (hasta mi abuelo lleva trazabilidad) y esperar laaargos años hasta poder tener un buen vino, el vino por el que todos te felicitan y recuerdan. A veces el corcho no está bien y se pica el vino o resulta que la cosecha no tuvo suficienta azúcar y el vino salió un poco flojo.
Exactamente pasa igual con un producto software, primero se crea y luego se madura. La diferencia es que la madurez del producto se adquiere una vez lo vas dando a probar. Por eso cuanto antes lo des a probar, mejor, y además cuanto menos des a probar, mejor que mejor.
De nada sirve estar un año creando un software con muchos matices si luego, a la hora de la verdad, no funciona muy bien la parte principal. Hace no demasiado presentaban google chrome, todo el mundo ha comentado lo bien que funciona y a pesar de que muchos han echado en falta la posibilidad de incluir pluggins, entre otros, hay buen sabor de boca, incluso se ha destacado su minimalismo.
Como desarrollador tiene también sus ventajas, sientes que has hecho algo redondo, que funciona y que es completamente usable. No hay peor sensación que la de estar frente a un sistema mastodóntico, que no sabes muy bien como funciona y que "a veces" (cuando pasa esto siempre se asocia a un fallo de sincronización de hilos) no "tira" como debería. Poner a funcionar un sistema simple es ya de por sí difícil, así que no me quiero imaginar si además el propio sistema te pone la zancadilla.
Lo mejor es que todo esto lo puedes aplicar a cada clase/fichero/subsistema :).
(1) alumbrar es hacer un hueco debajo de la planta para que el agua se acumule allí.
(2) hacer una especie de lego con las plantas, se deja la raiz de una y se acuña otro tipo de planta sobre ella, es realmente curioso, algo así como un frankestein.
(3) lugar donde se pisa la uva
Cada día que pasa estoy más convencido que el software _necesita_ un proceso de maduración. Mi abuelo hace vino y se tira todo el santo año cuidando el majuelo, poda las parras, las alumbra (1), las injerta (2), ara el majuelo con un arado especial (menos ancho de lo normal), va a menudo a ver que tal va, pone sistemas para que los pájaros con se coman las uvas (por ejemplo los típicos CD's), se pelea con el vecino para que no ponga panales de abejas, lo protege de los paseantes que quieren comerse las uvas cuando esté madura... luego lo vendimia, lo lleva al lagar (3) o la prensa, primero pisa la uva (de ahí sale el mosto más dulce), luego la prensa y mete en los cubetos. Tras varios meses en el que el mosto fermenta y se convierte en vino mi abuelo está pendiente de que nadie entre en la bodega ya que se puede afixiar (el proceso de creación del alcohol es así) ¡¡el vino ya se puede tomar!!
Sin embargo, a pesar de haber trabajado mucho, mi abuelo no queda conforme con su vino, sabe que debe meterlo en botellas de cristal, ponerle unos buenos corchos, etiquetarlas convenientemente (hasta mi abuelo lleva trazabilidad) y esperar laaargos años hasta poder tener un buen vino, el vino por el que todos te felicitan y recuerdan. A veces el corcho no está bien y se pica el vino o resulta que la cosecha no tuvo suficienta azúcar y el vino salió un poco flojo.
Exactamente pasa igual con un producto software, primero se crea y luego se madura. La diferencia es que la madurez del producto se adquiere una vez lo vas dando a probar. Por eso cuanto antes lo des a probar, mejor, y además cuanto menos des a probar, mejor que mejor.
De nada sirve estar un año creando un software con muchos matices si luego, a la hora de la verdad, no funciona muy bien la parte principal. Hace no demasiado presentaban google chrome, todo el mundo ha comentado lo bien que funciona y a pesar de que muchos han echado en falta la posibilidad de incluir pluggins, entre otros, hay buen sabor de boca, incluso se ha destacado su minimalismo.
Como desarrollador tiene también sus ventajas, sientes que has hecho algo redondo, que funciona y que es completamente usable. No hay peor sensación que la de estar frente a un sistema mastodóntico, que no sabes muy bien como funciona y que "a veces" (cuando pasa esto siempre se asocia a un fallo de sincronización de hilos) no "tira" como debería. Poner a funcionar un sistema simple es ya de por sí difícil, así que no me quiero imaginar si además el propio sistema te pone la zancadilla.
Lo mejor es que todo esto lo puedes aplicar a cada clase/fichero/subsistema :).
(1) alumbrar es hacer un hueco debajo de la planta para que el agua se acumule allí.
(2) hacer una especie de lego con las plantas, se deja la raiz de una y se acuña otro tipo de planta sobre ella, es realmente curioso, algo así como un frankestein.
(3) lugar donde se pisa la uva
8.31.2008
Se acabaron las vacaciones, conclusiones
Sí, este es el típico post del típico trabajador de la tecla que termina sus vacaciones...
Fundamentalmente he dividido el periodo en dos, el primero de ellos lo he pasado en un hotel-spa situado en Sesimbra (Portugal), unos 30 km al sur de Lisboa. El sitio muy bonito, una playa para pasear con el agua helada, pegando a un parque natural y con muy buena comida. Ya había estado de gira por Portugal, pero no ha dejado de sorprenderme la ausencia de radares fijos en autovía, las patatas hasta en la sopa y alguna que otra cosa. Una semana en la que creo que he hecho eso que denominan desconectar, esto es, no me he llevado el PC, PDA, ni he usado la wifi del móvil.
La segunda semana he estado en mi pueblo, pintando y adecentando mi habitación. Increíble lo difícil que puede ser hacer tareas manuales tan aparentemente simples como pasar un rodillo o tapar los agujeros provocados por mis antiguos posters. Ha sido un duro golpe quitar los posters de sega rally y tomb raider.
En resumen, lo de las vacaciones está muy bien, pero creo que soy animal de costumbres, me gusta más modificar mi rutina que cambiarla por completo. Me he dado cuenta de bastantes cosas:
- No hacer nada es una parte muy importante de la vida. Hacía tiempo que no me sentía bien sin estar haciendo nada.
- Me da igual estar al día. El día que llegué puse como leídos todos los post en mi bloglines, borré todos los correos no importantes (listas de correo, etc) y no ha pasado nada. Es más, he borrado la mayoría de los feeds a los que estaba suscrito... menudo peso de encima me he quitado de encima. Jo-der, que agusto
- Trabajo demasiado, es más, malgasto mi tiempo trabajando :)
Y no, no he recargado las pilas
Fundamentalmente he dividido el periodo en dos, el primero de ellos lo he pasado en un hotel-spa situado en Sesimbra (Portugal), unos 30 km al sur de Lisboa. El sitio muy bonito, una playa para pasear con el agua helada, pegando a un parque natural y con muy buena comida. Ya había estado de gira por Portugal, pero no ha dejado de sorprenderme la ausencia de radares fijos en autovía, las patatas hasta en la sopa y alguna que otra cosa. Una semana en la que creo que he hecho eso que denominan desconectar, esto es, no me he llevado el PC, PDA, ni he usado la wifi del móvil.
La segunda semana he estado en mi pueblo, pintando y adecentando mi habitación. Increíble lo difícil que puede ser hacer tareas manuales tan aparentemente simples como pasar un rodillo o tapar los agujeros provocados por mis antiguos posters. Ha sido un duro golpe quitar los posters de sega rally y tomb raider.
En resumen, lo de las vacaciones está muy bien, pero creo que soy animal de costumbres, me gusta más modificar mi rutina que cambiarla por completo. Me he dado cuenta de bastantes cosas:
- No hacer nada es una parte muy importante de la vida. Hacía tiempo que no me sentía bien sin estar haciendo nada.
- Me da igual estar al día. El día que llegué puse como leídos todos los post en mi bloglines, borré todos los correos no importantes (listas de correo, etc) y no ha pasado nada. Es más, he borrado la mayoría de los feeds a los que estaba suscrito... menudo peso de encima me he quitado de encima. Jo-der, que agusto
- Trabajo demasiado, es más, malgasto mi tiempo trabajando :)
Y no, no he recargado las pilas
8.25.2008
más reprogramaciones de centralita
Jajaja, lo sabía, sabía que algo no estaba funcionando bien. Acabo de recibir una carta de renault diciendome que tengo que ir a reprogramar la centralita de mi megane (releo es post y eché gasoil a 0.88) debido a que la anterior programación no solventaba los problemas que trabaja de corregir... :).
Para renault es una GRAN CAGADA, me imagino los gastos: por cada motor dCi vendido en un determinado periodo de tiempo han tenido que enviar una carta certificada a la persona (y buscarla si el coche ha cambiado de propietario), horas de ingeniero para corregir el problema, horas de calidad, horas de taller (que son cobradas a cojón de ovispo), malestar del comprador y eso por no hablar de los motores quemados a cuenta del problema.
He hablado ya algunas veces de los bugs que surgen en producción y lo importante de la trazabilidad. Punto negativo para renault por cometer un error el diseño del vehículo (cosas de industriales) que al final tiene que venir a corregir un trozo de software y otro punto negativo por el control de calidad que pasó la anterior reprogramación. Pero un buen punto positivo porque mantienen una trazabilidad bastante decente. Sería delito que las punteras en este tipo de cosas no lo hicieran, aún así es de agradecer.
Por cierto, desde renault no se han dignado a contestarme al correo que les envié solicitándoles que, por dios, mejorasen el mapeo acelerador -> inyección. He encontrado algunos circuítuos basados en filtros y aplificadores que corrigen ese problemas, pero tampoco es cuestión de meter electrónica si es posible modificarlo por software. Daré de nuevo la chapa con el tema a ver si consigo que me lo reprogramen con los parámetros que yo quiero.
Para renault es una GRAN CAGADA, me imagino los gastos: por cada motor dCi vendido en un determinado periodo de tiempo han tenido que enviar una carta certificada a la persona (y buscarla si el coche ha cambiado de propietario), horas de ingeniero para corregir el problema, horas de calidad, horas de taller (que son cobradas a cojón de ovispo), malestar del comprador y eso por no hablar de los motores quemados a cuenta del problema.
He hablado ya algunas veces de los bugs que surgen en producción y lo importante de la trazabilidad. Punto negativo para renault por cometer un error el diseño del vehículo (cosas de industriales) que al final tiene que venir a corregir un trozo de software y otro punto negativo por el control de calidad que pasó la anterior reprogramación. Pero un buen punto positivo porque mantienen una trazabilidad bastante decente. Sería delito que las punteras en este tipo de cosas no lo hicieran, aún así es de agradecer.
Por cierto, desde renault no se han dignado a contestarme al correo que les envié solicitándoles que, por dios, mejorasen el mapeo acelerador -> inyección. He encontrado algunos circuítuos basados en filtros y aplificadores que corrigen ese problemas, pero tampoco es cuestión de meter electrónica si es posible modificarlo por software. Daré de nuevo la chapa con el tema a ver si consigo que me lo reprogramen con los parámetros que yo quiero.
planificación inconsciente en desarrollo de software
Estoy leyendo el libro "práctica de la inteligencia emocional", una referencia según la gente que parece que sabe del tema. En uno de los capítulos hacen referencia a la toma de decisiones, como actúan las diferentes partes del cerebro, como se reaciona en diversas situaciones (estrés, tranquilidad, etc) y en qué forma las tomamos. En resumen habla de dos formas, una de ellas meditada y consciente y otra de ellas inconsciente.
La primera de ellas viene a ser las decisiones en las que razonamos en base a lo que vemos y la segunda es en base a un tick, al sexto sentido o como lo quiera que se llame. Cuantas veces me ha pasado que "algo" me decía que no debía hacer algo, finalmente lo hice razonando la decisión y al final la mangué. El libro da explicación a esto: el cerebro, subconcientemente, es capaz de dar resultados a tomas de decisiones muy rápidamente en base a la experiencia vivida anteriormente.
Actualmente estoy dentro de una implantación de CMM2, en la cual me han indicado que tenía que dar una serie de patrones para esblecer el tamaño y complejidad de una tarea dentro del proyecto del que soy responsable (en realidad soy juez y parte :P), de esta forma, gracias a estas medidas y la experiencia acumulada a lo largo del tiempo en diferentes tareas se pueda extrapolar el tiempo en una futura tarea.
Realmente esto es bonito, da igual quien esté que si alguien planifica una tarea, el tiempo se podrá estimar, con un ratio de error, toda la maquinaria funcionará perfectamente en base al conocimiento plasmado en tablas de datos, sobre tiempos, complejidades, tamaños y demás.
Lo cierto es que mi cerebro ya hace eso, cuando alguien me pregunta "oye, cuánto crees que tardarás en hacer tal cosa", mi cerebro ya sabe qué preguntas debo hacer, por donde pueden venir los problemas y cuando tiempo puedo tardar. Y lo mejor, a medida que pasa el tiempo lo hago mejor e incluso me dice el tiempo que podría tardar otra persona. Mi cerebro está tomando decisiones sin que yo tenga que pensar, mi sexto sentido programadoril (R) me dice lo que está pasando cual sentido aracnido a espiderman, de ahí la introducción de este post.
Esto no es tan bonito cara a una empresa, si el fulano encargado de hacer esas estimaciones se va, la empresa se queda en bragas, así que quizás un modelo híbrido sea lo mejor, sobretodo para pequeñas empresas, aunque en este caso, y como opinión personal, me vale más la opinión de una persona con experiencia que mil hojas de excel y mucho más en entornos con cambios rápidos de requisitos.
La primera de ellas viene a ser las decisiones en las que razonamos en base a lo que vemos y la segunda es en base a un tick, al sexto sentido o como lo quiera que se llame. Cuantas veces me ha pasado que "algo" me decía que no debía hacer algo, finalmente lo hice razonando la decisión y al final la mangué. El libro da explicación a esto: el cerebro, subconcientemente, es capaz de dar resultados a tomas de decisiones muy rápidamente en base a la experiencia vivida anteriormente.
Actualmente estoy dentro de una implantación de CMM2, en la cual me han indicado que tenía que dar una serie de patrones para esblecer el tamaño y complejidad de una tarea dentro del proyecto del que soy responsable (en realidad soy juez y parte :P), de esta forma, gracias a estas medidas y la experiencia acumulada a lo largo del tiempo en diferentes tareas se pueda extrapolar el tiempo en una futura tarea.
Realmente esto es bonito, da igual quien esté que si alguien planifica una tarea, el tiempo se podrá estimar, con un ratio de error, toda la maquinaria funcionará perfectamente en base al conocimiento plasmado en tablas de datos, sobre tiempos, complejidades, tamaños y demás.
Lo cierto es que mi cerebro ya hace eso, cuando alguien me pregunta "oye, cuánto crees que tardarás en hacer tal cosa", mi cerebro ya sabe qué preguntas debo hacer, por donde pueden venir los problemas y cuando tiempo puedo tardar. Y lo mejor, a medida que pasa el tiempo lo hago mejor e incluso me dice el tiempo que podría tardar otra persona. Mi cerebro está tomando decisiones sin que yo tenga que pensar, mi sexto sentido programadoril (R) me dice lo que está pasando cual sentido aracnido a espiderman, de ahí la introducción de este post.
Esto no es tan bonito cara a una empresa, si el fulano encargado de hacer esas estimaciones se va, la empresa se queda en bragas, así que quizás un modelo híbrido sea lo mejor, sobretodo para pequeñas empresas, aunque en este caso, y como opinión personal, me vale más la opinión de una persona con experiencia que mil hojas de excel y mucho más en entornos con cambios rápidos de requisitos.
8.24.2008
Mis últimas lecturas
En los últimos meses he leído dos libros sobre desarrollo de software, en mi opinión, imprescindibles. Los dos son "de perogrullo", dicen cosas de sentido común, cosas que a medida que programas te has ido dando cuenta, pero que muchas veces no eres capaz de condensar y plasmar tan bien como lo hacen en sendos libros.
El primero de ellos es "The pragmatic programmer". Si eres cristiano debes leer la biblia, si programas en C++ debes leer effective and more effetive C++ y si eres programador __tienes__ que leer este libro. No voy a resumir el libro, ya hay muchas opiniones en internet acerca de él. Te recomiendo que leas algún que otro capítulo y verás que dice verdades como puños, tantas que es imposible llevarlas todas a cabo :)
El segundo de ellos es "getting real", de 37signals , creadores de ror y cuyo blog (con curiosa url por cierto) es muy recomdable. Se puede leer online y pasa algo parecido que con el anterior, verdades como puños. En resumen habla un poco de como desarrollar de forma eficiente, pragmatismo puro en proyectos de desarrollo de software, sobretodo orientados a web, aunque muy válidos para cualquier proyecto no web e incluso no software. Ciertamente hay que tener una perspectiva un poco diferente, a mi me recuerda al equipo-A en la forma de trabajar :). El libro en si mismo refleja el pragmatismo (meta-pragmatismo), capítulos bien separados, fácil de leer y con ejemplos reales.
Son libros para tener de cabecera, para releer de vez en cuando, para tomar notas sobre ellos y para ir aplicando poco a poco. A medida que adquiero más experiencia desarrollando me voy dando cuenta que esos pasos ya los dieron los escritores de esos libros, los plasmaron y resumieron.
Ahora voy a ver si me leo "practices of an agile developer" que me ha recomendado félix.
PD: Se acabaron mis vacaciones ... :)
El primero de ellos es "The pragmatic programmer". Si eres cristiano debes leer la biblia, si programas en C++ debes leer effective and more effetive C++ y si eres programador __tienes__ que leer este libro. No voy a resumir el libro, ya hay muchas opiniones en internet acerca de él. Te recomiendo que leas algún que otro capítulo y verás que dice verdades como puños, tantas que es imposible llevarlas todas a cabo :)
El segundo de ellos es "getting real", de 37signals , creadores de ror y cuyo blog (con curiosa url por cierto) es muy recomdable. Se puede leer online y pasa algo parecido que con el anterior, verdades como puños. En resumen habla un poco de como desarrollar de forma eficiente, pragmatismo puro en proyectos de desarrollo de software, sobretodo orientados a web, aunque muy válidos para cualquier proyecto no web e incluso no software. Ciertamente hay que tener una perspectiva un poco diferente, a mi me recuerda al equipo-A en la forma de trabajar :). El libro en si mismo refleja el pragmatismo (meta-pragmatismo), capítulos bien separados, fácil de leer y con ejemplos reales.
Son libros para tener de cabecera, para releer de vez en cuando, para tomar notas sobre ellos y para ir aplicando poco a poco. A medida que adquiero más experiencia desarrollando me voy dando cuenta que esos pasos ya los dieron los escritores de esos libros, los plasmaron y resumieron.
Ahora voy a ver si me leo "practices of an agile developer" que me ha recomendado félix.
PD: Se acabaron mis vacaciones ... :)
8.16.2008
vacaciones
Estoy y me voy de vacaciones, este año toca a la zona sur de portugal, a ver si consigo descansar y desconectar (topicazo donde los haya).
Este año ha sido duro, he tenido mucho trabajo, quizás mucho más del que realmente he podido abordar. Con perspectiva realmente las cosas han salido bien y muchas veces he hecho que problemas con no lo eran tanto, sobretodo con agroguía (sistema de guiado con GPS). A toro pasado todos somos manolete, es muy fácil ver ahora los errores que me cometido: afixiarme de trabajo por nada, correr cuando no era necesario, creer que lo importante era mucho más importante de lo debido, etc. Son cosas que con la experiencia se mejoran, además, por suerte es un error muy común (mal de muchos...) en las empresas.
El error más grande que he cometido, de largo, ha sido trabajar demasiado y estar a muchas más cosas de las que realmente puedo controlar. Durante estos últimas semanas he notado cierta quemazón, pero es algo que tenía que pasar, es un testigo de que algo no estoy haciendo bien y por suerte creo que me voy dando cuenta de los errores y voy corrigiendolos. Obviamente no toda la culpa es mía, pero las circunstancias empiezan a ser problema tuyo cuando no las sabes manejar como deben.
Son 15 días que voy a usar para directamente no pensar. Hace unas semanas hubiera dedicado estas vacaciones para hacer algo en agroguía o pensar sobre vaya usted a saber. Pero no, lo voy a dedicar a leer el libro que mi buen amigo Alberto me regaló y descansar a dos manos :D.
Cuando venga hará dos años que pusimos agroguía en funcionamiento, voy a prepararme un post resumen con todo lo que hemos hecho y lo que tengo pensado hacer.
Este año ha sido duro, he tenido mucho trabajo, quizás mucho más del que realmente he podido abordar. Con perspectiva realmente las cosas han salido bien y muchas veces he hecho que problemas con no lo eran tanto, sobretodo con agroguía (sistema de guiado con GPS). A toro pasado todos somos manolete, es muy fácil ver ahora los errores que me cometido: afixiarme de trabajo por nada, correr cuando no era necesario, creer que lo importante era mucho más importante de lo debido, etc. Son cosas que con la experiencia se mejoran, además, por suerte es un error muy común (mal de muchos...) en las empresas.
El error más grande que he cometido, de largo, ha sido trabajar demasiado y estar a muchas más cosas de las que realmente puedo controlar. Durante estos últimas semanas he notado cierta quemazón, pero es algo que tenía que pasar, es un testigo de que algo no estoy haciendo bien y por suerte creo que me voy dando cuenta de los errores y voy corrigiendolos. Obviamente no toda la culpa es mía, pero las circunstancias empiezan a ser problema tuyo cuando no las sabes manejar como deben.
Son 15 días que voy a usar para directamente no pensar. Hace unas semanas hubiera dedicado estas vacaciones para hacer algo en agroguía o pensar sobre vaya usted a saber. Pero no, lo voy a dedicar a leer el libro que mi buen amigo Alberto me regaló y descansar a dos manos :D.
Cuando venga hará dos años que pusimos agroguía en funcionamiento, voy a prepararme un post resumen con todo lo que hemos hecho y lo que tengo pensado hacer.
8.13.2008
Caché Opengl con Python
Los decorators en python son tremendamente útiles, cada día veo cosas más interesantes creadas con decoratos. Últimamente sobretodo relacionadas con Django (me imagino que por su pronta 1.0), para temas de cachés.
Como python es bastante más lento que C++, cuando renderizo geometría estático con python la máquina tiende a morirse donde con c++ iría suavemente. Lo habitual en OpenGL es usar listas precompiladas para optimizar geometría estática, una especie de caché que deja en gpu los datos a renderizar.
tenemos el siguiente método:
Nada impide hacer el siguiente decorator:
def list_compiler(fn):
fn.__gl_compiled = -1;
def render():
if(fn.__gl_compiled < 0):
fn.__gl_compiled = glGenLists(1);
glNewList(fn.__gl_compiled,GL_COMPILE);
fn();
glEndList();
else:
glCallList(fn.__gl_compiled);
return render;
de esta forma decoramos el método:
@list_compiler
def draw_complex_geometry()...
De forma que la primera vez que se llame compilará ls lista opengl y las siguientes veces símplemente llamará a la geometría "cacheada"
Como python es bastante más lento que C++, cuando renderizo geometría estático con python la máquina tiende a morirse donde con c++ iría suavemente. Lo habitual en OpenGL es usar listas precompiladas para optimizar geometría estática, una especie de caché que deja en gpu los datos a renderizar.
tenemos el siguiente método:
def draw_complex_geometry():
glBegin(GL_QUADS);
for x in vertex:
....
glEnd();
Nada impide hacer el siguiente decorator:
def list_compiler(fn):
fn.__gl_compiled = -1;
def render():
if(fn.__gl_compiled < 0):
fn.__gl_compiled = glGenLists(1);
glNewList(fn.__gl_compiled,GL_COMPILE);
fn();
glEndList();
else:
glCallList(fn.__gl_compiled);
return render;
de esta forma decoramos el método:
@list_compiler
def draw_complex_geometry()...
De forma que la primera vez que se llame compilará ls lista opengl y las siguientes veces símplemente llamará a la geometría "cacheada"
Etiquetas:
opengl,
programacion,
python
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 :)
Etiquetas:
internacionalización,
programación,
unicode
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"
Suscribirse a:
Entradas (Atom)