domingo, 15 de julio de 2018

Conexión a fuente de datos (PostgreSQL) en iReport 3.7.3


Para crear reportes utilizando el asistente de reportes (Report Wizard), es necesario conectarse previamente a una fuente de datos, y para realizar esto, es necesario crear previamente una conexión a una fuente de datos.

Para crear una conexión a una fuente de datos para generar reportes, es necesario seguir los siguientes pasos:

  1. Presionar el botón Report Datasources, ubicado en la barra de herramientas.

  2. A continuación se muestra una ventana de diálogo que muestra las conexiones y fuentes de datos existentes. Se asumirá que aún no existe una conexión a la fuente de datos que se va a utilizar, y por lo tanto se procederá a crearla. Para ello, se hace clic en el botón New, ubicado en la parte superior derecha de la ventana.
  3. Aparece en pantalla otra ventana de diálogo, que muestra los distintos tipos de fuentes de datos. Para este caso, se elegirá el tipo de fuente más utilizado, Database JDBC Connection. Una vez seleccionado, se hace clic en el botón Next >.
  4. Luego aparecerá una tercera ventana de diálogo, que muestra las propiedades del tipo de conexión seleccionado. Es necesario darle un nombre mnemónico a la conexión. Para este caso, se llamará EjemploCon.
  5. En la misma ventana, se debe seleccionar el tipo de controlador JDBC (JDBC Driver), de acuerdo al sistema gestor de base de datos utilizado. En este ejemplo, se selecciona PostgreSQL (org.postgresql.Driver).
  6. También debe especificarse la URL de la base de datos a utilizar. En este ejemplo se utilizará la siguiente URL: jdbc:postgresql://localhost:5432/ejemplo
    En la URL de conexión a base de datos a través de JDBC, se especifica el protocolo de conexión, el subprotocolo, la dirección del servidor, el puerto y el nombre de la base de datos. En este ejemplo, estos parámetros son, respectivamente: jdbc, postgresql, localhost y ejemplo. Al utilizar la palabra localhost para especificar la dirección del servidor, se está haciendo referencia a la computadora actual, por lo que el servidor será la misma computadora desde la cual se generarán los reportes.
  7. Finalmente, debe detallarse el nombre de usuario y la contraseña, para poder acceder a la base de datos. Para este ejemplo, ambas palabras son postgres. Es posible indicar a iReports que almacene la contraseña, para evitar la molestia de ingresarla cada vez que se intente acceder a la base de datos, marcando la caja de Save password. En este ejemplo, se seleccionará la opción de recordar la contraseña, ya que no interesa la seguridad. A continuación, se ilustra mediante una captura de pantalla, la ventana de diálogo de propiedades de conexión, con todos los campos llenos:
    iReport advierte que la contraseña se almacena como texto plano, sin ninguna clase de encriptación. Por ello no se recomienda utilizar esta opción, a menos que se considere que no se requiere mayor seguridad. Si se elige no almacenar la contraseña, esta se solicitará cada vez que se intente acceder a la base de datos utilizando esta conexión.
  8. Una vez declarados todos estos parámetros, se presiona el botón de prueba (Test), para verificar que es posible realizar la conexión con los datos especificados.
  9. Si la prueba es exitosa, aparecerá el mensaje Connection test succesful!, indicando que fue posible establecer la conexión con la base de datos. En caso contrario, se mostrará un mensaje de error, indicando la posible causa de éste. Si se da esto último, es necesario verificar si los parámetros son correctos, o bien si el software servidor de bases de datos está activo y funcionando correctamente. También debe revisarse que la base de datos especificada exista, y se tengan los permisos adecuados para acceder a ella.
  10. Una vez que la conexión haya sido probada como exitosa, se hace clic en el botón Save, para que iReport guarde la nueva conexión.

Publicado originalmente el 2013-03-04, en https://itsouvenirs.wordpress.com/2013/03/04/conexion-a-fuente-de-datos-postgresql-en-ireport-3-7-3/.

sábado, 14 de julio de 2018

Finch vs Akka Http: Hola mundo en Scala


Hace varios días, buscando artículos sobre Scala en Medium, encontré un artículo sobre cómo crear una aplicación de lista de tareas utilizando Finch, que me llamó la atención. Este tenía un enlace a un artículo titutlado ¿Qué tan rápido es Finch?. En este artículo se mostraba el siguiente tweet con una gráfica comparativa de la velocidad de distintas librerías HTTP de Scala:



Siendo fanático de Scala, y estando acostumbrado a las herramientas más divulgadas para servicios web tales como Play Framework, Spray y Akka HTTP, me llamó bastante la atención que Finch mostrara por mucho un mejor desempeño que estas herramientas, a pesar de que la publicación tiene más de 2 años (publicada en febrero de 2016, vista por mí a principios de 2018). Así que me dio curiosidad de ver qué era Finch, hacer una pequeña prueba, y comparar el código con una aplicación similar con Akka HTTP.

¡Hola Finch!

Finch es una API de Scala para construir servicios HTTP sobre Finagle, la cual es un "sistema RPC extensible para la JVM, utilizado para la construcción de servidores de alta concurrencia", utilizando APIs uniformes de cliente y servidor agnósticas del protocolo (creo q podría describir a Finagle como el WCF para la JVM). En este sentido, Finch provee una delgada capa de bloques para construir APIs HTTP de forma tipada, utilizando conceptos de programación funcional. Esto convierte a Finch en una excelente herramienta para la creación de microservicios, ya que es más fácil integrarlos utilizando tipos compartidos. Cabe mencionar además que Finagle corre sobre Netty, por lo que no requiere de un servidor web separado.

Debido a que Scala es para mí más un pasatiempo, ya que no lo uso en mi trabajo, me costó un poco entender cómo se definía una API en Finch. Después de batallar un par de horas, pude crear el siguiente Hola Mundo, en un solo archivo:



Nótese que la API se compone de un solo endpoint, el cual es pasado como parámetro al servidor HTTP, para ser servido (valga la redundancia). Luego el programa queda en espera mientras el servicio se mantiene en ejecución. Las rutas se definen para cada endpoint, y los separadores utilizados en código son un par de dos puntos (::). Por otra parte, para la serialización de los datos desde y hacia JSON se usa Circe (antes llamada "JSON para gatos", vaya usted a saber por qué, jejeje).

El código completo pueden encontarlo acá: https://github.com/guillegr123/its-hellofinch

El proyecto se ejecuta utilizando SBT, con el siguiente comando:
sbt run
Luego, para probar el servicio, abrimos en el navegador la ruta: http://localhost:8080/api/v1/hello

Lo que más me gustó de Finch es que es que la creación de servicios web requiere poco código, y permite crear una API tipada desde el principio, pudiéndose definir los modelos de datos utilizados en el request y el response. Además, los endpoints son asíncronos, lo que permite una mayor concurrencia, razón de su excelente desempeño.

Pero... luego de algunas pruebas, y de investigar un poco, descubrí que Finch no hace uso de las clases estándares de Scala para programación asíncrona, sino que usa las implementaciones propias del ambiente de Twitter, por lo que obligatoriamente tendremos que hacer uso de sus librerías. Esto además, aunque no imposibilita, hace un poco más engorroso integrar librerías que hacen uso de las clases estándar de Scala. En este sentido, me parece mejor utilizar Finch para aplicaciones pequeñas, o aplicaciones de microservicios en las que hagamos uso extensivo de Finagle y las librerías de Twitter.

¡Hola Akka HTTP!

Descubiertos estos detalles de Finch, y habiendo saciado mi curiosidad de probar el framework, decidí volver a mis raíces con Akka HTTP. Akka HTTP es el reemplazo de Spray, y es considerada más como una librería en lugar de un framework, ya que su principal objetivo es solo proveer herramientas para cubrir las necesidades de integración de una o varias aplicaciones vía HTTP, en lugar de lineamientos sobre los cuáles construir la aplicación. Como tal no provee manejo de componentes como CSS/Javascript, plantillas para creación de vistas y otras herramientas orientadas a aplicaciones para navegadores web.

La construcción del hola mundo utilizando Akka HTTP me costó menos que Finch, debido a que ya había hecho una prueba hace mucho tiempo (y el código fuente estaba en control de versiones). El servicio se creó en un solo archivo, al igual que el ejemplo anterior:



El código completo puede encontrarse acá: https://github.com/guillegr123/its-helloakkahttp

Al igual que con el proyecto de Finch, para ejecutar el servicio, basta ejecutar el comando:

sbt run

Y para probar el servicio, abrimos en el navegador la ruta: http://localhost:8080/api/v1/hello
 
A simple vista, el código es más grande. Esto se debe a que Akka HTTP usa los actores de Akka para el manejo de concurrencia, por lo que es necesario crear un sistema de actores, un materializador de actores, y obtener el contexto de ejecución. Además, para la serialización de los mensajes a JSON, es necesario definir un trait para el formateo del mensaje.

Aparte de eso, en esencia la definición de los endpoints es similar. Las rutas se establecen para cada enpoint, pero usando la barra diagonal (o pleca) como separador, lo que resulta un poco más natural que los dos puntos de Finch, pero que sirven al mismo propósito. Los enpoints son asíncronos, pero a diferencia de Finch, usa la implementación de Futures estándar de Scala.

De forma similar a Finch, la instancia de rutas de la API es pasada como parámetro a su propio servidor web, el cual es iniciado. Sin embargo, en este caso no utiliza una librería externa como Netty, sino que se ejecuta sobre los actores y los flujos de Akka, y activa un puerto para hacer uso directo del protocolo HTTP.

Por otra parte, a diferencia de Finch, al finalizar el servicio web, es necesario desconectar el servidor web explícitamente del puerto, y finalizar el sistema de actores.

Conclusiones

Luego de estas pequeñas pruebas, considero que ambas librerías son excelentes, pero poseen enfoques diferentes, así como implementaciones, por lo que pueden usarse de distintas formas. Akka HTTP parece ser la mejor opción cuando tenemos una aplicación creada utilizando las librerías estándar de Scala, o bien actores de Akka, y solo necesitamos integrar sus componentes u otras aplicaciones vía HTTP. Y Finch parece ser una buena elección cuando necesitamos crear interfaces web tipadas, o sistemas de microservicios que deseamos integrar de forma fácil, ya que también facilita la creación de clientes.

En cuanto al desempeño, según el workbench mostrado por Vladimir Kostyukov, Finch es mucho más rápido que Akka HTTP. Sin embargo, la comparativa fue realizada hace dos años, cuando Akka HTTP aún estaba en pañales, por lo que quedamos a la espera de una comparación más reciente. En lo personal espero más Akka HTTP por ser considerado el reemplazo de Spray.

sábado, 7 de julio de 2018

Cambiar la URL de repositorio GIT remoto

Hola, este es un pequeño snippet para cambiar la URL de un repositorio remoto de GIT, en un repositorio local.

Primero, para listar las URL actuales del repositorio remoto, ejecutamos el siguiente comando, dentro de la carpeta que contiene nuestro repositorio local:

$ git remote -v

Esto mostrará un resultado similar al siguiente:

origin    https://github.com/mi-usuario/mi-repositorio.git (fetch)
origin    https://github.com/mi-usuario/mi-repositorio.git (push)

Puede notarse que el único repositorio remoto referenciado es origin, que suele ser el nombre por defecto asignado al repositorio remoto al clonarlo.

Para asignar una nueva url a dicho remoto, basta ejecutar el siguiente comando:

$ git remote set-url origin https://github.com/mi-usuario/mi-repositorio-nueva-url.git

Para verificar el cambio, podemos listar nuevamente los repositorios remotos, obteniendo el siguiente resultado:

$ git remote -v
origin    https://github.com/mi-usuario/mi-repositorio-nueva-url.git (fetch)
origin    https://github.com/mi-usuario/mi-repositorio-nueva-url.git (push)

Saludos.

Plantilla de Onsen UI para Vue CLI

Hola, en esta ocasión quería compartirles una plantilla de Vue CLI para crear un proyecto de aplicación web progresiva (PWA) con Onsen UI y Vue JS 2. Onsen UI es una librería de componentes para aplicaciones móviles híbridas, es decir, aplicaciones creadas con HTML y Javascript. Dicha librería está adaptada a 4 frameworks para la creación de aplicaciones web dinámicas: Angular JS (1), Angular 2+, React JS y Vue JS 2.

Vue JS 2 ofrece la herramienta de línea de comandos Vue CLI que permite crear la estructura básica de aplicaciones de una sola página (Single Page Applications, o SPA) de forma amigable. Para más detalles sobre la instalación y uso de esta herramienta recomiendo ver los siguientes enlaces:
La plantilla que he creado es un fork de la plantilla de Onsen UI para PWA con Webpack, la cual a su vez se basa en la plantilla para PWA de Vue JS. La plantilla de Onsen UI incluye:
  • Aplicación básica de ejemplo utilizando Onsen UI.
  • Webpack, para empaquetar los componentes del sitio web.
  • Recarga en caliente, para actualizar los cambios realizados en el código de forma inmediata en el navegador.
  • Verificador de sintaxis (lint).
  • Pruebas unitarias y de integración.
  • Extracción de CSS.
  • Manejo de estados utilizando Vuex.
Adicional a esto, he agregado las siguientes características en mi versión de la plantilla:
  • Soporte para TypeScript.
  • Uso de Vue Router para el manejo de rutas en aplicaciones de una sola página.
  • Integración de Vue Router y el componente Ons Navigator, mediante Vuex, para el cambio de páginas, basado en este ejemplo.
  • Axios como cliente HTTP para el consumo de servicios web.
  • La aplicación de ejemplo ha sido extendida para mostrar el manejo de rutas y la descarga de datos desde servicio web.
El código fuente de la plantilla está disponible acá: https://github.com/guillegr123/ons-vue-pwa-webpack-full

Para crear una aplicación utilizando la plantilla, basta ejecutar el siguiente comando, y contestar algunas preguntas:

$ vue init guillegr123/ons-vue-pwa-webpack-full mi-app

Luego, para instalar las dependencias:

$ cd mi-app
$ npm install

Y finalmente, para ejecutar en modo de desarrollo:

$ npm run dev

Con ello se muestra la siguiente aplicación de ejemplo:
Algunos puntos de interés:
  • En el menú lateral existe una sección llamada "internal links", que hace referencia a las páginas dentro de la app. El resto son enlaces externos. 
  • En la página de "Movies" se descarga un listado de películas desde un servicio web utilizando Axios.
Cualquier comentario/sugerencia con respecto a la plantilla, así como cualquier contribución, es bienvenida.
Saludos.
    Con la tecnología de Blogger.