Últimamente no he escrito demasiado, las principales razones: un final de año en el trabajo que ha absorvido la mayoría de mi tiempo, acabar unas prácticas para la universidad y ésta última semana de merecidas vacaciones , que he conseguido desconectar casi del todo, he empezado a leer el libro The Pragmatic Programmer.

En el primer capítulo(A pragmatic philosophy) habla, entre otras cosas, de invertir en tu portfolio de conocimientos, nuestra experiencia y nuestro conocimiento son nuestros activos más importantes, y da algunas recomendaciones de cómo hacerlo. Y aprovechando que se acaba el año me los pongo como propósitos para 2008.

• Conocer un lenguaje cada año: Diferentes lenguajes resuelven de diferentes formas los mismos problemas, de esta manera, puedes tener un punto de vista más amplio para resolver un problema. Este año espero tener tiempo para empezar con Ruby(RoR) y con Groovy(Grails).
• Leer un libro técnico cada 3 meses: En principio recomiendan leer sobre tecnologías con las que trabajas normalmente, pero también que cuando las domines realmente, cambies y estudies otras diferentes a las que estés acostumbrado. Veremos cuando acabe éste libro, que libros interesantes hay por ahí.
• Leer también algún libro no técnico: Hay que recordar que los ordenadores los usan las personas, como no soy demasiado aficionado a la literatura me dejaré recomendar.
• Asistir a clases: A ver si tengo tiempo(y me seleccionan) para asistir a algún curso del CTA, no conozco muchos más que puedan resultarme interesantes.
• Participa en grupos de usuarios locales: Con intención de hacerlo activamente, por aquí esto está complicado, están hispalinux y cadius, que serían lo más parecido, pero que yo sepa nada de puramente para programadores. Aunque de forma online, seguiré participando activamente en todo lo que pueda en JavaConGanas, que podría ser lo más parecido a ésto.
• Experimenta en diferentes entornos: A ver si este año por fin me cambio a usar Linux como mi SO principal, y en casa pruebo a fondo con IDEA y NetBeans.
• Mantente actualizado: Sigo portales como javaHispano, infoQ y TheServerSide además de bastantes blogs que tocan temas de actualidad TI ¿Recomendaciones?.
• Mantente conectado: Para encontrar gente que domine alguna tecnología, para esto ya utilizo sitios como los foros de javahispano, forosdelweb… Además de buscar información en internet, para esto además de los buscadores, mis contactos en del.icio.us me ayudan muchísimo:P.

Aparte de todas estas recomendaciones, que no son pocas, me apunto dos más.

• Aprende/Mejora tu inglés: Esto no lo comentan en el libro más que nada por que los autores son anglosajones , pero los que no dominamos demasiado el idioma debemos de hacer un esfuerzo en mejorar. Evidentemente la mayoría de documentación/libros aparecen en inglés primero y en muchas ocasiones no se llegan a traducir nunca, además así no nos limitamos a comunicarnos sólo con hispanohablantes.
• Colabora en algún proyecto open source: De ésta forma, además de aumentar tu portfolio de conocimentos, aumentas tu experiencia. También tiene alguna otra ventaja, como licencias gratuitas de herramientas de pago para utilizarlas en proyectos open source.

Bueno, ahora ya sólo me queda desearos a todos un feliz 2008, y cuidado con la resaca

Acabo de leer en el blog beautifulcode, una interesante entrada de Michael Feathers sobre el control de errores.

El post comienza con éste párrafo, que traduzco libremente: “El control de errores es un poco cómo discutir quién saca la basura. Todos sabemos que hay que hacerlo, pero no dedicamos demasiado tiempo en pensar en cómo hacerlo.”

Habla sobre trusted zones (zonas de confianza), en éstas zonas de nuestro código, no deben existir comprobaciones, únicamente la lógica de lo que estemos desarrollando, de ésta forma conseguimos un código más limpio y mantenible.
Si desarrollas librerías o frameworks, como no tienes control sobre cómo van a ser utilizados, sólo puedes hacerlo de forma confiada tus zonas de confianza no pueden ser muy amplias. Mientras si desarrollas una aplicación, debes tratar de separar el control de errores todo lo que sea posible de la lógica de negocio. El control de errores debe ser una cuestión de diseño, no algo de última hora.

Vamos, que por lo que parece utilizar trusted zones es una idea similar al diseño por contrato, pero sin contrato (sin precondiciones, invariantes o postcondiciones), y así evitar la programación defensiva para tener mejor código, más “beautiful”

Hasta no hace demasiado, pensaba que los documentos de textos eran una herramienta bastante válida para la creación y consulta de análisis funcionales basados en casos de uso. Eso sí, trabajando en aplicaciones de tamaño medio o incluso en servicios/módulos con funcionalidades muy específicas para aplicaciones grandes.

Actualmente estoy trabajando en un proyecto grande, y por ello se dividen los análisis funcionales en diferentes documentos de texto. Hasta ahí no tendría por qué haber ningún problema, ya que están divididos por subsistema para no tener un macro-documento funcional. Pero en este caso no es así, por que en muchos de los diferentes subsistemas, se encuentran repetidos casos de uso.

Esto es, que encuentras copy/paste de la descripción de un mismo caso de uso en diferentes documentos, y ésto en mi opinión nos lleva a dos grandes problemas:
- Problemas del mantenimiento del caso de uso para el analista, que debe controlar en qué documentos se repite para no perder coherencia.
- Desconocimento por parte del desarrollador de si es o no exáctamente el mismo caso de uso, debe comparar varios documentos, y aquí podemos heredar el problema de si están correctamente actualizados los documentos o no, lo que conlleva a péridas de tiempo y a posibles errores funcionales o duplicación de código.

Por otro lado, un compañero me ha prestado el libro UML Distilled(en mi caso la second edition) de Martin Fowler, muy recomendable por lo que he leído hasta el momento, sobre todo para los que no tenemos demasiados conocimentos sobre UML, y que además toca otros temas interesantes sobre desarrollo de software, aunque de forma superficial, como Extreme programming, diseño por contrato… En éste libro, encontramos en el tercer capítulo el tema de los casos de uso, y nos encontramos con que UML soluciona éste problema, forma similar a cómo lo haríamos programando, con los includes.

Un include es un tipo de relación de casos de uso (las otras relaciones serían generalization y extend), que como hemos comentado sería algo así a como lo haríamos programando, entonces llegamos a la conclusión que sí, se podría hacer en un documento de texto por ejemplo de ésta forma:”CU X ir a documento Y CU Z“, que claro sigue teniendo el problema de mantenimiento del documento, puede cambiar el nombre del documento, el nombre del caso de uso…

Todo ésto me lleva a hacerme un par de preguntas, ¿existen herramientas para la gestión correcta de casos de uso? ¿open source ?