Posteado por: israelantezana | 21 - octubre - 2009

Presentación de Agiles2009, Brasil

Anuncios
Posteado por: israelantezana | 12 - octubre - 2009

Mi participación en Agiles2009 – Florianopolis, Brasil

Fué una muy grata experiencia la que viví en Florianopolis durante Agiles2009 la semana pasada. Hubo muchas y muy buenas sesiones en paralelo que hacían difícil elegir a cual asistir, invitados internacionales de alto nivel cuyas sesiones fueron excelentes, muy buena asistencia y entusiasmo en general.  No pude asistir a los cursos previos a la conferencia pero escuché muy buenos comentarios e impresiones de algunas personas que participaron de los mismos.

me at agiles2009

Aquí va un resumen de lo que me pasó los días de la conferencia.

El primer día de la conferencia,  luego de la inauguración, se partió con el keynote de Brian Marick que personalmente me gustó mucho, ya que se alineaba mucho con el tema de mi charla, Brian destacó la necesidad de prácticas técnicas para el desarrollo ágil, fué una charla amena y con mucho sentido del humor. Luego, asistí a las sessiones de Naresh Jain sobre distributed agile y a la de Martín Salías ambas de las cuales estuvieron muy interesantes.

Luego del almuerzo, me tocó el turno con mi presentación, que tuvo buena asistencia, la mayoría brasileros, quedé contento con la misma ya que hubo buena participación de la audiencia durante la presentación y más que todo al finalizar la charla.  Luego, pude sentarme junto a Brian Marick mientras él programaba una aplicación, ya que desde el keynote el había anunciado que era lo que haría el resto de la conferencia y que toda persona que desee podía unirsele. Fue algo muy interesante, se puede percibir facilmente el nivel de experticia y práctica que Marick tiene para programar, además él iba explicando lo que hacía a medida que programaba, me gusto mucho poder conversar con él mientras programaba.

Diego_Brian_IsraelEn la foto Diego Fontdevila, Brian Marick y yo antes de la sesión de programación

El primer día finalizó con el keynote de Roy Singham presidente de ThoughtWorks, que empezó de una manera fuerte e incisiva con sus pensamientos, muchos de ellos orientados a enfatizar el valor que las personas representan para el desarrollo de software y el énfasis en fuertes prácticas técnicas para su empresa. Su tono incisivo y firme mantuvo atenta a toda la audiencia durante la presentación.

El segundo día sin notarlo explicitamente, asistí  a varias sesiones que tenían que ver con arte y desarrollo de software, primero la sesión de agilidad en la producción de video juegos de Pauline Morrison. Luego la sesión de Juan Gabardini y Diego Fontdevila en la que describieron una experiencia real en que ambos trabajaron  inspiradose en el libro Artful Making, fué una charla muy amena e interesante. Luego, la charla de Joshua Kerievsky que utilizó el arte, explicitamente la pintura,  como metáfora para explicar su perspectiva del desarrollo de software y la agilidad. Las ideas y las similutudes que Joshua explicaba hacían su presentación muy atractiva y la audiencia se mantuvo bastante atenta toda la charla. Una frase de Josh: “An organization is a gallery. Paintings are the software systems and artists the ones that make them”. Luego, la charla de David Hussman, una charla en la que Dave con muy buen sentido del humor comentó algunos indicadores, y tips sobre coaching.

Practicamente para finalizar se realizó el panel de cierre con la participación de los invitados internacionales y moderada por Samuel, presidente de la conferencia. Se lanzaron interesantes preguntas y temas, que hizo que los panelistas expongan más ideas y opiniones sobre sus perspectivas del desarrollo de software ágil. Por lo interesante de la conversación el tiempo se fué muy rapido. Acto seguido se tuvo el keynote de cierre de Diane Larsen, quién comento los aspectos importantes de una retrspoectiva y lanzó varias preguntas enfocadas a una retrospeciva general de la conferencia, fueron preguntas que realmente hacian necesario que la audiencia reflexione sobre sus expectativas sobre la conferencia y pensar el nivel de satisfacción logrado para que al final se plasmen en post-it notes, que la audiencia dejó, a manera de retroalimentación para la conferencia del año que viene.

Definitivamente, entre asitencia a sesiones muy interesantes, muy buenas conversaciones con colegas fuera de la sesiones, además de los gratos momentos compartidos amigos con los que nos vimos desde la conferencia del año pasado y algunos nuevos amigos, el tiempo pasó muy rápido, y la conferecia terminó dejando muchisimos buenos recuerdos y vivencias.

Posteado por: israelantezana | 11 - agosto - 2009

¿Te sientes orgulloso del código que escribes?

Este es el título de la presentación que realizaré en Agiles2009 en Florianopolis – Brazil. Aquí va una descripción de la charla:

I am a speaker at Agiles2009

Los procesos ágiles están orientados a las personas y destacan que ellas son el elemento primordial para el desarrollo de software, por lo que es muy importante que las personas se sientan satisfechas con su trabajo.

Escribir código de calidad es por demás satisfactorio para los desarrolladores de software, sin mencionar los beneficios que aporta para el éxito comercial del software. Pero, ¿pueden los procesos ágiles ayudarnos a producir código de calidad del cual sentirnos orgullos?.

En esta presentación se describirán varias prácticas ágiles que aportan a producir código de calidad. Algunos ejemplos de prácticas que se discutirán son: La programación dirigida por pruebas con la que podemos desarrollar un sistema que sabe cómo se supone que debe comportarse y que puede realizar pruebas de auto diagnóstico con tan solo presionar un botón, la refactorización para impedir que el código se deteriore y pueda continuar evolucionando, la programación por pares para realizar inspecciones y auditorias de código continuamente.

Posteado por: israelantezana | 28 - julio - 2009

¿Programar en ruby significa escribir menos código?

A manera de aprender/practicar Ruby acabo de terminar de implementar un pequeño juego que previamente implemente en Java. Tengo entonces dos implementaciones del mismo juego: Java y Ruby. Ambos implementan exactamente la misma funcionalidad. Tienen practicamente las mismas pruebas/specs. Y en ambas versiones intente producir código limpio fácil de entender y modificar.

Algo interesante, surge al comparar la cantidad de codigo de ambas implementaciones:

  Ruby Java % Diferencia
Nro. Líneas 746 1033 38.5%
Nro. Caracteres 21299 29694 39.4%

 

En un programa pequeño como este se ve una diferencia de alredor de 8000 caracteres y casi 40% más de código en la versión Java. Más interesante todavia es que hace tiempo mi amigo Dave Astels, llegó a una conclusión muy similar en su blog post que se puede ver aqui. Me pregunto si esto es solo coincidencia.

Posteado por: israelantezana | 1 - julio - 2009

Agiles 2009!

Agiles2009 Organizing committee

Estamos organizando agiles2009 a realizarse este año en Florianopolis(Brazil), varios disertantes internacionales reconocidos del área tales con Brian Marick, Diane Larsen, Naresh Jain, Matt Gelbwaks entre otros ya han confirmado su presencia. Actualmente se tiene abierta la llamada a presentaciones, así que tu también puedes participar no solo como asistente sino como presentador.

Esta segunda versión de la conferencia es organizada por profesionales entusiastas del tema, unidos por el objetivo de crear un espacio amplio de discusión sobre las metodologías ágiles y su adopción en América Latina. Sin duda será un evento de marcada importancia para la comunidad latinoamericana.

Pronto se abrirá el proceso de inscripción a la conferencia y a cursos previos a la misma, así que mantente atento.

Posteado por: israelantezana | 6 - mayo - 2009

¿Necesitamos disciplina para el desarrollo de software ágil?

¿Alguna vez has quedado cautivado  por la forma en que alguien realiza alguna actividad?, esto pensando no necesariamente en nuestra área sino en muchas otras, qué se yo, si admiras algún pintor, escultor, deportista, músico, empresario, etc.  ¿Te has puesto a pensar en por qué estas personas logran destacar en su actividad?.  Yo pienso que es por que les interesa y les gusta mucho su profesión (actividad) y la práctican con disciplina.

Así es, estoy seguro que el desarrollo de software ágil requiere de disciplina. Si alguien quiere una definicion para disciplina, esta es la primer definicion qué encontre y me gustó:  “Disciplina: Su sentido es amoldar el caracter y el comportamiento de un individio para conseguir una eficiencia máxima en alguna labor” (wikipedia). Además sé que si disfrutas  lo que haces, no ves el actuar de forma disciplinada como un esfuerzo la mayor parte del tiempo. A  un deportista no le importa entrenar todos los días, sin fallar, para lograr sus objetivos de mejorar por que le gusta lo que hace.

Por último, les dejo esta referencia de un video que habla sobre este mismo tema enfocado en nuestra área y añade algunas peculiaridades muy interesantes sobre la disciplina y la práctica para el desarrollo de software asemejadolo a las artes marciales, espero lo disfruten.

Posteado por: israelantezana | 24 - marzo - 2009

¿Te Lavas las manos antes de programar?

En su articulo “Profesionalismo y Desarrollo Dirigido por Pruebas”, Robert Martin toma el ejemplo de Ignaz Semmelweis, quien en 1847 logró reducir dramáticamente la tasa de mortalidad de una maternidad haciendo simplemente que los doctores se laven las manos antes de examinar a las mujeres embarazadas.  Semmelweis  se topó con resistencia que incluían quejas de que lavarse las manos antes de atender a cada mujer embarazada sería mucho trabajo y los doctores no tenían tiempo suficiente para eso.

Los desarrolladores que conocen o han escuchado hablar del desarrollo dirigido por pruebas,  TDD (Test Driven Development), pueden darse cuenta que esta técnica representa muchos beneficios para incrementar la calidad del software y por ende mejorar el nivel de profesionalismo del desarrollador.   ¿Te parece que puedes incrementar el nivel  de calidad de una aplicacion de software si más del 90% del código de producción se encuentra cubierto por pruebas automatizadas que puedes ejecutar en cualquier momento?. Si es así, esta comprobado que te das cuenta  de algunos de los beneficios de TDD. 

Sin embargo, es frecuente escuchar de muchos desarrolladores que dicen que escribir pruebas antes del código de producción puede ser mucho trabajo o tomar mucho tiempo. Ahí es donde la analogía de Robert Martin viene muy bien:  ¿ No te parece entonces importante lavarte las manos antes de programar?.  Claro que TDD no es una bala de plata y no tiene una implicación tan grande como lavarse las manos para los doctores, pero si tiene una connotación destacable en cuanto a tu responsabilidad y compromiso con tu profesión.  Si es que, como los doctores hace varios años,  aun muchos desarrolladores no usan TDD como parte habitual de su trabajo puedo citar una frase que la aplico con frecuencia:  “Algunas veces tienes que hacer lo que esta bién y no lo que hacen los demás”.

Posteado por: israelantezana | 22 - enero - 2009

¿Lo sabias?

Un video que me parece genial acerca de los cambios  constantes que vivimos a nivel mundial  y la evolucion acelerada de nuestros dias.

Posteado por: israelantezana | 3 - enero - 2009

¿Por qué tu código apesta?

Por: Dave Astels

Traducido por: Israel Antezana R. 
Del original en igles en: http://techblog.daveastels.com/2005/01/12/why-your-code-sucks/

Resumen

Si eres como la mayoría, e incluso posiblemente todos, los programadores (este humilde autor incluido) entonces tu código apesta. Quizás no todo tu código, y talvez no todo el tiempo, pero si ciertamente parte de tu código, en algún momento.  

Tu código apesta si no funciona.

¿Tu código funciona? ¿Cómo lo sabes? ¿Puedes probarlo?

Si no tienes pruebas para tu código, este apesta. Y me refiero a pruebas de programador compresibles, de granularidad fina (también conocidas como pruebas de unidad), como también a pruebas de nivel más alto funcional y de integración. Pruebas que están automatizadas. Pruebas que se ejecutan de forma rutinaria. Pruebas de programador que se ejecutan después de que se realiza cualquier modificación al código.

Sin pruebas adecuadas (tanto en término de cantidad  como de calidad) simplemente no puedes tener confidencia de que tu código funciona como se requiere. E incluso si tienes confianza en tu trabajo… ¿Por qué cualquier otro lo debería hacer? ¿Qué sobre las personas que trabajarán con el código después? ¿Cómo saben si el código aún funciona luego de que realizan cambios?

Tu código apesta si no es comprobable

Bien, entonces decides añadir pruebas a tu código. Típicamente esto no es tan fácil. Es muy posible que tu código no haya sido diseñado y/o implementado para ser fácil de probar. Eso significa que tendrás que realizar cambios en él para hacerlo más fácil de probar… sin romper ninguna de sus partes (en la actualidad usualmente esto se conoce como refactorización). Pero ¿cómo puedes rápida y fácilmente decir si has roto algo sin ese conjunto de pruebas de granularidad fina? Esto no es fácil.

Es más difícil de lo que crees. Si decides escribir las pruebas para todo tu código después de que escribes el código, tienes que realizar el esfuerzo adicional de tratar y diseñar/escribir el código para que pueda ser probado.

Mantener un nivel adecuado de pruebas cuando escribes las pruebas después del código que estás probando toma tiempo y planificación. Y si tienes que realizar trabajo adicional para hacer que tu código pueda ser probado…bueno…eso apesta.

Escribir pruebas antes de que escribas el código significa que el código es comprobable por definición. Si trabajas en una prueba a la vez, cosechas aún mayor beneficio, ya que cada prueba solo requiere cambios incrementales al código que sabes que es sólido.

Tu código apesta si es difícil de leer.

El código debería ser fácil de leer. El código debería ser conveniente para leer, no conveniente para escribir, Steve McConnell realizó esta afirmación en su clase magistral en SD West’04.

Varios aspectos están involucrados aquí. Elegir buenos nombres que son auto-explicativos es un buen lugar para empezar. Concéntrate en buscar soluciones simples, incluso si éstas son más prolijas o ineficientes.  No sabremos si la ineficiencia es un problema hasta que realicemos un análisis de rendimiento, luego en el proyecto, en una situación real de producción.

Elige convenciones de formato y estilo lo más pronto posible en el proyecto y apégate a ellas. Exige que todos sigan estas convenciones. Esto será más fácil de realizar si todos participan de las decisiones sobre las convenciones y se apropian de ellas. Esto hará que el código sea uniforme y por lo tanto más fácil de leer.

Y libérate de cualquier y toda duplicación. Más sobre esto después.

Tu código apesta si no es comprensible

Esto está relacionado al punto anterior. El código puede ser fácil de leer, pero no fácil de comprender. Tal vez se lea bien pero es engañoso. Quizás te tomaste el tiempo necesario para elegir un buen nombre para esa variable, pero la forma en la que es usada y lo que significa ha cambiado, pero el nombre no. Eso es peor que usar un nombre en clave… por lo menos en el último caso, el lector conoce el nombre y este es significativo. Si el nombre es engañoso, el lector puede hacer suposiciones infundadas sobre lo que esta pasando en el código, llevando esto a mal entendidos, y eventualmente a errores.

Tu código apesta si dogmáticamente se adapta a un framework de moda al costo de seguir buenas prácticas de diseño/implementación

Por ejemplo, Bob Martin recientemente tocó el tema de usar dogmáticamente atributos privados y getters/setters para una estructura de datos simple (ejm.: un DTO). Si un atributo es de lectura y escritura de forma transparentemente, ¿por que no simplemente convertirlo en un atributo público?. En la mayoría de los lenguajes puedes hacer eso. De acuerdo, en algunos no puedes. Por ejemplo, tradicionalmente en Smalltalk todos los atributos son privados y todos los métodos son públicos.

En general es algo bueno si podemos deshacernos, o evitar escribir, algún código. Usar un framework pesado generalmente requiere que tengas que escribir cierta cantidad significativa de código que no tiene valor para el negocio.

Existe una variedad de frameworks livianos para Java que son una respuesta a los frameworks pesados (por ejm.: EJB) que se han convertido en temas de dogma últimamente. O’Reilly tiene un nuevo libro sobre este tema, escrito por Bruce Tate.

Cuando tomas decisiones sobre frameworks, debes considerar si un framework liviano puede hacer el trabajo requerido. Usar algo como Hibernate, Prevayler, Spring, PicoContainer, NakedObjects, etc. puede realmente ganar en muchas situaciones. Nunca adoptes a ciegas un framework pesado solo por que es el último grito de la moda. Asimismo, no adoptes a ciegas un framework liviano solo por usar alguno. Trata de siempre dar la debida consideración a tus decisiones.

Tu código apesta si tiene duplicación

La duplicación es probablemente lo más importante de eliminar de tu código.

La duplicación puede tener varias formas:

textual

Esta es la más simple y usualmente la más fácil de encontrar. Esto es cuando tienes secciones de código que son idénticas o muy parecidas. Esto usualmente es resultado de programación copy & paste. Se puede usar muchas técnicas para eliminar esta duplicación, por ejemplo: extraer los métodos y reusarlos, convertir un método en un template method, extraerlo a una superclase, y proveer las variaciones en subclases, y otras refactorizaciones básicas. Puedes ver “Refactoring” de Fowler para más detalle al respecto.

funcional

Este es un caso especial de duplicación textual y está presente cuando tiene múltiples funciones/métodos que sirven para el mismo propósito. Esto usualmente se ve en proyectos que se reparten en grupos y que no se comunican lo suficiente. Esto puede ser el resultado de copy&paste, o puede ser el resultado de desconocer librerías o código existente. Políticas y prácticas que  alientan y promueven el conocimiento de todo el código base y todas las librerías y frameworks que se están usando pueden ayudar a evitar la duplicación funcional.

temporal

Esto es un poco extraño, más obscuro, y no muy fácil de encontrar. Tienes duplicación temporal cuando se realiza el mismo trabajo repetidamente cuando no se necesita. Este no es un problema de la misma forma que las dos formas anteriores de duplicación puesto que en esta no se involucra tener código extra. Se puede convertir en un problema en la medida que el sistema crece y el trabajo repetido empieza a tomar mucho tiempo. Varias técnicas se pueden usar para manejar este problema.

De los tres tipos que he identificado antes, la duplicación textual es la peor. Es la que más fácilmente te puede morder en tanto el sistema crece. Tiene el mal hábito de ser viral: cuando ves código duplicado en el sistema, puede tentarte pensar “oh, bueno, no es un problema si tan solo copio este fragmento de código también. Todos los demás lo hacen”. Es como el tema de la ventana rota del que  Dave Thomas & Andy Hunt hablan al respecto. Si  no te mantienes atento a  las pequeñas cosas tan pronto como aparecen, pronto todo se irá al caño.

Conclusión

Entonces, tienes buenas  probabilidades de que tu código apeste.

¿Que vas a hacer al respecto? Bueno, primero tienes que reconocer el hecho (y tengo la esperanza de que este artículo haya ayudado con eso) y admitir que existe un problema.

Luego, tienes una opción. Puedes elegir hacer algo al respecto. Puedes aprender nuevas formas de trabajar…métodos que te ayuden a escribir mejor código. Esto es grandioso. Si solo un programador hace esto, estaré feliz.

Tu otra opción es no hacer nada al respecto, y continuar escribiendo el código de la misma manera que siempre lo has hecho.

Es tu elección. Elige sabiamente.


 
Posteado por: israelantezana | 31 - diciembre - 2008

Agiles 2008. Un gran suceso de este año

Sin duda  un evento de mucha importancia para los agiles de latinoamerica fué Agiles2008 realizado en buenos aires-argentina en octubre.  El evento tuvo una participación bastante importante de la comunidad agil latinoamericana que a partir de este año se consolida. Realmente fué un evento exitoso con más de 400 participantes, invitados internacionales de reconocido prestigio, y mucho entusiasmo que se contagió entre los organizadores y participantes.  Se tiene disponible un resumen de los resultados del evento aqui.

Equipo organizador de agiles2008

Equipo organizador de agiles2008

Fue fascinante haber podido asistir y participar como organizador del evento.  Quedan varios puntos de contacto y fortalecimiento de la comunidad agil latinoamericana, uno de los principales puntos de encuentro es el sitio www.agiles.org

También se tienen disponibles el material de las presentaciones  en: http://www.agiles2008.org/es/programaJornadas.php

Older Posts »

Categorías