[Metro] Diseño Metro–Principios y Personalidad

Rebuscando por los muchos e interesantes vídeos que hay en Channel 9 del Build de Septiembre ‘11 encontré éste, en el que se describen los principios sobre los que se fundamenta el estilo de diseño Metro.

En el vídeo se explica que Metro tiene 3 influencias clave:

  • Diseño Moderno (Escuela Bauhaus), que se centra en eliminar todo lo que resulta innecesario en un diseño se centra en la funcionalidad. En su momento esta corriente surgió como reacción ante el sobre-adorno, algo que podría justificarse también hoy en día viendo el nivel de “glossy” de algunas interfaces.
  • Estilo tipográfico internacional (Diseño Suizo): en este aspecto son 4 las razones a destacar.
    • Tipografía clara, limpia, alto contraste, colores planos
    • Simetrías y jerarquías
    • Lenguaje universal
    • Fotografías en lugar de ilustraciones o gráficos, para aportar realidad
  • Diseño en Movimiento (Motion), que permite darle vida al resultado.

Estas 3 influencias clave terminan fundamentando los 5 principios sobre los que se sustentará Metro:

  • Orgullo del trabajo detallista, casi artesanal.
  • Rapidez y fluidez.
  • Auténticamente digital. El mejor ejemplo lo tenemos en los nuevos iconos.
  • Hacer más con menos.
  • Ganar como uno, adaptándose, por ejemplo, a las estructuras que predefine Windows 8. Aporta homogeneidad y coherencia.

En fin, si queréis saber más de cada punto, tendréis que ver el vídeo Smile

8 señas de una Aplicación Metro (I)

Durante el Build Jesen Harris, del equipo de Experiencia de Usuario de Windows, impartió una de las charlas más interesantes. En ella explicó las 8 señas de identidad de una Aplicación Metro.

Estas 8 señas son las siguientes:

  • Diseño con estilo Metro
  • Rapidez y fluidez
  • Partirse y redimensionarse con belleza
  • Utilizar los contratos adecuados
  • Invertir en un gran “Tile”
  • Sentir la aplicación conectada y viva
  • Mover datos a la nube
  • Abrazar los principios de Metro

En este post y sucesivos posts iremos analizando qué significan estos principios y cómo se traducen tanto desde un punto de vista de diseño, como de programación.

Diseño con Estilo Metro (Metro style design)

Las aplicaciones Metro van a tener una “silueta” común, entendida como una serie de principios y guías de estilo que todas deberían respetar para evitar que el usuario sienta incomodidad al pasar de una a otra.

Seguir este estilo resultará sencillo gracias a las plantillas y otros recursos que vamos a tener a nuestra disposición. Bellas tipografías, espacios entre elementos estándar, etc. Todo ello podremos lograrlo con poco esfuerzo. Con estas plantillas tendremos aplicaciones armoniosas con el estilo Metro y entre ellas.

Otro punto importante de las aplicaciones Metro es primar el contenido sobre el “chrome” o marco, entendido como la ventana y toda su decoración y elementos. Este tipo de aplicaciones clásicas de Windows seguirán teniendo su espacio para aplicaciones ricas orientadas a escritorio, teclado y ratón.

Otro punto a considerar son los bordes de la aplicación, que van a coincidir con los bordes de la pantalla puesto que las aplicaciones Metro se ejecutan a pantalla completa por defecto. Los bordes izquierdo y derecho van a ser para el sistema operativo, siendo el izquierdo el encargado de mostrarnos las ventanas ya abiertas y el derecho los “charms” principales.

Sin embargo los bordes superior e inferior son para que la aplicación haga el uso que crea conveniente de ellos. En estos bordes las aplicaciones deben poner la mayoría de sus comandos en barras en estos bordes, barras que aparecerán y desaparecerán dinámicamente y que evitarán estropear el contenido. Por supuesto aquellos comandos que tengan un uso muy habitual deben ir a la ventana principal como siempre.

Otro aspecto a tener en cuenta es que estas aplicaciones van a utilizarse en muchas ocasiones con los dedos a través del interfaz táctil, por lo que es recomendable seguir algunas pautas, como colocar controles en los bordes, que son lugares mucho más accesibles según los estudios de usabilidad realizados por Microsoft.

Otras Entregas

8 señas de una Aplicación Metro II: Rapidez y Fluidez (Fast & Fluid)

Instalar Windows Developer Preview

Ahora que se acerca el lanzamiento de la nueva versión de Windows 8 (sorprendentemente bautizada como Windows Consumer Preview, ¿dónde han quedado las “betas”?) es un buen momento para recapitulizar cómo podemos instalar una de estas versiones de evaluación junto con nuestro Windows 7 de trabajo diario, sin llorar por la pérdida de información.

Distintas opciones

Existen varias opciones para instalar Windows Developer Preview, tal como nos enumera Scott Haselman en este post de su blog. A la sazón serían:

  • Solución de virtualización, como VMWare o Virtual Box.
  • Instalarlo en una máquina en solitario.
  • Quitarle el disco duro a una máquina y meter uno nuevo para instalar en él.
  • Arranque dual.
  • Arrancar con hardware real usando VHD (Virtual Hard Disk).

Coincido con Haselman en que la última es la mejor de todas las opciones, puesto que es la única que nos garantiza un rendimiento muy cercano al de una instalación directa contra el “hierro”, al tiempo que nos ahorra todos los inconvenientes de hacer una instalación 100% real.

Pasos

Veamos qué pasos tenemos que seguir para hacer esta instalación con tecnología VHD

Paso 1 – De ISO a USB

Lo primero será descargarse la ISO y pasarla a formato USB para que podamos pincharla en la máquina antes de empezar su instalación. Microsoft tiene una aplicación para hacer este paso muy sencilla y funcional llamada “Windows 7 USB/DVD download tool”. No os dejéis engañar por su nombre rimbombante, no es más que una aplicación que “descomprime” ISOs en un pinchos USB para poder usarlos en instalaciones de estas características.

Choose Media Type

Paso 2 – Crear el fichero VHD

VHD funciona con ficheros que simulan un disco duro sobre el que se realizar toda la instalación y funcionamiento del sistema operativo. Desde una consola de MS-DOS lanzada con privilegios de Administrador tendríamos que escribir “diskpart” para lanzar la consola de creación de ficheros VHD, que tendrá un aspecto similar al siguiente.

image

Una vez en esta consola estos son los comandos que tenemos que introducir:

// maximum indica la cantidad máxima de GBs del disco

create vdisk file=d:VMsWin8.vhd type=expandable maximum=60000

 

// seleccionamos el nuevo "disco" para trabajar con él

select vdisk file=d:VMsWin8.vhd

 

// nos "atachamos"...

attach vdisk

 

// ... y creamos una partición primaria

create partition primary

 

Con estas pocas líneas ya tendríamos preparado el disco en formato fichero sobre el que vamos a realizar la instalación. Es importante que lo creemos en un disco duro real en el que tengamos espacio suficiente para la máxima expansión que puede alcanzar. De lo contrario tendríamos errores en tiempo de ejecución cuando el VHD intente expandirse en el disco duro real y no exista espacio disponible.

Paso 3 – Instalación

Los siguientes pasos son los habituales: pinchar el USB, seleccionar el arranque desde el pincho en el correspondiente menú que todas las BIOS nos ofrecen y esperar a que Windows termine de cargar los ficheros que necesita para empezar la instalación. Tan pronto lleguemos a la pantalla en que se los da a elegir dónde queremos instalar el sistema operativo, tendremos que pulsar “MAYUSCULAS” seguido de “F10”. Esto hará aparecer una consola en la que podremos seleccionar nuestro fichero VHD creado anteriormente y “cargarlo” para que se convierta en una de las unidades disponibles para la instalación. En las siguientes fotos nos lo enseñaba bien Haselman. Primero, el listado de las unidades disponibles para la instalación antes de cargar el VHD.

foto_instalacion_antes

En la ventana de Consola que se ve en la imagen introduciríamos los siguientes comandos para “cargar” el VHD.

// seleccionamos el disco con la ruta que creamos antes

select vdisk file=d:VMsWin8.vhd

 

// nos "atachamos"

attach vdisk

 

Una vez hayamos hecho esto, volvemos a la ventana de selección de unidad y refrescamos con el botón correspondiente. Y tal como se puede ver en la siguiente imagen, tendremos una nueva unidad disponible para hacer la instalación sobre ella; la unidad representada por el fichero VHD.

foto_instalacion_despues

Seleccionaríamos esta unidad y continuaríamos con el proceso normalmente, incluso aunque recibamos algún aviso sobre la posibilidad de que no se pueda arrancar el sistema desde la unidad seleccionada. No debemos preocuparnos por esto, debemos seguir adelante hasta que se nos solicite reiniciar, momento en el que retiraremos el pincho USB y procederemos.

Paso 4 – Arranque Dual

Windows Developer Preview es lo suficientemente listo para instalarse como gestor de arranque y dejarnos asombrados al comprobar que, por fin, Windows tendrá un sistema de arranque gráfico y vistoso, no basado en consolas de MS-DOS como hasta ahora. En la siguiente imagen puede verse.

booting

Conclusión

La instalación no puede ser más sencilla y es, además, muy rápida, como todo lo que viene con Windows Developer Preview. No esperes más para empezar a “cacharrear” con el sistema operativo más esperado en los últimos años.

Bibliografía

Scott Haselman – Guide to Installing and Booting Windows 8 Developer Preview off a VHD (Virtual Hard Disk)

Cómo suprimir errores en proyectos de DB

Últimamente estoy teniendo que pelearme mucho con proyectos de bases de datos de Visual Studio y no puedo decir que lo esté disfrutando.

Sin embargo he de reconocer que una de las cosas más interesantes que tienen es la posibilidad de compilar y analizar estáticamente el código TSQL de estos proyectos, como si se trata de código C# o VB.NET.

Siendo como es una ventaja para escribir código primero correcto y, posteriormente, más óptimo y, en general, de mejor calidad, en ocasiones cabe la posibilidad de que queramos hacer caso omiso a los warnings y errores que nos lanza.

A diferencia de sus equivalentes en código procedural, con los proyectos de base de datos no tenemos ni directivas pragma ni atributos SuppressMessage que nos permitan ignorar estas advertencias. Sin embargo no estamos perdidos del todo, tenemos dos posibles estrategias a seguir:

Fuerza bruta

Si eres de los que no le importa usar la fuerza bruta para resolver sus problemas lo más rápido posible, ésta es tu opción: simplemente eliminar todos los errores del tipo para todo el proyecto.

En la siguiente imagen se pueden ver las propiedades del proyecto de base de datos, en concreto la pestaña de Build. En ella podemos introducir los números correspondiente a las reglas que queremos ignorar para el proyecto completo.

image

El modo preciso

La desventaja clara de la opción anterior es que perderemos ese tipo de avisos para posteriores errores que pudiéramos introducir en el proyecto. Sería mucho más práctico si pudiéramos reducir el alcance de la supresión a, por ejemplo, un único fichero, sabiendo que en los proyectos de bases de datos cada fichero contiene un único objeto de la base de datos.

Pues bien, por suerte es posible y además es muy sencillo. Basta con pinchar en el fichero deseado y mostrar las propiedades del mismo. Veremos una caja de texto denominada “Suppress Warnings” en la que podremos introducir el código que representa la regla a suprimir. En la siguiente figura se puede ver.

image

Gracias a esta opción podremos seguir recibiendo los avisos de este error en otros ficheros en los que nos equivoquemos.

El Patrón Promise

El patrón Promise es precisamente nuevo, pero está creciendo en popularidad a raíz del gran uso que se hace de él en la API de WinJS, el wrapper JavaScript para hacer a la nueva API WinRT en Windows 8. El objetivo de este patrón es facilitar el modelado de procesos asíncronos, de forma que el código que consuma operaciones que no van a retornar inmediatamente sea lo más legible y fácil de escribir posible.

Escenario actual

La asincronía está de moda. La Nube, aplicaciones “responsivas”, etc. Todo parece empujar a los desarrolladores a hacer un uso cada vez mayor de este tipo de construcciones programáticas. Microsoft ha decidido hacer una apuesta decidida por la asincronía en las aplicaciones Metro con Javascript, por muchas razones.

En primer lugar hay que tomar en consideración también el hecho de que JavaScript sea un lenguaje de ejecución basado en un único hilo, lo que hace que cualquier tarea de larga duración congele la interfaz gráfica, con la consiguiente mala imagen para la aplicación frente al usuario. Además, la visión de Microsoft con respecto a las aplicaciones Metro se basa en fluidez, rapidez de respuesta y sensación de inmediatez, de ahí que la asincronía pase de ser una característica deseada a una obligación absoluta.

Por estas razones Microsoft ha decidido ofrecer versiones asíncronas de la gran mayoría de llamadas al sistema que WinRT pone a disposición de los desarrolladores. Estas llamadas van a implementar, en su gran mayoría, el patrón Promise, para simplificar su uso asíncrono.

Pero, ¿cómo es este patrón? ¿Qué características tiene y cómo podemos usarlo? Veámoslo.

El Patrón

Promises/A es el nombre del estándar detrás de este patrón. En él se propone que los objetos Promise tengan una propiedad then que será una función con tres parámetros:

  • Handler para gestionar el resultado satisfactorio.
  • Handler para gestionar los errores.
  • Handler para gestionar el progreso de la operación.

Al retornar un objeto promise la función estará “prometiendo” retornar un valor en algún punto del futuro próximo.

Esta implementación del estándar es exactamente la misma que ha hecho Microsoft en su librería. En el siguiente fragmento de código

myWebService.get("http://www.javierholguera.com")
    .then(
       function(result) { /* gestionar resultado correcto */},
        function(error) { /* manejar error */},
       function(progress) { /* informar sobre avances */}
     );

Para terminar uno de los principales beneficios del patrón es la facilidad para componer unos promises con otros. Por ejemplo, imaginemos que queremos realizar un proceso asíncrono A y cuando hayamos terminado dicho proceso satisfactoriamente, quedemos ejecutar un segundo proceso asíncrono B. Con el siguiente fragmento de código podemos ver cómo lo haríamos.

procesoA.ejecutar("http://www.javierholguera.com")
    .then(function(result) {
         // gestionamos el resultado de A ejecutando el proceso B
        // esta funcion retorna el promise del proceso B
        return procesoB.ejecutar(result);
    })
    .then(function() {
        // gestion del exito del proceso B
        console.log('B finalizo correctamente');
    }, function(error) {
        // gestion del error del proceso B 
        console.log('B finalizo con errores');
    });

Podemos apreciar en el código como el segundo .then está ejecutándose sobre el resultado retornado por el primer .then, que es en realidad el promise correspondiente al proceso B. En este caso he omitido, por claridad, el handler para el error en el promise del proceso A, pero podría haberse añadido perfectamente justo a continuación del manejador para el resultado exitoso del proceso A.

Conclusión

Promise es un patrón sencillo pero que nos ayuda a gestionar la asincronía de una forma fácil y limpia. Este patrón tiene una larga vida por delante, como parte fundamental de la API de WinJS en Windows 8, por lo que cuanto antes lo dominemos, antes empezaremos a escribir co´digo asíncrono como las aplicaciones Metro nos exigen.

Move y Merge en TFS

El equipo en el que trabajo está mejorando sus políticas de branching e intentando ser más riguroso a la hora de hacer Scrum.

Recientemente nos vimos en una situación que, aunque debería ser marginal, ocurre en todos los sprints (y probablemente en los de todos los equipos, para ser sinceros): un Product Backlog Item no se completó en el sprint.

Nuestra política de ramas es “un branch por característica”, por lo que tenemos tantos branches como PBIs. Además, para ser un poco más organizados, creamos carpetas padre para los PBIs que se hicieron en un sprint. Por eso, si el sprint es “Release 1 – Sprint 2”, tendremos una carpeta R1S2 que contendrá todos los branches correspondientes a los PBIs de ese sprint.

Solución 1: Llevar a Main

No podemos llevar el código inestable que hay en la rama original a Main y de ahí crear una nueva rama, puesto que estaríamos “rompiendo” Main. Además, tampoco tendría mucho sentido esta duplicidad.

Solución 2: Branch de Branch

Otra posible opción sería hacer un branch del branch original, en la nueva carpeta. Por ejemplo, hacer un branch de R1S2PBIXXX a R1S3PBIXXX, donde XXX es el ID del PBI no completado. El problema de esta solución es que, a la hora de llevar los cambios a Main, nos obligaría a ir hacia atrás en el tiempo, de la última rama a la anterior, y de ahí a Main. También nos obligaría a mantener “viva” la rama original, a la espera de recibir los cambios para poder, después, merguearse a Main y “morir”.

Solución 3: Move del Branch

Está creíamos que era la mejor solución: mover la rama de la carpeta original a la nueva. Por ejemplo, de R1S2 a R1S3. De este modo mantendríamos la rama “enganchada” a Main y podemos hacer el branch directamente desde la nueva posición.

Sin embargo, aquí viene TFS con las rebajas: al hacer el merge de vuelta a Main, interpreta TODOS los ficheros como mergeables, por haber sido movidos. Lo peor es que, si confirmamos el checkin, la historia de ese fichero refleja dicha entrada, aun cuando no hay diferencias reales en su contenido.

Parece ser que este comportamiento es premeditado y probablemente existan buenas razones para ello, pero a nosotros nos obliga a prescindir de esta solución, para no convertir el History de los ficheros en un pequeño caos.

Conclusiones

No existe una buena solución, pero tendremos que tirar con la Solución 2 porque es la única viable a día de hoy.

WebBrowser + Mango = IE9

El otro día me llegó al correo una pregunta que, como de costumbre, no supe responder. Me preguntaban si podíamos esperar que WebBrowser utilizara IE9 como navegador en Mango.

Lo primero que me sugería la lógica es que sí. WebBrowser había estado utilizando IE7 hasta ahora y, puesto que Mango trae como una de sus principales novedades IE9 como navegador, lo normal era esperar que fuera así.

Rebuscando por MSDN (ese sitio donde está toda la información pero es casi imposible encontrar nada), encontré un pequeño artículo sobre los cambios e incompatibilidades de Mango en el que, explícitamente, citaban a WebBrowser y decían lo siguiente (traducción de cosecha propia):

El control WebBrowser para Windows Phone se ha actualizado para soportar Internet Explorer 9. Las aplicaciones que usen este control deberían re-testearse para asegurar su compatibilidad con Internet Explorer 9.

Parecía suficiente, pero ya que tengo instalado Mango en el teléfono, decidí probarlo por mí mismo. Creé un proyecto en el que simplemente incrusté un WebBrowser y una caja de texto para meter una dirección. El resultado lo podéis en la siguientes imágenes, primero navegando a http://user-agent-string.info/parse para conseguir información sobre el User Agent String que está enviando el control WebBrowser.

MangoBrowser_7-31-2011_13.10.33.888

Y, en esta otra, navegando al test ACID3, que aunque no valga de mucho por ser muy poco exhaustivo, sí nos sirve para diferenciar entre IE7 e IE9.

MangoBrowser_ACID3_7-31-2011_13.14.50.684

En definitiva, WebBrowser en Mango SÍ funcionará sobre Internet Explorer 9.

Permisos a NetworkService en remoto

Hoy me he encontrado con una situación que, no siendo habitual, tampoco es tan extraña. Tenía una máquina con un servidor de aplicaciones IIS que hospedaba una aplicación web (unos servicios WCF, por concretar). El Application Pool sobre el que corría dicha aplicación web estaba utilizando la cuenta de Network Service de la máquina, y era preciso que accediera a una base de datos en otra máquina.

Parece fácil, ¿no? Pero, ¿cómo darle permisos a una cuenta que no está en nuestra máquina y que tampoco es una cuenta del dominio en el que se encuentran ambas máquinas? La primera pista la podemos encontrar en IIS.NET, en este post (en inglés). En él nos explican, entre otras muchas cosas, que cada cuenta Network Service de una máquina se convierte en una cuenta distinta cuando trata de acceder a recursos en máquinas distintas. Esta cuenta en la que se “transmuta” Network Service cumple el siguiente patrón:

<nombre_de_dominio><nombre_de_maquina>$

Con lo cual, si nuestra máquina XXX se encuentra en el dominio YYY, su cuenta “transmutada” sería: YYYXXX$. Fácil, ¿verdad? Ahora sólo haría falta dar permisos a dicha cuenta utilizando Management Studio, en el servidor de bases de datos al que queremos atacar. Sin embargo, aquí nos encontramos con otro pequeño problema: Management Studio no es capaz de reconocer dicha cuenta.

Por eso, en su lugar, tendremos que tirar de consola (o de una ventana de query del Management Studio) y ejecutar el siguiente procedimiento almacenado:

exec sp_grantlogin 'nombre_de_dominionombre_de_maquina$'

 

Y, ahora sí, refrescando la carpeta de Logins del servidor SQL Server, podremos a este nuevo login y configurarlo para que tenga los permisos necesarios para acceder a la base de datos que toca.

[WCF] Nombres de máquina incorrectos en WSDL

Nos había pasado anteriormente y nos ha vuelto a pasar: WCF nos generaba el documento WSDL con el nombre de la máquina, no con su dominio.

Esto hacía que, por ejemplo, una máquina con nombre XXX en un dominio YYY, aunque su WSDL estuviera accesible en http://XXX/Servicio.svc?wsdl, internamente las rutas del documento WSDL hicieran referencia a http://XXX.YYY/, lo que hacía el WSDL inservible.

Parece ser que, hasta WCF 4.0, la solución no era sencilla: había que parchear este "bug”, “feature” o como queramos llamarlo, tal como se explica en este KB de Microsoft: http://support.microsoft.com/kb/971842/en-us

Sin embargo, a partir de WCF se ha incorporado la corrección y ya podemos tirar directamente de XML y olvidarnos de DLLs. El fragmento sería tan sencillo como éste:

<behaviors>
  <serviceBehaviors>
    <behavior>
      <!-- Necessary to avoid problems with domain/computer names -->
      <useRequestHeadersForMetadataAddress>
        <defaultPorts>
          <add scheme="http" port="80" />
        </defaultPorts>
      </useRequestHeadersForMetadataAddress>
    </behavior>
  </serviceBehaviors>
</behaviors>

Con esto ya tendremos nuestros WSDLs enlazando internamente de forma correcta el resto de elementos de que se compone.

Rulesets y branches

Desde la versión 2010 de Visual Studio podemos configurar rulesets específicos para cada proyecto, que se guardan como ficheros con extensión .ruleset.

Esta nueva forma de gestionarlo es muy flexible y nos permite controlar cómo de estricto es Code Analysis a la hora de realizar el análisis estático de cada uno de los proyectos de nuestra solución.

Por supuesto, si todo el proyecto comparte unas mismas reglas, es perfectamente posible compartir un único fichero (la solución que, en mi caso, adopto el 99% de las ocasiones).

Puesto que los rulesets pueden definirse para cada proyecto, dicha configuración se refleja en el .csproj. de dicho proyecto. La buena noticia es que la ruta es relativa, con lo cual en el momento de crear nuevas ramas, no tendremos ningún problema. La nueva versión del .csproj en la nueva rama hará referencia directamente a la nueva versión del fichero .ruleset que también habremos brancheado (ojo con esto si estamos haciendo branches parciales).

Sin embargo, hay un comportamiento no deseado: cuando se mueve un proyecto, la ruta relativa no se actualiza. Por lo tanto, deja de hacer referencia a nada que exista, al haberse desplazado la posición del fichero .csproj.

En este caso, al compilar en Visual Studio, recibiremos un warning avisando de que, al no haber podido cargar el ruleset para el proyecto, no se ha ejecutado Code Analysis.

La solución es fácil: abrir las propiedades del proyecto y volver a seleccionar el ruleset correspondiente a la rama en la que nos encontramos. Pero ojo al realizar esta operación, puesto que en el combo de seleccionar, por defecto, no vamos a ver ese fichero.

ruleset

En su lugar, sí nos va a aparecer una entrada relativa al fichero original, aquél del que hemos hecho el branch, y es muy sencillo no percatarnos de ellos y elegirlo (puesto que, al ser nuestro branch una copia, tendrá el mismo nombre).

En definitiva, los rulesets y los branches funcionan perfectamente, pero debemos tener cierto cuidado en caso de que movamos alguno de nuestros proyectos. En tal situación, actualizar las propiedades del proyecto con cierto cuidado de no elegir el ruleset equivocado.