Para averiguarlo, podemos recurrir a la documentación que tenemos en MSDN, aunque también podemos ver directamente el código fuente.

La API que se nos ofrece es open source, con lo cual podemos no solamente ver el código fuente sino además poder realizar contribuciones al mismo.

En este artículo quiero hacer un breve recorrido por la API, para una operación muy concreta, insertar elementos. En otros artículos de esta serie veremos cómo hacer consultas, o qué pasa del lado de servidor.

Para este artículo usaremos los siguientes elementos:

• Tutorial de datos
• Documentación de la API en MSDN
• Código fuente del SDK en Github

Los ejemplos los veremos con el SDK de Windows Phone 8, pero podemos ver que existe un código similar para el resto de plataformas compatibles.

De un vistazo

La API de Azure Mobile Services está compuesto por objetos que nos ayudan a:

• Convertir nuestros objetos a formato JSON para su envío y hacer la operación contraria a la recepción (Serialización)
• Realizar solicitudes al servicio que hemos creado en Azure mediante comandos HTTP usando una arquitectura REST
• Gestionar autentificación y seguridad para las mismas.

El código fuente del SDK para Windows Phone 8 contiene varios elementos

• Tests que aseguran su integridad (a nivel de core como a nivel de cada cliente en particular).
• Código manejado (es decir, código en .NET tradicional).
• Código nativo, dentro de los espacios de nombres de WinMD (Recordemos que Windows Phone 8 tiene soporte para las API nativas de WinRT).

Para poder trabajar con Mobile Services necesitamos en primer lugar una referencia a la tabla:

private MobileServiceCollection<TodoItem, TodoItem> items;
private IMobileServiceTable<TodoItem> todoTable = 
    App.MobileService.GetTable<TodoItem>();

Este método está situado en la clase MobileServiceClient que contiene otros que veremos a lo largo del artículo:

Este método está situado en la siguiente ruta:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceClient.Managed.cs

El código es el siguiente:

public IMobileServiceTable GetTable()
{
    SerializableType type = SerializableType.Get(typeof(T));
    return new MobileServiceTable(type.TableName, this);
}

En primer lugar obtiene un tipo serializable específico, que es el que se usará para poder transformar el objeto en una tabla en el servidor. Luego generará una tabla de tipo MobileServiceTable con el nombre creado a partir de este tipo. Hasta aquí solamente hemos hecho trabajo en local, es decir, no ha habido conexión con el servicio.

Veamos qué pasa al insertar un elemento en la tabla:

await todoTable.InsertAsync(todoItem);

El código para esta función se encuentra en la siguiente ruta:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceTable.Generic.cs

En este código lo que vemos es lo siguiente:,

• No podemos insertar elementos nulos,
• Se obtiene un JObject (un objeto serializado en formato JSON) a partir de MobileServiceTableSerializer
• Se envía una petición ya con el objeto serializado
• Se recibe el resultado de la petición (en formato JSON)
• Finalmente, se convierte el objeto recibido en el enviado, por si los datos hubiesen cambiado.

public async Task InsertAsync(T instance)
        {
            if (instance == null)
            {
                throw new ArgumentNullException("instance");
            }

            // Serialize the instance
            JObject value = MobileServiceTableSerializer.Serialize(instance).AsObject();

            // Send the request
            JToken response = await this.InsertAsync(value);

            // Deserialize the response back into the instance in case any
            // server scripts changed values of the instance.
            MobileServiceTableSerializer.Deserialize(response, instance);
        }

El envío de la petición se hace en dos fases, una fase manejada, y otra fase nativa, la fase manejada se hace en un fichero situado en:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceClient.Managed.cs

En el que se realiza la siguiente operación:

public Task<JToken> InsertAsync(JObject instance)
{
    return this.SendInsertAsync(instance);
}

Que nos lleva a este otro fichero (situado en la fase manejada):

internal async Task SendInsertAsync(JObject instance)
{
    if (instance == null)
    {
        throw new ArgumentNullException("instance");
    }

    // Make sure the instance doesn't have its ID set for an insertion
    if (instance.Get(IdPropertyName) != null)
    {
        throw new ArgumentException(
            string.Format(
                CultureInfo.InvariantCulture,
                Resources.CannotInsertWithExistingIdMessage,
                IdPropertyName),
            "instance");
    }

    string url = GetUriFragment(this.TableName);
    JToken response = await this.MobileServiceClient.RequestAsync("POST", url, instance);
    JToken patched = Patch(instance, response);
    return patched;
}

Aquí las operaciones realizadas son:

• Comprobar que el elemento que estamos insertando no tenga ya un Id, al fin y al cabo es nuevo.
• Obtener la url de la tabla a la que vamos a insertar el elemento.
• Enviar una petición HTTP POST al servicio web, con la url que hemos especificado y los datos, y recuperar el resultado.
• Actualizar el objeto enviado con la respuesta.
• Devolver el objeto enviado.

Finalmente llegamos a RequestAsync, donde se realiza la petición, situada en este fichero:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceClient.cs

Este método genera una petición del tipo deseado, especifica que solamente queremos parámetros en formato JSON, especifica la autenticación a partir de las claves que hemos especificado en la configuración inicial, y finalmente envía la petición:

internal async Task<JToken> RequestAsync(string method, string uriFragment, JToken content)
        {
            Debug.Assert(!string.IsNullOrEmpty(method), "method cannot be null or empty!");
            Debug.Assert(!string.IsNullOrEmpty(uriFragment), "uriFragment cannot be null or empty!");

            // Create the web request
            IServiceFilterRequest request = new ServiceFilterRequest();
            request.Uri = new Uri(this.ApplicationUri, uriFragment);
            request.Method = method.ToUpper();
            request.Accept = RequestJsonContentType;

            // Set Mobile Services authentication, application, and telemetry
            // headers
            request.Headers[RequestInstallationIdHeader] = applicationInstallationId;
            if (!string.IsNullOrEmpty(this.ApplicationKey))
            {
                request.Headers[RequestApplicationKeyHeader] = this.ApplicationKey;
            }
            if (!string.IsNullOrEmpty(this.currentUserAuthenticationToken))
            {
                request.Headers[RequestAuthenticationHeader] = this.currentUserAuthenticationToken;
            }

            // Add any request as JSON
            if (content != null)
            {
                request.ContentType = RequestJsonContentType;
                request.Content = content.ToString();
            }

            // Send the request and get the response back as JSON
            IServiceFilterResponse response = await ServiceFilter.ApplyAsync(request, this.filter);
            JToken body = GetResponseJsonAsync(response);

            // Throw errors for any failing responses
            if (response.ResponseStatus != ServiceFilterResponseStatus.Success || response.StatusCode >= 400)
            {
                ThrowInvalidResponse(request, response, body);
            }

            return body;
        }

Es todo un conjunto de acciones que se llevan a cabo solamente para insertar un elemento. En el próximo artículo veremos cómo se ejecutan las consultas usando la API, y cómo funcionan métodos como este:

List<TodoItem> items = await todoTable
   .Where(todoItem => todoItem.Complete == false)
   .ToListAsync();

Happy Hacking!

Para ello me he creado un pequeño proyecto de ejemplo, y con la ayuda del desensamblador del lenguaje IL (el lenguaje intermedio que se genera cuando compilamos algún lenguaje de .net como C#) he podido ver qué pasaba realmente. Los resultados no dejan de ser interesantes.

Antes de empezar, un par de apuntes.

• IL nos podría recordar a ensamblador, ya que las funciones están basadas en manejo de pila, colocando en la misma el resultado antes de retornar.
• Los valores se definen por índices, de tal manera que cuando hablamos de ldarg.0 estamos operando con el índice 0.
• El resultado de llamadas a funciones externas se obtiene también de la pila.

Vistos estos detalles, pasemos al programa en cuestión:

class Program
{
    public static string MyFirstCustomFunction(string a)
    {
        a = a.Substring(4);
        return a;
    }

    public static string MySecondCustomFunction(string b)
    {
        return b.Substring(4);
    }

    public static string MyThirdCustomFunction(string c)
    {
        var result = c.Substring(4);
        return result;
    }

    static void Main(string[] args)
    {
        Console.WriteLine(MyFirstCustomFunction("Lorem ipsum dolor sit amet"));
        Console.WriteLine(MySecondCustomFunction("Lorem ipsum dolor sit amet"));
        Console.WriteLine(MyThirdCustomFunction("Lorem ipsum dolor sit amet"));
    }
}

Vamos con la primera función, si cargamos ILdasm a partir de la consola de desarrollador de Visual Studio, podemos cargar el ejecutable, obteniendo esta imagen:

Vamos con el desensamblado de la primera función:

.method public hidebysig static string  MyFirstCustomFunction(string a) cil managed
{
// Code size       16 (0x10)
.maxstack  2
.locals init ([0] string CS$1$0000)
IL_0000:  nop
IL_0001:  ldarg.0
IL_0002:  ldc.i4.4
IL_0003:  callvirt   instance string [mscorlib]System.String::Substring(int32)
IL_0008:  starg.s    a
IL_000a:  ldarg.0
IL_000b:  stloc.0
IL_000c:  br.s       IL_000e
IL_000e:  ldloc.0
IL_000f:  ret
} // end of method Program::MyFirstCustomFunction

Lo que está pasando es lo siguiente:

• Se define al principio del todo la variable de retorno, con el índice 0.
• Se carga en la pila el valor pasado por argumento.
• Se carga también de manera constante el entero de 4 bytes (i4) de valor 4.
• Se llama a la función substring, accediendo primero al ensamblado, y luego al espacio de nombres.
• Se obtiene el resultado de la pila (recordemos los apuntes iniciales), y se almacena en a
• Se vuelve a cargar en la pila el valor del argumento (que acabamos de machacar).
• Se almacena este valor en la variable de retorno (en la posición 0).
• Se realiza un salto a la siguiente línea (en este caso sin ninguna razón aparente).
• Se carga el elemento de la variable de retorno en la pila (para que la función que ha llamado a esta pueda acceder).
• Se retorna.

Por lo que podemos ver aquí, el hecho de almacenar el resultado en el argumento hace que carguemos el valor varias veces, lo cual no tiene por qué ser necesario.

Veamos qué sucede con la segunda función:

.method public hidebysig static string  MySecondCustomFunction(string b) cil managed
{
// Code size       13 (0xd)
.maxstack  2
.locals init ([0] string CS$1$0000)
IL_0000:  nop
IL_0001:  ldarg.0
IL_0002:  ldc.i4.4
IL_0003:  callvirt   instance string [mscorlib]System.String::Substring(int32)
IL_0008:  stloc.0
IL_0009:  br.s       IL_000b
IL_000b:  ldloc.0
IL_000c:  ret
} // end of method Program::MySecondCustomFunction

Hasta la llamada 0003 es exactamente igual que el anterior (incluida la definición de la variable de retorno de la función), sin embargo pasa lo siguiente.

• Se fija, directamente desde la pila, el valor a la variable de retorno.
• Se vuelve a colocar dicho valor en la pila antes de volver a la función “padre”.

Por lo que se ve, esta sería una opción sin duda más eficiente, ya que evita una operación de lectura.

Veamos qué pasa en el último caso, usando una variable intermedia que NO es la que hemos pasado por argumento, ¿cual sería el comportamiento en este caso?

.method public hidebysig static string  MyThirdCustomFunction(string c) cil managed
{
// Code size       15 (0xf)
.maxstack  2
.locals init ([0] string result,
[1] string CS$1$0000)
IL_0000:  nop
IL_0001:  ldarg.0
IL_0002:  ldc.i4.4
IL_0003:  callvirt   instance string [mscorlib]System.String::Substring(int32)
IL_0008:  stloc.0
IL_0009:  ldloc.0
IL_000a:  stloc.1
IL_000b:  br.s       IL_000d
IL_000d:  ldloc.1
IL_000e:  ret
} // end of method Program::MyThirdCustomFunction

La primera diferencia es que antes de empezar la ejecución tenemos una segunda variable local definida como una cadena, de tipo string, e inicializada, al igual que la variable de retorno. El resto de las llamadas hasta 0003 es igual, y podemos ver que hace:

• Guardar el resultado en la variable de retorno.
• Cargar el resultado de la variable de retorno en la pila
• Mover de la pila a la variable result.
• Mover de la variable result a la pila una vez más.

Es decir, se vuelve a hacer una operación de doble lectura y escritura, exactamente igual que la anterios, salvo que en vez de acceder a los argumentos, se accede a variables locales. Queda pendiente averiguar qué operación sería más costosa.

En resumen, si devolvemos directamente el resultado de una operación sin usar variables intermedias ahorramos una operación de lectura y escritura en la pila.

Para complementar, esta entrada de Stack overflow habla sobre algunas cosas que he dejado en el tintero, como los nop y las br:

http://stackoverflow.com/questions/12667008/questions-about-hand-coded-il-based-on-disassembled-simple-c-sharp-code

• Local: Se almacena en un directorio local al cual solamente tiene acceso nuestra app.
• Roaming: Se almacena de manera local, aunque esos contenidos se sincronizan entre los diferentes dispositivos que tengan nuestra cuenta live id. Si tenemos un juego, y queremos mantener el estado de la partida sincronizado, podremos usar esta carpeta.
• Temp: Se almacena de manera temporal, y se pueden borrar cuando la app esté cerrada.

En este artículo veremos cómo acceder a los ficheros almacenados en estas carpetas, y como hacer operaciones de lectura y escritura en los mismos.

Acceso a la ubicación:

Para acceder a estos datos, el primer paso es agregar la referencia a Windows storage:

using Windows.Storage;

Una vez tenemos la referencia, tenemos que acceder a la carpeta que contiene nuestros ficheros, y al fichero en sí, aquí podemos especificar qué tipo de carga queremos hacer:

StorageFolder localFolder = ApplicationData.Current.LocalFolder;
StorageFile myFile = await localFolder.CreateFileAsync("myfile.txt",
CreationCollisionOption.OpenIfExists);

El enum CreationCollisionOption permite especificar qué pasa si el fichero existe, teniendo entonces los siguientes escenarios:

• Si existe, abrir
• Si existe, devolver error.
• Si existe, sobreescribir.
• Si existe, renombrar.

Lectura de ficheros:

Para leer el fichero, en caso de que estemos trabajando con ficheros de texto, es mediante el uso de la clase FileIO:

string content = await FileIO.ReadTextAsync(myFile);

En este ejemplo todo el texto se lee a una sola variable, aunque también se puede pedir que devuelva cada línea en un elemento de una lista, usando el método ReadLinesAsync.
En caso de que estemos trabajando con ficheros binarios, deberemos realizar la lectura usando streams. Recordemos que los streams debemos liberarlos con la operación dispose como se muestra:

IRandomAccessStream stream = await myFile.OpenReadAsync();
stream.Dispose();

Aunque también es posible emplear using para un recurso que se liberará al salir del bloque;

using (IRandomAccessStream stream = await myFile.OpenReadAsync()){}

Una vez que tenemos el stream, se puede convertir a lo que necesitemos, imagen, audio, vídeo o incluso texto.
Escritura en ficheros:
Por lo generla una app de Windows 8 solamente puede escribir donde el usuario le diga, o en las carpetas que hemos comentado anteriormente. En el caso de ficheros de texto la escritura se realiza de la siguiente manera:

await FileIO.WriteTextAsync(myFile, content);

En el caso de streams, por otra parte, tenemos que leer el fichero con permisos de escritura, y usar un datawriter para almacenar información en nuestro stream. En el ejemplo, usando un texto:

using (IRandomAccessStream stream = await myFile.OpenAsync(
FileAccessMode.ReadWrite))
{
    using (DataWriter dataWriter = new DataWriter(stream))
    {
        dataWriter.WriteString(/*Text*/);
        await dataWriter.StoreAsync();
    }
}

Conclusiones

Usando el almacenamiento local y roaming podemos almacenar y acceder a ficheros de manera local en nuestra aplicacion. Estos ficheros pueden ser, o bien binarios, o bien de texto plano.

La idea es simplificar la resolución del conflicto entendiendo el código, resolviendo de manera automática aquellos en los que sea posible y permitir al usuario, de manera sencilla, encargarse de los conflictos restantes. En este artículo veremos de un vistazo la herramienta sus características, los casos que cubrimos y cómo la hemos desarrollado.

Una interfaz sencilla

La herramienta, formada básicamente por un panel donde se muestran los conflictos y diferencias, y un visor de código, permite por una parte resolver conflictos, y por otra ver en detalle los cambios sucedidos en cada fichero respecto a la base.

Para ayudar al usuario, cada conflicto tiene, en la cabecera, un campo identificado por una letra y un color por cada cambio que lleven al conflicto, en el ejemplo, un cambio concurrente en un método.

La magia

Para poder mostrar estos conflictos y resolver de manera automática aquellos en los que sea posible, analizamos los ficheros que el usuario nos pasa por parámetros, o a través de la pantalla inicial, si iniciamos sin parámetros (origen, destino y base).

Una vez hemos leído los ficheros y comprobado que no haya errores de análisis, creamos, para cada uno, un árbol semántico, similar a la ventana de clases que se puede ver en Visual Studio.

Ya con estos árboles, comparamos el origen y el destino con la base para obtener lo que denominamos un árbol de diferencias. Finalmente comparamos estos árboles de diferencias para obtener los posibles conflictos y las diferentes formas de solucionarlos.

Escenarios

Hemos empleado cientos de horas de análisis, y procesado millones de repositorios para obtener las operacions y los conflictos más comunes, entre los que destacan:

• Movidos divergentes: Si estamos haciendo refactor de nuestro código y movemos a diferentes partes del mismo (desarrollador A los prefiere por orden alfabético y desarrollador B los prefiere por orden de scope) detectamos el cambio y damos al usuario la opción de elegir.
• Movidos/borrados: En caso de que un elemento (método, clase…) se haya movido en origen y se haya borrado en destino, lo detectamos y damos al usuario la opción de conservar el movido o el borrado.
• Movidos + cambiados: En el caso de que un desarrollador mueva un método a otra clase y otro realice cambios en el mismo, se detectará automáticamente, y no habrá conflicto :)

Hay mucho más, disponible en semanticmerge.com

Integración

De momento, tenemos tutoriales sobre cómo integrarlo en Git, PlasticSCM, TFS y Perforce, y pronto deberíamos tener para Mercurial y SVN. Si usas otro sistema de control de versiones, avísanos!

Personalización

Mediante los parámetros de entrada, podemos especificar una herramienta de diff y merge personalizada, a través de los parámetros -emt y -edt de entrada. Además se puede especificar el tipo de fichero que estamos procesando aunque no tenga la extensión adecuada mediante el parámetro -t. En estos momentos el único lenguaje de programación soportado es C#, así que en este caso el único valor válido será text/csharp.

One more thing: Diferencias semánticas

Otra de las cosas que incorporamos es una herramienta de diff, que dados dos ficheros nos permite obtener las diferencias entre ellos.

Cómo se hizo

Aunque la idea ha estado en fase de análisis y diseño varios años, el desarrollo principal del proyecto se ha llevado a cabo en los úitimos 6 meses, en el que una buena parte del equipo de Códice ha estado implicada. Hemos estado divididos en dos grupos, uno encargado de las operaciones de merge y del backend de la herramienta, y otro grupo, que hemos estado cubriendo el diseño y la usabilidad de la herramienta.

Además, llevamos varias semanas usando la herramienta como herramienta de merge por defecto de manera interna, y las primeras betas privadas que distribuimos han tenido una acogida muy buena por parte de los voluntarios.

Bajo el capó

El lenguaje usado para todo el desarrollo de la app es C#, de ahí nuestro interés con que sea el primer lenguaje de programación soportado (llevamos semanas probando la herramienta a nivel interno).

La interfaz está desarrollada en WPF con algunos toques de Windows Forms, y para la ventana sin marco usamos la integración con Windows a través de Windows.Shell.

Las herramientas utilizadas han sido PlasticSCM como control de versiones, Visual Studio 2010 – 2012 como entorno de desarrollo y Blend 4 como herramienta de diseño de interfaces,

Pasos adicionales

Estamos en fase beta, con lo cual hay muchas cosas que pulir, además seguimos trabajando en mejorar la herramienta, la usabilidad, el diseño, la velocidad, así como el soporte para lenguajes adicionales y escenarios más complejos. Para ello hemos habilitado un portal en uservoice para recibir feedback de nuestros usuarios.

• SemanticMerge.com
• SemanticMerge en UserVoice
• PlasticSCM.com

See this post in english here

El pasado 20 de marzo tuve la oportunidad de asistir a los Firefox OS App Days de Valladolid, donde, tras unas cuantas sesiones de introducción, tuvimos un hackatón donde pudimos tener un primer contacto con la plataforma.

La plataforma

Firefox OS es, dicho de una manera sencilla, un núcleo de Android y un navegador, con lo cual todo el sistema, incluida la pantalla de inicio, están hechos en HTML5, CSS y Javascript. La diferencia fundamental con un navegador que se ejecute en Android o iOS, es que tenemos acceso mediante las API de Firefox OS a todas las funciones del teléfono, contactos, calendario, etc.

Desarrollo: Lenguajes, herramientas y simulador

El desarrollo es como el de cualquier aplicación web, es decir, HTML + CSS + Javascript, de manera que podemos extenderlo usando LESS, SASS, jQuery, Sencha… Para empezar no necesitamos más que un editor de texto y Firefox para depurar, ya que el motor de renderizado del teléfono es exactamente igual que el de la versión para escritorio.

Sin embargo, hay cosas que no se puedan probar en un navegador convencional, y para ello contamos con un simulador, que se instala como un complemento de Firefox y nos permite probar nuestras aplicaciones.

Building Blocks

Mozilla ha preparado, de manera adicional, algunas plantillas CSS para los elementos comunes (listas, botones, cabeceras, mensajes de diálogo) de manera que nuestra aplicación tenga un aspecto nativo y se integre con el estilo del sistema. Es importante destacar que tendremos que copiar manualmente los ficheros CSS, ya que de momento no contamos con ninguna plantilla vacía. 

Mi primer proyecto

Tras la sesión de introducción pasamos al hackathon, poco menos de dos horas para desarrollar una pequeña aplicación y empezar a trabajar. Mi primer proyecto consiste en una pequeña lista de tareas:

• Los estilos están tomados del repositorio de Github de Gaia, que es como se llama la Interfaz de Usuario de Firefox OS.
• Las animaciones y el cambio de página se hacen con una combinación de transformaciones CSS y Javascript, ayuda de los chicos de Mozilla y Telefónica I+D que estaban en el evento.
• Para gestión de la lista he empleado knockout.js para gestionar la lista de tareas y el proceso de agregar una nueva.

El resultado es lo que se aprecia en las capturas de pantalla:

Siguientes pasos

Esto es poco más que un hola mundo, para que la aplicación fuese funcional necesitaría guardar los datos, y se podría extender enlazando las tareas con acciones del calendario. Hay muchas cosas que se pueden hacer, y parece una plataforma interesante.

Enlaces

• Simulador de Firefox OS
• Building blocks
• Repositorio de Gaia en Github (UI de Firefox)
• Knockout.js
• Código de ejemplo en Github

Error 1: No definir correctamente el modelo de datos

Empecé con una lista, luego una segunda lista, luego una tercera, así tenía listas de listas de elementos que heredaban de otros… y cuando llevaba bastantes horas de desarrollo me di cuenta que esto no funcionaba, así que me tocó rehacer una buena parte, perdiendo unas horas muy, muy valiosas.

Cuando estemos desarrollando la aplicación, es importante sentarnos a pensar cómo van a estar organizados los datos, ya que luego nos será mucho más simple (o al menos, menos doloroso).

Error 2: No tener claras las prioridades

Cuando estás en modo hackathon lo único que que quieres es implementar la mayor cantidad de características en el menor tiempo, y no puedes empezar a pensar en la financiación, la publicidad o las compras in-app cuando no tienes definida ninguna manera de guardar información o acceder a ella una vez se cierre la app.

Error 3: No tener claro el modelo de financiación

Gratis, publicidad, compras in-app, trial? Pasé por todos los modelos hasta que encontré alguno que me gustara. Aprendí muchas características, pero eso, una vez más, me retrasó bastante. Hay cosas que no puedes probar (como las compras in-app) con seguridad hasta que la app no está subida, así que callejón sin salida.

Error 4: Demasiadas características para la primera versión.

Había cosas en el backlog como localización, Azure Web Sites, live tiles, las tareas de windows phone, envío de e-mail, localización, Skydrive… El mayor fallo estuvo en no priorizar qué características deberían salir para la primera versión, y saber cuales se quedarían para las siguientes. (Espero que haya siguientes :))

Error 5: Copy paste development

El peor error de todos, que me costó varias horas de desarrollo, copiar y pegar una función “casi” igual. Ese matiz de “casi” es lo que separa el PropertyChangingEventArgs de PropertyChangedEventArgs.

Es una diferencia que no genera errores de compilación, ni errores de ejecución, ni excepciones, ni trazas, nada. Solamente la aplicación no guarda los cambios en la base de datos, algo que es bastante crítico para un gestor de tareas. Este es un error de principiante que nos puede pasar a todos.

Pero no todo han sido errores, y creo que para esta versión he tenido un par de aciertos:

Acierto 1: Modelo en papel

Esto ha sido importante para evitar perderme en el desarrollo, una navegación clara y en papel, tener claro lo que quería que pasara en cada momento, así cuando tenía que enfrentarme a los problemas de la plataforma, no tenía que pensar qué tenía que hacer la app, porque ya estaba por escrito.

Acierto 2: Backlog de características

Otro acierto interesante, que habría sido mejor sin el fallo #4, pero la idea no era mala. Antes de empezar el desarrollo, hacer una lista de las features que querría ver en la app e intentar ajustarme al plan, agregando las cosas que se me ocurran a una lista (backlog).

Acierto 3: No comenzar a escribir código desde el minuto 0

Esto siempre se nos dice, que pensemos con el ordenador apagado, pero todos siempre empezamos por File > New Project. Es normal cuando estamos empezando una tecnología nueva, pero cuando es nuestra tercera/cuarta app el factor novedad ya ha pasado, y nos puede compensar pararnos a pensar.

Y tú, qué errores has cometido desarrollando apps?

En Códice Software desarrollamos Plastic SCM, un sistema de control de versiones enfocado a un entorno corporativo, que comparte filosofía con sistemas como Git o Mercurial, al ser un sistema pensado para su uso de manera distribuida.

A diferencia de estos, contamos con una serie de características dirigidas a entornos corporativos, por ello, nos adaptamos a sus infraestructuras integrándonos con mecanismos de autenticación existentes como LDAP o Active Directory, así como los diferentes sistemas de bases de datos disponibles, desde soluciones embebidas como Firebird o SQL CE, hasta soluciones basadas en Oracle. Además tenemos nuestra propia capa de seguridad a nivel de repositorio, rama o servidor, de tal manera que se pueden aplicar permisos específicos a diferentes roles de usuarios (por ejemplo, la rama de integración solamente la pueden tocar los chicos de Dev-Ops).

Además contamos con una interfaz muy limpia, elegante y completa, así como integración con entornos como Visual Studio, Eclipse o InteliJ IDEA.

Siempre intentamos ir un paso más allá, y es por eso que presentamos GitSync, un sistema por el cual se puede sincronizar un servidor de Plastic SCM con un servidor remoto de git. Esto nos permite compartir con otros desarrolladores que usen git para trabajar, subir nuestro código a sistemas como Github o Bitbucket, y aprovechar servicios que son compatibles con Git, como es el caso de Heroku, AppHarbor o, recientemente, Windows Azure.

Esta sincronización es bidireccional, y continua, no se trata de un importador/exportador (aunque eso, también lo hacemos). Sincronizamos todo el repositorio: ramas, changesets y etiquetas

En estos momentos estamos en fase de beta privada, a la que se puede acceder en este enlace. Valoramos mucho el feedback de nuestros usuarios, y por ello regalamos un iPhone 5 a aquellos que nos ayuden a mejorar nuestra herramienta. Quieres el tuyo?

Veremos temas como:

• Herramientas disponibles
• Plantillas por defecto.
• Integración con el teléfono.
• Representación de datos.
• Navegación entre páginas.

Todo esto mientras desarrollamos la que posiblemente sea la app más útil para Windows Phone, un gestor de tareas!

El código fuente y las slides estarán disponibles más tarde en este mismo artículo.

El VallaHackatón está organizado por los alumnos del Ciclo Formativo de Guía, Información y Asistencia Turística en colaboración con los alumnos de Desarrollo de Aplicaciones Multiplataforma, y junto a instituciones como la Junta de Castilla y León a través del programa de Datos Abiertos, la escuela universitaria de informática de Valladolid, el Centro de Innovación en Movilidad, empresas como Servilia o Códice Software, y grupos de trabajo como Urbapps.

Más información en: http://vallahackathon.es/

Este año tengo la suerte de formar parte de los galardonados (y a las pruebas me remito):

Diploma MAP 2013

En el ejercicio del pasado mes, descubrí que nunca había probado un método que devolviera una excepción, así que recurrí a lo primero que sabía, un bloque try catch, aunque el resultado deja bastante que desear:

[TestMethod]
public void TestMethodThatShouldReturnAnException()
{
  try
  {
    CodeMachine machine = CodeMachineBuilder.Generate("KKKKK");
    Assert.Fail();
  }
  catch (IncorrectCharactersException){}
}

Un bloque catch vacío es una de las cosas menos recomendadas desarrollando software, ya que se pueden capturar excepciones que no deseamos. Por suerte, Microsoft ha puesto a nuestra disposición el siguiente artículo: A Unit Testing Walkthrough with Visual Studio Team Test, que, aunque algo antiguo, nos propone otra manera de controlar las excepciones en un test unitario:

[TestMethod]
[ExpectedException(typeof(IncorrectCharactersException))]
public void
TestMethodThatShouldReturnAnException
()
{
 CodeMachine machine = CodeMachineBuilder.Generate("KKKK");
}

Con un atributo llamado ExpectedException y el tipo de excepción que esperamos, podemos mantener el código limpio y elegante, así, podemos seguir con nuestras pruebas.