It’s nobody’s fault but my own; it’s a wide topic and the narrow bit I wanted to talk about soon was left behind as wider topics aired, and the discussion ranged farther afield than I had prepared data for. Mea Culpa. I did a bad job of preparing myself to guest. It happens. It will be neither the first nor the last mistake I make. (At least I hope it’s not my last; the day I make my last mistake will be the day I die.) You learn from it and move on.

As this whole thing started with me shooting my mouth off, I’ll bring it back here, in a format I’m comfortable with and with a head not so encumbered with medication.

There’s a problem in our industry that we all have horror stories about, but we seem to be treating it as if it’s incurable. And I find that puzzling. Most developers I know got into the field because they loved solving problems. And here’s a problem. Yet we’re acting as if it weren’t possible to solve it?

I can’t accept that. And that’s where I was coming from. We have loads of people who come into our field on their own. They start learning on their own. They code, and they repeat the mistakes that have been made (and solved) decades ago. And there’s a very real and very strong faction in the industry that claims this is As It Should Be.

Bollocks. That is a large steaming pile of male bovine excrement. That is nothing more than the return of the “priesthood” mentality I fought to get away from in the 70′s and 80′s, the idea that programming is a form of magic, and you must endure your initiation rituals through the Hazings of Non-Scalability and Tight Coupling (et al.) before you are worthy to enter into the Holy Hall Of Patterns. It isn’t worthy of us.

I might have sounded a bit flippant there, but I was serious. If we know something is a problem, and we know ways of thinking that can avoid it, and we hold that information back because the developer in training hasn’t “felt the pain” yet, aren’t we doing a form of hazing — intentionally making someone suffer before deigning to let them join our ranks? The road to advancement is hard enough, there’s no need to artificially increase the difficulty.

First, we need to put to a final bloody death the damaging notion that one “cannot begin to understand” a concept until one has “personally experienced the pain” of doing without it. We all have learned far more from the vicarious experience of others than from our own. If I started up a table saw in front of you, I daresay the vast majority of you who did not stick your hand in the blade had never done so in the past. Yet you still learned not to. How about electricity? I suspect far more of you would work very hard to avoid being in a house without electricity for a week of a Wisconsin winter than actually have experienced it. You know it’s something to avoid, even though you haven’t personally experienced it.

No other field of human endeavor seems to suffer from this sort of hubris, that we start as tabula rasa and may only write what we directly experience. A bricklayer doesn’t demand his apprentices lay brick badly before showing them the right way to do it. A plumber teaches her apprentice the right way to do it first, and then checks their work to ensure they did it the way she taught them.

So if other fields don’t work this way, obviously the problem isn’t either incurable nor inevitable. It’s cheap and easy to say programmers all have this or that personality quirk; I just don’t think it’s either valid or useful. I’ve spent 45 years hearing the same drivel spouted about science fiction fans, and I know first hand it isn’t true there, either. Pull the other one.

So how do other fields allow self-starters and self-learners to “get up to speed” in their fields? By preserving, not ignoring, the past. Craftsmen through the ages looked at the work of those that went before them, saw what they did good, and what they didn’t. And passed those judgements on. And we don’t.

I joked the primary function of a junior developer is to write bad code. That isn’t to say the senior developer never writes bad code, but rather that along the road from junior to senior you (hopefully) learn to write less bad code.

It would not surprise me if it were true that every system of any significance ever written contains bad code. But what would absolutely astonish me would be if no system of any significance ever written contains good code. There are plenty of examples, I am sure, of cute ideas coded clearly and used well.

Where we (I include myself in this) have failed is we haven’t called them out. In every other field of literature there are known established examples of excellence that the neophyte can study to learn how to practice their craft better. Writers get not only books about writing, but they get reading lists of great examples of How It Is Done. We leave it up to the beginners to make their choices about what code to read; how can we claim to be surprised by what comes of that?

It’s the same in chess. We have a saying in chess education: “Study The Classics.” Not only are there treatises on the game, or specific phases of it. There are game collections. Beyond that, there are acknowledged masterpieces. You could show a top player today a position from a significant game of a century ago, and they could quote the rest of the game to you, and probably show you two or three similar examples.

But in the world of software development, we have treatises that can be considered “classics” (often with names like Robert Martin, Kent Beck, Martin Fowler or Michael Feathers attached) but we haven’t compiled (you should excuse the pun) the accompanying library of classic code. Where is our “reader’s library” to go with the “teaching library?”

I fear that until such a library gets widely disseminated, we’re doomed to forever repeat the mistakes of the past.

Let me start out with a simple fact: I’m a dog-lover, and I prefer mongrels. Pure-bred dogs (and my first dog was a pure Collie, so I’m speaking from some experience) come with issues. They can be nervous, even neurotic. Quick to anger (or hide). Prone to various diseases and birth defects.

Most of these issues don’t show up in mongrels. The mongrels I’ve owned were stable, loving and useful pets. They weren’t nervy, rarely got sick. The hardiness comes from the genes of one breed canceling out the weaknesses in the genes of another. (It’s like metallurgy. You want the iron to be stronger, more useful, you mix in some other elements. Alloys are the mongrels of metallurgy.)

So it goes when it comes to conferences. The wider the experience and cultural base of the presenters, in general the more they have to offer that I haven’t yet seen or learned. Yum.

Don’t start building that strawman, yet. I don’t believe in diluting the quality of an event just in order to achieve diversity. But I also refuse to accept that a decline in quality is a necessary result of trying to achieve diversity. In fact, just the opposite. All my experience as an organizer points to a properly organized diverse event being of higher quality than a monocultural one.

Let’s take the ruby world in particular, since that’s the concrete example on the microscope slide currently.

BritRuby started with 15 invited and 5 “open” slots for presenters, then filled those invited slots with 15 white males. Now, if I were picking my 15 favorite ruby presenters, I can’t imagine leaving off Sandi Metz (“Go Ahead, Make a Mess”) or Katrina Owen (“Therapeutic Refactoring”) at the very least (I’ve never made such a list, but they’d easily make my top ten). I wouldn’t end up with such a homogenous list without several people turning me down. I have no idea if that happened here, but available evidence (albeit hearsay) suggests not. And that’s unfortunate.

Why is something like diversity an issue? Can’t we just focus on the presentations, and leave the presenters out of it? Well, yes, but the numbers alone suggest such a list is unlikely to come out of a process that actually is blind to presenters, and experiential data is even more insistent on that point. (This Princeton article, for example, shows that when there is nothing except the music to concentrate on, more women are judged the superior performer than when any unconscious gender biases are allowed to influence the process.)

To be fair, I do not for one millisecond believe the BritRuby organizers to be evil, or even moderately chauvinistic, based on this list. I think more likely this is just one more example of the type of unconscious bias shown in that Princeton article: all of us are unconsciously biased towards selecting those in the pool more like us than others. In other words, I “accuse” the Brit Ruby organizers not of being ravening sexist misogynistic pigs, but merely of being human (and no less human than I, if it comes to that).

To me, diversity in a conference is a lot like tests for my code. I don’t write tests because other people want me to. I don’t write tests simply to have tests. I don’t have a specific number of tests in mind when I start writing, nor do I have a target number of tests per lines of code that I am expected to meet.

I write tests to make sure all paths through my code are exercised, and help me maintain that code in the face of changing requirements. My tests help me bring new developers into a project by helping them understand what the code is meant to do, and help non-developers understand what the code is doing, because the tests are easier to understand than the code.

Because of this, in order to write the tests I need to look at my coding task through other’s eyes, forgetting for the moment what I know about implementations and what I expect to do. I wasn’t always very good at this (in fact I used to stink quite badly at it, to be honest) and I still commit howlers even after all my focus on tests.

I rely on other people to see what I don’t. They have a different perspective on the code, so they see different things. After all, it’s not easy to look at code (or other things) from someone else’s viewpoint. Unless, of course, you *are* someone else.

And that’s the point. The more different from me someone is, the more likely they are to think of something I’ve missed, and I’ve learned the hard way that by listening to them I improve my ability to think of those things myself.

We all know “Linus’s Law” (“With enough eyes, all bugs are shallow”) and know its utility. But I’ve discovered that there’s a quality factor to that as well — that the more the eyes are like mine, the more likely they are to overlook the same things I do. I’d much rather have one pair that can see what mine don’t than a hundred pairs that see what I see.

We all suffer from unconscious biases, we all have blind spots that will bite us unless we put up controls for it. A useful one when organizing is to make the program item proposals anonymous, putting up a wall between me and my people biases. A second is to review my list of pre-selected speakers, and ask myself if there’s a valid reason it isn’t more diverse. (There may be one, though if the reason is because all my diverse invitations were turned down, I’d call that an “organizer smell” and start looking for a bug in either myself or my approach.)

Make no mistake about this, I’m not encouraging diversity simply for the sake of diversity. Like code quality in TDD, making everyone feel included is a byproduct, not the goal. I’ve a much more selfish agenda than that. Conferences with the same old guys giving the same old talks are boring. Hearing from minds different from mine, minds built from radically different experiences, strengthens my own, expands it, makes it capable of imagining bigger and better things.

Makes it into more of a tool I can build good stuff with.

I’m going to take as my starting point Donald Knuth’s idea that the main task in software development is to explain to other developers what we want the computer to do, that the primary audience of source code is a human, not a machine. That seems obvious enough to not need much supporting evidence. Nobody lives forever, no one stays in the same job forever; everybody gets replaced, either voluntarily or involuntarily.

While the syntax of the language makes this communication possible, we still need a common conceptual base to make it efficient. Even in English it’s easy to come away from a single sentence with multiple meanings; development languages, with their near-total focus on what over why, can be even more adept at hiding meaning.

Noted psychologist Adrian deGroot performed a number of experiments with the minds of chess players (you just knew I was going to work chess into this, somehow, didn’t you?) but the one that is most relevant to this involves testing memory and understanding of chess positions.

He gave players of varying playing strength a few seconds to look at a “normal” chess position, meaning one that quite easily could arise during actual play, even if it hadn’t. He then asked the players to reconstruct the position from memory on an empty chessboard. The better the player, he found, the more accurately they could reconstruct the position.

Then deGroot repeated the experiment using random diagrams, with pieces in improbable (even impossible) positions. Interestingly, he found good players were no better than anyone else at recalling those “nonsensical” positions.

There’s a reason for this that extends beyond chess. The brain simply isn’t good at remembering lots of little details. It’s as if the brain only has so many short-term “slots” to hold things, no matter their size. So it takes what it sees and “chunks” it into larger groupings that make sense to it. In this way, a grouping of chess pieces that commonly occurs in a game can be remembered as a single unit.

But we’re talking about software, not chess. Or are we? Think about a batch of unfamiliar code in front of you, that you’ve been brought in to revise and extend. If both you and the developer(s) who originally created the code have learned the same patterns, you can take many lines of this code and group them mentally under that pattern, keeping them in your mind efficiently while continuing to read more code.

If you and the original developer(s) of the codebase you’re working on did not have this common “pattern language” to call upon, you would still end up grouping lines of code into “chunks” in order to comprehend it, but you would additionally have to create your own “chunking algorithm” to do it. “Reinventing the wheel” like this is not only inefficient, it runs counter to today’s more pragmatic development principles.

And because you’ve been using a common pattern language, you not only group many lines of the code into a single “slot” in your memory under the name of a pattern you already understand, the odds are you and the original developer(s) had the same chunks in mind. You can build your mental model of the code more quickly and reliably, and your model will more closely resemble the original ideas behind the existing code.

This means even if you’re a new developer, you’d be more productive with a new codebase faster knowing the patterns than if you hadn’t learned the patterns in the first place.

I was listening to Ruby Rogues podcast episode #56 when the discussion turned to software patterns, and my teeth started grinding.

It wasn’t so much about what was said (though there were enough of those moments, to be sure) as about what was implied or left unsaid. With one exception (to come later) I’m going to leave names out of this, simply because I want the discussion to center on the ideas, not the personalities. Listen to the podcast, and you’ll be clear enough about who said what, if the who of it means that much to you. I’ll just say the guest and the rogues are all not short of accomplishments and as a group contain very good developers.

The implication that came out of it, and that was only halfheartedly challenged, was that software patterns weren’t useful things to teach beginning developers. The statement that made the show notes was “You need to feel the pain and understand the pattern before you begin to understand when and why to use it and when to deviate.” While the statement itself is defensible, it’s really irrelevant to the value of software patterns for either experienced or nascent developers. My own first reaction was, “So?, What’s your point?”

I have two problems with the discussion that ensued (for complete context, listen to the podcast). The first is with the implicit assumption in that statement, left completely unchallenged in the podcast, that you can’t understand something until you experience it first hand. This is patently absurd. I don’t have to fall off a cliff, or stick my finger in a light socket, before I can begin to understand it would be bad for me to do it. There is plenty of secondhand experience I can draw upon to inform my actions. (I used this technique with my kids frequently during their childhood, “I’ve already made that mistake, and this is what happened. It wasn’t pleasant. You go find your own mistakes to make.”)

I could possibly let that statement pass unchallenged if we replaced the concept of “begin to understand” with something like “intimately understand” but even then, I wouldn’t positively support it. We’ve proven as a species we can learn from other people’s mistakes often enough that it’s not a newsworthy event when we do.

Software patterns (including the Law of Demeter, which one voice seemed to hate so much it bordered on obsession) are shorthand for techniques commonly found useful in the field. As such, they are generalizations, meaning while they don’t have universal utility (few generalizations do) they are more often useful than not. Yet (I’m not clear why, except that possibly the speaker had seen bad code excused by the coder claiming to be following a pattern) the concept of patterns as something known by beginners was consistently trashed.

One of the rogues (James Edward Gray II, who gets named because the mention is positive, not negative) brought in the subject of chess, which is the most apt analogy to the concept. His point was arbitrarily rejected, but (without even asking for his permission) I’m going to expand upon it here, because he was ultimately correct.

Beginning chess players are taught various “rules” or principles. They are “chess patterns,” so to speak. One widely known one is “Rooks belong behind passed pawns.” This pattern was preached by (among others) Siegbert Tarrasch in his instruction book The Game Of Chess. An amateur, after watching a game which Tarrasch won by placing his rook in front of, not behind, a passed pawn, accused Tarrasch of teaching incorrect principles. Tarrasch replied, “Very well, then. Rooks belong behind passed pawns. Except when they don’t.”

In the chess world, John Watson and Jacob Aagaard carried on a multi-book discussion of the idea of chess principles and their exceptions. It’s not surprising that Aagaard, a grandmaster whose non-chess specialty is cognitive semiotics, took the “pro” position on patterns, against the American IM. As human beings, we learn by recognizing patterns in the world, then by refining that pattern recognition as we process the exceptions. The refinements come as we add to our knowledge base, but before we can recognize the exceptions to the patterns, we first have to know the patterns.

Every rule we have for significant human action has exceptions. So what? That somehow invalidates the rule? Not every software pattern is applicable in every circumstance. The Titanic sank. What should we do, ban ocean liners?

The 1st World Correspondence chess champion, CJS Purdy wrote: “There are chess players who do not know the principles, and are weak. There are those who know the principles, and are less weak. And there are those who know how weak the principles are, and are strong.”

In chess, the top players got there by following the principles, following the chess patterns, unless there was a reason not to. There in the position was the information necessary to judge whether the principle does or does not apply. Their “default state” is that it applies. That fact is itself the only excuse for the principle’s existence — were it not appropriate more often than not no one would care about it.

That’s the way it is with software patterns. I can’t let the idea that people should not follow patterns more often than they follow them stand unchallenged, as happened in the podcast, because I think that is a dangerously stupid idea.

In our haste to kick over the ceremonial idols of our past (and, as a veteran of SDM/70, I can confirm that plenty of them needed kicking over) we have become entirely too eager to throw away everything, rushing straight through iconoclasm into antinomianism. Baby. Bathwater.

We’ve but to look around us to see the effects of that. Uncle Bob talks about how much knowledge we’ve ignored in his presentation from Ruby Midwest, Architecture, The Lost Years. More directly to the point, at MagRails Aaron Patterson talks about how he speeded up Rails routing in Pattern Matching. The biggest point to take away from that presentation is that he did it not by ignoring the patterns and knowledge of the past, but by using them. (I really don’t think that can be emphasized enough. A better, faster, way was already known, years ago. I don’t want to belittle his achievement, the algorithm still had to be investigated and implemented. But that it took this many years for someone to apply this algorithm is, I think, indicative of how far we’ve gone in ignoring knowledge gained in the past.)

The idea that you have to make the mistakes yourself in order to advance (“You need to feel the pain and understand the pattern before you begin to understand when and why to use it and when to deviate”) is poisonous to the idea of any sort of science. We advance the state of the science (or craft, or trade, or art, call it what you like) of software development not by forcing everyone to recapitulate mistakes of the past, but by focusing our efforts on everyone learning from them.

Does that mean that new (and even experienced) developers will not abuse a given software pattern? Of course not. They absolutely will. But when they do, they (and we, by extension) will learn even more about the advisability and applicability of that pattern. And we will all advance (not just the person who “experienced the pain;” all of us). Tomorrow’s developers will see more details of software development than we do because they’re standing on our shoulders. If we force them to eat the same dirt we did, it may make us feel better about our own past, but it really won’t help them progress beyond us.

The implementation details of this aren’t easy; nothing worthwhile ever is. The final stop is the code, obviously, but before the code comes the idea, and that’s the territory for software patterns, just as the place for chess principles is in the realm of thought, not move. Sometimes that rook belongs somewhere else; sometimes that pattern doesn’t apply. But in neither case can you consider whether it applies until you know the principle, the pattern.

It means bad code will be written. But that’s a universal constant, not a consequence of software patterns. And bad code written in support of even a good pattern should not stand. But was the bad code the result of a good developer following a bad pattern (perhaps an anti-pattern) or is it the result of misapplying a pattern or badly implementing an appropriate pattern? Only in the first case do we question the value of knowing the pattern; in the second case we question ourselves, add to our own knowledge store (and, hopefully, pass the knowledge on to others).

In software development as in chess, a knowledge of the basic patterns of the endeavor is invaluable to our advancement in the field. It is the way in which we “stand on the shoulders of giants,” to borrow Newton’s words. It’s the way we become more productive than those who went before.

Software development patterns allow us to make new mistakes, rather than recapitulate past ones. And while repeating old mistakes will merely lead to our own improvement, making new ones will improve everyone.

OK, after the last installment I had a working in-browser test runner (standalone Jasmine) and a working command-line test runner (phantom-jasmine). But they were different files, meaning if anything significant changed, I was going to have to duplicate the changes in two different testing files. This, while workable short-term, is not an acceptable solution.

So I dug in to the files.

Upon examination, the browser runner that came with standalone Jasmine included the exact same jasmine files that the command-line runner that came with phantom-jasmine included, so I could dispense with those. But the reporters were different.

The standalone Jasmine used the HTMLReporter from jasmine-html.js, but that reporter wouldn’t cut it from the command line. And phantom-jasmine used a custom-written ConsoleReporter that wasn’t included at all in standalone Jasmine.

So I had some reconciliation to do. I revised the testing script in my testrunner file (I used the standalone Jasmine specrunner.html as my base file, because it already included most of what I wanted it to be) and revised the test script in it to be:

  var console_reporter = new jasmine.ConsoleReporter()
  var htmlReporter = new jasmine.HtmlReporter();
  var jasmineEnv = jasmine.getEnv();
  jasmineEnv.specFilter = function(spec) {
	return htmlReporter.specFilter(spec);
  };
  jasmineEnv.addReporter(htmlReporter);
  jasmineEnv.addReporter(console_reporter);
      var currentWindowOnload = window.onload;

      window.onload = function() {
        if (currentWindowOnload) {
          currentWindowOnload();
        }
        execJasmine();
      };

      function execJasmine() {
        jasmineEnv.execute();
      }

Originally, phantom-jasmine used the TrivialReporter, but that’s marked as deprecated currently, with the HTMLReporter suggested as the replacement for it, making this easy, because the specrunner file already used it.

Then I moved the ConsoleReporter javascript file into a “vendor” directory in my jasmine directory and added a <script> tag to point at its new location. Voila! The tests now ran from either source. A single file ran the same tests either from the command-line or the browser.

I mentioned I’d been using the command-line to run the tests for a while, and while I had been developing with it I noticed the reporting from it wasn’t what I’d like it to be. So I dug into more of the code.

Everything I needed to change was in the method “reportSuiteResults.” Originally it read:

  proto.reportSuiteResults = function(suite) {
    if (!suite.parentSuite) { return; }
    var results = suite.results();
    var failed = results.totalCount - results.passedCount;
    var color = (failed > 0)? "red" : "green";
    this.log(suite.description + ": " + results.passedCount + " of " + results.totalCount + " passed.", color);
  };

Note this completely skips reporting on the top level of describe blocks, so while you may know a little of what you’re testing, you don’t know the full context. Plus, if you had a series of tests that were at the top describe level, the results weren’t reported by this code. Not Good.

So I revised the code to be this:

  proto.reportSuiteResults = function(suite) {
    var results = suite.results();
    var failed = results.totalCount - results.passedCount;
    var color = (failed > 0)? "red" : "green";
    var mySuite = suite;
    var description = suite.description;
    while (mySuite.parentSuite) {
        mySuite = mySuite.parentSuite;
        description = mySuite.description + " " + description;
    }
    if (!suite.parentSuite) {
        this.log("-- " + description + " spec subtotals: " +
            results.passedCount + " of " + results.totalCount + " passed.",
            color);
    } else {
        this.log(description + ": " + results.passedCount + " of " +
            results.totalCount + " passed.", color);
    }
  };

This starts out pretty much the same as the original code. But it captures the describe blocks at every level, including the top, and concatenates them into one long sentence. It then creates either a subtotal line for an outer describe block or a results line for the inner describe block. This change helps me more easily find which tests ran fine and which ones didn’t.

I’m not sure this is the exact thing I’m looking for in this reporter, yet, but it’ll do for now. And hopefully I’ve given you some ideas for customizing the Jasmine reporters yourself. Let me know if you find some interesting things to do in them.

I’m talking sane development practice, not ghost stories.

I’d been using jsTestDriver for a while, but got tired of the way it would take off and go navel-gazing without warning, so I looked for something else and found Jasmine. This was working well for me (I was using the standalone version of Jasmine, which required me to refresh the browser whenever I wanted to test in it) but I missed the convenience of kicking off the tests automagically, from a command line.

Then I found the Phantom.

PhantomJS is a project that creates a webkit-based browser in headless form, quite useful for running things that don’t require a UI, such as tests. And, best of all, it installs easily under OS/X, providing you use homebrew on your mac. (Installation instructions for OS/X and other systems can be found here.)

For me, it was as simple as:

brew update
brew install phantomjs


And phantom was installed.

Then I turned to phantom-jasmine to hook the Phantom up with jasmine 1.2 and I was ready to roll. It was a simple matter of cloning the phantom-jasmine repo down unto my system, then popping the TestRunner.html file in place and pointing its internals at the locations I’d placed the code.

Invoking the tests from within my development directory turned out to be a trifle tricky, but nothing extremely complex:

phantomjs ../phantom-jasmine/lib/run_jasmine_test.coffee TestRunner.html


To break this down, “phantomjs” is what I installed with homebrew, the “../phantom-jasmine/lib/run_jasmine_test.coffee” parameter is from the phantom-jasmine readme (strictly cargo-culted, er, copy/pasted from the readme, it is the coffeescript that actually loads and runs the specified page) while the TestRunner.html file is the page to be used to run the tests. It was placed in my project root so this command line was run as if from there.

For a more concrete example, have a look at my Marshall project. I didn’t include TestRunner in the repo (perhaps I should have) because it relied on the configuration of my dev system, specifically the location of the phantom-jasmine project, but I’ll reproduce it here for your benefit:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>Jasmine Test Runner</title>
<link rel="stylesheet" type="text/css" href="../phantom-jasmine/vendor/jasmine-1.2.0/jasmine.css">
<script type="text/javascript" src="../phantom-jasmine/vendor/jasmine-1.2.0/jasmine.js"></script>
<script type="text/javascript" src="../phantom-jasmine/vendor/jasmine-1.2.0/jasmine-html.js"></script>

</body>
</html>


You’ll note the phantom-jasmine directory is located alongside the marshall project files in my dev directory on my dev machine. This isn’t necessary, just my custom.

Every other reference is based around the TestRunner being in the project root.

I’ll leave as an exercise for the reader the right way to integrate the command-line test execution into your chosen IDE.

This is interesting. Ron Donachie played Ser Rodrik Cassel on Game Of Thrones, the hot HBO series from the series of books by George R. R. Martin. as well as the heroic Steward from “Tooth and Claw”, the episode of Doctor Who that gave birth to Torchwood. He’s definitely got the cred for WorldCon.

But, as our Programming Head observed, there isn’t always a good place to fit an actor in. (WorldCon, I should explain for those of you unfamiliar with that land, is a gathering focused on the literary works of science fiction and fantasy. Media properties are welcome, and there are program items for fans to discuss them, but largely WorldCon is a place where Author, not Actor, nor even Director/Producer, is King.)

So I scanned the list of upcoming items looking for a fit. The Doctor Who discussions center around the Moffat/Smith years, alas. Then I see a panel devoted to discussing Season 1 & 2 of Game of Thrones. We talk about it, but it already has the full complement of panelists so we’d have to throw somebody off to make room for him, and it’s in one of our “normal” programming rooms, meaning we might overflow it terribly once we announce his addition to it.

Then I see the list of panelists and Lee (yes, that Lee) is one and I can’t let this slip by. I know she’s on wheels and parks at the end of the panel table, so there will be an empty chair even if the full group is there. And I know she’s a big fan of the series.

“How about we don’t announce it? We’ll just have him show up unannounced and join in. A special treat from him for the hard-core fans?” The eyes light up around the table and it’s agreed. If Ron Donachie can possibly make the time, he’ll be there.

I can hardly contain myself. Aside from this being my suggestion, you have to worry when sending a Name into a fan discussion. Names can be intimidating, even unintentionally, and can change the entire dynamic of the panel. And, back to the personal level, I owe Lee and disrupting her discussion is not In My Plans.

So I waited outside the door to see the results of my meddling. Yes he could make the time, and yes it worked out splendidly. Ron Donachie’s participation was met with rave reviews from panelists and audience alike. For your part in this, Mr Donachie, accept my thanks and IOU.

And for you, Lee: It took me two years, but I finally got you back!

It was nearing the end of the arrival day at a large convention some years back. The identity of the convention is irrelevant to my point, so I’ll neither name it nor explain it.

This thing had started going pear-shaped before I ever got to the office. I didn’t know how I was going to manage things, if I even could. I’d been making a few changes here and there, but nothing seemed to help. I was on the point of just giving up.

Then this feisty lady wheeled up to my desk (OK, table). We had not been kind to her at all, and she had some (valid) points to make about this. At the end of it all, she drew herself up, looked me in the eye and said:

“I know you. You’re better than this.”

I’m sorry Lee. You had more to say after that point, but try as I might, I don’t recall what it was. I’m not sure I ever really heard it. I was stuck on that line.

One of the least attractive features of the truth is the way that nasty little stinger in its tail generally finds the most sensitive spot to dig in and deliver its payload. This was no exception.

I sat there, well and truly stung, still processing those words as I watched her wheel away. I couldn’t say anything; she was right, hang it. I was better than this. Those four little words got farther under my saddle better than any burr. A couple of the people working for me noticed the change, and settled in beside me for the ride.

I won’t say I made that pear-shaped monstrosity work, because I certainly didn’t. We did. It was a team effort all the way; I merely stood up on my hind legs and played my role. By the end, we were getting compliments about how smooth it was going and how much better it was than the speaker thought (or was afraid) it would.

But the story doesn’t end here, nor is it simply about the one convention. There have been times since then, at conventions and elsewhere, when I’ve been backed into a corner and tempted to just “phone it in.” But whenever that moment has come, I hear the wheels roll up, and those four words, all ground up in gravel, drop into my inner ear: “You’re better than this!”

I thanked her for it after the convention, but I never really had the chance to thank her properly, until recently.

But that’s another story.

I may be giving too much credit to Mike Stackpole, Rick Loomis and the rest of the crew at Flying Buffalo for inventing the genre, but I give them credit for coming up with an interesting way of bringing interactivity to paper.

Creative as it was, the resulting stories were difficult to read. I had to stop every few sentences to turn pages, and jumping around through the book like a peripatetic kangaroo kept me from getting involved in the story itself, kept me all too aware of the medium rather than the message.

Yet how many of us today follow this noble, but failed, experiment when writing our code?

We begin writing our methods with the best of intentions. We lay out the opening scene (the arguments) and launch into the gripping tale of what is happening to them.

Yet only a few lines into the story, we stop. We interrupt the narrative flow in order to make a decision and send the reader off to somewhere else, with no regard for what is happening in the main storyline.

It might be something simple. We might break the reader’s concentration with something like:

id = params[:id].nil? ? 1 : params[:id]
Model.find(id)

Not only that, but if you wanted to be sure you weren’t getting slipped something troubling, you’d also have to check to see if what you were handed as the id actually is a numeric, and if not, handle that separately. It may be a small thing, but it distracts the reader (and ourselves) from the main point of the adventure, which is what we’re about to do with that id.

But we have to be sure there’s something both safe and useful in that id before we use it, I hear you say? Of course we do. It’s just there’s a better, more reader-friendly, way to word that. A way that will do less to distract our reader from our main plot.

If we use the fetch() method instead of simply [] to get the value, we can specify a default to use if the index is unset. This means we’ll get a real value back, no matter what, and won’t have to test for Nil and do any conditional branching to handle it as a special case.

Adding the .to_i method at the end of that (something we couldn’t do so long as the possibility of getting a Nil remained) will make the received value safer to use, by returning zero (a number) if the id value is anything but a number, which means the find method will always have a parameter it can work with, so we can drop it directly into the find:

Model.find(params.fetch(:id, 1).to_i)

This single line pulls from the model by id, supplies a default value of 1 if the id has not been given, and makes sure the given id is in fact a number, returning a zero if it isn’t.

By doing this we’ve handled the problems of Nil and non-numeric input at the same time, so we can guarantee the model will get a type of input it can use; failure in finding the zero id (the result of trying a non-numeric id) can be handled exactly the same as any failure to find an id not present in the database.

Look at your own code, this time realizing you’re telling the story of what happens to the data it encounters. Remember, the code you write today will be read tomorrow, either by yourself or someone else. Use good storytelling techniques to make that easier.

Tell the story of your code clearly, keeping digressions like error handling out if the main narrative flow as much as possible. Keep the main purpose of the code in a smooth unified narrative flow, so as not to confuse your reader. Your reader (who might also be yourself at some future date) will thank you for it.

And so will your code.

The issue with the ruby install is subtle, and doesn’t really show up until long after you have installed it. The issue is it points the gem repository to the wrong place. It points the gem repository to /usr/local/lib/ruby/gems/1.8 which is where the 1.8 gems should reside, not the 1.9 gems.

The ruby 1.9 gems should reside at /usr/local/lib/ruby/gems/1.9. And the default install doesn’t set that up. A sure way to make that happen is to put:

RUBY_DEFAULT_VER=1.9

in the /etc/make.conf file. It’s possible that adding the “-E RUBY_DEFAULT_VER=1.9″ flag on the make command will do the same thing, but I found the make.conf change worked, so I stopped at that point.

Make that change before you install ruby19 from the ports:

cd /usr/ports/lang/ruby19
make install clean

After that, the gems will install in the right location and everything will be work the way it’s supposed.

Nginx

The regular ports install for Nginx, on the other hand, is defective from the get-go. While the ruby issue is a subtle one that may not even pose a problem in some circumstances, the ningx issue will prevent the server from responding to any control scripts.

The issue here is the default configuration script points the .pid file to the wrong location. In the default nginx.conf file installed by the ports system is the line:

pid logs/nginx.pid;

This means the control scripts will not be able to find the nginx.pid file in order to send it signals. Instead the line needs to read:

pid /var/run/nginx.pid;

This will locate the nginx.pid file where the control scripts can find it, and everything will work.