Estimados lectores:

Antes que nada espero que la navidad y el fin de año hayan sido un periodo de descanso y celebración en familia, que sus metas del 2009 se hayan cumplido, pero sobre todo espero que este nuevo año 2010 que representa el inicio de un ciclo mucho mas importante, este lleno de salud, trabajo, logros y mucho éxito en sus vidas.

Este es nuestro primer post del año y me gustaria comenzar con el primero de una serie de posts dedicados a Visual Studio Team System 2010, aunque ya hemos hablado acerca de las nuevas capacidades de esta versión con anterioridad en algunos webcasts para MSDN Latam, este año tendremos mucha información relacionada con los eventos de lanzamiento y algunas otras sorpresas como la que les traigo el dia de hoy.

Para todos aquellos que no han tenido la oportunidad de probar y/o trabajar con la version 2008 de Visual Studio Team Suite (antes de conocer lo que depara la version 2010) aun pueden acceder a las imagenes de las maquinas virtuales cuyas fechas de expiración han sido extendidas por Brian Randell para que aun puedan instalarlas y experimentar con ellas, la nueva fecha de expiracion es el 31 de Enero del 2011 por lo que no tienen pretexto para no usarlas :) cuentan con los ultimos updates para que no tengan que actualizarlas y el deploy sea mucho mas comodo, ademas de que se proporcionan las imagenes con compatibilidad para Hyper-V  y Virtual PC 2007.

Y por ultimo para todos aquellos que esten ansiosos en probar VSTS 2010, ya pueden descargar las VMs (tambien para Hyper-V y Virtual PC) ademas de algunos laboratorios muy interesantes que les ayudarán a probar las capacidades mas importantes de esta herramienta para el desarrollo colaborativo que guarda muchas sorpresas, lo que si es una lastima es que aun no existan VMs y Labs para probar el Lab Management integrado, sin embargo el equipo de VSTS esta trabajando arduamente para incluirlas en un futuro, asi que a divertirse con VSTS,  bienvenido el 2010 !

VSTS 2008

Visual Studio Team Suite 2008 + Team Foundation Server 2008 (Hyper-V)

Visual Studio Team Suite 2008 + Team Foundation Server 2008 (VPC 2007 SP1)

Team Foundation Server 2008 ONLY (Hyper-V)

Team Foundation Server 2008 ONLY (VPC 2007 SP1)

VSTS 2010

Visual Studio 2010 Beta 2 (Hyper-V)

Visual Studio 2010 Beta 2 (Windows [7] Virtual PC)

Visual Studio 2010 Beta 2 (Virtual PC 2007 SP1)

Labs http://cid-8c96cc4d0756cacb.skydrive.live.com/browse.aspx/Public/Blog%20Attachments/2010%20Beta%202%20Labs?uc=3

 Descarga en PDF la edicion numero 22 de The Architecture Journal

 AJ22_EN.zip (3.95 mb)

Aqui les dejo algunos recursos mencionados en el webcast que considero importante que tenganm asi como la presentacion del evento para aquellos que esten interesados en tenerla.

Para generar estrategias de control de versiones considerando el 'branching':

Lab_Files_-_Single_Release_Single_Maintenance.zip (6.86 kb)

TFS_Branching_Guide_-_Main_2.0.pdf (869.71 kb)

TFS_Branching_Guide_-_Q&A_2.0.pdf (671.93 kb)

TFS_Branching_Guide_-_Scenarios_2.0.pdf (1.26 mb)

TFS_Branching_Guide_-_Drawings_2.0.zip (9.55 mb)

TFS_Branching_Guide_-_Labs_-__2.0.zip (1.47 mb)

PDF de la presentacion:

Estrategias para la adopcion de VSTS.pdf (1.03 mb)

Hace algunos dias tuve la oportunidad de colaborar nuevamente con el equipo de MSDN Latam con un webcast para la adopcion de VSTS, no habia podido subir la invitacion formal, pero gracias a que el evento fue grabado aqui les comparto la informacion del evento y la liga donde pueden acceder a esta grabacion, saludos.

Descarga en PDF la edicion numero 21 de The Architecture Journal

AJ21_EN.zip (2.53 mb)

Estoy simplemente impresionado por esto ... es un IDE muy parecido a Visual Studio pero para el browser, con la opcion de crear diferentes tipos de soluciones, descargarlas empacadas en un zip, ejecutarlas online y hasta hacer el deploy ... a la nube !!!

increible

http://coderun.com/ide/ 

Definiciones de conversión entre estructuras relacionales y objetos (Object Relational Mappers)

En el capítulo 3 hicimos nuestro primer esfuerzo para unir el mundo de los objetos con los datos mediante la escritura a mano de nuestra propia capa de acceso a datos y su definición de conversión. Este enfoque resultó ser más bien limitado y requirió una cantidad significativa de código repetitivo (aunque  fue útil para demostrar las bases).  Agregar más objetos y funcionalidad sobrecargaría nuestro Capa de Acceso a Datos (DAL) en una enorme violación inmanejable del principio que dicta ‘No te repitas a ti mismo’ (DRY, por sus siglas en inglés). En este capítulo veremos un marco de trabajo real para la definición de conversiones entre Objetos y Entidades Relacionales (O/R Mapping) que haga todo el trabajo pesado por nosotros. Específicamente veremos el popular marco de trabajo de código abierto llamado NHibernate.

La única y más grande barrera que impide a la gente adoptar el diseño guiado por el dominio (DDD por sus siglas en inglés), es el problema de la persistencia. Mi propia adopción de las definiciones de conversión entre estructuras relacionales y los objetos (O/R Mappers) inicio con gran confusión y duda.  Básicamente se te pedirá que cambies tu conocimiento de un método probado  por algo que parece de un poco mágico.  Puede ser requerida algo de fe ciega.

La primer cosa con la que hay que llegar a un acuerdo es con que las definiciones de conversión generan tu SQL por ti, lo sé, suena como que será algo lento, inseguro e inflexible, especialmente debido a que probablemente imaginaste que se tendría que usar SQL en línea. Pero sí puedes quitarte esos miedos de tu mente por un segundo, tienes que admitir que podría ahorrarte mucho tiempo y tener como resultado un número mucho menor de defectos. Recuerda, queremos enfocarnos en construir el comportamiento, no preocuparnos con cuestiones de interconexión (y si te hace sentir mejor, una buena definición de conversiones entre estructuras relacionales y objetos te proveerá formas sencillas de desactivar la generación automatizada de código y ejecutar tu propio SQL o tus procedimientos almacenados).

La incorporación de patrones es muy importante pues en un escenario como el anterior y ayudado de políticas de codificación te puede ayudar a establecer los parámetros mediante los cuales se le permite al equipo trabajar, pero no solo eso, los patrones nos dan una forma de resolver un problema común, retos a los que alguien mas ya se enfrento en su momento y para lo cual genero una solución, algo probado que sabes que funcionará, esto te ahorrará mucho tiempo en la conceptualización y el diseño, los patrones también como base para el establecimiento de mecanismos de generación automática de código por lo menos a nivel de proxys o contratos , es decir … que una vez establecido un patrón para cierto componente o parte de la aplicación puedes generar cuando menos platillas automáticas que te generaran el esqueleto, más aun, la aplicación de los patrones hacen que el costo de mantener,  modificar y extender tus módulos o la aplicación completa, sea infinitamente menor … algo que seguramente apreciarás cuando el cliente te pida cambios o adecuaciones ‘menores’  que sin la incorporación de patrones te tomaría meses … el tiempo invertido en el diseño puede ser el factor clave que te permita hacer esos cambios en solo días … incluso horas o minutos.

Aquí les dejo un reporte generado por Nucleus Reseach dedicado precisamente a analizar las ventajas de incorporar los patrones a sus proyectos de construcción de software.

A lo largo de mis años en la industria del desarrollo de software he tenido la fortuna de vivir en carne propia ambas caras de la moneda en cuanto al uso e implementación de de patrones, desde el desarrollo con un uso nulo de los mismos (en mis primeros años) hasta el uso extensivo y casi religioso de un conjunto bastante extenso. ¿Y porque digo que he tenido la fortuna de vivir ambos?, bien pues básicamente por que el pasar por la experiencia de no usarlos y después dedicar tiempo significativo en su evaluación e incorporación dentro de los proyectos solo me ayudó a entender el por qué son tan importantes, en el aspecto práctico el uso de patrones en el diseño de la arquitectura de software puede marcar la diferencia entre el éxito y el fracaso de un proyecto … crees que exagero ? ok, imagina que debes realizar un producto muy grande en donde por el tamaño necesitas que tu equipo esté formado por varios desarrolladores, cada uno con diferente nivel de experiencia (incluso en el manejo de la tecnología), cada uno con una forma de ver el producto y por supuesto cada uno de ellos con una manera diferente de enfrentar los retos tecnológicos que implica la construcción de la aplicación.