Coursera: Curso de Android, Semana #1

Acabo de completar la primer semana de este curso. Me llevó unas 4 horas de estudio entre videos, cuestionarios, tareas de programación y configuración/troubleshooting de las herramientas de desarrollo.

Por ahora viene bastante tranquilo, lo cual es lógico para ser la primer semana, pero pinta realmente muy interesante.

Si quieren aprender Android, creo que aún estan a tiempo de sumarse al curso.

Continuará…

 

Desarrollo Android en MacOS Maverick

Hace unos días comencé a hacer un curso de Coursera sobre programación de aplicaciones Android. A la hora de hacer las tareas de programación me encontré con algunas dificultades técnicas en mi ambiente de desarrollo cuya solución comparto aquí.

Para desarrollar aplicaciones Android es necesario el uso de un kit de desarrollo (Android SDK) que incluye entre otras cosas el ADT: Android Development Tools, básicamente un Eclipse personalizado.

La primer dificultad que encontré fue que el material del curso está basado en el SDK 4.3 de Android mientras que el SDK actual es el 4.4. Esta diferencia de versiones generaba algunos warnings en código del curso. Para evitar posibles futuros inconvenientes debidos a la diferencia de versión, decidí instalar el SDK 4.3. Esto lo hice utilizando el SDK Manager que es parte de ADT.

adt

La segunda dificultad que encontré fue la velocidad del emulador. Un desastre, por un lado el emulador tardaba mucho en iniciar y luego, una vez iniciado, cada interacción llevaba más de 10 segundos. Investigué un poco y encontré que debía instalar el paquete Intel Hardware Accelerated Execution Manager. Para mi sorpresa, una vez instalado este paquete, la situación  emperó, cada vez que iniciaba el emulador de Android, mi maquina quedaba totalmente colgada obligándome a reiniciarla. Luego de probar algunas variantes de configuración, me puse a googlear y descubrí que otras personas ya habían experimentado mi misma situación. Al parecer hay un problema conocido entre MacOS Maverick y el paquete Intel Hardware Accelerated Execution Manager 1.0.6 (R3) que yo había instalado. La solución consistió en instalar este hotfix del paquete de Intel. Luego de instalar esto, el desempeño del emulador mejoró notablemente.

Historia de Ágiles Argentina

Si tuviera que definir un hito punto de inicio de la comunidad ágil de Argentina, sin duda diría que ese hito fue la Conferencia Latinoamericana de Métodos Ágiles, Agiles 2008. Luego de ese evento, comenzamos con las reuniones mensuales de la comunidad ágil de Buenos Aires.

Recuerdo que la primer reunión estuvo dedicada a debatir sobre lo discutido en el panel de cierre de Agiles 2008 en el que habían participado los Poppendieck y Tobias Mayer entre otros. También recuerdo que no pude asistí a ese encuentro :-(.

Ya en 2009, empezamos con eventos en formato Open Space. El primero fue el Agile Open Buenos Aires 2009. Para mi el evento fue un éxito total, si les interesa pueden leer algunos posts que escribí en aquel momento. Luego de este evento realizamos lo que denominamos el “Agile Open Tour” que consistió en hacer eventos Agile Open en distintas ciudades del interior del país. Entre las ciudades que visitó el tour en todos estos años se encuentran: Buenos Aires, Córdoba, Tandil, Bahía Blanca, Tucumán, Rosario, Paraná, La Plata y Mar del Plata. En varios casos estos eventos fueron el punto de partida para la conformación de comunidades locales.

Hasta el 2010, la comunidad éramos básicamente un grupo de entusiastas autoorganizados con ganas de compartir inquietudes, experiencias, conocimientos y aprendizajes. Esto estaba muy bien, pero no contábamos con ningún tipo de estructura organizacional lo cual resultaba un inconveniente en ciertas situaciones . Un ejemplo de estas situaciones fue cuando organizamos la conferencia Agiles 2008. Algunos de los sponsors de la conferencia pagaban en especias haciéndose cargo de algún gasto del evento. Pero otros aportaban directamente dinero y esperaban una factura de parte de la organización, ¡oops!.  Este fue el principal motivo que nos llevó a pensar en la necesidad de contar con una estructura organizacional. Básicamente teníamos dos opciones: armar una asociación civil o bien sumarnos a alguna asociación ya existente como ser IEEE o SADIO. Finalmente fue SADIO.

SADIO es la Sociedad Argentina de Informática, una institución que desde 1960 realiza diversas actividades relacionadas a la difusión de la informática. Posiblemente la actividad más importante sean las Jornadas Argentinas de Informática e Investigación Operativa que año a año reunen a investigadores y profesionales de la informática. SADIO prevé en su estatuto la existencia de grupos de interés denominados divisiones. Lo que nosotros hicimos fue crear la División Ágiles Argentina. Para ello, unos 15 participantes de la comunidad ágil nos asociamos a SADIO y completamos las formalidades para dar origen a la división.

Como comunidad, el ser parte de SADIO nos brinda una estructura organizacional que nos facilita la organización de actividades, como fue el caso de Ágiles 2011, Ágiles 2012 y el Scrum Gathering de Buenos Aires en 2012. Como individuos, el estar asociados a SADIO, brinda descuentos para la participación en eventos/cursos/actividades así como también el acceso a una serie de recursos de la institución.

Desde que somos parte de SADIO hemos participado activamente de las Jornadas Argentinas de Informática, dando cursos de agilismo en el contexto del Simposio de Ingeniería de Software (ASSE).  Adicionalmente, en 2013 algunos miembros de ágiles argentina han dictado cursos en SADIO, una actividad que esperamos se repita durante 2014.

La comunidad no tiene un espacio físico, pero si un espacio virtual que está dado por una página y una lista correo, cuya dirección se encuentra en la página.

ao_tandil_2011Agile Open Tandil 2011

Sobre el tamaño de los proyectos y los equipos en agile

Este es un tema que suele prestarse a debate cuando se habla de métodos ágiles. En diversas ocasiones he escuchado afirmaciones tales como:

Los métodos ágiles no sirven para proyectos grandes.

o

En mi equipo no podemos aplicar métodos ágiles porque somos 50 personas.

Quiero dedicar algunas líneas para desmistificar estas cuestiones.

Respecto del tamaño de los proyectos, en primer lugar debemos dejar en claro qué define el tamaño de un proyecto: ¿mucho presupuesto? ¿mucho alcance? ¿mucha gente?. Podríamos decir que el tamaño de un proyecto está dado por su alcance. Naturalmente la cantidad de personas involucradas y el presupuesto del proyecto suelen ser proporcionales al alcance del mismo.

Aclarado qué entendemos por tamaño, podemos entonces preguntarnos ¿existe alguna limitación de tamaño para aplicar métodos ágiles? La respuesta es no. Entonces ¿puedo hacer proyectos de cualquier tamaño usando métodos ágiles? Tampoco.

La cuestión pasa una vez más por el desarrollo iterativo incremental y los ciclos de feedback. En este sentido la propuesta del agilismo es particionar un proyecto grande en varios proyectos pequeños, trabajando en forma iterativa con versiones incrementales que incorporen el feedback en forma temprana.

¿Y que hay del tamaño de los equipos? La respuesta a esto se deriva del párrafo anterior, si trabajamos en proyectos chicos tendremos entonces equipos chicos. Suele  decirse que el tamaño de un equipo debe ser tal que lo puedas alimentar con dos pizzas.

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.