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 June, 2012



Some javascript developers say that "===" operator is always better than "==". I disagree with that.
I find javascript a different language when you test-drive your code. Different rules and concerns apply.
If you test-drive your code, most of the time, the "==" operator is fine. It makes the code easier to read and it's proved and covered by your tests. They way the API is expected to be used is expressed in your tests. Any usage you expect is expressed in the form of a unit test.
Handling optinal arguments is a clear example of shorter code:

  1.  
  2. function someFuncWithOptionalObjects(arg1, arg2){
  3. if (!arg1)
  4. arg1 = someDefaultValue;
  5. ...
  6. }
  7.  

I don't mind if "arg1" is "null" or "undefined". "Falsy" expresses the concept better than "null or undefined" and the code is shorter. If I am test-driving this function and I expect the arguments to be objects, I don't have to worry about "arg1" being a boolean with "false" value. That is not the way I am going to invoke this function. So I don't need the "===" operator.

Now, If I am writing a framework, the rule might change. If I think that somebody else might pass in a boolean as the first argument, then I have to address this case. But I would ask myself first, why is my code confusing the consumer so much. Why is my code not expressing the intent clearly enough so that other developer is passing a boolean rather than an object.

Functions should have no more than 2 parameters, maybe 3. And they should be no more than 5 lines of code, maybe 7. The name of the function should communicate what it is intended for. Apart from that, I am test driving my code. So why do I need the triple-equals operator?

I guess that triple-equals operator is great when your functions are longer than 5 lines of code, or take a big list of parameters or have a confusing name.
I understand that this is not always the case. Writing a base framework like jQuery requires the triple-equals in many places for sure. But you don't write frameworks all the time, do you? I write applications more than frameworks.

Our team is currently developing a framework with emerging design. We are basically adding features as we need them, test-driving the desing. And even in the framework code, we rarelly use the triple-equals. However, we care about wrong API usages, so we try to respond the consumer with human readable error messages that help him understand the mistake. This time, we care about incorrect usage and not only the cases we designed the framework for. But this goes beyond the triple-equals. And it is because frameworks are so horizontal that they can be used in many ways.

In my opinion, Javascript best practices don't make sense without context. So far, the more important questions to me are:
- Are we using TDD to evolve the design?
- Are we writing a framework or an application? Business rules or architecture?
- Are we trying to write clean code or spaguetti?

Clean Coders: E1 subtitulado

CleanCoders.com es el portal que contiene la serie de videos sobre código limpio de Uncle Bob. Es formación en video. Los episodios se corresponden con capítulos del libro "Clean Code". Es excelente para quien prefiere ver vídeos a leer libros. Además la formación es muy amena, es divertida.

En nuestro equipo (SaludOnNet) proyectamos un capítulo a la semana como actividad formativa. Me parece muy recomendable para los equipos de desarrollo. Hay gente que no suele leer libros técnicos para aprender pero el video les resulta más asequible.

Cuando ví el primer episodio me encantó. Y además pensé que es genial la forma en que el tío Bob cuenta toda esta batalla del desarrollo de software. Así que pensé tambien que quería que la gente que no domina el inglés, pudiera entenderlo.

Escribí un email al autor y él me pasó un guión que usó para hacer el video. No era exactamente lo que dice en el video pero me servía para entender algunas expresiones y palabras que de oído me era dificil sacar. Despues me puse a trabajar con Gnome-Subtitles y varias semanas más tarde ... ¡ya lo tenemos subtitulado en Español!

Se puede descargar aquí: E1-960x540.srt

La descarga de episodio 1, cuesta menos de un euro. Hasta la fecha el fichero se llama E1-960x540.mp4.  Mientras que el .mp4 y el .srt tengan el mismo nombre,  el reproductor VLC carga bien los subtitulos en Windows, Linux y MacOS. Se puede configurar para que las letras salgan amarillas y no blancas en el propio reproductor.
Si el fichero no se llama igual, podemos añadir manualmente los subtitulos. Es diferente la forma de añadirlos en Windows y Linux. Esta es la forma de hacerlo en ambos casos:

 

<-- Windows

Linux -->

 

 

 

 

¿Te gustaría que hubiese más episodios de Clean Code subtitulados en castellano?