Como saben los que me siguen habitualmente, de vez en cuando me da por traducir algún artículo, con la intención de acercar información interesante a los más perezosos a la hora de leer en inglés. Éste es otro de esos artículos.

En este caso he traducido el artículo 10 Reasons to Avoid Test Driven Development, de Assaf Stone. No sé la licencia que tiene… no pone nada en su web.

Espero que os guste tanto como a mí.

Antes, cuando cambiaba mi PC, siempre me encontraba con el mismo problema: tener que reconfigurar todas mis aplicaciones. Gracias a GNU/Linux, descubrí que era más sencillo mantener mi home en otra partición, de manera que podía conservar esta configuración.

Ahora, por suerte o por desgracia, no trabajo en una única máquina: tengo un PC y dos portátiles; en el curro tengo mi portátil, una máquina virtual hosted donde suelo trabajar, una máquina virtual unhosted que puedo volver a crear de vez en cuando y… bueno… otras 60 máquinas en las que puedo llegar a necesitar hacer algo.

Gestionar mi configuración individualmente es… un coñazo. Así que me planteé la opción de guardar esta configuración en un repositorio, como Git (ahora entendéis mi post anterior :D). Realmente no me entusiasmaba la idea, pero resulta que mi colega Daniel Fanjul me dijo que él ya lo hacía así.

Vamos a ver cómo podemos gestionarlo de manera sencilla.

Tenía que ocurrir más tarde o más temprano. Y es que tenía que hablar de GIT. Es lo que tiene ser influenciado por Daniel Fanjul XD

Git es un sistema de control de versiones. Bueno, en realidad es algo más que eso. Es un sistema de ficheros sobre el que se ha construido un sistema de control de versiones.

No soy un experto, pero creo que a lo básico llego. Y, la verdad, me hacía falta este artículo antes de escribir el siguiente XD

Cansado de leer que Python 3 es lento, he decidido ver cómo de lento es. El resultado me ha dejado de una piedra.

He tratado de utilizar ejemplos lo más pequeños posible, con la idea de evitar otras posibles mejores implementaciones. Además, he ejecutado el código varias veces, para evitar posibles efectos de carga del sistema, mostrando aquí alguna de las medidas más representativas.

Admito que la sección más importante sea, probablemente, las conclusiones. Si yo fuera usted, probablemente saltaría allí directamente :D

Este artículo me resulta muy complejo. Así como en el resto de la saga de los “por qué UN LENGUAJE mola” he tratado de ser todo lo imparcial que he podido, temo que en este caso me sea imposible.

Y la causa es muy sencilla: mi propia ignorancia.

Nunca he hecho nada en Ruby, salvo algún kata que otro. Pero me estoy leyendo el libro “7 languages in 7 weeks” (libro muy recomendable) y he aprovechado para tomar algunas notas.

Así que éste es el artículo: “Por qué ruby mola, en mi opinión”.

Admitiré todo tipo de críticas y sugerencias