Autor: NicoPaez

Javascript tests running on Jenkins

Nowadays, no matter what technology you use to build your web application, it is almost sure you will need to write some JavaScript code. At the same Javascript script code is not only used to animate the web pages, it is also used to handle validations and application flow. Because of this, everyday is more needed to write unit tests for the Javascript code.

There are several unit testing frameworks for Javascript. In my case I choose Qunit, that is testing framework developed by the jQuery guys.

Of course that in order to be able to write unit tests for your code, you will need to follow some design guidelines, but that is part of another post. Let’s suppose you followed that guidelines and now you want to write some test, these are the steps you should follow to run your tests:

  1. Download qunit.js
  2. Download qunit.css
  3. Write your tests in a javascript file
  4. Create a html page referencing the 3 previous files

With these 4 steps you are almost done, open the html file and you will have your tests executed.

What is missing, is how to run these tests in the build server. The interesting point here is that to run Javascript t tests we need a Javascript engine. In a develop machine, it is not a problem, you can use your browser, but in the build server is not so easy. The approach I took was to use PhantomJS, a tool that among other things, can run Javascript without needing a browser.

So using PhantomJS and MSbuild I was able to have my Jenkins running my Javascript tests.

Here you can download a running example.

Build Tools for .NET

Setting up a build server for .NET development is not so easy like in Java. We could find several explanations for this and one of them could be the huge dependency .net developers have with Visual Studio. I have met many developer that have no idea of how to generate a build of their application without using Visual Studio. Even more, it is very common to find people installing Visual Studio in their build servers 😦 (I did that several times!). Maybe because of this, command line tools never had much popularity among .NET developers. At the same time, Visual Studio along could be not enough to create a quality build (Visual Studio out of the box can not run NUnit tests and StyleCop analysis).

My approach to build my applications is to use a build tool. For the case of .NET there a couple of build tools out there. I think the most popular are:

  • NAnt: it is basically a port of Ant, the famous build tool for Java
  • MSBuild: the Microsoft proposal
  • PSake: is a relatively new tool based on Power Shell

In my case, I choose MSBuild, but it is not enough, because this tool does not have out of box support for integration with some other tools that I use like Nunit, StyleCop, JsLint.  So  in additional to MSBuild I use a set of community extensions called MSBuild Community Tasks.

But the story does not end here, when I want to setup a new build server (or when a new member joins my team) several stuff must be installed in a new box. To simplify this setup, I have created an installation package that contains all the tools I commonly use to build my applications. I have called this package BuildTools4Net. Its current version includes the following items:

  • MsBuildCommunity Taks
  • NUnit
  • SharptLinter
  • FluentMigrator
  • StyleCop

Because of licensing concerns I can not share the my BuildTools4Net installation package, but I am working on script some you can create your own installations package.

Android Time! (curso gratuito)

Al igual que vengo haciendo los últimos veranos, este verano me he anotado para tomar un curso en Coursera. En esta ocasión se trata de un curso de Android llamado: «Programming Mobile Applications for Android Handheld Systems» ofrecido por la universidad de Maryland. El curso comienza el 21 de enero, tiene una duración de 8 semanas y requiere de una dedicación estimada de entre 3 y 6 horas semanales. Pueden ver más detalles en la página del curso.

Desde la semana pasada están disponibles los videos de las primeras clases que presentan la plataforma Android y las herramientas de desarrollo. Ya los estuve viendo y me parece que el curso será muy interesante.

Git + Jenkins + Windows (64 bits)

En el proyecto .net que estoy trabajando, el cliente finalmente nos dió el visto bueno para pasar a Git (veníamos trabajando con Subversion). Esto nos obligó a modificar la configuración de nuestro Jenkins para tomar el código de Git. Pero resulta que yo nunca había trabajado con Git + Jenkins sobre Windows Server, pues en general al trabajar en Windows siempre me he inclinado por Team City.
El pequeño tema que me requirió un poco de investigación fue hacer que Jenkins se conecte al servidor Git usando credenciales ssh. Aquí mi hallazgo:

En Windows el instalador de Jenkins instala Jenkins como servicio de Windows, poniéndolo a correr bajo la cuenta de usuario Local System. Cuando Jenkins intenta conectar a Git busca la clave privada ssh en el directorio home del cuenta de usuario actual, que en este caso viene a ser Local System. El en caso de Windows Server de 64 bits, el directorio home asociado a la cuenta Local System es %windows%\SysWow64\config\systemprofile.

Visual Studio 2013, esas cosas tan típicas de Microsoft

La semana pasada empecé a trabajar en un nuevo proyecto. Algo en teoría simple, un sitio web de tipo «informativo», en el sentido que tiene mucha información y muy poca lógica de negocio. El líder técnico del cliente decidió que lo hicieramos con ASP.NET MVC 4, corriendo sobre .Net 4.5 y utilizando Visual Studio 2013 como entorno de desarrollo.

Cómo era de esperar a la hora de instalar Visual Studio 2013 me encontré con varias cuestiones que podrían resultar difíciles de creer para muchos desarrolladores, pero que no sorprenden a nadie que haya trabajado con tecnología Microsoft por un par de años.

La primera cuestión llamativa fue que apenas ejecuté el instalador, me encontré con un mensaje indicando que la aplicación a instalar (VS2013) no era compatible con mi sistema operativo (Windows 7). Me ví obligado a instalar el Service Pack 1 de Windows 7.

Una vez instalado el SP1, volví a ejecutar el instalador y me encontré con un mensaje que me indicaba que la instalación requeriría ~9 GB, si si, NUEVE GIGABYTES. Lo curioso es que yo estaba intentando instalar esta aplicación en una máquina virtual cuyo peso en ese momento era de unos 8 GB.
Como me costaba resignarme a que mi máquina virtual creciera tanto, hice una instalación personalizada en la que removí ciertos componentes que no eran de mi interés y logré bajar de 9 GB a 7 GB.

Continuando con la instalación, me encontré con otro mensaje que me indicaba que mi máquina no contaba con Internet Explorer 10 y que ello podría ocasionar que algunas funcionalidades de Visual Studio no estuvieran disponibles. Así que suspendí la instalación de Visual Studio e instalé la nueva versión de Internet Explorer.

Finalmente pude completar la instalación de Visual Studio 2013.

ASP.NET: WebForms and MVC Side by Side

This is the situation I am facing:

I have a WebForms application that has been running for years. It was initially built with VS2008 (net 3), then was updated to VS2010 (net 4) and was recently updated to VS2012 (net 4.5).

The client has decided to redesign the UI of some pages. He hired a group of designers that produced a very cool set of new pages based on HTML5 and CSS. Now I need to take that HTML and CSS and adjust the webforms application. As you can imagine this can be a really hard work, because among other things, the webforms application uses several non-standart asp.net webcontrols.

So, what I would like to do is to implement these new pages using ASP.NET MVC. I did some googling and it seems it is possible to have WebForms and MVC living side by side in the same application. But before going further I would like to hear some opinions.

Sobre herramientas de gestión: Pizarra vs. Software

Ayer tuve una interesante charla sobre este tema. Uno de los participantes se inclinaba fervientemente por el uso de herramientas físicas: pizarra y post-its. Yo en cambio me inclino más hacia el uso de herramientas de  software, tal vez sea porque no soy muy amigo del papel o tal vez sea que tengo algunos motivos más profundos y menos subjetivos como ser:

  • El uso de pizarra y post-its tiene como positivo que es un irradiador natural de información y con un simple vistazo uno puede ver el estado. Sin embargo, esto ya no es algo exclusivo de las pizarras. Hoy en día existen diversas herramientas de software que «emulan» una estética/experiencia similar a los post-its y que combinadas con un monitor grande dedicado (o directamente un televisor) permiten disfrutar de este beneficio de la irradiación de información. Personalmente he trabajado con herramientas de software como Trello, Mingle y Pivotal, con muy buenos resultados.
  • El uso de post-its hace más compleja la obtención de métricas, ya sea porque las mismas deben calcularse a mano o bien porque la información que está en post-its debe replicarse en alguna herramienta software para el cálculo de las métricas.
  • Si tu organización requiere algún tipo de trazabilidad o un historial de items es muy posible que ya estés obligado a usar una herramienta de software.
  • Finalmente está la cuestión de la distribución del equipo, hoy en día es cada vez más común tener gente distribuida físicamente, lo cual dificulta el uso de herramientas físicas. Ojo, no digo que no puedan usarse, sino que su uso en un contexto así puede llegar a requerir de trabajo adicional.

Claro que si tu equipo no está distribuido y no usas métricas en tu proyecto puede que resulte más práctico usar una pizarra.
Más allá de esto, debo reconocer que hay cierta «mística» o «ritual» en el uso de post-its, que en ciertos contextos puede resultar motivador para los equipos.

Un proyectito en PHP

En los inicios de mi carrera hice algunas cosillas con Php motivado por un curso de Php que había tomando en el Club de Programadores y cuyo instructor había sido el maestro AJ Lopez.

Hace un tiempo volví a poner mis manos en Php y me encontré con varios cambios, algunos de los cuales había escuchado pero no había tenido la oportunidad de experimentarlos.

Mi percepción es que el lenguaje ha evolucionado bastante, incorporando diversas construcciones y soporte para programación orientada a objetos.

Por otro lado veo un gran ecosistema de herramientas y frameworks que le han permitido mantenerse como uno de los principales jugadores en el ámbito del desarrollo web a pesar del gran avance de Ruby y Python.

Al mismo tiempo noto que a diferencia de lo que ocurre en Ruby y Java, la comunidad no estan del todo «alineada», hay cuestiones que no parecen estar estandarizadas y otras que a pesar de parecer estandarizadas son ignoradas por gran parte de los practicantes.

En mi caso particular resulta que desde comienzo de año venía trabajando en una organización en una iniciativa de Continuous Delivery y llegado un punto necesitamos de una herramienta para secuenciar los pedidos de despliegue a cada ambiente. Por diversas cuestiones esta organización decidió construir esta herramienta con Php usando el framework Silex. Luego de una primera versión, fue necesario realizar algunas modificaciones y agregar nuevas funcionalidades y por cuestiones de disponibilidad de tiempo, fui yo el encargado de estas cuestiones. Esta organización ha manifestado la intención de liberar está herramienta con licencia open source, por ello es posible que en breve les traiga más noticias.

Continuará…

Firefox, mi navegador de desarrollo

Desde hace ya años uso un navegador para hacer desarrollo y otro para todo lo demás.  Esto se debe a que en mi navegador de desarrollo suelo estar probando plugins de forma relativamente frecuente lo cual podría llegar a «romper» el navegador o a impactar negativamente en el comportamiento de una alguna aplicación web.

Como navegador de desarrollo uso FireFox, pues tiene una importante cantidad de plugins que me resultan muy útiles para el desarrollo web entre las cuales se cuentan SeleniumIDE, FireBug, YSlow, HttpFox y ScreenShooter.

Por otro lado, uso Chrome para todo lo demás que no es desarrollo pues me resulta muy cómoda la forma en que se integra con los servicios de Google que uso de forma cotidiana.

Un detalle adicional que no es menor, es el que hecho de que FireFox se mantiene en cierto modo «más limpio/neutro» que Chrome, ya que este último incluye cada vez más extensión particulares para integración con los servicios de Google, algo que puede ser útil para el usuario final, pero que como desarrollador comienza a hacerme un poco de ruido.