Empezando con Windows Phone 7.1 (y IV) – Esquema de Ramas

Bien,

Ya tengo mi Backlog definido y mis Historias de Usuario más o menos ordenadas. Finalmente, para empezar a concretar (y que luego no se diga) dejadme que os haga un esbozo de esta primera aplicación.

La idea es simple (y nada fuera de lo común). Se trata simplemente de realizar una pequeña aplicación que sirva como una especie de diario personal que permita comentar lugares que uno ha visitado. Probablemente muy sencilla al principio pero (siguiendo con los principios ágiles) iremos incorporando valor a medida que vaya creciendo, tratando desde el primer momento que la aplicación sea capaz de aportar alguna utilidad desde la primera versión que vea la luz.

¿Cuál es el objetivo de la primera iteración? (Probablemente la más dura). Proporcionarme una idea sobre cómo ajustar mi solución de Visual Studio, habituarme a trabajar con los rudimentos de Expression Blend (siempre que sea posible) y proporcionar una primera versión que permita almacenar información sobre un lugar de interés para el usuario.

Empezando por el principio, he creado una estructura de ramas en el control de código (aquí TFS pero aplicable a cualquier otro de vuestro gusto, revisad, eso sí, la consabida guía de Branching en Codeplex). Inicialmente he empezado por considerando un esquema muy sencillo de tres ramas:

  1. Development
  2. Main
  3. Release
Basic Branching Scheme

Esquema Básico de Branching

Este esquema tiene la potencia de ser simple, permitiendo manejar lo más fundamental. Una rama principal de la que sale y hacia la que va la rama de desarrollo y luego N ramas de Release (relacionadas con cada una de las versiones sacadas de la herramienta, aunque potencialmente valdría con la “última versión”). Así mismo, si tenemos un problema con la última versión (que, por supuesto, ha sido adquirida masivamente en el “Market Place” de Windows Phone) podemos sacar una corrección para dicha versión sin invadir la rama de desarrollo.

Para más detalles, echadle un vistazo a la guía en Codeplex. Viene con unos casos de prueba que facilitan la comprensión y la implementación de estos esquemas en Team Foundation Server 2010.

Con este esquema, me he creado una nueva solución en Visual Studio 2010 del tipo Silverlight for Windows Phone Application /Panorama (OS v7.1)

CreandoElProyectoEnVS2010

Silverlight for Windows Phone 7.1 - Panorama App.

Y recordad que, al asociarlo al control de código fuente, la rama estable es “Main” así que esta es la primera rama que creo y, a partir de ella, se crearán “Develop” y “Release”

CreandoLaRamaMain

La primera rama que se crea es Main y, a partir de esta, Develop y Release

Hasta aquí todo sencillo. Los siguientes pasos serán comenzar con el diseño de la apliación (será muy sencillito, espero) y hacer una primera, y horrible, versión operativa en la que el usuario pueda registrar nuevos lugares así como ver qué lugares ha registrado (y el detalle de cada uno).

Mis Sitios de Interés: Vamos allá.

Empezando con Windows Phone 7.1 (y III) – Definición del Backlog

Mientras esperamos a que llegue el nuevo TFS Express (echadle un vistazo en el blog aquí) estos días me he montado un pequeño entorno de pruebas con un Team Foundation Server 2010 donde voy a llevar el control de mi pequeño proyecto.

De momento, por no complicarme la vida e ir arrancando, he escogido la plantilla de metodología Ágil por defecto (MSF for Agile v5.0) más adelante siempre habrá posibilidades de arrancar nuevos proyectos con nuevas plantillas (o con modificaciones a las existentes). He seguido algunos pasos añadidos como instalarme las TFS Power Tools en mi entorno de desarrollo (si dispones de una versión Express de Visual Studio 2010 de momento no te será posible).

Bueno, me he marcado una fecha (primeros de abril) y varias iteraciones. De momento mi idea es colgar de cada “Historia” de aprendizaje una o varias historias relacionadas con el funcionamiento de mi aplicación.

Por cierto, si alguien quiere ir metiendo los datos uno por uno en el TFS a través de las fichas, me parecerá de lujo pero, en mi opinión existe una alternativa mucho más ágil (de lejos). Se llama excel y permite arrastrar, soltar, copiar filas completas, pegar… En fin, luego siempre hay tiempo para un ajustes fino, pero he tardado lo mismo en introducir las dos primeras historias vía el formulario de TFS que el resto vía Excel.

User Story 45 via TFS Form

Historia de Usuario #45 introducida vía formulario de Team Foundation Server

No hay color.

TFS Backlog

Backlog en Team Foundation Server

Siguientes pasos: Completar el Backlog con un poco más de detalle funcional y empezar a asignar “Story Points” que reflejarán el esfuerzo que creo que cada una de las historias tendrá asociado.

Nos vemos en breve.

Empezando con Windows Phone 7.1 (y II) – Definición del Backlog

Que no parezca que me estoy demorando más de la cuenta en empezara a meterle mano al código… Estuve montando el entorno (sin comentarios dignos de mención: siguiente – siguiente – siguiente). Y el resultado es que ya tengo el IDE operativo para empezar a trabajar con Windows Phone.

El siguiente paso es ver qué queremos hacer. Creo que un Hola Mundo! puede aportar más bien poca cosa, así que vamos a ser valientes y comenzaremos con algo más ambicioso.

Para darle un poco más de sentido a todo esto voy a intentar hacer uso de algunas buenas prácticas de Metodologías Ágiles (os recomiendo echar un vistazo al blog de El Bruno para empezar por algo bueno). Si os atrevéis con el inglés, os pongo un enlace a un documento interesante (de Leonard Woody) que explica el proceso guiado, paso por paso, de tareas, actividades y procesos a tener en cuenta en un proyecto en el que se haga uso de la metodología ágil Microsoft Solution Framework for Agile Development v5.0

Así que, en eso estamos. Vamos a empezar pensando qué es lo que quiero que haga mi nueva aplicación. Como el objetivo es aprender (y no hacerme rico con una aplicación rompedora, aunque tampoco le haría feos a eso) los requerimientos que voy a poner sobre la mesa van a estar más orientados a mis objetivos de aprendizaje que a la funcionalidad de la aplicación.

A esta lista de requisitos, en términos de metodologías ágiles, nos podemos referir de varias formas (History List, Product Backlog, etc…) dependerá de la metodología que escojas. En mi caso, todavía no lo he decidido pero estoy dándole alguna vuelta al respecto. Os mantendré actualizados. De momento, he aquí la lista de funcionalidades con las que me gustaría jugar en Windows Phone 7.1.

Backlog

El siguiente paso es empezar con cierto realismo. Al fin y al cabo estoy yo solo, así que la velocidad de mi equipo (es decir, yo) probablemente sea muy baja. Empecemos con objetivos realistas y luego. ¡Cambiemos de opinión! Al fin y al cabo así es como funcionan las cosas. ¿No?

Nos vemos en el siguiente artículo.

Empezando con Windows Phone 7 (y I)

Bueno,

Pues allá vamos. Empecemos por lo más elemental (de perogrullo).

¿Qué necesito para empezar a programar Windows Phone 7(.1)? – Ojo, prácticamente la totalidad de la información que estoy enlazando aquí está en inglés. A medida que vaya encontrando recursos en español los iré incluyendo. Mientras tantos habrá que ir conformándose.

  1. El IDE de Desarrollo: ¡Gratis! Visual Studio 2010 Express for Windows Phone.
    1. A día de hoy, deberías de bajarte e instalarte el Service Pack 1. Acuérdate de ir revisando los últimos Service Packs para estar al día.
  2. Ojo, que lo que te has bajado arriba te permite desarrollar (muchas cosas) pero para hacerlo contra WP, necesitarás descargarte esto
    1. Las herramientas de Desarrollo para Windows Phone (Windows Phone 7.1 SDK)
    2. Actualización de Enero de 2011 para las herramientas de desarrollo
    3. Y, en caso de que desarrolles en Visual Basic .NET, también querrás entrar aquí.
  3. Muy bien. ¿Necesito teléfono? ¡NO! La herramienta viene con un emulador francamente bueno (me lo dejo para otro post). Pero sin duda te vendrá bien tener un teléfono con el que probar algunas de las cosas que quieras hacer. El mío es un HTC HD7, con el que estoy muy contento y que tengo ya desde hace algún tiempo (vaaaale, echo de menos el giróscopo, que no tiene. Pero lo superaré)
  4. ¿Y para aprender?
    1. Una página interesante puede ser la del DownloadCenter de Microsoft para Windows Phone que, en muchos casos terminará por llevarte al
    2. App Hub (os estoy enlazando el americano a falta todavía de algo mejor en español)
    3. El Windows Phone Development for Absolute Begginers de Channel 9
    4. El Windows Phone 7.1 SDK Training Course te puede ayudar a dar los primeros pasos
    5. Windows Phone Development Quickstarts también puede ser de ayuda
    6. La biblioteca de clases con la descripción del API

Hay más. Pero creo que es un buen comienzo, más adelante iré completando la información.

Por último. Verás en algunos sitios que se hace referencia a la actualización “Mango” de Windows Phone como Windows Phone 7.5 (de hecho, sin ir más lejos en este mismo blog). Microsoft decidió liberar Mango como una release 7.1 y no como la 7.5.

Prometo intentar ser lo más coherente posible y hacer el menor número de referencias posibles a una versión 7.5 que, en realidad, no existe.

Fecha Incorrecta en Eventos de SharePoint 2010

Resulta curioso que, en un blog que nace con la idea de hablar de mis experiencias con WP 7.5 la primera entrada sea sobre SharePoint 2010 y el tipo de Contenido Evento. En fin, vamos al grano.

Por ubicarnos un poco. SharePoint permite la utilización de Tipos de Contenido. Un tipo de contenido, al menos según nos cuenta Microsoft en su página oficial, permite modelar diferentes documentos que, si bien pueden estar relacionados entre sí, se crean, usan, comparten y conservan de diferentes maneras. Dichos tipos de contenido disponen, a su vez de cierta información relacionada llamada metadatos. Así pues, una imagen puede ser un tipo de contenido definido en tu colección de sites de SharePoint 2010. Pero explotarla puede hacerse algo complicado si no defines unos pocos metadatos (muchos formatos de imagen ya contienen gran cantidad de información /metadatos) como, por ejemplo: cuándo fue tomada, dónde, quién sale ahí, con qué cámara se tomo, la configuración de la cámara con la que dicha foto fue tomada. Por ejemplo, el formato Exif es un buen ejemplo de ello.

Hace unos días, en el trabajo, nos surgió uno de esos problemas curiosos que todos ansiamos que le ocurran a otro.

Resulta que habíamos creado una lista personalizada y la configuramos para hacer uso de un tipo de contenido que hereda de “Evento“. Evento es el tipo de contenido predefinido por SharePoint para modelar entradas de un calendario. Escogimos heredar de dicho tipo de contenido ya que proporciona mucha potencia a la hora de establecer eventos recurrentes (como reuniones, o sucesos que tienen que repetirse en el tiempo de acuerdo a determinado calendario) y, además añadimos cierta información interesante para el sistema que estábamos construyendo.

Hasta aquí todo perfecto.

Sin embargo, la sorpresa llegó cuando empezamos a probar dicha lista en una configuración similar a la que tendría una vez saliera a producción para su utilización por parte del cliente. Resulta que el cliente en cuestión se encuentra en una Zona Horaria (UTC -5 Eastern Time. US & Canada).

Empezaos a crear eventos y a registrar sus horas (lo bueno de los planes de pruebas es que, si lo tienes todo bien detallado te ahorras muchas idas y venidas).

Bien… Evento 1, Día 1, comienza a la 1 AM y finaliza 1 hora después. ¡Registrado!

Sin embargo, cuando miramos la hora que nos muestra la lista. ¡Cinco horas antes de lo previsto! ¡Vaya! No puede ser que SharePoint almacene en Universal Time Zone para luego olvidarse de mostrarlo bien. ¿No?

Doble click sobre el evento y… ¡Más sorpresa! La hora se muestra bien en el formulario de visualización /edición.

Evento diario creado en una lista MOSS 2010 con UTC -5
Puede verse diferencia en las horas de inicio en la lista y en el formulario

Bueno, basta de aburrir al personal. ¿Cuál es la conclusión? Parece (y lo tengo pendiente de confirmar) que la lista “Calendario” está preparada para hacer la conversión cuando muestra las horas en cualquiera de sus formatos (ya sea calendario, ya sea una vista tabular). Sin embargo, no lo hacen así las listas personalizadas de SharePoint.

¿Bug o diseño? Bueno, en cualquier caso la solución más rápida fue sustituir nuestra vista personalizada por un calendario con una vista tabular personalizada también para ajustarla a las necesidades del usuario.

Evento mostrado en el calendario y en el formulario

Puede apreciarse que no hay diferencia de fechas entre formulario y calendario

Cuando pueda verificar la suposición, miraré si otra opción es utilizar un XSLT personalizado para adaptar la hora … Me lo dejo para otro post.

¡Hola, Mundo!

Parece increíble que, a estas alturas, alguien que lleva ya unos cuantos añitos en el mundo de la informática todavía no tenga su Blog.

Pues bien, heme aquí. Escribiendo mi primera entrada de Blog y con la firme intención de seguir adelante con esto hasta convertirlo en un hábito.

Mi intención (excusa) es ir contando mis andares en la programación con Windows Phone 7 (7.5 más bien) y otras tecnologías con las que trabaje o juegue en mi día a día. Quiero empezar desde cero y aprovechar para poner en común los pasos que doy para ver a dónde llego en mi aprendizaje. Además, estoy más bien tirando a verde en este mundillo del “blogging” con lo que, imagino, este blog cambiará bastante en estilo, aspecto y funcionalidad hasta que de con la tecla.

Bienvenidos a todos (y a mi también, qué narices).

Nos vemos por los internetes.