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 March, 2011



Request dummies

If you ever need to create a Django request for testing purposes you can use this:

  1.  
  2. import urllib
  3. from urlparse import urlparse, urlunparse, urlsplit
  4. from django.test.client import FakePayload
  5. from django.conf import settings
  6. from django.conf.urls.defaults import *
  7. from django.http import HttpRequest, HttpResponse
  8. from django.utils.http import urlencode
  9. from django.core.handlers.wsgi import WSGIRequest
  10. from django.http import SimpleCookie
  11.  
  12. def create_request(path, data={}, method="GET"):
  13. parsed = urlparse(path)
  14. environ = {
  15. 'HTTP_COOKIE': SimpleCookie().output(header='', sep='; '),
  16. 'REMOTE_ADDR': '127.0.0.1',
  17. 'SCRIPT_NAME': '',
  18. 'SERVER_NAME': 'testserver',
  19. 'SERVER_PORT': '80',
  20. 'SERVER_PROTOCOL': 'HTTP/1.1',
  21. 'wsgi.version': (1,0),
  22. 'wsgi.url_scheme': 'http',
  23. 'wsgi.errors': None,
  24. 'wsgi.multiprocess': True,
  25. 'wsgi.multithread': False,
  26. 'wsgi.run_once': False,
  27. 'CONTENT_TYPE': 'text/html; charset=utf-8',
  28. 'PATH_INFO': urllib.unquote(parsed[2]),
  29. 'QUERY_STRING': urlencode(data, doseq=True) or parsed[4],
  30. 'REQUEST_METHOD': method,
  31. 'wsgi.input': FakePayload('')
  32. }
  33. return WSGIRequest(environ)
  34.  

It is pretty much a copy&paste from different parts of Django source code. Once you get this dummy request you can invoke actions directly (functions from your views.py)

¿Todavía crees en los mitos?

Así que crees que tal o cual persona es un super gurú venido de otra galaxia como los personajes de Dragon Ball... claro.... te crees el mito y eres fan de tal persona, le idolatras. Amigo, tienes que madurar.

Nadie es mejor ni peor que tú. Nadie es mas ni menos especial que tú. Si todavía no lo ves, tienes que seguir madurando. Todos tenemos que seguir madurando, pero en lo que respecta a las expectativas que te creas de los demás, te invito a que las deseches.

Todos tenemos cosas relativamente únicas y a la vez todos somos iguales. Lo que realmente tiene magia es la interrelación y la colaboración. Entre todos, entre un equipo, las cosas sí salen adelante como por arte de magia y el grado de satisfacción es realmente sano.

Ultimamente voy a sitios donde no conozco a gente que ha oído hablar de mí y cuando me dicen que soy famoso o que soy un gurú me entra la risa.El efecto es el siguiente: cuando sólo han oído hablar de mí, recibo un trato especial, halagos y expectación. Cuando les digo a la cara que no soy mas listo ni más capaz que ellos y muestro mis fallos, entonces paso de ser una estrella a ser una mierda. Es la caída desde la alta expectativa. ¡ni una cosa ni otra!

No debemos evaluar a las personas por lo que dicen de ellas, los rumores son perversiones de la realidad. Me gustaría que me reconociesen por mi trabajo, por las ganas que le pongo y por tratar de mejorar, sobre todo cuando me equivoco. No que me tomen por lo que no soy cuando me conocen y luego me infravaloren cuando digo que soy como cualquier otro, que sólo trato de vivir la vida como voy entendiendo que quiero y puedo hacerlo. Escribo y hablo en público porque me gusta compartir, porque donde yo vivo no hay trabajo para que me quede quieto en casa. Si quiero hacer lo que me gusta tengo que moverme, ser activo. Ser un famosillo no es el objetivo, no debería serlo para nadie con mas de 15 años. Creer en famosillos tampoco. Cree en tí mismo.

Ultimamente está habiendo un movimiento curioso en la comunidad Agile-Spain y con el tema de la artesanía, que parece resaltar la figura del gurú todo-poderoso. Se piensa que determinadas personas son mágicas y aparecen fans por todas partes. Es un punto de vista erróneo (como siempre en mi opinion, que para eso es mi blog). El verdadero ideal de la artesanía del software es el de ser más profesionales, hacer mejor el trabajo, ponerle toda la atención posible y mejorar constantemente.
Paradójicamente, las técnicas ágiles se han inventado para hacer frente a nuestras limitadas cualidades intelectuales mediante disciplina, potenciando el trabajo en equipo, la participación. Y alguna gente anda pensando que se trata de seguir a un tío que sabe más que nadie y que tiene una barita mágica para iluminarnos. Wrong!

Tenemos que madurar y dejar de creer en cuentos. A mayor expectativa, mayor decepción. Lo que estamos persiguiendo es la excelencia técnica a través de la motivación de las personas, con ayuda de la comprensión, la empatía, la paciencia, constancia y el sentido común. La figura del "crack" no me pega para nada con las metodologías ágiles. Paradójicamente algunos se lo creen.

Alguna gente me dice que si sigo diciendo que soy normal y corriente perderé la fama de mito. ¡ojala! lo que quiero es ser reconocido como profesional, como currante, con ganas y buena voluntad. No me voy a cansar de repetir de que estoy continuamente aprendiendo y que me sigo metiendo buenas cagadas con desarrollos y con tantas otras cosas. Gracias a los métodos ágiles, cada vez voy equivocandome antes y así, readaptando y mejorando. Eso es la agilidad en mi opinion.

Los que están en esa posición de ser admirados deberían utilizarla para ayudar a los demás a sentirse más felices consigo mismos, con su vida profesional e incluso personal. Es cómodo acostumbrarse a los halagos y vivir en la nube, pero es engordar el ego para bien de nadie. Cuando te mueras, no te vas a llevar nada de eso. Quedará de tí lo que dejases en los demás.

Desgraciadamente parece que esta idea de que el desconocido y el extranjero son más que uno, es muy española. Como digo, lo peor es luego el efecto rebote. Cuando voy a trabajar como mentor y coach a las empresas, el efecto es muchísimo mayor cuando les han hablado bien de mí. Cuando entro por la puerta y me han vendido como una estrella, la gente escucha atentamente lo que digo y me hacen caso sin conocerme de nada. Si me conocen no me valoran. En un sitio donde nunca me han visto como Huesca, hacemos un dojo y se llena hasta la bandera. En Canarias les digo a los amigos del grupo que les doy un curso de TDD gratis y pasan del tema. Total como ya echamos las birras juntos... (ojo, no digo que mis amigos del grupo agile-canarias no me tengan estima).
Por exceso o por defecto, no hay una correspondencia con como creo que debería de ser. Hay que intentar aprender de todos, aprovechar lo bueno de cualquiera, y cuando alguien te presta ayuda, ser agradecido. Sea famoso, o sea tu peluquero.

Las personas de agile-spain con las que mejor me llevo son las que me han tratado exactamente igual antes de conocerme que despues de jartarnos de birras juntos o de ver código malo mío. Intentamos aprender unos de otros sin envidias ni exaltaciones.

La naturaleza de nuestro ego es querer sentirse distinto y especial, es humano. Por es la gente está orgullosa de pertenecer a una comunidad como agile-spain, porque creen que eso les convierte en algo diferente hacia mejor. Sin embargo, no veo nada distinto en agile-spain a lo que veía hace 10 años en las comunidades de usuarios de linux. Algunos buenos profesionales y algunos que necesitan madurar algo más que otros. Por esto la palabra "agile" suena mal en algunos ambientes, porque ha pasado a ser dogma (bueno, también porque la han usado pero luego no tenían ni idea de "agile"). Estar en la comunidad agile-spain no te hace mejor profesional. Demuestralo con tu trabajo, demuestralo siendo mejor compañero.
Cuando hablo con un cliente que no ha oído nada de "agile", no voy diciendole "agile", "scrum", "tdd"... le hablo de valores. De entregas tempranas e iterativas. De colaboración, de valor, de satisfacción para el cliente.

Nos pasamos la vida comparando a los demás con uno,... "más listo", "más tonto", "más guapo", "más feo"... cuando en realidad no hay mejor sensación que la de ver que los otros son capaces de sentir como uno, y viceversa. Sentir que somos iguales.

Para que las metodologías ágiles o cualquier otras pongan a nuestra profesión en el lugar que merece, tenemos que madurar nosotros primero. Dejarnos de pajas mentales y trabajar duro. En equipo, con humildad, con ilusión, sin límites mentales.

How to select the main template tabs status from a child template using Django:

base.html:

{% block tabs%}
<ul class="menu">

<li class="{{ SEARCH_TAB_STATUS }}"><a href="/">
<span>{% trans "search_professional" %}</span></a></li>
<li class="{{ REGISTER_TAB_STATUS }}"><a href="/register">

<span>{% trans "want_work" %}</span></a></li>
</ul>
{% endblock %}

register.html:

{% extends "base.html" %}

{% block tabs%}
{% with "inactive" as SEARCH_TAB_STATUS %}
{% with "active" as REGISTER_TAB_STATUS %}
{{ block.super }}
{% endwith %}
{% endwith %}
{% endblock %}

Nice one!!!

Tour Retrospective 1

Update: Thanks to Adrian Perreau (@eidrien) for fixing English mistakes in this post :-)

I have been visiting many companies since 2009. The experiences I've been having as mentor/coach these months are teaching me lots of key aspects of software development teams. I am learning more about us, technical folks. Sometimes I make mistakes, sometimes I apply techniques that are successful. Let's share them :-)

To really coach a team from the beginning and make it a real team, you probably have to work with them for 6 months. You can't change the team in a week. If the team is small, willing to learn and change, and they are already walking the agile journey, then you can do more in a single week. You can help in a short period of time. Right. You can also try it out if you face a team which is starting a sprint and have time to listen (everyone in the team), including product owners.
If all those circumstances are not in place, just act as a mentor, don't try to coach any team. Don't even try to coach one by one unless you can help an individual, as a person, not as a team member. Why? Because you just can't help in those few days. You might open wounds and then not be able to close them because you leave too soon. Or at least, you will disrupt people without any benefit. Specially if you arrive to the team at the middle or at the end of the sprint or they are feeling pushed against a deadline, you will be more an obstacle than helpful. Try to discover who are the guys that are available and willing to be mentored. Sit down and code with them, well, if you are and XP mentor :-)

When you do pair programming with them...:

  • Have a look at the code they have written before you arrive. This will tell you if they need a refactoring session, a redesign session, a TDD session to implement a new feature or a code kata.
    • Refactoring session: small refactoring steps to make sure nothing gets broken, running the tests after every refactoring. Just finding better names and removing duplication will teach deep lessons.
    • Redesign session: you sit down and don't understand the code at all, although it does not look that ugly. You redesign the code together to understand it. That would be a big refactoring. Don't commit the outcome to the repository, you are probably breaking things. The lesson is, how the code can explain the domain itself.
      People love conclusions, so if you don't think the redesign can be done in the time frame you have, avoid it.
    • Development of new features: Test drive the features together. I don't have to tell you the huge benefit of this, have I?
    • Code Kata: None of the previous strategies seem to apply. OK, lets enjoy a code kata together to learn more about TDD and design principles.
  • Be aware of the pair programming rules. If you haven't practiced enough pair programming be very careful, read some books before.

If you plan to give a workshop and also coach, do the training before the coaching. There are some reasons for this:

  • People start knowing who you are. You gain the credibility you will need when coaching, specially if is the first time they see you.
  • The impact of a good training can open their minds so that they will be happy to be mentored one by one.
  • The whole team realizes from the beginning that something good is going on.

Make your rules clear to management. I have a TDD workshop that works very well when it lasts all day long, starting from 9 o 10am (2 days). Sometimes companies have asked me to start after lunch and run the workshop over several more days in order to make it fit. I have accepted and the outcome hasn't been as good as with my required time table.

Language and culture are fundamental aspects of communication. If you mentor/coach people with different culture or language than yours, you have to readapt your approach:

  • Start coaching or mentoring one by one, rather than approaching the team, you will see how the communication is with everyone.
  • Expect for the unexpected and always have a B plan. What happens if too many points are being missed in the communication channel?
  • Take more breaks if you need it.
  • Work less hours than you are used to. You will need more energy.
  • Don't worry if you don't have the time to explain everything you wanted, make the people understand clearly what you teach, make communication a priority and don't worry for the things you don't have time to study.
  • If you can't speak in the language you choose, as fluent as they do, just don't work with them, it will be a failure.

Custom in-home training/workshop is very risky. By custom I mean something the company ask you to teach, but which is not the training/workshop you are used to doing. In my case, I love teaching TDD and other XP techniques but sometimes people ask me for specific training on some languages or tools. If that is the case, try the following:

  • Send a short questionnaire to every attendee, trying to figure out what topics they really want to approach. Usually the topics are arranged by managers and sometimes they don't match what attendees really wanted. Even if management sent a survey to attendees, make sure you ask them one by one before, to let them be responsible for what they asked. It is a good way to start the commitment.
  • Make sure attendees have similar skills.
  • Make sure groups are very small, I'd say about 10 people max. You will need to find the time to sit down with individuals.
  • Be able to split the group into smaller groups on the fly.
  • If you are not really passionate about the subject of the workshop, don't do it. This happens to me with some tools. Sometimes I get the feeling that people can just read a manual and get the same knowledge as they would by attending the workshop, and in those cases I prefer to refuse giving the workshop.

As in a speech, coaching/mentoring has three parts and the most important ones are the beginning and the conclusions, not the work in the middle as one might think (well, this is the case if the visit to the company is really short. The case of the coach working with the company for several months, is very different). The beginning is really important to catch people attention and motivation. Conclusions give the people a last feeling which summarizes their experiences along the work. Usually people don't give you real feedback about what they were taught, they give you feedback according to their feelings as human beings. A nice conclusion is even more important than everything else. Remember that we need purpose (feel that what we do has a clear meaning) to get motivation. Conclusions should bring all the purpose of your working sessions and make it crystal clear.