1er OF Hack Day Mayo 2013

Hace ya una semana que tuvo lugar la primera edición del primer OF Hack Day en Openfinance y es hora de contaros cómo fue el evento y qué conclusiones hemos sacado.

El objetivo de la actividad era fomentar la creatividad, la innovación, el trabajo en equipo y la utilización de nuevas tecnologías y los cubrimos con creces! Participamos 5 equipos de 5 y 6 personas por cada equipo, cada equipo tuvo un espacio de trabajo individual para desarrollar su idea, producto o prototipo sin molestar al resto de equipos y todos los equipos consiguieron tener un MVP para presentar.

Fue muy positivo ver cómo los diferentes equipos plantearon el desarrollo de sus ideas para construir un MVP en 24 horas. Los equipos cuyos productos estaban basados en una sola feature priorizaron el desarrollo de prototipos con mocks sobre los que iban sustituyendo mocks por funcionalidad real mientras que los equipos cuyos productos ofrecían más de una feature optaron por priorizarlas e ir implementando según el tiempo que tenían.

El evento finalizó con la evaluación de los proyectos. La evaluación consistió en que cada equipo presentó durante 8 minutos su producto/prototipo acompañado de su plan de negocio y viabilidad mientras el resto de participantes lo puntuaba. El equipo que obtuviera la máxima puntuación sería el ganador y en esta edición el ganador fue SOStion, una app que permite avisar de forma manual o automática en caso de accidente a tus contactos de la agenda u otros usuarios que se encuentren próximos a tu posición.

En definitiva, ha sido una experiencia muy enriquecedora para todos los participantes, todos lo pasamos genial y hemos vivido y aprendido la experiencia de construir un producto a partir de una idea. Además, ha servido para mejorar nuestras skills técnicas ya que hubo gente que desarrolló su primera aplicación en iOS, en Android, en HTML5 o que aplicaron tecnologías que no usan en su día a día como node.js, MongoDB o jQueryMobile.

Ahora sólo queda que entre todos hagamos una restrospectiva conjunta para determinar qué cosas podemos mejorar y comenzar a trabajar en la segunda edición del OF Hack Day!!

evento , ,

1er Openfinance Hackday

Openfinance organiza su primera sesión de Hackdays con el fin de fomentar la iniciativa, el trabajo en equipo, la innovación, el aprendizaje de nuevas tecnologías…

Mediante la organización voluntaria de equipos multidisciplinares trabajarán durante dos días en el desarrollo y ejecución de una idea, materializandonse en un producto o prototipo y un plan de viabilidad asociado.

Al finalizar la jornada todos los equipos realizarán un Pitch del producto resultante y el resto de equipos lo evaluarán. Cada miembro del equipo ganador recibirá un cheque regalo como premio.

El evento se desarrollará los días 23 y 24 de mayo en un edificio del centro histórico de Valencia donde se encuentran las oficinas de Engloba Comunicacion. (Ver Mapa)

Este  evento esta orientado a los trabajadores de Openfinance, pero aceptamos invitados. Si estáis interesados podéis contactar con Luis Hoyos. lhoyos@openfinance.es

Horario:
   Jueves 23 de mayo
13.30. Apertura y configuración de equipos
14.30. Almuerzo de trabajo

20.00. Afterwork
21.00-24.00 Chillout & Mojitos

   Viernes 24 de mayo
8:00 Vuelta al trabajo
14:00 Presentación Proyectos
14:30 Cierre jornada y entrega de premios.

Equipos apuntados:

  1. sQRew Party: Aplicación para hacer el juego  “tornillo” o “tuerca” con la que se generará un código QR y leyendo con tu móvil el código QR de otros participantes tendrás que encontrar el que se empareja contigo.
  2. Photofridge: Sistema que te permite tener una foto exacta de los alimentos que tienes en la nevera y controlar la fecha de caducidad de los mismos.
  3. Securetaxi: Una aplicación móvil que te permita coger un taxi con seguridad.
  4. CrashAlert: Aplicación móvil que manda una alerta a un contacto en caso de accidente de tráfico entre otras novedosas funcionalidades que la harán muy divertida!
  5. Qué comemos: Aplicación móvil que te permite ver el menú del día que tienen los restaurantes de la zona.
Uncategorized , ,

Marketing Attraction

El pasado mes de noviembre se organizó un pequeño evento en el espacio de co-working workether de marketing attraction dentro de la iniciativa StartupBus. Yo no sabía nada ni de lo que era el startupbus ni mucho menos lo que era el marketing attraction y me entraba curiosidad así que allí que me fui.

La idea del startupbus es algo parecido a los startupweekends donde un grupo de personas (en este caso eran 27) de diferente ámbito desarrolladores, diseñadores, gente de negocio, marketing se juntan para poner en marcha una idea o proyecto. La mayor diferencia es que iban viajando dentro de un autobus por diferentes ciudades españolas, Barcelona, Valencia, Madrid y Bilbao. Acabando en París donde había una competición de las ganadores de diferentes StartaupBus de otros países que se pusieron en marcha la mismo tiempo. En cada una de estas ciudades hacían como un meet-up donde iban moldeando su proyecto con talleres, charlas, etc…

En el caso de Valencia como he comentado anteriormente era sobre Marketing Attraction. Lo que comentaron inicialmente es que la forma en que se esta haciendo el marketing actual de las marcas/productos/servicios esta anticuado y no ha evolucionado en mucho tiempo. Lo que hacen las grandes marcas es gastarse un dineral en publicidad para que la gente “pique” y compre su marca. Básicamente es una táctica de acoso y derribo. No piensan ni en los usuarios ni mucho menos en las personas.

Con la fuerte entrada de las redes sociales la forma de hacer marketing tiene que cambiar, ahora mismo cualquier persona puede hacer una gran influencia sobre mucha gente simplemente escribiendo un tweet o un post en algún foro. Cada vez más es importante que los usuarios estén atraídos por la marca y se sientan parte de ella son los que al final van a vender tu marca. Y lo más importante a un coste prácticamente cero.

La importancia de las personas

¿Qué es más importante?, tener 10.000 usuarios en tu maravillosa startup de los cuales el 90% no interactuen con ella ni para bien ni para mal o tener 2.000 pero que estén enamorados de la marca y la usen/comenten/compartan a diario. ¿Cuál de ellas va a tener un crecimiento mayor?. En eso consiste el marketing attraction, atraer a las personas más que a los usuarios.

La idea principal es no encerrarte en que tu idea es tuya y de nadie más sino tienes que abrirla al público haciendo contenidos de los cuales los usuarios formen parte activa de ellos.

Aquí os dejo la presentación que nos hicieron

Un saludo

@jomarmen

evento, marketing

Introducción a las Expresiones Regulares.

Seguramente nos hayamos topado en no pocas ocasiones con tareas que implican filtrados avanzados así como búsquedas con unos patrones más o menos fijos pero que no pueden ser expresados sólo con palabras de nuestro lenguaje o tareas de tratamiento de texto de cualquier índole que acaban convirtiéndonos en un autómata que realiza constantemente las mismas acciones sobre diferentes líneas de un mismo documento.

Si eres desarrollador muy probablemente te hayas enfrentado a validadores que han acabado siendo una secuencia de desguace de una cadena de texto para ir validando pedazo a pedazo sus partes con el fin de hallar fallos de construcción.

Para solucionar todos estos problemas tenemos las llamadas Expresiones regulares (a partir de ahora ER). Estas no son más que cadenas de texto; símbolos y caracteres alfanuméricos, que definen autómatas de estados, estados que se irán recorriendo  sobre el texto a analizar en busca de coincidencias.

Imaginemos que tenemos que buscar en un texto la palabra “futuro”, ¿Qué hará el buscador de texto del programa que estemos empleando para editarlo?

La respuesta es obvia, irá buscando en el texto una “f”, después mirará si la siguiente letra es una “u” y sino empezará de nuevo el proceso, pero si sí lo es, analizará si el siguiente carácter es una “t”, y así sucesivamente.

Con expresiones regulares la búsqueda será exactamente igual, solo que habrán ciertos símbolos darán información adicional definiendo múltiples búsquedas de una sola vez.

Supongamos que tenemos un texto de 40.000 líneas en el que aparecen direcciones de email, y nosotros necesitamos obtener una lista completas de todos los emails para, por ejemplo, poder enviarles SPAM. Podríamos buscar “@” e ir copiando una a una las direcciones que nos salgan, pero eso parece una tarea un poco dura. Con las ER y un simple patrón podríamos encontrarlas todas, de hecho, podríamos decir que todo lo que NO sea una coincidencia, sea borrado, para tener una lista limpia de emails separadas por comas. Un ejemplo de ER que coincidiría con emails sería:

[A-Za-z]+@[a-zA-Z]([A-Za-z]+\.)+[A-Za-z]{2,3}

Notar que este es un patrón, uno que nos serviría para encontrar cualquier cadena de texto que incluya una o mas letras seguidas de una arroba seguidas de una o mas letras y puntos seguidas finalmente por dos o tres letras. En un texto como el de este post sería capaz de coincidir con correos como nombre@dominio.es o nombre@dominio.co.uk.

Mostradas las capacidades de las Expresiones regulares, vamos a enumerar los operadores posibles.

  • . (Punto): Coincide con cualquier carácter.
  • + (Más): Sirve para indicar una o más repeticiones.
  • * (Asterisco): Parecido al símbolo más, pero este indica cero o más repeticiones.
  • ? (Interrogación): Indica al patrón precedente su posible aparición, es decir, indica cero o una aparición.
  • \ (Barra inversa): Lo emplearemos para escapar caracteres especiales y que así pierdan su significado como operador.
  • $ (Dólar): Indica final de línea.
  • ^ (Acento circunflejo): Comienzo de línea.
  • {} (Llaves): Estas seguidas de un numero o un intervalo seguido de una coma indican el número de repeticiones . Por ejemplo, {2} indicaría dos apariciones. {1,3} indicaría de una a tres apariciones.
  • () (Paréntesis): Sirven para agrupar caracteres, además en ciertos motores de búsqueda indican un grupo de referencia al que puede ser accedido con posterioridad. Esto lo explicaremos más adelante.
  • [] (Corchetes): Representan lo que llamaremos clases de caracteres, Útiles cuando hay que buscar un grupo de caracteres. En el ejemplo de los email, se mostraba en varias ocasiones el rango [a-zA-Z], esto indica cualquier carácter alfabético, ya sea en mayúsculas o minúsculas, aunque también podríamos emplear rangos como, [0-9]; indicando números del cero al nueve o porqué no [a-f0-5], coincidiendo con númoers del cero al cinco o letras de la a “A” la “F”.
  • | (Barra vertical): Se emplea para indicar opcionalidad entre unas y otras clases de caracteres.
Uncategorized

Gestión de dependencias con NuGet

NuGet logo

 

 

La reutilización de código es uno de los principales pilares en los que se basa cualquier empresa desarrolladora de software, ya que permite vender varias veces lo mismo, algo que dificilmente se puede conseguir en otro tipo de empresas. Para poder hacer uso de esta funcionalidad, encapsulamos este código en diferentes componentes o librerías.

Para una empresa basada en producto como Openfinance, la gestión de dependencias entre componentes juega un papel fundamental de cara a facilitar la publicación de versiones y a mantener una correcta relación de dependencias.

En otras tecnologías como Java existen herramientas muy populares como Maven que permiten centralizar y abstraer estas dependencias haciendo posible la compilación de componentes de manera fácil, rápida y muchas veces transparente al desarrollador. Sin embargo, en .NET este tipo de herramientas no son tan populares por lo que es difícil para un equipo de desarrollo encontrar una herramienta efectiva para estos fines. Desde hace unos meses hemos empezado a utilizar NuGet y estamos bastante satisfechos con el resultado obtenido por lo que queremos compartir con vosotros un pequeño tutorial que os servirá de introducción por si queréis utilizarlo en vuestros proyectos.

¿Qué es NuGet?

NuGet es una extensión de Visual Studio que facilita la gestión de dependencias de un proyecto .NET con librerías externas, componentes u otros proyectos. Además, proporciona un repositorio público donde se almacenan y comparten varios “paquetes” de librerías que podremos agregar a nuestros proyectos y permite la creación de repositorios privados donde almacenar paquetes propios.

 

¿Cómo funciona?

Tras instalarnos el complemento en Visual Studio, nos aparecerá la opción “Manage Nuget packages..” en el menú contextual del proyecto.

Esta opción nos abrirá una ventana muy similar a la de gestión de extensiones de Visual Studio, desde la que podremos añadir, quitar y actualizar los paquetes de nuestro proyecto.

Cuando se añade un paquete a un proyecto:
- Se descarga el paquete y los paquetes dependientes en la carpeta ‘packages’ que se crea a nivel de la solución.
- Se añaden las referencias necesarias al proyecto.
- En su caso se modifican los archivos de configuración necesarios.
- Se actualiza el fichero packages.config.

A partir de este momento, el proyecto contendrá un fichero (packages.config) que contendrá las dependecias (identificador de paquete y versión) de nuestro proyecto.

 

Creación de paquetes

Un paquete es un fichero con extensión .nupkg que contiene todos los ficheros necesarios para incluir una librería en nuestro proyecto. En la mayoría de casos, contendrán el assembly necesario, pero puede contener además archivos adicionales como scripts o formularios aspx. También puede incluir las modificaciones a realizar en nuestro archivo de configuración de aplicación, que se realizarán automáticamente al añadir el paquete.

Para crear un paquete necesitaremos el ejecutable para línea de comandos  NuGet.exe o la aplicación NuGet Package Explorer. En ambos casos, se parte de un fichero XML con extensión .nuspec donde se definen los metadatos del paquete, las dependencias que tiene y la ruta de los ficheros que vamos a incluir:

<?xml version="1.0"?>
<package>
  <metadata>
    <id>MyPackageId</id>
    <version>1.0.0</version>
    <authors>openfinancedev</authors>
    <owners>openfinancedev</owners>
    <licenseUrl>http://LICENSE_URL_HERE</licenseUrl>
    <projectUrl>http://PROJECT_URL_HERE</projectUrl>
    <iconUrl>http://ICON_URL_HERE_OR_DELETE_THIS_LINE</iconUrl>
    <requireLicenseAcceptance>false</requireLicenseAcceptance>
    <description>Package description</description>
    <tags>Tag1 Tag2</tags>
    <dependencies>
      <dependency id="SampleDependency" version="1.0.1" />
    </dependencies>
  </metadata>
  <files>
    <file src="..\MyPackage\bin\Release\MyPackage.dll
        target="lib\net35\MyPackage.dll" />
  </files>
</package>

Ejecutando “nuget pack MyPackageId.nuspec” si utilizamos NuGet.exe o desde la opción de menú “File -> Save” del Nuget Package Explorer nos generará el fichero .nupkg.

Instalar un repositorio de paquetes propio

Una de las principales ventajas de NuGet, es que permite montar fácilmente repositorios “privados”. Hacerlo es tan fácil como crear una aplicación web vacía y añadir el paquete Nuget.Server. Después, solo tendremos que desplegar la aplicación en un IIS y copiar los paquetes que queramos distribuir a la carpeta “Packages”.

Para poder utilizar este repositorio, solo tendremos que añadir la URL del mismo en la configuración de NuGet dentro del menú de Opciones:

 

Restauración de paquetes

Para habilitar la restauración de paquetes solo tendremos que seleccionar la opción en el menú contextual de la solución. Esto hará que se cree en la solución una carpeta .nuget que contendrá el ejecutable por línea de comandos de NuGet y un archivo MSBuild donde podremos configurar las rutas de los repositorios de los paquetes además de otras opciones. Este archivo provocará que, al compilar la solución, se lance una tarea de comprobación de paquetes, en la que se analizarán los archivos packages.config de cada proyecto de la solución y se comprobará si se dispone del paquete y versión necesarios. Si no, se descargará de los repositorios.

Para mí, esta es una de las principales funcionalidades de NuGet, por las siguientes razones:
- Hace que las actualizaciones de dependencias sean transparentes para el resto de componentes del equipo de desarrollo.
- Permite integrar NuGet con el sistema de integración continua.
- Facilita la instalación del proyecto desde cero.
- En el sistema de control de versiones no será necesario añadir ningún paquete ni librería.

 

Enlaces

NuGet Docs - http://docs.nuget.org/

desarrollo ,

Workshop Responsive Web Design

El próxima día 27 de octubre Swwweet (http://swwweet.com) (@savetheusers) imparte en nuestras oficinas de Valencia un Workshop sobre Responsive Web Design.

Este Workshop forma parte del programa de formación interna de Openfinance y está dirigido a los ingenieros del equipo técnico. Como sabemos que hay mucha gente interesada y es muy complicado encontrar formación de calidad en estos temas, Openfinance pone a vuestra disposición dos invitaciones gratis para poder asistir a este evento.

Los que estéis interesados tan solo tenéis que mandar un mail a dev@openfinance.es indicando vuestro nombre, correo electrónico y vuestra cuenta de Twitter (si tenéis) . El jueves 25 realizaremos un sorteo entre todos los interesados y comunicaremos los ganadores.

¡¡¡SUERTE!!!!

evento, workshop , , , ,

iCuke para iPhone

Para realizar pruebas de funcionalidad o aceptación en nuestra aplicación iPhone, podemos utilizar iCuke. Esta herramienta, nos va a ayudar a bajar la barrera que separa a la gente de negocio con los programadores.

Las pruebas de aceptación nos permiten probar el comportamiento de una aplicación desde el punto de vista del cliente.

Una prueba de aceptación se compone de:

  • Feature: Es la característica o funcionalidad que vamos a probar.
  • Scenario: El escenario sería la historia de usuario de la funcionalidad, por lo que cada escenario probaría la funcionalidad en un contexto distinto.
  • Given: Es el estado inicial del escenario, se pueden concatenar varios mediante AND’s.
  • When: En este punto se especificará la acción que se desea probar. Se pueden concatenar con AND’s pero deberíamos probar sólo una cosa en cada escenario.
  • Then: Contendrá las comprobaciones que nos permitirán saber si el escenario se está ejecutando correctamente o no.

En este caso, como ya se ha comentado, la herramienta que vamos a utilizar es iCuke. Con esta herramienta se van a poder hacer pruebas de aceptación en nuestro proyecto iPhone sin necesidad de modificar el código de nuestra aplicación.

Para instalar iCuke, lanzaremos el comando que se muestra a continuación.

$ sudo gem install icuke

La estructura que debemos tener es la que se muestra en la figura 1. Se podría montar la estructura de cualquier otra forma, pero crearse una carpeta para meteré el código de la aplicación me parece la forma más limpia.

Estructura de ficheros

Figura 1: Estructura de ficheros

Dentro de la carpeta features, que se observa en la figura 1, será donde tendremos los ficheros “.feature” que contendrán los escenarios que queramos probar. En la carpeta app es en la que se introduce el código de la aplicación que se desea probar.

A continuación se va a mostrar un escenario de ejemplo. En este ejemplo lo que se prueba es el login de la aplicación Openfinance. Lo que hará será:

  • Inicia la aplicación en el simulador, en este caso se puede observar que la ruta de la aplicación es app/Openfinance.xcodeproj, si se hubiese hecho otra estructura se tendría que poner la ruta que corresponda (Given)
  • Pulsará sobre el botón Login, escribirá la palabra user en el campo Usuario y la palabra pass en el campo Password (When)
  • Comprobará que el nombre de usuario que aparece es “Santi Ruiz” (Then)


Feature: iPhone integration tests
In order to test my iphone application
As a developer
I want cucumber to be able to drive the simulator
Background:
Given "app/Openfinance.xcodeproj" is loaded in the iphone simulator
Scenario: Login
When I tap "Login"
And I type "santi" in "Usuario"
And I type "pass" in "Password"
Then I should see "Santi Ruiz"

Para permitir que iCuke utilice el simulador es necesario que se active el acceso para dispositivos de ayuda en los ajustes de MAC, en la opción Acceso Universal. Además en el simulador hay que activar el Accessibility Inspector entrando en el menú Ajustes -> General -> Accesibility. Se pueden observar en la figura 2.

Configuraciones previas MAC y simulador iPhone

Figura 2: Configuraciones previas MAC y simulador iPhone

Una vez se ha activado todo lo necesario y tenemos nuestro escenario creado, tenemos que ejecutar en el terminal el comando que se muestra a continuación, estando situados en el directorio donde se encuentre nuestra carpeta features creada anteriormente.

$ cucumber features

Tras lanzar el comando anterior, se iniciará la prueba en el simulador, y si se pasan todas las pruebas el resultado que obtendremos será el que se puede observar a continuación.

En el caso de que falle alguna de las pruebas, se nos mostraría en rojo la prueba que ha fallado y las posteriores se abortarían.

desarrollo ,

Evento Agile Levante – Pruebas funcionales

El próximo martes 10 de abril Agile Levante organiza su evento mensual en las oficinas de Openfinance. Esta vez el tema elegido para charlar es pruebas funcionales.

Podéis encontrar más información en http://agilelevante.wordpress.com/ y sacar los tickets en http://agilelevante1204.eventbrite.com/.

desarrollo, evento ,

Testing de servicios REST protegidos con oAuth usando SoapUI

En ocasiones necesitamos montar un test (ya sea funcional o de integración) sobre un servicio que se encuentra protegido por oAuth y nos encontramos en la situación de tener que montar todo el proceso de autenticación para conseguir hacer la llamada.

En lugar de programar un cliente específico (en .Net o en Java) que haga el trabajo y ejecutarlo como un proyecto de pruebas, podemos usar como alternativa la herramienta SoapUI con bastante poco trabajo. En este post vamos a describir como hacerlo paso a paso

 

Entorno de pruebas.

Nuestro entorno de pruebas tendrá los siguientes elementos

  • Servicio web de petición de token de autenticación : GetRequestToken.svc
  • Servicio web de petición de token de acceso al recurso : GetAccessToken.svc
  • Servicio web de acceso al recurso :  Wall.svc (en nuestro caso)

Para simular la autorización por parte del usuario del acceso al recurso protegido, hemos montado un servicio web que valida los datos de prueba y genera la verificación del token requerida

  • Servicio web de validación del token : UserAuthorization.svc

Los servicios REST usados en este ejemplo están desarrollados en C# con VS2010 y emplea la librería de devDefined oAuth (http://code.google.com/p/devdefined-tools/wiki/OAuth) que implementa la versión 1.0 del protocolo

Para el desarrollo de este post hemos usado SoapUIPro versión 4.0.1 aunque la versión libre de la herramienta también sirve para los mismos propósitos.

 

Creando las peticiones a los servicios.

Lo primero que tenemos que hacer es montar un nuevo proyecto para nuestras pruebas y añadir los servicios REST. Con el servicio, el recurso y la petición asociada al mismo creado tenemos que verificar que todo esta correcto.

Abrimos el método que cuelga del recurso (getToken) y añadiremos a ese método el parámetro que necesitamos. En nuestro caso es un parámetro llamado “Authorization” y le indicamos que es de estilo HEADER

Abrimos la petición asociada, verificamos que la URL es la esperada (la editamos ahí mismo si no es el caso)

Si dispusiéramos de algún valor del parámetro valido, lo podemos testear aquí mismo introduciendo ese dato y usando la flecha verde de ejecución.

 

Con todos los servicios creados tendremos un proyecto como el mostrado. Verificamos que todas las peticiones tienen el endPoint adecuado en las peticiones y que todas tienen el parámetro Authorization en los métodos.

 

 

 

 

Creando las pruebas.

El siguiente paso es crear la suite de pruebas que ejecute las llamadas en el orden adecuado preparando las cabeceras de cada llamada y que mueva los datos resultado de cada llamada a la siguiente etapa. Vamos por pasos.

Creamos una nueva TestSuite y un nuevo TestCase en nuestro proyecto. Vamos a usar las propiedades de ese TestCase para mover los datos entre llamadas a los servicios de forma que vamos a la pestaña de “Properties” del caso de test y añadimos las siguientes propiedades mostradas en la captura de pantalla.

Como veréis, solamente las primeras tienen un valor establecido que es el necesario para iniciar la autenticación oAuth. El resto de variables irán tomando valor en cada uno de los pasos del test. El valor de las variables user y password se emplea para simular la autorización por parte del propietario del recurso en el servicio web UserAuthorization.svc

Con las propiedades listas, vamos a ir añadiendo pasos a nuestro caso de test. Para cada servicio estableceremos cuatro pasos simples

  • Crear la cabecera oAuth con un script
  • Insertar la cabecera en el siguiente paso (Property Transfer)
  • Ejecutar la llamada al servicio REST
  • Extraer los datos de la respuesta del servicio y rellenar las variables del Test Case pertinentes.

Empecemos por el primer servicio (GetRequestToken.svc) y empecemos por crear el script que realiza la firma y monta las cabeceras oAuth (Add Step:Groovy Script)

 

El contenido del script es el mostrado en el siguiente fichero :

import java.util.Random
import java.net.URLEncoder
import java.util.regex.Pattern
import java.util.regex.Matcher
import javax.crypto.Mac
import javax.crypto.spec.SecretKeySpec
import org.apache.commons.codec.binary.Base64


// Generate auth_nonce
Random rand = new Random()
def rn1 =(rand.nextFloat() * 100000000)
def rn2 =(rand.nextFloat() * 100000000)
String oa_nonce = "oauth_nonce="+ rn1.round().toString()+ "-" + rn2.round().toString()


// Generate ticks
Date now = new Date();
int tm = (now.getTime()/1000)
String oa_timestamp = "oauth_timestamp=" + tm

//Otras variables
def oa_consumer = "oauth_consumer_key=" + testRunner.testCase.getPropertyValue( "oauth_consumer_key" )
def oa_version = "oauth_version=" + testRunner.testCase.getPropertyValue( "oauth_version" )
def oa_sig_method = "oauth_signature_method=" + testRunner.testCase.getPropertyValue( "oauth_signature_method" )
def oa_secret = testRunner.testCase.getPropertyValue( "oauth_secret" )

// Montamos la firma
String baseURL = "http://localhost:50595/"
String resource = "GetRequestToken.svc"

String headerParams = "oauth_callback=GetRequestToken.svc" +
"&" + oa_consumer +
"&" + oa_nonce +
"&" + oa_sig_method +
"&" + oa_timestamp +
"&" + oa_version

String sigBase = "GET&" +
URLEncoder.encode(baseURL+resource+"/") +
"&" + URLEncoder.encode(headerParams);

String keyF = URLEncoder.encode(oa_secret)+"&"

Mac m = Mac.getInstance("HmacSHA1");
m.init(new SecretKeySpec(keyF.getBytes(), "HmacSHA1"));
m.update(sigBase.getBytes());
byte[] res = m.doFinal();
def signature = new String(Base64.encodeBase64(res));

String cabecera = "OAuth " + headerParams.replaceAll('&', ',') + ",oauth_signature=" +signature;

return cabecera

Como podéis ver, el script calcula la firma de los parámetros y monta la cabecera oAuth con los mismos devolviéndolos como resultado del script. Merece la pena fijarse en la forma de acceder a las propiedades del caso de test (testRunner.testCase.getPropertyValue  ) ya que en todos los demás pasos iremos accediendo a las propiedades que vamos guardando después de cada ejecución de la llamada REST.

A continuación incluimos un nuevo paso de test para mover los resultados del script a la llamada y la llamada al servicio REST. (Incluir los pasos y luego configurar)

El paso de mover parámetros, tomara como origen el resultado del script anterior y como destino la propiedad “Authorization” del paso de llamada a servicio REST.

 

El ultimo paso es de nuevo un “Property Transfer” que obtiene los datos del resultado de la llamada al servicio REST y los introduce en las propiedades del caso de Test.

En nuestro caso, sacamos el token y el secret de la llamada con dos transferencias. Fijaros en que tenemos como origen el paso de llamada REST, la propiedad es “ResponseAsXml” y usamos un XPath (diferente en cada valor) para acceder al dato dentro de la respuesta. El destino es el caso de test y la propiedad correspondiente.

Esto finalizaría el primer paso de llamada al primer servicio REST.

 

Completando el test.

Procedemos de la misma forma en el resto de casos de llamada a los servicios hasta ir completando toda la información necesaria para el último paso que es la llamada al servicio protegido con oAuth. El caso de test completo se puede ver debajo

 

 

 

 

 

Para completar el test, incluimos en la llamada una aserción de test que cuente los nodos de comentario y lo contraste con el número esperado.

Ejecutando el test.

Con todos los pasos creados, podemos ejecutar el test del tirón y comprobar que aparece el resultado en verde.

Pulsando sobre cada paso del log, podemos ver los detalles de ejecución del paso o el error que aparezca en caso de tener alguno.

 

 

 

 

Mejoras y evolución.

Puesto que la llamada a los métodos oAuth son comunes a todas las llamadas a métodos protegidos, podria crearse un caso de test que contuviera solamente las llamadas oAuth y llamarlo como un paso mas en cada uno de los tests de nuestros servicios como paso previo. Esto nos permitiría reutilizar el mismo grupo de llamadas y simplificaría el test de regresión de todos los servicios ofrecidos por nuestro aplicativo.

 

Conclusiones.

Como veis, es bastante sencillo montar un proyecto de test y extenderlo para cubrir todos los servicios ofrecidos por nuestra aplicación que se encuentren protegidos con oAuth.

Os animo a probar este método de prueba y a crearos vuestros própios proyectos de test de las aplicaciones de forma que podais efectuar un test de regresión rápidamente después de cada despliegue.

desarrollo , , , , , ,

CAS 2011

No me gusta escribir sobre este tipo de eventos mientras tienen lugar o nada más terminan porque el compañerismo, la euforia de lo que estás viviendo y el hecho de hablar de mejorar y mejorar me nubla las ideas y no me permite valorar objetivamente el evento. Ahora que ya han pasado unos días hago retrospectiva, miro atrás y puedo dar mi crítica para que sea lo más constructiva posible.

Esta es la primera vez que asistía a un evento de este tipo y mis impresiones son las siguientes:

Me ha gustado…

  • La organización. No es nada fácil organizar un evento de esta magnitud y el resultado ha sido fantástico
  • El compromiso adquirido entre los compañeros que fuimos desde Openfinance para poner en marcha las ideas que íbamos tomando de cada una de las ponencias y otras tantas que nos iban surgiendo
  • La keynote de Xavier Quesada, para mí la mejor de todas las ponencias que han tenido lugar, la que más captó mi atención y de la que más “apuntes tomé”
  • Poner cara a mucha de la gente de la que leo, he oído hablar o sigo en twitter
  • La conversación que tuve con Emma (@hell03610)
  • El esfuerzo realizado por Openfinance por llevarnos y el patrocinio de la comida del viernes demostrando el apoyo y el trabajo que se está haciendo en pro de las metodologías ágiles

No me ha gustado…

  • El nivel y la calidad de muchas de las charlas a las que ido, sin duda esperaba mucho más
  • Que la mesa redonda no diera pie a un debate más abierto y que prácticamente consistiese en la opinión de los que componían la mesa
  • Que los tracks eran muy parecidos en contenido y al final daba la impresión de que todo era muy repetitivo
  • No haber podido intercambiar experiencias e ideas con toda la gente que me hubiese gustado

Mis propuestas para la próxima edición…

  • Que los tracks sean realmente tracks, más diferenciados y que no haya tantas sesiones que hablen de los mismos temas
  • Fomentar más el diálogo entre los asistentes ya que de estas conversaciones es de donde más se aprende
evento