miércoles, 3 de diciembre de 2014

MarkLogic - Test Unitarios con Roxy


Test Unitarios con Roxy

La industria del software cada día necesita entregar más prototipos, en menos tiempo con mayor calidad. Pero si nos detenemos a pensar en esto, la primera impresión es que algo estamos haciendo mal o no estamos usando las herramientas correctas para hacerlo. Para no entrar en discusiones, YO voy a decir que siempre podemos encontrar y aprender la manera de hacer algo mucho mejor de lo que actualmente es. 

De acuerdo con lo anterior y en inspiración de mejorar los procesos de desarrollo de aplicaciones realizadas con MarkLogic, he decidido realizar este post sobre como realizar Test Unitarios con Roxy para ayudar a mejorar los procesos de integración, permitiendo encontrar problemas de sintaxis, casting o permisos de manera más rápida y controlada en los servidores de los clientes. Digo servidores de los clientes, porque en nuestros ambientes ya deberíamos estar haciendo esto. 

Ahora que ya estamos en contexto, para poder entender este post vas a necesitar saber sobre:

  1. MarkLogic
  2. Roxy - Más info aquí
  3. XQuery

Configurando Roxy


Lo primero que debemos hacer para iniciar es descargar el código de Roxy desde el repositorio. Esto lo pueden realizar con git o descargando el zip desde github. Una vez tengan el código, debemos crear una aplicación desde la linea de comandos usando el siguiente comando:
./ml init app-name --server-version=7 --app-type=rest
Para windows
ml.bat init app-name --server-version=7 --app-type=rest

Con este comando crearemos una aplicación que se llamará "app-name", que correrá en la version 7 de MarkLogic y que será de tipo "rest". Luego de ejecutar este comando debemos ir a modificar el archivo "build.properties" creado por el framework en la carpeta "deploy". Podemos cambiar las configuraciones que deseemos, pero para este ejemplo nos vamos a enfocar en los siguientes cambios:

  • test-content-db=${app-name}-content-test
  • test-modules-db=${app-name}-modules
  • test-port={ PUERTO DISPONIBLE}

con estos cambios ahora solo resta ejecutar el comando para crear los servidores, bases de datos y forests. Para esto ejecutamos los siguientes comandos:
./ml local bootstrap
./ml local restart
./ml local deploy modules
Para windows
ml.bat local bootstrap
ml.bat local restart
ml.bat local deploy modules
después de ejecutar estos comandos estarán creados los servidores y podrán ingresar a http://localhost:{puerto} para ver la aplicación corriendo.

Creando el primer test unitario


Para crear nuestro primer test unitario vamos a necesitar abrir la carpeta "src" que se encuentra en la raíz de Roxy. En esta carpeta encontraremos 4 carpetas más, a continuación una breve explicación de que es cada una:

  1. App: Es la carpeta donde debemos colocar todos nuestros archivos de XQuery que van a ser usados por el REST para tareas de servidor.
  2. Public: Es la carpeta que contiene todo el front-end de la aplicación, imágenes, javascripts, etc.
  3. Roxy: Es la carpeta que contiene todo el código del Framework
  4. Test: Es la carpeta donde están todos los test unitarios y es la que vamos a usar.
La carpeta de Test tiene una carpeta llamada "suites" la cual tiene una carpeta por cada uno de los tests que deseemos correr en la aplicación, por tanto vamos a crear una carpeta llamada "Mi Primer Test" dentro de la carpeta "suites" (/src/test/suites/). Dentro de esa carpeta vamos a crear un archivo llamado "primer-test.xqy", el cual tendrá el siguiente código:

xquery version "1.0-ml";
import module namespace p = "http://yuxipacific.com/models/project" at "/app/models/project.xqy";
p:create("/project/test.xml","Test 1", "fabian@hotmail.com", "document.docx",("test","unit"))
;
import module namespace test="http://marklogic.com/roxy/test-helper" at "/test/test-helper.xqy";
test:assert-exists(fn:doc("/project/test.xml")/name[.= 'Test 1']),
test:assert-exists(fn:doc("/project/test.xml")/users/user[.= 'fabian@hotmail.com']),
test:assert-exists(fn:doc("/project/test.xml")/files/file[.= 'document.docx']),
test:assert-exists(fn:doc("/project/test.xml")/tags/tag[.= 'test']),
test:assert-exists(fn:doc("/project/test.xml")/tags/tag[.= 'unit'])

Como pueden ver en el código anterior tenemos un script de XQuery que esta ejecutando dos transacciones. En MarkLogic cuando se encuentra un ";", hace referencia a separación de transacciones, por lo que el anterior código ejecutará la primera parte en una transacción y la siguiente en una transacción posterior a la primera. Lo que nos permite poder ver en la Base de Datos los cambios realizados en la primera transacción.

Ahora bien, el código de la primera transacción esta importando un modulo llamado project, el cual posteriormente es usado para llamar la función "create" a la cual se le pasan unos parámetros para su correcta ejecución. En la segunda transacción se importa el modulo de test de Roxy y se realizan unos asserts que verificarán sí lo que se le pase como parámetro existe o no. Para este ejemplo, la primera transacción ha creado un documento en la Base de Datos, que en la segunda transacción verificamos haya sido creado y contenta cada uno de los elementos que deben haber quedado guardados en el XML.

Con esto ya hemos creado nuestro primer Test Unitario que validará que nuestra función de crear proyectos funcione sin problemas.

Ejecutando las pruebas unitarias


Para poder visualizar la interfaz de Test Unitarios debemos dirigirnos a nuestro entorno con el puerto que definimos anteriormente para el test-port en la sección de Configurando Roxy, la dirección quedaría así "http://localhost:{puerto}/test".  Cuando vayamos a esta dirección debemos encontrar algo como esto.



En esta pantalla podemos seleccionar de la parte derecha los Tests que deseamos ejecutar, podemos seleccionar todos o solo nuestro Test. Luego en la parte inferior o en la parte derecha encontrarán un botón "Run Tests", si presionan ese botón el sistema ejecutará todos los test seleccionados y retornará un success sí todo se ejecutó correctamente, de lo contrarió informará cual fue el error. 

Con esto ya habrán realizado su primer Test Unitario con Roxy, ya pueden jugar con los diferentes tipos de assert que Roxy provee. Para más información sobre los diferentes tipos de Test Unitarios permitidos presionar Aquí 

Conclusión


No importa el tipo de metodología que estemos siguiendo para la creación de nuestras aplicaciones, siempre va ser útil tener procesos automáticos que nos ayuden a validar que cada integración que realicemos no esta dañando nada de nuestro código antiguo y mucho más prevenir que esos errores lleguen a nuestro proceso de QA. Esta simple tarea mejorará nuestros tiempos de entrega y hará que nuestros ciclos de desarrollo se demoren menos y tengamos menor cantidad de errores. 

Espero este post les ayude a que sus procesos sean mucho más ágiles, con mayor cantidad de funciones y mucho más cortos. Recuerden comentar en caso de que tengan preguntas y si no las tienen, igualmente comenten que es buenos saber sus opiniones. Hasta la próxima!.

miércoles, 19 de noviembre de 2014

AngularJS: Como aplicarla a mis proyectos?

AngularJS

Seguramente vas a encontrar mucha información en la Red sobre AngularJS y cómo hacer un blog en 5 minutos. Sí esto es lo que estas buscando, este no es el post que necesitas y siento mucho decepcionarte, busca en alguna otra entrada de mi blog algo que te ayude en lo que estas tratando de hacer, y de esa manera no te habré hecho perder el tiempo. Ahora, hablemos de lo que si vamos a tener en este post.

En el siguiente post voy a tratar de resumir que es AngularJS, que problemas podemos encontrar al tratar de implementarlo en uno de nuestros proyectos y un breve resumen de como se supone funciona todo este mundo de controladores, dependencias, directivas y servicios. Dicho esto, empecemos y espero les sea de ayuda.

Que es AngularJS?

AngularJS es un framework MVW (Model View Whatever) como sus creadores lo han denominado. Que traduce cualquier cosa que quieras usar MVC, MVVC o lo que sea que te permita AngularJS hacer y funcione, está bien. Pero como algunas bases debe tener, podemos decir que AngularJS es un Framework MVC en el lado del cliente que esta compuesto de Controladores, Modelos y Vistas. A los cuales se le agregan las directivas, servicios, filtros, dependencias, etc. Si quieres más información puedes consultar la página oficial de AngularJS.

Que problemas podemos encontrar migrando un proyecto hacia AngularJS?

En la mayoría de proyectos que usan javascript sin ningún framework tiene a jQuery cómo base para la creación de sus funciones, eventos y demás actividades en el cliente. Pero la mayoría de estos coinciden en que tienen un javascript por página que es el encargado de inicializar todos los eventos y asignar valores por defecto a las librerías, constantes, etc. 

En este contexto, si la decision fuera pasar de estos complejos y largos archivos con código que posiblemente ya dejo de ser mantenible, hacia un entorno AngularJS, estos son algunos de los problemas que se van a encontrar:

  1. AngularJS necesita de un modulo ("Aplicación") para a partir de este crear los demás componentes. Se podría crear un modulo por página pero sería equivalente a tener el mismo esquema de un archivo js por página. 
  2. AngularJS esta pensado para ser aplicado en modo single page. Es decir, la página de index carga todos los recursos y se encarga de todas las vistas. Normalmente, en los proyectos MVC se tienen templates para cargar vistas, pero cada uno es un recurso diferente. Este cambio es largo y tedioso. 
  3. AngularJS tiene directivas que nos permiten reusar código y funcionalidades, no comiences migrando página por control. Comienza con las directivas y será más rápido.
  4. Es usual tomar los proyectos y comenzar a cambiar todo hacia AngularJS. Te va resultar mucho más fácil si comienzas un proyecto nuevo y reusas el código del proyecto que deseas migrar. Trata de comenzar por las rutas de la aplicación, luego la seguridad, directivas, servicios, controladores y finalmente los estilos. 
  5. AngularJS tiene mucha variedad de plugins/librerías para solucionar los diferentes inconvenientes que se presentan a la hora del desarrollo, es muy importante que no escojas lo primero que veas en internet, investiga cual se acopla mejor a tus necesidades y cuando tengas decidido las librerías que vas a usar, es momento de comenzar a codificar. 

Cómo funciona esto de AngularJS?

Ya sabemos que AngularJS es un Framework, que podemos usarlo como MVC, MVVC o como mejor nos parezca y que además si vamos a migrar una aplicación típica de MVC vamos a tener que cambiar el modo de trabajo de nuestro proyecto. Pero, y Porque? Cómo funciona esto?. A continuación intentaré responder estas preguntas.

AngularJS es una librería que esta pensada para ser cargada una sola vez y a partir de ese momento servir todas las funcionalidades de la aplicación de forma asincrona. De tal manera que todos los scripts que necesitemos para nuestra aplicación van a estar en esta página. De esta manera las vistas van a ser cargadas mediante llamados ajax y AngularJS se encargará de iniciar todos los eventos necesarios para mapear la vista con nuestros controladores.

De igual forma Angular requiere que importes los servicios, directivas y demás archivos en la página de inicio de manera que cuando Angular vaya a resolver las dependencias no genere error ninguna dependencia. Por tanto, la migración de aplicaciones ya existentes no es tan fácil y limpia como se podría pensar, en algunos casos ni siquiera aplica para el modelo del proyecto y no todos los proyectos se pueden trabajar con este esquema, no olvides que existe más frameworks en el mercado. 

Conclusión


AngularJS es un muy buen Framework para el lado del cliente que te ayuda a organizar, agilizar, gestionar, mantener y acelerar tus desarrollos. Pero no todos los proyectos que realices deben tener AngularJS, en algunos casos el model simplemente no se acomoda a las especificaciones del Framework y no puedes intentar cambiar el proyecto para que se acomode al Framework. No depender de las librerías debe ser una de tus reglas principales al momento de realizar un desarrollo. No dejes que tus herramientas se vuelvan tus debilidades. 

Espero les haya gustado y servido este post, para los que esperaban ejemplos, aquí los pueden encontrar, no tenía sentido reinventar la rueda. Saludos y espero sus comentarios.


viernes, 14 de marzo de 2014

Creando una Replica Flexible con Marklogic

Replica Flexible en Marklogic Server



Pre-requisitos


Los siguientes son conocimientos que deben tener previamente al tratar de leer este documento:

  • Marklogic Server
  • Creación de Forest y Bases de Datos
  • Creación de Documentos
  • Content Processing Framework (CPF)

Introducción


En esta oportunidad voy a explicarles como realizar replicas de Bases de Datos en Marklogic Server. Para esto primero definamos algunos términos:

  • Replicar: Es crear una copia de un documento en otras bases de datos y mantener esa copia sincronizada(Posiblemente con algo de retardo/latencia) con el original.
  • Maestro: Es el repositorio que ofrece las actualizaciones por parte de las aplicaciones. El maestro es el que replica las actualizaciones a otros repositorios llamados replicas. 
  • Replica: Es un repositorio que recibe actualizaciones del Maestro.
  • Copia Maestra: Es el contenido que va empezar a ser replicado.
  • Replicación Flexible: Es una implementación de replicación basada en el Marklogic Server Content Processing Framework(CPF). Esta replicación es de un Único Maestro, asincrono y provee un nivel medio de latencia.
Ahora bien, explicados los conceptos que vamos a manejar, quiero mostrarles una imagen que va ilustrar más en detalle de que estamos hablando cuando decimos "Replicar".

Replica Basica
En este punto debe estar claro que es Replica de Bases de Datos y en que consiste. Quiero agregar que las replicas se pueden hacer en Marklogic por Colección, Directorio o Documento.


 Implementando una Replica de Bases de Datos en Marklogic


Para realizar la replica debemos seguir los siguientes pasos en el orden que los voy a enunciar. Recuerden que deben revisar las políticas de seguridad entre los servidores que se están comunicando para que el proceso no sea bloqueado por un Firewall o Proxy. 


Creando las Bases de Datos


Debemos crear una base de datos "Master" y una base de datos "Replica". Para esto debemos crear un forest para cada base de datos y agregarlo respectivamente a cada base de datos. Una vez tenemos las bases de datos que queremos configurar para la Replica, podemos pasar a configurar la base de datos Master, a continuación los pasos:

  1. Verificamos que tenga una base de datos asignada en Triggers. Por defecto podemos usar la de Triggers del sistema o podemos crear una y asignarla.
  2. Vamos a la opción de Content Processing en la base de datos Master e Instalamos presionando el boton Install. 
  3. Después de instalar observamos que el sistema creo un grupo por defecto con los pipelines de conversion de documentos asociados. En este punto debemos seleccionar solamente "Status Change Handling" y "Flexible Replication" como aparece en esta imagen. 
  4. Una vez seleccionamos los pipelines correspondientes, presionamos "Guardar".
Con estos pasos habremos configurado la base de datos Master para que procese todos los documentos que se creen, pero hasta el momento no esta enviando ninguna información. 


Creando La Aplicación de Replica


En la Replica de datos necesitamos hacer uso de una Aplicación para recibir los datos que la base de datos Master nos va enviar, para esto debemos crear la aplicación siguiendo los pasos a continuación:

  1.  En la base de datos de Replica(La Base de datos que va recibir la información) buscamos la opción "Flexible Replication" y presionamos Click.
  2. En esta pantalla le damos al botón "Create" que se encuentra debajo del titulo "Application Server" 
  3. Esto nos abrirá una pantalla donde debemos solamente colocar el numero del puerto que vamos a usar, los demás campos los dejamos tal cual como los define el sistema.
  4. Presionamos el botón "Guardar" y con esto habremos creado la Aplicación correctamente.

Configurando el Envío de Información a la Replica


En esta parte vamos a configurar a donde debe enviar la información la base de datos Master y con que configuraciones. Para esto debemos buscar en la base de datos Master la opción "Flexible Replication" y presionar Click. Una vez hagamos esto debemos seguir los siguientes pasos:

  1. Buscamos en la pantalla las opciones de "Content Processing" y presionamos click en el grupo que creamos en la instalación del Content Processing. Por defecto es "Default Master" donde Master es el nombre de la base de datos en la que estamos trabajando. 
  2. Esto nos va llevar a una pantalla en blanco con un botón "Create", presionamos el botón.
  3. Nos debe aparecer una pantalla para colocar la información necesaria para configurar un envío de datos. En esta pagina debemos llenar los siguientes datos:
    • target name: Es un identificador para diferenciar de varios destinos. 
    • target urls: Podemos colocar varias urls si deseamos replicar a varias bases de datos. Para este ejemplo colocamos la url de la aplicación que creamos en el paso de "Creando la Aplicación de Replica".
    • username: Usuario en la base de datos de Replica para autenticación.
    • password: Contraseña del usuario ingresado en username.
  4. Una vez llenamos los datos presionamos el botón "Guardar".
Con estos pasos ya tenemos configurado que el sistema va enviar datos a una base de datos de replica y sabemos a donde la va enviar. Pero todavía nos falta decirle cada cuanto lo va enviar, para esto debemos crear una tarea.

Creando Tarea de Replicación


Para crear la tarea que va estar pendiente de enviarnos todas las actualizaciones de información debemos ir a la base de datos de Master y buscar la opción "Flexible Replication" y seguir los pasos a continuación:


  1. Buscamos la opción "Scheduled Tasks" y presionamos el botón "Create" que se encuentra en esa opción. 
  2. Luego aparece una ventana con una información por defecto, lo único que debemos cambiar es la periodicidad con la que deseamos actualizar nuestros datos en la base de datos de Replica. El valor por defecto es "minutely". Y para un mejor performance, podemos cambiar la opción de "Task Priority" a "Normal".
  3. Presionamos el botón "Guardar" y listo.

CONCLUSIÓN


Con estos pasos ya tendremos una base de datos principal que hará replica minuto a minuto de todos los cambios que sucedan en nuestra base de datos a un servidor que puede ser externo, local o incluso en el mismo cluster. Esta funcionalidad nos va permitir tener opciones para cuando tengamos un problema en un servidor, tengamos problemas de conexión o incluso por si nuestro servidor principal sufre daños, tendremos la Replica como backup de todos los datos.

Comenta si tienes preguntas, sugerencias o deseas saber mas sobre como Marklogic puede mejorar tus procesos.