Buscar
Social
Ofertas laborales ES
domingo
oct252009

JavaHispano Podcast - 060 - Noticias Octubre 2009 (a)

viernes
oct232009

Incrementa la presión para que Oracle venda MySQL

Esta semana, todo el mundo parece haberse puesto de acuerdo para hacer presión sobre Oracle para que venda MySQL una vez se haya hecho con Sun. Uno de los primeros ha sido Michael Monty, uno de los cofundadores de la base de datos opensource. Richard Stallman también se ha unido a la llamada, afirmando que la licencia GPL no es suficiente para garantizar la libertad, y viendo como la mejor solución a este conflicto el que Oracle se deshaga de la base de datos opensource.


Y para colmo, el Wall Street Journal ha publicado un artículo en el que afirma que la Unión Europea está decepcionada con la cooperación de Oracle relativa al proceso antimonopolio abierto el mes pasado relativo a la adquisición de Sun.


Mi opinión personal es que Oracle debería vender MySQL, ya que la base de datos tiene un futuro bastante negro dentro de la compañía. Y no sólo eso; aunque en Internet el clamor eso lo relativo a MySQL porque es el producto más conocido (con toda probabilidad, es la base de datos que más instalaciones tiene) creo que Oracle por el bien del opensource y de los programadores también debería deshacerse de Glasfish, de Metro (todo el stack de servicios web de Sun) y, salvo que estén por la labor de apostar por él, de Netbeans.


Con la base de datos, el servidor de aplicaciones y el stack de servicios web juntos es perfectamente posible crear una compañía de middleware opensource. Una compañía pequeña y dinámica cuyos empleados realmente van a tener interés en seguir evolucionando y mejorando estos productos. Especialmente en el caso de Glasfish y Metro, aunque Oracle (una compañía gigante, lenta y pesada) tuviese interés real en desarrollar estos productos (cosa que dudo mucho) no es el sitio adecuado para ellos.

 

Estos productos son bastante recientes, no tienen penetración de mercado, y su principal ventaja competitiva respecto a los productos establecidos en el mercado es el tener un menor bagaje, lo que les permite tomar decisiones rápidas y avanzar a gran velocidad. Sin embargo, esto no suele ser posible en una compañía del tamaño de Oracle. Aunque Oracle intentase honestamente desarrollarlos, no creo que sea el lugar adecuado para ellos. Todos los procesos burocráticos y de control de la compañía harán que el desarrollo de estos productos se ralentice, y que pierdan su principal ventaja competitiva en estos momentos.

 

¿Cuál creéis vosotros que será el futuro de todos estos productos? ¿Creéis que pueden tener un futuro brillante dentro de Oracle o que su única esperanza es ser desarrollados por otra compañía más pequeña y ágil?

jueves
oct222009

Liberado Weld 1.0. RC1 (el antiguo Web Beans)

Esta semana se ha anunciado la versión Release Candidate 1 de Weld 1.0, la implementación de referencia del JSR 299: inyección de dependencia para Java EE (el proyecto antiguamente conocido como Web Beans). En estos momentos, el Proposed Final Draft de la especificación, la implementación y el test  de compatibilidad están pendiente de la última votación del Java Community Process, votación que dará luz verde definitiva a esta especificación.


La especificación formara parte del Java EE 6, y esta implementación (Weld) y sus haya ya por Glasfish v3 y será empleada por JBoss 5.3.

jueves
oct222009

Otra vez con los ORM

Este fin de semana en DZone se ha publicado un post llamado <a href="http://codemonkeyism.com/orms/">ORMs are a thing of the past</a>.A raiz de ésto ya ya llevan publicados otros 4 post para contestarle:

  • <a href="http://java.dzone.com/news/orm-debate-obsolete-technology">The ORM Debate: Experts Weigh In</a> 
  • <a href="http://java.dzone.com/articles/are-orms-really-thing-past">Are ORMs Really a Thing of the Past?</a>
  • <a href="http://blog.schauderhaft.de/2009/10/18/hibernate-problems-alternative/">Hibernate has Problems, but where is the Alternative?</a>
  • <a href="http://www.crazymcphee.net/x/2009/10/19/orm-is-dead-meme/">ORM-is-Dead meme</a>

Lo sorprendente es que haya habido varias respuestas a un tema que ya se daba por zanjado. Pero lo interesante es ver voces discordante con el "sentir" general. Mi impresión es que hablar en contra de la corriente general suele ser tabú y se suele quedar como un ignorante con lo que uno acaba por no discrepar.El ejemplo más famoso fué en el los EJB hace ya años.

Por ello aprobechando estos post voy a comentar algunas cosas sobre los ORM y persistencia con los que no estoy de acuerdo:

  • Los ORM permiten que se cambie el esquema de la base de datos: Esto es cierto pero lo normal es que sea más estable la base de datos que la propia aplicación.Las app van y vienen pero las bases de datos se mantienen.
  • Los ORM se ahorran gran catidad de SQL:Tambien es cierto pero de todas esas SQL la mayoría pueden ser para hacer un CRUD de cada una de las tablas.En una mañana se puede hacer el código que te genera automáticamente las 4 SQLs por tabla.Y para el resto quizas es mejor hacerlas a mano que dejarselas al ORM.
  • Las validaciones de los ORM: Nunca he entendido pq Hibernate (o cualquier otro) tiene una sola linea de código para hacer validaciones.La validaciones deben estaar en la capa de negocio y los ORM están en la de persistencia. Ya se que nadie te obliga a usarlas pero están ahí y al final uno no se pregunta si debe o no usarlas, con lo que acaba usándolas.
  • Oponer un ORM a ActiveRecord: Los ORM se dedican a la persistencia y el ActiveRecord también así que el ActiveRecord también es un ORM.
  • El ActiveRecord permite la persistencia de una única tabla: ¿Hay alguna ley que prohiba que actue sobre más de una tabla? El ActiveRecord lo único que tiene es que los métodos de "save", "delete", "read", etc. Se encuentran en la propia clase de negocio lo demás son limitaciones que alguien impondría alguna vez y el resto repetimos como loros.
  • Con el ActiveRecord se mezclan el código de negocio con el de  persistencia:¿Acaso el ActiveRecord no puede delegar la persistencia a otra clase? La duda sería entonces pq usar ActiveRecord si luego no hacen la persistencia dentro. La respuesta es simplemente para mantener el interfaz de las operaciones de "save", "delete", etc en la propia clase. Para mi es mucho más cómodo que tener que buscar un nuevo objeto que las persista.
A estas horas no se me ocurre nada más pero valga ésto para no caer en la complacencia y pensar que las cosas ya están bien como están.
martes
oct202009

Los 50 mejores trabajos en América

Aunque la noticia no afecta directamente a un país hispano, me ha parecido interesante y creo que puede ser punto de partida para ciertas reflexiones de cómo nuestros países hispanos se comparan con el país que, nos guste o no, lleva la batuta en lo referente al desarrollo de software.


La CNN ha publicado una lista con los 50 mejores trabajos de América, creando el ranking teniendo en cuenta la retribución económica de los trabajadores en esas profesiones y las expectativas de crecimiento del mercado en torno a esa profesión. Y, francamente, los trabajos relacionados con tecnologías de la información han quedado bastante bien:

  • #1 Systems Engineer
  • #5 Information Technology Project Manager
  • #8 Network Security Consultant
  • #12 Software Developer
  • #16 Software Project Manager
  • #17 Information Technology Business Analyst

¿Creéis que este ranking refleja aproximadamente la situación en vuestro país, o vuestra situación es completamente diferente?