Andoni Arroyo

Que te voy a contar que tu no sepas...

July 2009 - Artículos

Hosting gratuito para pruebas con Microsoft Visual Studio 2010 y Web Deployment Tool (MsDeploy)

La gente de Labs de  discountASP.NET ha abierto dos programas gratuitos para beta testers:

Cito:

1. FREE Sandbox Hosting for testing Microsoft Visual Studio 2010, Web Deployment Tool (MsDeploy) with .NET Framework 4 beta 1
Experience Next-Generation Web Application Packaging and Deployment Using Microsoft Visual Studio 2010 beta 1 and Web Deployment Tool RC1 (MsDeploy) and ASP.NET 4 beta 1.

2. FREE Sandbox Hosting for testing Microsoft Visual Studio 2010, Web Deployment Tool (MsDeploy) with .NET 2.0/3.0/3.5 SP1
Experience Next-Generation Web Application Packaging and Deployment Using Microsoft Visual Studio 2010 beta 1 and Web Deployment Tool RC1 (MsDeploy) with .NET 2.0/3.0/3.5 sp1


Si os interesa poder comenzar a hacer pruebas  podeis consultar más información en  http://labs.discountasp.net/ (todavía quedan cuentas!!)

Fundamentos de la I.A. (Inteligencia Artificiosa??)

Las aplicaciones informáticas (eso si, a golpe de cañon!) van madurando. Ya consiguen, en la mayoria de las ocasiones, hacer lo que dicen que hacen  y comienzan a ser realmente útiles y hasta necesarias. Partiendo de esta base, el usuario, como es lógico, desea que la aplicación sea más y más eficiente. Demanda ciertas características asociadas tradicionalmente con lo que denominamos "inteligencia". Que el software no solo responda de manera determinista, sino que sea capaz de ayudarle, de preveer sus necesidades con antelación y responder con reflejos a la realidad del día a día.

De nuevo, la pelota está en nuestro tejado...(la de los desarrolladores de software, no mires hacia arriba!!)

Nuestras aplicaciones, independientemete de la funcionalidad que cubran, deben comenzar a adoptar dichas caracteríaticas puesto que será una cualidad excluyente a plazo medio. Es fácil de decir, pero no tan sencillo de transformar en instrucciones que admita un compilador... Por ello vamos a analizar algunas de las características que debe cumplir un software para poder decir que es "inteligente" y a que problemas comunes se deben enfrentar independientemente del campo en el que se apliquen.

Haciendo un poco de historia, hacia 1950 parecía que la mecanización de la inteligencia estaba a tiro de piedra pero todavía más de 50 años después no hemos conseguido interiorizarla a nivel general. ¿Existirá alguna razón oscura para no poder lograr alcanzar esa misteriosa meta? Realmente no hay quien sepa donde está la raya divisoria entre la conducta inteligente y la no-inteligente (pensar que exista una raya puede ser una error en si mismo) Lo que si sabemos es que existen algunas características que denotan inteligencia:

  • Responder con mucha flexibilidad a las situaciones.
  • Sacar provecho de circunstancias fortuitas.
  • Hallar sentido en mensajes ambiguos o contradictorios.
  • Reconocer la importancia relativa de los diferentes elementos de una situación.
  • Encontrar semejanzas entre varias situaciones, pese a las diferencias que puedan separarlas.
  • Encontrar diferencias entre varias situaciones, pese a las semejanzas que puedan vincularlas.
  • Sintetizar nuevos conceptos sobre la base de conceptos viejos que se toman y reacomodan de nuevas maneras.
  • Tener ideas novedosas.
  • (Ahí queda eso...)

Existe aquí una paradoja, puesto que los ordenadores son por naturaleza máquinas inflexibles y recae sobre el software simular estas características. Los expertos en I.A. crean gran cantidad de reglas inflexibles para conseguir que las máquinas sean flexibles. Dichas reglas deben estar organizadas en diferentes niveles, Tiene que haber reglas "llanas"," metareglas" con las que modificar las reglas "llanas" y probablemente "meta-metareglas" con las que modificar las "metareglas"...(¿Hasta donde?)

La razón de tantas reglas que operan a tantos niveles distintos es que el ser humano (que asumimos posee inteligencia) se enfrenta cada día a millones de situaciones distintas, de diferentes tipos. En ciertas ocasiones nos servirán las reglas "llanas", en otras ocasiones deberemos aplicar un conjunto de reglas "llanas" modificadas o ajustadas por ciertas "metareglas". En otras ocasiones, sin embargo, deberemos crear nuevas reglas a partir de las existentes enriqueciendo así el conjunto disponible. En el meollo de la inteligencia hay, sin duda, extraños bucles fundados en reglas que directa o indirectamente se modifican a si mismas.

Aunque la complejidad de nuestro entendimiento parece a veces tan abrumadora que el problema de entender nuestro inteligencia parezca no tener solución. Pero tengamos fé. Se han dado pasos hacia su resolución y sin duda se darán más, es cuestión de trabajo y tiempo!!

8 maneras de cargarte la metodología de un plumazo!!

No es fácil implantar una manera común de desarrollar proyectos de Software. Cada maestrillo tiene su librillo y no siempre nos es fácil adaptarnos al mínimo común necesario para trabajar en equipo de manera orquestada.

Por contra, lo que sí que es realmente fácil , es dinamitar el camino andado. Hace falta muy poco para saltarse alguna que otra regla y echar abajo lo ganado con tanto esfuerzo. Existen algunos puntos claves en los que los equipos somos especialmente propensos a ceder, veamos algunos…

(*Hablando en SCRUM)

  1. No preparar suficiente Product Backlog para que el equipo adquiera prespectiva del proyecto.
    Aunque parezca mentira a los desarrolladores nos gusta saber qué leches estamos programando. De hecho las mejores propuestas de mejora de las aplicaciones surgen, al menos en las primeras fases del proyecto, del propio equipo de desarrollo. Para poder aprovechar toda esa energía/sinergia los desarrolladores deben poder hacerse una idea global del proyecto.
  2. No profundizar lo suficiente el el Sprint Planning Meeting por cansancio o falta de concrección en la exposición del Product Owner.
    La reunión previa en cada sprint permite al equipo hacerse una idea lo más concreta posible de las funcionalidades que más valor aportan al proyecto. Nos permite alinearnos con las necesidades del cliente de tal forma que todos aunemos esfuerzos en la misma dirección. También permite mitigar los riesgos e identificar sorpresar antes de asumir un compromiso. Un buen hábito que no siempre se realiza es el de poner una meta al sprint ( por ejemplo “Disponer del sistema de automatización de informes” ) que identifique la situación ideal al final del mismo y ayude al desarrollador a responder preguntas que le “tienten” por el camino. (¿Es esto importante para la meta del sprint?)
  3. Falta sistemáticamente al Daily Scrum o no respetar sin aviso las pocas liturgias que especifica SCRUM.
    Una de las características que hace a SCRUM “medio” bala de plata tan demandada por los desarrolladores, es las pocas imposiciones que propone. De éstas, una de las más importantes, es la de realizar una pequeña reunión diaria en al que cada miembro del equipo explica que ha hecho el día anterior, que impedimentos se ha encontrado y que pretende hacer en el mismo día de la reunión. Este Daily Scrum es el que da jabón al equipo y permite que todo el mundo este al día del avance, evitar duplicar batallas…
  4. Estancar conocimiento asumiendo un mismo desarrollador todas las Sprint Backlog Item de un Product Backlog Item.
    Es importante que nadie sea imprescindible. Que todos los miembros del equipo desarrollen tareas de todos los Product Backlog Items permite evitar que se creen “Reinos de Taifas” y estandariza el código. Además los equipos de desarrollo con un poco de verguenza torera se igualan por el mejor, lo que permite que se produzca aprendizaje por el camino, mejorando la calidad final del proyecto.
  5. Inventarse tareas sobre la marcha o modificar las existentes bajo demanda.
    Cuando un equipo de SCRUM asume un compromiso con el cliente a través de un sprint, dicho compromiso es inmutable por ambas partes. Es por esto que los sprints son tan cortos, para permitir reorientar el proyecto entre sprints.
  6. Intentar esconder las desviaciones o sufrir el “sindrome del investigador“.
    Si existen desviaciones, lo mejor es saberlo y ser consciente de las causas que las han provocado. En la mayoría de ocasiones dichas desviaciones se pueden justificar y son el argumento principal para mejorar los procesos del equipo. Otro de los aspectos que debe afrontar cualquier metodología es lograr una adecuada visibilidad. Esta característica es la que debe permitir permite que los StakeHolders conocozcan la situación del proyecto. Adoptar una visibilidad adecuada permite detectar las desviacioes de manera temprana así como planificar las acciones orientadas a corregirlas. Como equipo debemos ser capaces de justificarlas y transmitir los motivos a los StakeHolders adecuados, así como las acciones y planes creados. Suele ser un buen hábito, especificar a nivel de Product Backlog Item las condiciones de aceptación, en las cuales se especifican las poscondicones necesarias para que una historia pueda darse por terminada. Por supuesto, deben cumplirse todas para que se pueda dar por finalizada.
  7. No retroalimentar Sprint Backlog Items después de realizarlos.
    Es verdad que siempre vamos con prisa, que existen muchas tareas y todas las excusas que quieras poner, pero para poder decir “Hecho” (y hecho es hecho!!) cada desarrollador debe actualizar como parte de la tarea el estado de los Sprint Backlog Items asociados. Mantener al día dicha información nos permite, analizar las desviaciones y observar la tendencia del sprint y el producto. Colateralmente nos ayuda a ganar y mantener la visibilidad del proyecto manteniendo a los diferentes StakeHolder lo más al día posible.
  8. Evitar las Sprint Retrospective o demostrar falta de compromiso.
    En SCRUM la unión y el compromiso del equipo es clave puesto que todos los miembre del mismo interactuan ampliamente con los demás. El Sprint Retrosprective es la liturgia clave para recibir feedback del mismo y aumentar la unión y sentimiento de grupo. Estas reuniones pueden mejorar mucho los procesos afinando el día a día del equipo, identificando los posibles cuellos de botella y planificando como evitarlos.
    Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Como siempre, la clave es la constancia, no ceder al desaliento y aplicar las técnicas espartanas de confianza en tus compañeros de equipo. Solo así se puede lograr el “milagro” de echar a andar y mantener una forma de trabajo metodológica.

Como incluir un fichero en el resultado de una prueba unitaria en Visual Studio 2008

Existen ocasiones en las que nos puede interesar que una prueba unitaria incluya un determinado recurso. Esto ocurre cuando el código que deseamos testear cuenta con la existencia , por ejemplo, de un determinado fichero de texto, una hoja de cálculo o una Service-based Database (.mdf)

Como sabeis, el resultado del proceso de test genera una nueva carpeta (TestResults) donde incluye el resultado de cada generación. Si dicho resultado cuenta con una referencia relativa (la mejor manera de hacerlo) hacia un recurso pues ya la tenemos liada...

Pero como siempre (o casi) la solución es más facil de lo que parece. Existe un decorador especialmente creado para esta necesidad. Basta con colocar sobre el método que deseamos incluya el recurso el item de despliegue de la siguiente manera:

[TestMethod()]
[DeploymentItem(@".\fichero.xls")]

public int EjemploTest()
{

...

(.\ si está en la raiz claro...)

Por supuesto los más inquietos ya se estan preguntando como evitar tener que incluir este decorador en todos los métodos (especialmente interesante si se trata de una Service-based Database (mdf)).

Pues para esto también existe una facil solución. Basta con incluir el recurso en el ficheroLocalTestRun.testrunconfig dentro del elemento Deployment con la siguiente sintaxis:


\[Nombre del proyecto]\[Nombre del recurso]

y ya podemos quitar el decorador.

Por cierto, si deseais incluir un fichero Service-based Database (mdf) en una prueba unitaria y referenciarlo con una cadena de conexión del estilo: "..AttachDbFilename=|DataDirectory|.." necesitais tenerinstalado el SP1 de VisualStudio 2008. Sin este, la referencia se realiza directamente contra en .Net Framewok y no encontrará el recurso.