El Café extraterrestre

[:es]

 

Nuestro compañía siempre, pero siempre esta buscando la forma de buscar nuevos y más eficientes métodos para hacer mejor las cosas y el café no escapa a este afán de mejora.  Es por eso que voy a comentarles acerca de nuestro nuevo método de hacer café nivel extraterrestre, que gracias a nuestro compañero Aldemar, tenemos un nuevo descubrimiento para compartir.

Este nuevo método se llama “Café al vacío” que si bien puede no sea realmente nuevo, lo fue para nosotros, tanto que nos llevó a rebautizarlo como “extraterrestre”. Aunque diría que por los utensilios, esto ser vería mas parecido a un laboratorio de la serie “Breaking Bad”.

Bueno, en que consiste el método: Normalmente el café es realizado al vapor, filtración, presión (café italiano)… Pero este utiliza las leyes de la física para su realización.

El utensilio es muy parecido a la tetera italiana donde el agua va bajo el recipiente con el café, separado por un filtro. Hasta este punto parecen ser similares. Sin embargo, la tetera italiana contiene un tubo de seguridad que impide que el café vuelva.

Una vez montado todo se calienta el agua con un mechero o cocinilla de butano en la parte inferior. Esta al calentarse genera presión de vapor la que hace subir el agua caliente al recipiente del café, mezclándose ambos por el tiempo que dura en pasar toda el agua hacia el recipiente superior (aproximadamente 5 minutos).

1.- Etapa de Presión

Una vez que toda el agua queda en el recipiente superior comienza el trabajo inverso, al condensarse el vapor residual, éste se convierte en vacío dentro del recipiente de agua. Este vacío hace que el agua caliente que esta mezclada con el café en la parte superior sea succionada a través del filtro nuevamente al recipiente inferior. El resultado es: un delicioso café muy bien filtrado, mezclado con un sabor extraterrestre.

2. Etapa de Vacío

 

 [:]

Metodologías GIT – Centralized Workflow

[:es]Este es el primero de una serie de artículos que haré sobre las distintas metodologías que al momento de redactar estas líneas son ampliamente conocidas y discutidas en el mundo T.I para el trabajo con el también conocido control de versiones GIT.

Si bien ni este documento ni los siguientes pretenden ser un tutorial de GIT, de igual forma se abarcarán algunos tópicos y comandos básicos (o avanzados dependiendo de lo que se requiera mostrar)  como complemento de la metodología tratada.

 

Centralized Workflow

Se trata del workflow o estrategia de trabajo más simple que veremos en esta serie. Desde mi punto de vista, es el paso lógico de adaptación/transición si es que vienes de un sistema de control de versiones como SVN y pretendes comenzar a utilizar GIT.

Esta metodología consiste en mantener un único repositorio y una única rama sobre la cual los desarrolladores van subiendo sus cambios.

Pese a ser tan simple y tener ciertas similitudes, esta metodología aún nos permite visualizar algunas ventajas sobre SVN, por ejemplo, cada desarrollador puede trabajar y hacer commits en su copia local sin afectar el trabajo de los demás hasta el momento de hacer push sobre el branch remoto.

 

Workflow-centralized-image

 

Operación

Tal como mencioné anteriormente, esta metodología trabaja con un único branch Master, similar al trunk si hacemos la analogía con SVN. La primera gran diferencia, es que cada desarrollador puede generar cuantos commits estime necesarios en su rama local hasta llegar a una funcionalidad completa, para sólo entonces hacer un “push” al repositorio. Todo esto sin afectar el trabajo de los demás, ya que todos los cambios pequeños se hicieron localmente.

En general, los pasos para trabajar con esta metodología (o workflow) son los siguientes:

  1. Cada desarrollador realiza un clone de la única rama del proyecto, en este caso Master,  en su working copy para trabajar de forma local.
  2. Un desarrollador crea, modifica o elimina código con la finalidad de completar una historia de usuario, suponiendo que estamos trabajando con Scrum. Para esto puede generar tantos commits en su branch local como estime conveniente, como ya se dijo, sin afectar el trabajo de los demás miembros del equipo.
  3. Una vez que el desarrollador tiene código listo para liberar, hace un último commit sobre su rama local y posteriormente realiza el push a la rama Master remota, quedando de esta forma el código sincronizado y listo para que los demás miembros del team puedan actualizar su código fuente también.

 

Ejemplo

Con el fin de aterrizar un poco más esta estrategia de trabajo, veremos un ejemplo con un proyecto Libros  en el que está trabajando un equipo de tres desarrolladores: Marcelo, Javier y Jimmy.

Para tales efectos, tenemos entonces un repositorio único cuya rama principal Master será la que cada miembro del equipo debe clonar para tener una copia en su equipo.

[code]

$ git clone https://gitlab.com/company/mi-proyecto-prueba

[/code]

Una vez que tenemos el código en nuestro equipo local, cada desarrollador del equipo comienza a trabajar.

Jimmy será el primer miembro del equipo que haga un push sobre el repositorio remoto. No encontrará mayores problemas ya que dicho repositorio se encontrará exactamente igual al momento de hacer el clone. Por esto, será un push absolutamente limpio.

[code]

$git commit -m "últimas modificaciones antes de hacer push"

$git push master origin

[/code]

Cuando el segundo miembro del equipo, que esta vez será Marcelo, llegue a la fase de hacer push de SU código al repositorio, podría encontrarse con el primer problema. Jimmy en su trabajo de implementación de la funcionalidad “búsqueda de libros” ha debido agregar métodos a la clase Libro.

Marcelo por su parte ha debido crear también métodos y atributos que permiten hacer una reserva, para lo cual realizó cambios también en la clase Libro.

[code]

$git commit -m "Reserva de libros finalizada"

$git push origin master

[/code]

Si tanto Jimmy como Marcelo tuvieron la fortuna de no modificar el mismo código dentro de la clase Libro, el push de Marcelo se llevará a cabo sin mayores problemas. Pero si la suerte no nos acompaña, y esto comenzará a suceder en la medida que los proyectos vayan avanzando y aumentando su complejidad  y el número de miembros del equipo vaya en aumento, Marcelo deberá realizar el proceso de merge del código de ambos desarrolladores para poder llevar a cabo, finalmente, el push del código ya sincronizado a la rama Master.

Ahora es el turno de Javier. Debe actualizar el código que recién acaba de terminar y, deberá hacer el mismo proceso que Marcelo para poder dejar el código del proyecto totalmente sincronizado para todos los miembros de equipo.

Resolución de conflictos

En esta metodología el problema más común que se encontrarán es la constante desactualización de código en las ramas locales, más aún cuando los equipos que modifican código de forma transversal en el proyecto. Esto debido a que la única rama remota está sufriendo constantes updates con cada push que se haga sobre ella.

Será necesario entonces contar con una buena herramienta de resolución de conflictos, como el p4merge u otra que sea de su agrado.

[code]

$git commit -m "Reserva de libros finalizada"

$git push origin master
[/code]

CONFLICT (modify/delete): README.md deleted in HEAD and modified in branch-b. Version branch-b of README.md left in tree.
Automatic merge failed; fix conflicts and then commit the result.

[code]
$git merge tool

[/code]

Para resolver el conflicto, hacer el commit y hacer nuevamente el push del código al repositorio remoto.

 

Ventajas

Esta metodología es especialmente útil para equipos que están cambiando de un sistema de control de versiones como SVN a Git, ya que su línea de trabajo es muy similar. No obstante las diferencias que ya se han mencionado, la utilización de esta metodología permite comprender en la marcha de un proyecto, la filosofía de Git y los comandos utilizados para la operación diaria.

 

Desventajas

La principal desventaja de esta metodología es que, como se está trabajando con un branch local que hace tracking del branch remoto, cada uno de los commits locales que un desarrollador hace pasan a formar parte también del branch remoto, dejando una rama principal (y única) muy sucia y muy compleja de analizar su historia.

 

Recomendación Experta

Como ya he mencionado en más de una oportunidad en este artículo, esta metodología me parece un excelente primer paso para migrarse a GIT ya que se está orientada a comprender el uso básico de este control de versiones. Creo importante que el proyecto que se utilice como proceso de adaptación no corresponda a un desarrollo pequeño, sino más bien un proyecto de envergadura media, de esta forma el equipo se verá enfrentado a problemas de baja dificultad como resolución de conflictos, creación de stashes, utilización de Tags, etc, que le permitan en un siguiente proyecto abordar otras metodologías con características más avanzadas de GIT.

Como último consejo, sería conveniente sobre todo al principio del proyecto, que cada desarrollador tome líneas lo más independientes posibles dentro del desarrollo, para de estar forma comprender primero los comandos a utilizar y luego, comenzar a trabajar con situaciones más complejas como los merges y rebases.

 [:]

Ejecutando SOAP-UI mockservicerunner en modo servidor (Linux)

[:es]La ejecución de servicios mock (simulados) es una de las características mas potentes de SoapUI, hemos explorado en este post, un conjunto de tips que pueden ser útiles en la generación de los mismos. El propósito de esta publicación es compartir la forma cómo hemos automatizado la ejecución de servicios mock en modo servidor.

SoapUI cuenta con un script llamado mockservicerunner.sh el cual permite la ejecución de mock services previamente configurados en un proyecto mediante línea de comandos, lo cual se hace tremendamente útil para disponibilizar un conjunto de mocks en modo servidor, y acceder a estos mismos mediante los endpoints configurados previamente. El uso de la shell es como sigue:

usage: mockservicerunner [options] <soapui-project-file>
-a <arg> Sets the url path to listen on
-b Turns off blocking read for termination
-D <arg> Sets system property with name=value
-G <arg> Sets global property with name=value
-m <arg> Specified the name of the MockService to run
-p <arg> Sets the local port to listen on
-P <arg> Sets or overrides project property with name=value
-s <arg> Sets the soapui-settings.xml file to use
-S Saves the project after running the mockService(s)
-v <arg> Sets password for soapui-settings.xml file
-x <arg> Sets project password for decryption if project is encrypted

Generalmente nuestra configuración es más simple y solo requiere el nombre del mock service, el puerto (sobre-escribiendo la configuración por defecto de los endpoints definidos en el projecto) y el proyecto xml:

mockservicerunner.sh -p 9090 -m "REST MockServices" $PROJECT_HOME/my-project.xml"

Al ejecutar la línea de comandos, por consola se iniciaran los servicios hasta que se presione una tecla para terminar:
23:45:24,638 INFO [SoapUIMockServiceRunner] Started 1 runner
Press any key to terminate...

Sin embargo, este escenario no es muy práctico para el modo en que queremos levantar nuestro servicio, por tanto hemos creado un script para iniciar el mockservicerunner en segundo plano (con nohup), el cual permite iniciar, validar el estado actual, detener y reiniciar el servidor. Considerando que los procesos hijos que levanta SoapUI para la ejecución del runner, cambiaban de Padre (PPID) cuando intentábamos matarlos (con kill -9) fue necesario adaptar un proceso de detención dinámico basado en el nombre de los procesos hijos.

Pre-requsitos básicos (no mayor detalle):

  1. Java instalado
  2. Descargar SoapUI para linux
  3. Descargar el proyecto soapui en el servidor que ejecutará el mockservicerunner

Una vez tengas la herramienta desempaquetada, usaremos las herramientas de línea de commandos para ejectuar el modo servidor. El script que hacemos referencia, lo puedes encontrar en gist de Github acá. Su ejecución es simple:
Usage: ./soapui_mockservicerunner_script.sh { start | stop | restart | status }

Antes de ejecutar, asegurarse de completar las variables requeridas adecuadas:
[code language=”bash”]
# Variables to edit according to your environment
SOAPUI_HOME=$HOME/SoapUI-5.2.1
PROJECT_HOME=$HOME/somefolder/soap-ui
USR=myuser
[/code]

Detalles del script lo puedes encontrar en el gist, para nuestro propósito, sabemos que el servicio mock está ejecutándose en un servidor, con un puerto personalizado y siendo accedido mediante URLs que pueden ser automatizada en una ejecución de tests. Grandioso no? No olvides de probarlo con Postman.

[feather_share show=”twitter, facebook, linkedin” hide=”reddit, pinterest, tumblr, google_plus, mail” size=”24″]

[:]

Mocking REST services con SOAPUI y Postman[:en]Mocking servicios REST con SOAPUI en modo servidor

[:es]El prototipado de servicios es una potente herramienta para acelerar el desarrollo de software, más aún cuando existen dependencias de terceros o cuando simplemente las líneas de tiempo no se cruzan y la gestión de pre-requisitos se convierten en caos y búsqueda de culpables.

La premisa a postular acá, es que sin importar si los servicios (dependencias) con que me estoy integrando están desarrollados  o no, siempre debe existir una capa de “simulación controlada”, que además de servir de base para las pruebas automatizadas, permita validar condiciones de borde, reproduciéndolas fácilmente de manera controlada.

Existen un número importante de herramientas/frameworks que permiten hacer el llamado “mocking”, en nuestra experiencia, las más útiles son las menos invasivas, que al cambiar algo mínimo (como una URL o un parámetro de ambiente), ejecuten un plan simulado o un escenario real.

Al trabajar con servicios web (SOAP/REST) una de las herramientas más versátiles para las pruebas funcionales es SOAPUI, que en su versión OpenSource es suficiente para el objetivo que queremos lograr. Este POST incluye algunas de las prácticas más comunes que seguimos para su implementación, así como algunas de sus ventajas entre las que es importante destacar:

  1. Funciona tanto para un modelo simulado como para conectarse a servicios reales.
  2. El archivo de proyecto es un xml que puede ser versionado fácilmente. Además que el principio asociado a esto es que su edición sea colaborativa.
  3. Se pueden incluir conjuntos de test para un modelo automatizado.
  4. Iniciar el Mock Server puede hacerse mediante la interfaz de usuario como por línea de comandos (ver este post).
  5. El scripting dentro de los mocking es Groovy.

Algunas Prácticas (Sin importar el orden)

  1. Definir múltiples endpoints de acuerdo a los ambientes que se desean probar (show service viewer). Si tienes un nombre de contexto mucho mejor. service-endpoints
  2. Agregar los recursos que se puedan agrupar a recursos base.
    recursos
  3. Generar el Mock Service después de tener los recursos ya creados, así se crearán todos los mockings de una sola vez.
    mockservices
  4. Editar los headers de las respuestas de acuerdo al caso, en muchas ocasiones se requiere prevenir problemas con CORS (Cross-origin resource sharing) para consumir los servicios independiente al origen. Usar los siguientes con discresión (recordando que propósito principal aqui son las pruebas. No usar en servicios reales).
    headers
  5. Definir diferentes respuestas asociadas a un servicio para seleccionar la adecuada respecto a una entrada.
    response
  6. Puedes usar Scripting (Groovy) para determinar a cual respuesta se debe redireccionar. Aquí un ejemplo que recibe y retorna un json, se toman decisiones basado en el contenido para elegir una respuesta predefinida, la que también puede ser modificada dinámicamente con en el caso 3 de nuestro if.

    [code language=”groovy” highlight=”5,9,18″]
    def slurper = new groovy.json.JsonSlurper()
    def jsonReq = slurper.parseText(mockRequest.requestContent) // Entrada es un json
    log.info jsonReq.userIde
    if (jsonReq.userId == "1") {
    return "sessionNOK" // Retorna una de las respuestas definidas en el mockResponses
    }
    if (jsonReq.userId == "3") {
    sleep (8000) // Lo uso para generar timeouts de la aplicación a propósito
    return "sessionOK"
    }
    else if (jsonReq.userId == "4") { // Caso donde manipulo la salida basado en un parámetro como fecha
    use( groovy.time.TimeCategory ) { //Utilidades de fecha en groovy
    currentDate = new Date()
    after30Mins = currentDate + 5.minutes // Sumando 5m a la fecha actual para retornarlo como parámetro
    }
    dateExpiring = after30Mins.format("yyyy-MM-dd’T’HH:mm:ss’Z’", TimeZone.getTimeZone("UTC")) //Formato ISO 8601
    requestContext.responseMessage = ‘{"id": "0","desc": "OK","result":{"token":"ABCDE123456789", "dateEnd":"’+dateExpiring+’"}}’
    return "expiring" // redirige a este tipo de respuesta, que a su vez usa ${responseMessage} como salida.
    }
    else {
    return "sessionOK"
    }
    [/code]

    Expiring response:
    expiring

  7. Considerando que el archivo de proyecto es xml codificado en UTF-8 hace sentido que los datos que usemos se representen con la codificación adecuada y no tengamos conflicto cuando el servidor mock está arriba. Adicionalmente se recomienda agregar explicitamente el header Accept-Charset: utf-8. Ejemplo de mensaje json codificado utf-8 con acentos.

    [code language=”javascript”]
    { "resultado":"Buenos d\u00EDas UTF8" }
    [/code]

  8. Usar los http codes para emular problemas en las respuestas de los servicios resulta bastante útil para condiciones de borde. Ejm
    401
  9. Una vez tengas los servicios simulados, basta con iniciar el servicio desde la misma interfaz de SoapUI. Luego de esto necesitas probar que todo esto funcione bien…
    startmock

Una de las herramientas que mejor se complmenta con los servicios mock creados en SOAPUI, es Postman, plugin de chrome que también funciona como aplicacion independiente.  Te recomiendo usar Postman para validar todos los servicios creados en los pasos anteriores, Postman valida las salidas mucho mejor que SOAPUI, así que es más fácil encontrar un error (un corchete mal cerrado por ejemplo) en la respuesa de salida. Además permite crear diferentes casos de prueba, almacenar las entradas y el formato de intercambio (almacenamiento) es también un xml que puede ser versionado.

Algunos consejos con Postman

  1. Usar un archivo base json (Collection) que sea incremental, colaborativo y versionado. Este archivo debe ser importado constantemente en la herramienta y a su vez exportado (sobre-escribiendo la versión inicial) cuando haya cambios.
    postman-import-export
  2. Agrupar por carpetas los servicios similares.
  3. Parametrizar los endpoint de tal manera que las URL sean fácilmente intercambiadas entre distintos ambientes. Esta configuración, soporta http y https usando los puertos respectivos (por defecto 80 y 443 respectivamente), además se configura de esta manera buscando soportar nombres de contexto vacío (si los hubiese).
    Formato:{{protocol}}://{{server}}:{{port}}/{{context}}myServiceName
    endpoint1
  4. Los ambientes se parametrizan en la sección “manage environments” que permite almacenar configuraciones por ambiente independientes.environment
  5. Cada ambiente se almacena además como un archivo de configuración json diferente (no olvides exportarlo y versionarlo). Los valores se reemplazan dinámicamente en las variables del contexto de prueba cuando se llama el servicio (endpoint clasificado)
    env-local

Bien, esto es apenas una introducción de todo lo que se puede lograr con SoapUI como herramienta de generación de respuestas simuladas y controladas en nuestros ambientes de desarrollo. La extensión, cobertura, desarrollo de mock services y generación conjuntos de test sobre los mismos, dependerán del contexto y el objetivo que queremos lograr. Pero siempre, será buena idea lograr aislarnos de dependencias fuertes como lo son servicios web.

[feather_share show=”twitter, facebook, linkedin” hide=”reddit, pinterest, tumblr, google_plus, mail” size=”24″][:]