Buscar
Social
Ofertas laborales ES
martes
may202008

Se ha hecho publica la JSR-000292 Invoke Dynamic

Según leo en el siguiente Post se ha hecho pública la Java Specification Request 292 la cual nos brindara un mejor soporte para lenguajes dinámicos dentro de la JVM. Además de estar propuesta su inclusión para JSE 7.0

Les dejo los siguientes Links 

Link de la Noticia

Descargala

Home JSR 292

Reunión en JavaOne 2008 

Dicha especificación se hace realidad por medio del proyecto Multi-Language VM o the Da Vinci Machine Project, para el cual todos podemos contribuir y observar su avance. 

 

Como siempre recordar e incitar a las personas expertas en dichos temas a que hagan llegar el feedback necesario para el cual cuentan con 90 días antes que se cierre el periodo del EDR

martes
may202008

CodeCity: Análisis de código en 3D

Richard Wettel, estudiante de doctorado en la universidad de Bern en Suiza, ha publicado una curiosa herramienta para el análisis de código llamada CodeCity. Esta herramienta aporta un enfoque bastante novedoso para la visualización del resultado de aplicar métricas a un proyecto de software:

"CodeCity es un ambiente integrado para el análisis de software en el cual los sistemas de software son visualizados como ciudades 3D interactivas y navegables. Las clases son representadas como edificios, mientras que los paquetes son representados como distritos (barrios) a los cuales pertenecen los edificios. Las propiedades visibles de los artefactos de la ciudad representan un conjunto de métricas de software".

CodeCity ha sido programado en Smalltalk sobre la plataforma de análisis de código Moose creada por la misma universidad y es capaz de analizar código en Java, C++ y Smalltalk. Utiliza OpenGL para el render del 3D y se puede ejecutar sobre Windows y Mac OSX. La herramienta es gratuita pero no opensource.

Me lo he descargado pero me parece que antes tienes que utilizar Moose para generar las métricas de tu proyecto y después CodeCity las interpreta en forma de ciudad por lo que cuando tenga tiempo ya intentaré hacerlo. Si no te imaginas el resultado de mostrar tus proyectos como una ciudad, te dejo la ciudad que genera el análisis del código de ArgoUML, además en su Wall Of Fame Richard ha colgado las ciudades de otros proyectos como Azureus:

CodeCity

Una curiosa herramienta para análisis de código que quizás no pueda tener mucho sentido, pero vaya que es bonita.

martes
may202008

Maven: The definitive guide 0.8

Tim O'Brien ha publicado la nueva versión de su libro "Maven: The Definitive Guide", un libro electrónico gratuito que busca convertise en una guía de referencia para esta herramienta de gestión y construcción de proyectos.

Tim no es el único autor, el libro también es escrito por John Casey, Brian Fox y Jason Van Zyl  que junto con Tim trabajan en la empresa Sonatype y Bruce Snyder que no tiene relación laboral con ellos. Me llama un poco la atención el objetivo del libro:

"Aunque hay un gran número de referencias a Maven en línea, no existe un solo libro bien escrito que funcione como una referencia y una introducción.Lo que hemos intentado hacer con este esfuerzo es brindar tanto una referencia comprensiva como una introducción narrativa a Maven".

Parece que a Tim y sus colegas no les convenció el libro de la empresa Exist (antes Mergere): "Better Builds with Maven" que también es gratuito y hasta la fecha es mejor referencia a esta herramienta.

Por otro lado, Maven: The Definitive Guide puede ser leído en línea en formato HTML (no se menciona si en el futuro harán un formato descargable) de forma totalmente gratuita. Una felicitación a los autores que están invirtiendo tiempo y esfuerzo en brindarnos buena documentación sobre esta gran herramienta.

 

lunes
may192008

Singleton vs inyeccion de dependencias

A travéz de DZONE he visto el siguiente blog:
<a href="http://googletesting.blogspot.com/2008/05/tott-using-dependancy-injection-to.html">TotT: Using Dependancy Injection to Avoid Singletons</a>
Su idea es dejar de usar el Singleton y usar inyección de dependencias.
Es decir no debemos tener cosas como Service.getIntance() sino que debemos substituirlo por un constructor ( o un método "set") con un parámetro que sea la instancia del servicio.
Llevo unos cuantos años oyendo este tipo de cosas, sobre todo desde que se puso de moda <a href="TotT: Using Dependancy Injection to Avoid Singletons">Spring</a> y creo que va contra uno de los paradigmas mas importantes de la programación: La encapsulación.

Una de las ideas fundamentales de la encapsulación es ocultar los detalles internos referidos a la implementación y que además son subcestibles de ser cambiados.

Pués bien,vamos a poner un ejemplo en la que la inyección de dependencias no ayuda para nada a la encapsulación.
Imaginamos una clase llamada "NotificaciónNomina" esta clase se usa en una aplicación bancaria para notificar a los clientes cuando les llega la nómina. Actualmente mi banco me ofrece la posibilidad de notificarme mediante un SMS. De esta forma la clase necesitaría del servicio de envios de SMS.

public class  NotificaciónNomina
 private SMSSender smsSender;

 public void setSMSSender(SMSSender smsSender) {
  this.smsSender= smsSender
}

 public void notificarNomina(String idCliente) {
  this.smsSender.sendSMS(...,idCliente,.....)
}
}

¿Que pasa ahora si mi banco quiere ahorrase el dinero del SMS y ahora lo quiere hacer por Email?
Tengo que eliminar el método setSMSSender y añadir setMailSender.Como todos sabemos no se deben cambiar los métodos públicos de una clase si solo modificamos su implementación, pero además ¿por qué alguien que ve el JavaDoc de la clase tiene que saber si uso Email o SMS? ¿A quien le importan los servicios que necesita una clase para hacer su trabajo? Si una clase necesitan de 20 servicios, ¿debe tener 20 métodos setXXXXX?.

Para acabar se puede argumentar que usar inyección de dependencias hace que sea mas cómodo cambiar de una implementación a otra del servicio pq la configuración está en un XML , pero: ¿no puede Service.getIntance() hacer lo mismo e ir a buscar la información a un XML?

 

viernes
may162008

Rails vs OpenXava: una carrera por la productividad

Javier Paniza ha publicado en JavaLobby un interesante artículo que compara los pasos para crear una aplicación CRUD utilizando Ruby en Rails y OpenXava. Obviamente la comparativa esta sesgada ya que Javier es el creador de OpenXava, pero aún así resulta interesante ver las diferencias sustanciales entre un framework MVC como Rails y un framework model-driven como OpenXava.

Quizás lo interesante del artículo es dar a conocer una alternativa para la construcción de aplicaciones Java en la que solo especificas el módelo del dominio de tu aplicación y el framework te construye todo lo demás (desde la BD hasta la vista). A pesar de que existen varios frameworks en Java que hacen esto (Javier menciona además de OpenXava a Trails, NakedObjects, JMatter, MDA y RomaFramework, yo añadiría a Grails y Seam) el desarrollador medio se ha quedado con la idea de que el desarrollo en Java sigue siendo como hace unos años con Struts y EJBs y desplegando en WebSphere 4.0. Cuando la realidad es que Java se ha ido adaptando cada vez más a las necesidades de RAD presentes en la industria.

En el artículo, se puede apreciar que OpenXava genera un resultado mucho más acabado y bonito que Rails, fruto de que el framework produce una aplicación lista para usarse (no hay que olvidar que OpenXava está sobre todo enfocado a producir Portlets listos para desplegarse en un contenedor); mientras que Rails produce una aplicación lista para modificarse para incluir CSS y cambiar el diseño de las páginas.

La comparativa de Javier deja claro que en Java usando un framework model-driven se puede echar a andar una aplicación web con una velocidad similar al tiempo que te tomaría hacerlo en Rails y con un resultado visual mucho mejor. Sin embargo el ciclo de desarrollo no se queda en esto y es donde creo que Rails u otros frameworks como Django de Python siguen teniendo ventaja. En este tipo de frameworks, es mucho más sencillo el despliegue de aplicaciones en los servidores y la modificación de aplicaciones que están en producción, además del tiempo que te ahorras por no tener que compilar el código generado. Sobre estos puntos Alberto Molpeceres ya habló en un artículo. Sin embargo el mundo Java se está acercando a estos últimos puntos con iniciativas como OSGi y JavaRebel y obviamente con los frameworks como OpenXava.

Sería interesante implementar la misma aplicación (con todo y la  foto de la paella valenciana ;-) ) en otros frameworks similares como Grails o Trails o porqué no en Django o Akelos (PHP) y sacar conclusiones más globales. ¿Cuál es vuestra experiencia desarrollando en Rails vs desarrollando en Model-Driven frameworks?