DataSource en Jasper Report e iReport

Tal como mencione en mi articulo anterior iReport es una herramienta practica, visual y muy simple de utilizar para desarrollar reportes utilizando el API de Jasper Report.

Los datos que vamos a mostrar en nuestros reportes pueden provenir de distintos lugares tales como una base de datos o un archivo XML, estas formas diferentes de obtener datos son las llamadas fuentes de datos - Data Source.

Las fuentes de datos son representadas en Jasper Report por una interfaz llamada JRDataSource, el motor ya provee muchas implementaciones de esta interfaz para poder utilizar datos provenientes de Arreglos, Vectores, Collections, Modelos de Tablas, Consultas SQL, Cubos OLAP, Consultas JPA, Consultas Hibernate, Archivos CVS,  Documentos XML, por nombrar algunos.

Este artículo mostrará como utilizar iReport para manipular datos provenientes de distintos orígenes, es decir que veremos como se usan con iReport distintas fuentes de datos. El articulo completo se encuentra en Mendoza JUG

¡Feliz 2008!

Aunque con un poco de retraso, feliz 2008 de parte de todos los que estamos detrás de javaHispano. Esperamos que este año el portal siga creciendo con la ayuda de todos vosotros y muchas gracias por vuestro apoyo.

Artículo sobre creación Builders con Groovy

Hace algún tiempo publicamos un artículo sobre DSL's en Groovy, en el que comentábamos que una de las herramientas que nos proporciona para la creación de estos lenguajes "específicos de dominio" son los Builders ("Constructores").

Hoy publicamos, como continuación de aquél artículo, otro de Andrés Almiray en el que se detallan los mecanismos integrados en Groovy 1.5 para creación de Builders, y lasdiferencias y ventajas de cada uno de ellos.

Esperamos que os resulte interesante. 

Manual de Calidad y Estilo de Codificación

Motivado por el post de un antiguo compañero de trabajo y por la falta de un manual en castellano similar en muchas de las empresas en las que he estado, me he decidido a publicar, bajo licencia CreativeCommons, el manual de estilo de programación que desde hace más de una década llevo utilizando en los proyectos.

El manual trata toda clase de aspectos relacionados con el código en forma de "catálogo de buenas prácticas " - desde nombres de identificadores hasta control de flujo, pasando por recomendaciones sobre trazas, codificación de pruebas unitarias o modelo de datos. No pretende sustituir, claro está, una lectura de los libros pertinentes (se incluye una amplia bibliografía), pero reconociendo que muchas veces no hay mucho tiempo para leer y que la rotación de programadores es muy grande, intenta paliar esta carencia resumiendo lo mejor de las diferentes fuentes, a modo de solcuión "temporal".

El manual se encuentra ubicado aquí y espero poder actualizarlo con los comentarios y sugerencias que reciba. (Formato : PDF, 86 páginas, 1,05 Mb)

Benchmark de javascript en navegadores

Jeff Atwood de Coding Horror ha realizado un benchmark de la implementación de javascript de las últimas versiones de los navegadores más usados actualmente: Opera 9.5, Safari 3, Explorer 7 y Firefox 2. Para ello utilizó un nuevo benchmark lanzado por Apple llamado SunSpider que se basa en código "real" o sea código que normalmente es usado en aplicaciones web, las diferentes categorías que cubre son:

3d	Cómputo que se usaría para renderizar 3d, como operaciones de punto flotante.
accesso	Acceso a arrays, propiedades de objetos y a variables
bitops	Operaciones bitwise
Control de flujo	Bucles, recursividad, condicionales.
criptografía	Código para funciones criptográficas.
fecha	Desempeño del objeto "Date"
Matemáticas	Cálculos matemáticos
regexp	RExpresiones regulares
string	Operaciones con cadenas de caracteres

Como podrás ver en los resultados del benchmark, Opera tuvo el mejor desempeño pero como indica Jeff tuvo que usar la última beta del navegador para que todo el benchmark funcionara correctamente. Le sigue Safari, un gran resultado considerando que las pruebas se hicieron sobre el SO Windows, seguramente sobre mac OSX sus números incluso mejorarían. El tercer lugar sería para Firefox 2, pero eso gracias a una anomalía de Explorer en las operaciones con Strings, de no ser por eso, Explorer gana por bastante margen al navegador de Mozilla.

En un mundo en que cada vez se usa más javascript, este tipo de benchmark empiezan a tener sentido. Lo de Firefox es una llamada de atención al equipo de desarrollo, resulta increible que es prácticamente el browser más lento en javascript. Sería interesante ejecutar el benchmark sobre Firefox 3 beta 2.