See you in London!

Fui a Londres por primera vez por año nuevo del 2000 con mi hermana. Londres me enamoró. Es una ciudad enorme pero con millones de sitios donde estar tranquilo, con infinidad de parques y con la mayoría de casas que no tienen más de 2 pisos. Y encima hablan bien inglés 🙂

En 2005 intenté ir a trabajar allí por primera vez. Por aquel entonces me interesaban bastante los gráficos por ordenador y fuí ha hacer una entrevista a una spin-off de la BBC, que se encargaban de hacer todos los gráficos que salían por televisión. La entrevista fue bien, pero al final cogieron a otro chico.

En 2010 lo volví a intentar. Por aquel entonces llevaba 5 años trabajando en Indra y estaba loco por irme de allí. Esta vez fue para ir a trabajar a una entidad financiera. La entrevista también fue bien, pero me dijeron que no por el inglés.

Y por fin 2014 ha sido el año. En parte ha sido una decisión muy difícil de tomar. He tenido el inmeso placer de trabajar en Plain Concepts durante tres años y medio.  Con Ibon siempre recordamos la entrevista que me hicieron. No paraban de preguntarme si sabía tal tecnología o tal otra y yo iba diciendo que no, que no había trabajado nunca con ellas, que yo trabajaba con WinForms y Ado.Net. Pero decidieron darme una oportunidad, y creo que no la he desaprovechado. Ahora mismo soy infinitamente mejor profesional que cuando llegué. Me queda un camino larguísimo por recorrer pero por lo menos estoy en ese camino y sé hacia dónde he de tirar. Y todo ello rodeado de unos compañeros alucinantes de los que he aprendido un montón. Me podría pasar un buen rato diciendo cosas buenas de Plain, pero solo os diré que si os gusta desarrollar en .Net (o desarrollar en general) ya estáis tardando en enviar un correo a Rodrigo.

Pero la verdad es que tenía ganas de irme de España. Un país donde no puedes leer el periódico porqué todo son noticias de corrupción, de recortes en las libertades, de decisiones económicas que solo favorecen a los de siempre. Un país donde mi novia encuentra ofertas de trabajo de 6000 euros al año.

Así que un buen día nos sentamos y decidimos que lo mejor para la familia era intentar irse a Londres. Y por suerte lo hemos conseguido. El lunes que viene empiezo a trabajar en Valtech, una consultora con mucho amor a las metodologías ágiles donde espero seguir aprendiendo un montón.

Así que ya sabéis, si os pasáis por aquí un día, nos vamos a tomar una pinta.

Nos vemos en los pubs!

Se buscan beta testers

Hola a todos,

los amigos de Plastic SCM,  están buscando beta testers para su nueva herramienta de merging, como ellos mismos dicen, su “mergetool” que entiende tu código. Están buscando público específico Microsoft que desarrolle en .NET (c#, vb.net) y que le interesen temas de merge. Aquí tenéis los detalles de la petición:

La panacea del merge de ficheros de código que todos hemos deseado alguna vez es una herramienta que sea capaz de operar método a método, using a using, clase a clase en lugar de línea a línea. Algo capaz de entender que si un developer toca el método GetHostName() y otro mueve GetHostName() de sitio en el mismo fichero, se trata del mismo método, y aplique el movido y el cambio sin generar conflictos absurdos. Suena bien, no?

Pues esa herramienta existe, basada en el núcleo de merge de Plastic SCM pero disponible como standalone tool para TFS, Git, SVN… o el control de versiones que uses…

De hecho, están buscando “early adopters” que quieran proponer sugerencias, mejoras y por supuesto reportar bugs!!

Si te interesa, está disponible para lenguajes .net aquí: http://plasticscm.com/sm/index.html

Venga, animaros a ayudarles, que son buena gente y tienen un muy buen producto.

Un saludo!

Testing with CasperJs – Introduction

 

(Crossposting from vgaltes.com )

Today we will start a serie of tutorials about testing websites using CasperJS. We will cover installation and basic error detection, integration with a Team Foundation Server build and executing tests.

What is CasperJS?

In words of its creators, CasperJS is an open source navigation scripting & testing utility written in Javascript and based on PhantomJS — the scriptable headless WebKit engine. It eases the process of defining a full navigation scenario and provides useful high-level functions, methods & syntactic sugar for doing common tasks.

Installation

First of all we have to download the latest version of PhantomJS and extract the contact where you want. After that it’s recommended to add this path to your PATH environment variable.

Now you can download the tag 1.0.2 of CasperJS repository on GitHub. You can clone the repository and checkout this tag:

$ git clone git://github.com/n1k0/casperjs.git $ cd casperjs $ git checkout tags/1.0.2

or you can download directly from here.

As before, it’s recommended to add the path where you have downloaded CasperJS to your PATH environment variable. But don’t add the base path, add the batchbin folder.

First steps

To test CasperJS we will use the web site created by the MVC internet application template of Visual Studio 2012. If you are not a .Net developer, please create a simple website with your prefered technology, and skip this step.

For .Net developers, open your VS2012 in administrator mode and create a new project with the MVC4 application project type

Project template
Project template

And now chose the internet application template

ProjectCreation2

 

In order to facilitate our job, we will create a new web site on IIS and link it to our brand-new project. So please, open IIS manager and create a new website

Web site creation
Web site creation

And now open the properties window of the web site application project in VS2012 and associate the project to the new web site we’ve just created

project properties
project properties

Now, add a folder under the Scripts folder and create a new JavaScript file called testCasperJS.js.

Working with CasperJS

All the scripts start with a call to ‘create’ method. The simplest way to do it is this:

1 var casper = require('casper').create();

You can pass a javascript settings object to this method with several parameters. For example, we could set the viewport size:

1 var casper = require('casper').create({
2     viewportSize: {width: 1024, height: 768}
3 });

The next function we need to call is ‘start’. This call could be without parameters or we could pass an Url and the function that will be called after the page downloading.

1 casper.start('http://localhost:8000/'function () {
2     this.echo('page downloaded: ' this.getCurrentUrl());
3 });

Now, we only need one more code block to end our first CasperJS script

1 casper.run(function () {
2     this.echo("Done.").exit();
3 });

With this code, we are indicating to CasperJS that we want to run our script and that, when it finishes we  want to write ‘Done’ in the console and exit CasperJS.

Right now, we could save our script, open a Command Prompt, go where the script is located and write

1 casperjs testCasperJs.js

And we will see the result of our script

script result
script result

Conclusions

In this post we have seen how to install CasperJS and how to make a very simple script. In the next posts of this series, we will see more operations to use and how to integrate all these scripts in a build for our Team Foundation Server.

See you soon!

 

Actualización de febrero de TFSService

Buenas a todos,

se acaba de anunciar el despliegue de la actualización de febrero de TFSService. Después de las grandes novedades del sprint pasado capitaneadas por el soporte a Git ha tocado un sprint más tranquilo pero no por ello más interesante. Una de las principales novedades, y algo que eché de menos justo la semana pasada, es la posibilidad de configurar una build de integración continua teniendo un repositorio de Git. Sin duda una característica muy importante en todo buen sistema de integración continua.

Podéis leer más detalles de la release en el post de Brian Harry y en el feed de novedades de TFSService.

Un saludo!

EDIT: para activar las builds de integración continua necesitáis la CTP3 del Update 2 de Visual Studio 2012. La podéis descargar aquí.

Cobertura de código en JavaScript con Blanket.js

Hacía tiempo que andaba buscando una manera de calcular la cobertura de código en JavaScript. Con el amigo Andoni habíamos visto algunas soluciones que no veíamos claras y parecía que al final tendríamos que acabar tirando de jsTestDriver que tiene una herramienta para calcular la cobertura de código. Lo malo de esto es que no nos valía la infraestructura que ahora tenemos montada para pasar los tests y esto nos complicaba un poco la vida.

Pero el otro día llegaba a mi timeline un tweet del amigo Juanjo Coello como este:

Y la verdad es que la librería funciona muy bien. Aquí van los pasos que tenéis que seguir si la queréis utilizar junto con Jasmine.

1.- Bajarse la librería. La podéis descargar aquí: http://migrii.github.com/blanket/
2.- Bajarse el adapter de Blanket para Jasmine de aquí: https://raw.github.com/Migrii/blanket/master/src/adapters/jasmine-blanket.js
3.- En el runner de Jasmine (típicamente SpecRunner.html) incluir el script de blanket y el adapter de Jasmine de la siguiente manera:

<script type=”text/javascript” src=”../libs/blanket/blanket.min.js” data-cover-adapter=”../libs/blanket/jasmine-blanket.js” ></script>

Para incluir los archivos a los que queremos pasar la cobertura de código tenemos dos opciones. La primera es utilizar esta misma línea que acabamos de escribir. Utilizando el atributo data-cover-only podemos indicar los archivos a los que queremos pasar la cobertura, ya sea con una expresión regular, con un string con “comodines” o con un array de nombres de archivo. Un posible ejemplo sería el siguiente:

<script src=”blanket.min.js” data-cover-adapter=”jasmine-blanket.js” data-cover-only=”[‘source1.js’,’src/source2.js’]”></script>

Y ya está, ya lo tenemos todo configurado. Ahora solo falta pasar los tests y al final del archivo se nos adjuntará la información sobre la cobertura.

Saludos!

Espiando a jQuery

Como vimos en un anterior artículo, podemos utilizar Jasmine para espiar a jQuery. En aquél caso, lo hicimos para simular el retorno de una llamada ajax, convirtiendo un posible test de integración en un test unitario en el que se mockea al colaborador.

Imaginemos que nuestro código tiene una función parecida a esta:

 

muestraConfirmacion = function () {
            $("#dialog").fadeToggle('fast');
};

 

Puede que nos interese testear que se ha llamado a fadeToggle y que el selector utilizado ha sido #dialog. Esto lo haremos espiando la función fn de jQuery. Como explican muy bien aquí fn es un alias de la propiedad prototype de jQuery, con lo que podremos utilizarlo como punto de entrada para mockear las funciones de jQuery.

Por lo tanto el test podría quedar así:

 

it("espiamos un selector", function () {
        spyOn($.fn, "fadeToggle");
        var lechazoService = new LechazoService();
        lechazoService.muestraConfirmacion();
                
        expect($.fn.fadeToggle).toHaveBeenCalled();
        expect($.fn.fadeToggle.mostRecentCall.object.selector).toEqual("#dialog");
    });

 

Como podéis observar en el código, comprobamos que se ha llamado a la función fadeToggle y que el selector utilizado ha sido #dialog.

Podéis encontrar más código de ejemplos de test en Jasmine en este repositorio de GitHub: https://github.com/vgaltes/PucelaTechDay

Espero que os sea útil.

TFS Express

Mucho hemos hablado por estos lares de la versión de TFS en Azure, pero todavía no hemos comentado que tenemos otra versión gratuita de TFS lista para utilizar:el TFS Express. Esta versión, al igual que TFS Service, es gratuita para equipos de hasta cinco usuarios, aunque es ampliable a más usuarios con la compra de las CAL’s correspondientes. Se instala sobre un SQLExpress, con lo que no tenemos reportes ni tampoco Sharepoint. Lo malo de esto es que tampoco tenemos la preciosa Task Board de la versión en la nube 🙁 Tenéis más detalles en este artículo de Brian Harry.

Instalar el servicio es extremadamente sencillo. Basta con descargarse el instalador de la página del producto y seguir sus instrucciones paso a paso.

Pasamos las verificaciones:

E instalamos:

Ahora mismo ya tendríamos instalado el TFS. Vamos ahora a instalar el servicio de build:

Seleccionamos el servidor y la colección a la que conectarnos:

Seleccionamos los agentes a instalar:

Qué cuenta queremos utilizar:

Pasamos las verificaciones

E instalamos

Y ya lo tenemos!

 

Como veis, ha sido extremadamente sencillo. Ahora ya podemos abrir nuestro Visual Studio (o nuestro Eclipse) y conectarnos tan ricamente a nuestro recién instalado TFS Express.

Nos leemos!

Material de la charla Automatización de pruebas funcionales

Hola a todos,

solo comentaros que tenéis disponible en este enlace las PPTs de la charla que dí el pasado martes en Artalde sobre Automatización de pruebas funcionales. Espero que a los asistentes les gustara y que a los que no pudisteis asistir encontréis útil la presentación.

Nos leemos!

Ladder of inference

 

“Tenemos que despedir a
Júlia”

Esta acción, que puede
ser importante para tu empresa, para tu equipo y, sobretodo, para la pobre
Júlia, la tomas después de seguir (consciente o inconscientemente) una serie de
pasos llamados ladder of inference. Realizar estos pasos de manera consciente
nos ayudará a tomar decisiones basadas en la realidad. Si recorremos estos
pasos demasiado rápido podemos acabar tomando decisiones basadas en creencias y
en visiones parciales de la realidad, lo que nos puede llevar a que estas
decisiones no sean todo lo buenas que deberían y podríamos acabar despidiendo a
Júlia sin motivos.

Esto, que puede parecer
algo alejado de nuestra realidad como desarrolladores, es muy importante cuando
hacemos retrospectivas. Asegurando que recorremos los pasos con calma,
conseguiremos que nuestras retrospectivas sean mucho más provechosas, con
acciones de mejora más eficaces.

Los pasos del ladder of
inference
son los siguientes: 

Empezando por abajo,
tenemos los hechos y la realidad. Si recorremos estos pasos demasiado rápido
podríamos tener un escenario como este:

  1. Seleccionamos los
    hechos en función de nuestras creencias y la experiencia previa.
  2. Interpretamos qué
    significan
  3. Aplicamos asunciones
    previas, generalmente sin considerarlas.
  4. Extraemos
    conclusiones basadas en los hechos interpretados y nuestras asunciones.
  5. Desarrollamos (o
    afianzamos) creencias basadas en estas conclusiones.
  6. Tomamos acciones que
    parecen “correctas” porqué están basadas en nuestras creencias.

 

 Veamos un ejemplo:

Trabajamos en una
consultora. Nuestro superior nos ha puesto a Júlia en nuestro equipo sin
nosotros pedirlo. Júlia tiene un sueldo por encima de la media y me va a costar
más cuadrar las cuentas a final de trimestre. Desde que está Júlia tenemos
menos velocidad en el equipo y la build está rota constantemente.

¿Qué pasos puedo seguir?

  1. De todo lo que veo,
    selecciono que tenemos menos velocidad y que Júlia rompe muchas builds.
  2. Interpreto que el
    equipo está bajando la calidad de su trabajo.
  3. Como Júlia viene
    impuesta y encima del departamento de BI, asumo que no tiene los conocimientos
    necesarios de programación.
  4. Llego a la conclusión
    que Júlia no está haciendo bien su trabajo.
  5. Me formo la idea que
    Júlia no está capacitada para trabajar con nuestro equipo.
  6. Creo que lo mejor es
    despedir a Júlia.

 

En este proceso hay dos
cosas importantes. La primera es que lo hemos recorrido muy rápido, sin
pararnos a pensar en cada paso ni preguntarnos si eran correctas las
interpretaciones, asunciones, conclusiones que hemos ido tomando. La segunda es
que estamos dejando que el proceso se retroalimente de una manera peligrosa.
Casi en la base del mismo, estamos dejando que nuestras creencias e ideas
preconcebidas nos influyan incluso en el primer paso.

Por tanto, antes de tomar
una acción es necesario que nos cuestionemos cada paso:

¿Estoy seleccionando
todos los hechos importantes?

¿Por qué estoy haciendo
estas asunciones?

¿Puedo testar estas
asunciones?

¿Por qué creo que esto es
la acción correcta a tomar?

¿Me estoy dejando
influenciar por mis creencias de una manera “peligrosa”?

 

La retrospectiva

¿Cómo influye esto en las
retrospectivas? De la misma forma que antes hemos llegado a la acción de
despedir a Júlia seguramente de una manera equivocada o, por lo menos, sin
tener en cuenta otras acciones que podrían ser mejores, en una retrospectiva
podemos llegar a acciones de mejora que no sean todo lo provechosas que
deberían.

Para asegurarnos que
recorremos bien todos los pasos, Esther Derby y Diana Larsen definieron en su
famoso libro “Agile Retrospectives: Making good teams great” un framework a
utilizar para facilitar una retrospectiva. Este framework dicta los siguientes pasos:

Set the stage
En esta fase vamos a explicar el propósito de la retrospectiva y a establecer el foco de esta retrospectiva (una semana, dos semanas, etc)

Gather data
En esta fase recolectaremos los echos (no opiniones) relevantes para la retrospectiva que tienen los miembros del equipo en sus cabezas

Generate insights
En esta fase interpretaremos los echos recolectados en la fase anterior observando patrones, buscando causas, identificando posibles soluciones o mejoras.

Decide what to do
Es esta fase, pasaremos de la discusión a la acción, llegando a un acuerdo entre todo el equipo de las acciones a tomar.

Close the retrospective
Finalmente cerraremos la retrospectiva recordando las acciones y como haremos su seguimiento, reconoceremos el esfuerzo de todo el mundo e identificaremos la manera de hacer mejor la siguiente retrospectiva.

Como veis, hay un claro paralelismo entre los pasos del ladder of inference y los pasos del framework. Siguiendo estos pasos, nos aseguraremos un mejor rendimiento de nuestras retrospectivas.

Espero que el artículo os haya resultado interesante. Nos leemos!

Fuentes:

 

Control estático de código JavaScript con VS2012

Hace poco hablábamos que para pasar JSLint ( o JSHint ) en nuestro código JavaScript desde Visual Studio 2012 teníamos que echar mano de Chirpy. El otro día investigando esto con Rodrigo, vimos que en este breve ( o no tan breve ) lapso de tiempo tenemos dos herramientas más que nos ayudarán en esta tarea, Web Essentials 2012 y JSLint for Visual Studio 2012. Aquí van las conclusiones que saqué:

Web Essentials 2012

Web Essentials es una extensión de Visual Studio muy conocida. A parte de ayudarnos con JSHint, maneja archivos LESS, TypeScript, CoffeScript, y un largo etcétera. Instalarlo es muy sencillo, solo tenéis que ir a la opción del menú “Extensions and Updates” e instalaros la extensión:

 

Una vez instalada la extensión ( y reiniciado VS2012 ) veremos que si hacemos un fichero con un código tan simple como este:

if ( a == 1 )

veremos en la ventana de warnings los siguientes errores:

¡La que podemos liar con tan sólo una línea!

Para configurar las opciones del analizador estático de código tenemos que irnos a TOOLS -> Options

A parte de las configuraciones sobre qué errores mostrar o no mostrar (que os animo a qué exploréis) algo que me parece importante es decidir donde se van a mostrar los mensajes de error. Por defecto estos se muestran en la pestaña de Warnings, pero a mi me gusta tratar estos errores como tales y, por lo tanto, prefiero que Visual Studio me los marque como errores. Por tanto, cambiamos el “Error location” a Error. El problema con esta extensión es que nos pone los mensajes en la pestaña de errores pero no nos da la build por fallida, con lo que, si no somos muy cuidadosos, podemos obviar estos mensajes y nada malo nos pasará. Otro “problema” es que solo se pasa cuando un fichero .js se guarda.

 

JSLint for Visual Studio 2012

JSLint for Visual Studio 2012 es una extensión cuya única finalidad es pasarnos el analizador estático de código. La manera de instalarla es idéntica a Web Essentials:

Las opciones de JSLint están directamente debajo del menú TOOLS y en la siguiente imagen podemos ver que son muy completas:

Algo importante que podemos ver es que podemos validar los archivos tanto al grabar como al realizar una build, que podemos tratar estos mensajes como errores y que podemos cancelar la build si hay errores. Si lo configuramos así podemos ver en nuesta ventana de errores lo siguiente:

Como podéis ver, en la última línea nos informa que ha cancelado la compilación por errores de validación de JSLint.

Otra cosa interesante que tiene JSLint for Visual Studio 2012 y que no tiene Web Essentials es que podemos marcar tanto ficheros individuales como carpetas enteras para que no se le pase el analizador de código. Esto es recomendable cuando trabajamos con librerías de terceros y no queremos que influyan en nuestra build. 

Y por último, algo también muy interesante es que, haciendo click con el botón derecho sobre la solución en el Explorador de Soluciones, podemos añadir el archivo de configuración de JSLint. 

 

Esto nos permitirá subir este archivo a nuestro repositorio de fuentes y que todos los miembros del equipo compartan la misma configuración de la extensión para esta solución ya que la extensión por defecto carga la configuración de este archivo.

Espero que os haya parecido de utilidad!