devnettips

El crecimiento que ha tenido el desarrollo para dispositivos móviles en los últimos años, propiciado por tecnologías como Cloud Computing, el auge de las redes sociales y también, por qué no decirlo, la facilidad de obtener beneficios que tienen los desarrolladores con las tiendas  de aplicaciones (appstore, android market…) invita pensar que el desarrollo para dispositivos móviles (ya sean teléfonos, tablets o lo que venga después) va a ser uno de los mercados más importantes en los próximos años (si no lo es ya), y entrar en él va a ser prácticamente indispensable para todo desarrollador o compañía. 

Pero entrar en el desarrollo de Smartphones se antoja complicado. La multitud de plataformas ya existentes, y las que están apareciendo, provoca una gran fragmentación en el ecosistema móvil, haciendo difícil la elección de por dónde empezar: ¿Apostamos seguro por los IPhone y IPad? ¿O mejor tirar por la opción “libre” que representa Android?¿Quizás sea mejor apuntar a un tipo de cliente más de negocio cómo el que representa Blackberry?¿Bada, WebOs…? También existe la opción multiplataforma, donde estándares cómo el promovido por WAC y la W3C prometen interoperabilidad total, pero por ahora no pasan de ser intentos más o menos acertados.

Uno de los últimos grandes actores en sumarse a este mercado ha sido Microsoft, con su SO Windows Phone 7, que viene a sustituir al ya caduco Windows Mobile. A priori se podría pensar que el salto llega un poco tarde, con Apple ya consagrada y Android creciendo cada vez más, pero el buen trabajo realizado con el SO, la gran comunidad de desarrolladores y su reciente alianza con Nokia (anunciada en el pasado Mobile World Congress de Barcelona) hacen que se les haya que tener en cuenta.

Interfície gráfica

La original y sencilla interfície de usuario hacen de WP7 un sistema fresco y muy atractivo visualmente. Centrándose en el contenido y la tipografía han conseguido desmarcarse de las características interfícies de usuario de sus competidores basadas en listas e iconos, añadiendo además conceptos interesantes cómo el sistema de vista panorámica.

Menú principal de un dispositivo con Windows Phone 7

Sistema de vista panorámica

Desarrollo

Siendo el número potencial de usuarios de nuestras aplicaciones mucho menor, por el momento, que el de las otras grandes compañías, ¿qué nos ofrece a los desarrolladores Microsoft para que nos decidamos por ellos?

Plataformas y Herramientas

Una de las grandes ventajas de Microsoft, es su set de plataformas y herramientas, ya que son las mismas que utilizan los desarrolladores de .Net para web o escritorio. Visual Studio cómo IDE (pudiendo desarrollar en C# o VB.Net), Blend Expression, y Silverlight o XNA Game Studio (para aquellos que quieran desarrollar videojuegos en WP7) permiten una curva de aprendizaje muy pequeña a todos aquellos acostumbrados a desarrollar con ellas, en comparación con el coste de aprender otros lenguajes y plataformas.

Además estas herramientas, así cómo el emulador de WP7, están disponibles de manera gratuita en AppHub, donde también podéis encontrar otros recursos en forma de foros, tutoriales, etc.

Servicios y funcionalidades

Las APIs de WP7 proporcionan acceso a funcionalidades del teléfono como la geo-localización, la pantalla multi-táctil, el acelerómetro o el micrófono, además de servicios como la reproducción multimedia o las notificaciones Push (que permiten actualizar los bloques de la pantalla principal).

Por contra, el sistema no soporta multitarea, dejando en manos de los desarrolladores la opción de implementar opciones de salvar y recuperar el estado (de hecho lo recomiendan cómo Best Practice) para dar la sensación de que la aplicación no deja de funcionar en ningún momento.

WP7 tampoco permite el acceso a la API nativa de Windows. Microsoft justifica esta decisión en base a asegurar la fiabilidad de las aplicaciones desarrolladas, pero esto penaliza en la extensibilidad y personalización de la plataforma.

SDK de WP7

La distribución de aplicaciones WP7 se realiza “únicamente” a través del Windows Marketplace. En este sentido la política de Microsoft es bastante cercana a la de Apple, no permitiendo instalar aplicaciones por otra vía que no sea la de su tienda (aunque es probable que haya gente que encuentre atajos :P). La cuota de acceso al Marketplace (para poder subir y vender aplicaciones) son de 99$ al año, y si no lo he entendido mal, el precio mínimo para una aplicación son 0,99$ (no se pueden subir aplicaciones gratuitas??)

Además, como anécdota, Microsoft no permite subir código libre al Market, lo que ha generado reacciones no muy positivas por parte de la comunidad Open-Source.

De nuevo Microsoft justifica estas medidas argumentando que así evitan que el Market se llene de aplicaciones absurdas que en muchos casos sólo sirven para perder el tiempo (por ejemplo,Android Market está lleno de ellas) y garantizan un alto nivel de calidad y una gran experiencia de usuario en todas sus aplicaciones.

Para abrir una cuenta en el MarketPlace se puede hacer también  través del AppHub

Conclusiones

El nuevo SO de Microsoft puede llegar a ser un importante animador en el sector de los Smartphones.Aunque de momento esté lejos en cuanto a números de las grandes dominadoras (Apple, Android, RIM…), su nombre, su gran comunidad de desarrolladores y su alianza con un gigante cómo Nokia hace que no haya que perderlo de vista.

A su favor tiene, además de lo mencionado:

• Un SO realmente atractivo visualmente y original que además, da la sensación, funciona con una gran fluidez.
• Herramientas conocidas por todos los desarrolladores Microsoft, permitiendo una curva de aprendizaje muy pequeña

Y cómo posibles puntos en contra:

• Un sistema de distribución bastante restrictivo (aunque a Apple, con un sistema similar no le ha ido nada mal)
• Un SO aún un poco verde
• El limitado número de aplicaciones y clientes en comparación a las otras grandes compañías.

Espero que este pequeño artículo os haya ayudado a tener una idea global sobre WP7 y todo lo que le rodea.

Un saludo!!

Después de una interesante discusión producida ayer en twitter y en la lista de agile-spain sobre la estimación en puntos de historia, he estado dándole vueltas al tema y me da la sensación de que es algo que mucha gente cuando empieza con Scrum no tiene demasiado claro. Lo viví en primera persona cuando me tocó supervisar la implantación de Scrum en mi última empresa, llegando incluso a tener discusiones grandes sobre porqué debíamos estimar así y no cómo se había hecho “toda la vida”… Así que me he decidido a aportar mi granito de arena y tratar de explicar de manera sencilla en qué consiste esto de los puntos de historia y qué beneficios aporta.

Antes de empezar, simplemente explicar, para quien no lo sepa, que los puntos de historia es la medida de estimación utilizada cuando se trabaja con Historias de Usuario, una de las técnicas mas utilizadas al trabajar con la metodología Scrum.

Relatividad

En primer lugar  los PH son relativos no absolutos. Es decir estimamos en función de la diferencia relativa entre una historia y otra. Si a una historia le damos 1PH, y a otra 3PH, esto únicamente indica que una es el triple que la otra. ¿Pero el triple de qué? Pues eso lo veremos después. Además, la relatividad se aplica entre diferentes equipos, es decir que 3PH para un equipo no tienen que significar lo mismo para otro equipo (aunque trabajen en el mismo proyecto, no importa!!)

De ahí viene el utilizar la famosa escala de  0, 1, 2, 3, 5, 8, 13, 40.., ya que lo que interesa no es el valor absoluto, únicamente el orden de magnitud, además de que nos ayuda a evitar la tentación de estimar hasta el más mínimo detalle: ¿Que importancia tiene estimar 40 o 42? Cuanto mas grande es la historia a estimar, menos certeza y precisión tenemos sobre la misma, con lo cual la escala nos ayuda a ser conscientes de esa imprecisión.

Tamaño

Cuando se estima en puntos de historia, lo que se intenta es dar un valor del TAMAÑO de la historia. ¿Y qué implica Tamaño? Pues yo entiendo que una combinación de:

• Complejidad: No es lo mismo implementar una alta en un formulario que, por ejemplo, un algoritmo de inteligencia artificial para un juego
• Esfuerzo: ¿Es una tarea que tengo que repetir en muchos sitios? ¿Me va a llevar mucho tiempo aunque sea una cosa fácil?
• Riesgo: ¿Estamos trabajando con una tecnología desconocida? ¿Tiene la gente del equipo experiencia en el negocio?

Utilizando cómo métrica el tamaño, sacamos al tiempo de la ecuación, de manera que evitamos la tentación de buscar conflictos del tipo “esta historia debería estar hecha en 3 días, y tu llevas 4”, o cosas de este estilo que suelen aparecer cuando se utiliza la métrica del tiempo.

Entonces, alguien se preguntará, ¿cómo les decimos a nuestros clientes cuando tenemos listo el producto? Eso lo vamos a ver en el siguiente apartado.

Velocidad

La velocidad es el factor que nos sirve para ver cuanto trabajo somos capaces de entregar en cada sprint. Si nuestra velocidad son 15PH, estamos diciendo que entregamos 15PH de media en cada iteración. Con esto conseguimos ese factor de conversión de los puntos de historia a fechas, es la manera que tenemos de poder decirle a nuestro cliente cuando estimamos que nuestro producto estará listo (ojo, es una estimación, no hay que caer en el típico error de considerar que las estimaciones son contratos!!)

Hay que tener cuidado con esto, ya que se puede caer en la tentación de hacer cuentas y empezar a pensar en tiempo en lugar de estimaciones (1 tío 8 horas = 1PH). Esto aunque en media sea cierto no lo va a ser para todas las historias, e incluso es posible que haya historias de 1 punto, que por ejemplo se tarden mas en hacer que una de dos puntos. Por suerte, la velocidad actúa también cómo factor de corrección y a la larga, todas las historias que estén estimadas con los mismos PH van a caer mas o menos en la misma zona (la distribución aproximada debería tener forma de campana de Gauss)

Tareas

Conviene aclarar que lo que he dicho hasta ahora se refiere a la estimación de historias, no a la de las tareas en las que descomponemos dicha historia durante la planificación de Sprint. No es el objetivo de este post entrar en este tema, así que sólo diré que mi recomendación para la estimación de tareas es:

• No estimarlas
• O dividir la historia en tareas que ocupen aproximadamente un día

En Conclusión…

• Los puntos de historia permiten abstraernos del tiempo a la hora de realizar estimaciones, de manera que podemos centrarnos en aspectos cómo la complejidad o el riesgo de la historia, y valorarla en función de eso.
• Al indicar el tamaño relativo de una historia respecto a otra, es sencillo realizar estimaciones triangulando, con lo cual el proceso,con el tiempo, se vuelve muy eficiente.
• Los PH evitan la especificación al detalle, poniendo de manifiesto el aumento de incertidumbre de una especificación a medida que esta aumenta.
• La velocidad actúa cómo factor de corrección de las desviaciones en las estimaciones y nos permite realizar la conversión a fechas para poder dar plazos de entrega a nuestros clientes o superiores cuando sea necesario.

A partir de aquí lo que toca es experimentar y probar,e intentar encontrar la medida de estimación que mejor se adapte a nuestro equipo, aunque yo sin duda recomiendo encarecidamente probar con los PH!

Ya sabéis, cualquier comentario será bienvenido!!

Aprovecho que en los últimos días los compañeros Luís Ruiz Pavón y Bruno Capuano han escrito sendos artículos sobre Moles ( aquí y aquí ) para hacer una pequeña introducción a otro framework de mocking llamado Moq.

Lo primero que tenemos que hacer es bajarnos la dll de su web . Una vez hecho esto ya podemos incluir la librería (Moq.dll ) en nuestro proyecto de test.

El código que vamos a testear se compone de una clase llamada AssetManager que tiene una dependencia a IDAO, una interfície para definir la manera en que se persistirán los objetos, ya sea en una base de datos, en un fichero o en memoria. Es esta interfície la que «mockearemos», evitando así tener que codificar una implementación para testear AssetManager.

 

Lo primero que vamos a hacer es crear un stub para la función SaveAsset de IDAO. Para tener clara la diferencia entre un Mock y un Stub, consulta este artículo de Martin Fowler.

Veamos el código para testear esta función:

[TestMethod]
public void SaveAsset_returns_true()
{
    var mockDao = new Mock<IDAO>();
    AssetManager assetManager = new AssetManager(mockDao.Object);

    Asset asset = new Asset();
    mockDao.Setup(dao => dao.SaveAsset(asset)).Returns(true);

    Assert.AreEqual(true, assetManager.SaveAsset(asset));
}

Como podemos ver estamos creando un stub de nuestra interfície IDAO indicando que cuando se llame a la función SaveAsset nos devuelva el valor true. Así, al invocar al método SaveAsset de la clase AssetManager, que a su vez llama al método SaveAsset de la interfície IDAO, nos devolverá true y el test pasará. Para comprobar que esto es cierto, basta con cambiar el valor de retorno de la función de IDAO y veremos que el test no pasa.

En el ejemplo anterior, nada nos garantiza que realmente se haya llamado a la función de IDAO, ya que SaveAsset de AssetManager podria haber devuelto true directamente. Ahora vamos a ver como podemos «mockear» una función y verificar que realmente se llama:

[TestMethod]
public void GetAssetByName()
{
    var mockDao = new Mock<IDAO>();
    AssetManager assetManager = new AssetManager(mockDao.Object);

    assetManager.GetAssetByName(«MyFirstAsset»);

    mockDao.Verify(dao => dao.GetAssetByName(«MyFirstAsset»));
}

Como podemos ver claramente en el código, con la función Verify verificamos que se haya llamado a la función GetAssetByName de la interficie IDAO con el parámetro MyFirstAsset. Podemos comprobar que esto es cierto modificando el string «MyFirstAsset» de una de las dos llamadas por otro string. El resultado será que el test no pasará. Este tipo de cosas puede hacer que nuestro test sea demasiado frágil y, por lo tanto, difícil de mantener. Moq nos ofrece la classe It para lidiar con este tipo de problemas. Podriamos substituir el string «MyFirstAsset» por sentencias del tipo:

• It.IsAny<string>() -> pasa como parámetro cualquier string

• It.Is<string>(s => s.StartsWith(«My»)) -> pasa como parámetro un string que empieza por «My»

• It.IsRegex(«ba») -> pasa como parámetro un string que empieza por la letra a

Al igual que podemos comprobar que se ha llamado a una función, quizá también nos pueda interesar comprobar que se ha seteado una propiedad. Para hacerlo, nos apoyaremos en la función VerifySet del mock:

[TestMethod]
public void Verify_ConnectionString_was_set()
{
    var mockDao = new Mock<IDAO>();

    AssetManager assetManager = new AssetManager(mockDao.Object);

    mockDao.VerifySet(dao => dao.ConnectionString = It.Is<string>(connectionString => connectionString.StartsWith(«Non»)));
}

Con este código comprobaremos que se ha seteado la propiedad ConnectionString con un valor que empieza por «Non».

Y por hoy ya tenemos suficiente. Hemos visto que es muy fácil utilizar Moq y hacer los primeros pasos con él. En posteriores tutoriales veremos más características de este framework.

Os dejo el código fuente por si le queréis echar una ojeada.

Hasta la próxima!

Muchas de las implantaciones de Scrum ( u otras metodologías ágiles ) que he conocido estos años son implantaciones que podríamos llamar bottom-up, es decir que parten del equipo de desarrollo. Estos se dan cuenta que no pueden continuar con la organización que llevan ahora y deciden tomar cartas en el asunto y empezar a hacerlo por ellos mismos. Es lo que se denomina comúnmente agilismo de guerrilla.

Aun siendo una muy buena opción para empezar ( yo empecé así ) a la larga se acaba quedando corta y es necesaria la implicación de la gerencia para llegar a algo más completo. Para mi los principales puntos débiles son:

• Adolecen de un mentor experimentado: en la mayoría de los casos, el equipo se ha documentado sobre Scrum y empieza a probarlo.

• Mala repartición de los roles: sobretodo si sólo está utilizando Scrum un equipo, hay gente que tiene dos roles: equipo y Scrum Master o equipo y Product Owner. La por situación es si hay alguien que tiene los tres roles, en lo que esto tiene muchos números de convertirse en un command and control encubierto.

• Product Owner poco implicado: al ser un miembro del equipo le va a costar hacer de Product Owner. No va a tener relación directa con el cliente, no va a saber todo lo que se tiene que hacer a lo largo del tiempo o no le va a gustar definir bien las historias.

Veamos este punto con un poco más de detalle. Todas las cosas en contra que he comentado no tienen porqué pasar… pero tienen muchos números de que pasen. A los desarrolladores en general no nos gusta demasiado hacer especificaciones, definiciones de acabado y cosas por el estilo. Por lo menos a mi no me entusiasma ni a ninguno de mis compañeros. Esto desemboca en que nuestro Product Backlog no sea lo que tendría que ser.

Pero llega un día en que alguien con mucha más relación con el cliente y con visión del producto se instala en tu equipo. Y empieza a generar un Product Backlog con todas las historias que quiere que a corto/medio plazo se implementen, las prioriza, detalla más las más importantes, especifica las condiciones de aceptación de cada una de ellas. Este día será un día importante en tu historia dentro del proyecto. Los cambios más importante que se producirán en tu equipo para mi son:

• Ánimo dentro del equipo: ver que la gerencia se preocupa por el proyecto y pone toda la carne en el asador para que tire adelante anima a la gente.

• Mayor cuidado con la aplicación: todos somos profesionales y estamos comprometidos, pero no es lo mismo que cada quince días el equipo le haga a un Product Owner "externo" la demo del sprint que se la hagan entre ellos.

• Mayor acierto con la implementación de las histórias: el equipo desarrollará lo que el Product Owner quiere, no lo que él cree que el Product Owner quiere.

• Mayor visión del producto: el equipo sabe hacia donde tirará el proyecto y puede tomar decisiones en función de ello.

Por lo tanto, si tienes ya un buen Product Owner en tu equipo, cuídalo y no lo dejes marchar, y sinó búscate uno en quanto puedas!

 

Nota 1: este post está basado en hechos reales. Ningún Product Owner, Scrum Master o miembro del equipo ha sido maltratado en la realización del mismo.

Nota 2: este post está basado en mi experiencia. Si la tuya es diferente, no dejes de contarla en los comentarios!

Empiezo nuestra aventura en geeks con la review de un libro que tengo pendiente desde hace algún tiempo, y que no es otro que Clean Code, de Robert.C. Martin.

Lo primero que tengo que decir de Clean Code, es que es un “Must Have” de cualquier desarrollador que se precie de serlo! Es un de esos libros que debería ser obligatorio que te hagan leer en la facultad, y no sólo leer, sino casi recitar de memoria!

¿Y porqué hago tales afirmaciones? Pues porque Clean Code es un libro genial, bien explicado, con ejemplos claros y concisos, va al grano, y además, es entretenido de leer (bueno, algunos capítulos son un poco pesados, pero en general es bastante ameno)

Si, si,¿pero de que va el libro? os estaréis preguntando muchos… Pues el libro trata simplemente de cómo escribir código limpio (el propio título lo indica). Algo que parece una chorrada pero que es sumamente difícil. En el libro, Robert no das las claves para  ser capaces de escribir código lo más legible posible, algo que además de facilitar la lectura (según él. el 90% del tiempo que pasamos programando, estamos leyendo código nuestro o de otras personas) va a afectar de manera directamente proporcional al diseño, la reutilización o la escalabilidad de nuestro código.

Cómo ya he comentado antes, el libro es muy conciso, presentando en cada capítulo soluciones a diferentes errores comunes que la mayoría de gente comete o ha cometido en diferentes ámbitos del código: Comentarios, Clases, Funciones, Tratamiento de errores, tests unitarios… todo ello aderezado con múltiple ejemplos sacados de proyectos reales. Esta estructura de los capítulos permite tanto una lectura secuencial cómo a modo de libro de consulta. Y además, y vuelvo a repetirme, el libro es muy ameno.

En definitiva, un gran libro que recomiendo a todos los desarrolladores (presentes, pasados y futuros) ya que puede ser una muy buena guía para intentar mejorar en nuestro trabajo.

Un saludo!!

Hola a todo el universo geeks!

Somos Juan Antonio Sosa y Vicenç García y ante todo nos gustaría agradecer a Rodrigo Corral que nos invitara a participar en esta gran comunidad.

Estamos aquí con la intención de intentar aportar nuestro pequeño grano de arena explicando cosas tanto de desarrollo en .Net como de metodologías ágiles de desarrollo y todas sus buenas prácticas asociadas.

Esperamos que os guste lo que vamos escribiendo y que todos podamos aprender cuantas más cosas nuevas mejor.

Saludos!