.NET Framework 3.5 en Software Guru 2007

El próximo 29 de Octubre estaré dando una plática de .NET 3.5 en el evento de Software Guru 2007.

Les resumo un poco el evento. Está dividido en cuatro tracks, Herramientas y Tecnologías, Procesos, Ingeniería de Software y Estrategias para Empresarios. Todas tienen platicas muy interesantes intercaladas conferencias magistrales como la de Scott Ambler: Applying Agile Software Development Techniques on Real-World Projects.

Espero y tengan oportunidad de ir.

Visual Studio 2008 Beta 2 Liberado

Primero ve y descargalo y mientras se descarga puedes revisar todo lo que hay nuevo. Hay tantas características en áreas tan distintas que te sugiero imprimir y leer con calma el overview. Ahora sí, revisa el what's new donde encontrarás links para profundizar un poco más respecto a cada tema.

Algo de lo que más promete es la mejora en el IntelliSense para Javascript y ASP.NET Ajax y la vista en Split, al estilo Dreamweaver, para HTML y Diseño (algo tan simple, que no sé como no lo incluyeron antes).

Hablando de Split Views, el Diseñador para WPF funcionará de manera similar y obviamente también tendremos IntelliSense en el XAML.

Otra mejora importante es que podremos aprovechar nuestros nuevos procesadores de doble núcleo para compilar nuestras soluciones.

Existen otros detalles que pudieran parecer mínimos pero los apreciaremos bastante cuando naturalmente terminemos por usarlos como las mejoras al debugger.

Hay otras características que serán importantes para muchos, por lo que las mencionare aunque no me parezcan tan relevantes por el uso de otras herramientas que hacen muy bien su trabajo: LINQ to SQL y el O/R designer.

Hablando concretamente del .NET CF 3.5, otra vez, encontramos algunas ventajas tan simples pero muy apreciadas como el hecho de que al depurar al ocurrir una excepción hará el break en el lugar donde ocurrió y no en el Run Method (como odio esto) o que el StackTrace ahora incluirá la firma de los métodos para distinguir entre las sobrecargas.

Seguramente tener parte de WCF en Mobile genera altas expectativas, sólo espero agreguen soporte para JSON o algún protocolo más ligero que XML ya que transmitir por celular con estos formatos se puede volver prohibitivo y nos hace buscar alternativas menos practicas, pero económicas. El uso de Exchange como protocolo es, aunque una solución bastante sobrada, al menos una forma de resolver el problema de cómo notificar a los dispositivos móviles. Aunque realmente sigo prefiriendo la opción de SMS y requiere definitivamente menos infraestructura es bueno saber que existe la otra opción y definitivamente provee otras ventajas adicionales.

Para proyectos de Mobile encontraremos muchas herramientas como las de pruebas que tuve la oportunidad de usar en el Beta 1 en conjunto con TFS y tengo que decir que es lo mismo que si estuvieras usando Team Edition for Testers, realmente no hay ninguna diferencia, sólo que antes estábamos tan limitados que nos acostumbramos a que esto no funcionara como siempre debería haber sido. Se puede decir que simplemente hace lo que se supone que hace. Ahora a mi me hubiera gusto que tuviera dos modos (tal vez los tiene, pero no los encontré) uno para probar sobre el dispositivo (este si existe) y otro para probar lo mismo pero corriendo en el escritorio (este se tendría que hacer manualmente). Actualmente tenemos que crear dos proyectos, uno de Mobile y otro normal de pruebas donde hagamos referencias a los proyectos de Mobile (con algunos warnings que nos da) el de mobile lo usamos junto con el TestHarness del Mobile Client Software Factory para correr las pruebas dentro del dispositivo y el otro lo usamos para las pruebas dentro del escritorio e integración continua. Aunque tenemos forma de automatizar las pruebas de Mobile para que corran dentro de nuestro build, no tenemos manera de reportar los resultados de regreso a TFS, así que estábamos obligados a tener ciertas pruebas que corrieran en el escritorio, pero obviamente no todo lo podíamos probar en esa plataforma. Aunque ahora en VS 2008 podamos usar las del dispositivo para CI y que este reporte directamente a TFS, tienen la desventaja de ser lentas, por lo que sería necesario tener ambos entornos para ciertas situaciones, como pruebas durante el proceso de programación y una vez que pasen las pruebas en el escritorio correr las pruebas en el dispositivo.

Otra de las herramientas sumamente útiles, que ya tenemos actualmente como Power Toy de Mobile es el Device Security Manager que tal como su nombre lo dice, nos permite cambiar las configuraciones de seguridad, de tal forma que podamos probar nuestra aplicación en diferentes "entornos". Sin embargo, la mejor fuente para herramientas de Mobile es el Windows Mobile 6.0 SDK que merece otro post por sí sólo, el Cellular y GSM Emullator son bastante útiles. Tampoco podría dejar de mencionar los Power Toys que más usamos: ActiveSync Remote Display (para ver en tu escritorio la pantalla de tu dispositivo), CECopy y RAPIStart (para iniciar un proceso remoto).

Volviendo a VS 2008 y siguiente con Mobile, incluye nuevos Code Snippets, que hasta ahorita parecen estar sólo para VB, todos empiezan con sd para distinguirlos de los de escritorio.

En definitiva una de las principales ventajas es aprovechar las mejoras al lenguaje, extensión methods, tipos anónimos, lambda expressions, collection initializers y parte de LINQ que están ya disponibles también para .NET CF 3.5.

Sin lugar a dudas algo de lo más atractivo es el SQL Server Compact 3.5 aunque las ventajas listadas no parecen ser tan prometedoras, salvo SyncServices que no estará disponible para Mobile en el release de este año y es más bien un desarrollo del equipo de ADO.NET y no directamente del SSC3.5. Esta característica sirve para sincronizar con diferentes bases de datos o con SQL Server sin tener que usar Merge Replication o RDA. Lamentablemente para mobile parece que nuevamente nos quedamos un poco cortos, sin embargo, el hecho de que SQL Server Compact Edition lo estén usando para escritorio hará que evolucione a un ritmo distinto y esto se verán como beneficios en un futuro (cercano espero).

Para Datos, tenemos un nuevo designer que nos permite tener como DataSources, ResultSets, DataSets, Objetos y WebServices.

Espero y tengan oportunidad de probarlo.

Simular el HttpContext desde ASP.NET

Les dejo el link de Phil que hizo una librería super sencilla de usar
http://haacked.com/archive/2007/06/19/unit-tests-web-code-without-a-web-server-using-httpsimulator.aspx
Todo lo que haces es iniciar la simulación y listo, todas las llamadas a tu código pueden usar algo como HttpContext.Current.Application como si estuvieras en Web.

Puede hacer más que eso, pero eso lo que he probado.

I Muestra de Software - Todo un éxito

El miercoles pasado se realizo la I Muestra de Software Lagunero, la cual resulto ser todo un éxito cumpliendo su primero objetivo: dar a conocer a las empresas laguneras que en la región existen compañías de desarrollo de software que pueden satisfacer sus necesidades. Adicional a esto algunos desarrolladores comentan que han establecido buenos enlaces que más adelante pudieran convertirse en contratos.

Les muestro una imagen del evento, donde salgo exponiendo del proceso de ventas tipico de una empresa sin el uso una solución como las que ofrecemos usando dispositivos móviles.



Pueden ver un artículo completo en el Siglo de Torreón

Microsoft Expert Zone

Toda la semana del 25 al 29 de Junio de 2007 se llevará a cabo el evento Expert Zone que organiza Microsoft.

El evento incluye conferencias de servidores y de las nuevas herramientas de desarrollo. No tiene ningún costo. También cuenta son sesiones "Pregúntale al Experto" donde gente de Microsoft estará resolviendo dudas técnicas todos los días de diferentes temas desde Sistemas Operativos de Servidores y Administración de Base de Datos hasta Desarrollo de Software en Equipos y Diseño de Interfaces de Usuario.

Google Maps para Pocket PC

Todos conocen Google Earth, ok gran cosa, ya paso de moda. Bueno tal vez este ya también paso de moda, pero para mí fue la novedad este fin de semana. Google Maps, para que les platico, no le haría justicia, puse algunas fotos, pero tampoco muestran lo que realmente es, así que tuve que hacer mi primer screencast.




La oficina de Integradores Tecnológicos encontrada usando GPS y el ITESM CL.

Mientras yo sigo en Torreón mi novia está en Sea World en San Diego viendo las ballenitas así que se me ocurrió buscarlo. Para EU tenemos también la vista de mapa adicional a la imagen satelital.

Y para probar la búsqueda, mis tacos favoritos en San Diego, Guerrero Taco Shop. No es un cadena ni el tipo de local que buscaría anunciarse con Google, pero véanlo ahí. Instrucciones para llegar y la foto satelital con simplemente buscar Guerrero Taco Shop.

Primera Muestra de Software Lagunero

Durante los últimos 2 o 3 meses hemos estado organizando la primera muestra de Software Lagunero y todo está listo para que este miércoles estemos presentando la oferta tecnológica de la región a empresarios de diferentes sectores. En esta muestra se expondrán de productos y servicios como computo móvil y comercio electrónico (nosotros), aplicaciones web, software embebido, paquetes administrativos y soluciones a la medida. Estarán mis colegas de Microsip, Nazca, Programática Creativa, Indap, Sensa, Interfase Technologies, Merkanet y claro nosotros.

Este tipo de eventos son muy importantes, no sólo por las relaciones comerciales que pudieran desprenderse del mismo, sino por el impacto en general que tiene del sector de TI sobre el mercado local y la evolución que esto podría provocar sobre otros sectores. Finalmente el que las empresas tengan, por ejemplo, procesos automatizados les ayuda a ser más eficientes en sus tareas. El hecho de que empresas en la región puedan adoptar nuevas tecnologías es un diferenciador importante sobre su competencia no adopten tecnología los dejaría en una clara desventaja sobre todas las demás que ya lo están haciendo.

Muchas empresas no compran por desconocer los beneficios y que existen proveedores a 15 minutos de sus oficinas, este evento les servirá para conocer qué podemos hacer nosotros y nuestras soluciones hacer por ellos. Hay otras empresas que adquieren software fuera de la región y el establecer relaciones comerciales con proveedores locales les permitirá ahorrar algo de dinero en viáticos y honorarios más altos.

Herramientas para Team Foundation

Team Foundation nos ha ayudado bastante desde el trabajo del día a día hasta el seguimiento de proyectos y definición de procesos, por si sólo Team Foundation es una gran herramienta, pero la hemos ido haciendo aún mejor con ciertos productos de terceros y claro las personalizaciones que le hemos hecho. Aquí presento herramientas de las que usamos o conozco, sin embargo la lista completa esta aquí.

1. Scrum for Team System del mismo Ken Schwaber y Conchango. TFS viene con MSF para CMMI y MSF Agile, sin embargo ninguna nos gusto. En lugar de trabajar desde cero en la definición de un nuevo proceso, tomamos Scrum For Team System que es un template que provee otros tipos de Work Items y flujos de trabajos. Les platico las diferencias más importantes.
   

   Ahora tenemos un Product Backlog donde vamos metiendo todos los requerimientos del cliente. Cada ítem dentro del Product Backlog en algún momento se relacionará con un Sprint, los cuales a diferencia de las iteraciones de MSF tienen una fecha de inicio y fecha de fin. Esos mismos ítems los relacionamos con n ítems más del Sprint Backlog donde tenemos ahora si actividades más técnicas.
   

   Los ítems del product backlog se asignan a un equipo de desarrollo y los Sprint Backlog Items se asignan a una persona. Una de las adaptaciones que hicimos es que estos work ítems puedan asignarse a un par para decir, está tarea la hacen Mike y Tea en lugar de que ambos trabajen en ella y sólo aparezca uno de los dos. Esto aún no tiene ningún efecto en reportes ni nada por el estilo, pero ya sería cuestión de luego usarla como filtro o para agrupaciones, finalmente la información ya se está guardando.
   

   Trae nuevos reportes como Product Burndown y Sprint Burndown que te muestran el progreso y una tendencia del proyecto o iteración actual respectivamente. Aunque muchos reportes se apegan más a nuestra metodología, tengo que decir que extraño algunos de MSF.
   

   Resumiendo Scrum for Team System nos permite ejecutar nuestros proyectos de una forma más natural que MSF.
   

2. Continuos Integration de Vertigo Software y con mejoras de Daniel Cazzulino de Clarious Consulting y miembro del equipo de desarrollo del MCSF es un simple WebService que se suscribe al evento Check-In e inicia el proceso de Build. Requiere un poquito de configuración, pero una vez jalando es una chulada. Lo usamos en todos nuestros proyectos en los que configuramos el build. Ya he puesto otros posts de Integración Continua.
   
3. TeamPlain de Devbiz empresa recién adquirida por Microsoft es un website que se conecta a servers de TFS para poder hacer casi todo lo que haces desde TFS a excepción de checkouts y checkins. No he probado si podemos iniciar un build, sin embargo, para lo que lo usamos es ver WorkItems, reportes, archivos, etc. y para esa función es una excelente herramienta con una interfaz sexy y muy intuitiva. Aún no probamos el 2.0 RC que ahora usa Ajax.
   

   Esta herramienta es gratuita desde que Microsoft adquirió devbiz.
   

4. Team Foundation Power Tools incluye a su vez 4 herramientas.
   
   1. Nuevas políticas para los check-ins. A mí me han resultado muy útiles la que forza los comentarios para el check-in y la de asociar un WI que con los resultados de un Query específico de tal forma se puede forzar a que sólo le den check-in usando WIs dentro del proyecto al que pertenece el código y asignados a ese usuario y así no mezclen por error.
      

      Hay otros tantos como el Forbidden Patterns que te permite decirle que archivos no deben subirse usando RegEx que aún no he tenido oportunidad de conocer.
      

   2. El Test Build Pack nos permite seleccionar todo un dll en lugar de tener que escoger un vsmdi para nuestras pruebas, esto se integra con los Team Builds por lo tanto se puede usar con CI que les mencionaba en el punto 2. Yo no he tenido necesidad de usarlo y me gusta más la opción de especificarle los nodos de las pruebas del vsmdi que quiero utilizar y esto me permite buena flexibilidad para especificar que ciertas pruebas se automatizaran y otras no deben correr en nuestro servidor de Builds.
      
   3. El famoso Process Template Editor de Joel Semeniuk de imaginet se integra ahora con VS para editar las plantilas ahí mismo y usa DSL para definir los flujos que puede tener un WI. Esta herramienta es vital para personalizar Team Foundation, aunque ya al personalizar toda una plantilla realmente terminas metiéndote al XML el PTE te permite perder el miedo inicial a hacer cambios de la manera más sencilla. Esta herramienta por si sola merece un post por separado.
      
   4. Una herramienta de Consola que provee nuevos comandos. A esta no he tenido necesidad de meterme aún, pero cuando trabaje con TF.exe si me di cuenta que está limitada en ciertos aspectos, pero me ayudo mucho en su momento. Ahora tenemos más opciones disponibles como un comando UU (Undo Unchanged) un TreeClean y un TreeDiff que por cierto estas últimas dos ya vienen junto con Orcas.
      

Algunas herramientas que estamos por instalar pero parecen muy interesantes son las siguientes.

1. Light Weight Scrum Process Template es otra plantilla similar a Scrum for Team System, pero supuestamente más light. Algo de lo que presumen mucho es que usan Areas e iteraciones para la definición de sprints y Scrum for Team System lo hacen como un Work Item más, yo la verdad ya me acostumbre a hacerlo de esta forma y tiene la ventaja de que le puedes poner fechas, cosa que las iteraciones de VSTS no incluyen. Habrá que ver como hacen con las fechas. Definitivamente es una plantilla que al menos nosotros que usamos buena parte de las bases de scrum tenemos que probar. Si resulta interesante luego publicare algo.
   
2. Team Build Ticker es un notificador de builds, suena como una herramientas muy útil que te avisa (estilo Messenger creo) el estatus de tu build. Esto nos evita el tener que esperar el e-mail. El link para la descarga al parecer está fallando.
   

Como no he probado estas herramientas no les puedo decir más de lo que he leído, por eso mejor chequen los links que les deje.

Espero y les sean de utilidad a nosotros nos han ayudado bastante. Les dejo una lista completa de herarm

Queda pendiente un post sobre Team Foundation Orcas y el Process Template Editor.

SqlServer Compact Edition en ASP.NET

Este post salvo el día. Para poder usar SqlServerCompactEdition con ASP.NET todo lo que hay que hacer es:
AppDomain.CurrentDomain.SetData("SQLServerCompactEditionUnderWebHosting", true);

Listo, eso es todo.
Antes por cuestiones de licenciamiento (en SqlServer Mobile) no se podía a menos que se tuviera instalado Sql Server al menos Express o herramientas de desarrollo. Con la nueva versión ya no hay problema de licenciamiento sólo hay que usar esa línea de código.

Espero y les pueda servir.

TDD y la matriz de trazabilidad

En MoProSoft y CMMI constantemente nos encontramos con que la matriz de trazabilidad es necesaria para poder medir el impacto que un proyecto tendrá al momento de realizar un cambio. Dicen que es necesario el conocer esto para poder estimar y una vez aprobado el cambio, saber que áreas debes de cambiar.

TDD ofrece un enfoque un tanto distinto. En un principio nos obliga a tener un diseño altamente desacoplado por pensar primero en como usar el código antes de pensar en como hacerlo y principalmente por refactorizar constantemente. Esto nos trae como ventaja que el impacto en distintos componentes de código sea minímo.

Ahora si, partimos de que el impacto es minímo, ¿cual sería la necesidad realmente de tener la trazabilidad si sabemos que pocos componentes se verán afectados?. Por otro lado, gracias a ese diseño desacoplado, ahora sabemos que conocemos los limites y repercusiones del cambio por lo que la estimación es fácil. Hasta aquí cumplimos con el propósito de la matriz de trazabilidad.

La verdad es que ninguno de los dos enfoques es mejor que el otro como para determinar el impacto a los componentes. Algunos dirán que la matriz de trazabilidad da una mejor visibilidad lo cual es cierto, TDD no te la da (no directamente, ya veremos más adelante), pero te da confianza al hacer los cambios. El problema es que tener esa visibilidad viene con un gran costo, el mantener la matriz muy bien actualizada y con alto nivel de detalle, esto sin duda consume mucho tiempo, probablemente más que el necesario para hacer los cambios que pudieran presentarse al proyecto.

Partiendo de que ninguno de los dos enfoques es exacto al preveer el impacto en los componentes afectados, la desventaja de la matriz de trazabilidad es que no es capaz de identificar realmente el impacto que tuvo el cambio una vez realizado y ahí es otra área donde las pruebas que tenemso al usar TDD tienen su alto valor.

Digamos que hacemos un cambio al código y nuestra matriz nos dice que tenemos que cambiar el componente A, C y D, hacemos el cambio en los tres lugares esperados, verificamos que funcionen bien, se integra y antes de liberar aún tenemos que revisar que B no haya sido afectado y probablemente nos daremos cuenta de que B sufrio cambios hasta las pruebas de aceptación y será muy tarde para ver quien introdujo ese error y tratar de corregirlo a tiempo para liberar el producto y volvemos a la fase anterior sin poder liberar.

Viendo el mismo ejemplo en un proyecto que utilizo TDD desde un principio, estamos confiados a que sólo A necesitará un cambio ya que las dependencias entre los otros componentes son muy debiles, realizamos el cambio, damos check in se corre una serie de pruebas automatizadas que nos muestran que B ya no funciona como se esperaba. Ya le habíamos cotizado al cliente sabiendo que sólo tendríamos que cambiar A. En este momento estamos a buen tiempo de para:
a) Corregir el impacto causado en B y volver a dar check in a ver que pasa.
b) Explicarle al cliente que costará más de lo esperado y tomará más tiempo,
c) Que el cliente decida que prefiere si retrasar la entrega del proyecto por su impacto en B o no incluir el cambio propuesto y continuar con la fecha de entrega como se planeo originalmente.

La ventaja de TDD sobre la matriz de trazabilidad es que tiene otras ventajas adicionales a las de poder estimar conociendo el impacto sobre los componentes al hacer un cambio y aunque no nos da visibilidad nos da seguridad que muchas veces es más imporante. Sin embargo, es muy sencillo hacer una pequeña matriz de trazabilidad de Requerimientos-Pruebas-Implementación si se busca cumplir con algún modelo como MoProSoft, CMMI, ISO o simplemente se necesita usar para tener un poco de mejor visibilidad.

¿Cómo hacemos esta matriz usando TDD? Simple, nuestros requerimientos ya los tenemos dados de alta en Team System como Work Items, seguramente como Sprint Backlog Items, Tasks o lo que sea que manejen, un Work Item digamos Requerimiento 1, puede estar relacionado con Tarea 1 y Tarea 2, así que tenemos la trazabilidad directa desde la herramienta de requerimientos a actividades. La actividad usando TDD empezará por realizar una prueba unitaria, por lo que ahora relacionamos Tarea 1 con Tarea1Test y Tarea1FailsTest. Desde las pruebas en código, podemos navegar dando click en "Go to Definition" en el metodo o clase que estamos probando, por lo que tenemos navegación completa de requerimientos hasta implementación. Por otro lado si se tiene una capa de acceso a datos, sabremos claramente que partes de la base de datos se usan y por otro lado esta altamente desacoplado (o debería).

Nos falta otra parte de la navegación, que es desde implementación hacía requerimientos, esta parte es un poco más difícil de seguir, ya que un metodo o clase podría ser usado en diversas áreas, sin embargo dando click en "Find all referencies" llegamos a nuestras pruebas y de las pruebas ya podemos ver que tareas estan relacionadas con esta. Team System no ayuda mucho con la navegación bidireccional entre Work Items pero podrían hacerse algunos queries si fuera realmente necesario.

Resumiendo, con TDD
Tenemos diseños desacoplados que ayudan a minímizar el impacto a los diferentes componentes.
Nos da seguridad y confianza al hacer los cambios sabiendo que tenemos un buen diseño y en caso de errores detectaremos rápidamente si otros componentes se impactaron.
Podemos obtener visibilidad a través de la navegación entre Work Items, Pruebas e Implementación.

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.

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.

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

Batalla en el escritorio

Nunca había visto está página pero encontre lagunabites.com por un CV que me mandaron. Está página promete tener contenido interesante. Les dejo este video y vean otros de sus posts, estan buenos (menos el de Sexo en el Oxxo).

http://lagunabites.com/bites/2007/01/28/batalla-en-el-escritorio/

AttachEnabled, Attach to Process, Mobile Debug

Cada que trabajo con una agenda nueva me pasa lo mismo y nunca recuerdo exactamente como hacerlo, siempre busco en mi blog pensando que alguna vez publique algo, pero oooh decepción.

Así que aquí va. Realmente la info sale de aquí pero resumido es lo siguente:

En Remote Registry Editor (parte de VS) vayan a su dispositivo y agreguen la siguiente llave HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETCompactFramework\Managed Debugger\AttachEnabled=1

Es un Dword. Reinicien su dispositivo y listo Ahora pueden darle en Tools/Options/Attach to Process.

Es más rápido esto que dar F5 desde un principio. Lean las recomendacioes de David Kline

Team System

Wow!!! nuestro Team System está rapidisimo. Despues de formatear todas las máquinas y servers de la office Team System va que vuela.

Ahora el único problema es que mientras hace un get latest ya no alcanzamos a ver que archivos se estan bajando.

No se puede depurar en ASP.NET desde Vista

Recien formateamos las máquinas de la oficina para instalar el nuevo OS de MS, pero oh sorpresa en dos de las máquinas no podían correr ASP.NET.

Todo el truco esta en que VS debe estar corriendo como administrador de la máquina para poder depurar. Al parecer Vista y VS 2005 aún no se llevan bien, pero fuera de eso y otros problemas relacionados con lo mismo de permisos, no hemos batallado y en una de las máquinas hace 4 meses que se trabajaba con VS y Vista.

Otro de los problemas es que no puedes loggearte a Team System si no corres como Administrador VS.

Para como solucionar esto, lo más sencillo sería dar clic derecho y run as admin, para mejorjes soluciones chequen mi otro post.

Integradores Tecnológicos Integrando Continuamente.

Haca ya un buen tiempo publique algo de CI, bueno finalmente lo estamos haciendo.

Que es, simplemente cada que damos un check-in nuestro servidor de build es notificado se jala la última versión desde nuestro servor de versiones, compila, corre code analysis, hace algunas pruebas de performance y otras pruebas automatizadas y finalmente se agregea todo el log a una lista de builds, queda en un dropbox todos los binarios compilados y listo.

Es muy sencillo el concepto, pero muy valiosos, auqnue sólo tenemos 2 días de usarlo, se que nos va a servir.

Toda la magía esta en una aplicación que recibe una notificació de Team Foundation, por cierto, les sugiero tambien copiar el default.aspx de Daniel

Post para matar el tiempo.... Code Analysis

Estoy trabajando en un proyecto que al ratito les platico y está tardando mucho en realizar algunas cosas que luego les comento. Mientras esperaba me desesperaba y me ponía a buscar páginas de internet. Después de agotar los últimos posts de Martin Fowler y revisar el foro de discusión de roller.com.mx termine revisando mi blog. Me di cuenta que agote tenía casi un mes sin postear algo.

Después de un tiempo sin que se me ocurriera nada de que postear, me doy cuenta de que casi todo lo que hago vale la pena por un post, naaaa no es cierto, no soy todavía tan creído, pero si hay muchas cosas que me gustaría poder compartir. Por ejemplo, justo ahora estoy usando Code Analysis en un proyecto, aunque ya había usado FxCop en .NET 1.1 con excelentes resultados y un par de veces había curioseado con Code Analysis en VS 2005, no me había puesto a usarlo desde un principio en un proyecto.

Bueno ahora estoy haciendo un framework como parte de un proyecto de un cliente. Un framework es de esas partes en los proyectos que más debes de cuidar sobre todo porque son componentes que usaran muchos desarrolladores en diferentes proyectos, por lo que las sugerencias de Code Analysis resultan muy útiles aunque muchas muy enfadosas.

Code Analysis ha resultado ser muy lento, al menos como para correrlo cada vez que quiero compilar, pero si es tolerable como para correrlo como parte de mi suite de pruebas. Algún día creo que voy a hacer o a buscar algo que se encargue de en el background mientras yo sigo codificando se ponga a correr mis pruebas y code analysis y se vayan automáticamente corrigiendo los errores que aparecen en VS, pero de mientras, tendre que irlo corriendo manualmente de vez en vez.

Más adelante les platicare más de Code Analysis. Ahora voy a resumir un poco de lo que he hecho en estas tres semanas de ausencia.

Bueno el 3 de Noviembre di un curso en el Tec de Monterrey como parte de la serie de conferencia del MDCD, hable de lo que es el .NET Framework 3.0.

Luego fuí a Cd Victoria en Tamaulipas a una reunión de Clústers. Lo interesante es ver como los demás clusters del país tiene los mismos problemas que encontramos nosotros en Torreón, inclusive los grandes como el caso de Jalisco o TI Baja, aunque tenemos mucho que aprender del camino que ellos han recorrido.

Leí un libreo de XP (Extremme Programming), lo que más me gusto es que no es a las prácticas que se han vuelto buzz words como pair programming o TDD a lo que le dan la importancia si no a los valores y principios que deben de tener las personas, los equipos y la organización en general para que el proceso funcione bien. En general, has aquello que aporte valor al proyecto. XP es otro tema para platicar por si sólo, aunque soy más fan de muchas prácticas de Scrum y EssUP resulta otra metodología ágil interesante, la escencia de XP es algo que toda metodología debería tener: valores y principios pensados por el bien del proyecto.

Ya no avance con el libro de CSLA, pero lo poco que he leído me ha ayudado mucho, no para el propósito de ese framework, sino para la elaboración de otros. Es interesante ver desde adentro como esta armado y porque algo es internal en lugar de public o private por ejemplo.

Recién empiezo un libro de Team System que se ve muy prometedor.

Le ayude a Carina Casco a hacer un concurso nacional de patines (ufff que friega, pero ya salimos).

Terminamos algunos proyectos (entre ellos el primer piloto de MoProSoft) y estamos empezando otros, tal vez es por eso que no he tenido tiempo de postear.

Bueno y que sigue. Jugueteando con .NET el 8 de Diciembre, la idea es que lleven un juguete para poder entrar y estos sean donados, así DotNetLaguna aporte algo a la comunidad lagunera. Voy a estar viajando a Monterrey por motivo de un proyecto así que cada 15 días andare por allá. Seguirle con MoProSoft y la guerra con metodologías ágiles y formales. El fïn de año es de buenas ventas tanto para Integradores como para roller.com.mx así que esperemos que haya mucha chamba.