Archive for the ‘iExpertos’ Category
iExpertos se transforma en grupo
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?
- times statement is also available in spies, not only mocks
- stubs ignoring arguments can live together with stubs defined with arguments
- a new matcher: obj_with_fields
1: This sintax is now possible:
assert_that_method(spy_obj.some_method).was_called().times(2) or assert_that_method(spy_obj.some_method).was_called( ).with_args(SOME_VALUE).times(2)
2: The most precise matching condition will be used:
when(spy_obj.some_method).then_return(SOME_VALUE) when(spy_obj.some_method).with_args(10 ).then_return(OTHER_VALUE)
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:
assert_that_method(spy_obj.some_method).was_called( ).with_args(obj_with_fields({'id': 20, 'name': 'Carlos'}))
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.
def test_using_a_stub(self):
USERID = 20
collaborator = stub(Collaborator())
when(collaborator.one_arg_method).with_args(
USERID).then_return(SUCCESS)
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that(result, equal_to(OK))
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:
def test_stub_simplification(self):
collaborator = stub(Collaborator())
when(collaborator.one_arg_method).then_return(SUCCESS)
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that(result, equal_to(OK))
Now, let's replace the stub with a spy object, assuming we don't need to specify any stub behavior:
def test_if_arguments_are_important_check_them_out(self):
USERID = 20
collaborator = spy(Collaborator())
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that_method(collaborator.one_arg_method
).was_called().with_args(USERID)
assert_that(result, equal_to(OK))
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?:
def test_if_arguments_are_important_check_them_out(self):
USERID = 20
collaborator = spy(Collaborator())
when(collaborator.one_arg_method).then_return(SUCCESS)
sut = SystemUnderTests(collaborator)
result = sut.exercise_method()
assert_that_method(collaborator.one_arg_method
).was_called().with_args(USERID)
assert_that(result, equal_to(OK))
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 n
avegador (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
Resumen de los cursos en Valladolid y Barcelona
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.
Resumen del último curso de TDD
La semana pasada tuvo lugar la última edición del curso de TDD en Tenerife. Ha sido muy productivo ya que éramos un grupito reducido en comparación con otras veces y encima todos aportaban muchísimo feedback, y se mostraron muy abiertos a las actividades colaborativas.
Convocamos el curso con Java + Eclipse como herramientas de desarrollo y resultó que el 90% no utilizaba Java sino Python y PHP. A pesar de ello no tuvieron ningún problema para aprender y trabajar, lo cual indica que Java también es una buena plataforma para la docencia.
Afortunadamente cada vez tengo menos protagonismo en los cursos ya que las actividades son tan prácticas que consigo que todo el mundo vaya trabajando y que me de tiempo de supervisar y corregir puntos flacos. Por supuesto imparto los conocimientos teóricos pero he descubierto que es mejor dejar que la gente descubra por sí misma sus errores, para que aprendan y se conciencen sobre las técnicas que exponemos en la parte teórica.
En esta ocasión tuvo éxito la idea de rotar las sillas (cambiar de puesto). Lo pondremos en práctica siempre que sea posible
Es estupendo ver cómo algunos asistentes ayudan a otros y ver que algunos pueden enseñarnos cosas a todos.
La novedad en esta edición ha sido la sesión de Gregorio Mena sobre ATDD, donde tuvimos la ocasión de hacer actividades con Concordion de manera que dió tiempo a ver el ciclo completo de desarrollo.
Es una pena que se me escaparan dos para la foto finish , casi siempre se me olvida cuando terminamos, con lo bien que queda luego en el blog 
Gracias de nuevo a todos por venir!