martes, marzo 27, 2007

Como ver los mensajes de error en el Compact Framework (CF)

Ok, para ahorrar espacio los desarrolladores del CF pusieron en un dll por separado los mensajes de error (más info). Así que lo que tenemos que hacer para mostrarlos es instalar el CAB correspondiente a su idioma que se encuentra en C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE\Diagnostics. Si hacen el deployment desde VS, el IDE instale este CAB automáticamente, pero si el deployment de la aplicación lo hacen de otra forma, necesitarán instalar este CAB.

domingo, marzo 25, 2007

Visual Studio Plugins

Alguna vez han deseado comparar algún archivo con otro que tienen localmente en su máquina, tal como hacen con los archivos desde source control? Han querido tener una vista de árbol con sus clases de C# tal como con sus archivos de HTML en el document outline? Han pensado alguna vez porque son tan lentas las busquedas en VS, qué porque no esta indexado? Bueno la solución estan en unos pequeños power toys de Microsoft http://www.microsoft.com/downloads/details.aspx?FamilyID=cd7c6e48-e41b-48e3-881e-a0e6e97f9534&DisplayLang=en

Espero y les sirva el links, son bien simples, pero útiles.

Por cierto, hablando de plugins para VS, Resharper de jetbrains agrega funcionalidades muy útiles la más interesante es como detecta errores en el código y algunas opciones para refactorizar, sin embargo si de eso se trata Refactor! deDeveloperExpress hace de una forma gráfica, intuitiva y práctica muchas técnicas de refactorización, sin embargo, un tanto lento. CodeRush también de la misma empresa, se encargará de cambiarle toda la vista a tus clases agregando simbolos y una navegación un tanto útil entre metodos, en lo personal, tanti icono me parecio demasiado aunque al principio es interesante, despues no resuslta tan práctico. No sé si este plugin en partículuar (que fue el último que instale) o si fue el conjunto de todos los que tenía instalados, pero VS 2005 se volvio especialmente lenta al tener CodeRush. SlickEdit es otro producto interesante y tiene una versión gratuita aunque no ofrece nada realmente muy atractivo, a menos que el saber cuantas líneas de código tiene un metodo o proyecto les parezca interesante, tiene otas dos o tres monerias, sin embargo la versión de paga tiene una funcionalidad muy interesante, que por cierto en otros IDEs como Delphi.NET ya viene incluide de fabrica. Cada vez que guardas un archivo crea una copia y va llevando el historial, después te permite hacer un diff, merge y cosas así que haces con herramientas de control de versiones.

Espero y algunas de estas herramientas les sean de utilidad, yo sinceramente despues de formatear mi maquina solo volvi a instalar las de Microsoft ya que de todas las demás no supe cual hizo tan lento mi IDE.
Les sugiero tratar primero con las de SlickEdit, Resharper, Refactor y CodeRush e ir desinstalando la anterior ya que algunas ofrecen funcionalidad tan similar y de una manera transparente que después es difícil distinguir quien es quien te la esta ofreciendo.

sábado, marzo 10, 2007

TFS desde Web

Para acceder a Team System y especialmente al control de versioens desde las oficinas de nuestros clientes, siempre era un rollo, porque, porque teníamos que conectarnos a través de VPN, algunos clientes no permitían este tipo de enlaces por sus proxies y cuando lo podíamos lograr era muy lento.

Finalmente TFS funciona a través de Web Services, así que porque diablos no podíamos consumirlos normalmente, no era todo lo que proponía "Servicios Web XML", un estándar, portable, sin problemas de firewalls y puertos por ser una tecnología propietaria, etc, etc, blablabla.

Bueno el problema no eran el consumir un Servicio Web en sí, si no más bien la forma en que funciona la autentificación. Con el SP1 de TFS esto se arregla, ya que incluye un Filtro ISAPI para el IIS que permite autentificar contra Active Directory (o de la forma en que TFS lo necesite) sin tener que usar en IIS "Autentificación de Windows" y ahora podemos usar Digest y Clear Text, aunque relamente no queremos usar esta ultima sin SSL y Digest tampoco es tan seguro que digamos. Bueno el link que les dejo lleva paso a paso con instalar un SSL y el filtro ISAPI y configurar lo necesario para que puedan acceder a TFS desde Internet.

En resumen los pasos son sencillos (no voy a explicar como configurar un SSL aquí).
Simplemente da de alta el filtro en IIS
Escoge el tipo de autentificación que necesitas
Conectate desde Internet utilizando tu dirección publica.

Algunos problemillas:
TFS corre en el puerto 8080 y algunos cliente nuestros tienen bloqueado ese puerto (mmmm), la solución fue mapear en nuestro firewall que lo que llegue al 80 lo mande al 8080, en el 80 teníamos Sharepoint, pero quien quiere Sharepoint realmente? Bueno si es útil, pero podemos prescindir de el estando fuera de la oficina.

Seguramente quisieras una forma de ver el mismo dominio estando fuera de la oficina como estando dentro, bueno simplemente configuren su DNS para que apunte al TFS estando localmente cuando soliciten algo como midominio.com y obviamente redirijan el tráfico de midominio.com al TFS.... bueno cada empresa lo tendrá distinto.

Si no tienen midominio.com o sudominio.com o IP estática vayan a homedns.org y saquen uno dinámico, con eso puede funcionar bien.

Suerte y espero y les funcione igual de bien que a nosotros.

Como tratar un bug

Todos hemos lidiado con bugs, nuestros o de terceros, en proyectos en desarrollo o en proyectos cerrados, los hemos visto como usuarios de software y tambien como desarrolladores.

Los desarrolladores y los usuarios hemos aprendido que el software no es perfecto, que existen bugs y también service packs. Es cierto que nadie quiere ver esos bugs, pero más importante, nadie los quiere por segunda vez.

Así que aquí estan los 5 puntos de Miguel Madero para lidiarn con bugs (desde el punto de vista de desarrollo).
1. Tener un buen sistema de log.
Lo peor es que el único que puede reproducir el error es el usuario final, pero ¡No sabe como hacerlo!.
2. Revisar frecuentemente ese sistema de log o implementar un sistema de alertas. Los usuarios no van a venir a decirte que errores hay (a menos que sea muy grave) ellos aprenden a vivir con ellos y esperan que algún día se arreglen sólos. Muchas veces ni siquiera estaran concientes de que hay un bug, pero el análizar la información del sistema de log te puede ayudar a corregirlo antes de que se haga costumbre.
3. Habla con tus usuarios.
¿Qué les parece el software? ¿Qué problemas tienen? ¿Qué los hace sufrir cuando usan el software? Estos es muy importante y junto con la informacíón del log puedes encontrar el problema y su causa. Tambien te darás cuenta que muchas cosas que ellos piensan estan mal, simplemente son resultado de una mala capacitación o que no saben como usar cierta funcionalidad. Dependiendo del tipo de sofware se pueden usar tecnicas como reuniones de grupo, foros de discusión, apoyo de usuariso expertos, etc para mitigar esos problemas que por cierto no son el punto de este post.
4. Confirmar que encontramos el bug.
Estan pensando "una vez encontrado, correr a codificar un fix directamente".... NOOOOOOOOOOOOO, no hagan eso (en casos muy sencillos con eso terminaríamos). Hay que estar concientes que hasta este punto sólo hemos encontrado una probable causa y tal vez sólo un posible problema. Lo primero es crear una nueva prueba (vean mi post de TDD) que demuestr el bug. Esta es realmente una de las formas más sencillas de empezar a usar TDD. Para desarrolladores que nunca han usado esta buena práctica, la idea es que antes de codificar creemos una prueba que falle, luego hagamos la prueba pasar, lo cual garantiza que se haya cumplido el requerimiento o parte del requerimiento a probar.
Bueno un bug es finalmente un requerimiento más: "arreglar el problema de....". Así que usamos TDD de la misma forma que con cualquier otro. Aquí es más sencillo porque lo puedes hacer de manera aislada, es decir, no tiene que estar para todo el proyecto, sólo para parte del código, en este caso ya tienes también una idea (gracias al log y la platica con tu usuario) de como hacer una prueba que falle.
Aquí es donde vale la pena algo de código. El bug es el siguiente, el usuario dice que la aplicación esta calculando mal la suma de 2+2. Tu sabes que tienes una clase que hace esa suma, por lo que ese código es el que probaremos.
[TestMethod]
public void TestTwoPlusTwoIsFour()
{
MiClaseSumador sumadora = new MiClaseSumador();
int result = sumadora.Add(2,2);
int expected = 4;
Assert.AreEqual(result,expected);
}

En esta ocasión el log no nos hubiera ayudado mucho. Por otro lado el usar TDD fue muy sencillo en este caso, porque ya existía la clase y metodos a probar. Cuando no se esta acostumbrado a hacer pruebas al estilo TDD lo primero que hechan de menos el intellisense porque cuando escriben algo como "sumadora." el IDE no sabe que metodos hay porque no existen, ni que parametros espera, etc. Bueno cuando estamos corrigiendo un bug nos evitamos este problema haciendo la adopción de la técnica más fácil. Por otro lado, lo que realmente estamos probando antes de codificar no es en sí la clase, sino lo que hace la clase, así que pasamos al punto 5.

5. Corregir el bug identificado.
Una vez que tenemos una prueba que falla, sabemos que ese es el bug y simplemente hay que codificar algo para que pase la prueba. Una vez que la prueba pasa, no sólo estamos seguros de que efectivamente se corrigio el bug, sino más importante aún, de que no aparezca por segunda ocasión (claro hay que volver a correr esta antes de cualquier futuro release del software y mejor aún si se automatiza para que corra con cada checkin o cada noche por lo menos).


Claro que esta es una prueba sencilla, sólo quería ejemplificar. Por otro lado, la mayoría de los bugs podrían requerir de más de una prueba para garantizar que esta corregido, por ejemplo sumar 2,3 o algo distinto.

Otros puntos a notar.
El bug debería quedar documentado, si se usa alguna herramienta como Team Foundation Server el bug deberá relacionarse con las pruebas para que automaticamente nos provea la Trazabilidad que piden MoProSoft o modelos así (que por cierto a veces es útil).
La prueba debe volver a correrse de vez en cuando y mejor aún si es en cada check in.
Es importante el tener una forma rápida de actualizar a los clientes para que este bug quede corregido, si es un website puede ser fácil si es Windows o Mobile algo como Click One o el Updater Agent pueden ayudar.

QUE GANAMOS
Estamos seguros de que lo que correjimos es efectivamente el bug encontrado y no una cosa distinta, la prueba garantiza que realmente podemos reproducirlo.
Estamos seguros de que si se vuelve a presentar, seremos notros los primeros en encontrarlos al correr de nuevo la misma prueba.
Aprendimos TDD
Corregimos el bug.
Trazabilidad del bug a la prueba y a la corrección