PragPub 2011-01: Issue #19

Table of Contents

Features

Grokking Pattern Matching and List Comprehensions

by Bruce Tate

Bruce explores two powerful features of modern programming languages that can make your code more beautiful and you more productive.

Everyday JRuby

by Ian Dees

Wherein Ian creates a simple game and then shows you several ways to deploy it.

Code Coupling

by Tim Ottinger, Jeff Langr

Those big software design concepts like coupling, cohesion, abstraction, and volatility have real practical value. In this article, Tim and Jeff talk about what coupling is, why it’s necessary, and how you can reduce it to just that necessary amount.

Rediscovering QA

by Chris McMahon

Software Quality Assurance is more than testing. The breadth of knowledge necessary for really good QA work are surprisingly broad.

When Did That Happen?

by Dan Wohlbruck

Dan continues his series on the history of technology with a look at the index register.

Departments

Up Front

by Michael Swaine

We Friend Your Curiosity

Choice Bits

A good aphorism is part wit, part wisdom. A typical tweet is half witted.

Guru Meditation

by Andy Hunt

Why adopting agile methods might be harder than you think.

Calendar

Here’s how 2011 is shaping up.

Shady Illuminations

by John Shade

John examines the drama of wikileaks and concludes that the heroes are the genie and the butterfly.

Except where otherwise indicated, entire contents copyright © 2011 The Pragmatic Programmers.

Feel free to distribute this magazine (in whole, and for free) to anyone you want. However, you may not sell this magazine or its content, nor extract and use more than a paragraph of content in some other publication without our permission.

Published monthly in PDF, mobi, and epub formats by The Pragmatic Programmers, LLC, Dallas, TX, and Raleigh, NC. E-Mail support@pragprog.com, phone +1-800-699-7764. The editor is Michael Swaine (mailto:michael@pragprog.com). Visit us at http://pragprog.com

ISSN: 1948-3562

Up Front

We Friend Your Curiosity

by Michael Swaine

What does it mean that this year began with Facebook surpassing Google in hits? So large a fact, distilled from so many individual human choices, must mean something about what it is to be human in the 21st century. But what?

Does it mean that we’re more friendly than curious?

If so, that might be a good thing, but here at the start of 2011 and of this issue of PragPub, I’m banking on your curiosity.

If you have a healthy curiosity about programming languages, you’ll enjoy Bruce Tate’s exploration of language features that can make your individual coding style more powerful and artful.

If you’re curious about how you can get a better view of the big picture in your development work, seeing it whole and from the user’s perspective, you’ll appreciate Chris McMahon’s thoughts on software quality assurance, a discipline that doesn’t always get enough respect or attention.

Jeff Langr and Tim Ottinger will satisfy your curiosity about one particular aspect of agile development, Ian Dees’ series on everyday JRuby will enlighten you about methods for sharing your code, Dan Wohlbruck will satisfy your history itch with a shamelessly nerdy retrospective on the index register. Andy Hunt will tell you Why Johnny Can’t Be Agile, and John Shade will share his take on the phenomenon of wikileaks.

So that’s what’s in this issue. In case you were curious.

Choice Bits

We thought you might like to know...

A few selected sips from the Twitter stream.

What’s Hot

Top-Ten lists are passé—ours goes to 11. These are the top titles that folks are interested in currently, along with their rank from last month. This is based solely on direct sales from our online store.

1^ | 2 | Agile Web Development with Rails
2^ | 3 | The RSpec Book
3v | 1 | Crafting Rails Applications
4^ | 6 | Hello, Android
5 | 5 | Seven Languages in Seven Weeks
6v | 4 | Programming Ruby 1.9
7^ | NEW | iPhone SDK Development
8^ | NEW | The Definitive ANTLR Reference
9^ | NEW | Cocoa Programming
10v | 7 | HTML5 and CSS3
11^ | NEW | Learn to Program

Inquiring Minds Couldn’t Care Less

Twitter is a great place to ask those questions that you just have to ask but that nobody’s going to answer.

Why the heck does it take Leopard so long to install? — @HuntHenning

Do you write Cucumber features in Romanian? — @aslak_hellesoy

Don’t you play music when you code? — @louielouie

Do you use zillow.com to see how property you used to own is doing? — @davewiner

Are you a Groovy guy, then, looking for some cool tips and finding none? — @SamirTalwar

Don’t all good projects start with a ‘G’? — @matthewmccull

Can you contribute to mine instead of maintaining your own? — @edavis10

Who will do for Prolog what Clojure has done for Lisp? — @puredanger

Anyone in the twitterverse have a recommendation for a hair-clogged drain? — @squarepegsys

Any recommendations for a good work-friendly coffee shop around Lincolnwood/Rogers Park? — @eng

What iPad applications are a must for me to try out? — @JEG2

Are we witnessing Agile Bread Development? — @dimsumthinking

Wait, what? When? — @rit

Damn, the word “acknowledgements” is so long. Can we call it A14S from now on? — @bphogan

Acknowledgements

You did it! You totally have the right to brag.

First review of Japanese Pomodoro Technique Illustrated comes from Gordon Pask awarded Kenji Hiranabe http://bit.ly/hjxP2C — @staffannoteberg

#GQuick has another 5-star review: "The best 200 pages of technical literature I have ever read." http://amzn.to/hDAZKi — @daveklein

Just blogged: Driving Technical Change book review—http://bit.ly/gGKn0O — @pragdave

First audio interview describing the genesis of the Agile Samurai is now available via Pragmatic Bookshelf—wp.me/pt5cX-oF — @jrasmusson

It’s official, I’ll be joining Microsoft as the GM for System Experience in the Interactive Entertainment Business: http://is.gd/jc9AO — @rahulsood

I earned the Radiohead(50) sticker on @GetGlue! http://bit.ly/fsz6tG — @chadfowler

New on Ihnatko.com: Why I’m better than the banking industry. http://bit.ly/i18niX — @Ihnatko

Yay, only 15 failures left in my test suite. Then on to all the prototype JS stuff that no longer works. #rails3upgrade — @bphogan

Tweets of Science

Scientists link size of amygdala to size, complexity of person’s social networks. http://bit.ly/f9Z8Bp — @hrheingold

Ray Kurzweil reckons he knows how to live forever. So how’s that working out for him so far? http://bit.ly/h8LXJv — @newscientist

Would a hamster & a dog survive if dropped from on high? The RI Christmas lectures—BBC 4: 28, 29, 30 Dec, 8 pm http://bit.ly/gLyyNr — @newscientist

The t-distribution in statistics was invented by the guy responsible for quality control in the Guinness Brewery. Another triumph for beer. — @marick

Mathematics is the only subject that many people BRAG about hating. — @janetbyronander

Solar panels for your pants. http://idek.net/3gGm — @GuyKawasaki

The Coding Life

A woman tells her programmer husband: “Get me a quart of milk? And if they have eggs, get a dozen.” He comes back with 12 quarts of milk. — @bphogan

I just found myself touching a word in a paper book, hoping to get a definition. — @pragdave

When working against deadlines involving computers, don’t get your eyes dilated by the optometrist. #lessonlearnetoolate #cantfocus — @adamgoucher

The easiest way to shut down WikiLeaks would be to have Yahoo acquire it. http://read.bi/eiyeZJ — @hblodget

One good way to learn your bug fix was correct: People complain that their “loophole” code stopped working because of the bugfix. — @rit

Opportunity lost: “Welcome to day one at your new job, here’s a memo about the dress code.” http://www.jdwalt.com/?p=67 — @theworkinggeek

Listening to the Tron soundtrack while I code makes me feel way, way cooler than I actually am. — @benrady

Tweets of Wisdom

There is no writing, only rewriting. There is no coding, only refactoring. There is no testing, only feedback. — @PragmaticAndy

Institutions will try to preserve the problem to which they are the solution. — @cshirky

If people are not trying to hire your employees, you have the wrong employees. And if they leave, you have the wrong model. — @adamgoucher

Job boards no more “help” you find a job than a billboard “helps” you find a new pair of shoes. http://bit.ly/aRecvK — @theworkinggeek

Efficient is othogonal to Effective! — @staffannoteberg

It says a lot about humanity that the word “hypocrite” has no antonym. — @trevorburnham

I haven’t read the #pomodoro book yet, but just thinking about it makes me focus more. — @javaHelena

The senti-mentalist: “Think of a card. Maybe it was your favorite card from back-porch games of Whist with your grandfather….” — @undees

If you want others to be happy, practice compassion. If you want to be happy, practice compassion. — @DalaiLama

Snow Tip: The other people out shoveling are called “neighbors.” They are like Facebook friends who live nearby. — @pourmecoffee

Life Is Frustrating, but then a Cool App Comes Along, and Everything’s Great

I’ve failed after 4 attempts to enter the right Capcha on this registration site—I am no longer human. — @venkat_s

“Nor can we currently ship Nexus S orders to Canadian addresses.” #foiled — @adamgoucher

Isle of Man is crazy. As part of the entry you have to assure them the cost of transporting your corpse is already covered. — @wolever

#amigos can call it a Crisp Meat Burrito all they want; they’ll never convince me that the name is more than 2/3 true. — @scottdavis99

Gave a demo of Word Lens to my wife. Thought she was going to pass out. — @eng

Gonna be a lot of angry frat boys when Word Lens starts translating Kanji tattoos. — @ryanirelan

London kids throwing snowballs at me in the street. Hit one back in the face. Fun! — @aslak_hellesoy

After much soul-searching, we decided to clean up the spelling and punctuation and so forth in the tweets we found. So the people credited actually said what we credited them with saying, but not necessarily precisely how we said they said it. This month those people included Dion Almaer, Janet Byron Anderson, Henry Blodget, Trevor Burnham, Eric Davis, Ian Dees, Luis de la Rosa, Brian Eng, Chad Fowler, Adam Goucher, James Edward Gray II, Aslak Hellesøy, Hobie Henning, Helena Hjertén, Brian Hogan, Mike Hostetler, Andy Hunt, Andy Ihnatko, Ryan Irelan, Guy Kawasaki, Dave Klein, Dalai Lama, Andy Lester, Brendan W. McAdams, Matthew J McCullough, Brian Marick, Alex Miller, New Scientist, Staffan Nöteberg, @pourmecoffee, Ben Rady, Jonathan Rasmusson, Howard Rheingold, Clay Shirky, Rahul Sood, Daniel Steinberg, Venkat Subramaniam, Samir Talwar, Dave Thomas, Dave Winer, and David Wolever. Fair is fair: you can follow us on twitter.

Twitter is now complete. @slightlylate has joined the party. Call it done! — @dalmaer

Guru Meditation

Why Johnny Can’t Be Agile

by Andy Hunt

Your brain is not wired to work with agile methods.

Ten years ago in February, at Snowbird in Salt Lake City, Utah, I was hanging out with 16 notable folks who cared deeply about software development. We talked about many things, all around the general theme of what to that point had been called “light-weight processes.”

But “light-weight,” while perhaps technically correct, carried connotations of insufficiency. So after some discussion, we all agreed on coining the term agile. And thus the Agile Manifesto and the eponymous movement were born.

But agile techniques were a hard sell. Even simple, non-controversial practices such as version control weren’t yet universally adopted. I used to ask audiences at talks how many people did not use any version control on their project. Typically somewhere between 10% and 30% of the audience raised their hands. It wasn’t that folks were dead set against using version control on religious grounds, they either just didn’t know any better or just didn’t bother.

So surely this was just a matter of education; of spreading the word. Agile methods made sense. Agile ideas are grounded in reality, and even some actual science. Surely the world would see the logic in it? You’d expect some amount of resistance to any new way of developing software—especially one where continuing to Embrace Change was part and parcel of the new method. Folks don’t like change in general, and here we were advocating riding the wave of constant change. But somehow it seemed that resistance to agile ways went deeper than that.

We are not rational or logical creatures. We’d like to think we are, but the biological, psychological truth of the matter is that we’re predictably irrational. How irrational? Take a look at Wikipedia’s list of common cognitive biases for starters. This dauntingly long list begins to describe the many ways that we humans aren’t as logical or reliable as you might think. While you might encounter many of these in your daily life or work, a few stand out as significant barriers to agile adoption. These cognitive biases are why Johnny Can’t Be Agile.

Need for Closure

I think the most significant cognitive bias that affects agile methods in particular is our Need for Closure. In general, people are not comfortable with doubt and uncertainty—so much so that we’ll go to great lengths to resolve open issues and to remove uncertainty and reach closure. In other words, our default wiring says it’s better to make the wrong decision now instead of waiting and making a better decision later.

That’s partly why classic Big Design Up Front seemed so appealing. It demanded a heavy initial investment in design and architecture, but promised closure. With the big formal design done, there was no doubt and no uncertainty. There would be problems later on of course, because of pesky low-level details or volatile changes that often invalidated the initial design. The promised closure and removal of lingering uncertainty never actually materialized, but everyone felt better with the illusion of closure.

Uncertainty is a good thing: it leaves your choices open. Forcing premature closure, as in Big Design Up Front, cuts off your options and leaves you vulnerable to errors and unforeseen changes. Artificially making and declaring a decision, such as the end date of a project, doesn’t remove the inherent uncertainty; it just masks it. So agile requires that we grit our teeth and not only put up with uncertainty and doubt, but hold on to them. Live in them. Revel in uncertainty, and postpone closure for as long as possible. After all, you know the most about a project after it’s delivered, and you know the least when you first start.

Logically then, you should postpone major decisions until near the end of the project. But you won’t want to, and some folks simply can’t stand it. They’ll demand an answer, a decision, now. The agile way to respond to that is to offer an answer as a current estimate that will be revised periodically.

The end date of a project is a popular bit of closure that lots of folks would really like to know. But we don’t know it; it’s uncertain based on quite a few variable factors, not all of which we control. So we make a guess. An iteration or two go by, and we’ve got more data to work with. So we make a better guess. Time goes on, and we slowly converge on what will ultimately be a mostly-right answer. For someone who is uncomfortable with uncertainty, this might seem like slow torture.

The Devil You Know

There’s an old expression, “better the devil you know than the devil you don’t.” There are a number of cognitive biases that support this approach; we’re happier with a familiar situation, even if it’s sheer torture, instead of facing the unknown—which might just be even worse.

Hmm, this smacks of another issue, Post-purchase Rationalization: the tendency to persuade oneself through rational argument that a purchase was a good value. That tendency keeps a lot of expensive tool vendors in business. You've got a lot of incentive to use that crappy IDE or database because your team spent so much money on it. Even if it's killing your project.

This is summed up nicely in the Exposure Effect. We tend to prefer things just because they are familiar. This includes tools, techniques, or methods that aren’t working well anymore or that are even actively causing harm. So we’ll generally stick to a crappy way of working, or a crappy programming language, or a crappy IDE just because it’s familiar.

On a related note, we’re wired to be very much Loss Averse. That means it’s usually more important to us not to risk winning if there’s any chance at all of losing something we already have. Remember all those certifications that you worked so hard for? Isn’t that language dying out? You might think it’s better to stick to the dying language because of your investment in it. Hmm, this smacks of another issue, Post-purchase Rationalization: the tendency to persuade oneself through rational argument that a purchase was a good value. That tendency keeps a lot of expensive tool vendors in business. You’ve got a lot of incentive to use that crappy IDE or database because your team spent so much money on it. Even if it’s killing your project.

You’ll even promote those few choice bits of fact to support your decision, whilst conveniently ignoring the vast majority of facts that show you’re in deep trouble. Ah, that would be the Confirmation Bias at work. Everyone has a tendency to find just the facts that fit their own preconceptions and pet theories, and dismiss the rest.

With all of this baggage supporting the existing status quo, it’s even harder for a newcomer, such as an agile method, to gain acceptance.

The Programmer’s Bias

Okay, I’ll admit it, there actually isn’t a cognitive bias named The Programmer’s Bias, but there should be. First, take the Planning Fallacy: the tendency to underestimate task-completion times. Add to that some Optimism Bias: the tendency to be over-optimistic about the outcome of planned actions. Sound uncomfortably familiar?

Left to our own devices, we’ll underestimate the task at hand and overestimate the quality of the result. Now in agile methods, we’ve got techniques to help counter that, including iterative and incremental development, feedback with unit and other automated tests, heavy user involvement to validate our efforts, and so on. But you actually have to use these techniques, there are no shortcuts. And folks in your organization who aren’t part of the agile experience may still expect it to be perfect and available yesterday.

Reflecting Dimly

Agile methods are big on reflection, on conducting formal, team-wide and informal, personal retrospectives. It’s a great idea, and really the only way you can improve over time. But there are some problems here.

First, there’s the well-known Hawthorne Effect. Researchers have noticed that people have a tendency to change their behaviors when they know they are being studied. You’ll see this when you introduce a new practice or a new tool on a team. At first, while everyone is watching—and everyone knows they are being watched—results look great. Discipline is high, and the excitement of something new fuels the effort. But then the novelty wears off, the spotlight moves away, and everyone slides inexorably back to previous behaviors.

That’s enough to condemn agile in the eyes of many organizations. They’ll say, “We tried it once, and it didn’t work.” Perhaps a bit of confirmation bias has snuck in there as well. The normal lull after the initial novelty wears off gets confused for failure of the method itself.

Finally, and perhaps most damagingly of all, is the little-known Dunning–Kruger effect. This is the source of my favorite story about the “Lemon Juice Man,” the fellow who robbed a bank in broad daylight and thought that lemon juice made him invisible to the security cameras. It didn’t. But it never occurred to him to doubt his own belief in the power of lemon juice.

This lack of “metacognitive ability” is our lack of thinking about how we think; our lack of critically evaluating what we know and how we think we know it. As a result, less skilled people will overrate their own capabilities by a large amount. Highly skilled people will underrate their abilities, because they have come to understand just how complex their field can be.

So we often don’t know what we don’t know, and it’s hard to convince us otherwise. But knowing that there are problems in how we think is the first step in avoiding them.

Something to think about.

Andy is a Pragmatic Programmer, author of a bunch of books including Pragmatic Thinking & Learning, and dabbles in music and woodworking. Follow him on Twitter at @PragmaticAndy, at his blog andy.pragprog.com, or email him at andy@pragprog.com.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

Send the editor your feedback or discuss the article in the magazine forum.

Grokking Pattern Matching and List Comprehensions

Two Language Features that Rock

by Bruce Tate

Like a painter, a programmer learns gestures and techniques that make the canvas more beautiful and the work more confident.

My mother was an artist, and a great one. She had this incredible ability to capture the essence of an idea with a few brush gestures on a canvas. She knew that she could suggest the presence of people in a crowd or flowers in a field with splatters from a toothbrush, or tall grass by scraping with a credit card. She learned these techniques from years of study of the masters, and lots of trial and error.

As programmers, we are the same. We, too, come to understand abstractions and techniques that we can use to solve similar problems. Any developer worth his salt can conjure up a set of language features, idioms, libraries, and even languages that work best to solve the problems they find day to day in the workplace. If you want to become great, though, you need to find your own particular set of gestures and techniques that will make your canvas more beautiful, and make you more efficient.

In this article, I’m going to show you two language features that I found as I was writing Seven Languages in Seven Weeks. You may find that these features are new to you, too. Whether or not you do, I hope you, as I did, find joy in the journey.

Pattern Matching

C, Pascal, Java, and C# developers will all be familiar with the case or switch statement. This feature allows a user to direct control to a code block based on the contents of a variable or expression. For example, in Java, the statement looks something like this:

| switch (message) {
| case conditionOne: codeBlockOne;
| case conditionTwo: codeBlockTwo;
| case conditionThree: codeBlockThree;
| ...
| case conditionN: codeBlockN;
| default: code_block_default;
| }

So to print the day of the week corresponding to a variable day having an integer value between 1 and 7, you might construct a statement that looks like this:

| switch (day) {
| case 1:
| System.out.println("Monday\n");
| break;
| case 2:
| System.out.println("Tuesday\n");
| break;
| case 3:
| System.out.println("Wednesday\n");
| break;
| case 4:
| System.out.println("Thursday\n");
| break;
| # ... and so on
| }

The case statement allows more complex decisions within methods, allowing your idea to be expressed more densely than you would in, say, an if-then-else statement. Some languages allow these kinds of decisions to be made before a method or function is even invoked at all. Most functional programming languages lean heavily on recursion, so the functions must also behave differently based on the contents of the arguments. (A functional programming language is composed entirely of mathematical functions. The strictest functional languages allow no side effects, so recursion is how you do iteration.)

Let’s take a quick dive into Haskell, a strict functional language. Let’s say we wanted to take the size of a list. We first need to know a little bit about list processing in Haskell. Here are a few statements in a Haskell interpreter:

| *Main> head [1, 2, 3]
| 1
| *Main> tail [1, 2, 3]
| [2,3]

So [1, 2, 3] is a list, the head of the list is the first element, and the tail of a list is the list of all of the elements except the head. Building a function to recursively take the size of a list is pretty easy, then. The size of an empty list is zero, and the size of any other list is one plus the size of its tail. So let’s build a function to compute the size of a list:

| module Main where
| size list = if list == []
| then 0
| else 1 + size (tail list)

That’s our program. Ignore the first line. The functional definition is in the next three.

The first three words, size list = , mean we’re defining a function called size with one argument called list. The if-then-else statement is pretty simple. If list is an empty list ([]), we return a size of zero. Otherwise, we return 1 plus the size of the tail of list.

Running the program gives you the results you’d expect:

| Bruce-Tates-MacBook-Pro:~ batate$ ghci lists.hs
| GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help
| Loading package ghc-prim ... linking ... done.
| Loading package integer-gmp ... linking ... done.
| Loading package base ... linking ... done.
| Loading package ffi-1.0 ... linking ... done.
| [1 of 1] Compiling Main ( lists.hs, interpreted )
| Ok, modules loaded: Main.
| *Main> size []
| 0
| *Main> size [1]
| 1
| *Main> size [1, 2]
| 2

While the program works, it is wholly unsatisfying. You have to read too deeply into the function to understand what’s happening. Fortunately, Haskell’s pattern matching lets us conditionally invoke a version of a function based solely on the function’s parameters. Here’s an alternative implementation of size that is a little easier on the eyes:

| module Main where
| size [] = 0
| size (h:t) = 1 + size t

That’s more like it. Once again, ignore the first line. The next two lines define the size function. size [] = 0 means that we’re defining a function called size. If the first parameter matches the empty set, then invoke this function, returning zero. Said another way, the size of an empty list is zero.

The second line also defines the function size. It matches the parameter (h:t), which takes a nonempty list and breaks it into a head and tail. In English, size (h:t) = 1 + size t means the size of a nonempty list with head h and tail t is one plus the size of the tail. Pattern matching accomplished a few things nicely:

It simplified our functions, with each conditional execution expressed clearly. Breaking one complicated element into two simpler ones is one of the cornerstones of good software design.

It allowed us to deconstruct parameters into more basic terms. In this case, we mapped a list onto elements of head and tail.

It allowed us to put important complexities front and center. In this case, instead of burying an important decision in an if-then-else function, we pushed that decision up to the forefront in the form of a pattern match.

This pattern matching abstraction is becoming increasingly important, in languages such as Haskell, Scala, and Erlang. Though not all languages support pattern matching, you can still make a conscious effort to accomplish the three goals above. I will often simulate pattern matching in my Ruby programs by using return statements and one-line ifs for error conditions, like this:

| def size(list)
| raise "error" if some_precondition_is_not_met
| return( 0 ) if list.empty?
| compute_the_size_of_list
| end

Though my language of choice does not support pattern matching, I have another idiom to apply to my canvas when I encounter methods that have grossly different behaviors based on the function parameters. Our next technique will build on the pattern matching motif.

The List Comprehension

As I wrote the Erlang chapter of Seven Languages, I wanted to see how language constructs in my favorite languages might be implemented. Many languages have a function called map, which builds a list from each of the return values of a function called on all of the elements of a list. For example, in Ruby, you could double all of the members of a list like this:

[1, 2, 3].map {|x| x * 2}

Ruby returns [2, 4, 6].

That code takes an array, ([1, 2, 3]), and calls the map function on it. The map function takes another function ({|x| x * 2}) as an argument. The function is anonymous, meaning it has no name. The function takes a single argument, x, and returns x * 2. That’s a closure.

I could write the same expression in Erlang like this:

| 3> lists:map(fun(X) -> X * 2 end, [1, 2, 3]).
| Erlang returns <ic>[2, 4, 6]</ic>.

In this case, I’m calling a function called lists:map. The first argument is a function (fun(X) -> X * 2 end), and the second is a list ([1, 2, 3]).

Map is an extremely useful tool, and one of the interesting mental exercises when working in a new language is answering the question “How, exactly, would you implement map?”

My first attempt looked like this:

| map(F, [H|T]) -> [F(H) | map(F, T)];
| map(F, []) -> [].

[H|T] means that the list is broken into the head element H the tail of the list T.

Let’s break the rest of this program down. This definition of map is recursive. The clause map(F, []) -> []. says that the map of a function F and some empty list is an empty list. This clause gives you exactly the behavior you’d expect for any function and any empty list. The second clause, map(F, [H|T]) -> [F(H) | map(F, T)];, says that the map of F over a list with a head H and tail T is F(H) plus map(F, T).

That’s a short two-line implementation of map. In the text, I asked the rhetorical question “What would you say if I told you I could write map in a short two-line program?”

The initial technical review of the book came back, and the creator of Erlang answered the question. Joe’s answer was, “I’d say Bruce Tate writes very verbose programs.” Then, he introduced me to a concept that has become one of my favorites. A list comprehension is a mathematical expression of a list. For example, if you told a mathematician to describe the function that we’ve been building with map in both Ruby and Erlang, he’d show you something like this:

L = { 1, 2, 3 }

S = { 2 · X | X is in L }

Said another way, L is the set of numbers { 1, 2, 3 }, and S is the set of elements built by the function 2 · X where X is taken from the set L. If you wanted only the numbers between, say, 1 and 3, the list comprehension can accommodate that idea, too:

L = { 1, 2, 3, 4, 5 }

S = { 2 · X | X is in L, 1 < X < 5 }

In this case, L would be { 1, 2, 3, 4, 5 }, X would come from the numbers { 2, 3, 4 }, and S would be { 4, 6, 8 }.

The list comprehension has three elements:

a function where the variable, or variables, represent the members of one or more input lists

one or more input lists

one or more optional predicates that filter the incoming lists

List comprehensions in programming languages are fantastic abstractions that allow you to define and transform all kinds of functions concisely and simply. In Erlang, here are a couple comprehensions:

L = [ X * 2 || X <- [1, 2, 3] ].

In English, for X taken from the list [1, 2, 3], build a list of X * 2.

L = [ X * 2 || X <- List, X > 1, X < 5].

For each X taken from List that is greater than 1 and less than 5, build a list of X * 2.

You can manipulate just about any list in this way. For a shopping cart tuple with (item, price, quantity), you could add a tax item to the tuple. Or, you could transform the points of a polygon to reflect them vertically or horizontally. By pulling numbers from a list, you can compute all combinations effortlessly, and reduce those combinations with filters.

You’re not limited to dealing with expressions. You can deal with functions, too. After all, what is a map but a list comprehension? You can define map like this:

map(F, L) -> [ F(X) || X <- L ].

That’s it. map(F, L) means “For every X taken from list L, build a list of F(X).”

List comprehensions show up in many different languages, including Erlang, Python, Scala, Clojure, and Haskell. But here’s the point. After seeing list comprehensions several times in Seven Languages, my Ruby programming has changed. Now I find myself often chaining selects and maps together to give me a similar effect. For example, to double all of the even elements in a list, I might do something like this:

[1, 2, 3, 4, 5].select(&:even?).map {|x| x * 2}

It’s not a full list comprehension, but it’s close. We capture the spirit of the language feature, and we have another gesture for plopping just the right picture onto our canvas.

Wrapping Up

Part of the struggle of writing Seven Languages was my ignorance. I had no idea about the breadth and depth of languages as vastly different as Clojure and Io. I gladly confess that I made some pretty spectacular messes along the way, especially in Prolog and Haskell. But there’s a certain catharsis that comes with failing so spectacularly. I can often understand that my own programming paradigms are inadequate for some of the challenges I might face.

If you, too, like the idea of exploring language features like these, let me know. If there’s sufficient interest, I’d like to see your suggestions for new features that we might cover in future articles.

My book Seven Languages in Seven Weeks formed the foundation for this article. Joe Armstrong’s Programming Erlang has some excellent coverage on list comprehensions. And the Haskell Wiki has some excellent discussion of Haskell’s type system and pattern matching, including a Cookbook for Pattern Matching.

Bruce Tate is a kayaker, mountain biker, and father of two from Austin, Texas. An international speaker and prolific author, Bruce’s primary focus through the years has remained steady: rapid development of web applications with small, effective teams. He is the chief architect behind several commercial websites including changingthepresent.org, classwish.org, and most recently, digthedirt.com. His books through the years have included the Jolt-winning Better, Faster, Lighter Java and the controversial Beyond Java. He is also the author of From Java to Ruby and Seven Languages in Seven Weeks.

Send the author your feedback or discuss the article in the magazine forum.

Everyday JRuby

Part 2: Sharing Your Software

by Ian Dees

Ian continues his series on Everyday JRuby by showing how to build a game and share it with others.

People are using JRuby for amazing things worldwide. They’re also using it at smaller scales to make their day-to-day work a little easier. This series is an exploration of everyday situations where JRuby comes in handy.

In the previous installment, we discussed how to extend a large engineering environment like MATLAB using JRuby (and its statically typed cousin, Mirah). The plugin we ended up with was easy to deploy, because it didn’t have any dependencies other than the basic JRuby runtime.

For this article, we’ll look at a slightly more complicated case. We’ll build a data-backed Web application that uses Java libraries, Ruby gems, and static template files. When it comes time to share our app, we’ll need to make sure all the pieces get packaged up correctly.

Six Degrees

At work, my colleagues and I occasionally need to throw together a simple Web front end for some engineering data. But for this article, let’s look at something much more interesting (and less likely to get me fired): the movies.

We’re going to implement an old party game known as “Six Degrees of Kevin Bacon.” In this game, players choose an actor and then try to find as direct a connection as possible between that actor and Kevin Bacon by looking at movie roles. For example, we can get from Kevin Bacon to Danny Glover in two steps: Kevin Bacon starred in JFK with Kevin Costner, who in turn starred in Silverado with Danny Glover.

Connecting to the Database

The standard “how to write a blog server” tutorial has you stash your data in a relational database like MySQL. But since finding connections between actors is essentially a graph traversal activity, we’ll use Neo4j, an open source graph database, instead.

For this exercise, you’ll run Neo4j as a standalone server and connect to it from Ruby, just as if you were handed a server address and login credentials on a real-world project. Download and extract Neo4j 1.2 from the official site. Launch the background server, and leave it running for the remainder of the experiment:

$ ./bin/neo4j start

On the Ruby side, we’re going to use a dependency management tool called Bundler to install Ruby libraries. First, install Bundler:

$ jruby -S gem install bundler

Now, create a file called Gemfile in your project directory with the following contents:

| source 'http://rubygems.org'
| gem 'neography', '~> 0.0.7',
| :git => 'git://github.com/undees/neography.git',
| :branch => 'warbler'
| gem 'jruby-openssl', '~> 0.7'

We’ll be using a Ruby wrapper around Neo4j called Neography. The :git notation means that we need a fork of Neography that’s been tweaked to match the latest Neo4j API. When this change makes its way into the official gem (which may happen by the time you read this), you can remove this modifier.

To install Neography and its dependencies, run the following command:

$ jruby -S bundle install

Now, we’re ready to build a small Ruby API for storing actors and movies in a database. Put the following code in lib/database.rb:

| require 'bundler/setup'
| require 'neography'
| require 'cgi'
| class Database
| def neo
| server = ENV['NEO4J_SERVER'] || 'localhost' # Line 1
| @neo ||= Neography::Rest.new 'http://', server
| end
| def find(type, name) # Line 2
| hit = neo.get_index type, 'name', CGI.escape(name)
| # get_index will return nil or an array of hashes
| hit && hit.first
| end
| def find_or_create(type, name) # Line 3
| # look for an actor or movie in the index first
| node = find type, name
| return node if node
| node = neo.create_node 'name' => name
| neo.add_to_index type, 'name', CGI.escape(name), node # Line 4
| node
| end
| def acted_in(actor, movie)
| neo.create_relationship 'acting', actor, movie # Line 5
| end
| end

On line 1, we default to connecting to the local machine, but allow a remote server name to be set in an environment variable. On lines 2 and 3, we create a couple of helper methods that take care of the details of object creation and retrieval. These details include marshaling strings into the format required by Neography, storing data into two indices named actor and movie, and so on. On line 5, we connect an actor to a movie (which implicitly creates a link from the movie back to the actor).

The alert reader will notice that we’re comparing movies by title only. That means that this script can’t tell the difference between, say, the 1939 and 1994 versions of Love Affair. The app will erroneously describe Warren Beatty and Irene Dunne as co-stars.

To distinguish different movies with the same title, we’d need a unique identifier for each film. As we’ll see in the next section, the data source we’re using doesn’t directly contain that information.

Populating the Sample Data

We’ll fill the database with a Creative Commons licensed flat file from the Freebase project. A warning for those who love to read through raw data files: there are over 60,000 movie titles in this file, and not all of them are work-safe.

Here are a couple of sample rows from performance.tsv, with arrows in place of tabs. The first non-empty column is a unique ID for the performance (not the movie, alas). The next two are the ones we’re interested in: the actor name and film title.

| ->/m/0jybnb->Kevin Bacon->Footloose->->Ren McCormick->
| ->/m/0k2ckt->Val Kilmer->Real Genius->->->

To get the data into Neo4j, we just loop through the rows looking for actor and movie names, then use our Database object to make one actor/movie connection for each performance. Put the following code into Rakefile in your project root:

| desc 'Import movie data into Neo4j'
| task :import do
| require 'lib/database'
| File.open('performance.tsv') do |f|
| db = Database.new
| f.gets # header
| f.each_line do |line|
| _, _, actor_name, movie_name = line.split "\t"
| next if actor_name.empty? || movie_name.empty?
| actor = db.find_or_create 'actor', actor_name
| movie = db.find_or_create 'movie', movie_name
| db.acted_in actor, movie
| end
| end
| end

Now, run your import task like so:

$ jruby -S rake import

This process took a while on my old machine, so we watched a Christmas movie while I waited for it to complete. (Die Hard, if you’re curious. You can get from Bruce Willis to Kevin Bacon in only two steps, by the way.)

Traversing the Graph

Neo4j ships with a function to find the shortest path between two nodes—between two actors, in our case. It would certainly be more fun to dust off our Dijkstra and write our own traversal than just to learn the quirks of someone’s API. But fetching all those graph nodes across the network and creating a bunch of intermediary Ruby objects would almost certainly slow down the final program. With a heavy heart, add the following code inside your Database class:

| def shortest_path(from, to)
| from_node = find 'actor', from
| to_node = find 'actor', to
| return [] unless from_node && to_node
| acting = {'type' => 'acting'}
| degrees = 6
| depth = degrees * 2
| nodes = neo.get_path(from_node, to_node, acting, depth)['nodes'] || []
| nodes.map do |node|
| id = node.split('/').last
| neo.get_node(id)['data']['name']
| end
| end

The API is now fully-featured enough for you to play a command-line version of the game:

| $ jirb -rubygems -rlib/database
| No Extensions Found: /Users/username/.neography
| jruby-head :001 > db = Database.new
| => #<Database:0x4e26d560>
| jruby-head :002 > db.shortest_path 'Kevin Bacon', 'Bruce Willis'
| => ["Kevin Bacon", "The Magic 7", "Michael J. Fox",
| "Die Hard", "Bruce Willis"]

From here, it’s fairly straightforward to wrap a Web interface around the game.

Showing the Data

We’ll serve the data through the Sinatra web framework. Though templates are overkill for this project, we’ll use the Haml template language for the presentation. Doing so gives us an excuse to see how our packaging tool handles static files. Add the following lines to your Gemfile:

| gem 'sinatra', '~> 1.1'
| gem 'haml', '~> 3.0'

...and then re-run Bundler to install the libraries:

$ jruby -S bundle install

The Web application is pretty simple. Create a new file called lib/degrees.rb with the following code:

| require 'bundler/setup'
| require 'enumerator'
| require 'sinatra'
| require 'haml'
| require 'lib/database'
| db = Database.new
| get '/' do
| from = params[:from] || 'Kevin Bacon'
| to = params[:to] || ''
| path = if to.empty?
| []
| else
| db.shortest_path from, to
| end
| previous = path.shift
| @results = path.each_slice(2).map do |slice| # Line 6
| movie, actor = slice
| result = %Q(#{previous} was in "#{movie}" with #{actor})
| previous = actor
| result
| end
| @from = CGI.escapeHTML from
| @to = CGI.escapeHTML to
| haml :index
| end

We store the two actors’ names and the path between them in the @from, @to, and @results instance variables, so that the template can display them.

Our database wrapper hands us an array of alternating actor and movie names. The loop on line 6 steps through this array two items at a time and builds the final list of actor/movie/actor links.

The template just needs to display the results, along with a form for entering the next two actors’ names. Here’s what that looks like in Haml (this code goes in lib/views/index.haml):

| %h1 Six Degrees
| %ol
| - @results.each do |result|
| %li #{result}
| %form(action="/")
| %input(name="from" value="#{@from}")
| %input(name="to" value="#{@to}")
| %input(type="submit" value="Search")

You can run the app directly like this:

$ jruby -rubygems lib/degrees.rb

...but it will be handy later on to launch the app through the Rack interface. Rack is a wrapper that presents your app to the rest of the Ruby and Java ecosystem through a standard interface. You’ve already got Rack—it came along for the ride when you installed Sinatra. All you need to do is to create a configuration file in your project root called config.ru:

| require 'rubygems'
| require 'lib/degrees'
| set :run, false
| set :environment, :production
| run Sinatra::Application

...and launch again using the rackup command:

$ jruby -S rackup

You should be able to point your browser at http://localhost:9292 and see something like the figure.

Sharing Your App

Now that we have everything running on our development system, how do we package the software for deployment? Our system contains several different kinds of files:

The Ruby files that make up the program

Additional static files (templates, in this case)

Supporting Ruby libraries

jar files containing Java code used by the Ruby libraries

The JRuby runtime

The goal is to package all these items up in a single file, hand it to our end user, and say, “Run this.” There are a few different ways to do this:

Extract all our Ruby, Java, and other files into a staging area, then use the jar command to combine them into a single file.

Partially automate the process with the Rawr packaging tool.

For Web apps, completely automate the packaging process with Warbler.

All three of these approaches can be automated to some degree, but some require more custom code than others. Let’s take a closer look at the three techniques.

Do It Yourself

Doing your own packaging used to be the only game in town for JRuby deployment. You’d extract jruby-complete.jar to a staging area, copy in all your Ruby gems, and then recursively go through and extract any jars contained in those gems.

You’d then write and compile a little Java stub program that would launch your main Ruby program, something like this:

| import org.jruby.embed.ScriptingContainer;
| public class Launcher {
| public static void main(String[] args) {
| ScriptingContainer container = new ScriptingContainer();
| container.runScriptlet("require 'lib/degrees'");
| }
| }

There’s a bit of grunt work here, but it’s not as bad as it sounds. JRuby has gotten pretty good at loading jars within jars, so you can often get away with just throwing a mixed directory tree of rb and jar files into the final package.

This approach gives you fine control over the package layout—something that comes in handy for things like Java service providers. But if what you’re doing falls into the more common use cases, it makes sense to use an automated tool to help you package your software.

Package with Rawr

Rawr is a library for packaging JRuby projects. It downloads the JRuby runtime, provides a prefab Java launcher, compiles code, and builds executables for the Mac and Windows platforms. To use it, you’d run the following commands from your project directory:

| $ jruby -S gem install rawr
| $ jruby -S rawr install

This would give you a Rakefile containing common packaging tasks, plus a build_configuration.rb file where you’d specify details like the program name and list of included files.

Rawr looks in your project directory for code to package, so you’d have to copy your Ruby dependencies there yourself. One easy way to do this is to rerun the bundle install command and pass it a destination directory. As we’ll see in a moment, there are alternatives to Rawr that don’t require this extra step.

Package With Warbler

For the specific case of Web applications, there’s a packager called Warbler that provides a more fully automated experience. In a single command, it does everything we need to prep our Six Degrees program for sharing. Warbler leans on two Ruby standards we’ve already seen: the Rack Web interface and the Bundler packaging tool.

Because Warbler isn’t a dependency that needs to get packaged along with the program, we just install it using plain old RubyGems:

$ jruby -S gem install warbler

Warbler’s output is a war file, which is an archive suitable for deployment on standard Java Web servers. These files don’t usually run on their own, but it’s possible to create one that does. If you pass the executable option on the command line, Warbler will embed a standalone Java Web server in the war file and connect it to our app:

$ jruby -S warble executable war

Warbler has several configuration options for including libraries and static files. By default, it brings in all the libraries and dependencies in your Gemfile, plus all the files in lib. Since we kept to those conventions, we don’t need to do any extra configuration.

You should now be able to copy the resulting file to your target system, set the NEO4J_SERVER environment variable to point to the database, and run the program:

| $ export NEO4J_SERVER=ip.address.of.database
| $ java -jar jruby-degrees.war

By leaning on JRuby and adhering to a few conventions for laying out Ruby projects, we’ve turned packaging into a one-liner. No struggling with MySQL adapters, tripping over conflicting Ruby versions, or wondering if the end user’s machine has gcc installed. Just a simple file copy.

That’s a good stopping point for this exercise. You’ll find the example source code at http://github.com/undees/pragpub. As a next step, you might choose a test framework and write a simple functional test for the app. In the spirit of the Six Degrees game, may I suggest Bacon?

By day, Ian Dees slings code, tests, and puns at a Portland-area test equipment manufacturer. By night, he dons a cape and keeps watch as Sidekick Man, protecting the city from closet monsters. Ian is the author of Scripted GUI Testing With Ruby and co-author of the upcoming Using JRuby.

Send the author your feedback or discuss the article in the magazine forum.

Code Coupling

Reducing Dependency in Your Code

by Tim Ottinger, Jeff Langr

When it comes to couplings, there is strength in weakness.

Last month we listed the four biggest ideas in software: cohesion, coupling, abstraction, and volatility. Vowing to tackle one at a time, we focused on how lack of cohesion creates challenges in software. This month we continue through the idea list, moving on to the ever-present alliterative pair-partner of cohesion, coupling.

We learned that cohesion is to be maximized, so that proximity follows dependency. Where coupling is concerned, our rule is that dependency should be minimized. We’ll tell you why and how.

Definition

When we talk about coupling in this article, we are referring to “attachments” required due to the dependencies between modules in an object-oriented (OO) system. A module can be a class or an aggregation of classes (a package). The term coupling can refer to other dependencies, such as those between methods, but we’re not interested in those here.

A dependency exists when code in one class refers to another class—via any of several possible mechanisms:

a field

an argument

constructed within a function

inheritance or mix-in

shared knowledge

When you cannot compile or operate module A without the immediate presence of module B, module A is dependent upon module B. Dependency is coupling. More importantly, if a change in module B could cause breakage in module A, A is coupled to B.

Coupling among software components is reasonable and necessary. If a part (class, module, library) of a system we’re writing has no connection to any other part, we typically call it “dead code” and delete it. All useful code has some coupling.

Simple Dependency

We need a Branch class to represent the various physical buildings in which library patrons can find books or other materials. We need a Material class to represent an item that patrons wish to borrow. A Branch object must contain a collection of Material objects. (Let’s not confuse this with database design, in which case a Material might have a back reference to a Branch table.) Figure 1 shows how we diagram such dependencies using UML.

Without Material, Branch has no reason to live; Branch is dependent upon Material. Any changes to the definition of Material might impact Branch. If you change the Material class, you’ll need to re-test both the Material and Branch classes before releasing the change. On the other hand, changes to Branch are not important or interesting to Material. We can say that effects flow against the direction of the dependency arrows. The problem with couplings is not their existence or even necessarily their number, but their potential to cause dependent code to break.

Transitive Dependency

More trouble comes when there are many layers of dependency (see Figure 2).

Dependence is transitive. To understand the full impact of a dependency, follow the chain backward. For example, a small code change to the details of how fees are calculated in FeeCalculator has the potential to impact LibraryController! You’ve no doubt encountered this effect: you make a change in one corner of the system and it breaks code in a far, far distant corner. You might not even spot such a defect, particularly if you don’t do extensive regression testing with each release. That of course means your unfortunate customer will likely be the one who spots the defect.

Unit testing, one of our favorite things to do (and do first of course, i.e. using TDD), also becomes far more difficult with deep dependency chains.

If you want to test the FeeCalculator class, you simply create a new instance:

var sut = new FeeCalculator(baseRate);

Since it has no dependencies, you’re ready to call methods on it for verification purposes.

Tests for Material, on the other hand, will at some point require you to also construct an instance of FeeBasis, which requires an instance of a FeeCalculator. Tests of Branch will require Materials, and so on. By the time you arrive at the most dependent class, that insecure fellow who cannot live without a host of other objects, you may find yourself writing dozens of lines of code to create and populate associated objects.

Structural Dependency

Staying with the same example, if classes that use the LibraryController need to access the FeeCalculator by traversing Checkout, Branch, Material, and FeeBasis, then we have a structural dependency. If we ever collapse or extend the structure of that part of the application, code in all the places that are aware of the structure of the application will likely fail in one way or another. Hopefully it will be at compile time.

Implicit Dependencies

A diligent programmer can easily trace explicit dependencies between code modules as in the chain from LibraryController to FeeCalculator above. Implicit dependencies are rather trickier. When different parts of the program share knowledge, in violation of what we discussed last month about coherence, they will exhibit an implicit dependency.

Say that your auditor wants you to report the specific fee calculation method by name. Sadly, when the fee is calculated, the algorithm name is not recorded. You could change the fee transaction to include the algorithm name, but that means a change to a core business object and also to the database. Luckily, you remember that only the large payment calculator can levy fees as large as $23.00. You can infer the calculation method!

| if Fee.amount > 23:
| calc_method_name = “large payment”

It works! You can now produce your report without touching/damaging existing code in the rest of the system! The problem is that now you have an implicit dependency on the limits of the large payment calculation. Maybe it works for now, maybe it will work for months or years, but it is not guaranteed always to work. If the calculation ever changes, this code will be quite broken, even though the fee report does not explicitly depend on the large payment fee calculator.

When details escape the class where they “belong” (see our previous article, “Cohesive Software Design”), we refer to them as leaky abstractions.

Fee.amount is a primitive integer in the example above. The authors implicitly assumed a currency. If they are our countrymen, it’s a sure bet they’re thinking US Dollars. And that might be all right, if there is a business rule in the system that all amounts are given as integer dollars, but it is a shared assumption.

Couplings are particularly troubling when they mix concerns that should be independent. If a calculation in the bowels of the system is written to pop up a modal dialog box, it couples calculation to user interaction. So much for calculating values in batch mode!

All implicit couplings seem convenient when first introduced, but later become reasons that the code cannot be easily diagnosed, repaired, or extended. In a small web app we’ve been working on, we spotted a shared bit of knowledge about file locations and URL construction. This information appeared in utilities, UI, and in the core class model of the app. Once we realized that we had a shared secret across modules, we realized we’d lost cohesion and had created implicit couplings that were going to bite us. Some redesign was in order.

How often do we hear developers saying that they would love to make an improvement to the code structure, but that it would take too long, cost too much, and risk too much? Typically, the programmer sent to resolve the problem must write the code that the original author avoided. Unfairly, the original author may be initially credited with quick turnaround, when in reality he did an incomplete job that his colleagues must finish for him.

Solutions

We need a way to maintain necessary couplings, but reduce the strength of the couplings so that a change in a depended-upon class does not cause rippling changes or failures throughout the system.

Prefer explicit couplings to implicit couplings. Increase cohesion so that one class becomes the single point of truth for a given fact. By doing so, we reduce the ability of implicit couplings to distribute errors throughout the code base. This is perhaps easier to say than do, but it goes a long way toward preventing “step back” errors.

If we can reduce our use of a class to a smaller set of method signatures, then we are depending on an interface rather than on the full implementation of the class. This is a weaker dependency that may replace couplings to a number of concrete (possibly derived) classes. This is the concept behind many “inversion of control” frameworks. The dependency on an interface also makes it a snap to replace a production concrete implementation with a stub, greatly simplifying the effort required to code unit tests.

It’s better yet to depend on fundamental, unchanging interfaces on objects. For instance, if we can rework the code to treat the FeeCalculator as a black box into which we pass a rental instance and receive a fee object, we can use the facts the calculator provides to us without depending on how it does its work. This weaker dependency provides us with a kind of “dependency firewall.” Abstraction (to be covered later) allows us to tolerate change.

Structural couplings are difficult to deal with, because navigation is frequently necessary and it has to go somewhere. The most common ways to deal with this are the Law of Demeter or the use of special classes (with names including words like Gateway or Repository) that will do navigation for us with methods like Repository.FeeCalculatorFor(Material). We trade a dependency on the broader structure of the system for dependency on a single class that hides those dependencies for us.

It is common to introduce additional mechanisms (interfaces, abstract base classes, facades, repositories, navigation functions, etc.) to help us manage troublesome couplings. It adds some complexity to our applications to have these extra parts, but the additional mechanisms are trade-offs we willingly make to keep the system from degrading due to unnecessary strong couplings.

Summary

Coupling is necessary, it makes our code useful, but it can also make it fragile. By seeking weaker couplings, we can reduce code breakage in our systems. As a result, we’ll spend less time tracking down weird problems and more time writing and polishing new features.

Jeff Langr has been happily building software for three decades. In addition to co-authoring Agile in a Flash with Tim, he’s written another couple books, Agile Java and Essential Java Style, contributed to Uncle Bob’s Clean Code, and written 90+ articles on software development. Jeff runs Langr Software Solutions from Colorado Springs, where he also pair-programs full-time as an employee of GeoLearning.

Tim Ottinger has over 30 years of software development experience coaching, training, leading, and sometimes even managing programmers. In addition to Agile in a Flash, he is also a contributing author to Clean Code. He writes code. He likes it.

Send the authors your feedback or discuss the article in the magazine forum.

Rediscovering QA

Three Unusual Attributes for Software Quality Assurance

by Chris McMahon

It’s time to take a fresh look at Software Quality Assurance, a discipline that deserves much more respect that it usually gets.

Managing the software development process for the ultimate benefit of the users of the software is the work of Software Quality Assurance (QA). QA work in software has always been widely misunderstood and has often been done poorly, but especially in recent times, QA work in the software universe has languished.

Because of some historical accidents, QA in software development is wrongly conflated with software testing, so much so that there is a strong movement among software testers to divest themselves of the title of QA altogether. But that leaves real Quality Assurance an orphan without champions.

Software testers are often the sole members of the development team working on the system as a whole, and are often the only members of the team working as proxies for actual users. The critical skills of good software testers, the ability to identify issues and to advocate change, are a great start to providing real Quality Assurance on agile software development projects. There is a strong case to be made that software testers are in a position to provide good QA to software development teams. But QA work demands skills and experience beyond software testing. Good QA work is methodology work, not testing work.

Other skills are required beyond testing skills to provide good QA. Besides testing, I would identify three additional areas that provide a good background for QA work, although you may find my selections surprising. But before I get to them, let me motivate the discussion with an example of why QA work might be necessary on agile software development projects.

Software Application Semantics

There is a thing that happens sometimes on agile software development projects that looks something like this:

A fairly complex hunk of data is to be exposed to users. The development team builds a “view” page to display that data. But privileged users need to edit the data, so then in subsequent iterations the team builds an “edit” page for privileged users that is hidden from unprivileged users. At this point the application has very clean and clear semantics: the “view” page displays some complex data, the “edit” page allows privileged users to alter that data.

But over a few more iterations, it becomes required to edit the data in several different modes, so the team builds multiple search and view options into the “edit” page. Over a few more iterations, it becomes desirable to allow unprivileged users to edit certain aspects of the data in question, so all users, regardless of privilege, are given a limited edit ability on what had been the “view” page.

This is the point where quality on an agile project can begin to suffer. Each enhancement to the “view” page and to the “edit” page makes sense within the context of each iteration. But after a number of iterations, the original semantics governing the concepts of “view” and “edit” have become muddled, overlapping, and confused. And when the semantics of a software application are muddled and confused, the workflow presented to the users of the application is also muddled and confused.

The same sort of confused semantics is often found in very old legacy applications with dedicated function keys and combination key presses and such, where special training materials and documentation are required to be able to manipulate the application correctly. Agile projects are capable of generating this same sort of complexity and confusion—and they can do so much more quickly.

Testing or Design or UX?

Not every agile team ends up with confused application semantics, and there are people with certain roles on software development teams who may help prevent such mistakes from happening.

Dedicated software testers certainly may be in a position to spot confusion in the UI as it comes up, and to help guide the semantics of the application in a more appropriate direction.

Front-end designers and User Experience (UX) specialists may also be in a position to prevent confusing, contradictory, and inefficient workflow from evolving over the course of time. Although the state of UX practice today is an interesting grab-bag of technique and opinion, there are some emerging and coherent schools of thought that embody a high degree of sympathy for the users of software, something that has not always been true in the history of software development.

But regardless of one’s role on the the team, it is often still difficult to see the forest for the trees when working in an iterative manner. Some real, dedicated QA work is often required—and is frequently missing.

Linguistics, Architecture, Methodology

I use the word “semantics” liberally in this article, and I do so quite deliberately. Semantics is the study of meaning, and someone who understands a bit about semantics will more readily see when the concepts of “view” and “edit” begin to lose their meaning. Taking this further, an understanding of semiotics is even more useful.

Semiotics deals with “signs,” the relationships between the “signified,” the swarm of concepts and meanings that comprise the culture within which the work is performed, and the “signifiers,” the concrete representations of the signified. The culture of software development has its own signs: “search,” “display,” “expand/collapse,” “edit,” “enter,” “submit,” “save,” “OK/Cancel,” “CRUD,” “push,” “pop,” etc., etc., etc. To create software is a linguistic act: it is to string together signifiers in the same way that an author writes a book or that performers put on a show. Someone working in QA (or UX, for that matter) would do well to have a good understanding of semantics, semiotics, and linguistics generally.

Besides linguistics, someone working in Quality Assurance should have a solid grasp of software architecture. Without a visceral understanding of the consequences of technical debt and of the legacy of bad design, Quality Assurance will be mostly illusion. This is one of the reasons that software testers reject the label of QA so vehemently: merely having a Quality Assurance process in place will not guarantee that the product will be of high quality.

One useful way to view Quality Assurance work is that it exposes a series of examples and counterexamples, that ultimately invest a useful methodology within the software development process. Brian Marick has a remarkable paper on this subject from 2004 called “Methodology Work is Ontology Work.”

The paper is remarkable in a number of ways (Kent Beck and Ron Jeffries as Emersonian philosophers?), but of particular interest to those working in QA is the well-considered justification for finding some few core postulates, or some sets of them, and for then building a local methodology or a process based in those few postulates. But “[m]ethodologies do not succeed because they are aligned with some platonic Right Way to build software. Methodologies succeed because people make them succeed.” This conclusion of course resonates strongly with the first value of the Agile Manifesto, “Individuals and interactions over processes and tools.”

Software testing or UX work is a good first step to real software QA work. Add linguistics, add a deep understanding of software architecture and a sophisticated view of methodology, and you put real Software Quality Assurance back into the development tool box.

Chris McMahon is a software tester and former professional bass player. His background in software testing is both deep and wide, having tested systems from mainframes to web apps, from the deepest telecom layers and life-critical software to the frothiest eye candy. Chris has been part of the greater public software testing community since about 2004, both writing about the industry and contributing to open source projects like Watir, Selenium, and FreeBSD. His recent work has been to start the process of prying software development from the cold, dead hands of manufacturing and engineering into the warm light of artistic performance. A dedicated agile telecommuter on distributed teams, Chris lives deep in the remote Four Corners area of the U.S. Luckily, he has email: christopher.mcmahon@gmail.com.

Send the author your feedback or discuss the article in the magazine forum.

When Did That Happen?

The Rise of the Index

by Dan Wohlbruck

The humble index register was crucial to the development of high-level languages.

On January 15, 1962, IBM announced its model 7094 mainframe. The 7094 was the fastest, most powerful computer of the second generation of computers. Among the improvements offered by the 7094 were an operating cycle of 2 microseconds and the ability to execute two instructions per storage cycle. Because it was the supercomputer of its age, the 7094 was used by NASA to control the flight operations of the Gemini and the Mercury space flights. In fact, a 7094 was kept as a standby during the first Apollo missions. Because the 7090 series of mainframes were the first to disassociate data channels and the hardware to which the cable was attached, thereby permitting both I/O interrupts and the simultaneous execution of I/O and storage instructions, the 7094 was used by MIT’s Project MAC for the world’s first time sharing system.

There was something else that the 7094 did that is often lost in the hype: it maximized the use of index registers. An index register is a specialized circuit (or register) found in the central processor that is used most often to process an array. The need to scroll through a table or an array of data was so obvious to the original programmers that the first index register was implemented in the University of Manchester’s Mark I in 1949.

Throughout the first and most of the second generation of mainframes, computer hardware designers assumed that main storage was slow and unstable. Accordingly, the only storage operations that these machines supported were fetch and save. In other words, neither computations nor transformations were performed on stored data. In the von Neumann model of computer architecture, program instructions were executed by the processor. As directed by the stored program, the processor would fetch a field of data and place it into a register within the processor itself.

It was within the processor or the Arithmetic Logical Unit (ALU) that the calculation or data manipulation happened. Once the operation was finished, the changed or calculated field of data was sent back to main storage. These register-to-register operations were much faster and more secure than they would have been if performed in the vacuum tubes that made up storage for the first generation of mainframes.

Within the processor, the absolute address of the next instruction to be executed was kept in a register, as was the absolute address of its data field. Without an index register, the absolute addresses of the next row or table entry had to be computed before the fields could be accessed.

Consider the following FORTRAN statement:

DIMENSION PERCNT(0:100)

PERCNT is an array with a length of 101. The individual elements of PERCNT are addressed in FORTRAN with subscripts, so the tenth element can be designated with a subscript as PERCNT (9). The subscript is implemented by using an index register. Indeed, without index registers higher-level languages like FORTRAN and COBOL would not have been developed.

The IBM 7094 brought all of these elements together. It delivered either three or seven index registers, it ran the FORTRAN Operating System, and it ran like the wind. Later generations of mainframes, most directly IBM’s System 360, supported general-purpose registers. Any general-purpose register could be used as an index or used for register-to-register computations or data transformations. Sometime when you’ve nothing better to do, perform an internet search on Zilog’s first Z80 processor. When you locate the chip’s specifications, you’ll find the index register—the programmer’s best friend.

It began almost fifty years ago—and that’s when it happened.

Dan Wohlbruck has over 30 years of experience with computers, with over 25 years of business and project management experience in the life and health insurance industry. He has written articles for a variety of trade magazines and websites. He is currently hard at work on a book on the history of data processing.

Send the author your feedback or discuss the article in the magazine forum.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

Jan 10, Cleveland Cocoaheads, Cleveland, OH

“Yet another look at Blocks” with Craig Castelaz

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Jan 12–14, CodeMash, Sandusky, OH

Keynote

Chad Fowler, author of The Passionate Programmer

Jan 12–14, CodeMash, Sandusky, OH

Precompiler workshop “iOS Development: A Fresh Start” and two sessions

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Jan 12–14, CodeMash, Sandusky, OH

“iOS Development in the Real World” and “The Dark Depths of iOS”

Chris Adamson, co-author of iPhone SDK Development

Jan 14–16, Agile Coach Camp Norway, Oslo, Norway

Coaches Dojo

Rachel Davies, co-author of Agile Coaching

Jan 20, Software East, Cambridge, UK

Talk on Agile Retrospectives

Rachel Davies, co-author of Agile Coaching

Jan 25–28, Pragmatic Studios, Reston, VA

“iPhone/iPad Programming” with Matt Drance

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Jan 26–28, Pragmatic Studios, Reston, VA

Pragmatic Rails Studio with Dave Thomas

Chad Fowler, author of The Passionate Programmer

Feb 2–4, Magic Ruby, Orlando, FL

Keynote

Chad Fowler, author of The Passionate Programmer

Feb 4–5, Agile Coaches Gathering, Madrid, Spain

Sessions

Rachel Davies, co-author of Agile Coaching

Feb 14–16, Belgium Testing Days, Brussels, Belgium

“Tutorial: Becoming a Great Test Manager” and “Keynote: Lessons Learned from 20 Years of Managing Testing”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Feb 15, Jfokus 2011, Stockholm, Sweden

“Regex—the Future Programmer’s Best Friend”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Feb 17–18, Agile Program Management, Stockholm, Sweden

Class

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Feb 19, MobiDevDay Detroit 2011, Detroit, MI

“iOS Multimedia APIs”

Chris Adamson, author of iPhone SDK Development

Feb 25–26, Greater Wisconsin Software Symposium, Madison, WI

“Grails Deep Dive,” “Hello! Groovy,” and “Rediscovering Apprenticeship in the 21st Century”

Dave Klein, author of Grails: A Quick-Start Guide

Feb 28, Agical Geek Night, Stockholm, Sweden

“Regex—the Future Programmer’s Best Friend”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Mar 7–10, Pragmatic Studios, Santa Clara, CA

Pragmatic Rails II Studio with Dave Thomas

Chad Fowler, author of The Passionate Programmer

Mar 7–10, Pragmatic Studios, Santa Clara, CA

“iPhone/iPad Programming” with Matt Drance

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Mar 10, Crisp Rocket Day, Stockholm, Sweden

“Regex—the Future Programmer’s Best Friend”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Mar 16, Turku Agile Day 011, Turku, Finland

“Regex—the Future Programmer’s Best Friend”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Mar 21–22, SDC, Wellington, NZ

“Keynote: Creating an Adaptable Life” and “Keynote: Who’s On Your Team?”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Mar 24–25, SDC, Sydney, Australia

“Keynote: Creating and Adaptable Life” and “Keynote: Who’s On Your Team?”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Mar 28–29, SDC, Sydney, Australia

“Working Effectively With Distributed Agile Teams”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

O’Reilly Events

As publishers who think of ourselves as being on the cutting edge, we’re always interested in O’Reilly’s Tools of Change conference.

Feb 1–3, Strata, Santa Clara, CA

O’Reilly Strata Conference: “Get control of the new data opportunity at Strata—immerse yourself in three full days of hands-on training, information-rich sessions, and a sponsor pavilion filled with the key players and products. This new O’Reilly conference brings together the people, tools, and technologies you need to make data work.”

Feb 14–16, TOC, New York, NY

O’Reilly Tools of Change Conference: “Join us as we explore this new world of ‘Publishing Without Boundaries’ at the fifth annual O’Reilly Tools of Change for Publishing Conference.... This premiere event provides an unparalleled opportunity for stakeholders from across the book publishing and tech industries to network, share ideas, engage in lively debate, and consider the many issues we face individually and collectively.”

Mar 28–31, TOC, San Francisco, CA

O’Reilly Web 2.0 Expo SF: “The program will spotlight experts, leaders, and under-the-radar innovations, and in the spirit of Web 2.0, there will be ample opportunity for attendees to connect, contribute, and collaborate. Web 2.0 Expo will be a place for creativity, engineering, and innovation.”

USENIX Events

What’s coming from our USENIX friends.

Feb 15–18, FAST ’11, San Jose, CA

9th USENIX Conference on File and Storage Technologies: “FAST ’11 brings together storage system researchers and practitioners to explore new directions in the design, implementation, evaluation, and deployment of storage systems.”

Mar 29, Hot-ICE ’11, Boston, MA

Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services: “The first Hot-ICE workshop seeks to bring together researchers and practitioners working on network and service management in the Internet, cloud, and enterprise domains. The scope of Hot-ICE includes all aspects of network and service management.”

Mar 29, LEET ’11, Boston, MA

4th USENIX Workshop on Large-Scale Exploits and Emergent Threats: “LEET aims to be a true workshop, with the twin goals of fostering the development of preliminary work and helping to unify the broad community of researchers and practitioners who focus on worms, bots, spam, spyware, phishing, DDoS, and the ever-increasing palette of large-scale Internet-based threats.”

Mar 30—Apr 1, NSDI ’11, Boston, MA

8th USENIX Symposium on Networked Systems Design and Implementation: “NSDI ’11 will focus on the design principles, implementation, and practical evaluation of large-scale networked and distributed systems.”

Other Happenings

January

Happy New Year! We here at Pragville wish you a prosperous and fulfilled 2011.

Jan 10

MUD co-creator Richard Bartle is 51.

Jan 10

Donald Knuth, who continues to inspire authors who are having trouble finishing that book, is 73.

Jan 11

Tony Hoare, author of Quicksort, is 77.

Jan 20

Sims creator Will Wright is 51.

Jan 21

Paul Allen is 58.

Jan 22

On this day in 1984, Superbowl viewers watched a woman with a hammer smash Big Brother.

Jan 24

Alain Colmerauer, Prolog’s creator, is 70.

Jan 25

Pac-Man creator Toru Iwatani is 56.

Jan 31

Guido van Rossum, author of Python and possessor of an excellent last name for a programmer (Google “R.U.R.”), is 55.

February

In February, 1986, Richard Stallman published the first official definition of Free Software. In February, 1992, Linus Torvalds first placed Linux under the Gnu Public License. In February, 1998, the Open Source Initiative was founded. And in February, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people wrote the Agile Software Development Manifesto.

Feb 4

Ken Thompson is 68.

Feb 5

Brad Fitzpatrick, author of memcached, is 31.

Feb 7

Leslie Lamport, creator of LaTeX, is 70.

Feb 8

MIT professor Gerald Jay Sussman is 64. Among his other accomplishments, he is a bonded locksmith, so he can stay out till quarter to three and not worry about anyone locking the door.

Feb 12

Phil Zimmerman, author of PGP, is 57.

Feb 15

Niklaus Wirth is 77.

Feb 19

CGDA Hall of Fame game developer Danielle Bunten would have been 62 today.

Feb 22

Bill Jolitz is 54.

Feb 24

The Ruby programming language was conceived on this date in 1993.

Feb 27

Grady Booch is 56.

Feb 29

Seymour Papert would be 83 this year if it were a leap year.

March

Maybe you knew that Edsger Dijkstra’s famous letter “Go To Statement Considered Harmful,” appeared in Communications of the ACM in March of 1968. But maybe you didn’t know that the phrase was not in fact Dijkstra’s, but was attached to the letter by the publication’s editor, Niklaus Wirth.

Mar 1

Yahoo (as a corporation) is 16.

Mar 3

GNOME first came out of its burrow on this date in 1999.

Mar 9

Jef Raskin would have turned 68 today.

Mar 11

J.C.R. Licklider would have turned 96 today.

Mar 13

On this date in 1986, Microsoft went public, creating four billionaires.

Mar 15

A-life pioneer Craig Reynolds, who worked on the first Tron, is 58.

Mar 15

It’s the Ides of March. Beware.

Mar 16

Richard Stallman is 58 and MINIX author Andy Tanenbaum is 67.

Mar 24

It’s Ada Lovelace Day, honoring women in technology and science.

Mar 24

Mac OS X is X today.

Mar 25

On this day in 1995, Wiki went worldwide as Ward Cunningham installed WikiWikiWeb on the Web.

Mar 26

Larry Page is 38.

Mar 31

Evan Williams, co-founder of Twitter, is 39.

Mar 31

It’s the second anniversary of Steve Wozniak’s last appearance on “Dancing with the Stars.”

Shady Illuminations

Wikileaks and the Genie

by John Shade

John examines the drama of wikileaks and concludes that the heroes are the genie and the butterfly.

The internet is a vast and rapidly-expanding store of information. Much like Samuel Johnson. You would have enjoyed knowing Samuel Johnson. In addition to compiling the first dictionary of the English language and annoying his friends with his erudition, the corpulent 18th Century lexicographer suffered from Tourette’s syndrome. So there’s another similarity between Johnson and the internet. OK, maybe you wouldn’t have enjoyed meeting him.

If the internet’s content is vast, its connections are vaster. The number of paths to any piece of information on the internet today is on the order of 2 to the power of mama mia, or umpteen squared. These figures are only approximations, you understand.

My point is, there are a lot of paths. Really, a lot. Take a typical search situation. Say you’re interested in the roots of chaos theory and you want to find the exact quotation in which Henri Poincaré comments on Newton’s three-body problem. I found myself in that situation just the other day, and the first search string that came to my mind was “Won’t somebody kill that butterfly?”

Well, I’ve already tipped you off to the punchline. The search worked. “Won’t somebody kill that butterfly?” led me directly—by which I mean eventually—to “it may happen that small differences in the initial conditions produce very great ones in the final phenomena.” There are a lot of ways to get from here to there on the internet. To me, this would seem to have implications for attempts to censor internet content.

It’s Fun to Say

Which brings us, as so many other paths could have, to Julian Assange.

Twitter account @funtosay posts a new fun-to-say word every few days. @funtosay invites you to tickle your uvula with such fun words as palpitate, periwinkle, verisimilitude, and nincompoop. On December 10, 2010, the chosen word was Assange. Congratulations, Mr. Wikileaks. You’ve got a target painted on your back, but your name is fun to say.

Of course, the place where Assange has arrived doesn’t seem like a very comfortable spot. But just to be different, let’s ignore the tabloid aspects of the wikileaks story. I wouldn’t say I’m not interested in whether Julian Assange is a rapist, or whether he’s a journalist, or whether he’s Not a Nice Person. I ignore tabloid journalism only with great reluctance. But I would say that these questions are irrelevant to the question of whether wikileaks should have released all the documents it has released.

Personally, I find that the more information I have, the less comfortable I am. But since I’ve never been comfortable with being comfortable, I’m all right with that. Just give me the information, is my attitude, and let me ignore it as I will. You may see it differently.

But my opinion and yours may in turn be irrelevant now that the information is out there. It seems to me that the genie can’t be put back in the bottle.

Douglas Rushkoff sees it differently.

Not Free, Never Will Be

Rushkoff is an authority. He is a media theorist, writer, columnist, lecturer, documentarian, consultant to industry and government, former cyberpunk, graphic novelist, and recovering techno-utopian. He teaches, writes books, and regularly appears in GQ and Magical Blend. So you know he’s the real deal.

Rushkoff told a news site, “the stuff that goes on on the Internet does not go on because the authorities can’t stop it. It goes on because the authorities are choosing what to stop and what not to stop.” The internet, he says, is a top-down, authoritarian system that was not designed to be free or open or user-controlled, and never will be.

Which comes as a surprise to those of us who bought the meme that the internet was designed by the DoD to have no central control so that the bad guys couldn’t take it down.

Rushkoff’s point seems to be that the DNS system is a throttle point for the net: you want to shut somebody up, you pull their address from the DNS. And viola—or as soon as the change percolates through the net—ShadyBusiness.com has ceased to exist. Which is accurate enough, but it hardly amounts to government control over what information can and can’t be disseminated. Yes, it’s easier to remember a domain name than an IP address, and yes, taking down a domain name is devastating to a corporation, but not so much to, say, an underground political movement. Which I think is more the point if you’re going to throw around phrases like “the authorities are choosing what to stop.”

Be a Moving Target

Rushkoff surely knows that, so I’m guessing the news site sensationalized what he said. And he did go on to talk about creating distributed alternatives to the DNS system. He’s not alone. There are a lot of people looking at the choke points of the internet and considering how to work around them.

James Cowie did a nice blog on the steps wikileaks took to keep its information alive. It reads like a spy story, which I guess it is, sort of. Over a thousand volunteer sites mirrored the wikileaks content. Ultimately, Cowie concluded, “[t]aking away WikiLeaks’ hosting, their DNS service, even their primary domain name, has had the net effect of increasing WikiLeaks’ effective use of Internet diversity to stay connected.” Wikileaks was a target, but it stayed a moving target.

Rushkoff may be an authority, but I’m turning to Mitch Kapor for the real story, because—well, because I found this paper. Mitch says that 99 percent of the internet is under distributed control, and one percent is—sort of—centralized. He and his co-author detail that one percent. Then they point out that this locus of control is a sort of moving target, too, and add, “Ever since journalists began to notice the Internet, they have been reporting the fatal flaws that are going to stop its growth. The list of flaws keeps changing, however. The Internet has survived as long as it has by adapting, and there is no reason to expect this evolution to stop.”

I’ve never been a fan of imaginary creatures. I don’t know what joy vampires and zombies offer the world that piranha don’t bring in spades. I’m also not a fan of adorable insects. But in anarchy and chaos I trust, so when it comes to rebottling the genie or killing the butterfly, my money’s on the genie and the butterfly.

John Shade was born under a cloud in Montreux, Switzerland, in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He wishes to make clear that it’s not all insects that he’s down on, just adorable ones.

Send the author your feedback or discuss the article in the magazine forum.