Danilo Sato

Following the recent trends on Planet TW, George and I decided to share our homage to those who, like us, miss (or don’t) running Java 6 on a Mac :-)

 

 

If you ever got your Mac screen dimming or your Screen Saver running in the middle of a presentation, here’s a quick tip: give you Mac some Caffeine. Before discovering this I used to play around with Energy Settings but always forgot to change it to ‘Custom’ and, let’s face it, switching this functionality on and off in one click is always better than two! Enjoy! :-)

 

It’s been a while since I read the 2nd Edition of “XP Explained” and I really enjoyed the emphasis on separating practices from values and principles. If you try to map the original 12 XP Practices to the new primary and corollary practices, you will notice that it’s not a one-to-one map. And that’s great! Practices are good when you are at the Shu level of learning, but they should be tailored to specific situations, and understanding the underlying principles and values is what will help you do that.

Besides Pair Programming and Test-Driven Development, most of the original XP practices are distilled in more than one practice in the second book. Refactoring and Simple Design are better exposed as Incremental Design, while the Planning Game can be recognized in a list of practices such as: Stories, Weekly Cycle, Quarterly Cycle, and even Slack. Although Coding Standards are not explicitly cited as a practice, you can see its importance when reading about Shared Code and Single Code Base. But you will miss one practice in particular from the first book: the System Metaphor.

The System Metaphor was probably the less adopted practice and usually one of the hardest to explain. If you’re able to express and design your system in a shared metaphor such as “Payroll is like an Assembly Line”, you will see the benefits of this practice shining through: communication with domain experts will be easier and the gap between domain model and implementation will become much shorter. But as it turns out, it is not easy to find a useful metaphor for every system.

If you miss this practice from XP and is looking for the underlying principles behind it, I strongly recommend reading Domain Driven Design, by Eric Evans. Striving to find an Ubiquitous Language to bridge the communication gap between developers and domain experts, and isolating complexity in a rich domain model are goals worth fighting for. In Eric’s words:

 

System Metaphors are not useful on all projects. Large-scale structure in general is not essential. In the 12 practices of Extreme Programming, the role of a System Metaphor could be fulfilled by a Ubiquitous Language. Projects should augment that language with System Metaphors or other large-scale structures when they find one that fits well. 

 

Other patterns for large-scale structure are discussed in the book, as well as a lot of other precious material. So if you still haven’t done it, go read the book!

 

While working with Git on my current project, my pair and I noticed a source of waste when synchronizing with the master repository: in Portuguese “Puxe” means pull, which sounds exactly like push, but with the opposite meaning. Push in Portuguese is “Empurre”. Because of that, it always take me a few seconds before figuring out which command to execute. Since we are all for eliminating waste, here’s the visual solution in our pairing station… :-)