Cargar el tipo de cambio desde Banco Central de Costa Rica en GNU/Linux

El Banco Central de Costa Rica tiene una serie de servicios web disponibles para obtener de forma automatizada varios indicadores económicos (más información). Uno de los más utilizados es el que nos devuelve el tipo de cambio entre el Dólar y el Colón.

Para obtener estos datos en una entorno de producción con un servidor GNU/Linux, lo más sencillo es crear un pequeño script que se encargue de obtener la información, y llame a un procedimiento almacenado en la base de datos para guardarla.

Estos serían los pasos que sigue el script:

  1. Obtener la fecha actual y pasarla al formato de la llamada de los servicios web.
  2. Componer las URLs para las llamadas a obtener el tipo de cambio de compra y de venta para la fecha actual.
  3. Obtener el tipo de cambio de compra mediante “curl” y “sed”.
  4. Obtener el tipo de cambio de venta mediante “curl” y “sed”.
  5. Si se ha obtenido el tipo de cambio:
    1. Llamada a la base de datos para almacenarlo (hay que tener cuidado con el formato al leer la fecha).
    2. Envío de email informativo (utilizando “mutt”).
  6. Si no se ha obtenido el tipo de cambio:
    1. Envío de email informativo (utilizando “mutt”).

Para automatizar la ejecución del script, basta declarar un crontab que lo ejecute una vez al día:

  • 00 6 * * * /RUTAALSCRIPT/tipoCambioCR.sh

Pueden encontrar un ejemplo de este script en el siguiente repositorio:

Gestión de imágenes y documentos (prototipo con GRAILS)

Como parte de las mejoras propuestas para nuestro sistema Sistema de Administración de PROpiedades INmobiliarias vamos a incluir la opción de añadir documentos multimedia a los elementos que lo conforman:

  • Imagen principal: a propiedades y entidades (clientes, proveedores y empresas propias)
  • Otras imágenes: a propiedades
  • Planos: a propiedades
  • Documentos: a propiedades y entidades
  • Vídeos: a propiedades

Las imágenes y documentos se alojan en el servidor de la aplicación, mientras que los vídeos deben estar alojados en Youtube o Vimeo.

A la hora de seleccionar los documentos multimedia a subir al servidor se ha validado su formato en cliente (con el parámetro accept del input y en JavaScript una vez seleccionado) y en servidor,  y su tamaño en cliente (en JavaScript una vez seleccionado) y en servidor.

*Actualización: se ha dejado de controlar el tamaño máximo de las imágenes, ahora se redimensionan al subirlas al servidor.

El diseño de la aplicación debe permitir incluir con facilidad documentos multimedia a otros objetos, como podrían ser los arrendamientos (podría subirse el contrato escaneado). Además, puede que se requiera la implementación de un gestor documental que permita acceder a los documentos multimedia sin tener que hacerlo desde el objeto que los contiene.

De este modo, lo primero ha sido montar un prototipo muy sencillo que tenga esta funcionalidad, para posteriormente incluirlo en el sistema. Sobre un proyecto en blanco de GRAILS 2.5.1, sólo añadiendo Twitter Bootstrap (para la visualización de las secciones de los documentos  multimedia), y una galería de imágenes en Jquery, este ha sido el resultado:

Se ha buscado poder reutilizar tango pantallas como código en el servidor (la gestión de los documentos multimedia se hace desde un controlador común haciendo un forward desde el controlador de cada objeto que los contiene).

Los parámetros de número máximo de elementos están guardados en el fichero de configuración Config.groovy, y los parámetros tamaño máximo están guardados en las clases (cada objeto sabe cual es su tamaño máximo permitido), de esta forma hay un ejemplo de las 2 formas de gestionarlos.

Para quien pueda servirle, el código fuente del prototipo está disponible en esta dirección:

GPS-K Logistics: Localización satelital y administración de flotillas

GPSK_logoDurante los últimos meses hemos estado trabajando sobre la plataforma “GPS-K Logistics” de Grupo Kineret. Actualmente esta plataforma de localización satelital y administración de flotillas está operativa con unidades en Costa Rica, Panamá y Nicaragua, además de prospectos en México, Honduras y Guatemala, buscando situarse como un referente a nivel centroamericano para posteriormente harcelo a nivel latinoamericano.

La plataforma GPS-K Logistics permite:

  • Seguimiento de unidades (vehículos, motocicletas, personas, etc.) en tiempo real.
  • Administración, cumplimiento y tiempo en clientes en rutas.
  • Simulación de recorridos históricos (con registro de eventos, limites de velocidad, paradas…).
  • Integración dispositivos Garmin y navegación celular (a través de Waze y Google Maps).
  • Control de combustible y temperatura.
  • Amplio menú de reportes, con la opción de automatizarlos.
  • Generación de diferentes alarmas o eventos (botón de pánico, batería desconectada…).
  • Envío de comandos a las unidades (apagado, cierre central…).
  • Avisos personalizados en respuesta a eventos de las unidades.
  • Diferentes mapas (4 de Google, 3 de Microsoft, OpenStreetMap y mapa propio GPS-K).
  • Definición de cercas electrónicas y control de entradas y salidas de las mismas.
  • Definición de puntos de interés para cada cliente.
  • Amplio listado propio de puntos interés comunes para todos los usuarios.
  • Búsqueda centralizada de unidades, puntos de interes propios, puntos de interés del mapa y cercas electrónicas.
  • Personalización de iconos de rastreo y capas del mapa.
  • Aplicacion desktop con base de datos propia sincronizada, aplicación Web, y aplicación Web para dispositivos móviles.

Los principales objetivos del proyecto han consistido en:

  • Actualización tecnológica de la plataforma.
  • Rediseño de la interfaz de usuario de la aplicación Web.
  • Rediseño de la interfaz de usuario de la aplicación Web para dispositivos móviles.
  • Incremento en la funcionalidad proporcionada por la aplicación Web.
  • Reporteador automático.
  • Integración nuevo dispositivo inteligente GPS de última generación (controla eventos de conducción como aceleraciones, giros, frenazos… y genera dos evaluaciones de la conducción, una basada en la seguridad, y otra en la ecología).

Tecnológicamente hablando se ha pasado de Visual Studio 2005 a 2013, y del framework 2.0 de .net al 4.5. Hemos migrado la versión de los componentes de Devexpress utilizados de la 8.2 a la 14.1, y los hemos aprovechado al máximo posible. Además, se ha enriquecido la interacción del usuario ampliando el uso de Javascript en las pantallas.

En cuanto a la visualización del interfaz de usuario se ha rediseñado por completo la aplicación siguiendo las más utilizadas actualmente, como es un diseño casi liso, muy limpio, manejando la superposición de diferentes elementos para mejorar su acceso (muy al estilo utilizado por Apple en IOS 7-8 y OS X Yosemite, Google en Android Lollipop y Microsoft en Windows Phone y Windows 8). Esto sin perder la esencia de la plataforma, donde se prima la rápida visualización de las unidades y su estado, con la opción del rastreo a un clic, manteniendo mucho espacio para el mapa.

El pase de diapositivas requiere JavaScript.

Más información en la página Web de Grupo Kineret.

Sincronizando bases de datos diferentes

En muchos proyectos te encuentras retos inesperados tras hacer la toma de requisitos. Parte de lo bonito de nuestra profesión es afrontarlos y superarlos, pero claro, esto aumenta el trabajo a realizar.

En nuestro mayor proyecto hasta la fecha, la Reingeniería del Sistema interno de Grupo Kineret SA, se buscaba actualizar el sistema sustituyendo módulos desarrollados varias tecnologías (Coldfusion, VisualFox, ASP.NET, vb.net) cada uno con su bases de datos, por un sistema integrado con una sola tecnología (vb.net) y una única base datos.

El primer paso consistía en la integración y rediseño de bases de datos.

Estado previo:

  • Diferentes módulos accediendo cada uno a una base de datos propia (4 bases de datos).
  • Algunas de las tablas de las bases de datos propias con pequeñas sincronizaciones.
  • Varios cientos de tablas, la mayoría con decenas de columnas.
  • Desarrollo largo (finalmente, tras varios aumentos en el alcance) unos dos años y medio.
  • Requisito de liberación paulatina de cada desarrollo (ir liberando módulos dejando todos los demás perfectamente operativos).

Requisitos integración y sincronización de las bases de datos:

  • Algunos cambios en el diseño de las tablas (varias normalizaciones e integraciones de información).
  • Todos los nombres de tabla diferentes (estandarización).
  • Todos los nombres de las columnas diferentes (estandarización).
  • Algunas claves primarias se modificarían (integraciones de información y mejoras).
  • Mantener la sincronización ACID.
  • Modificaciones masivas.

De la mano con el departamento de TI de Kineret (área con bastante músculo), tras analizar las opciones de sincronización que nos ofrecía el motor utilizado (SQL Server 2008 R2), se decidió que la única opción era hacer la sincronización a través de disparadores de tabla a tabla. Evidentemente esta solución nos aumentaba el nivel de carga en el servidor durante el periodo de desarrollo, pero era la única forma de cumplir los requisitos.

Esta solución implicaba realizar 6 disparadores por tabla, uno para inserciones, uno para modificaciones y otro para borrados, a ambos extremos de la sincronización:

  • Cada disparador debe insertar, actualizar o borrar la información equivalente en el otro extremo a partir de los datos en las tablas “inserted” y “deleted”.
  • En los casos de modificación de tabla primaria necesitamos generar tablas intermedias.
  • Hay que evitar revotes en estos disparadores (controlar al principio su nivel de anidamiento para que no se ejecuten más que una vez).
  • Modificaciones masivas: la mejor forma para realizar las modificaciones fue generado los insert, update y delete haciendo inner joins entre la tabla origen, la tabla inserted o deleted, apuntando la acción a la tabla destino. De esta forma se ejecuta bien tanto las modificaciones sobre una fila, como sobre varias.
  • Deshabilitar todos estos disparadores fácilmente (estandarizamos los nombres con un prefijo que nos permitía simplemente deshabilitarlos haciendo un recorrido automático).

Formato SQL inserción:

INSERT INTO rutaCompletaTabla (col1,col2,….)
select col1,col2,… from inserted

Formato SQL actualización:

UPDATE destino
SET  destino.ch_col1 = i.col1,  destino.col2 = i.col2, …
FROM INSERTED i
INNER JOIN rutaCompletaTabla destino ON  destino.col1PK = i.col1PK …

Formato SQL borrado:

DELETE destino FROM DELETED d
INNER JOIN rutaCompletaTabla destino ON destino.col1PK = d.col1PK …

Generador de código

Escribir manualmente todos estos disparadores sin errores nos hubiese llevado una barbaridad de tiempo, por lo que decidimos desarrollar un generador de código, el cual requería una tabla con la ruta completa de cada tabla y columna de ambos extremos de la sincronización, y tenía las siguientes funciones:

  • Carga de datos.
  • Generación de disparadores.

En este tipo de tareas siempre me acuerdo de esta imagen:

Original de Bruno Oliveira
Original de Bruno Oliveira

El generador bien alimentado nos automatizó la generación de toda la sincronización entre las tablas sin cambios entre claves primarias, y su carga de datos. Y su código generado nos servía como base para modificar las que necesitasen una tabla intermedia para la sincronización, o una carga diferente por la integración de información o modificaciones en el diseño.

De no ser por el desarrollo de este generador, el tiempo de desarrollo se hubiese disparado por culpa de algo invisible para los usuarios (siempre es más complicado de justificar).

Sistema Administración de Propiedades Inmobiliarias

Además de proyectos directos para clientes, también dedicamos tiempo a desarrollo propios. En este caso un Sistema de Administración de Propiedades Inmobiliarias con las siguientes características:

  • Administración de propiedades:
    • Terrenos
    • Edificios
    • Locales comerciales
    • Viviendas
    • Almacenes
    • Etc.
  • Administración de entidades:
    • Arrendatarios
    • Compradores
    • Operadores
    • Propietarios
    • Proveedores
  • Administración de mantenimientos
  • Control de gastos e ingresos

Nos hemos planteado el desarrollo de una aplicación Web (para disponible de acceso multidispositivo y multiplataforma) y un entorno de desarrollo flexible, rápido y moderno. Se decidió realizar el desarrollo sobre Grails, un metaframework de código libre para el desarrollo rápido de aplicaciones Web basado en la convención sobre la configuración, que corre sobre la JVM, y sustentando en solventes tecnologías como:

Para la maquetación general y la definición de estilos visuales estamos utilizando el framework Twitter Bootstrap. Como gestor de control de versiones de código utilizamos Git (GitFlow como flujo de trabajo), y tenemos el repositorio principal alojado en Bitbucket.