Sácale todo el partido a los tests haciendo que griten

Si tuviese que decir en qué se basa una prueba unitaria, diría que las principales características que debe cumplir son (sin ningún orden en particular):

  • Que sea rápido y sin efectos secundarios.
  • Que sea realmente unitario.
  • Que sea auto explicativo.

Pero con el tiempo veo que la gente tiende a centrarse en las dos primeras de mi lista.

Se busca que sea rápido y sin efectos secundarios porque de esa forma podemos lanzarlos siempre que queramos, dándonos confianza. Si tuviésemos que esperar minutos en saber el resultado, o tuviésemos que andar limpiando una base de datos cada vez que quisiésemos lanzar pruebas, simplemente no lo haríamos tan frecuentemente como debiéramos.

También se prioriza que sean unitarios y aislados, para que cuando algo falle, tengamos la granularidad suficiente para identificar el problema en cuestión de segundos. Si tuviésemos una prueba que lo probase todo, el día que fallase, no sabríamos cual de las partes ha sido la culpable.

Y aunque considero que estas dos características son importantísimas, creo que se desprecia la última de mi lista. Las pruebas deberían ser auto explicativas, en el sentido de que debería ser muy fácil saber qué se está probando en todo momento, y sobretodo, qué hace el componente que estamos probando.


Read more

Share Comments

Administrar recursos frontend con Assetic (sin Symfony2)

Buscando mejorar el rendimiento de nuestras aplicaciones web, muchas veces nos centramos en el backend sin prestar suficiente atención al frontend. Una de las mejoras que podemos aplicar en la parte frontal de nuestras webs para que vayan más rápidas es reducir el número de peticiones HTTP que son necesarias para cargar la web. Para ello podemos, por ejemplo, combinar varios archivos CSS o JS en uno solo para que, aunque tengamos que cargar muchos recursos, solo una petición HTTP sea necesaria.

Hacer esto a mano puede ser tedioso y llevar a problemas, por tanto una buena solución sería preguntarnos si alguien ya ha solucionado este problema antes. Como tantas otras veces la respuesta es que sí.

Hoy vengo a hablaros de Assetic, una herramienta que nos permite administrar fácilmente los recursos de la web, como archivos CSS o Javascript, para combinarlos, minificarlos u optimizarlos.


Read more

Share Comments

Caminante no hay camino, se hace camino al andar

Llevo 3 años enseñando buenas prácticas en el desarrollo de software entre el internship de Softonic y las colaboraciones esporádicas con la universidad, y algo que he aprendido de todo esto es que es muy difícil.

Es difícil explicarle a alguien que la duplicación es mala si no ha sufrido las consecuencias en sus carnes. Es complicado decirle que no abuse de la herencia entre clases si no se ha visto incapaz de cambiar su código por culpa de esto.

Es decir, podemos enseñar buenas prácticas a estudiantes, decirles que hagan esto y aquello, o que eviten eso de allí, pero no lo interiorizarán de verdad hasta que no vean claras las consecuencias. Podemos explicarles los beneficios, los pros y los contras de una decisión y lo memorizarán. Pero no lo entenderán del todo y lo dominarán hasta que no lo sufran y se digan a sí mismos: “mierda”.


Read more

Share Comments

¿Qué es el versionamiento semántico y por qué es importante?

Cuando decides utilizar un código que no es tuyo como puede ser un framework o una librería, una de las cosas de las que tienes que preocuparte es de estar al día con las últimas versiones que vayan sacando. No solo porque quizá incluyan cosas que te puedan interesar, si no porque puede que la última versión del framework en el que acabas de basar toda tu aplicación no sea compatible con código de versiones anteriores.

Aquí nacen dos problemas del mundo del software. Uno, para el consumidor de ese código, que necesita una forma de saber si la última versión de una herramienta es un cambio absoluto del comportamiento o solo arregla unos fallos menores. Y dos, para el creador de código, que necesita de una manera de comunicar a sus usuarios la naturaleza y el alcance de la última versión que va a publicar.

Para esto se inventó lo que conocemos a día de hoy como versionamiento semántico, o semantic versioning.


Read more

Share Comments

Limitar memoria máxima de Redis

Haciendo pruebas en uno de los proyectos que tengo, utilicé Redis como sistema de caché, en vez de utilizar Memcached que es el que normalmente uso. Por defecto, Memcached va llenando su memoria hasta que esta se llena, y es entonces cuando empieza a borrar valores existentes para hacer sitio a las nuevas. La estrategia elegida para borrar es eliminar aquellas keys de la cache que han sido menos utilizadas.

Cuando activé Redis para mi proyecto, el proceso _daemon_ del servidor empezó a ocupar más y más memoria hasta que ocupaba casi la totalidad de la RAM del servidor. Poco después, el propio sistema operativo decidió matar el proceso de redis para no morir en el intento.


Read more

Share Comments

Inspección continua de la calidad de nuestro código

Una de las formas que tenemos para poder mejorar el código de nuestro proyecto es someterlo a una inspección continua y constante. Lo primero que podemos hacer es lanzar nuestros tests tras cada push al repositorio, de forma que sabremos en todo momento si hay algo que no funciona bien.

También podemos analizar la complejidad del código y comprobar si estamos incrementándola o disminuyéndola.

Hasta ahora, todas estas tareas eran posibles solamente teniendo un servidor de integración continua configurado, siendo Jenkins el más famoso. En él podemos ejecutar todas estas tareas tras cada push. Recursos como http://jenkins-php.org/ te ayudarán a configurar este versátil servidor hecho en Java.

La buena noticia es que cada vez hay más herramientas online que te permiten hacer estas tareas sin necesidad de configurar practicamente nada. Hoy veremos como lanzar tests y analizar la calidad de nuestro código sin utilizar un servidor de integración continua.


Read more

Share Comments

Geolocalización en PHP y las páginas de afiliados locales

Una de las webs de las que soy responsable contiene artículos sobre productos electrónicos: análisis, comparativas, novedades, etc. Utilizando el sistema de afiliados de Amazon y, si tus análisis convencen a los usuarios para rascarse el bolsillo, puedes sacar un porcentaje de la venta.

El problema con Amazon es que tiene una tienda distinta para cada país. Es decir, Amazon para España no es el mismo que para Francia o Estados Unidos. El catálogo es distinto, sus usuarios diferentes y hasta el programa de afiliados funciona de manera distinta. De hecho, para participar en el programa de afiliados tienes que darte de alta por separado en cada uno de los países que quieras participar.

Mientras hacíamos esto, mi compañero y yo nos dimos cuenta de un detalle. Si un usuario desde México lee nuestro análisis y quiere comprarse el producto, seguramente lo quiera comprar en la tienda de Estados Unidos, no en la Española. Sin embargo, tener que poner en todos nuestros artículos varias versiones de enlaces del tipo “_si vienes desde México entra aquí, si vienes desde España entra allí_“, no nos parecía una opción viable. Así que, ¿cómo podíamos solventar esto?


Read more

Share Comments

Ni hombres lobo ni balas de plata

Durante años, programadores de todos los lenguajes han buscando sin descanso la respuesta a todos sus problemas. Una metodología, un principio. Algo que termine de un plumazo con las complicaciones a la hora de programar. A esta respuesta se le llama comúnmente la bala de plata.

Muchas veces es costoso tener que decidir si este principio es mejor que ese otro; o si es mejor aplicar tal patrón de diseño en vez de otro distinto. Os suenan cosas como:

– Siempre tienes que tener 100% de code coverage.

– Nunca deberías utilizar un ORM.

La buena noticia que quiero compartir hoy contigo es que no tienes por qué elegir. No tiene sentido hacerlo. ‘X’ no es mejor que ‘Y.’ Pero tampoco ‘Y’ es mejor que ‘X’.


Read more

Share Comments

Herramientas para el programador PHP moderno

La comunidad de PHP ha evolucionado muchísimo en los últimos años, no pareciéndose en nada a las versiones anteriores. No solo ha cambiado mucho, si no que cada vez cambia más frecuentemente. Y cuando hablo de comunidad, me refiero tanto al lenguaje, como a las personas que lo utilizan, así como a las herramientas que nacen alrededor.

Hoy vengo a hablaros precisamente de herramientas. No puede ser que programes PHP con las mismas herramientas que utilizabas hace 3 años. Haber actualizado tu IDE a la última versión es un comienzo, pero no es suficiente. Estás perdiendo la posibilidad de trabajar más cómodamente y ser más productivo, pudiéndote centrar en lo que realmente importa: crear cosas.


Read more

Share Comments

Sin refactoring no es TDD

Parece evidente, ¿verdad? Cuando explicas TDD (Test Driven Development), explicas que tiene 3 fases: rojo, verde y refactoring. Sin embargo, parece que son las 2 primeras las que entran con mayor facilidad en la mente del programador.

Presentas la kata y allí van disparados a escribir su primer test para estar en rojo. Una vez allí, _baby step_ en el código con lo mínimo indispensable para pasar el test y ponernos en verde. Es entonces cuando deberíamos pensar en el refactoring, pero normalmente es difícil encontrar cosas a refactorizar en nuestro (poquito) código en las primeras iteraciones, así que pasamos a rojo otra vez escribiendo un nuevo test.

Este proceso se repite de forma rápida durante los primeros tests, y con la excusa de que con pocos tests es difícil encontrar duplicaciones o cosas a mejorar en el código que hace pasar estos tests, poco a poco entramos en el modo semárofo del rojo-verde.


Read more

Share Comments