domingo febrero 05, 2006
domingo febrero 05, 2006
Librería de aspectos con AspectJ 5
Hace menos de un mes se publico el interesantísimo artículo Check out library aspects with AspectJ 5 en la serie de artículos sobre AOP de developerWorks: AOP@Work. Este artículo, escrito por Wes Isberg, ofrece una visión muy clara de las distintas posibilidades que nos ofrece usar AOP.
En entradas anteriores he comentado mi cierto escepticismo por el uso real de AOP/AOSD tal cual. Sigo pensando que la gran implantación se centrará en servidores de aplicaciones, contenedores de servicios, frameworks, etc. Mientras que a corto plazo veo muy difícil que un ingeniero desde el análisis tenga en mente los aspectos.
El artículo se posiciona en el no tan cómodo término medio. Usar aspectos de forma consciente para ciertas tareas. Si atendemos a las cifras de descargas de AspectJ Development Tools (AJDT), un interfaz gráfico para AOP que se integra perfectamente en Eclipse, como comenta Ron Bodkin en su blog, esto no es en absoluto descabellado.
Además del artículo en si, su código fuente nos ofrece una colección de ejemplos, siempre bienvenida para los que nos iniciamos en el uso de AspectJ 5.
Recomiendo encarecidamente la lectura de este articulo que intenta ser ameno, a la par que educativo y práctico. Y por supuesto, recomiendo empezar a desarrollar nuestras propias librerías (bibliotecas) de aspectos, y a compartirlas con los demás. Utilizar aspectos puede ser MUY PRÁCTICO en infinidad de casos,
Una vez más, y no me cansaré de repetirlo, animar a la gente que lea esto, a escribir algún comentario y poder intercambiar impresiones. De todas formas, amigo lector, gracias por invertir tu tiempo con esto. 
Posted at 01:13PM feb 05, 2006 by Ricardo Santamaría Bogónez in AOP | Comentarios[0]
Estrés, DesperatingException y otros compañeros
No, no voy a hablar de los test de Stress (ver tutorial en jH y proyecto JMeter). DesperatingExcepcion es una clase que instancio con demasiada frecuencia en el comportamiento de mi "sistema software", empiezo a pensar que el nombre de esa clase es erróneo, de excepción tiene poco.
Ayer me sucedió una cosa curiosa. Iba yo al trabajo tranquilamente y me disponía, como hago habitualmente, a coger mi ejemplar de 20minutos, que extraño pensé, la chica que los reparte no está, será porque es viernes. Avanzo unos metros más y pienso en la poca gente que hay por la calle, me da por mirar el móvil y...¡era una hora antes!. Se me quedo la misma cara de gilipollas que el día anterior cuando el examinador me cargo el carné de conducir. Eso si, recomiendo un paseo por Valladolid a las 6:30 un día laborable, si no te importa el frió.
Hace mucho que no escribo por aquí, mitad falta de tiempo, mitad pereza. Pero hoy intentaré hacer un resumen/reflexión de todos los fregados en los que ando metido y aprovechar para ordenar mi mente que se nota que lo necesito 
.
Entre otras cosas, "gasto" mi tiempo sacando el Certificado de Aptitud Pedagógica (todo el mundo lo conoce por CAP). He tenido suerte, las prácticas me han tocado en el ciclo formativo de Grado Superior de Desarrollo de Aplicaciones Informáticas (DSI) y más concretamente en el módulo/asignatura de programación.
Oooh, si, enseñar a programar en Java. La verdad es que me gusta, ojala tuviera más tiempo para dejarlo de ver como un compromiso y verlo como una experiencia.
Envidio en cierta manera a los alumnos de ese modulo, a mi nunca me enseñaron a programar en Java, y es más, creo que entre todas las asignaturas de programación de la Técnica y la Superior nadie me ha enseñado a programar, pero ese es otro tema.
Por si a alguien le interesa utilizan las siguientes herramientas:
Ya contaré que tal dando la clase de javadoc. Seguro que dejo la documentación por aquí.
De mi pequeña experiencia laboral hay varias cosas que tengo claras. Una de ellas es que es muy muy conveniente tener:
- Un prototipo de la interfaz de usuario
- Una arquitectura de la aplicación sólida
- Un modelo de datos CORRECTO (que la base de datos tenga sentido)
- Tener claro el workflow del proceso que estas automatizando
Los prototipos siempre son peligrosos, dan al cliente una falsa sensación de la situación del proyecto y lo que queda por hacer. Además hay que tener mucho cuidado reutilizando ese prototipo. La pregunta del millón es ¿los prototipos IU se deben reutilizar?. En mi caso, el interfaz era web y, bueno, la reutilización va bien pero esto no siempre es así.
Sin embargo la información que nos aporta tener el prototipo IU tanto a desarrolladores como al cliente NO si tiene precio.
La arquitectura de la aplicación debe ser sólida, y la elección de tecnologías coherente (conocimiento por parte del equipo de desarrollo, entorno de producción, licencias, estabilidad, madurez...). Para mi este es uno de los puntos cruciales para tener un final feliz y a la vez uno de los mayores quebraderos de cabeza.
El modelo de datos tiene que ser correcto (no hace falta que este en la 5ª Forma Normal 
) y se debe pensar en un modelo físico eficiente. Si el sistema hace uso intensivo de una base de datos no esta demás dedicar un tiempo a tareas de optimización y análisis de los planes de ejecución de las consultas más complejas. Se puede mejorar el rendimiento sin necesidad de caches que complican el sistema software.
Lo del workflow es lógico, si no sabes como funciona, el famoso KNOW HOW, como vas a automatizarlo. Aunque ojala fuera todo tan sencillo. Cuidado con clientes que no saben como funcionan las cosas. Esto es muy habitual cuando trabajas para la Administración Pública.
Otra cosa que he aprendido es que para que un equipo de trabajo funcione se deben dar las siguientes condiciones:
- Debe existir una jerarquía, preferiblemente lo más plana posible y dialogante. Además de una jerarquía es necesario definir claramente los puestos, funciones y responsabilidades de cada integrante del equipo.
- Es necesario un "jefe" que realice una supervisión de la marcha del proyecto y que tenga capacidad de decisión para dar la "última palabra". Bueno, hay muchas clases de jefe.
- La comunicación entre los integrantes del grupo debe ser fluida. No se puede ocultar información.
- Tiene que existir "buen rollo" en el equipo, esto facilitará la comunicación y el apoyo entre compañeros a la vez que hace más fácil la vida laboral.
- La documentación es vital. Debe haber un buen análisis, un buen diseño, y seguir unas buenas prácticas a la hora de codificar.
- Es necesario tener el soporte de herramientas como gestores de versiones (cvs, subversion,...).
Y no puedo callarme, tengo que hacer el siguiente comentario. ODIO que la gente haga aplicaciones web para todo. Que nadie entienda mal, pero estoy HARTO de que muchas aplicaciones se tengan que hacer web por narices. Señores, html es html, javascript apesta y el protocolo HTTP esta bien pero tiene muchas carencias (falta de estado,...).
Tan cansado estoy de eso como de RoR, AJAX y similares. Hace unos meses y al hilo de una noticia comentábamos en jH que no hay un framework definitivo para aplicaciones web. El problema no esta en los framework actuales si no en el problemón que intentan resolver para suplicar la carencia de las capas inferiores. Tal vez la respuesta sea XUL o XForms o quien sabe qué.
Supongo que es por todo esto que he comentado anteriormente, por lo que me gustaría apostar por los JavaServer Faces. Mi sueño es poder desarrollar aplicaciones web como desarrollaba las aplicaciones de escritorio con Borland C++ Builder o como parece que se pueden desarrollar hoy día en java con Matisse . Y que luego se "traduzcan" mediante renders en (x)html+javascript (con o sin AJAX) o XUL o lo que toque.
Otra cosa que me gustaría comentar, es el "nuevo mundo" de los microkernels y microcontenedores. Hace tiempo estuve investigando un poco en este mundillo debido a mi faraónico proyecto. Por cierto, la próxima vez, que no habrá próxima vez, propongo el típico proyecto de página web + BD y a correr. Como iba diciendo, esta semana ha vuelto a mi mente gracias al proyecto OCAS.
El concepto no es nuevo ya que en cierta medida es lo mismo que se ha venido haciendo con JMX en los servidores de aplicaciones. ¿Es hora de jubilar JMX para este cometido?. La verdad es que yo no lo tengo muy claro. Los microcontenedores basados en IoC están arrasando a la hora de dar soluciones a POJO, pero parece que los grandes servidores siguen apostando por JMX. Además JMX cada vez esta más integrado en el JSE. ¿JMX esta pensado para ser microkernel?. Yo creo que no, que simplemente ha cubierto un vació que existía y ahora es difícil que los grandes servidores refactoricen sus microkernels a soluciones IoC.
Si a alguien le interesa mi opinión, que hasta puede ser posible, aprovechando el cambio que se esta produciendo en EJB 3 (anotaciones,...) y la importancia y madurez de las soluciones POJO modificaría la arquitectura de los servidores por microkernels IoC + servicios proporcionados mediante aspectos.
Bueno, esta entrada es extremadamente larga y densa al igual que los desvaríos de este pobre "javero" aprendiz de mucho y conocedor de poco. Por último sugerir la lectura de una novela juvenil, que releí el otro fin de semana aprovechando que mi salud no estaba en su momento álgido. Los bonsáis gigantes de Lucía Baquedano es un libro de El Barco de Vapor, si, ya he dicho que es juvenil, interesante de leer a cualquier edad y que no lleva más de dos horas y algo.
Espero que si alguien logra leer todo esto le sirva para algo. Yo por lo menos estoy más tranquilo espiritualmente . Se agradecería comentarios de cualquier tipo, siempre y cuando sean constructivos.
Posted at 10:30AM feb 05, 2006 by Ricardo Santamaría Bogónez in General | Comentarios[1]