Manuel has taught us today about the default value while destructuring: The following example illustrates the use of an :as directive to bind a local with the entire map. user=> (def point {:x 5 :y 7}) #'user/point (let [{:keys [x y] :as the-point} point] (println "x:" x "y:" y "point:" the-point)) x: 5 y: 7 point: {:x 5, :y 7} We’ve now seen the :as directive used for both vectors and maps.

In the last TDD workshop (experience report here), a conversation with Gary McLean Hall introduced to me this new concept of “Redesign” as a TDD phase. Concept As Gary introduced it to me1, it is a phase that might appear after refactor. It is about changing the outside design without changing the expected behavior. I thought this was also included in the refactor phase. How I do redesign I usually do this “changing of the outside design” by applying a series of refactors 2 to the production code but not changing the test code; using a bridge / adapter to get to the new API from the old one.

This is an experience report on Jason Gorman’s “Test-driven development intensive workshop” on the April 11th, 2015 I attended this training in the Greenfell housing & training in South Wimbledon, London SW19 1JZ. The training spanned from 10:00 to 17:00 with a half an hour for lunch plus three or four 10-15 minute pauses. (7 - ,5 - 4 * 12/60 = ~5.7hours = 5 hours 45 minutes) Introduction There were 23 of us, including me.

This post belongs to the growing-software series Imagine this situation: the code works. You are at this stage Disregarding the tests, the production code is complete. Could be better, but it is ready if you are in a hurry. Now, picture your test as a plant in a plant pot: it might be healthy on the outside (external quality) but how are their roots (internal quality)? Do you imagine them in an ordered fashion or in a jungle of roots?

This category is mainly dedicated to anything related or included in the book ‘Flow: The Psychology of Optimal Experience’, written by Mihaly Csikszentmihalyi Note: This has been created a posteriori with a previous date

Yesterday, Manuel Rivero and I facilitated a workshop using the tire pressure TDD microexercise. (More microexercises can be found in this category, also here) We scheduled the session as follows: 10 minutes introduction to the exercise 10 minutes to download the code and take a first look 10 minutes explanation about the exercise, what the problem is, etc 30 minutes for the attendees to explore the solution (on their own) 10 minutes for commenting the explored solutions, comments about it 40 minutes of prepared kata format 10 minutes of final explanations, questions and answers (Q&A) Total: 120 minutes or two hours, approximately