33ideas

Hace más de un año escribía en el blog mis temores acerca de la compra de Sun por parte de Oracle.

Entonces temía por el futuro de muchas de las aplicaciones que aportaba Sun, como Open Solaris, OpenOffice, Java o MySQL, muy extendidas entre los desarrollos OpenSource, sobre todo los dos últimos, si bien ninguno de ellos son exactamente abiertos.

Con esta compra, Oracle continuaba su flirteo con el mundo Open Source participando en muchos de los eventos relacionados.

Pero al final parece que se ha destapado. Como nos cuenta Paula Rooney, unas horas después de abogar por el software abierto en la LinuxCon, Oracle demanda a Google por infringir 7 patentes Java en Android, el sistema operativo de Google basado en Linux para plataformas móviles. Si bien Android es un sistema operativo Linux, sus aplicaciones son desarrolladas mediante una SDK Java sobre la máquina virtual Dalvik.

Y el caso es que, como se plantean otros analistas en la red, esta demanda puede suponer una de las más importantes vividas entre gigantes de la tecnología y puede traer consecuencias importantes.

Además de lo que esto va a suponer de terremoto tecnológico, parece claro que afectará al futuro de las plataformas móviles.

Google ha conseguido plantar cara a Apple con Android debido, entre otras cosas, a la gratuidad de su licencia que hace interesante a los ojos de los distintos fabricantes de móviles androides, HTC, Motorola, etc. Y era, a ojos de muchos, la conformación de que Linux tiene mucho que decir también en las plataformas móviles también en su modo abierto.

No está claro si Oracle persigue con esta demanda sacar tajada de los fabricantes de móviles y Google o va más allá, me inclino más por lo último. Lo que sí resulta evidente es que no son tan defensores del software abierto como pregonan, la lista de empresas compradas por Oracle es sorprendente, incluso una tal SPL Worldgroup, coincidencias…

Quizás esto le venga bien a MeeGo, y de paso a Apple para tomarse un respiro.

Hace bastante tiempo que no escribo, quizás demasiado. Pero este vídeo me ha animado de nuevo, aunque únicamente sea para compartirlo.

Reconozco que es un vídeo exclusivo para programadores, el resto no le verá demasiada gracia, pero así es la vida…

Quedan claras mis filias, ¿no?

A principios del 2010 se cumplirán 15 años de la publicación de la primera edición de “Design Patterns: Elements of Reusable Object-Oriented Software”, uno de los libros que más ha influido en la ingeniería del software de los últimos años.

En 1994 la “banda de los cuatro” (Gang of Four), o lo que es lo mismo: Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides, escribió un libro en el que sentaron las bases del diseño basado en patrones en la programación orientada a objetos. Básicamente es un libro de recetas en el que presentan soluciones en problemas comunes en el proceso de diseño orientado a objetos de una aplicación.

InformIT ha publicado una entrevista a los autores que no tiene desperdicio. En ella los autores hablan acerca de cómo ven el diseño de software en la actualidad y de cuan vigente sigue todavía su libro.

Alguna de las perlas de la entrevista  tiene que ver incluso con el SDK de programación de iPhone, el mismo que se utiliza para programar en Mac OSX y basado en NeXTSTEP, de NeXT que cosas y que tiempos…

Este libro salió a la luz cuando todavía no existía Java, y de hecho el lenguaje recoge muchos de los patrones. Después se escribieron bastantes más libros relacionados con los patrones y han aparecido títulos más digeribles.

Me quedo con el primer párrafo del libro, toda una declaración de intenciones:

El diseño de software orientado a objetos es duro, y diseñar software orientado a objetos reutilizable es todavía más duro. Es necesario encontrar los objetos adecuados, convertirlos en clases con la granularidad correcta, definir interfaces de clases y jerarquías de herencia, y establecer las relaciones clave entre ellas. El diseño debe ser adecuado al problema pero al mismo tiempo lo suficientemente genérico para permitir resolver problemas y requerimientos futuros. Al mismo tiempo buscaremos evitar el rediseño futuro, o al menos minimizarlo.

Este libro ha influido en nuestros proyectos, tanto los escritos en Java como los escritos en PHP. Con Java no tuvimos problemas, era la manera natural de diseñar porque el lenguaje se adaptaba a la perfección.

Pero hace 8 años era una rareza escribir un portal web en PHP basándonos en patrones. Hoy, la mayoría de los frameworks más conocidos (cakephp, symphony, etc.) están basados en patrones… y escritos en PHP. Eso sí, PHP tuvo que hacerse orientado a objetos.

Pues eso, quedan un par de meses para el aniversario, aunque el libro a estas alturas, y hace 15 años, ya estaba escrito.

El pasado 20 de abril Sun publicó una de las noticias que más consecuencias puede tener para el futuro cercano del software: Oracle compra Sun.

Y con Sun, compra MySQL, Java, OpenOffice, Solaris y unas cuantas tecnologías más que forman parte importante del movimiento Open Source. Y la duda que todos tenemos es ¿qué hará Larry Ellison con todas estas tecnologías?

Sun, es principalmente fabricante de hardware y con ella Oracle tiene control sobre todo el proceso.

Parece que el futuro de MySQL no es demasiado esperanzador, teniendo en cuenta que es uno de los “competidores” de la base de datos de Oracle.

En cuanto a Java, imagino que la gente de IBM todavía estará pensando cómo les han levantado a la novia. No creo que sea malo para Java, aunque habrá que esperar.

¿Y OpenOffice? puede ser uno de los misiles para la linea de flotación de Microsoft, la tan odiada por Ellison podría sufrir bastante si se potencia más la Suite competencia de Office por excelencia.

En fin, el tiempo lo dirá, pero es seguro que vendrán cambios.

Ya se sabe: “big business”.

El otro día, leyendo el Blog de Matt Raible me volví a encontrar con Grails en una revisión bibliográfica. Como ya hacía tiempo que tenía ganas de verlo en acción y con Rails hemos desarrollado un par de proyectos en serio, viendo de lo que es capaz, me propuse pegarle un vistazo al libro del que habla Matt: Getting Started with Grails y así de paso podía probarlo.

He de decir que me ha sorprendido gratamente. En los proyectos que hemos desarrollado con Java, hemos utilizado Struts+Hibernate+DWR+display-tag+…, y la verdad es que es muy tedioso. Últimamente, con Struts 2, la cosa mejora bastante, pero no deja de ser muy “manual” y engorroso tanto fichero xml. Para hacer algo que con un lenguaje de script básico se hace en un plis, con esta estructura … en fin, que voy a contar.

Grails es una copia casi exacta de Rails, pero a lo Java. Incluso las convenciones típicas de Rails en cuanto a relaciones, configuraciones de base de datos, etc. paren lógicos. Las tareas repetitivas, como los CRUDs, son instantáneas, etc. En fin, una especio de sueño para un programador Java.

Utiliza el lenguaje Groovy, muy claro y elegante. Las validaciones de datos se controlan desde el modelo, tal y como se hace en Struts 2 mediante las anotaciones de Java.

Para acabar de complicar el asunto, leo en este benchmark que al parecer Grails no es nada lento, de hecho parece que es comparable e incluso más rápido que Rails.

En definitiva, estoy algo deslumbrado por lo que he visto hasta ahora. En poco más de 5 minutos, siguiendo el libro e instalando Grails en el Mac, ya tenía una aplicación con dos entidades funcionando a la perfección.

Después, jugar con validaciones de campos, etc., no ha sido nada difícil y de igual forma muy rápido.

Seguiré avanzando para ver si, una vez más, nos toca volver a cambiar de tecnología… es lo que tenemos los tecnópatas

Espero comentarios…

O’Reilly nos sorprende de vez en cuando con libros diferentes.
Uno de los últimos libros que estoy leyendo es Head First Design Patterns.
Lo que me llamó la atención es el nuevo enfoque da la serie a los libros técnicos. La serie Head First , dirigida por Kathy Sierra y Bert Bates, está basada en las últimas teorías del aprendizaje. El libro utiliza un lenguaje muy visual y un estilo de redacción personal y directo. Hace al lector reflexionar sobre cada uno los conceptos que trata, al tiempo que propone la resolución de problemas de una manera algo lúdica. Pero lo más sorprendente es que uno de los objetivos de la serie es provocar las emociones del lector. Obviamente me refiero a emociones de sorpresa, curiosidad, etc., que nadie se asuste.

Cuando leí el resumen, me pareció que la mejor manera de comprobar la efectividad de este tipo de libros era ponerme como conejillo de indias, y así lo hice.

La verdad es que es un libro agradable de leer, a pesar de lo denso de los patrones de diseño, y como quien no quiere la cosa ya he leído las primeras 80 páginas.

Por lo pronto los patrones Strategy ,Observer y Decorator, los ha tratado de manera muy clara y nada pesada. Este tipo de libros recuerda un concepto básico: la POO no consiste simplemente en la herencia, y aunqe sea una obviedad es muy frecuente ver diseñadores que no parece que lo tengan tan claro.

Así que por ahora mi valoración del libro es positiva.

El libro presenta cada capítulo con un ejemplo de programación, tras describir el problema a resolver propone al lector que obtenga por si mismo el diseño orientado a objetos que mejor se adapta. Comenta pros y contras, principios básicos de POO y conceptos clave que repite machaconamente con el objeto de que se recuerden.

Los conceptos los van presentando diferentes personajes, entre los que se encuentran el programadro, el maestro meditante, el pequeño aprendiz, etc.

Si bien el libro es adecuado para cualquier lenguaje de programación, el lenguaje utilizado para implementar los diferentes ejemplos que plantea es Java… ¿porqué será?

Esta serie demuestra que los buenos libros no siempre tienen que ser 850 gr de celulosa densamente cubiertos de párrafos somnolientos y aburridos.

Esta es una de las preguntas que más frequentemente me hago.

Desde la óptica del arquitecto de sistemas, o al menos desde la mía, las tecnologías candidatas para desarrollar soluciones de calidad serán aquellas que permitan mayor independencia de la plataforma, mayor flexibilidad, herramientas de desarrollo avanzadas que permitan generar código de calidad mediante refactoring, testing, etc. y lo suficientemente implantadas en aplicaciones reales de producción como para poder confiar en su futuro.

En la selección de tecnologías entra el lenguaje, el servidor de bases de datos, el sistema operativo, el framework, el hardware, la tecnología a utilizar para el interfaz de usuario, etc.

Si además nuestro diseño se basa en la programación orientada a objetos, el círculo se hace más pequeño.

Desde este punto de vista, y utilizando la web como interfaz de usuario, lenguajes como Java para grandes aplicaciones y/o PHP para aplicaciones más modestas, la linea de separación siempre es difusa, son a menudo los escogidos.

En la otra acera tenemos la plataforma .NET que, para variar, ha asimilado capacidades de otros lenguajes/tecnologías. Sobre el resto, a mi juicio, destaca por:

• Posibilidad de programar en varios lenguajes
• Entornos de desarrollo tremendamente productivos

pero tiene algunas desventajas:

• Futuro ligado al de una empresa, eso sí, una de las más grandes y voraces.
• Una única plataforma sobre un sistema operativo, aunque con algunas iniciativas interesantes

Es innegable la capacidad de Microsoft para crear herramientas de desarrrollo de alta productividad con las que generar código de manera semiautomatizada. Eso sí, generando un código no demasiado optimizado que puede maquillarse con un hardware potente.

Para el resto de lenguajes destaca como entorno de desarrollo eclipse, uno de los IDEs más interesantes por su capacidad de extensión, de hecho se presenta como una plataforma de desarrollo para cualquier cosa y ninguna en particular.

Pero el asombro y pasmo generalizado aparece con lenguajes como Ruby o frameworks como Rails. Aunque Ruby tiene ya los sufientes años como para considerarse un lenguaje maduro, los defensores de los Java y PHP afirman que no puede competir, todavía, con el marketing y la base de conocimientos existentepara estos.

Ruby es un lenguaje OOP que permite desarrollar soluciones reales como Basecamp, por lo que la crítica de que es un lenguaje de juguete no es creible.

Por supuesto existen soluciones en el mundo Java para incrementar la productividad, XDoclet, etc., pero ese será motivo de otro post

Uno de los valores de la programación extrema es el coraje. Aunque nada indica en XP que esto signifique que haya que cambiar de lenguaje de desarrollo, es posible que tengamos que abrir los ojos ante el nacimiento de otra forma de programar.