Corey Haines2019-05-04T23:06:47+00:00http://articles.coreyhaines.comCorey HainesWoman-Authored Scifi Recommendations2016-01-29T00:00:00+00:00http://articles.coreyhaines.com/posts/woman-authored-scifi-recommendations<p>I spent about the last half of 2015 reading only woman-authored scifi. I’ve had a lot of people ask me for recommendations. I’ve been keeping my book lists on <a href="https://www.goodreads.com/review/list/34873476-corey-haines?shelf=read" target="_blank">goodreads</a>. But, I thought I’d put some here (I’ll update as I think of them). I don’t have time right now to put up reviews of them, but these are ones that I would recommend.</p>
<h2 id="standouts-go-read-these-now">Standouts (go read these now)</h2>
<ul>
<li>The Long Way to a Small, Angry Planet by Becky Chambers <a href="https://www.goodreads.com/book/show/26042767-the-long-way-to-a-small-angry-planet" target="_blank">goodreads</a></li>
<li>Recovering Apollo 8 by Kristine Kathryn Rusch <a href="https://www.goodreads.com/book/show/26042767-the-long-way-to-a-small-angry-planet" target="_blank">goodreads</a></li>
<li>The Legend of ZERO series by Sara King <a href="https://www.goodreads.com/series/103017-the-legend-of-zero">goodreads</a></li>
</ul>
<h2 id="others-of-note">Others of Note</h2>
<ul>
<li>Dark Orbit by Carolyn Ives Gilman <a href="https://www.goodreads.com/book/show/24799061-dark-orbit">goodreads</a></li>
<li>The Heart Goes Last by Margaret Atwood <a href="https://www.goodreads.com/book/show/25104929-the-heart-goes-last">goodreads</a></li>
<li>Memory by Linda Nagata <a href="https://www.goodreads.com/book/show/17678192-memory">goodreads</a></li>
<li>The Phoenix Code by Catharine Asaro <a href="https://www.goodreads.com/book/show/672918.The_Phoenix_Code">goodreads</a></li>
<li>Crossfire series by Nancy Kress <a href="https://www.goodreads.com/series/55234-crossfire">goodreads</a></li>
<li>Forgotten Suns by Judith Tarr <a href="https://www.goodreads.com/book/show/24290807-forgotten-suns">goodreads</a></li>
</ul>
<h2 id="not-technically-sci-fi-but-i-enjoyed">Not Technically Sci-Fi but I enjoyed</h2>
<ul>
<li>Wreckage by Emily Bleeker <a href="https://www.goodreads.com/book/show/23745132-wreckage">goodreads</a></li>
<li>The Good Girl by Mary Kubica <a href="https://www.goodreads.com/book/show/21847076-the-good-girl">goodreads</a></li>
</ul>
<h2 id="common-answers-to-common-questions">Common Answers to Common Questions</h2>
<ul>
<li>I read the first two books of the Imperial Radch series by Ann Leckie and had trouble getting into them. Might return later, but there are so many ones that I do get into out there.</li>
<li>Wondering why there is no Ursula K. LeGuin (or your favorite author)? These are highlights of the books I’ve read over the latter part of 2015. And most of these were unknown to me before.</li>
<li>Have I read Y? Where Y is a great woman author. No, I probably haven’t. Please feel free to tweet to me, so I can put her on my reading list, including a specific book if possible.</li>
<li>Are the stories different? Maybe. There are some things I think I notice, but I’m unsure if it is just the typical “well, not all the female protaganists have big boobs”-level of obvious. So, I’m settling on the thought that it isn’t that the stories are different, just that the ones I listed above are good. Bear in mind that I have spent a lot of time reading self-published space opera, so there’s that.</li>
</ul>
<h2 id="whats-next">What’s Next</h2>
<p>This was a great way to expand the currently incredibly list of authors I know about. Right now, I’m finishing up The Void (Peter F. Hamilton, a dude, but I started it after the new year on a recommendation from someone). After this, I’m diving back into my constraint-based discovery of awesomeness by enhancing the constraint: woman- and POC-authored. I recently attended a presentation by Floyd Webb on Afrofuturism (including this <a href="http://www.tiki-toki.com/timeline/entry/309200/Afrofuturism" target="_blank">timeline</a>), and it solidified the realization that I’ve been missing out by settling for the usual, “Amazon recommends this white guy based on your reading of this other white guy” list of books. If you have great suggestions, please send them to me. First up, some Octavia Butler!</p>
I'm joining Hearken2015-02-04T00:00:00+00:00http://articles.coreyhaines.com/posts/joining-hearken<h2 id="every-sabbatical-must-come-to-an-end">Every sabbatical must come to an end</h2>
<p>Last October, after a year and a half with Wavetable Labs, including the purchase of <a href="http://powerreviews.com/">PowerReviews</a> which led to a refocusing of our business, I decided to take some time to work on personal stuff. And thus started the sabbatical that I’ve been on for the past four months.</p>
<aside class="callout highlight">Incidentally, PowerReviews is a great company with a great product. If you are looking for a position working on the JVM, please see the <a href="http://powerreviews.com/careers/">PowerReviews' careers page</a>: good company; good folks to work with. And tell them Corey sent you.</aside>
<p>This isn’t the first time I’ve taken an extended leave from employment. And, knowing my life, it won’t be my last. I like periodically taking time to focus on non-work-related projects. For example, during this sabbatical, I spent my time exploring a lot of non-computer stuff alongside the technical:</p>
<ul>
<li>took a <a href="/images/painting-of-zak.jpg" target="_blank">painting class</a>;</li>
<li>started piano lessons;</li>
<li>spent two weeks substitute teaching at DevBootcamp (DBC);</li>
<li>began writing a book called <em>Explorations in the Lambda Calculus</em>;</li>
<li>wrote the first version of <a href="http://lightningvote.com/">Lightning Vote</a>, with <a href="https://twitter.com/martinisoft">Aaron Kalin</a> and some DBC alumni: <a href="https://twitter.com/shrey_317">Shreya Patel</a>, <a href="https://twitter.com/galeforcevr">Gale Van Rossem</a> and <a href="https://twitter.com/ryanmilstead">Ryan Milstead</a>;</li>
<li>did some epic walking (walked over a million steps for a total of 500 miles over the four months);</li>
<li>and got TWO NEW CATS: <a href="/images/squeaks.jpg" target="_blank">Squeaks</a> and <a href="/images/pistachio.jpg" target="_blank">Pistachio</a>!!!!!!</li>
</ul>
<aside class="callout highlight">Fun Cat Fact: Squeaks' full name is "'You can do it, Squeaks!' the story of little Kerri Strug, by Corey Haines"
</aside>
<p>But, as with all good things, even an awesome sabbatical must come to an end, making way for an even more awesome thing.</p>
<p>In December, I was introduced to <a href="https://www.linkedin.com/in/jennbrandel">Jennifer Brandel</a>, of WBEZ’s wildly successful <a href="http://curiouscity.wbez.org/">Curious City</a> radio show/podcast. She was in the process of branching out and expanding the Curious City format to other stations and was looking for development help. Jenn’s background, in radio and media, is extensive and impressive; it was exciting to meet someone deeply involved in a domain that I’ve loved from the outside for so long. Plus, she turned out to be a pretty awesome person all around.</p>
<p>After a lot of emails and some great conversations, we decided that it made sense for me to join her team on this venture. I’m thrilled to have this opportunity. I’ll be helping build the platform for other stations to use, and Jenn and I will be working together to build a business around this awesome idea, called <a href="http://wearehearken.com/">Hearken</a>.</p>
<h2 id="what-is-hearken">What is Hearken</h2>
<p>Hearken is a model for helping journalists better engage with their audience, by supporting participation earlier in the editorial process. Historically, journalists haven’t had a great way to find out what stories people really wanted to hear. Finding a story often meant seeing what other journalists were reporting on, looking at what events were happening in the world, or even just copying press releases. This works, but we now have the technology to add a more audience-centric and audience-relevant model to the editorial process; and this is what Jenn did a couple years ago with Curious City. Over time, other stations created shows based on this idea; unfortunately, each time a show is created, it needs to be built from scratch. Wouldn’t it be great if stations had a way to jumpstart the creation of these shows? This is what we are solving with Hearken.</p>
<p>Hearken consists of two parts: a technology platform and expert content-creation guidance. It enables journalists, editors and stations to listen more closely to their audience via a voting model based on a simple question: “What are you curious about?” Members of the community submit topics, then vote on what to report. The newsroom can build stories around what questions and interests people have, in addition to the usual “beat-oriented” story choices.</p>
<p>In a way, you can think of it as “audience engagement as a service.”</p>
<h2 id="what-to-expect-in-the-near-future">What to expect in the near future</h2>
<p>Over the next few months, we’ll be finishing up the platform, bringing on some stations for feedback and assumption-testing. During this time, I’ll be writing more regularly on the Hearken blog about the technical platform work, so you can expect similar content to what you read here. And, since it will be part of my job, the posts will be much more frequent. :)</p>
<p>I’m super duper excited to start this next phase of my journey. Until next time, please follow the <a href="https://twitter.com/wearehearken">Hearken twitter account</a> to keep up to date.</p>
The best comment section2014-11-25T00:00:00+00:00http://articles.coreyhaines.com/posts/auto-clear-comment-form<aside class="callout highlight">
I've wanted to put this commenting form on a my site for a while. Unfortunately, I think this could come off as too sarcastic and a bit mean. I pride myself on doing my best to not be mean online; I slip up sometimes, sure, but I try to keep friendly and supportive.
</aside>
<p>So, I hate comment sections. They really are horrible places. When I set up this new blog, I chose to not include any form of commenting section.</p>
<p>Sometimes, though, people read something and really want to respond. They have some passionate reaction and need to clear the air. Just like <a href="http://c2.com/cgi/wiki?RubberDucking">Rubber Ducking</a> in programming, sometimes just the act of writing out your response is enough. Nobody really needs to read it, your relief can come from just writing it down. So, wouldn’t this be the absolute best comment form?</p>
<section class="comments">
<h1>Would you like to leave a comment?</h1>
<form>
<div>
<label>Comment:</label><br />
<textarea rows="10" placeholder="leave comment here"></textarea>
</div>
<div>
<label>Now that you've gotten that off your chest, feel free to click the button below.</label><br />
<input type="reset" value="Click here to erase what you've written" /></input>
</div>
</form>
<footer>Powered by Don't Read the Comments</footer>
</section>
Short-lived Branches2014-11-21T00:00:00+00:00http://articles.coreyhaines.com/posts/short-lived-branches<aside class="callout highlight">
<header>tl;dr</header>
What if a branch had only a day to live? What if you had a single day to either complete your feature or start over the next day? How would this impact your coding? Sometimes you would work hard to cut features in small-enough sizes. For "longer" features that take n days, you would have n-1 days to use as drafts for it, then a day to complete the final version.
</aside>
<p>tl;sr (too long; still read)</p>
<p>Suppose you have a feature that you’ve estimated would take about 4 days to complete. Monday comes around, and you begin development on it.</p>
<p>Now consider a familiar workflow when developing this feature.</p>
<p>After exploring the requirements and possible designs, you create a branch and start writing some code. By the end of the day, you’ve made some progress, ready to start again the next morning. Tuesday morning rolls around, and you have an epiphany in the shower about a better solution. Getting into work, you begin making some adjustments to the code you wrote the day before. Of course, Monday’s work wasn’t really done with this new thought in mind, so you have to decide whether to put some shims in for your new idea or just keep going with the approach from the day before. Already, a single day in, you’ve got some technical debt built up: decisions that were made at the beginning of the feature are now negatively influencing your design (see <a href="https://www.youtube.com/watch?v=pqeJFYwnkjE3">Ward Cunningham reflect on technical debt</a> ~5 minute video). But, of course, you keep going. You could take the time to refactor the previous day’s work, but that would take time you aren’t sure you want to spend right now.</p>
<p>Now consider a different workflow.</p>
<p>After exploring the requirements and possible designs, you create a branch and start writing some code. By the end of the day, you’ve made some progress, ready to continue the next morning. Tuesday morning rolls around, and you have an epiphany in the shower about a better solution. Getting into work, you notice the work from yesterday has been deleted, so you create a branch and start working. You re-explore the requirements and possible designs, now influenced by the learnings and thoughts you had the previous day plus the time you had to think in the shower. While the code you written the day before is gone, it only takes an hour, or so, to get back to where you were. You actually end up in a better place, since you’ve had some insights into the design that will make it simpler.</p>
<aside class="callout highlight">
This idea originally started as a thought experiment based on talks with Michael Feathers and others about code lifetime and churn, combined with my experiences running coderetreat workshops, where we actively delete code and start afresh. Over time, though, my thoughts have become more concrete, and I think this style of development could have some great outcomes on our code.
</aside>
<h2 id="so-what-if-branches-had-only-a-day-to-live-disappearing-each-and-every-day">So, what if branches had only a day to live, disappearing each and every day?</h2>
<p>I’m going to write up some more thoughts about the effect, but the core idea is that you could accomplish a task in the same amount of time with better code quality.</p>
<p>If you have a task that you think is going to take you 4 days to complete, you could do 1 of 2 things: spend 4 days coding away; or, you can have 3 days to write drafts, effectively exploring the space, then spend a single day writing your final version with much better quality of code based on these 3 spikes.</p>
<p>At first, this seems like a strange, even nonworkable, idea; it immediately feels easy to come up with situations where this absolutely wouldn’t work. For each of those examples that come to mind, I would encourage you to take some time really thinking about it before you form an opinion. If you didn’t have a choice, how would your code and habits change?</p>
<p>I’d like to write more about this idea, exploring the benefits (and dangers), but I wanted to get this out in the world.</p>
<p>To try this, I’d recommend picking a 4-day, non-mission-critical feature and delete the branch every night at the end of the workday. It will be scary the first two days, but I bet you will be excited and happy on the third day. If you do, please let me know either <a href="http://www.twitter.com/coreyhaines">on twitter</a> or <a href="mailto:coreyhaines+slb@gmail.com">email</a>.</p>
An idea about email introductions2014-11-14T00:00:00+00:00http://articles.coreyhaines.com/posts/on-email-introductions<p>Throughout my adult life, I’ve been a bit of a <a href="http://en.wikipedia.org/wiki/The_Tipping_Point#The_Law_of_the_Few">connector</a>. By virtue of this, I often am asked to make an introduction for someone; a person I know is interested in contacting another person I know. I have a standard email format that I use for this, but the most recent time I did it raised a few questions in my mind about whether I was invading people’s privacy. This post highlights an idea I have for privacy-respecting email introductions.</p>
<p>A couple weeks ago I was talking to Annie, who was looking to fill a job opening. She’s a great developer at a good company, and I knew a few people who might be a fit. I thought specifically of Bob, so she asked me to send an introduction. I enjoy bringing people together, especially for an opportunity to work together.</p>
<p>In this case, I did what I generally do: brought up an email, added both people to the To and used my usual format for the body:</p>
<aside class="callout highlight">
To: Annie@coolcompany.com, Bob@personalemail.com
This is an introduction email.
Bob, meet Annie. She's the lead developer at Company X, doing some really cool things. She's looking for a developer, and you came to mind. I think you might be a good fit, so I wanted to introduce you both.
Annie, meet Bob. He's a really solid dev that I've known for a while; I mentioned him to you the other day. He's got a good background in the kind of technology you are using, as well as an interest in your domain.
Good Luck!
</aside>
<p>Now, while I think about the people, I don’t usually think much about the email; I try to make it a bit personal, but I mostly want to get the introduction out there and active. This is why I use a pretty standard format:</p>
<aside class="callout highlight">
To: person_wanting_introduction@theircompany.com, introducee@personalemail.com
This is an introduction email.
Introducee, meet person who wants an introduction.
Person who wants an introduction, meet introducee.
Good Luck!
</aside>
<p>I’ve done this many, many times, for various reasons. But, this last time, something felt different.</p>
<p>Lately, I’ve been learning more about and considering people’s boundaries, privacy and expectations, and, completely unexpectedly, all that rushed to mind after sending this last email introduction. To be honest, it shocked me a bit, but I had an overwhelming feeling that I might have just invaded Bob’s privacy. It boiled down to one simple question:</p>
<aside class="callout highlight">
Does Bob really want his personal email given to Annie?
</aside>
<p>Now, don’t get me wrong, I didn’t think this was necessarily the end of the world. On the surface, it doesn’t even seem like that big of a deal. But, even though Bob was a well-known developer and it was public that he was looking, he probably was getting a lot of offers and might have valued his choice of whom he talked to about potential jobs. He might not want to be receiving email from all the people I think might be interested in hiring him.</p>
<p>With a bit of thought, I came up with an idea on how to do this in the future while still maintaining the introducee’s privacy.</p>
<aside class="callout highlight">
Put the introducee in BCC and the person who wants the introduction on the To line. This establishes interest, puts the relevant email in public (the person who wants the introduction) while still maintaining the privacy of the introducee.
</aside>
<p>So, in the future, I’ll be continuing to do email introductions whenever I can. But, instead of putting both parties on the To line, I’ll use the following rule.</p>
<aside class="callout highlight">
> Annie: Hey, can you introduce me to Bob?
> Me: Sure, I'll send an email introduction.
To: Annie's email
BCC: Bob's email
</aside>
<p>I don’t think this is a huge, ground-breaking thing. But, over the years, I’ve learned that every little bit can help.</p>
Four-Second Test Runs2014-05-18T00:00:00+00:00http://articles.coreyhaines.com/posts/four-second-tests<h2 id="qualities-of-tests">Qualities of Tests</h2>
<p>When I talk to people about a test suite, I often say that they should satisfy the 3 F’s:</p>
<ul>
<li><strong>Fast</strong> - They should be fast as possible to minimize the amount of time to get your feedback.</li>
<li><strong>Focused</strong> - They should be focused and provide you with specific, immediate details on where the failure is.</li>
<li><strong>Full</strong> - They should fully cover your system.</li>
</ul>
<p>When people ask me how fast their test suite should be, my general answer is “faster.” Whether you do TDD, test-first, test-while or test-after, being able to change your code and quickly see whether you’ve broken anything is very important from a workflow perspective. Whenever you have to sit and wait to find out the results of your change, your flow is broken.</p>
<p>One way to achieve the “Fast” requirement is by using certain isolation techniques. In Rails, the greatest way to achieve a first level of isolation is simply by removing the dependency your domain logic has on the underlying Rails framework. There are many benefits of isolation, but I want to talk about the obvious benefit of a major side-effect, fast tests: your workflow isn’t interrupted.</p>
<p>In DHH’s post, <a href="http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html">Slow Database Test Fallacy</a>, he talks proudly about their use of the spring application loader and how that allows him to run a specific model’s tests in “just under 4 seconds from start to finish.” He then follows up with the statement “Plenty fast for a great feedback cycle!” This definitely seems like a reasonable perspective. But is it? Whenever I hear claims about time and its effects, I like to do what I call the <em>Yellow Submarine Test</em>: see the time and see exactly how it feels.</p>
<p>I pulled down an application I’ve worked on and decided to run my tests.</p>
<aside class="callout highlight">
*Note* This specific model doesn't need 52 cases and 111 assertions. To keep a like-like comparison, though, I duplicated my tests to have around the same number.
</aside>
<p>To show 4 seconds, I had to alter my tests to add a sleep to increase the time for the tests (this is why there is a pause at the end). Here is what 4 seconds looks like.</p>
<iframe width="420" height="315" src="//www.youtube.com/embed/rQOsJEzxuZo" frameborder="0" allowfullscreen=""></iframe>
<p>For me, this pause is too much, especially when running it frequently. For every change I make, I like to run the tests to make sure I haven’t broken any previous functionality. Waiting 4 seconds each time, with this sort of pause, can be frustrating. However, some people may be concerned that the techniques for speeding this up would add complexity to the code base that would negate any speed gains we’d get. Let’s see if we can get faster without adding complexity to the codebase.</p>
<p>Let’s take a look at using my very simple <a href="/posts/active-record-spec-helper/">“only load active record” technique</a>, which doesn’t require any changes to your design, and, thus, no added complexity. In fact, it can help minimize complexity by highlighting unnecessary or too many dependencies.</p>
<iframe width="420" height="315" src="//www.youtube.com/embed/00OSP-5LrVs" frameborder="0" allowfullscreen=""></iframe>
<p>When recording with Quicktime, it adds half a second to the run, so it actually takes around 2 seconds. This is still a bit slow, though. For me, even the 2 or 2.5 second run is still quite a pause when I’m working. When in a good process that includes writing unit tests, it can definitely pull me out of my flow.</p>
<p>By doing very small changes to my design, though, I can improve this. When writing my domain code, it generally doesn’t actually need to load up my database. By writing my business logic in pure Ruby, without a dependency on the Rails framework, the flow looks something like this.</p>
<iframe width="420" height="315" src="//www.youtube.com/embed/vV0GEE7pd1g" frameborder="0" allowfullscreen=""></iframe>
<aside class="callout highlight">
*Reminder* this is about half a second slower because Quicktime adds that when doing recording on my laptop.
</aside>
<p>By emphasizing the separation of concerns between my business logic and the underlying persistence-layer or whole web framework, I can keep myself much more in flow with even faster feedback cycles that don’t make me feel like I’m waiting.</p>
<p>Whether you write your tests first or your tests last, the feedback time is important. Let’s look again at the “Plenty fast for a great feedback cycle!” run.</p>
<iframe width="420" height="315" src="//www.youtube.com/embed/rQOsJEzxuZo" frameborder="0" allowfullscreen=""></iframe>
<p>Now let’s look again at the feedback cycle I have when I am working on business logic.</p>
<iframe width="420" height="315" src="//www.youtube.com/embed/vV0GEE7pd1g" frameborder="0" allowfullscreen=""></iframe>
<p>The four-second test run is obviously okay for some people, but I prefer to keep my flow uninterrupted and my feedback loop very small. And, the changes I’m making add very little complexity, and in fact emphasize when I’m doing the wrong thing from a design perspective. As with everything, the choice is yours and highly dependent on your style.</p>
<p>The original code for this can be seen at <a href="https://github.com/coreyhaines/bawch">my video series’ repository</a>.</p>
<p>Thanks to <a href="https://twitter.com/cory_foy">Cory Foy</a> for proof-reading this post.</p>
Speeding Up ActiveRecord Tests2014-05-04T00:00:00+00:00http://articles.coreyhaines.com/posts/active-record-spec-helper<p>It is no secret that I’m a huge proponent of fast tests and their contribution to effective testing and design techniques. When doing any form of test-first development, the length of the feedback cycle when running individual tests should be as fast as possible. The design techniques associated with test-driven development (TDD), in particular, rely on taking small steps, teasing out design guidance via constant and focused refactoring. To do this, it is essential that running individual tests, the ones you are working on right now, be so fast it would be silly not to run them constantly. I’m not talking here about the time for the entire test suite, but rather for the the individual tests that you run while developing a specific component.</p>
<p>Of course, with Ruby on Rails, test speed has always been a huge problem. Or, rather, it isn’t the individual tests that are slow to run, but rather the startup time for Rails is generally at least an order of magnitude longer than the time it takes to run the tests. This post is focused on how to test more effectively, writing tests against individual, isolated parts of your application.</p>
<aside class="callout highlight">
<h2>As An Aside</h2>
The recent release of Rails 4.1 includes the Spring application pre-loader to help with startup time. This is the latest in a long-line of application pre-loaders, but this one has been bundled into the core distribution. While this helps startup time, it is really just a band-aid over the real problem: loading up your entire environment when running a microtest. By loading up your entire environment, you lose one of the most important parts of test-driven development: design feedback. The feedback provided by TDD can be understood in many ways, but I like to explain it in a simple statement:
"If you find something difficult to test, change your design to make it easy to test."
If this seems a bit overly simplistic, I recommend you watch Michael Feathers great talk called *[The Deep Synergy Between Testability and Good Design](http://vimeo.com/15007792)*. In it he discusses how many instances of code smells are naturally dealt with by focusing on testability.
</aside>
<p>I’d like to share a technique for speeding up the tests that are dependent on ActiveRecord and the database. While there is a lot of information and talk about testing the parts of your system that are independent of the Rails framework (and, frankly, most of your business logic should be isolated from Rails), there isn’t a lot about how to make your tests truly effective and enjoyable when testing those parts that are integrated with Rails. This post covers the specific case where you are testing an ActiveRecord model.</p>
<p>But, wait, you say, aren’t unit tests isolated from the database? If they touch the database, are you still writing unit tests! Perhaps, perhaps not. This post, though, is not about the meaning of the term “unit tests”, or even if we should all switch to the term “<a href="http://anarchycreek.com/2009/05/20/theyre-called-microtests/">micro tests</a>”. It is true that almost of all of your code should be isolated from the database with one exception: code that is writing and making sql queries. That is, ActiveRecord scopes and other code that explicitly updates records in the database.</p>
<p>I love scopes. I find them to be a great way to emphasize “Expresses Intent” from the <a href="http://c2.com/cgi/wiki?XpSimplicityRules">4 rules of simple design</a>. In fact, for anything other than simple lookups using an id or a single field, I almost always use scopes. Providing a name for a lookup makes my code more understandable. It also allows me to test my business logic isolated from the details of the database. For me, TDD naturally leads to heavy scope usage.</p>
<p>When talking about isolation tests, we generally think of using some form of test double. Isolation, though, is about only including the parts of your system that the code needs to run. When talking about scopes, this necessarily includes the database. So, we want to test scopes with an actual connection against our database. But loading up Rails ends up taking more time than running the actual test. With a small-ish codebase, this might be a matter of only a couple seconds, but the load time increases as your application gets larger.</p>
<p>So, what can we do? Let’s think about what it means to test a scope.</p>
<p>When testing against your db, you really only need to do a couple steps:</p>
<ul>
<li>Create a connection to the database</li>
<li>Load up the code under test</li>
<li>Seed the database with appropriate data</li>
<li>Run the code under test</li>
<li>Verify the results</li>
</ul>
<p>This attitude, keeping isolated to just the essentials has led me to build a new spec helper called active_record_spec_helper. Here’s what it looks like.</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">require</span> <span class="s1">'active_record'</span>
<span class="n">connection_info</span> <span class="o">=</span> <span class="no">YAML</span><span class="p">.</span><span class="nf">load_file</span><span class="p">(</span><span class="s2">"config/database.yml"</span><span class="p">)[</span><span class="s2">"test"</span><span class="p">]</span>
<span class="no">ActiveRecord</span><span class="o">::</span><span class="no">Base</span><span class="p">.</span><span class="nf">establish_connection</span><span class="p">(</span><span class="n">connection_info</span><span class="p">)</span>
<span class="no">RSpec</span><span class="p">.</span><span class="nf">configure</span> <span class="k">do</span> <span class="o">|</span><span class="n">config</span><span class="o">|</span>
<span class="n">config</span><span class="p">.</span><span class="nf">around</span> <span class="k">do</span> <span class="o">|</span><span class="n">example</span><span class="o">|</span>
<span class="no">ActiveRecord</span><span class="o">::</span><span class="no">Base</span><span class="p">.</span><span class="nf">transaction</span> <span class="k">do</span>
<span class="n">example</span><span class="p">.</span><span class="nf">run</span>
<span class="k">raise</span> <span class="no">ActiveRecord</span><span class="o">::</span><span class="no">Rollback</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre></div></div>
<p>As an example of usage, here’s a scope that we might want to test.</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">class</span> <span class="nc">Coderetreat</span> <span class="o"><</span> <span class="no">ActiveRecord</span><span class="o">::</span><span class="no">Base</span>
<span class="k">def</span> <span class="nc">self</span><span class="o">.</span><span class="nf">running_today</span>
<span class="n">where</span><span class="p">(</span><span class="ss">scheduled_on: </span><span class="no">Date</span><span class="p">.</span><span class="nf">today</span><span class="p">)</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre></div></div>
<p>Now, at the top of our spec file, rather than writing</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">require</span> <span class="s1">'spec_helper'</span>
</code></pre></div></div>
<p>and loading the whole framework and all the dependencies, we can require our active_record_spec_helper.</p>
<div class="language-ruby highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nb">require</span> <span class="s1">'active_record_spec_helper'</span>
<span class="nb">require</span> <span class="s1">'models/coderetreat'</span>
<span class="n">describe</span> <span class="no">Coderetreat</span> <span class="k">do</span>
<span class="n">describe</span> <span class="s2">".running_today"</span> <span class="k">do</span>
<span class="n">it</span> <span class="s2">"returns a coderetreat scheduled for today"</span> <span class="k">do</span>
<span class="n">coderetreat</span> <span class="o">=</span> <span class="no">Coderetreat</span><span class="p">.</span><span class="nf">create!</span> <span class="ss">city: </span><span class="s2">"Chicago"</span><span class="p">,</span> <span class="ss">scheduled_on: </span><span class="no">Date</span><span class="p">.</span><span class="nf">today</span>
<span class="no">Coderetreat</span><span class="p">.</span><span class="nf">running_today</span><span class="p">.</span><span class="nf">all</span><span class="p">.</span><span class="nf">should</span> <span class="o">=~</span> <span class="p">[</span><span class="n">coderetreat</span><span class="p">]</span>
<span class="k">end</span>
<span class="n">it</span> <span class="s2">"does not return a coderetreat not scheduled for today"</span> <span class="k">do</span>
<span class="n">coderetreat</span> <span class="o">=</span> <span class="no">Coderetreat</span><span class="p">.</span><span class="nf">create!</span> <span class="ss">city: </span><span class="s2">"Chicago"</span><span class="p">,</span> <span class="ss">scheduled_on: </span><span class="no">Date</span><span class="p">.</span><span class="nf">today</span><span class="p">.</span><span class="nf">advance</span><span class="p">(</span><span class="ss">:days</span> <span class="o">=></span> <span class="o">-</span><span class="mi">1</span><span class="p">)</span>
<span class="no">Coderetreat</span><span class="p">.</span><span class="nf">running_today</span><span class="p">.</span><span class="nf">should</span> <span class="n">be_empty</span>
<span class="k">end</span>
<span class="k">end</span>
<span class="k">end</span>
</code></pre></div></div>
<p>Doing a timing comparison on my machine, running with the full spec_helper looks like:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Finished <span class="k">in </span>0.04543 seconds
2 examples, 0 failures
real 0m3.004s
user 0m1.624s
sys 0m0.640s
</code></pre></div></div>
<p>Switching to using active_record_spec_helper, it looks like:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Finished <span class="k">in </span>0.04452 seconds
2 examples, 0 failures
real 0m1.224s
user 0m0.712s
sys 0m0.200s
</code></pre></div></div>
<p>That’s nearly a 2-second savings for each run. This is a very small application, too. As it grows, the spec_helper version will increase its time to load. The active_record_spec_helper version, though, will stay at the 1.2 seconds. This is one of the benefits of isolated testing:</p>
<p><strong>Your tests do not change as the complexity of the rest of the application grows</strong>.</p>
<p>There is another very large benefit of this: how this relates to the design feedback of TDD. Notice that we have to explicitly require the model we are testing. Because we are not loading up our entire application, we can’t rely on having everything available to us; we have to be explicit about the code that is under test. Not just the code we have under test, but also its dependencies. So, if your model includes a module, you need to explicitly require that. But, why is this good?</p>
<p>Rampant coupling and complex dependency graphs are one of the most significant causes of difficulty around change, and larger Rails-based applications are poster-children of these problems. While the auto-loading in Rails can be useful at times, it definitely makes it easy to hide your coupling. On the surface, this is good. Until you come back to make changes and find yourself wading through a complex game of “why is X happening, and where is that code defined.”</p>
<p>Now, I’m not here to say don’t use the auto-loader; it can be handy. Instead, pay attention to the number of dependencies you have. One way would be to list your dependencies as comments at the top of your model files. Of course, comments very rapidly rot. Instead, rely on your executable documention, your examples. By forcing yourself to load your dependencies when testing, you have a living list of dependencies. When this starts to get too large, listen to the feedback and do some refactoring. After all, TDD is about listening to the feedback your tests provide. If you mask this feedback, you lose a huge benefit.</p>
<p>Thanks to <a href="https://twitter.com/fablednet">Sarah Gray</a> for proof-reading this post.</p>
We don't (always) need no stinkin' testing framework2014-04-20T00:00:00+00:00http://articles.coreyhaines.com/posts/dont-always-need-a-testing-framework<h2 id="so-much-setup">So much setup</h2>
<p>So, for some crazy reason, I like writing small collection implementations. I don’t worry too much about performance, I’m just writing them as small exercises when I want to write something. Because of their size and fairly straight-forward(haha) requirements, I can use them to experiment with how I write tests. But, often I find setting up a testing framework to feel so heavy-weight.</p>
<p><em>what a pain!</em></p>
<p>I also use simple stacks and queues as introductory challenges when I’m introducing people to the idea of automated unit testing, especially moving to test-driven development. But, there is a bit of a chicken-and-egg situation when first starting: writing tests requires introducing a testing framework, but testing frameworks often assume some base knowledge of testing by hiding a lot of the underlying principles.</p>
<p><em>hard to know where to start!</em></p>
<p>Helping beginners learn to program also has its rewards. When people are still trying to understand the very basics, even things like classes or dependencies can be confusing. Having a test framework potentially diverts us to talking about non-beginner or non-relevant topics.</p>
<p><em>yak-shaving galore!</em></p>
<h2 id="when-all-you-have-are-frameworks-every-problem-looks-like-a-dsl">When all you have are frameworks, every problem looks like a DSL</h2>
<p>Learning a new testing framework often can involve some form of a DSL. True, it might be as “simple” as learning:</p>
<ul>
<li>name your methods in the form testXXX;</li>
<li>don’t forget the call to assert_XXX.</li>
</ul>
<p>or it might be more complex:</p>
<ul>
<li>method definitions? Oh, we don’t really use those, we have a DSL;</li>
<li>oh, assertions are actually done by calling methods on the object you are testing.</li>
</ul>
<p>When you’ve been doing automated unit testing for a while, and you’ve played with different tools, it can be easy to forget that a lot of the testing tool concepts aren’t clear and obvious.</p>
<h2 id="testing-framework-we-dont-always-need-no-stinkin-testing-framework">Testing Framework? We don’t (always) need no stinkin’ testing framework.</h2>
<p>So, what’s to do when we need something quick, or we don’t want to introduce unnecessary complexity? Get back to the basics! To understand that, we can ask ourselves what is at the core of a testing framework? This isn’t actually the right question, though. Let’s get even more basic. What is at the heart of testing? Forget the automated part and think about what you do when you are building without automated tests.</p>
<p>Let’s investigate this with the beginnings of a stack. Put the following into a file and run it.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> stack = Stack.new
puts "New stack size is #{stack.size}"
</code></pre></div></div>
<p>Once we get this passing, we can write another test.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> stack = Stack.new
stack.push 1
puts "Stack size after pushing is #{stack.size}"
</code></pre></div></div>
<p>Now run this script and see if the messages make sense. We have two tests now.</p>
<p>And so on. The problem here is pretty obvious: this method is fairly inefficient. Every time you run, there is a mental step to interpret the messages. As the number of tests get larger, the feedback cycle to make sure you broke something gets larger and longer.</p>
<p>This is one of the standard arguments for having an automated test suite, of course. But, we are just playing around with building a stack. Or, we don’t really know how to work with a testing framework. Or, lots of different reasons. What to do?</p>
<p>Let’s go back to the core of testing. We run the script, look at the output and compare it to our mental checklist. AHA! Let’s just make the computer do that. Using the standard “programming by wishful thinking” methodology, let’s rewrite our test to look like this.</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code> stack = Stack.new
assert_equal 0, stack.size, "New stack should have no elements"
</code></pre></div></div>
<p>Do you need anything fancy to run this? Not really, you just need a method to compare the two values. So, when in doubt, or you want a quick way to run some automated tests, just give yourself the following method:</p>
<div class="highlighter-rouge"><div class="highlight"><pre class="highlight"><code>def assert_equal(expected, actual, message)
if expected != actual
raise "Expected #{expected}, got #{actual}\n#{message}"
end
end
</code></pre></div></div>
<p>This simple method can help you quickly get up and running, allowing you to focus on the problem your solving, rather than the possible complexities of a testing framework.</p>
<p>So, the next time you are playing around, or learning a new language, or teaching someone the idea of automated testing, ask yourself if you need anything more than this simple method and hold off on bringing in something larger.</p>
<p>Thanks to <a href="https://twitter.com/fablednet">Sarah Gray</a> for proof-reading this post.</p>
Understanding the 4 Rules of Simple Design - My Book2014-04-06T00:00:00+00:00http://articles.coreyhaines.com/posts/i-wrote-a-book<section class="book-embed" style="float:left;margin-right:10px">
<iframe width="160" height="400" src="https://leanpub.com/4rulesofsimpledesign/embed" frameborder="0" allowtransparency="true"></iframe>
</section>
<p>So, I wrote a book called <em><a href="https://leanpub.com/4rulesofsimpledesign">Understanding the 4 Rules of Simple Design</a></em>! Huzzah! It has been a long time coming, for sure. Here’s a bit more information about it, as well as some feedback from readers. I’ve also created a <a href="http://samples.leanpub.com/4rulesofsimpledesign-sample.pdf">free downloadable sample</a> to get a taste of it.</p>
<p>I’m <strong>donating 10% of the profits</strong> to support kids-oriented programming events. I already have funds earmarked to support a local <a href="http://girlswhocode.com/">Girls Who Code</a> program here in Chicago.</p>
<p>The only thing we truly know about the act of building software is that we are going to be faced with change. It is inevitable. As we gain more knowledge about our domain and our use cases, we will have to change our software. This book is about how to survive in the face of this fact.</p>
<p>At coderetreat workshops, we focus on practicing fundamental software development techniques, such as test-driven development, iterative design and pair-programming. Over the past five years of facilitating these workshops, I’ve come to a realization that simple design, the idea of writing maintainable code that facilitates the inevitable change, is the key. The <a href="http://c2.com/cgi/wiki?XpSimplicityRules">4 Rules of Simple Design</a>, originally codified by Kent Beck in the late 90s, are a fantastic starting point to building flexible codebases.</p>
<p>In <em><a href="https://leanpub.com/4rulesofsimpledesign">Understanding the 4 Rules of Simple Design</a></em>, we look at small, focused examples of applying these rules. While the backdrop is Conway’s Game of Life (the domain used at coderetreat workshops), you won’t need any background in it. Never been to a coderetreat? That isn’t a problem either, I don’t make any assumptions that you have.</p>
<p>On the fence? Check out some of the early feedback from the book.</p>
<p>Bart Bakker wrote a <a href="http://blog.thesoftwarecraft.com/2014/04/book-review-understanding-4-rules-of.html">great review with personal thoughts on it</a>.</p>
<p>Richard Dalton wrote a nice <a href="http://www.devjoy.com/2014/04/understanding-the-four-rules-of-simple-design/">review of <em>Understanding the 4 Rules of Simple Design</em></a>.</p>
<p>Ian Whitney, after reading the book, wrote a post about experimenting with the idea of <a href="http://programming.ianwhitney.com/blog/2014/04/13/4-simple-rules-and-declarative-builders/">using declarative builder methods instead of the default initializer</a>.</p>
<p>Erik Olsen, a beginner developer out of Dev Bootcamp, wrote about <a href="http://erikolsen-dev.tumblr.com/post/82618138712/understanding-the-four-rules-of-simple-design">his thoughts after reading it</a>.</p>
<blockquote class="twitter-tweet" lang="en"><p>The backdrop & common example of Conway's Game of Life extends perfectly from code retreat to book in <a href="https://t.co/nYdv26LBNp">https://t.co/nYdv26LBNp</a></p>— Chad Fowler (@chadfowler) <a href="https://twitter.com/chadfowler/statuses/450758751889272832">March 31, 2014</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>Quite liked how <a href="https://twitter.com/coreyhaines">@coreyhaines</a> managed to recycle and exemplify old XP lessons in his book <a href="https://t.co/RaGKpM9zCK">https://t.co/RaGKpM9zCK</a></p>— Ivan Sanchez (@s4nchez) <a href="https://twitter.com/s4nchez/statuses/450583194061246464">March 31, 2014</a></blockquote>
<blockquote class="twitter-tweet" data-conversation="none" lang="en"><p>Behavior Attractors is a concept I've never been able to put a name on before. Well thought <a href="https://twitter.com/coreyhaines">@coreyhaines</a>, nice book! <a href="https://t.co/yoQ5CnlyyR">https://t.co/yoQ5CnlyyR</a></p>— Jni (@jni_viens) <a href="https://twitter.com/jni_viens/statuses/450445396922621952">March 31, 2014</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>Several AHA moments with great <a href="https://twitter.com/coreyhaines">@coreyhaines</a> 'Understanding the Four Rules of Simple Design',just 1 fail:too short ;-)<a href="http://t.co/utauy4Idsr">http://t.co/utauy4Idsr</a></p>— amisai (@amisai) <a href="https://twitter.com/amisai/statuses/451283402982162432">April 2, 2014</a></blockquote>
<p>Still not convinced? Here are some more happy readers!!</p>
<blockquote class="twitter-tweet" data-conversation="none" lang="en"><p><a href="https://twitter.com/coreyhaines">@coreyhaines</a> So far, so good. Probably my best experience with self-published books: quick execution, high-quality content, & cool cover.</p>— Benjamin Fleischer (@hazula) <a href="https://twitter.com/hazula/statuses/450438690930569216">March 31, 2014</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>Finished <a href="https://twitter.com/coreyhaines">@coreyhaines</a> book this morning. Going to read it again. It's good. It doesn't ask for a lot of your time or money and it delivers.</p>— Richard Dalton (@richardadalton) <a href="https://twitter.com/richardadalton/statuses/451303132568772608">April 2, 2014</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p><a href="https://twitter.com/coreyhaines">@coreyhaines</a> really enjoyed the book, it's right up there with <a href="https://twitter.com/avdi">@avdi</a> & <a href="https://twitter.com/sandimetz">@sandimetz</a> ; )</p>— Gerhard Lazu (@gerhardlazu) <a href="https://twitter.com/gerhardlazu/statuses/451486202127187969">April 2, 2014</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>Just finished <a href="https://twitter.com/coreyhaines">@coreyhaines</a>' 4 rules of simple design, feeling an intense desire on learn and practice more. You should totally read it! :)</p>— Manuel Mujica (@m_mujica) <a href="https://twitter.com/m_mujica/statuses/451356654005522433">April 2, 2014</a></blockquote>
<blockquote class="twitter-tweet" lang="en"><p>Finished <a href="https://twitter.com/coreyhaines">@coreyhaines</a>’s Four Rules of Simple Design book (not sure how it snuck ahead of the queue). Short, but full of great advice.</p>— Kerry Buckley (@kerryb) <a href="https://twitter.com/kerryb/statuses/451848621756284928">April 3, 2014</a></blockquote>
<p>I’m super excited about this book, so please check out <em><a href="https://leanpub.com/4rulesofsimpledesign">Understanding the 4 Rules of Simple Design</a></em>.</p>
<script async="" src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
<p>Thanks to <a href="https://twitter.com/fablednet">Sarah Gray</a> for proof-reading this post.</p>
Some thoughts on pair-programming styles2014-03-16T00:00:00+00:00http://articles.coreyhaines.com/posts/thoughts-on-pair-programming<p>Over the past 10 years of practicing extreme programming, I’ve done a lot of pairing; I’ve worked in traditional pairing styles, and I’ve written code with people in less-traditional places. I’ve worked with folks who have been pairing much longer than I have, and other who had never written code like this before.</p>
<p>And over the past 5 years of facilitating coderetreat workshops, I’ve watched a lot of people in different pair-programming situations. I’ve watched people who have never written code with someone else, and I’ve looked over the shoulders of people who have been writing code in pairs for years.</p>
<p>All of this time spent both doing and watching has given me some thoughts around the technique. So, I thought I would write down some observations and thoughts I’ve developed over the years regarding pair-programming, specifically around a couple different styles.</p>
<h2 id="driver-navigator">Driver-Navigator</h2>
<p>Traditionally, pair-programming has been introduced via the <a href="http://guide.agilealliance.org/guide/pairing.html">Driver-Navigator</a> form. In this form, one member, The Driver, has the keyboard and control of the input. Their job is to type and focus on the minute-to-minute coding. The other member is The Navigator. Their job is to pay attention to the code being written, but keep the larger picture in mind, guiding the driver in the right direction. Frequently, the roles should be swapped.</p>
<p>Unfortunately, too often this form of pair-programming leads to what I call the “Driver-Twitterer” style of collaboration. In this mode, the person with the keyboard is writing code while the other person watches intently for a short time. Then, after a bit, the navigator starts to lose interest. Perhaps the driver isn’t talking, perhaps the navigator doesn’t want to disturb them. Sometimes I’ve seen where the driver says “just a second, I’ve got an idea,” and then proceeds to code in silence for minutes on end. As expected, this can have the effect of boring the navigator. So, what do they do? Naturally, they check twitter, or email, or some other non-code-focused task.</p>
<p>Now, the above situation isn’t what is <em>supposed</em> to happen, but I see it end up like that way too often. As with every aspect of development, communication is key here. But, without practice, driver-navigator level of communication can be difficult to achieve. In order for this style to work, the pair needs to have good communication habits, constantly keeping the other abreast of what thoughts are going through their head. Unfortunately, this level of communication isn’t necessarily built-in to a new pair. Because of this intense communication requirement, I generally consider the driver-navigator style of pair-programming to be a more intermediate level style, and I guide new people away from it.</p>
<p>It is quite common for a coderetreat workshop to be a person’s first time pair-programming, their introduction to the practice of writing code in an intense collaborative style. Because of this, I like to introduce them with a pairing form that has the necessary level of communication built-in to the practice. The style I introduce is called “Ping-Pong Pairing.”</p>
<h2 id="ping-pong-pairing">Ping-Pong Pairing</h2>
<p>There are two basic forms of ping-pong, but they both share on very important aspect: both members are writing code frequently. Because of this, I stress the importance of having two sets of live input devices, one for each participant. So, there would be two keyboards and two mouses, both live. I find that having this setup minimizes the context shift when switching who is typing. Having two live input devices isn’t a requirement, of course, but it definitely can help smooth over some inherent friction that can arise if you have to pass the keyboard back and forth.</p>
<p>The first style of ping-pong is where one member takes on the role of test writer, and the other takes on the role of getting the tests to pass. I like to call the test writer the <strong>“test redder”</strong> and the one getting them to pass the <strong>“test greener”</strong>. The table below illustrates the flow of control.</p>
<table>
<thead>
<tr>
<th>member 1</th>
<th>member 2</th>
</tr>
</thead>
<tbody>
<tr>
<td>write test</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td>make test green</td>
</tr>
<tr>
<td>write test</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td>make test green</td>
</tr>
</tbody>
</table>
<p>The second style of ping-pong is where the role of “test redder” passes between participants. This is done by having the first member write a test, then control is passed to the other member. That person gets the test to pass, to turn green, then they are immediately responsible for writing the next test. The table below illustrates the flow of writing.</p>
<table>
<thead>
<tr>
<th>member 1</th>
<th>member 2</th>
</tr>
</thead>
<tbody>
<tr>
<td>write test</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td>make test green</td>
</tr>
<tr>
<td> </td>
<td>write next test</td>
</tr>
<tr>
<td>make test green</td>
<td> </td>
</tr>
<tr>
<td>write next test</td>
<td> </td>
</tr>
<tr>
<td> </td>
<td>make test green</td>
</tr>
<tr>
<td> </td>
<td>write next test</td>
</tr>
</tbody>
</table>
<p>The primary difference between these two is that in the first form, the role is stable, but control is passed. In the second, the role is passed along with control. Both can be effective and great ways to introduce people to pair-programming.</p>
<h2 id="which-style-should-you-choose">Which style should you choose?</h2>
<p>If you are working in an experienced pairing, both members are experienced at some form of collaborative code writing, then it doesn’t matter which style you use. In fact, it is common to see all styles used through a pairing session, cycling through all types. With experience, participants generally have developed the level of communication necessary for working in whatever form is useful at the moment, and the moments and pairing needs change throughout a programming session.</p>
<p>As I mentioned above, though, I consider driver-navigator a more intermediate style. So, if one, or both, of the participants are new to pair-programming, then ping-pong can be a fantastic way to introduce the concepts. I generally recommend a specific ping-pong style based on the level of testing experience of the members.</p>
<ul>
<li>
<p>One member has experience writing tests, but the other doesn’t = Form 1</p>
<p>Beginning with having the experienced person writing most of the tests is the most effective. Over time, the less-experienced person can start writing some tests. By watching the tests being written, though, they can learn the thought process behind test-driven development.</p>
</li>
<li>
<p>Both members have experience writing tests = Form 2</p>
<p>I generally recommend the second form, where control of input is passed back and forth. This gives a good workout of both roles in a pairing situation.</p>
</li>
</ul>
<p>Pairing is a fantastic way to develop software. I’ve written some of my best code, my best systems, when most of it was written with two people’s hands on a keyboard together. At the end of a coderetreat, it is very common to get the feedback from first-timers that they didn’t expect working in a pair to be so productive. Pair-programming is listed frequently in the closing questions as both surprising and what they will take with them going forward.</p>
<p>Thanks to <a href="https://twitter.com/fablednet">Sarah Gray</a> for proof-reading this post.</p>
Thoughts on the symmetry between good test names and your object's API2014-03-06T00:00:00+00:00http://articles.coreyhaines.com/posts/test-names-should-influence-design<p>While running <a href="http://coderetreat.org/">coderetreats</a>, I have the opportunity to see a lot of people working on <a href="http://en.wikipedia.org/wiki/Conway%27s_game_of_life">Conway’s Game of Life</a>. As we go through the day, I make comments about design, both in the large and in the small. Over the years, I’ve seen similar patterns pop up across many different developers. This article is one of those ideas that has come up over the years.</p>
<p>One of the <a href="http://c2.com/cgi/wiki?XpSimplicityRules">4 Rules of Simple Design</a> is “Expresses Intent.” In a lot of cases, this can be thought of as “Good Names.” The idea of naming, and how it relates to the intent of your code, can be seen when looking at the symmetry between test names and the test code.</p>
<p>In Conway’s Game of Life, a common approach is to start with a World class. Since one of the techniques we practice at coderetreat is test-driven development, they start with a test. A common starting point is that a living cell can be added. I see the following 2 tests quite often.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">test_a_new_world_is_empty</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">assert_equal</span> <span class="mi">0</span><span class="p">,</span> <span class="n">world</span><span class="p">.</span><span class="nf">living_cells</span><span class="p">.</span><span class="nf">count</span>
<span class="k">end</span>
<span class="k">def</span> <span class="nf">test_a_cell_can_be_added_to_the_world</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">world</span><span class="p">.</span><span class="nf">set_living_at</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">1</span><span class="p">)</span>
<span class="n">assert_equal</span> <span class="mi">1</span><span class="p">,</span> <span class="n">world</span><span class="p">.</span><span class="nf">living_cells</span><span class="p">.</span><span class="nf">count</span>
<span class="k">end</span></code></pre></figure>
<p>On the surface, these seem like reasonably-written tests. However, let’s look at it from the idea that the tests should express intent. There is an obvious mismatch between the test names and the code in the test.</p>
<p>Let’s look at the first one, since this probably the simple one that we write first.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">test_a_new_world_is_empty</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">assert_equal</span> <span class="mi">0</span><span class="p">,</span> <span class="n">world</span><span class="p">.</span><span class="nf">living_cells</span><span class="p">.</span><span class="nf">count</span>
<span class="k">end</span></code></pre></figure>
<p>The test name talks about an empty world. The test code, though, has nothing to do with an empty world. Instead, it is brutally reaching into the object, yanking out some sort of collection and counting it.</p>
<p>When we write our tests, we naturally spend time on our test names. We focus on describing the behavior of the system and the way we expect to use the component under test. Especially when starting a new component, we can use our test names to influence and mold our API. Think of the test as the first consumer of the component; it should interact with the object the same way as the rest of the system. Do you want the rest of the system to be reaching in and grabbing the internal collection. No, of course you don’t. Instead, have the test code reflect the test name. How about something like this.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">test_a_new_world_is_empty</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">assert_true</span> <span class="n">world</span><span class="p">.</span><span class="nf">empty?</span>
<span class="k">end</span></code></pre></figure>
<p>This hides the internals of the object, all the while building up a usable API for the rest of the system.</p>
<p>Now, let’s look at the second test.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">test_a_cell_can_be_added_to_the_world</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">world</span><span class="p">.</span><span class="nf">set_living_at</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">1</span><span class="p">)</span>
<span class="n">assert_equal</span> <span class="mi">1</span><span class="p">,</span> <span class="n">world</span><span class="p">.</span><span class="nf">living_cells</span><span class="p">.</span><span class="nf">count</span>
<span class="k">end</span></code></pre></figure>
<p>After the previous discussion, we can see the lack of symmetry here. The test name talks about adding to the world, but the verification step isn’t looking for the cell that was added, it is simply looking to see if a counter was incremented. Let’s apply the symmetry again and have the test code actually reflect what we say is being tested.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">test_a_cell_can_be_added_to_the_world</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">world</span><span class="p">.</span><span class="nf">set_living_at</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">1</span><span class="p">)</span>
<span class="n">assert_true</span> <span class="n">world</span><span class="p">.</span><span class="nf">is_living_at?</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">1</span><span class="p">)</span>
<span class="k">end</span></code></pre></figure>
<p>This now adds to our API. Additional tests, of course, will flush out the behavior of these methods, but we now have begun to build up the usage pattern for this object.</p>
<p>We also could add a test around the #empty? method using #set_living_at.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">test_after_adding_a_cell_the_world_is_not_empty</span>
<span class="n">world</span> <span class="o">=</span> <span class="no">World</span><span class="p">.</span><span class="nf">new</span>
<span class="n">world</span><span class="p">.</span><span class="nf">set_living_at</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">1</span><span class="p">)</span>
<span class="n">assert_false</span> <span class="n">world</span><span class="p">.</span><span class="nf">empty?</span>
<span class="k">end</span></code></pre></figure>
<p>This is another way of slowly building up the API, especially the beginnings of the #set_living_at behavior.</p>
<p>Focusing on the symmetry between a good test name and the code under tests is a subtle design technique. It is definitely not the only design influence that our tests can have on our code, but it can be an important one. So, next time you are flying through your tdd cycle, take a moment to make sure that you are actually testing what you say you are testing.</p>
<p>Thanks to <a href="https://twitter.com/fablednet">Sarah Gray</a> for proof-reading this post.</p>
"Iterating over a list and filtering" OR "Iterating over a filtered list"
2013-09-22T00:00:00+00:00http://articles.coreyhaines.com/posts/iteration-styles<h2 id="noticing-a-pattern">Noticing a pattern</h2>
<p>The other day, I was working on some list-processing code. The system was serializing a set of commands to send to another server for further execution. Only a subset of the commands needed to be sent, so each serialization routine was responsible for filtering its child objects. I noticed an interesting pattern around the filtering, and I started thinking.</p>
<h2 id="processing-a-list">Processing a list</h2>
<p>Suppose I’m writing a system that manages items and actions on those items. We might have a class called Command. Each of these commands represents one of four types of actions: Update, Create, Contract or Expand.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">class</span> <span class="nc">Command</span>
<span class="nb">attr_accessor</span> <span class="ss">:type</span>
<span class="k">def</span> <span class="nf">to_json</span>
<span class="c1">#generate json here</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
<p>In my program, I get an unfiltered list of these that I need to send to another system. I could send them individually, but I want to instead batch them up into a single message.</p>
<h3 id="only-interested-in-a-subset">Only interested in a subset</h3>
<p>But, the other system isn’t interested in all the types of commands, just Updating and Creating. The other types, Expanding and Contracting, have slightly more complex rules around them, so we are handling them separately.</p>
<h3 id="filtering-with-next-if-condition-statements">Filtering with “next if <em>condition</em>” statements</h3>
<p>This is a very common problem that comes up in code, and there are different ways to solve it. In this situation, the programmers chose to use the following construct, iterating with Enumerable#each and guarding against the undesired commands with a set of “next if <em>condition</em>” statements.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="c1"># the json variable is defined higher up as a json builder object</span>
<span class="n">commands</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="k">next</span> <span class="k">if</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s2">"expand"</span>
<span class="k">next</span> <span class="k">if</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s2">"contract"</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<h3 id="my-reaction-ugh-should-use-select-then-each">My Reaction: Ugh! Should use #select then #each</h3>
<p>As I bounced around the codebase, I noticed this pattern in several places. Some had a single “next if” and others had quite a few. My initial reaction to this was “Ugh! Stinky! I prefer to use #select, followed by #each” The use of this pattern wasn’t related to the bug I was helping resolve, so I just passed over it, although I’m sure I made a small grunting noise.</p>
<blockquote>
<p>Note: There is another smell here around the closure over the variable, json. I won’t be talking about that.</p>
</blockquote>
<h3 id="why-this-reaction-what-is-wrong-with-this-pattern">Why this reaction? What is wrong with this pattern?</h3>
<p>The code worked.</p>
<p>So, why did I have this reaction to that pattern? What makes me strongly prefer a filter/process approach over a simple loop/(short-circuit/process) one? Over the past few years, I’ve become fascinated by the idea of understanding “why” one uses a certain technique. As I’ve been teaching more, I find myself sharing the idea “I don’t care how you do it, as long as you have a justifiable, thought-out reason for it.” It is common to challenge people to explain their decisions in terms of fundamentals, principles like <a href="http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod">SOLID</a> and the <a href="http://c2.com/cgi/wiki?XpSimplicityRules">4 Rules of Simple Design</a>.
So, why not hold myself to the same standard? What is my “justifiable, thought-out reason” for disliking this pattern and preferring a filter/process approach?</p>
<h3 id="whats-the-difference">What’s the difference?</h3>
<p>In order to compare them, it helps to characterize the two patterns. Is there a fundamental difference between them? After some thought, I came to a statement of difference as <strong>“Iterating over a list and filtering”</strong> and <strong>“Iterating over a filtered list.”</strong> Once I had this differentiation, I could spend some time thinking of them independently.</p>
<h2 id="iterating-over-a-list-filtering">Iterating over a list, filtering</h2>
<h3 id="a-common-pattern">A common pattern</h3>
<p>The first form, iterating over a list, doing all the work in the loop body, is fairly common. In the case above, for example, the filtering/processing were inter-mingled in the same clause. As a reminder, this is what it looks like.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="n">commands</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="k">next</span> <span class="k">if</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s2">"delete"</span>
<span class="k">next</span> <span class="k">if</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s2">"transfer"</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<h3 id="used-to-be-the-main-technique">Used to be the main technique</h3>
<p>Back before most languages adopted iterator-style syntax, we all did our loops with a for statement: doing explicit iteration over a list, embedding our guard clauses into the block, itself.</p>
<figure class="highlight"><pre><code class="language-javascript" data-lang="javascript"><span class="k">for</span><span class="p">(</span><span class="kr">int</span> <span class="nx">i</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span> <span class="nx">i</span> <span class="o"><</span> <span class="nx">commands</span><span class="p">.</span><span class="nx">count</span><span class="p">;</span> <span class="nx">i</span><span class="o">++</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span><span class="p">(</span><span class="nx">command</span><span class="p">[</span><span class="nx">i</span><span class="p">].</span><span class="nx">type</span> <span class="o">===</span> <span class="s1">'update'</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">// Process this command</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p>or, perhaps your language supported an index-free form</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">for</span> <span class="n">command</span> <span class="k">in</span> <span class="n">commands</span>
<span class="k">if</span><span class="p">(</span><span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s1">'update'</span><span class="p">)</span>
<span class="c1"># Process this command</span>
<span class="k">end</span>
<span class="k">end</span></code></pre></figure>
<h3 id="enumerableeach-becomes-the-thing-to-use">Enumerable#each becomes “the thing to use”</h3>
<p>As languages introduced (or, in certain cases, people discovered the language support) enumerator-style syntaxes, people began abandoning the explicit looping constructs. In Ruby, Enumerable#each became all the rage, leaving the lowly <em>for</em> keyword sad and abandoned, looking for things to loop over, calling out in the night, dreaming of the day when it, too, could yield up items without fear of over-flowing bounds.</p>
<p>Using this newer style feels strong. This abstraction of iteration almost feels safer. It feels “functional.” There is a sense of extracting the loop semantics from the processing, which feels a bit more maintainable, too. The conversion is fairly easy, too, just take whatever was in the body of the for loop and move it to the body of the #each call.</p>
<p>###But often the switch stops there</p>
<p>Often the switch often stops here. The satisfaction of using Enumerable#each, especially without thought of the “why,” leads to a sense of stability. So, we don’t continue in converting our mindset to a more list-processing style.</p>
<h3 id="what-value-does-enumerableeach-give-over-the-for-statement">What value does Enumerable#each give over the <em>for</em> statement?</h3>
<p>Stopping here begs the question of value, though. Is there a fundamental difference between a for-loop and calling #each with a block? Especially when the language already provides an index-free looping construct, such as Ruby’s for.</p>
<p>After all, we’re still effectively combining all the processing together. Although it feels “functional,” we should ask ourselves what that means and whether this really exemplifies the “functional” philosophy.</p>
<h2 id="iterating-over-a-filtered-list">Iterating over a filtered list</h2>
<h3 id="and-is-often-an-indication-that-a-process-is-doing-too-much">“And” is often an indication that a process is doing too much</h3>
<p>Whenever I find a description of a style that contains the word “and,” such as “iterating over a list and filtering,” I take it as a sign that there could be a different, more decoupled way to do this. “And” often signals that a process is doing too many things. This can be bad, as it often mixes concerns, coupling together several responsibilities. The result often is difficulty changing the code when the time comes.</p>
<h3 id="splitting-the-and">Splitting the “And”</h3>
<p>One technique I use when looking at a process that includes an “and” is to see if each clause’s responsibility can be satisfied separately. In our case, we have “iterating and filtering,” so let’s look at doing these two processes separately. Moving them separately leads to “Iterating over a filtered list,” where the filtering has already been done.</p>
<h3 id="thinking-in-small-chunks">Thinking in small chunks</h3>
<p>Splitting the different tasks into separate parts allows us to think in terms of the individual responsibilities. For example, what is the result of filtering? What is the task that is being done on each element?</p>
<p>This could look like the following bit of code.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="n">commands</span><span class="p">.</span><span class="nf">select</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="p">[</span><span class="s2">"create"</span><span class="p">,</span> <span class="s2">"update"</span><span class="p">].</span><span class="nf">include?</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span>
<span class="k">end</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<p>or, if it makes more sense to talk about what <em>isn’t</em> included</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="n">commands</span><span class="p">.</span><span class="nf">reject</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="p">[</span><span class="s2">"delete"</span><span class="p">,</span> <span class="s2">"transfer"</span><span class="p">].</span><span class="nf">include?</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span>
<span class="k">end</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<h2 id="splitting-allows-you-to-name-the-pieces">Splitting allows you to name the pieces</h2>
<p>By decomposing purposefully into a filter/process step, you can improve the readability of the code.</p>
<h3 id="what-is-the-actual-list-being-processed">What is the actual list being processed?</h3>
<p>In our example, when we separate out the filter step from the processing step, we also give ourselves a way to better reveal the goal, explicitly naming our list to process.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="k">def</span> <span class="nf">creation_based_commands</span>
<span class="nb">self</span><span class="p">.</span><span class="nf">commands</span><span class="p">.</span><span class="nf">select</span> <span class="p">{</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span> <span class="p">[</span><span class="s2">"create"</span><span class="p">,</span> <span class="s2">"update"</span><span class="p">].</span><span class="nf">include?</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="p">}</span>
<span class="k">end</span>
<span class="n">creation_based_commands</span><span class="p">.</span><span class="nf">each</span> <span class="p">{</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span> <span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span> <span class="p">}</span> </code></pre></figure>
<p>This isn’t always needed, but it is worth thinking about the person who is going to come to this codebase later to make a change. In general, the more explicit we are, the better.</p>
<p>After all, “Reveals Intent” is one of the <a href="http://c2.com/cgi/wiki?XpSimplicityRules">4 Rules of Simple Design</a>.</p>
<p>##Iterating over a list, filtering - have to think about what the filter is for
When you come to code that looks like this.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="c1"># the json variable is defined higher up as a json builder object</span>
<span class="n">commands</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="k">next</span> <span class="k">if</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s2">"delete"</span>
<span class="k">next</span> <span class="k">if</span> <span class="n">command</span><span class="p">.</span><span class="nf">type</span> <span class="o">==</span> <span class="s2">"transfer"</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<p>You have to spend some time thinking “why aren’t these included?” “Are there others?” or “Should I add my new type to this list?”</p>
<h2 id="iterating-over-a-filtered-list---provide-opportunity-to-explicitly-name-the-concept-that-the-filtered-list-represents">Iterating over a filtered list - provide opportunity to explicitly name the concept that the filtered list represents</h2>
<p>This focus can also be used to effectively put a name on the filter. By separating the filtering into a first-class part of your processing, you can more clearly communicate the intent.</p>
<h2 id="could-just-combine-all-the-next-if-values-into-an-array">Could just combine all the “next if” values into an array</h2>
<p>Is splitting into a filter/process flow the only one? Surely we could just encapsulate the name of the types into an array and use that.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="c1"># the json variable is defined higher up as a json builder object</span>
<span class="n">commands</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="k">next</span> <span class="k">unless</span> <span class="no">CREATION_TYPES</span><span class="p">.</span><span class="nf">include?</span><span class="p">(</span><span class="n">command</span><span class="p">.</span><span class="nf">type</span><span class="p">)</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<h3 id="this-works-okay-for-simple-cases-but-still-suffers-from-some-of-the-issues-outlined-above">This works okay for simple cases, but still suffers from some of the issues outlined above</h3>
<p>This can be tempting. And, as an initial step, it isn’t too bad. This works reasonable well for simple cases like this, but starts to degrade a bit when we have more complex logic. That complex logic could be encapsulated in a method.</p>
<figure class="highlight"><pre><code class="language-ruby" data-lang="ruby"><span class="c1"># the json variable is defined higher up as a json builder object</span>
<span class="n">commands</span><span class="p">.</span><span class="nf">each</span> <span class="k">do</span> <span class="o">|</span><span class="n">command</span><span class="o">|</span>
<span class="k">next</span> <span class="k">unless</span> <span class="n">creation_command?</span><span class="p">(</span><span class="n">command</span><span class="p">)</span>
<span class="n">json</span> <span class="o"><<</span> <span class="n">command</span><span class="p">.</span><span class="nf">to_json</span>
<span class="k">end</span></code></pre></figure>
<p>By doing this, we’ve extracted the logic for the filtering to another place. At this point, though, we are just a simple step away from a full decoupling. Should we take the last step?</p>
<p>##Inhibiting change
One argument for taking the last decoupling step is that it will make the code easier to change in the future. Paying attention to the Single Responsibility Principle (SRP) at this low level can often pay off when we come back to the code. We’ll talk about that in a later section on analyzing the code based on SRP and the Open-Closed Principle to this code.</p>
<p>##Theory Talk
###Filtering/Transforming/Using</p>
<p>When decomposing a complex process into steps like this, I think in terms of Filter/Transform/Reduce/Use.</p>
<ul>
<li>Filter - Generate a subset of a list, based on a certain quality of each item.</li>
<li>Transform - Generate a new list consisting of elements based on their respective original element.</li>
<li>Reduce - Collapse a list into a single element.</li>
<li>Use - Act in some fashion on each element of a list, generally resulting in a side-effect.</li>
</ul>
<p>Decomposing a process into these is really a matter of building a composition-based pipeline for the data you are processing.</p>
<p>###Data pipelining</p>
<p>Data pipelining is a method for focusing on the workflow and transformations that a set of data undergoes when processing.</p>
<p>###Each technique has a focus and point</p>
<p>A major benefit of pipelining in this fashion is that each step has a strong focus and point. While the final composition might have complex behavior, the individual parts are easily understood as a step in the final process. Having small, focused parts help in maintaining code, moving us closer to the SOLID principles.</p>
<p>###SRP</p>
<p>####Each clause should have a single reason to change</p>
<p>For example, when decomposed properly, each step can be looked at as abiding by the Single Responsibility Principle. That is, each step has a single reason to change. If the filtering needs to change, it can be altered independently of the future processing. Any transformation or processing of the filtered set can be very explicit and focused on what needs to be done.</p>
<p>###OCP</p>
<p>####Enhancements can often be made by adding clauses, rather than changing existing ones</p>
<p>Just like effective object decomposition, breaking into small, focused clauses can help gain the benefits of the Open-Closed Principle. If you need to alter the workflow, you can often do this by adding clauses, rather than changing existing ones.</p>
<h3 id="unix-mentality">Unix mentality</h3>
<h4 id="pipelining-through-single-fit-for-purpose-utilities">Pipelining through single, fit-for-purpose utilities</h4>
<p>Data pipelining of this fashion isn’t really a new or ground-breaking idea. Most of us spend time on the unix command-line, where a world of small, focused utilities is an environment we live in. Think of all the wonderfully complex actions that can be done by just stringing simple steps together. For example, here’s a script to calculate the <a href="https://github.com/garybernhardt/dotfiles/blob/master/bin/git-churn">churn in files in your git repository</a>.</p>
<p>##Concerns</p>
<p>###Iterating multiple times over list
One of the major push backs on this style of list processing is the idea that you are then iterating multiple times over the same list. If you have N items, then you feasibly could be looping M#N times, where M is the number of steps in your process.</p>
<p>My first response is that this rarely is an issue that will affect you. In general, readability and maintainability trump this level of optimization.</p>
<p>Now, if your lists get to the size where this does cause problems, you can always look at lazy iterators. These chain the iterator, itself, rather than a primitive data structure, such as an Array. Some languages do this by default, and Ruby 2.0 has <a href="http://ruby-doc.org/core-2.0.0/Enumerable.html#method-i-lazy">added them to the standard library</a>.</p>
<p>###Difficulty in understanding / tracking process
Another common complaint is that separating these steps out can deter understanding/comprehension of what is going on and what the final result should be.</p>
<p>Of course, this is a common complaint against object decomposition, as well. As I like to say, “I’ve not really seen too many classes, but I’ve seen a lot of crappy abstractions.” I think that sentiment comes into play in the situation here, as well. When decomposing a series of steps, it can be important to think about the flow of the data in understandable, readable steps.</p>
<h2 id="benefit---can-be-easier-to-debug">Benefit - Can be easier to debug</h2>
<p>When separating a process into small, composable pieces, we often find the system is much easier to debug. Each step can be run individually to verify that it is doing its job correctly.</p>
<p>###Composition can be tested at different levels
If we have a problem with the fully-composed pipeline, we can more easily debug it by separating out different levels of composition to see that the data is processed correctly each step of the way.</p>
<p>###Examples for each piece can provide clarity
Each individual piece can be tested in isolation. Not just testing for verification, though, but also for clarity. The set of examples we write while isolation testing can give valuable feedback on the purpose of the unit.</p>
<p>Thanks to <a href="https://twitter.com/fablednet">Sarah Gray</a> for proof-reading this post.</p>