Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Developing software since 2001.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Is it risky? do you need advise?
  • May I pair with you to write better code?

Events

Upcoming public training courses:

  1. [Online - en Español] 25 y 26 de Junio
    Test Doubles con JavaScript - Online
  2. [in English] July 7, 8 & 9
    TDD (open to the public) - Tenerife, Canary Islands
  3. [en Español] 14 y 15 Julio
    TDD (en abierto) - Gran Canaria, Canary Islands
  4. [in English] October 13, 14 & 15
    TDD (open to the public) - London, UK
  5. [en Español] 29, 30 y 31 de Octubre.
    TDD (en abierto) - Madrid, Spain

Conferences:

  1. I'll be at SocratesUK 2014
  2. I'll be at the London Test Gathering Workshops.

Archive for November, 2011



RS: Pomodoros

reunion de retrospectiva

Esta retrospectiva vale por las dos últimas semanas. Lo que todo el mundo ha visto fácilmente y en consenso es que nos hace falta respetar más los pomodoros, de ahí el título de hoy.

Estamos contentos porque se van notando cambios muy positivos. Los repasamos juntos:

  • Refactor sólo donde duele: no tocamos código que funciona, si no tiene bugs (que sepamos) y no hay que ampliar su funcionalidad.
  • Refactorizamos siempre para alcanzar "the low hanging fruit": Extract method y Extract constant nos dan beneficio rápido sin apenas coste.
  • No nos metemos con tareas que no son de desarrollo funcional salvo que hayamos hecho un estudio claro y concreto de ventajas y desventajas: Mucho cuidado con las tareas de infraestructura u otras que no sean directamente entregar valor a corto plazo.
  • Code reviews: Sabemos que no pueden durar mas de 15 minutos al día asi que somos selectivos para combinar con pair programming con el objetivo de la propiedad colectiva del código. Están empezando a dar fruto. Ya sabemos que hay que mirar si el código que queremos hacer, lo ha hecho alguien ya. Reutilizar el esfuerzo de los demas.
  • Pair programming: nos damos cuenta cuándo hay que unirse en pareja y también cuándo hay que separarse. A veces nos equivocamos en los dos lados, por no hacerla y por hacerla.
  • El bus factor es malo, sabemos que lo tenemos que ir reduciendo poco a poco.
  • Un equipo XP entrega valor al negocio constantemente, sin parar.
  • El pomodoro nos lo tenemos que tomar todos más en serio. Demasiada interrupción, aunque no para todos, para los que tienen mayor bus factor.
  • El daily meeting se hace a su hora, esté quien esté. Ya casi siempre respetamos el tiempo y conseguimos contar lo importante.
  • Los meetings fuera del daily, son tóxicos. Mejor dejarlos para el viernes despues de la comida porque nos consumen mucho tiempo y es dificil valorar lo que aportan.
  • Nadie escribe código basura a conciencia. Ninguna prisa justifica escribir un código mal sabiendolo hacer bien. Si no se sabe hacer mejor, vale, de eso me voy encargando yo, poco a poco.
  • No tenemos tiempo para que todo el mundo aprenda todo lo que nos gustaria que supiera durante las horas de trabajo. Cada uno ha elegido ya un libro de la lista y la empresa ha comprado un Kindle además de libros en papel para continuar con la formación que ya tenemos en el día a día. Los viernes hay exposición aunque hoy nos hayamos comido el tiempo de Jaime con la restrospectiva. Sorry!

This is the second part of the "Replace conditional with polymorphism" screencast, where I kept using the Command and Template Method design patterns. This time we see how a base controller class emerges from refactoring.

Nota: En los tests del controller que se muestran en el video hay un inconveniente y es que al usar " hardcoded json" como dato de entrada, puede haber bugs en el propio test. En una version posterior a este screencast, usamos el Translator para generar el json por nosotros en estos tests, ya que hay otro TestCase para los casos de serializacion-deserializacion. Es decir, hubo un refactor de tests.

Lectura adicional recomendada: Pensando en Generics

¿Te gustaría patrocinar el próximo screencast? Just let me know! :-)

First refactoring screencast

Note: Although this screencast is narrated in Spanish, the code is in English. Some parts of the code are legacy. There are more notes about this below. Although the code is C#, everything is valid for Java, including the use of Generics.

Me complace presentar el primero de una serie de screencasts narrados sobre refactoring. La idea surgió para ayudar en la formación de mi equipo de desarrollo pero quería tambien compartirlo con todo el mundo.

En este primer video vemos los patrones de diseño "Template Method", "Factory" y "Command", aplicando el refactoring "Replace conditional with polymorphism". Además veremos cómo usar "Generics" de manera emergente.

Aviso: Algunas partes del código eran heredadas. No prestes atención a la implementación del JsonTranslator ya que en este primer video es incorrecta. En el segundo vídeo veremos cómo en su lugar utilizamos DataContractJsonSerializer.
Las clases DTO tienen el sufijo puesto en el nombre para evitar colisiones con objetos que ya existían, pero no significa que sea una buena practica, es sólo convivencia temporal con código legado.

Desde ahora abro la posibilidad de que cualquier empresa que desarrolle software pueda patrocinar estos screencasts. Habría publicidad de la empresa al comienzo del screencast y en algún punto intermedio (una imagen con el logo). Si tu empresa tìene interes, no dudes en contactar conmigo.