“refactoring in ruby” is available to buy!
The book I’ve been writing with Bill Wake for almost 2 years is now available on Safari Rough Cuts: Refactoring in Ruby! This is a draft we completed a couple of months ago; we’ve since completed another round of edits, and we’re beginning to prepare for production now. Woot!
(Our original working title was Ruby Refactoring Workbook, but apparently that kind of title was likely to limit sales.)
reek mailing list
Discussion about Reek seems to be popping up all over the place at the moment, so I’ve created a Google group where problems, ideas and suggestions can be shared in one place. I’ll be making release announcements there and seeking feedback from you on my ideas for Reek’s future.
So if you’re using Reek, hop over to http://groups.google.com/group/ruby-reek and let’s get the ball rolling.
initial observations on kanban introduction
One of the teams I coach decided this week to adopt kanban-style limits on the WIP at each part of their value stream. It’s much too early to tell how beneficial this will prove; the transition, though, showed up a few points of interest:
- In order to set WIP limits we had to map the company’s value stream more completely. In retrospect, the previous fuzzy understanding of the value stream had been one cause of the bottlenecks towards the customer end of the process. Kanban was the catalyst to fixing this, but otherwise unrelated.
- Re-mapping the value stream temporarily focussed everyone on clearing some inventory, because a couple of WIP piles were initially bigger than the WIP limits we had all agreed.
- We quickly discovered that some of the existing inventory was caused by cards only having customer value in batches. Cards had been held up in huge piles at the “Beta” and “UAT” stages, because they didn’t represent stand-alone demonstratable user value.
- The introduction of WIP limits helped everyone to realise that the cards had been representing engineering tasks rather than customer value. So either the WIP limits had to be multiplied by the number of engineering tasks per user story, or future cards had to change and become user stories.
- The introduction of WIP limits also served to focus everyone’s attention on the whole value stream. Previously the developers had been throwing cards “over the wall” into “Beta” and “UAT” and then forgetting about them. WIP limits quickly encouraged the developers to address bottlenecks in all areas.
- Some of the existing value stream stages turned out to be buffers for others; and at least two of these buffers were “discovered” during the mapping exercise. We set low WIP limits on these buffers, to help squash the “over the wall” mentality.
No doubt WIP limits will throw up other subtle side-effects as the next month or so unfolds. Interesting times ahead…
discussion on TDD and code analysis tools
During the last few weeks I’ve been participating in an email discussion about the relationship between static analysis tools (such as Reek) and TDD. The discussion was instigated by Pat Eyler, and he has now organised and posted the results on his On-Ruby blog.
To help me get an initial handle on the topic, I found it extremely useful to list the main areas of discomfort I feel when using Reek in my own work. Then for each of these (there were two) I constructed conflict clouds to get a balanced view of the problem. I don’t have the clouds to hand now, but you can read the results in Pat’s article. I’ll definitely be using that technique again, because it very quickly helped me to organise my thoughts. (Note to self: throw nothing away.)
crap4r
Inspired by Uncle Bob’s use of crap4j, and egged on somewhat by various members of the Twitterverse, Marty Andrews and I have spiked crap4r on Github. This version looks for Rspec examples in all files called spec/**/*_spec.rb; then it runs them using Rcov and calculates the CRAP metric using code from Roodi. Very neat.
It’s all a bit scrappy and difficult to use right now, but we’ve proved the concept, and over the next few weeks we’ll get it licked into shape and (hopefully) published as a gem.
i’ve moved my code
My website, kevinrutherford.co.uk used to be implemented using the Drupal CMS. I did that because I wanted to host various code samples and suchlike, but in the end it was rubbish. So this week I killed it and replaced it with the much simpler 1-page site you can see there now. As a consequence I’ve moved all of my old code samples to repositories on github. All much easier for me to maintain.
The one downside to all this is that I no longer have somewhere to host my simulation of coin tossing. Well, that’s a shame, but not the end of the world. If you want to try it you can clone the github repository; or you can simply look at the three sample outputs I’ve posted here, here and here. Not a live simulation, I know, but possibly the next best thing for now.
“Lean, Constraints, Action!” write-up
Earlier this year Allan Kelly and I ran a workshop on agile/lean at Kingston University for the local BCS SPA group. Immo Hüneke, who invited us down there, has published an insightful write-up of the session, complete with photos (I’m the fat one in mid song).
callbacks break hexagonal architectures
I just figured out why callback style APIs are harder to test (and harder to deal with in general). It’s because they break one of the essential ingredients of a hexagonal architecture: the middle hexagon should be independent of the adapters. Here’s why…
In order to use a callback API, one or more of our application classes must implement the callback method(s), and must therefore conform to some abstraction defined by the API’s provider. So our classes must depend on the API. Which means that the API can’t be easily mocked or stubbed. We have to treat our callback objects as being part of the adapter for that API, and test the rest of the application by mocking or stubbing them.
In fact, now I’ve written it down it’s trivially obvious, and hardly worth saying.
As you were.
reek wiki
As I prepare to release version 1.0.0 of reek, I’ve begun gradually re-organizing all of reek’s online presence. So here’s where to look for anything reek-related in future:
- Gem download: Rubyforge
- User documentation: Github
- API rdoc: Rubyforge
- To clone the latest source code: Github
- Defect reports and feature requests: Lighthouse
For anything else, send me an email :)
