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?
  • Do you need a technical consultant?
  • May I pair with you to write better code?

Events

Upcoming training courses:

  1. TDD - [en Español] - 6 y 7 Octubre
    Gran Canaria
  2. TDD - [in English] - October 20, 21 & 22
    London, UK
  3. TDD - [en Español] - 29, 30 y 31 de Octubre.
    Madrid, Spain

Conferences:

  1. I'll be at the Agile Testing Days 2014
  2. I'll be at the London Test Gathering Workshops.

Archive for the ‘iExpertos’ Category



¿Puedo ayudarte?

Además de ser desarrollador de software, soy consultor y mentor. Los tres roles me gustan siempre que sean medios que me permitan ayudar a los demás. Ser de utilidad a alguien. Cuando tengo que escribir un software que no va a servir a nadie, no encuentro la motivación para ello (de ahí que cada día piense más "lean" porque no me gusta trabajar en cosas que no se usan). Cuando tengo que impartir un curso a alumnos que asisten obligados, no me siento motivado a ello. Cuando tengo que ser consultor en un cliente que no quiere escuchar sugerencias ni propuestas de mejora, no me motiva serlo.
Pero en todos los demás casos estoy encantado de ser desarrollador, consultor y mentor, por separado o combinando los roles. Dependiendo de las necesidades de mi cliente.

Desde hace más de un año, SaludOnNet ha sido mi principal cliente y lo siento como mi equipo de trabajo. El reto era y es muy grande porque la empresa está creciendo muchísimo y el producto es muy poderoso y lider en el sector, con una competencia feroz. Como agente de cambio en la organización he aprendido muchísimo. Afortunadamente hemos mejorado mucho en este año y siento que cada vez se me necesita menos. Esto quiere decir que estamos haciendo bien el trabajo, aunque tambien hemos cometido errores. Yo he cometido algunos que no repetiré.   La misión de un consultor externo consiste en hacer que el equipo mejore sin que se genere una dependencia permantente. Es decir, mi objetivo es ser prescindible cuanto antes, tal que en el largo plazo solo tienen que contar conmigo para momentos puntuales. A partir de enero ire dedicando menos tiempo progresivamente a mi equipo de SaludOnNet para que otros equipos y empresas puedan contar conmigo.
En este periodo también he tenido la suerte de formar parte del equipo de Alea Soluciones, el cual ya por suerte no me necesita, porque son totalmente autosuficientes y el tamaño es más manejable (gracias @eferro!).

Recientemente me ha sorprendido mucho que amigos de la comunidad me dijesen que desconocían que podían contar con mi ayuda para sus equipos. ¡Claro que se puede, ese es mi trabajo!

En España la mentalidad de contratar al consultor externo no está muy consolidada. Cuando a las empresas les gusta cómo trabajas quieren que te quedes en plantilla con ellos de forma exclusiva todo el tiempo posible. Por otro lado cuando no te conocen les resulta difícil entender por qué, en sólo unas semanas de trabajo, les puedes ayudar a dar un gran salto en el camino de la mejora contínua. Pero creo que las cosas están cambiando y se está empezando a confiar más en expertos que sólo están de paso.

¿En qué puedo ayudar a tu empresa o a vuestro equipo?

Cómo desarrollador y arquitecto

  1.  En identificar y solucionar problemas de infraestructura y arquitectura:
    En algunos equipos la arquitectura brilla por su ausencia y sin embargo es esencial para abordar cuestiones como la tolerancia a fallos, la trazabilidad, la escalabilidad, la internacionalización, la seguridad, la reutilización, etc... Puedo ayudar en el diseño de la arquitectura o en mejoras de la arquitectura existente.
  2. En mejorar el proceso y las metodologías de desarrollo. Desde la toma de requisitos en las primeras conversaciones con el cliente hasta las puestas en producción. Revisamos y trabajamos juntos en el ciclo completo de desarrollo aplicando métodos ágiles y lean. A la vez que aplicamos BDD hacemos pair programming para que el conocimiento se quede en el equipo. Practicamos eXtreme Programming adaptado al contexto del equipo. Hacemos código limpio y mantenible en equipo.
  3. En solucionar problemas técnicos varios, como por ejemplo refactor de código legado o nuevos diseño.
  4. En resumen, tanto para ayudar técnicamente en el arranque de los proyectos como para desatascar los que llevan tiempo en marcha.
Tarifa como desarrollador/arquitecto para 2013: 50€/hora. (la tarifas podrían cambiar)


Cómo consultor

Mediante observación y sentido común, el trabajo del consultor consiste en ayudar a que su cliente vea lo que en realidad es evidente y sin embargo, pasa desapercibido.
El día a día de las empresas absorbe a los individuos de una manera que ya no consiguen ver cuál es la raíz de sus problemas o incluso darse cuenta de cuáles son sus problemas. Unos días de análisis y observación por parte de un agente externo, no condicionado por la rutina de la empresa, da como resultado un informe que incluye acciones de mejora a aplicar en el corto y medio plazo. En cierta forma es una auditoría global que tiene el objetivo de idenfiticar problemas y proponer soluciones a los mismos.
Mi propuesta es pasar cuatro días trabajando en vuestras oficinas, manteniendo contacto con todas las capas de la empresa. Necesitaré tener pequeñas reuniones con los diferentes actores que intervienen en vuestros proyectos/productos y en ocasiones incluso, sentarme a trabajar con los desarrolladores para analizar y auditar también el trabajo técnico.
A veces también aplicaré mi experiencia y conocimientos de coaching (reconociendo que no soy coach profesional) para ayudar a personas dentro de las organizaciones con problemas puntuales.
El último de esos días determinamos juntos las acciones de mejora a aplicar y trazamos un plan de cambio para los siguientes tres meses. Durante esos meses mantenemos videoconferencias regularmente para reforzar el proceso de cambio y regreso a visitar la empresa dos o tres días cada mes. Cada vez paso menos tiempo por la empresa hasta que al final el cambio se produce sin necesidad de que yo ayude.

Tarifa como consultor para 2013: 90€/hora. (la tarifas podrían cambiar)

 

Cómo mentor/docente:

Llevo años impartiendo cursos técnicos. La docencia me encanta cuando no ocupa el 100% de mi actividad profesional y los asistentes vienen con ganas de aprender. En los últimos años me he especializado formando a desarrolladores en  Test Driven Development y Behavior Driven Development, revisando también otras prácticas de XP como la programación en pares.
Ofrezco cursos in-house dentro de las empresas y tambien cursos en abierto. En ambos casos, los trabajadores pueden utilizar la Fundación Tripartita para que hasta el 60% del precio del curso les sea subvencionado.
Si quieres  organizar un curso abierto en tu ciudad y crees que puedes convocar al menos a 10 asistentes, contactame y podrás beneficiarte de descuentos como organizador del evento.
Los cursos son de un dia y de dos días, depende del contenido. El temario y ejercicios son adaptados al contexto del grupo.

Tarifa como profesor para 2013: 190€/dia/asistente. La formación ocupa toda la jornada laboral.

Buscando la sinergia

En los últimos años he buscado colaboraciones con otros profesionales independientes para dar mejor cobertura a las empresas. La sinergia significa que 1+1 pueden ser 3 o 4, no sólo 2. Cada colaboración ha sido para mi un placer y una oportunidad de mejora y aprendizaje. Sin embargo no es fácil crear verdadera sinergia. Hay que estar muy alineados y sincronizados. Por ahora es mi asignatura pendiente como consultor autónomo, hacer verdadero equipo con otros consultores autónomos para proyectos concretos.
Estoy abierto totalmente a colaborar con otros profesionales siempre que exista un win-win, es decir que ganemos todos. Que la energía fluya en las dos direcciones y haya auténtica sinergia.
Es muy posible que pronto haga consultoría en pareja para aportar todavía mayor valor a las empresas y al mismo tiempo conseguir feedback rápido para mejorar.  Es decir que iremos dos consultores juntos a las empresas para complementarnos. Pero será una estrategia muy meditada y trabajada para estar seguro que nuestros clientes obtienen el máximo beneficio.
Si quieres que colaboremos, por favor contacta conmigo y hablemos por videoconferencia y en persona para ver si efectivamente compartimos la misma visión.
Desde luego mi visión no es pelear por los clientes sino hacer bien el trabajo para que lo demás venga por inercia.

Este 2013 se presenta repleto de retos y cambios, como la vida misma. Lo comienzo con la ilusión de poder contribuir al desarrollo de las personas y el bien común.

Gracias por contar conmigo :-)

Nota: Estos precios son para el mercado español. En otros paises de Europa manejo otras tarifas.

Hasta hace poco iExpertos era nuestra pequeña gran empresa de desarrollo de software y formación pero tal como anuncié en la #XPWeek, desde ahora pasa a ser un grupo de profesionales independientes. Ya no es una empresa como tal. Ahora es una marca y una alianza de profesionales con ideas comunes. No llega a ser comunidad porque somos pocos y no es previsible que seamos numerosos.

Las puertas están abiertas para aceptar a nuevos artesanos del software. El requisito es venir avalado por un miembro del grupo, el cual necesitará haber trabajado directamente con el candidato para poder confirmar de primera mano que su trabajo es excelente y su compromiso con el cliente es máximo.

La otra gran noticia es que Enrique Amodeo se une a iExpertos y vamos a ampliar nuestro catálogo de formación para que desde ya, recorra el país llevando su conocimiento a las empresas. Mis clientes irán siendo también clientes de Enrique si así lo desea.

En esta nueva etapa de iExpertos, yo viajaré menos y estaré más centrado en el proyecto en que me encuentro actualmente,  SaludOnNet, haciendo de "agile" mentor y lead developer, hasta que el equipo no necesite ningun mentor ni lead developer. Proximamente hablaré de esta nueva etapa :-)
Este año me pierdo la CAS2011 por motivos de trabajo pero con el reto de ir a la CAS2012 hablando de cómo nuestro proyecto en SaludOnNet pasó de cero a ágil en un año.

En breve espero anunciar más incorporaciones al grupo.

La web de iExpertos está pendiente de un cambio de look, ya que como bien se comenta, tiene un aspecto muy anticuado.

pyDoubles 1.3 released

What's new in pyDoubles 1.3?

  1. times statement is also available in spies, not only mocks
  2. stubs ignoring arguments can live together with stubs defined with arguments
  3. a new matcher: obj_with_fields

1: This sintax is now possible:

  1.  
  2. assert_that_method(spy_obj.some_method).was_called().times(2)
  3. or
  4. assert_that_method(spy_obj.some_method).was_called(
  5. ).with_args(SOME_VALUE).times(2)
  6.  

2: The most precise matching condition will be used:

  1.  
  2. when(spy_obj.some_method).then_return(SOME_VALUE)
  3. when(spy_obj.some_method).with_args(10
  4. ).then_return(OTHER_VALUE)
  5.  

The two lines above inside a test would mean the objet will return OTHER_VALUE when the input parameter will be 10 and SOME_VALUE in any other case. In previous releases, it would return SOME_VALUE always because stubs ignoring arguments use to override any other stub definition.

3: obj_with_fields matcher:

  1.  
  2. assert_that_method(spy_obj.some_method).was_called(
  3. ).with_args(obj_with_fields({'id': 20, 'name': 'Carlos'}))
  4.  

Which means the object passed in as a parameter, should have fields id and name with those values.

The stubbing spy

Do you really need a stub or do you better use a spy? Or is it a spy object with some stubbed specifications? Let's see some examples using pyDoubles:

You can choose a stub object to prepare the scenario and then, assert on the returned value of the system under test.

  1.  
  2. def test_using_a_stub(self):
  3. USERID = 20
  4. collaborator = stub(Collaborator())
  5. when(collaborator.one_arg_method).with_args(
  6. USERID).then_return(SUCCESS)
  7. sut = SystemUnderTests(collaborator)
  8.  
  9. result = sut.exercise_method()
  10.  
  11. assert_that(result, equal_to(OK))
  12.  

The test above says: "I don't really care what the SUT does internally as long as the returned value is the expected, but it might need help from a collaborator, so I set it up, just in case."
Note the "might" part of the sentence. It is not necessary to specify the possible arguments in the call to the collaborator. This tests is more robust and still serves the same:

  1.  
  2. def test_stub_simplification(self):
  3. collaborator = stub(Collaborator())
  4. when(collaborator.one_arg_method).then_return(SUCCESS)
  5. sut = SystemUnderTests(collaborator)
  6.  
  7. result = sut.exercise_method()
  8.  
  9. assert_that(result, equal_to(OK))
  10.  

Now, let's replace the stub with a spy object, assuming we don't need to specify any stub behavior:

  1.  
  2. def test_if_arguments_are_important_check_them_out(self):
  3. USERID = 20
  4. collaborator = spy(Collaborator())
  5. sut = SystemUnderTests(collaborator)
  6.  
  7. result = sut.exercise_method()
  8.  
  9. assert_that_method(collaborator.one_arg_method
  10. ).was_called().with_args(USERID)
  11. assert_that(result, equal_to(OK))
  12.  

The test above means: "The SUT needs to call its collaborator at least once in order to complete the operation. I want to make sure that happens apart from getting the expected value."
Depending on the problem, we can have just one test with the 2 asserts, or maybe 2 tests, with one assert each.

We didn't need to define any stub method, but what if we need it?:

  1.  
  2. def test_if_arguments_are_important_check_them_out(self):
  3. USERID = 20
  4. collaborator = spy(Collaborator())
  5. when(collaborator.one_arg_method).then_return(SUCCESS)
  6. sut = SystemUnderTests(collaborator)
  7.  
  8. result = sut.exercise_method()
  9.  
  10. assert_that_method(collaborator.one_arg_method
  11. ).was_called().with_args(USERID)
  12. assert_that(result, equal_to(OK))
  13.  

We don't tell the stub what arguments is going to receive. That is not important. The stub part is intended to prepare the scenario. The easier the scenario setup is, the better. We do assert on the arguments at the end of the execution.

Conclusion:
If calling the collaborator is a critical part of the action, use a spy and make sure arguments are passed in as they should. If you need to stub out a method in the spy object, do not specify the arguments in the stub definition. In the stub definition, just tell the framework the returned value and later on, assert on the arguments once the system under test execution has finished

Reason: If you specify arguments in the stub definition and also don't assert at the end, you need to debug the failing test to find out that maybe some argument wasn't passed in.
It is more efficient to let the doubles framework tell you what was wrong :-)

Ultra simplifying SOLID

This is just another way of viewing the SOLID design principles very very shortly :-)

  • S: Methods with no more than 5 lines of code,
    classes with no more than 3 public methods (average).
  • O: If it works, don't touch it (extend it)
  • L: Don't abuse inheritance (are they really the same thing?)
  • I: This one was placed here to form the word "solid"
    but it's the same as S.
  • D: Never create the instance of the dependency inside the object
    which uses it.

La metáfora del cirujano

Robert C. Martin lleva años diciendo que un desarrollador de software debería parecerse más a un médico que a un albañil. No se refiere a connotaciones relacionadas con el sueldo, el nivel de vida o la valoración social. Se refiere a la importancia del factor humano en estas profesiones.

El grado de profesionalidad es más determinante en una operación quirúrgica que en una etapa de una cadena de montaje de una fábrica. Pueden darse excepciones lógicamente pero digamos que te preocupas más de investigar quién te va a operar del corazón que de la persona que viene a pintarte la casa. En ningún momento estoy diciendo que una profesión sea más digna o importante que otra.

Estos días viendo el programa El Cirujano me gustó ver una pequeña parte del trabajo del Doctor Julio Mayol (@juliomayol) y me pareció una metáfora excelente aplicada al desarrollo de software profesional. Veamos algunos matices:









  • El cirujano no opera solo. Además de cooperar con anestesistas y enfermeros, hay algún otro cirujano que le ayuda --> Programa en pareja.
    Si la tarea requiere una concentración y una ejecución importantes, ¿por qué confiamos en que vamos a programarlo igual de bien solos?
  • Antes de abrir al paciente, se han hecho todos los estudios posibles para conocer el problema y sus soluciones --> Analiza y haz los spikes que sean necesarios. Conoce patrones de diseño, etc. Pero ten en cuenta que si el análisis se dilata demasiado, el paciente se muere.
  • En la sala de operaciones cuenta con todo el instrumental necesario y conoce perfectamente qué herramienta debe usar en cada caso --> Domina tus herramientas. Comprende tus herramientas.
  • Desconfía de su capacidad intelectual y es lo más metódico posible para evitar errores básicos. En la operación se ve cómo el Doctor Mayol recuenta las gasas que saca del cuerpo del paciente, para no olvidar ninguna dentro antes de cerrar --> Practica Test Driven Development.
  • Conoce las posibles consecuencias de cada actuación y está preparado para que las cosas vayan mal --> Equivocate pronto, readapta y sigue.
    Es la esencia de la agilidad, fallar rápido para corregir y mejorar.
  • El cirujano no admite que el paciente le diga cuánto puede tardar en terminar la cirugía ni cómo tiene que hacerlo --> Trabaja sin prisa pero sin pausa. Puedes manterner el foco con la técnica del pomodoro.
  • El cirujano sabe que por encima de todo está la salud de su paciente --> Lo más importante es el negocio de nuestro cliente.

Podríamos seguir con una extensa lista de parecidos "razonables" (yo los veo razonables). Cuando veo todas estas medidas, lo que pienso es en profesionalidad. Si queremos que se nos respete como a un profesional de la medicina, tenemos que ser tan profesionales como ellos. Mientras sigamos trabajando sin ser suficientemente rigurosos, seguiremos estando en el lado de la magia y las ñapas.
Steve McConnell dice en Code Complete que uno de los indicadores de profesionalidad es cuando dejas de creer en la magia y te preocupas por entender el comportamiento de tus herramientas. Recuerda que las máquinas de hoy en día siguen siendo deterministas.

La metáfora del cirujano deja de ser válida en muchos aspectos. Cuando cometemos un error básico y entregamos un producto defectuosos, generalmente nadie muere por ello. Esto es positivo y muchiiisimo menos estresante para nosotros. Aunque tambien hay excepciones.
Por el contrario, en nuestro sector los cambios son mucho más rápidos y teniendo en cuenta que aparecen herramientas nuevas todos los días y que a veces te ves forzado a cambiar con rapidez, no siempre puedes dominar la herramienta. Yo mismo me equivoqué hace unos meses con la elección de la plataforma cloud para nuestro proyecto. Sintoma de que hay que seguir madurando profesionalmente. Sin embargo lo importante es la progresión, la superación, la retrospectiva.

Aunque existen situaciones (sobre todo de mercado) que obstaculizan a veces nuestra profesionalidad, la meta debe ser alcanzarla, reconocer su ausencia y perseguir su consecución. Una cosa llevará a la otra. El mercado no nos favorecerá si no lo exigimos nosotros mismos.

Debemos reivindicar nuestra competencia con hechos y no sólo con titulaciones.

Custo abierto de TDD en Donosti

Me complace anunciar que los dias 25 y 26 de noviembre celebramos un curso abierto de TDD en Donosti. Abierto significa que puede asistir cualquier persona. El unico requisito es pagar la plaza. Todavia quedan plazas libres.
Gracias a Mario Nunes y Luis Artola, hemos reunido un grupo de desarrolladores que tienen el espiritu de mejora continua. El espiritu adecuado para afrontar un intenso curso de Test Driven Development.

En el mismo viaje pasare por Vitoria. Tanto en Donosti como en Vitoria, si alguien quiere reunirse para tomar unos pintxos y hablar un rato, solo es cuestion de proponerse quedar :-)

Puede que con suerte consiga estar en el coderetreat que organizan JM Beas y Enrique Comba en Donosti. Mas info aqui.

Gracias a todos. Siempre que viajo al norte me acojen de maravilla. Estoy ya deseando ir a escribir codigo con vosotros!

Ha llegado MavenCharts.com

Git dice que hice el primer commit en el repositorio el dia 2 de diciembre de 2009. Sin embargo la idea se me ocurrió hace 3 años. Aquello de que el día a día no te deja, retrasó el proyecto hasta hace poco. La unica manera de poderlo llevar hacia adelante ha sido dedicarme a ello exclusivamente, primero en solitario y luego con un equipo de desarrolladores vocacionales como el que somos ahora. Oscar se unió al proyecto hace unos 3 meses y Dani todavía no ha hecho el mes. Curso a curso he ido pagando el alquiler y las facturas para ponerlo todo en este desarrollo. Se ha llevado a cabo usando Test Driven Development al 100% en el backend. Para el frontend, no hemos hecho tests automaticos del javascript. Realmente es el mejor código que he escrito en mi vida. Y estamos tranquilos de que podemos hacer cambios con velocidad sin perder estabilidad. Menos mal, porque Google App Engine lo pone muy dificil.

Cuando empecé a escribir código en diciembre, planeaba tener lista la version que ha salido ahora, en abril. O sea que nos hemos retrasado 3 meses, practicamente el doble de la previsión. Calculo que trabajando sobre un sistema SQL tradicional y un servidor web como Apache, hubiesemos de verdad terminado en abril o mayo a más tardar. Realmente desarrollar sobre GAE ha sido un dolor. En primer lugar porque es NoSQL y eso significa que tienes que aprender a acceder a datos de otra manera. Tienes que pensar diferente. En segundo lugar, porque el Datastore (la base de datos) tiene tal cantidad de restricciones que hacer consultas medio complejas es muy muy complejo. Las consultas del buscador de MavenCharts son complicadas sin duda. Esto ha hecho que haya más tests de integración de los que hubiesen sido deseables.
Por otro lado, cargar la base de datos con las poblaciones de España tambien ha sido complejo. Primero habia que buscar los datos, tratarlos y subirlos. Los tenemos georeferenciados vía google maps para las nuevas funciones en las que estamos trabajando. Eso también llevó su trabajo.
GAE no te permite hacer ningun request que dure mas de 30 segundos, lo interrumpe con un error 500. Entonces te las tienes que ingeniar para dividir la tarea. Menos mal que hemos usado python y los scripts se hacen rápido porque hemos automatizado mil cosas de ese tipo. Para subir datos no puedes hacer un dump de SQL, todo lo que tienes es CSVs, que puedes subir si te programas las clases que los saben interpretar. Te lo tienes que hacer todo tu.
Otro problema importante es que el entorno de desarrollo de GAE en el pc local no es igual que el de la nube, y los tests de integracion que te van bien en local, luego arriba petan por falta de indices en la BD y cosas asi. Gracias a WebDriver, el cual hemos manejado desde Java, hemos podido automatizar las pruebas de integracion mas intensivas y complicadas.

El otro gran problema que nos supuso 3 semanas de retraso y unas 1500 lineas de código tiradas a la basura, fue el de la gestion de cache de datos. GAE te permita usar memcache. La gran pregunta es... ¿cómo gestionas la cache cuando tienes datos que actualizar? Despues de intentar mil cosas hemos adoptado la politica de Google, es decir, el buscador no refresca los datos inmediatamente sino que necesita unas horas. En nuestro caso unas 24 horas. Francamente es lo más optimo que se puede hacer. Todo lo demas, no escala. Realmente no vale con usar GAE para que tu aplicacion escale, sino que tienes que tener en cuenta mil cosas mas, y pensar que, cada peticion a la web, podria ser arrancada en una instancia distinta, en un servidor distinto, y si tenias un singleton por ahí, tienes un gran problema. Todo esto lo hemos ido aprendiendo a bofetadas. Menos mal que nuestras baterias de tests estaban ahí, porque sino, el caos nos hubiera ganado.

Finalmente, como todo el mundo sabe, la maquetación ha sido muy dura por aquello de que cada nequipo_mavenavegador (sobre todo Internet Explorer) pinta las cosas como quiere. Hemos cometido el error de dejar toda la maquetacion para el final pensando que seria sencilla, y no lo ha sido. En lo sucesivo iremos armando las pantallas a medida que el backend esté hecho. De hecho ahora hay que darle un gran refactoring a las css, pero al menos ya se ve bien en casi todos los sitios.

En la foto teneis al equipo de MavenCharts 1.0. En desarrollo, Oscar Moreno, Dani Latorre y un servidor. En diseño Lucas Carmona, Carlos Sosa y Pedro Gracia. En QA tenemos a Dácil a la cabeza de un grupo de amigos y colaboradores.

Ya tenemos la web internacionalizada y todo listo para soportar más paises e idiomas, asi que en las próximas semanas vamos a intentar salir en EEUU y en varios paises europeos, a la par que ir abriendo más funcionalidad. Hay ya cientos de lineas de codigo esperando a ser puestas en produccion :-)

Nos hacen falta 4 buenos desarrolladores pero por desgracia todavia no hay pelas para contratar. Ojala podamos seguir creciendo pronto.

Tenemos mucha ilusión y estamos poniendo mucho esfuerzo en este proyecto. Cualquier feedback es bienvenido. Gracias a todos los que lo habeis retuiteado y lo comentais en facebook.

Seguimos trabajando :-)

http://www.MavenCharts.com

La semana pasada fue intensísima y dura pero muy fructífera. Tuvieron lugar dos cursos abiertos de TDD, uno en Valladolid y otro seguido en Barcelona.

En Valladolid la acogida fue excepcional. Todo el mundo se esforzó a tope para que el curso saliese bien. Además Jorge Jiménez, Amalia Hernández y Pencho Herrero han sido unos anfitriones de lujo. Me enseñaron Valladolid e incluso pude ver lo contundente que es el Cocido Castellano. La ciudad y su gente me han conquistado.
Además grabamos un podcast aprovechando que la gente tenía un nivelazo tremendo.
Pencho me dió también la oportunidad de conocer a Pablo Santos de Plastic y a Jacinto Canales de Tecsidel, lo cual ha sido genial!
Por si todo esto no fuera suficiente, Pencho ha escrito este estupendo post sobre el curso!
Acabamos de colgar las fotos en Facebook.
Espero poder volver pronto a Castilla :-)

En Barcelona fuimos pocos pero la cosa estuvo bien. No me dieron tregua. DoubleYou puso las instalaciones a cambio de algunas plazas para el curso y gracias a ello pudimos celebrarlo ya que no habíamos llegado a cubrir el minimo de plazas requeridas. No sabemos cual es el motivo de haber captado tan poca atención. Desde luego no acertamos con la campaña.
Lo cierto es que lo pasamos muy bien y aproveché para conocer el bonito barrio de Gracia, donde se come muuuy bien. No tuve tiempo de hacer turismo pero afortunadamente ya he visto la ciudad otras veces (y me encanta). Grabamos otro podcast muy interesante y tuvimos tiempo de debatir-cerveza-en-mano bastantes cosas. Ha valido la pena el esfuerzo para conocer a gente tan interesante y tan profesional.

Ahora vuelta a casa, a programar a muerte, que en junio tenemos el lanzamiento de nuestro producto estrella :-)

Un mes de viajes

En breve regreso a Tenerife después de haber recorrido en tren buena parte de la península, desde Girona hasta Sevilla, pasando por Madrid y viajando a Segovia. Los motivos del viaje han sido 3. Primero la charla y el taller de TDD en Castellón, cuyo vídeo podeis ver en decharlas.com o directamente en vimeo. El mp3 de la charla tambien lo teneis en podgramando.es, el podcast técnico que por fin hemos arrancado.
Como ya he dicho antes, estoy super agradecido a Ricardo Borillo y David Castelló por invitarme a Castellón, a una universidad impresionante y por tratarme de lujo.

Luego tuvo lugar nuestro curso de TDD en Madrid. Creo que siempre digo que el último curso de TDD que hago es el que mejor sale, pero es que me queda siempre esa sensación al terminar. Esta edición ha ido muy bien sobre todo porque el nivel de los asistentes era altísimo. De hecho me han enseñado cosas, como en ediciones anteriores. El feedback de los asistentes es inmejorable, podeis leer sus comentarios aquí. Teneis las fotos en la cuenta de Facebook de iExpertos. Gracias miles a todos por haberos volcado y currado a tope en este curso. Lo habeis hecho realmente bien!

Lo mejor de los cursos de TDD es que estoy teniendo la oportunidad de programar con los mejores desarrolladores de todo el país. Es un lujo decir que me he sentado con los programadores más despiertos de muchas las cuidades y estoy encantado.

Finalmente, el sábado JM Beas me llevó en su coche junto a más amigos a Segovia al Code Retreat, donde pasamos un día agradable discutiendo temas de programación. Eso sí, iba bajo mínimos y no pude hacer nada interesante a nivel técnico. Apenas sin descansar, no se pueden hacer las cosas bien. Pero bueno, lo pasamos bien y me gustó conocer en persona al grupo de Valladolid, al que espero ver pronto. Me dieron ganas de intentar hacer el Code Retreat en Tenerife. A ver si lo organizamos.

Ahora ya ultimando detalles para ir a San Sebastian donde la semana que viene, tenemos una edición privada de nuestro curso de TDD.