Some time ago, while researching types of defects and the cost of fixing them1, I stumbled upon this:
Years ago I worked with a bunch of economists in the US Federal Government - they categorized ‘bugs’ in their memos into three types:
Typos: Simple misspellings of words. Infrequent, easy to detect, easy to fix.
Writos: Incoherent sentences. More frequent, hard to detect, harder to fix.
At a client, today we’ve done a brown-bag session on refactoring: we’ve gone through and a live demo, including refactoring a core piece of our code.
We’ve done some mob programming to help identify some smells and how to fix them.
Update: I’ve grouped all small posts related to the self-study from June 2015 into a single post
Le monitoring de flux par l’exemple I’ve read this article about monitoring, in the way of “by example”, by Cédrick Lunven and Julien Kirch (French)
The First Micro-service Architecture I’ve read this article about microservices and how they were implemented many years ago by Robert C. Martin
How I Learned to Balance My Life With Remote Work I’ve read this article about balancing life and work, either physical or remote by Michael Erasmus
At a client, I’ve presented today an internal training on “BPM: Process and tools for developers”
In it, we have introduced the BPM concept and the main ideas in Activiti BPM.
Also techniques for hotswapping processes, tips and how-tos.
This category is mainly dedicated to anything related or included in the book ‘Practical Object-Oriented Design in Ruby’, by Sandi Metz
Note: This has been created a posteriori with a previous date
At a client, we’ve done today an internal training on “QA & how to test”. In it, the most skilled person with the QA role in the dev team has explained to us some techniques and concepts for testing
My notes Verification vs validation: building the product right vs building the right product.
Principles Extracted from ISTQB:
testing shows presence of defects exhaustive testing is impossible early testing is better than later testing defect clustering: areas with bigger defect ratio or more critical, etc should be tested more thoroughly pesticide paradox testing is context-dependent absence of errors fallacy: the absence of defects does not imply perfect software.