[lang_es]Acabo de recibir el anuncio de que el proceso de compra de JBoss por parte de Red Hat ha finalizado y que por lo tanto a partir de ahora JBoss es ya – "oficialmente una parte de la más grande compañía independiente de sofware de código abierto" – .
En los próximos meses tendremos oportunidad de ver qué significa esto realmente para el futuro de JBoss (y de Red Hat).[/lang_es]
[lang_es]Estos días estoy teniendo la oportunidad (y la tarea) de leer cantidades ingentes de documentación relativa a arquitectura de aplicaciones J2EE (en el artículo Bibliografía y recursos java estoy recopilando la información de referencia que me parece más relevante).
Uno de los documentos que me ha parecido interesante es una presentación de Matt Raible, creador de AppFuse y Equinox , en la que hace una comparativa, desde un punto de vista eminentemente práctico y desde su (amplia) experiencia; de algunos de los frameworks que están más de moda: Spring, JSF, Struts, Tapestry y WebWork.
Os la recomiendo.[/lang_es]
Estoy leyendo una entrevista realizada por TheServerSide a Rod Jhonson el creador del framework Spring. La entrevista es vieja, de Febrero de 2003, pero en mi opinión muchas de las cosas que dice siguen siendo totalmente ciertas. Os traduzco (libremente) algunas de las que me han parecido más interesantes.
Hablando sobre los mayores "pecados" del desarrollo J2EE dice:
– Los desarrolladores tienden a pensar que el simple hecho de que existan tecnologías complejas, como los EJB's, implica la necesidad de utilizarlas. – – Las soluciones más complejas necesitan más tiempo para su desarrollo, implican un mayor esfuerzo de mantenimiento y, con frecuencia, proporcionan peor rendimiento. –– Es necesario que abordemos los problemas con la mente abierta y deberíamos estar preparados para utilizar la solución más simple y efectiva. –
Cuando le preguntan por la importancia de los patrones dice lo siguiente:
– He visto desarrolladores enloquecidos con los patrones. Centrados en encontrar oportunidades para aplicar patrones en vez de en dar respuesta a los requerimientos reales. – – Los patrones deben ser utilizados como herramientas para construir una buena solución, sin pensar que el hecho en si mismo de utilizarlos convierte una solución en buena. – – Mi consejo a los desarrolladores es: leer el libro de patrones de la banda de los cuatro de cabo a rabo al menos una vez al año. Contiene el 90% de lo que necesitáis saber de patrones y os hará mejores programadores cada vez que lo leáis. –Hay que decir que Rod recomienda a continuación leer también el libro Core J2EE Patterns y su propio libro, Expert One-on-One J2EE Design and Development, que nos ayudará a poner los pies en el suelo y a aprender como usar los patrones de la banda de los cuatro en un entorno J2EE.
Cuando contesta a la pregunta acerca de su opinión acerca de la gestión que Sun está haciendo de Java suelta algunas perlas y una de las que más me ha llamado la atención es la siguiente:
– Quizás lo peor que ha hecho Sun en la historia de J2EE ha sido desarrollar la Pet Store y presentarla como un ejemplo a seguir para el desarrollo de aplicaciones J2EE. La Pet Store está inflada y es ineficiente y ha dado a Microsoft un objetivo perfecto para atacar a J2EE. –Más sobre los EJB's, pero en este caso para ponerlos en su sitio sin demonizarlos.
– Creo que los EJB's son la herramienta idónea para algunas tareas, pero están sobreutilizados. No veo a los EJB's como el núcleo de J2EE. Son solo una más de las tecnologías que incluye J2EE y sirven para resolver un tipo de problemas muy concreto. –Aunque a continuación dice:
– No me gustan demasiado los Entity EJB's. Hay muy pocas situaciones en las que los he usado. –Como véis, creo que lo que dice está totalmente vigente todavía.
A estas alturas tengo ya recopilada o identificada una buena cantidad de documentación y recursos interesantes relacionados con Java, más concretamente con J2EE. El caso es que cuando realmente los necesito me cuesta encontrarlos por que los tengo desperdigados por distintas ubicaciones. Asà que me he decidido a crear esta entrada para recopilarlos todos y que me sirva de página de inicio cuando de Java se trata.
La documentación que aquà recojo es toda pública, gratuita y accesible. Está más orientada hacia el arquitecto de aplicaciones que hacia el programador y está además claramente orientada hacia aplicaciones J2EE empresariales.
Debéis considerar esta recopilación como un trabajo indefinidamente inacabado. Intentaré ir manteniendola actualizada.
La he dividido en las siguientes secciones:
Por ahora voy a poner solo la lista de «herramientas que hay que conocer», la iré completando con los enlaces y comentarios. También las iré estructurando en categorÃas. Si creéis que algún «imprescindible» se me ha quedado en el tintero avisadme. 🙂
Todavía no lo he probado, el modelado de software no está en las primeras posiciones de mi lista de prioridades, pero lo haré. Una cosa que no me gusta es que solo funciona en plataformas Win32, esto es una limitación que, en mi opinión, hoy por hoy es poco justificable. Una cosa que me gusta y mucho, es que es un proyecto nacido en 1996, ¡hace 10 años!, y que va ya por su quinta versión. Anteriormente se llamó Plastic o Agora Plastic. [/lang_es]
[lang_en]StarUML is an open source project which aim is to develop a UML/MDA platform running on Win32 platform. StartUML has the goal of build a software modeling tool and also platform that is a compelling replacement of commercial modeling tools such as Rational Rose, Together and so on. Some of its main characteristics are:
I have not tried it yet, software modelling is not in the first places of my ToDo list, but i will do it. One thing that i don't like is that StartUML only runs on Win32 platforms. I think that nowadays this is a unacceptable limitation. And one thing i like a lot is that this project is live since 1996, ten years ago!. StarUML is formerly known as "Plastic" or "Agora Plastic" [/lang_es]