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.