Oracle compra Sun

Hoy se acaba de hacer público el acuerdo de adquisición de Sun por parte de Oracle. En la nota de prensa que se ha publicado tanto Scott McNealy como Jonathan Schwartz por parte de Sun se felicitan por el acuerdo. Por el lado de Oracle, Larry Ellison hace hincapié en que tras el acuerdo Oracle va a poder ofrecer a sus clientes un completo stack de productos que abarca desde el sistema operativo Solaris (de Sun) hasta bases de datos, Java y software de gestión de negocios.

¿Qué sucederá con el SAI? No lo sabemos. Es una de las muchas incógnitas en este momento. En el documento de preguntas más frecuentes dicen explícitamente que Oracle continuará con la estrategia de formación y cursos de Sun (y suponemos que con su política de apertura hacia las universidades). Habrá que esperar unos meses a que concluya la integración de las compañías.

Otras preguntas todavía sin respuesta: ¿qué sucederá con los productos duplicados (o triplicados) en el stack? Muchos de los productos de Sun ya tienen su equivalente en Oracle: GlassFish (servidor JavaEE), MySQL, NetBeans (entorno de desarrollo). Muchos pensamos que los productos de Sun (a excepción de la base de datos) son mejores, pero al final serán criterios de negocio los que primen. ¿Qué sucederá con la apuesta de Sun por el open source? Oracle ya ha dicho que quiere rentabilizar rápidamente la inversión y convertir a Sun en una máquina de hacer millones. Mucho me temo que los experimentos han terminado. ¿Qué sucederá con el JCP, el proceso de definición de estándares de Java? Esta pregunta es más fácil de responder. Supongo que no cambiará demasiado, aunque ahora otros jugadores (léase IBM) estarán algo más reticentes a que sea controlado/dirigido por el nuevo gigante. ¿Qué sucederá con Java en el escritorio? JavaFX era una de las grandes apuestas de Sun y no parece encajar muy bien en una empresa como Oracle orientada al mundo de los servidores. Son muchas preguntas que se irán respondiendo en los próximos meses.

Una cosa segura, sin embargo, es que la nueva empresa Oracle/Sun va apostar igual de fuerte que la antigua Sun por el lenguaje y la plataforma Java. Todos los productos de Oracle dependen de este lenguaje y de esta plataforma. Eso sí, quizás se va a ralentizar su evolución y no vamos a ver demasiadas novedades en bastante tiempo (por parte de Oracle; sin embargo, la comunidad seguirá innovando como siempre: Groovy, Scala, …).

Como reflexión final, es bastante triste que el destino de una empresa como Sun sea el ser comprada por otra. Han estado más de 20 años innovando y, como dice Jonathan Schwartz en un correo enviado a los trabajadores de Sun, pensando y diseñando a diez años vista. Pero los resultados a corto plazo son los que mandan en la actualidad y algunos han terminado perdiendo la paciencia.

Comunicado de prensa

Preguntas más frecuentes

Noticia y comentarios en InfoQ

Un Enfoque Pragmático (I)

Buenas, ya estamos de vuelta. ¡ Han pasado las Navidades, y casi la Pascua !

Para que no se haga eterno y pueda publicarse antes de que cambiemos de milenio, he dividido este articulo en dos. Aquí va la primera parte.

En el primer apartado, La Maldad del Duplicado, se nos recomienda que no debemos duplicar el conocimiento a lo largo de nuestro sistema, y además, no dividir una pieza de conocimiento entre múltiples componentes del sistema. Es decir, que cada pieza de conocimiento tenga una representación única, fiable y sin ambigüedades.

Tip 11: DRY – No te repitas (Don’t Repeat Yourself)

DRY

¿Algo da más rabia para un desarrollador que hacer lo mismo dos veces? Pues aunque parezca que no, al final siempre nos acaba sucediendo. Es más, al tener partes de la aplicación duplicada (reglas de negocio, métodos, menús, etc…), con cada cambio, nos toca retocar cada parte por duplicado/triplicado/…

¿Y por qué aparecen los duplicados? porque (1) no podemos evitarlos, o (2) no nos damos cuenta, (3) por pereza o al compartir código, (4) por duplicación del mismo trabajo por diferentes desarrolladores.

¿Y como evitar la duplicación? ¿Es posible? En el primer caso, cuando no podemos evitarla, por temas de diferente representación de la información, los generadores de código pueden ayudarnos. Cuando documentamos el código, estamos duplicando. Y los comentarios,en ocasiones son imprescindibles. ¿Solución? Simplifica el código. ¿Y si el código se basa en un documento de especificación? ¿Y qué pasa con los lenguajes de programación que nos hacen repetir mucho código (no hay que ir más lejos que la separación interfaz/implementación)? Aquí la refactorización y los IDEs juegan un papel muy importante. Cuando los duplicados aparecen por nuestra negligencia (suena mejor descuido), solo nos queda aprender de los errores. Respecto a la pereza (o las prisas), os dejo dos refranes. No dejes para mañana lo que puedes hacer hoy y Vísteme despacio que tengo prisa. 🙂 Y finalmente, para la debida al trabajo en equipo, lo mejor es la comunicación, abierta, activa, bidireccional y entre todos los miembros del equipo.

Tip 12: Facilita la Reutilización (Make It Easy to Reuse)

Para evitar duplicados, si nuestro código es reusable y está localizable en un lugar adecuado, nuestro equipo no va a reimplementar algo que ya está hecho. Si el código no es reusable, o su uso no es facil/amigable, nadie lo usará, e inevitablemente, aparecerán duplicados 🙁

En el segundo apartado, titulado Ortogonalidad, se trata la cohesión y el acoplamiento (2 de los conceptos más importantes dentro de la ingenieria del software). 2 lineas son ortogonales si forman un angulo recto. 2 vectores son ortogonales si son independientes. 2 componentes son ortogonales si al modificar uno, el otro no se ve afectado. La base de datos es ortogonal del interfaz de usuario, si al modificar la base de datos, no tenemos que modificar ninguna pantalla  ¿esto es posible?

Tip 13: Elimina los Efectos entre las Cosas que No Están Relacionadas (Eliminate Effect Between Unrelated Things)

Al diseñar componentes cohesionados y con bajo acoplamiento, un cambio en un componentes evita tener que cambiar otros. Con esto, ganaremos productividad, ya que aquello que es modificable está localizado, y por tanto, los cambios se hacen estimable, las pruebas viables, y además, se reduce el riesgo.

Respecto a como eliminar los efectos, con una buena organización del equipo de desarrollo, un diseño basado en capas, con un buen uso (y no abuso) de los patrones de diseño, con ayuda de la AOP, etc…

El tercer apartado, Reversible, trata sobre la inestabilidad de las decisiones. Lo que hoy es blanco, mañana es negro y la semana siguiente es gris. El problema viene cuando estas decisiones son críticas, como elegir un proveedor de base de dastos o un patrón arquitectónico, ya que el coste de deshacer esta decisión suele rechazar de antemano la posibilidad del cambio.

Dentro del marco de las metodologías ágiles, donde se abrazan los cambios y el diseño se minimiza para favorecer la producción temprana de código, el cual va mejorando día a día mediante refactorizaciones, nuestra aplicación va a cambiar siempre. Lo que hoy nos vale como solución, puede que dentro de un mes no. Hoy hacemos un prototipo, y la semana que viene lo tiramos a la basura.

Tip 14: No Hay Decisiones Finales (There Are No Final Decisions)

Por esto, necesitamos que nuestra arquitectura sea flexible, que vea los cambios como algo bueno (al fin y al cabo, una petición de cambio por parte del cliente supone más trabajo, y más trabajo debe suponer más ingresos). ¿Como conseguimos una arquitectura flexible? Una arquitectura en capas (lógicas, más que físicas) es imprescindible, así como un buen uso (y no abuso – me repito) de los patrones de diseño.

Bueno, hasta aquí medio capítulo más … espero que os haya gustado. La segunda mitad, si no pasa nada raro, estará para después de vacaciones. A disfrutar del merecido descanso, y que la fuerza os acompañe 😉