Creación de Reportes con Múltiples Formatos usando JasperReports y iReport

Frecuente, o mejor dicho siempre, los clientes desean ver reportes sobre los datos que se generan en el sistema y, en ocasiones, se encuentran almacenados en nuestra base de datos.

Si han tenido que hacer reportes de 7 o más columnas sabrán que esto no es tan sencillo como muchos de nosotros podríamos pensar. Muchos desarrolladores me han comentado que es lo más fácil que hay ya que, a lo más, nos tardaremos media hora en "crear el query" para obtener los datos que necesitamos...

Si bien esto podría ser cierto en la mayoría de los casos, lo que no siempre es fácil es mapear estos datos a los objetos que vamos a usar y aún menos el formaterarlos de manera que nuestro reporte sea fácil de entender y le proporcione al cliente la suficiente información como para que este le sea de utilidad.

La cosa se complica cuando nos piden reportes en formatos distintos al texto plano o HTML (en el caso de los sistemas web) como por ejemplo PDF, CSV, XLS, RTF, etc., ya que estos formatos no son manejados de forma nativa por Java

Configurando Nuestra Herramienta de Trabajo, el NetBeans

Como programadores nuestro objetivo es facilitarle la vida a alguien a través de nuestras aplicaciones. Para hacer esto de una forma más simple, debemos usar varias y variadas herramientas en cada una de las etapas del ciclo de vida de nuestra aplicación. En esta ocasión me enfocaré unicamente a la etapa de desarrollo. En algún otro post hablaré de las herramientas que pueden servir en las etapas de análisis, diseño, y pruebas.

Con Java solo es necesario que contemos con el compilador (javac) para crear una aplicación. Podemos escribir todo el código fuente de nuestra aplicación en un blog de notas, vi, o cualquier editor de texto simple que nos permita guardar nuestro archivo con la extensión .java.

Una vez que tenemos nuestro archivo solo hay que compilarlo con el comando javac de la siguiente forma:

javac [opciones] Archivo.java

Y listo!! Esto nos genera un archivo .class, el cual es nuestra aplicación.

Sin embargo, cuando tenemos proyectos de un tamaño mediano/grande el hacer uso de un bloc de notas y la línea de comandos para compilar no es lo más recomendable. Comenzamos a necesitar separar nuestra aplicación en varios archivos, cada uno conteniendo una o varias clases. Posteriormente dividimos estas clases en paquetes, y asignamos la responsabilidad de estos paquetes a uno o varios desarrolladores.

La cosa se complica cuando comenzamos a hacer pruebas de rendimiento, y calidad, arreglo de bugs, etc.

El Obligatorio Primer Post de Presentación

Saludos a todos. Este es el primer post obligatorio en el que explico quién soy y cuál será el futuro de este blog ^-^.

Primero que nada, soy un programador Java con algunos años de experiencia. A lo largo de esos años he "aprendido" a hacer uso de esta tecnología para resolver situaciones de muchos tipos. Desde sencillas aplicaciones de consola para la obtención de datos de rendimiento de sistemas, pasando por aplicaciones para tratamiento de imágenes y reconocimiento de patrones, sistemas web para la creación de comunidades virtuales, videojuegos, sistemas financieros, etc. Por la naturaleza de estos proyectos, he tenido que investigar, entender, probar, evaluar, y finalmente usar varias APIs para agregar funcionalidades a cada una de estas aplicaciones.

Sin embargo, me he dado cuenta de que, como a muchos otros les debe pasar, dejo de usar alguna de estas APIs y olvido cómo se usan o (como es también muy común) salen nuevas versiones de las APIs las cuales pueden ser incompatibles con versiones anteriores y/o la implementación de las mismas funcionalidades con respecto a versiones anteriores es distinta. Claro, recuerdo los detalles básicos de su uso, pero cuando es tiempo de re-implementar esas funcionalidades en otros proyectos hay veces que nos es suficiente con ver el código que dejamos. Necesitamos regresar a la fuente original de la cual obtuvimos el conocimiento para volver a entender su uso. Claro, esto también presenta otros problemas como puede ser el hecho de que la página haya dejado de existir, o que no estén manejando la versión que necesitamos del API.

Es por eso que pretendo que este blog sea una fuente de conocimiento para todos aquellos programadores Java de habla hispana que desean aprender a hacer uso de estas APIs (y de paso me servirá a mi como libreta de apuntes para recordar cómo hacer las cosas).

También publicaré cosas como configuración de servidores (para los amantes de JEE), interacción entre los mismos, etc. No pretendo tocar temas demasiado básicos, a menos que alguien me pida algún tema particular, ni tampoco escribir de forma muy constante.

Además, me encuentro trabajando el algunos proyectos de videojuegos con un lenguaje distinto de Java, ActionScript 3, así que de vez en cuando publicaré algunos post sobre este tema.

Siéntanse en la libertad de dejar sus comentarios, que siempre serán bien recibidos.