Mes: enero 2009

Continuando con los posts sobre el testing del Service Pack 2 de Windows Vista y Windows Server 2008, ahora voy a hablar un poco sobre cómo Microsoft administra una característica o feature que agrega a sus sistemas operativos. La calidad es el objetivo primario cuando se agrega una nueva característica en Windows. Una cosa es  tener muchos e interesantes escenarios por soportar al momento de agregar una característica, pero es peor si se agrega algo que no trabaja bien a que no se agregue. Por eso siempre menos es más, porque si se proporciona una nueva característica o tecnología y no funciona total o parcialmente, el usuario se alejará con la impresión de que no funcionó. En cambio si la característica funciona aunque no cumpla con todas las expectativas esperadas, el usuario va a quedarse con la impresión de que sabe que funciona pero le gustaría que además pudiera hacer X, pero X tal vez venga en el próximo release del sistema. Por eso es importante concentrarse en esto al momento de testear Networking y las tecnologías de transición de IPv4 a IPv6.

Como Windows es una plataforma realmente amplia y hay tanta gente que desarrolla, lo extiende y lo usa de infinidad de maneras diferentes lo que hace imposible para Microsoft conocer cada situación y ser capaz de testear de la manera que trabaja cada uno. Precisamente es aquí donde todos entramos en juego para ayudar y validar que lo que hace Microsoft funciona en todos los escenarios y en la infinidad de maneras en que Windows puede ser utilizado. Es importante siempre reportar qué parte de la experiencia no funcionó o qué se esperaba versus qué es lo que se obtuvo. Para reportar bugs en Networking lo primero que se necesita es el Mapa de Red, al cual se llega haciengo click en el «Network and Sharing Center» en el Panel de control.

 Luego clickear en el link que dice «View Full Map».

 

Este mapa es una representación de la red a la que pertenecemos, el cual es nuevo en Windows Vista. Así que utilizar el Mapa de Red para describir nuestro esquema de red incluyendo el tipo de conexión. En algunos escenarios, es posible que el mapa de red no muestre toda la información relevante sobre nuestra red, de ser así por favor hacer saber sobre las computadoras o dispositivos faltantes siguiendo las instrucciones detalladas que aparecen al clickear en el área resaltada en la siguiente figura:

Un verdadero reporte de bug de Networking necesita contener toda información relevante incluyendo fabricante de hardware y versión del driver como así también la versión del firmware para cualquier hardware de red como placas de red, access points y routers. Para ello necesitamos la información provista por ipconfig, Desde la consola y con privilegios administrativos ejecutamos «ipconfig /all»:

Información como direcciones IP, direcciones MAC, fabricantes de NIC y mucho más aparecerán en la consola. Toda esta información es necesaria incluirla en el reporte de bugs de Microsoft Connect como un archivo adjunto junto con cualquier screenshot. Esta información es necesaria para cualquier tipo de conexión incluyendo pero no limitado a conexiones wired, wireless, VPN y dial-up.

En Windows Vista se ha agregado soporte para la próxima generación de protocolos de Internet, conocidos como IPv6. Esta información se incluye como parte del reporte de «ipconfig /all» si IPv6 está habilitado en nuestra red. Cabe destacar que en Windows Vista IPv6 está hablitado por defecto, sin embargo no todo el hardware de red soporta IPv6 todavía. Durante 1970, IPv4 fue inventado pero pasó mucho tiempo antes que la red Internet que conocemos actualmente fuera concebida y creada. Si bien IPv4 ha sobrevivido todo este tiempo hay ciertas cuestiones  que necesitan ser corregidas. Entre ellas la escasez de direcciones IP, esto es particularmente muy visible en Asia y Europa, que entraron tarde al juego de Internet y como resultado no recibieron la asignación de direcciones IP que USA obtuvo. Actualmente USA tiene el 8% de la población mundial mientras que posee el 75% de las direcciones IPv4.

Por lo tanto, esencialmente, IPv6 apunta a la visión de que todos los dispositivos que se conecten(inalámbricamente o no), ya sean celulares, cámaras, etc. permitirles participar en Internet como ciudadanos de primera clase. IPv6 apunta a satisfacer esa necesidad y es por eso que en  Windows Vista está habilitado por defecto. Esto significa que los desarrolladores ahora tienen que escribir sus aplicaciones para que sean agnósticas de protocolo de red y las empresas necesitan empezar a crear un plan de cómo van a implementar IPv6 en el tiempo. En Windows Vista hay muchas tecnologías que permiten que esta transición suceda sin tener que actualizar toda la red, entre ellas Toredo, ISATAP, PortProxy para más información les recomiendo leer el excelente paper sobre tecnologías de transición de Networking  en http://technet.microsoft.com/en-us/library/bb726951.aspx. Por eso se recomienda empezar con las aplicaciones y las tecnologías de transición y posteriormente a medida que los patrones de tráfico cambien evaluar como actualizar la red a IPv6.

Para reportar bugs de Networking es necesario lograr reproducir el bug en un contexto de tracing. Esto realmente consiste en 3 pasos básicos:

1. Tener habilitado tracing antes de testear.
2. Ejecutar los pasos necesarios para reproducir el bug.
3. Deshabilitar tracing.

Por ejemplo , para el caso de una conexión cableada en una LAN:

1. Habilito tracing desde la consola en como Administrador: netsh lan set tracing mode=yes
2. Luego voy paso a paso para reproducir el problema. Supongamos que estoy testeando conectividad IPv6 en la LAN.
3. Finalmente, una vez reproducido el bug de forma exitosa deshabilitar tracing con: netsh lan set tracing mode=no

En «C:Windowstracingwired» encontraremos un archivo llamado wired.cab con todo el reporte de tracing. Este archivo habrá que adjuntarlo al reporte de bugs en Microsoft Connect. Los logs generados por tracing son críticos para debugear el bug  por parte del Windows Beta Team, es por ello que siempre que sea posible reproducir un bug de Networking hay que enviar toda la información de contexto de tracing.

Si probamos IPv6 sobre VPN, los logs generados encuentran en «C:Windowstracing», son varios archivos con la extensión .log.  Los comandos para habilitar y deshabilitar tracing son:

• netsh ras set tracing * enabled
• netsh ras set tracing * disabled

Para una conexión  wireless, los logs se almacenan en «C:Windowstracingwireless» y concretamente habrá un archivo wireless.cab que contiene todo el reporte de tracing a adjuntar. Los comandos para habilitar y deshabilitar tracing son:

• netsh wlan set tracing yes
• netsh wlan set tracing no

Finalmente adjuntar todos las trazas sobre cualquier tipo de conexión que reportemos un bug, como cualquier otro bit de información que ayude debugear la conectividad de la red. 

Fernik

Continuando con la serie de posts acerca del testing de Windows Vista Service Pack 2, el cual también se puede extender a Windows 7 Beta 1(que parece que todo el mundo lo tiene instalado). En esta ocasión analizaré algo muy familiar para todos los usuarios: el Shell.

Un Shell, es la porción de software de un sistema operativo que provee una interface al usuario, ya sea un shell de línea de comandos o un shell gráfico. El Windows User Shell se manifiesta en un sistema Windows desde que encendemos el ordenador hasta que nos logeamos e ingresamos al escritorio y vemos el menú inicio, la barra de tareas, Windows explorer, el panel de control, todo eso se considera el Shell. Es un conjunto muy variado de características de Windows. Asegurarse que el Windows Shell esté libre de bugs asegura una experiencia de usuario fluida. No sólo es conveniente reportar bugs sino también sugerir mejoras, ya que por ejempllo una importante mejora desde Windows 3.11 a Windows 95 fue la desactivación de los protectores de pantalla cuando se realizan tareas intensivas de CPU y datos, como es el caso de una defragmentación. Esto evitó agregar la carga de ejecutar el protector de pantalla cuando se realizaban este tipo de tareas. Si bien es una mejora simple, agrega mucho valor a nivel de experiencia de usuario, sobre todo si tenemos que tomar decisiones en base a los datos que se actualizan por pantalla constantemente.

Como regla general, la cual no siempre garantiza encontrar la causa del bug en el Shell o de una aplicación que falla, lo recomendable es ejecutar la aplicación «Feedback Data Collector» para recolectar información del estado del sistema. Al reportar bugs en el windows Shell vamos a reportar problemas o crashes de las aplicaciones, como lo muestra la siguiente imagen: 

La herramienta Feedback Data Collector reunirá información genérica del sistema(principalmente logs) y les informará sobre ello.

Como esta herramienta no es ni tiene que ser lo suficientemente inteligente para determinar qué tipos de archivos o información extra de contexto buscar(sobre todo si durante una sesión de usuario más de una aplicación ha crasheado) es necesario ayududarla usando criterio e inteligencia. Para ello es útil adjuntar los siguientes archivos a través del botón «Add..»:

%WINDIR%LogsCBSCBS.log
%WINDIR%LogsCBSCBS.persist.log
%WINDIR%Panthersetupact.log
%WINDIR%Panthersetuperr.log

Una vez adjuntados los archivos adicionales,  Feedback Data Collector almacenará todos estos archivos en un archivo Reports.cab el cual habrá que adjuntar al reporte de bugs en Microsoft Connect.

Para el caso de reportar un crash, desde el Panel de Control ir al ícono de «Problems Reports and Solutions».

 Luego hacer click en «View Problem history». 

Posteriormente buscar la aplicación que ha crasheado en la lista y clickear en «View problem details».

 En este punto hay que hacer click en «Copy to Clipboard» y pegar el reporte en el area de descripción de nuestro bug en Microsoft Connect.

 

Ahora bien, algunos crashes pueder tener un dump file o volcado de memoria asociado el cual puede ser reconocido por sus extensiones .mdmp o .hdmp. Para encontrarlos hacer click en «View temporary copy of these files». Luego seleccionar estos archivos y copiarlos a una ubicación accesible, como por ejemplo el escritorio. Luego adjuntar estos archivos, el archivo Reports.cab y cualquier otro archivo relevante al reporte de bugs en Microsoft Connect.

No olvidarse de que los screenshots o capturas de pantallas son bienvenidos siempre que ayuden a repoducir el bug.

Para concluir quiero que se comprenda que el comportamiento actual del Shell de Windows el resultado de la interacción de todos los actores de un ecosistema de software, el Shell es una parte importante de la plataforma Windows y es necesario hablar sobre cómo se relaciona con los usuarios, las aplicaciones de legado, las aplicaciones nuevas, etc. Hay ocasiones en que reportar bugs del Shell es algo puramente técnico, pero hay otras ocaciones en que hay que aplicar el sentido común y la heurística para mejorar la interactividad del Shell con los usuarios. En este sentido hay una gran oportunidad para mejoras. Así que aprovechen esta oportunidad para que Microsoft conozca cuales son sus preferencias como «Me gustaría que no se activara… cuando…», «Me molesta que Windows notifique….», «Sería útil parametrizar……», y así sucesivamente. 

Fernik

En estos tiempos de crisis e incertidumbre económica me encuentro con mucha gente, sobre todo estudiantes a punto de recibirse que me comentan que se les dificulta conseguir trabajo ya que no están capacitados y ni siquiera se los considera juniors. Si bien Microsoft Latinoamérica, Microsoft Argentina y el programa S2B proveen de muchos programas académicos y no académicos, personalmente creo que lo mejor es Imagine Cup.

Más allá de ser una competencia en la que tienes que emplear tecnología Microsoft, la cual debes dominarla con cierto grado, genera en sus participantes espíritu emprendedor, responsabilidad profesional para cumplir los milestones requeridos y actitud hacia la industria del software que se nota en futuras entrevistas laborales. Así que si no tienes trabajo, deja la lloradera y ponte en marcha todavía estás a tiempo para participar en ciertas competencias como MashUp, Short Film, Photography, Design. MashUp es relativamente fácil así que es una buena oportunidad para destacarse. Si no se animan con una competencia están los Imagine Cup Awards que consisten en proporcionar soluciones más concretas en los temas de Parallel Computing, Design for Development, MultiPoint Education, Interoperability, realmente son una buena opción con el poco tiempo que quedan para las finales.

Ahora seguro se estarán preguntando, de dónde obtengo el software Microsoft para desarrollar? Pues de Imagine Cup Software Access, ahí se explica cómo obtener el software que necesitan y no son versiones trials así que no abusen y no conviertan este recurso en un puerto pirata.

En fin, la opotunidad está, el software también, falta la actitud y eso depende de cada uno.

Fernik