Lidiando con emergencias: algunas lecciones aprendidas
¿Qué hacer y, sobre todo, qué no hacer cuando un sistema se cae? Algunas ideas para atravesar lo mejor posible esta experiencia y obtener aprendizajes en el proceso.
A case against nameless objects
We name objects, we name variables, we name classes, messages, functions and types. We name all the time because names allow us not only to reference “something” but also to understand what that “something” means.
Las 12 propiedades deseables de los tests según Kent Beck
Un análisis sobre el artículo "Test Desiderata" escrito por Kent Beck, en donde se listan 12 propiedades deseables de los tests.
This is not a User Story, or is it? Thoughts about telling and managing stories
We surely agree that there’s nothing better than users telling the dev team such stories. But, How should we call them? User stories, backlog items, story cards? And even more important: what is the most efficient way to write and manage these stories?
Anonymity vs. Agile maturity... (vs?)
Does anonymity play any role in agile teams? Even more, can we pretend to pursue a mature agile environment when members of the team are afraid to take ownership of their opinions? Let's think of a few tips to evolve into trust and self-confidence on agile teams.
Chernobyl Driven Development: 10 lessons learnt from the miniseries
Inspired by the success of the series about the Chernobyl disaster, these are 10 lessons learnt from it so you too can make sure your project is a bomb.
From a newbie, to a newbie
It's been less than a year since I joined 10Pines, and a little more than two since I started working officialy as a programmer. I don't like calling myself a junior developer because
Ruby On Pains
Have you ever heard about the Rails way? I would like to introduce some pains that I've seen and keep seeing in all the Rails projects due to the Rails way... ActiveRecord How
Two ways we understand code: Unitary vs Integral understanding
There is an often unresolved question in software about comments and documentation. It is said that code should be "self-documenting", thus comments can be a sign of a lack of clarity in the code.