April 2010 - Posts
Siguiendo con los ejemplos que se han armado para el material del Proyecto Hogwarts, quiero hoy publicar un caso de uso de Test-Driven Development con Visual Studio 2008 y C#. Ya había publicado un ejemplo anterior con video en:
Un ejemplo de TDD
La idea es implementar una pila. Ya tenemos una implementación dentro del propio framework de .NET. Pero la idea acá es desarrollarla usando TDD. Para eso, planteamos una serie de test iniciales, a cumplir por nuestra implementación. Programar de esta forma, permite poner explícitamente cómo esperamos consumir al software que estamos construyendo. Al escribir los tests, estamos poniendo cómo queremos que se consuma y actúe nuestro objeto pila. En una pila, colocamos elementos, en este caso enteros, y los retiramos, con el criterio último entrado, primero salido.
Por simplicidad, hacia el final de este ejemplo, se implementó usando una pila interna de .NET. Pero podríamos haber implementado con una lista o de otra forma. Puede quedar el caso para un próximo refactoring. También se repitió código de inicialización: hay que estudiar cómo podemos mejorar esto. Y un tema para la próxima edición de este ciclo, es el uso de code coverage: cómo podemos conocer qué parte de nuestro código hemos probado.
Pueden verlo directamente en Youtube, más grande, en http://www.youtube.com/watch?v=d6JrhC1u2Dw y con opción a pantalla completa.
Espero que les sirva, cualquier “feedback” es bienvenido.
El código del ejemplo en TddStack01.zip.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ya comenté sobre el Proyecto Hogwarts: el desarrollo de material, entregables, que sirva de soporte para el entrenamiento de desarrolladores de software. Los puntos claves a atacar en este primer release, son:
- TDD Test-Driven Development
- DI Dependency Injection, contenedores de Inversion of Control
- Mocks, usos y librerías
- Principios SOLID
Una de las ideas que estamos explorando, es producir pequeños ejemplos de los temas, como parte de los entregables. En este post, viene una primera versión de un ejemplo que proponemos como parte de una charla de introducción a TDD.
El instructor describe primero a grandes rasgos los elementos de TDD, como el ciclo rojo-verde-refactor, pero para fijar el concepto, se necesita mostrar un ejemplo andando.
En este video, mostramos el uso de Visual Studio 2008, con sus proyectos de tests, y la forma de encarar el ejemplo: queremos desarrollar una simple clase que implemente una calculadora, y la suma de dos números.
Esperamos ir generando más videos de los ejemplos que estamos preparando, como forma de exponer a la comunidad parte de los entregables que se van sumando al proyecto. Se agradece cualquier comentario, sugerencia, sobre este video y los próximos (resolución, calidad de video, sonido, así como ejemplos elegidos, claridad de exposición, etc…)
Pueden bajar el código de TddCalculator01.zip.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
De nuevo, este sábado tendremos des-conferencia virtual, organizada por la gente de la comunidad ALT.NET Hispano. Será este sábado 17 de abril, a las 18hs GMT (3 de la tarde acá en Buenos Aires).
El tema, esta vez, será TDD (Test-Driven Development), de la mano de Carlos Blé (@carlosble). Escribe el bueno de Jorge Gamba (@jorgegamba) en
Test-Driven Development (TDD)
Escribe Jorge
Test Driven Development’ que en español corresponde con ‘Desarrollo guiado por pruebas’ o ‘Desarrollo dirigido por ejemplos’, como lo llama Carlos Blé, es una de las prácticas ágiles más apreciadas en el mundo ALT.NET puesto que aplicándola con juicio se obtiene una mejora sustancial en el proceso de desarrollo de software. Contrario a lo que muchos creen, es más una técnica de diseño que de pruebas
El método consiste en que primero se escriben las pruebas basadas en los requerimientos, se comprueba que estas fallen inicialmente, luego se implementa el código para que pasen satisfactoriamente y finalmente se refactoriza o *** el código y así sucesivamente se continúa desarrollando pequeños incrementos.
Carlos Blé ya había escrito en la lista de ALT.NET Hispano:
En esta ocasión podemos hablar sobre Test Driven Development. En enero publicamos un libro en español sobre ello que podéis leer gratuitamente aquí:
www.dirigidoPorTests.com/el-libro
Como introducción recomendaría echarle un vistazo a esta presentación que hice hace poco: http://www.podgramando.es/video/charla-en-castellon-de-carlos-ble, para no repetirme y ver mas cosas si os apetece.
Mi idea es hablar de los errores típicos que se comenten en la práctica de TDD y luego si queréis, programar juntos un poco utilizando Visual Studio con escritorio compartido.
Jorge también anuncia:
Como un beneficio adicional, en nuestras VAN obsequiamos algunos eBooks, suscripciones y licencias de productos de interés para nuestro auditorio
y nos recuerda:
Hay que aclarar que no se requiere ningún tipo de registro, simplemente acudir el día y la hora indicados a la dirección Web http://snipr.com/virtualaltnet, eso sí, deberán tener instalado el programa cliente de Live Meeting; hay más instrucciones sobre cómo hacer esto y otras indicaciones en la página wiki Descripción de Reuniones.
Pienso que TDD es una de las disciplinas primeras a aprender y practicar, aunque también veo que para muchos es difícil implantarla (Ver Más allá de hablar de buenas prácticas).
Tengo que preparar un post con recursos de TDD que estamos usando como base del material del Proyecto Hogwarts. Y comenzar a publicar más sobre lo que estamos generando en ese proyecto sobre el tema. Una idea es comenzar a grabar videos cortos, con los primeros ejemplos.
Mis enlaces sobre TDD:
http://delicious.com/ajlopez/tdd
http://delicious.com/ajlopez/tdd+tutorial
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Siguen organizándose actividades para desarrolladores de software, por estos lares. Es interesante ver cómo algunas prácticas se van difundiendo (TDD, refactoring, SOLID y demás), y si bien una práctica tiene su fundamento y teoría, es necesario, justamente practicarla para ponerse “proficient” en la misma. Una forma de practicar es en grupo. Esa es la idea de los Code Retreat. Pueden leer en:
http://www.coderetreat.com/how-it-works.html
What Is Code Retreat
The idea for code retreat was spawned at the January, 2009, Codemash Conference by Patrick Welsh, Nayan Hajratwala and me, Corey Haines. The idea was to develop a repeatable, day-long event that was focused on practicing the fundamentals of software development. The first event was held in Ann Arbor, MI, not long after the conference.
Más información en:
http://www.coderetreat.com/
http://coderetreat.ning.com/
Ahora, gracias a la organización de la gente de Prama, tendremos un Code Retreat en Buenos Aires:
http://sites.google.com/site/comunidadagiles/argentina/code-retreat
Leo ahí:
La idea de un Code Retreat es que un grupo de programadores nos juntemos, programemos , discutamos y aprendamos unos de otros.
Cuándo: 24 de Abril, 8:30 a las 17:30
Dónde: El evento va tener lugar en las oficinas de Pragma (que es el sponsor) y va a durar desde la 8:30 a las 17:30. Después está la idea de compartir un par de cervezas con aquellos que puedan. La dirección es San Martín 575 Piso 1 (San Martín y Tucumán).
Como recibimos algunas consultas, aclaramos que el evento no tiene costo para los participantes.
Tienen en esa página el enlace para inscribirse.
Es un evento de gran parte del día, es un día sábado, para que puedan concurrir sin estorbar tanto el día laboral. Y una excusa para pasar el sábado con otros desarrolladores de software. Leo en la página:
La mecánica es la siguiente: vamos a trabajar haciendo Pair Programming y TDD. Todos los pares van a atacar el mismo problema en sesiones de 40 minutos. Una vez terminada la sesión haremos una retrospectiva de unos 10-15 minutos para reflexionar sobre los problemas que encontramos. Luego de la retrospectiva, se cambian los pares, se borra el código escrito en la sesión anterior y se arranca una sesión nueva con el mismo problema que la anterior.
La idea es hacer unas tres sesiones a la mañana, almorzar juntos y hacer un par más de sesiones a la tarde. Como evento final del Retreat vamos a hacer alguna actividad relacionada pero distinta a las sesiones.
Los lenguajes que elegimos para este Retreat son Java y C#. Generalmente se usa un solo lenguaje por retreat, pero son lenguajes muy parecidos y nos pareció que abría un poco más la convocatoria usar los dos.
Durante el retreat vamos a trabajar los siguientes conceptos:
- es bueno ser capaces de tirar el codigo y empezar de nuevo
- pequeños pasos en TDD, muy pequeños
- foco en el tercer paso del ciclo de TDD: calidad del codigo y refactoring
No es necesario tener experiencia en TDD ni en Pair programming.
Vamos a necesitar que todos los que puedan lleven laptops con Eclipse/Visual Studio instalados.
Como se va a trabajar con Pair Programming, pueden concurrir sin laptop, pero cuantos más lleven, mejores parejas se podrán formar.
Bienvenida la iniciativa!
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Se viene una Cloud Camp, creo que la primera en Buenos Aires:
CloudCamp Buenos Aires, Mayo 7, 2010
CloudCamp is an unconference where early adopters of Cloud Computing technologies exchange ideas. With the rapid change occurring in the industry, we need a place where we can meet to share our experiences, challenges and solutions. At CloudCamp, you are encouraged to share your thoughts in several open discussions, as we strive for the advancement of Cloud Computing. End users, IT professionals and vendors are all encouraged to participate.
El organizador es el bueno de @MartinSalias. El lugar es @Southworks. Más info:
Fecha
7 de Mayo 2010, 3:00pm - 7:15pm
Lugar:
Oficinas de Southworks
C. Peru, 375 - 1er piso
(esquina Belgrano)
Ciudad de Buenos Aires
Buenos Aires, Argentina
Precio:
Entrada Libre, Se servirá comida después del registro.
Who should come:
Developers and managers from Buenos Aires and surrounding cities who are working with or are interested in working with cloud computing technologies.
Agenda:
3:00pm Registration & Networking, Food
3:30pm Welcome, what is cloudCamp.
3:45pm Lightning Talks (5 minutes each)
Sponsored Talks TBD
Community Talks TBD
4:15pm Unpanel
4:45pm Organize the Unconference Sessions
5:00pm Unconference Session 1
5:45pm Food break and Networking
6:15pm Unconference Session 2
7:00pm Wrap-up Session
7:15pm Go out for drinks! (TBD)
Vean otras CloudCamp que se han organizado:
http://www.cloudcamp.org/
Uds. pueden organizar una en su ciudad, y anunciarla ahí.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Hoy, revisando correo, me encuentro con la noticia: Marcelo Duschkin nos dejó el viernes pasado, 9 de Abril de 2010.
Algunos de Uds. lo habrán conocido. Su actividad desde hace más de treinta años eran los sistema digitales. Y también desde hace años, se volcó a la educación de todo lo que sabía, a compartir con todos lo que iba armando, por ejemplo, en robótica educativa. Lo conocí siendo ambos instructores en el Club de Programadores.
En los últimos años, luchó con una larga enfermedad, con recuperaciones y caídas. Hace unos meses, se quejaba en una lista de correo, que por los problemas de salud, no podía mantener mejor a sus páginas. Tal era su dedicación.
Alguna vez asistió a uno de mis cursos. Quería aprender más de Java, para poder colaborar mejor con uno de sus proyectos preferidos, XLogo. Y practicó, investigó, recuerdo que llegó con dudas sobre el manejo del puerto de comunicaciones, para sus robots, y los fue resolviendo.
Hace ya un tiempo que no lo veía. Pero siempre lo leía en las listas, colaborando, respondiendo dudas, con alguna lagunas en el tiempo, fruto de sus recaidas.
Yo había escrito sobre su trabajo, hace tiempo:
Mi primer robot, con XLogo y Rasti
Vean lo que entonces mostraba del trabajo de Marcelo:
Otros posts comentando la desaparición de Marcelo:
Se nos fue Marcelo Duschkin
Querido Marcelo
Siempre amable, dispuesto a conversar con todos, hoy les deja a su familia, esposa, hijos y amigos, su obra privada. Para los demás, nos fue preparando, poco a poco, toda su obra pública. Visiten:
http://www.miprimerrobot.com.ar
"Mi Primer Robot" está destinado a hacer posible en forma sencilla y económica, la experimentación en Robótica en la escuela y el hogar
http://www.sudram.com.ar
http://radioculturalibre.com.ar (su programa de radio)
Se nos fue Marcelo, alguien que seguramente, pasa el test.
Angel
No para la actividad de reuniones virtuales, desconferencias VAN, organizadas por la comunidad de ALT.NET Hispano. Leo el anuncio de una nueva VAN para este sábado 10 de Abril, a la hora 18 GMT (las 3 de la tarde por aquí en Buenos Aires) en el blog de Jorge Gamba (@jorgegamba):
Control de Versiones con Git
Ahí leo:
Los que estamos inmersos en el mundo del desarrollo de software sabemos lo indispensable que es tener un sistema de control de versiones confiable y eficiente para administrar el código fuente y recursos relacionados de nuestros proyectos. Desafiando la hegemonía de Subversion, últimamente hay bastante ruido en torno a Git que gana cada vez más popularidad, tanto que muchos y reconocidos proyectos se están moviendo a este sistema, el cual resulta muy apropiado para administrar el código de aplicaciones con gran cantidad de código e intervienen numerosas personas.
Alguien que tiene bastante experiencia con Git es Mauricio Scheefer (@mausch), por supuesto, él se dedica al desarrollo de software y también participa activamente en varios proyectos OSS, entre estos es de mención especial su contribución al proyecto Castle, precisamente hace poco Mauricio fue el principal responsable de la labor de migración a Git de este conjunto de proyectos tan importante. Tendremos entonces su colaboración con la exposición, no solo de los conceptos y tareas básicas, sino que seguramente veremos varios casos prácticos y él podrá contestar las inquietudes que tengamos al respecto del tema. Además, se ha abierto una entrada en nuestra lista de correo para atender inquietudes previas a la VAN, pueden participar aquí.
Hay nuevas ideas en repositorios de código, los distribuidos. Ejemplos destagados Mercurial y Git.
Agrego mis enlaces:
http://delicious.com/ajlopez/git
http://delicious.com/ajlopez/svn
http://delicious.com/ajlopez/csv
http://delicious.com/ajlopez/mercurial
Por ejemplo:
An Intro to Distributed Version Control | I am Zef Distributed Version Control is here to stay, baby - Joel on Software Cocoa Is My Girlfriend » Why version control is important for solo developers Cocoa Is My Girlfriend » Why version control is important for solo developers If Version Control Systems were Airlines | The Changelog AlBlue's Weblog: Git for Eclipse users Terminal, Git, and GitHub for the Rest of Us: Screencast | Nettuts+ Git for Subversion users, Part 1: Getting started Easy version control with git El bueno de Jorge Gamba nos recuerda:
Hay que aclarar que no se requiere ningún tipo de registro, simplemente acudir el día y la hora indicados a la dirección Web http://snipr.com/virtualaltnet, eso sí, deberán tener instalado el programa cliente de Live Meeting; hay más instrucciones sobre cómo hacer esto y otras indicaciones en la página wiki Descripción de Reuniones.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Esta semana pasada, Hari Hariri (@hhariri) escribió un interesante post:
Loved the show but I have toget back to the real world now
Hariri comenta sobre su experiencia en dos conferencias, en dos charlas que dio, para desarrolladores. Escribió:
As usual, to set the context, I asked a series of questions regarding unit tests:
“How many of you know what a Unit Test is” – 80% put up their hand.
“How many of you do Unit Testing?” – 10% put up their hand.
“How many of you think Unit Testing is valuable?” – 80% put up their hand
La primera charla fue enfrente de desarrolladores PHP. Pienso que los desarrolladores PHP todavía trabajan un poco diferente de los demás desarrolladores, pero esto en base a mis recuerdos de programación PHP intensiva. Puede ser que hoy tengan más herramientas a su alcance para su trabajo. Pero la segunda chara de Hari fue en frente de 200 personas interesados en arquitectura de software.
Recientemente, en una charla interna en una compañía de software, @MartinSalias hizo preguntas parecidas, y el resultado fue similar al de Hariri. No tomé notas, pero en una de mis charlas los resultados tenían el mismo bias: a una gran mayoría les gusta y algo conocen de mejores prácticas, disciplinas XP, etc… Pero pocos las implementan.
Entonces, ¿dónde está el problema? Hariri escribe:
“A is good. I like A. I should do A. But I won’t do A”.
People identify themselves with the issues we talk about. They see the value writing automated tests and complying with design principles adds. They get excited, yet they don’t do it. Why?
I usually ask this question too, and the typical responses are:
1. Tight Schedules.
2. Decrease in Productivity. Drag and Drop is more productive
3. Customers want deliverables. Tests are not deliverables
and my all time favorite
4. “I’m paid to write code, not tests”.
Bueno, hay muchas razones, cada desarrollador de software y su equipo pueden tener varias razones para no aplicar TDD, pruebas automáticas, revisión de código, programación de a pares, etc…
Tomemos un tópico, para ser más concretos y avanzar en el tema: TDD. ¿Por qué la gente no está usando más TDD en su trabajo diario? Mis razones candidatas:
- Conocen qué es TDD, pero nunca lo practicaron o practicaron poco, y tienen muchas dudas
- Si trabajan en un equipo, no todos los miembros del equipo están al tanto de lo que es TDD, y la persona que conoce algo no tiene la experiencia como para transmitirla a los demás.
(claro, también puede ser por la impresión de que lleva más tiempo (posición discutible) y que el “management” lo ve como un trabajo adicional sin valor)
¿Qué necesitan? Pienso que necesitan estos puntos:
- Conocer el “rationale”, el fundamento que sustenta a TDD (en general, se aprende en charlas, conferencias, libros…)
- Practicar TDD
- Tener un mentor para preguntar dudas, resolver problemas, revisar patrones
Cuando tuve que realmente comenzar a aprehender (más que aprender) TDD, el segundo punto lo resolví aplicándolo en mis proyectos personales. Y el tercer punto, lo encaré preguntando a otros programadores, usando foros web (poco), leyendo ejemplos, más libros, y principalmente, revisando código abierto; todavía sigo trabajando en los tres puntos. Pero veo que no todos los desarrolladores de software tienen el tiempo disponible para mejorar en sus habilidades, más allá del trabajo diario. Yo promuevo el “auto-aprendizaje”, pero la realidad es que no todos los desarrlladores tienen el tiempo (y la voluntad) de tomar ese camino. Y es un camino no exento de riesgos: al auto-aprender, podemos aprender mal algo sin tener una retroalimentación; sin tener un mentor, es dificultoso aprender temas que abarcan tantos puntos y detalles, como TDD.
Estoy trabajando en equipo en el Proyecto Hogwarts para solver esos puntos: darle a la gente el soporte para aprender TDD, IoC, principios SOLID, y más. No sólo con ejemplos, sino también con fundamentos. No sólo teoría, sino también práctica. No solo práctica, sino evaluación, soporte posterior, detección de puntos débiles, acciones correctivas. En el caso de este proyecto, el cliente final ya compró la idea de las mejores práctica: no tenemos que convencer a un “management” escéptico. Estamos todavía en una etapa temprana del proyecto: los primeros entregables estén en beta, distribuidos internamente. Siguiendo lo ágil, producimos algo y lo entregamos, para conseguir revisión, en vez de esperar a tener todo armado. Espero que cuando el proyecto gane más momento, más material y también la experiencia ganada en el proceso, será publicada y compartida con la comunidad.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Quisiera describir brevemente una propuesta sobre cómo usar Twitter en aplicaciones. Me imagino que esta idea no es nueva, y que debe haber algo parecido implementado en algún lugar de la Twittoesfera. Mi punto a demostrar es que se puede implementar algo simple y extensible.
Supongamos que queremos operar en un mercado virtual. Actualmente, tenemos que ir a un sitio web, ingresar nuestra oferta, esperar respuestas y contraofertas. Un método alternativo podría ser usar una cuenta de Twitter para enviar mensajes con ofertas.
Algo como:
Cualquier otra aplicación (no necesariamente una sola) puede leer el feed de @ajmarket y procesar los mensajes: responder, hacer una contraoferta, publicarla en un website, hacer análisis de mercado, etc.
Propongo como formato de mensaje:
Si necesitamos enviar más información, podemos agregar enlaces a los datos (posiblemente en formato JSON, podría ser XML pero prefiero JSON):
Cada aplicación debería entonces publicar sus verbos y argumentos válidos. La aplicación que lee los mensajes (o que escribe las respuestas o nuevos mensajes para otras aplicaciones) puede estar distribuida, no necesita tener un punto de entrada, una URL. El punto de entrada y salidad de mensajes es la cuenta de Twitter. Me parece un punto de entrada más flexible.
Imagino que podemos construir cualquier tipo de aplicación que se base en el envío y recepción de mensajes.
Podría ir más allá: cada aplicación con cuenta de twitter puede ser visto como un agente. Si necesitamos planear un viaje, o encontrar información sobre un tema, podemos derivar el problema a una aplicación “inteligente” que esté escuchando en Twitter, y que tenga conversaciones con otros agentes de Twitter para resolver su problema.
La aplicación que se esté ejecutando puede estar en Azure, Amazon, o en nuestro propio centro de proceso. Podemos usar otro transporte de mensajes, Yammer en vez de Twitter, o cualquier cosa similar en el futuro.
En resumen: Usar Twitter como un canal pubsub, con un simple pero flexible formato de mensaje.
Debe haber algo así ahí afuera.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez