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
Suscribirse a:
Entradas (Atom)