//BrainBackup

…y si además de ser gratis hace que estés en el candelero, que tengas unos followers extra en twitter, o unos cientos más de visitas en el blog… pues habrá que opinar, ¿no? ¿no es lo que hace todo el mundo? si no lo haces te quedas atrás… no estás en “la ola del software”!!!

Personalmente, hasta hace poco no he tenido tiempo de meterme un poco con todo este tema de HTML5 como para tener una opinión que defender. Hasta ahora había asistido a charlas de diferentes proveedores, había leído algún documento del W3C, he visto algún video, he probado algunas demos… pero no estaba cómodo defendiendo una opinión propia aun. Es sorprendente como tanta gente pasa a tener una opinión del mundillo de HTML5 tan rápidamente, suena a que más de uno está comulgando con opinión prefabricada }=)   vade retro tecnicoless!!

De todos modos, como opinar es gratis y en internet publicamos cualquiera, pues ahí va mi opinión sobre toda esta historia…

En realidad, de qué se habla cuando se habla de HTML 5?

En los foros en los que yo he estado y en los recursos que he consumido, cuando se habla de HTML5, realmente se habla de HTML5 como leguaje de marcas, de CSS3 y de las nuevas APIs que deberían exponer los navegadores. Estos bloques se corresponden cuasi perfectamente con los working groups dentro de HTML 5, que son:

w3c HTML. Lenguaje de marcas

w3c Web Apps. API

w3c CSS. Estilo

w3c SVG. SVG 😉

ecma  ECMAScript. Lenguaje para manipular el DOM

Y estos grupos, aproximadamente trabajan sobre 100 especificaciones diferentes que tienen interdependencias… sencillito ¿no? 🙂

Diferencias de implementaciones de HTML 5 entre navegadores

Resulta muy curioso ver como en las web de demos de HTML 5 de algunos proveedores se pide su navegador para ver la demo… pero si es un estándar… no debería poder verse cualquiera de las demos con cualquiera de los navegadores que dicen que lo soportan??

( por ejemplo…)

Si haces un bypass de la petición e intentas ver la demo en tu navegador, supuestamente  compatible con HTML5 te llevas la sorpresa de que no funciona!! Pero… ¿no funciona porque tu navegador no es compatible? o ¿no funciona porque el sitio web no es HTML5?

Espera…debe ser nuestro navegador… porque en la web que visitamos pone que es HTML5, y porqué no fiarnos, no? <modoPardillo/>

En las sesiones de Google he visto como los websockets son parte del estándar, la geolocalizacion es parte del estándar, los web workers son parte del estándar, los sensores son parte del estándar, la base de datos SQL en cliente es parte del estándar, lo que empieza con –webkit es parte del estándar…  eso si… “use it ar your own risk”   Que yo sepa, los elementos que están 100% seguros en la especificación de HTML 5 del w3c con el canvas, svg, audio, video y algunos elementos de markup (article, section, nav…) y poco más.

Entonces… web workers, sql en cliente, sensores…

Web SQL Database… http://dev.w3.org/html5/webdatabase/ “Beware. This specification is no longer in active mantenance”

Web Workers. No son una especificación w3c, son una especificación de whatwg. Un grupo fundado en el 2004 por Mozilla, Opera y Apple que tiene como objetivo introducir cambios más agresivos en la web. No es una especificación w3c. http://www.whatwg.org/specs/web-workers/current-work/ 

Web Sockets. Especificación draft en Nov 2010. http://dev.w3.org/html5/websockets/ 

Sensores. Que tengamos acceso a través de ECMAScript a información de los sensores/gps… presentes en el dispositivo. Ni siquiera he encontrado el spec. Si alguno lo tenéis os agradecería el enlace, solo he encontrado una discusión en un foro de whatwg.

etcétera… No digo que sean malas ideas, ni mucho menos, pero tenemos que tener en cuenta que NO son parte del estándar w3c, ni tienen porqué estar soportadas en el futuro por todos los navegadores. A todos los efectos sería como hacerte un plugin especifico para tu navegador y esperar que tu web se vea igual en todas partes.

 

y es que….el estándar no esta listo!!!

Obviamente los aprox 100 documentos de los diferentes working groups no están en el mismo estado, algunos están acabados, otros en proceso y otros con mucho trabajo pendiente. El estándar… HTML5 como gran paraguas, no esta acabado, pero ¿hasta qué punto está usable? ¿puedo empezar a trabajar basandome en el? ¿cuánto le importa a un fabricante de navegadores? y ¿ cuánto nos importa como desarrolladores? :) 

Mientras se va cerrando el estándar y los diferentes navegadores compiten para tener una implementación que respete los estándares, pienso que también se hace una carrera paralela por hacerse con el estándar de mercado / estandar de uso. Imaginemos que un navegador YYY implementa alguna funcionalidad de HTML5 sin que esté cerrada, en un momento en el que aún se está discutiendo en el w3c. Imaginemos que a facebook ( como uno de los sitios más importantes) le encanta esa funcionalidad y decide sacarle partido. Aunque no estuviese en el estándar

¿a alguien le cabe la duda de que no lo van a implementar todos los navegadores? No, ¿verdad?

y ¿qué ha pasado entre que el resto de navegadores lo han  implementado?

Que la mayoría de usuarios de facebook han descargado el navegador YYY y lo han colocado en posición dominante respecto a cuota de mercado…. y eso por tirarse a la piscina con el estándar. Premio!!

En este momento casi todos los proveedores están jugando la baza de SU implementación del estándar para que se adopte cuanto antes y el resto vayan detrás. Y digo casi todos porque creo que desde Microsoft estamos siendo bastante estrictos con la implementación (aunque no sé como… acabaremos siendo los malos)… cosa que a estas alturas del negocio, personalmente no sé si es buena idea o es pecar de pescadilla en aguas de tiburones. Remitimos más tests que nadie para asegurarnos que todos implementamos el estándar del mismo modo, estamos en todos los foros donde se están definiendo las especificaciones, intentamos dar transparencia en el proceso de w3c, llevamos la implementación de forma muy cautelosa… a ver cómo acaba 🙂

Me recuerda a la imagen de un duelo… donde los participantes muy respetuosamente cogen el arma y se alejan 10 pasos de espaldas… pero al segundo paso se oye  un ¡bang!

 

Mi recomendación personal e intransferible

Audio, video, canvas, css3, nav y demás… si a día de hoy quiero hacer algo que salga de ahí y que no se pueda hacer con JQuery. Lo hago con Silverlight.

 

Pero entonces… si HTML 5 es TAN, TAN, TAN genial… ¿qué pasa con Silverlight?

esto lo dejamos para otro día… 😉

 

happy hacking!

~ds

 

PD1 –> Estoy algo cansado de oír que HTML 5 es el futuro de la web. Si lo es o no lo es… lo decidirá el tiempo. Hemos oido tantas veces que X o Y es el futuro de la web…

PD2 –> los principales sitios de prueba de HTML5

Microsoft –> http://ie.microsoft.com/testdrive/

Google –> http://www.html5rocks.com/

Apple –> http://www.apple.com/html5/

La semana pasada tuvimos un mini-taller donde había que resolver el problema de los números perfectos con un enfoque TDD.

y por enfoque TDD, acordamos:

loop {

Crear prueba de cómo queremos que el código se comporte

Crear código de infraestructura para que la prueba compile pero falle

Crear código para que la prueba pase

Refactorizar

}

Por si alguien se anima a hacer el ejercicio, éstas son las historias que hubo que ir resolviendo… Vete haciendo una por una, así tendrás que ir refactorizando y el ejercicio será más útil.

h1 – Dado un número, saber si es un número perfecto o no. Es perfecto, si la suma de sus divisores ( excluido el mismo ) es igual a él mismo. Por ejemplo:

6 tiene como divisores: 1 2 3 (y 6). Si los sumamos 1 + 2 + 3 == 6. 6 Es perfecto

h2 – Dada una serie de números, identificar los perfectos { 1, 6, 78, 344 } –> { 6 }

h3 – Dado un número, además de si es perfecto, queremos saber si es abundante ( suma de divisores > num ), deficiente ( suma de divisores < num ) o primo ( divisible entre sí mismo y la unidad )

h4 – Dada una serie de números, identificar los perfectos, abundantes, deficientes y primos.

Podemos enfocar la solución de diferentes formas, agrupar los tests de diferentes maneras, nombrarlos de diferente forma, invocar a uno u otro autor a la hora de refactorizar… pero creo que no hay una verdad única. Yo os planteo una posible solución, sobre todo para que las personas que nunca han hecho nada de TDD, vean la idea.

 

Happy hacking!

~ds

 

PD –> Gracias a Hadi Hariri  ( @hhariri, blog ) por la sugerencia. En principio íbamos a hacer un ejercicio diferente, pero tras su experiencia en la devcon London, me sugirió que este podía ser interesante 🙂

PD2 –> Si bien los métodos en .NET son PascalCase, para los tests pongo guiones bajos porque es más cómodo de leer en la ventana de resultados

PD2 –> :O has usado youtube!!!  si, tb lo subiré a channel9 para que esté accesible desde los dos sitios. Y no.. no me estoy consumiendo entre llamas por haberlo hecho 🙂

Los practicantes de kungfu, y los de cualquier actividad física, tienen que entrenar, tienen que repetir las acciones hasta que les salen naturales, sin pensar.

La repetición es uno de los procesos de aprendizaje reconocidos, en base a repetir cierta actividad, el cerebro pasa a responder a la orden de ejecutar esa actividad desde una zona diferente. Es el momento en el que hemos ‘interiorizado’ la actividad y ya no es necesaria una actuación tan consciente para llevarla a cabo.

Este mecanismo de aprendizaje no es exclusivo de las actividades físicas. ¿cómo nos aprendimos las tablas de multiplicar? ¿los axiomas matemáticos? ¿la tabla periódica? ¿las valencias?…  diciéndolo en voz alta, copiándolo en un papel n-veces… en definitiva, repitiéndolo.

Y qué pasa cuando acabamos de repetirlo… que lo olvidamos. Tardamos más, incluso años, para olvidarlo completamente y que el cerebro sobreescriba esa zona. Durante ese tiempo sin práctica, vamos perdiendo fluidez en la actividad. Frases como “el que tuvo retuvo” “vivir de las rentas”… muestran esa misma idea… hay un camino en el monte, pero poco a poco se va tapando y cuanto más tardemos en volver a pasar…más nos costará la vuelta.

¿Recuerdas cuando aprendiste a programar?

Hacíamos itoa y atoi sin inmutarnos, reordenar arrays, fibonacci, las torres de hanoi, algoritmos de ordenación… ¿y ahora? Ahora nos sonreimos porque no nos acordamos y lo buscamos en internet. Porque “ya no hace falta saberse las cosas de memoria” ¿verdad? ]:)

Pero, a que es satisfactorio cuando haces las cosas a la primera? a que cuándo haces una algoritmo algo complicado de los que antes ‘te salian solos’? sonries…  Y nada que decir de esa persona a la que admiramos en este contexto, le salen las líneas solas, ´fluido y encima le compila a la primera.

Todos estamos de acuerdo en que desarrollar tiene su punto de arte, un espacio de creatividad dentro de la ingeniería.

Además de por trabajo, los pintores pintan por hobby, practican sus trazos. Los deportistas también practican, y los cirujanos, los pilotos,… muchos profesionales practican para su profesion. Bien porque la profesión se presta o bien porque les gusta su trabajo 😉

¿Tu practicas tu código?

No me refiero a formar parte de un proyecto Open Source, eso puede indicar un nivel de compromiso que no estamos dispuestos a asumir. Me refiero a practicar por nuestra cuenta, a hacer un fibonacci de vez en cuando…

La mayoría no lo hacemos.

En las artes marciales, para facilitar el aprendizaje y perfeccionamiento los movimientos se agrupan en secuencias. El practicante, en lugar de hacer movimientos aislados, repite las secuencias. Ésto le ayuda a mantener su nivel, perfeccionar y reforzar las conexiones en el cerebro. Dependiendo del arte marcial, estas secuencias tienen un nombre: Katas (Karate), Pumses(Tae-Kwon-do), formas (Kung-fu), etcétera…

Pues bien, hace años (personalmente lo descubrí hace poco)  se creo la figura de los CodeKatas. Ejercicios de complejidad creciente donde podemos practicar nuestro código.

Original. http://codekata.pragprog.com/   Tiene publicados 21 CodeKatas.

Referencia y enlaces extra. http://en.wikipedia.org/wiki/Code_Kata

Siendo una persona a la que me encantan los típicos puzles para programadores,  os podéis imaginar que me encantó la idea. De vez en cuando me hacía un puzle, algo reactivo, normalmente no lo buscaba, me lo encontraba y lo hacía.

Pero la idea de resolver un problema cada cierto tiempo, de practicarlo… nunca lo había contemplado. De hecho, en algunos CodeKatas el reto está en resolverlos de diferentes formas (por ejemplo… nada de if’s) y así darle otra vuelta a la tuerca.

Los codekatas me parecen una muy buena forma tanto de aprender como de perfeccionar y entretenerse. Desde que lo conocí procuro hacer alguno de vez en cuando.

También descubrí que alrededor de los codeKatas se había creado un ecosistema de entusiastas, y algunas actividades/agrupaciones específicas ( con unos nombres horribles ]:) )

CodingDojos: Los dojos son los lugares de aprendizaje en las artes marciales, de modo que el CodingDojo se convierte en el lugar donde se practica en grupo los codekatas. Llamémoslo grupo de usuarios.

Coderetreats: Eventos  prácticos. Tienen unas reglas determinadas, como trabajar en parejas, 0 slides, una experiencia inmersiva (varias horas).

Seguro que me dejo algún otro…

Llámalo kata, dojo, retreat o como te de la gana, pero las ideas que hay detrás son interesantes. Algunas son nuevas, algunas no, pero todas interesantes 🙂

Empezando a terminar, señalar que la repetición ayuda a aprender/mejorar, pero sobre todo si se acompaña de motivación. La motivación es clave para anclar cuanto antes los movimientos en el cerebro. Pero entiendo que si hacemos un codekata a las tantas al volver de trabajar… será porque estamos motivados, no? porque a nuestra edad …ya es difícil que nos obliguen 🙂

 

happy hacking

 

~ds

 

PD 01–> Los nombres me parecen una aberración porque he practicado artes marciales y deportes de contacto durante más de 20 años… no me gusta que se reutilicen conceptos, para mi es un mundo muy especial. Pero queése le va a hacer.. codekata… pues codekata :_)

PD10-> oxigeno, azufre, selenio, teluro. Fluor cloro bromo yodo

PD11-> 12 * 12 144 13*13 169 14*14 196 …

PD100-> post 2 días seguidos… estoy in flames! ^^

Cuando ejecutamos nuestros desarrollos para ver cómo funcionan, ver si cascan, ver si todo se comporta como se espera, si esa nueva funcionalidad devuelve lo que debe… estamos probando nuestro código.

De hecho solemos ir más alla, porque solemos incluir cierto código de vez en cuando para ver que funciona todo, ¿no?. Podíamos decir que tenemos cierto nivel de automatización.

Por ejemplo, digamos que tengo un método que normaliza un string en base a ciertas reglas a nivel de negocio (referencias, caracteres especiales…) Ya sea en ese proyecto u otro, antes de acabar la aplicación, nos creamos algunas líneas de código para probar el método y ver el resultado en pantalla, así vemos que funciona como debe. En ese momento tenemos una prueba, un elemento que nos puede ayudar a hacer un desarrollo iterativo asegurándonos la consistencia de lo que ya tenemos y avisandonos de si introducimos algún problema… pero LO BORRAMOS!! 

Ahora, si en el futuro incluimos algo de código que rompa esa conversión, tendremos que investigar a ver qué parte se ha roto prácticamente desde cero. Porque con el sistema crecido, puede que no veamos el error de conversión, si no, un fallo en un control de la interfaz, al consumir un servicio web, en un XML… hala… a perder el tiempo :_)

Pruebas de andar por casa, que sirven perfectamente

Imaginad que hubiesemos guardado ese código. Algo simple, olvidad los frameworks de testing y demás vainas. Simplemente añadir un proyecto nuevo a la solución que se llame pruebas. Que tenga una clase con un método que se llame probar y dentro de ese método vamos validando nuestro código…

 

Cada vez que vamos generando nuevo código, borrando o refactorizando, ejecutamos ese proyecto para ver si todo lo que funcionaba SIGUE funcionando.

¿No crees que sería una forma ÓPTIMA de desarrollar? dicho de otro modo, ¿no crees que es una forma genial de asegurarnos de que nada nuevo rompe nada de lo que hay hecho? Nos evitaríamos un montón de bugs tontos!! 

En una segunda vuelta, se nos podría ocurrir generar pruebas para asegurar que el código falla cuando tiene que fallar ¿no? Saber qué la aplicación solo se comporta como debe, cuando debe, también es importante. Además de que el hecho de que los errores y las excepciones  sean los esperados en cada caso es importante. También son parte del funcionamiento del sistema y deberíamos asegurarnos de que funcionen cómo y cuando deben 🙂

Las pruebas no son la bala de plata contra los bugs, por mucho que las hagamos los bugs aparecen, en menor medida, pero aparecen. ¿Qué debemos hacer cuando aparece un bug? Podemos corregirlo sin más, pero para seguir manteniendo la consistencia, lo primero que deberíamos hacer es el test correspondiente al fallo, la prueba que demuestra que es un bug. A partir de ese momento, cuando este corregido, será una prueba más que nos asegura la consistencia del sistema. Tendremos ese escenario y los adyacentes mejor asegurados para el futuro.

Los frameworks de testing

Muchos hacéis las pruebas como hemos dicho en el apartado anterior, es hora de que déis el salto!! Un framework de testing nos ayuda a hacer las pruebas de una forma más sencilla y nos proporciona información sobre el código probado. Por ejemplo, automatiza las llamadas a los métodos de prueba, genera informes de resultados integrados en el propio entorno de desarrollo, dan mayor granularidad porque permiten lanzar solo ciertas pruebas, etcétera…

Hay numerosos frameworks, normalmente, si sabes uno, cambias algo la sintaxis y sabes todos, no hay grandes cambios. Personalmente utilizo el MSTest porque viene integrado con Visual Studio.

Para poner un ejemplo, partiendo de la idea de antes, podríamos agregar un nuevo proyecto de testing a la solución con un código como el siguiente:

 

Es prácticamente lo mismo que teníamos, pero con una mejor organización, decorado con atributos y teniendo un informe de resultado de la ejecución de las pruebas cada vez que queramos tener feedback, cosa que habría que ir haciendo cada MUY poco tiempo. Porque cuanto antes descubramos el fallo, más fácil será corregirlo y menos impacto tendremos en el resto del sistema.

 

Probar te hará mejor profesional

Sin duda!! El hecho de probar tu código va a requerir que tengas que refactorizar, que simplifiques tus clases para que solo tengan el código que DEBEN tener, que en determinados escenarios aprendas cosas como mocking, la necesidad de la inyección de dependencias y la consecuente mejora en el diseño,… además SOLID, YAGNI y demás acrónimos serán parte de tu vocabulario sin que te des cuenta de ello 😉

 

Cómo empiezo a probar

Una vez estás convencid@ de que probar merece la pena y te ahorra tiempo, lo primero que te recomiendo es que escojas un framework de testing. Si no quieres demasiadas complicaciones al principio, utiliza el que traiga tu entorno de desarrollo por defecto. Según  vayas experimentando y acostumbrándote…prueba otros. Puede que encuentres matices que te resulten más útiles en tu contexto. Lo mismo es aplicable a los mocks… cuando empieces con ellos 🙂

Aqui te dejo enlaces a los más utilizados aparte del que viene integrado con VS.

Testing: xunit, nunit

Y un enlace a un video (12min) en Channel 9 de mi compañero Aurelio Porras con una intro a testing en Visual Studio 2010.

 

 

Happy hacking!

~ds

 

PD –> Frameworks de mocks: moq, rhinomocks, moles

PD2-> Frameworks de inyección de dependencias: Unity, Ninject, Castle Windsor

PD3 –> Una herramienta interesante y relacionada es Microsoft Pex… te genera tests para tu código

PD4 –> Vamos a jugar ^^ …. piensa por un segundo que en lugar de hacer el código y luego probarlo, primero haces la prueba ideal que debería pasar el código cuando funcione… y luego haces el código que haga que la prueba funcione… bienvenido a TDD 😉

Buenas…

En la ekoparty de Argentina, Juliano Rizzo y Thai Duong, mostraron un 0 day sobre ASP.NET. A quitarse el sombrero.. donde hay talento lo hay… pero.. hay un pero y muy gordo. Me parece aberrante su decisión de hacerlo público en una conferencia sin avisar a la empresa en cuestión previamente y más el entregar algunos pen drives con el código fuente del exploit.

Volviendo al asunto… un 0 day es una vulnerabilidad nueva, nadie teóricamente sabe que existe y no se puede estar preparado para ella.

He estado leyendo bastante sobre cuál es la parte vulnerable y como se explota. Pero por ahora no hay demasiada documentación de este caso en concreto y mucho son conjeturas de expertos en seguridad y expertos en .NET

Por si os interesa leer sobre ello, personalmente las mejores lecturas que he encontrado sobre el tema son:

http://www.reddit.com/r/programming/comments/dfhnz/think_the_aspnet_padding_oracle_exploit_is_no_big/  (Importante leer los comentarios)

http://threatpost.com/en_us/blogs/new-crypto-attack-affects-millions-aspnet-apps-091310?page=1

http://visualstudiomagazine.com/articles/2010/09/14/aspnet-security-hack.aspx

http://usenix.org/events/woot10/tech/full_papers/Rizzo.pdf

Y la respuesta de MS a día 19/09

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx

Hay que mirarlo con un poco de ojo crítico… muchas personas opinan sin saber, muchos intentan hacer astillas solo por ser Microsoft, etcétera… no le quito importancia en absoluto. Pero permanezco cauto hasta que encuentre un documento o el código fuente o algo más que opiniones e hilos de discusión.

En resumen… explota una vulnerabilidad relacionada con el algoritmo de cifrado que se utiliza en la autenticación por Forms. Va probando diferentes entradas y detectando la diferencia de respuesta de la aplicación para aprender y finalmente dar con una clave que da acceso.

Hay muchas teorías de que: Habilita Custom errors ya una misma página y ya está… ó  eso pasa por no usar SSL ó que cambies de AES a 3DES ó que si tienes una red mínimamente securizada, va a parecer un DoS y se va a bloquear la IP…  personalmente aún no tengo una opinión 100% formada.

Pero teniendo en cuenta que es un ataque Padding Oracle… se basa en aprender y recabar información en base a respuestas diferentes resultado de peticiones mal formadas. De modo que la recomendación que hace MS Corporación a través del blog de Scottgu, me parece más que razonable… misma página de error para todo, no demos pistas de nada hasta que esto se aclare un poco más y veamos dónde hay que tocar para arreglarlo.

Happy hacking!

~ds

PD –> Las actividades que más me han gustado y atraido de nuestro mundillo son las de la seguridad y el análisis postmortem. De hecho los ratos más satisfactorios desde que tengo un PC siempre los recuerdo en esos ámbitos :)  En seguridad tenía la necesidad de tener que estar siempre al día de todo, tBBDD, fwrks, desarrollo, SO… y además algo de picardía para buscar huecos o hacer algo de ingeniería social. En análisis postmortem tienes que tener muy bien unidos todos los puntos para entender qué esta pasando. Conocer de verdad lo que tienes delante, pq el problema está ahi y sólo dependes de tu capacidad para encontrarlo. Ambas disciplinas me aportaron las mismas sensaciones… la realización cuando das en el clavo y encuentras el hueco, cuando funciona el rootkit o encuentras el problema en el dump.

Ese es el momento álgido y no otro. El momento en el que lo logras. Sonries porque eres un crack, avisas a quién ha hecho el juguete defectuoso y te vas a tomar algo con el resto de geeks con los que currabas en esto.  Personalmente dudo que tirar 4 pendrives en una charla, cargarte el fin de semana de muchos admins/developers, dejar daños colaterales a algunos usuarios y ser el chulo de la conferencia cause el mismo subidón que haberlo logrado. IMHO estas acciónes muestran una absoluta falta de ética.

Ya lo decía le chiste… “Hay que organizarse!!”  Y cuanta razón tenía… como no te organices bien….  ^^’

Como muchos sabréis, hay numerosos métodos de organización, productividad personal, seguimiento de proyectos,… que proponen una serie de acciones que ‘se supone’ te hacen ser más productivo. Por mi trabajo o por mi falta de organización, he tenido la oportunidad de experimentar varios de estos métodos y ver como algunos se estrellaban contra la realidad de mi inbox y otros contra mi falta de disciplina. Obviamente no todo ha sido malo, el hecho de experimentar me ha valido  para crear mi propio batiburrillo de técnicas / prácticas que me ayudan para organizarme y no perderme en el día a día.

Quería compartir alguna de estas ‘ayudas’ por si estáis en la misma situación que yo y os pueden servir de referencia.

Proyectos, historias y tareas

He dividido mi trabajo en proyectos ( grandes bloques ), cada uno de estos proyectos en historias ( las diferentes partes del proyecto que tienen que llevarse a cabo ) y cada historia en tareas.

Una tarea es una acción… y como tal, estimo el esfuerzo que me va a requerir ( S, M ó XL ), la prioridad, pongo la fecha límite para empezarla, mantengo actualizado el estado y registro el ‘accountability’ de la acción.

Todo esto lo llevo en una hoja de excel, donde semanalmente decido las tareas a las que me voy a dedicar esa semana. ( pocas de nivel XL, algunas de M y algunas más de S).

Según las voy acabando o van apareciendo, las tareas de la lista cambian dinámicamente. Lo de mirarlas una vez  a la semana es para ver el global, en que proyecto avanzo, en cuales no, los stoppers, etcétera…

Planear el unplanned

Los fuegos y las urgencias son un hecho, hay que acometerlas y resolverlas cuanto antes, en mi caso lo fundamental es… no perder de vista los objetivos iniciales y acordarme de registrar esas acciones unplanned. Así, cuando veo que no he acabado una tarea planeada, al menos tengo la justificación de qué otras cosas han acabado mi tiempo.

Es importane ser realista en cuanto a las acciones que se planean para una semana… miro las reuniones, los compromisos, el volumen de mail, los marrones que sobrevuelan… Prefiero quedarme corto y añadir nuevas tareas que sentir siempre que no acabo nada.

A primera hora… lo que más cuesta

Las 2 o 3 primeras horas del día las dedico a la tarea más importante en base al peso y la por prioridad, cuando puedo uso intervalos de 25 minutos para centrarme (pomodoro) y ser más productivo. Cuando he dedicado ese tiempo, cambio el tercio y me dedico a otras tareas.

Es difícil dedicarte tanto rato a una tarea y normalmente, a no ser que se trabaje desde casa es casi imposible evitar las interrupciones… sobre todo por parte de los perfiles no-técnicos ( hay mucha gente que no entiende porqué los perfiles técnicos podemos necesitar concentración y ratos sin interrupciones )

un segundo, tienes 5 minutos, oye no me funciona nosequé, puedes mirarmelo?…

…intento no desesperarme, hay que vivir con ello, intento emplazar las interrupciones para otro momento, pedir que me lo envien por mail, pero como hemos dicho… plan the unplanned!

El mail, el twitter, … las interrupciones

Cerrado. Lo abro durante 5-10 minutos cada X tiempo y lo vuelvo a cerrar. SI no no avanzo. No se si os pasará, pero personalmente he llegado a un punto en el que se me hace mucho más dificil cerrar el twitter que el mail.

Las reuniones las considero interrupciones. Son necesarias, pero creo que con un tercio de las que tenemos sería suficiente. A las reuniones se llega preparado, con un tema a tratar trabajado previamente, se discute, se toman acciones y vuelta al trabajo. Con ese formato se consideran acciones, si son el tipico rato de 50 minutos donde los participantes miran el mail, no se sabe muy bien que se va a tratar, hay muchos ratos muertos… planteate que igual deberías estar discutiendo en la máquina de café o en la comida en lugar de en una sala de reuiones 🙂

El inbox … la falsa lista de tareas pendientes

Mis tareas están en el excel, no en el inbox. Ver tanto mail te hace llegar a pensar que tienes que tomar acciones en todo, y nada más lejos de la realidad.

Mi regla de oro… si voy en el To… el correo cambia de color. Si no… en los ratos que abro el mail lo voy procesando. Archivando en carpetas por proyecto, respondiendo lo inmediato o creando una tarea unplanned para lo que me va a llevar más de 2 minutos tiempo.

Luego claro que tengo otras reglas… mails de los managers a una carpeta, del equipo a otro, de las listas de distribución a otra… así de una pasada veo donde tengo acciones pendientes.

 

Personalmente, con estos 4 puntos alcanzo un nivel de productividad con el que me siento contento, me voy a casa satisfecho con el trabajo. Y en cierta manera… se pueden asimilar al desarrollo de software: declara, prioriza, ejecuta, espera el cambio e itera

Happy hacking!

~ds

PD1 –> Al final va a pasar lo mismo con el “things done” que con el “Driven Design”, solo tienes que ponerle una letra cualquiera delante para crear tu marca y diferenciarte 🙂

Hoy ha sido mi segunda quedada en Madriagil ^^^

Parece que todos hemos tenido cierto mono en vacaciones, porque nos hemos juntado unos cuantos más que la última vez ( quedada para refactorizar ). Creo que he contado 19. A través de la lista de correo se había acordado centrar la discusión entorno a dos temas. Contratos ágiles y cómo vender TDD a la gestión/management.  Hemos dedicado X tiempo a cada tema e intentado sacar algunas conclusiones en claro. Voy a hacer un pequeño resumen de lo ocurrido para quién le interese… agradeceré que cualquier asistente me corrija o complemente el resumen con alguna otra observación 😉

He llegado con el tema de los contratos ágiles empezado, de modo que no se como hemos iniciado la discusión…pero ahí algunos puntos donde nos hemos parado y algunas notas que he tomado en torno a ellos… y mi opinión personal e intrasferible.

Contratos ágiles

Partimos de la base de que queremos un contrato ágil y hemos tenido en cuenta las dos orillas del rio. Desde el punto de vista del contratante ¿Cómo podemos tener seguridad de que estamos contratando un equipo ágil? y desde el punto de vista del contratado ¿cómo puedo exponer el valor de mi equipo a través de un contrato?

Para entrar en materia hemos empezado trabajado entorno a una licitación pública de la de la junta de andalucia donde solicitan que el pliego técnico sea realizado empleando SCRUM. Luego hemos coincidido en que el hecho de que sea de la administración hace que gran parte de los beneficios que pueden venir por parte de tener un equipo ágil se pueden perder por la burocracia del trabajo con la administración. Por ejemplo… Si a la segunda iteración, no me gusta la empresa y quiero deshacerme de ese proveedor y contratar otra.. puedo tener una muerte por trámites 🙂

Talking points:

– El pliego tiene techo pero también debería tener suelo. Deberían asegurarse una serie mínima de de iteraciones, si no lo hacemos podríamos encontrarnos en una situación en la que invirtamos en montar/contratar el equipo para el proyecto y se caiga antes de empezar.

– ¿Cómo comparamos proveedores en una licitación ágil? Obviamente podemos usar un portfolio o experiencias en anteriores proyectos, pero ¿Podemos medir a los proveedores en base a su velocidad? o ¿podemos establecer un estándar de puntos de esfuerzo para todos los proveedores? En MI opinión, estos son medidas PARA el equipo, internas, no creo que valgan en una oferta.  Otra opción era reunirse con los proveedores para que nos propusiesen un release plan y que valorasemos en torno a eso… siempre con cuidado de no caer en un Gannt y perder la agilidad por el camino. Tambien se han planteado las certificaciones… podemos confiar en el nivel de certificación en SCRUM/AGILIDAD del proveedor? o certificarlos nosotros? Si bien es una falsa seguridad, en mi opinión…algo es algo…

– ¿Es el contrato ágil un nuevo tipo de contrato? La mayoría pensabamos que no… que se puede enmarcar dentro de un modelo tradicional, ya sea de contrato por servicio o por obra.

Todos hemos coincidido en que la naturaleza de un contrato ágil nos debe permitir cambiar de dirección en las iteraciones. Bien  sea para parar, continuar o cambiar de proveedor.

 

TDD

Cuando ha sonado el gong ( a la segunda o tercera vez 😛 ) hemos cambiado de tercio y hemos pasado a ver cómo podíamos vender TDD a la gerencia. Al final nos hemos liado la manta a la cabeza y además de ver como vendérselo a la gerencia, nos hemos autoconvencido, se lo hemos vendido al equipo, entre equipos, hemos discutido de si TDD merece la pena, etcétera… vamos, que nos ha quedado completito el rato dedicado a TDD 🙂

Cabe destacar que NO todo el mundo de la reunión hace TDD, había personas que lo habían descartado por ahora y preferían quedarse con el enfoque tradicional de testing para sus proyectos. En lo que SI estabamos todos de acuerdo es que HAY QUE PROBAR el código 😉

y OJO que TDD no exime de hacer otras pruebas o de utilizar herramientas como PEX para asegurar la consistencia del código.

Talking Points

– Cómo vender el valor de TDD a la gerencia. En realidad hemos visto que la gerencia que tiene un perfil de negocio no es problema. No esta capacitado para tomar esas decisiones y va a tener que fiarse de algún técnico. El problema esta en si TDD afecta demasiado al rendimiento en las fases iniciales y esto impacta a la productividad. Estabamos de acuerdo en que TDD como proceso tiene su tiempo de adopción y su curva deaprendizaje, y una vez implantado, hay que meter tiempo en ello… si un gerente comercial se queja, siempre podemos enseñarle un diagrama donde se vea que el número de bugs disminuye o uno donde se vea que aumenta la cobertura de código.

De acuerdo…cobertura de código no tiene porqué implicar calidad…. pero como hemos dicho antes…algo es algo. Y recordemos que estamos hablando con un gerente comercial.

– TDD desde el equipo de desarrollo. Otra posibilidad es que los individuos comiencen a hacer TDD, por su cuenta, sin que tenga que venir impuesto por el gerente. El equipo puede ser el iniciador del cambio. Hemos pensado en algunos motivos que esgrimir cuando queremos convencer a alguien a que haga TDD:

TDD mantiene el diseño a prueba constantemente

TDD nos permite avanzar con seguridad en el contexto de un dominio desconocido

TDD ayuda a detectar antes los posibles fallos

Es más fácil empezar a hacer TDD si hacemos pair programming

TDD es una herramienta efectiva para la gestión del cambio

TDD implica mejorar como desarrollador porque a base de usarlo vas a reconocer patrones, refactorizar, detectar bugs…

TDD es un acto de fé… prueba y verás como te engancha

– Cómo empezar con TDD. Una vez el equipo se decide… ¿Cuál es la mejor manera de empezar a hacer TDD? ¿Dónde lo aplicamos? En estos puntos han surgido también varias ideas:

Podemos enfocarlo como diseñar orientado a ejemplos. Escribimos el ejempo de como ha de quedar y luego el código que lo resuelve.

En lugar de empezar directamente con TDD, podemos emprezar con unit testing tradicional y cuando el equipo se sienta cómodo probando y refactorizando…dar el paso de empezar con los tests en lugar de con el código.

Los tests de aceptación pueden ser también un acelerador de la adopción de TDD. Si tenemos requisitos de negocio escritos como pruebas nos va a resultar mucho más natural escribir los requisitos funcionales también como pruebas.

Podemos restringir el uso de TDD a la parte del proyecto que tenga un dominio más desconocido.

 

Conclusión

Al igual que el primer dia, me lo he pasado bien y he aprendido un montón en base a la experiencia del resto de compañeros. Nada de lo que tratamos ni ninguna de las conclusiones en un axioma que nadie deba memorizar. De hecho, reina la divergencia de opiniónes en las reuniones, pero creo que hay temas en los que estamos TODOS de acuerdo. Para mi hoy han sido los beneficios que aporta el trabajo iterativo de los equipos de desarrollo y la importancia de las pruebas a la hora de construir software robusto.

Como he destacado, ninguna de las opiniones es ley, pero si no haces alguna de esas dos cosas tal vez podrías probar… nosotros 19 estábamos de acuerdo en que a nosotros nos funcionan 😉

 

Próxima quedada.

Nos hemos propuesto vernos el 23/9 (lugar por determinar) para hablar sobre:

Mejores prácticas de branching

Cómo repartir tareas dentro de un equipo en SCRUM

Si quieres venirte estate atento a la lista o a la web para cuando anunciemos el sitio.

 

Recursos

Web de madriagil

Madriagil es uno de los grupos de personas interesadas en metodologías ágiles… pero hay más!  Mira en este enlace  http://www.agile-spain.com/ y anímate

 

Happy hacking!!

~ds

PD –> No pongo nombres de los asistentes pq no me los sé todos aun y no quiero poner unos sí y otros no. O todos o ninguno.

El Martes 17 de Agosto a las 8:00 am UTC +1 se me acabaron las vacaciones y volví a la oficina. supongo que al igual que muchos de vosotros, la primera semana me la pasé pensando diferentes maneras de poder vivir sin trabajar. Que si montar un chiringuito en tal o cual zona, hacerse profesor de surf en verano y de ski en invierno, invertir a lo salvaje, montar el siguiente facebook, irme a un pais donde lo poco que pueda tener ahorrado me de para toda una vida,… y un largo etcétera de proyectos emprendedores que curiosamente siempre me rondan en las mismas fechas 😛

En algún momento durante el ensoñamiento de una vida llena de dinero, levantándose a las 12 y haciendo lo que me viniese en gana…desperté. Son finales de Agosto, estamos entrados en FY11 y hay un montón de cosas por hacer!!!

{ Para quien pueda interesar, en MS nuestros años fiscales no se corresponden con años naturales. Van de Julio a Julio, justo hemos acabado lo que internamente denominamos el Fiscal Year 10 y estamos empezando el FY11 }

Comenzando el FY11 y a sabiendas de que los objetivos del año cambiarán en base a necesidades, los productos sorpresa q se lancen sin avisar,  crisis sorpresa… nosotros hacemos una primera planificación de objetivos para el año fiscal. En base a los resultados el FY anterior, objetivos marcados por corporación y objetivos locales y personales, definimos el tipo de contenido que queremos contemplar, los eventos a realizar, paises pequeños a comprar, plataformas en las que haremos hincapié, formatos, y demás acciones relacionadas.

Os puedo adelantar algunas de las áreas en las que intentaremos hacer hincapié desde MSDN… ya veremos en Junio 2011 si con más o menos éxito, pero por nuestra parte que no quede.

(conste que la lista no está ordenada por prioridad)

Internet Explorer 9. Esperamos que sea un bombazo y lo esperamos con los brazos abiertos.

Plataforma Windows Azure. Nació en PDC 2008, este año pasó a plataforma comercial y ahora tiene más de 10k clientes. Seguiremos contando los beneficios del cloud y animandoos a probar.

Plataforma Web Web Matrix, Orchard, Web Forms, MVC, IIS, PHP, OData, Web App Gallery… hay mucha oferta para diferentes perfiles de trabajadores web. Veremos si podemos aclarar el mapa y ayudar a escoger la tecnología más adecuada en cada caso.

Windows Phone 7. Nunca ha sido tan fácil crear aplicaciones tan ricas para un teléfono móvil, esperamos que llegue cuanto antes a españa y podáis reutilizar lo que ya sabéis, pero aplicado al teléfono.

Desarrollo para desktop. Windows 7 y WPF salieron hace ya bastante. Seguiremos trabajando en pro de la integración de las aplicaciones con el escritorio para sacarle el máximo partido a la experiencia del usuario… y tb tendremos que hablar de Visual Studio LightSwitch, no?

Online y videos. Si bien nos encanta estar de ruta, está más que demostrado que los recursos online os resultan más útiles, así que intentaremos mejorar la plataforma, trabajar la buscabilidad, organizar los recursos… 😉

Lamentablemente no es viable que estemos todos los compañeros metidos en todos los saraos, aunque no nos faltan ganas… Personalmente estaré más involucrado en lo relacionado con

IE9  y Plataforma Web de Microsoft Todas las novedades que aparezcan este año relacionadas con el desarrollo web no RIA.

Optimización del trabajo en grupos de desarrolladores .NET Abrazar aspectos que sobradamente han demostrado que ayudan a equipos de desarrollo desde una perspectiva .NET / Visual Studio. Esto incluye tanto temas metodológicos (reuniones, gestión de equipos, reporting) como de ingeniería ( pruebas, tests de aceptación… )

Creación de materiales. Videos, aplicaciones de ejemplo, eventos empaquetados para grupos de usuarios, laboratorios… Todo lo que se me ocurra o me comentéis que pueda servir de ayuda.

Veremos si no nos sorprendemos lanzando el UberMegaCoolDevProduct en Diciembre y tenemos que cambiar todos los objetivos 😛

En fin…

Si AUN disfrutáis de las merecidas vacaciones… aprovechadlas que todo se acaba. No se que haces leyendo geeks…. geek!

Si ya has vuelto… deja de pensar en la crisis postvacacional! y ponte las pilas 😉

 

Happy hacking!!

PD-> Te recuerdo que MSDN esta en twitter para lo que necesites. www.twitter.com/esmsdn  preguntas, feedback,…

PD2 –> Para mi el comienzo de FY es como año nuevo, así que busco profesor de inglés, estoy a dieta, me he apuntado a un par de aficiones nuevas, quiero escribir un libro… ^^’

Ayer por la noche se anunció la Beta de WebMatrix, tengo la impresión de que hay unos cuantos elementos que no están muy claros gravitando alrededor del lanzamiento… Razor, WebMatrix, ASP.NET Pages, IIS… mi intención en este posts es ordenar un poco los elementos que han formado parte del lanzamiento.

Elevator pitch –> Web Matrix es un conjunto de herramientas que facilitan disponer de un entorno rápido y sencillo para el desarrollo de sitios web.

Actualmente si quieres hacer un desarrollo web con tecnología Microsoft tienes que activarte el IIS, descargar el framework, configurar el IIS para que trabaje con el framework, descargar la herramienta de desarrollo, el SQL…. si bien el Web Platform Installer simplifica la tarea con un único punto para gestionar las descargas… siguen siendo una serie de herramientas demasiado independientes para una persona que no ha sido ‘iniciada’ en el mundo MS.

Componentes de Web Matrix

Una versión de desarrollo de IIS, el IIS Developer Express. Una mezcla entre el IIS tradicional y el ASP.NET developer server que trae Visual Studio. Lo bueno es que ocupa menos de 10Mb, corre como un proceso, no necesita privilegios de administrador, soporta SSL, URL Rewriting…

Una base de datos, SQL Compact. No necesita setup, ni administrador ni nada… simplemente copiar los binarios a la carpeta bin de la aplicación web.  El motor de la base de datos funciona en memoria con la aplicación.

Una herramienta de creación de páginas web, que también se llama WebMatrix. Este es uno de los grandes valores, para minimizar la curva de aprendizaje de la herramienta, ha sido diseñada orientada a las tareasdel desarrollador. A nivel de desarrollo, permite extender conocidas aplicaciones del mundo Open Source (blogengine, Drupal, Gallery, WordPress… ) o empezar desarrollos en base a plantillas o desde 0.  Pero también tiene otras perlas, como publicar a FTP, usar los servicios de deployment para desplegar en un hoster, sugerencias SEO…

Una nueva sintaxis para ASP.NET, Razor. Ha sido creado como una vista de ASP.NET MVC, NO ES UN NUEVO LENGUAJE, es una vista, como Spark, NHaml,…  Sintácticamente es muy parecida al ASP/JSP/PHP/ASP.NETMVC, donde el código de servidor se entrelaza con el HTML.

Ahora mismo es algo separado, pero  hecho en la próxima versión de ASP.NET MVC, Razor será una de las posibles motores de vistas disponibles. Al no estar aún integrado con MVC, WebMatrix también trae un paquete extra ASP Pages, que da soporte a Razor.

(Me permito fusilarle la imagen a scottgu ^^)

Veís que la arroba es el escape para variables y sentencias…

Lo que os decía… muy ASP/PHP/JSP/MVC =)

 

Opinión personal e intransferible ( siempre discutible )

Creo que webmatrix tiene varios puntos en los que enganchar con diferentes perfiles. Por ejemplo… si eres un desarrollador web .NET que ya controla el IIS, el SQL, MVC… pues tal vez te interese echar un vistazo a Razor para usarlo en las vistas. SI eres ‘adaptador’ web, tal vez la parte de la integración de la herramienta con aplicaciones Open source sea interesante, para estudiantes o gente que se inicia (desarrolladores ASP, Java, PHP que tengan que ponerse las pilas en .NET), es un stack muy fácil de instalar y echar a andar… 

Acaba de salir la beta… ya iremos entrando a detalle en las posibilidades de cada una de las piezas, espero que haya servido como introducción general.

Descarga –> http://www.microsoft.com/web/webmatrix/

Documentación, tutoriales…. –> http://www.microsoft.com/web/webmatrix/learn/ ( solo en inglés )

 

Happy hacking!!

~ds

PD –> Si… antiguamente existía un producto que se llamaba ASP.NET WebMatrix … ya sabéis que en MS a veces tenemos duendes en marketing ( .NET 3.0, Plataforma Windows Azure con servicio Windows Azure … ^^ )

Creo que en los últimos años no ha variado la cantidad de gente que trabaja con tests… han evolucionado los frameworks, se han creado nuevas herramientas… pero no ha habido demasiada adopción, no se ha transmitido correctamente el valor de los tests y no se ha invertido el suficiente tiempo en ellos. Quien hacía pruebas en el 2009… es porque las hacía desde el 2003 🙂

Por fin… en el 2010 😀 parece que poco a poco va entrando en la cabeza de los equipos la rentabilidad de probar el código de una forma formal y sostenible y de una forma u otra los equipos van haciendo sus pinitos.

Para estos equipos que se inician, para quién quiere probar herramientas nuevas o para quien tiene código heredado que no sabe como atacar…llegan dos addins de visual studio  ( de la mano de Microsoft Research ) que facilitan la generación y el trabajo con puebas.

Microsoft Moles 2010::

Resumiendo, es un framework de mocks. Si nunca has trabajado con un framework de mocks, su misión es ayudarnos a aislar el código de dependencias externa, permitiendo reemplazar métodos y propiedades por equivalentes para pruebas.

<breve intro a lo que es un mock>

Supongamos que estamos validando la funcionalidad de sumar dos enteros (original, eh?) Y los valores de esos enteros, se leen de una BBDD.

Ahora supongamos que al lanzar el test, éste falla porque la red esta mal configurada y no se puede resolver el nombre del servidor SQL. Eso NO es lo que buscabamos en este test… lo que queremos probar es si es capaz de SUMAR correctamente.

Vamos  mockear el acceso a bbdd. Vamos a suplantar esa llamada, de modo que el nuevo método devuelva dos enteros, sin más, sin ir a bbdd ni nada, para que la prueba de la Suma pueda centrarse en su ámbito.

</breve intro a lo que es un mock>

Microsoft PEX 2010::

El nivel  básico es conceptualmente sencillo. En base a un análisis del código, crea tests con las entradas necesarias para ejecutar todas las ramas existentes en el código ( todas las posibilidades de if, switch… ) y descubrir posibles excepciones o errores.

Además nos deja personalizar esos tests o recoger información relativa a la cobertura de código ( cobertura en VS Premium o Ultimate ).

En este post nos centraremos en PEX y en otro posterior atacaremos Moles 😉

 

¿Cómo funciona PEX?

Una vez instalado, PEX funciona a través de un menú de contexto en Visual Studio, lo invocaremos para inspeccionar una clase o método y nos mostrará una ventana con pares de información introducida y resultado obtenido.

Es MUY sencillo obtener esta información… simplemente hay que ejecutar PEX… y éste se encargará de ejecutar varias veces el código seleccionado con diferentes opciones de entrada ( Exploraciones PEX )

nota… la primera vez que ejecutas pex te pide que selecciones un framework de tests

Y el resultado…

 

Vemos que entradas ha probado null, “”, “” … y que en todas ha ido sin problemas excepto en la primera, PEX ha detectado que este método podría generar un NullReferenceException Leyendo el código se nos podía haber escapado ( y no digas que no que el software esta lleno de despistes como este )… y puede que si hacemos los test a manos estemos demasiado centrados en lo que debe pasar y no en lo que pueda pasar…pero al analizar todos los statements y sus ramas, lo ha cazado 🙂

Al hacer click sobre la excepción en la ventana de PEX nos da información adicional del stack y detalles del test creado.

 

Y hasta nos permite mandársela por mail a quién consideremos oportuno

 

Algo más avanzado… precondición y asunción

Imaginemos que este método no tiene que tratar esa posibilidad de parámetro = null porque siempre se le llama con un valor correcto. En ese caso sería el componente que llama el responsable de controlar el valor del parámetro.

En la imagen anterior podemos ver que hay una opción Add Precondition, si nos situamos sobre la opción, nos muestra un pop up donde vemos una posible forma de tratar el error.

Si hacemos click, pex modifica nuestro código añadiendo la precondición para propagar la excepción al que invoque

Personalmente no me gusta esta solución, lanzar una excepción nueva no es solucionar el error. PEX nos da opciones ms elegantes, como añadir Assumptions al caso de prueba. Podriamos indicarle al test que asumimos que ese parametro nunca va a ser null y evitamos la excepción.

Tendríamos que guardar el test fallido (o todos, al gusto),y editar la clase que inicia las pruebas.

Así podremos indicarle que asuma que el valor no es nulo.

Y al volver a ejecutar los tests… evitarnos la excepción 😉

La funcionalidad de explorar las ramas con diferentes valores hace a PEX útil desde el minuto 0, pero como véis, además podéis entrar dentro del framework y trabajar a un nivel mayor de detalle.

Discusión… tiene sentido PEX en un entorno TDD?

Aquí me gustaría abrir algo de debate a ver qué opináis… sé que los comentarios no son un foro… pero permitidme la licencia 😉

Para mi tiene todo el sentido… TDD para aceptación y funcionalidad y PEX para descubrir despistes y dar información de cobertura.

 

Documentación, descarga y demás… –  http://research.microsoft.com/en-us/projects/pex 

Laboratorio de PEX – http://research.microsoft.com/en-us/projects/pex/digger.pdf

Vídeo de Unai en ch9 de intro a PEX – http://channel9.msdn.com/posts/Daniel+Garzon/Introduccion-a-PEX/  (tiene algo más de un año… pero hace el servicio 😀 )

 

Happy hacking!

PD –> Nos vemos con Holanda en la final! ( a ver si no tengo que tachar el comentario mañana tras el Alemania-España xD )