PragPub 2010-10: Issue #16

Table of Contents

Features

HTML5: Accessibility For All

by Brian Hogan

One in every ten people in the world has some sort of disabiliy. That’s 650 million potential users of your software, and 650 million people you should think about when developing web sites.

What Agile Is Not

by Jeff Langr, Tim Ottinger

Jeff and Tim shuffle the Agile deck and come up with some jokers.

Good Code Tells the Truth

by Hew Wolff

Your editor’s favorite characterization of good writing is from Rust Hills, former fiction editor of Esquire magazine: “clarity of perception and expression.” Hew Wolff is talking about something similar here when he characterizes good code as truthful.

When Did That Happen?

by Dan Wohlbruck

This month marks the 149th anniversary of the beginning of electronic messaging.

Your Halloween Costume

by Jeremy Bingham

Courtesy of the Chinese and Goodwill, Jeremy offers you this 2010 Halloween costume.

Departments

Up Front

by Michael Swaine

The Easter Eggs of October

Choice Bits

It was a dark and stormy night, and I shuddered with eldritch dread to think that somewhere out there novels were being written on Twitter.

Guru Meditation

by Andy Hunt

“Oh I’ll Remember That.” No, actually, you won’t.

Way of the Agile Warrior

by Jonathan Rasmusson

It starts out so hopefully. As you begin the project, you and your team are all on the same page. Or so it seems. Then you start actually building, and you realize that you all had something different in mind. Has it happened to you?

The Quiz

by Michael Swaine

A monthly diversion at least peripherally related to programming.

Calendar

Jared Richardson, author of Ship It!, will talk about “The Value of Value Story Cards” at Agile Development Practices East in Orlando, FL in November. Also, Linux turns 19. And other items for your calendar.

Shady Illuminations

by John Shade

Our resident curmudgeon taps into the mind of Linus Torvalds and finds a kindred spirit.

Except where otherwise indicated, entire contents copyright © 2010 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

The Easter Eggs of October

by Michael Swaine

This is our October issue, and for many of us, October is a time of witches and spirits and too much candy. Scary stuff. In that spirit, we’ve scattered October and Halloween references throughout the issue, some of them more overt than others. Consider them our October Easter eggs.

Moving right along...

We’ve got another Guru Meditation by Andy Hunt that I think you’ll find memorable. And this issue introduces a new column by The Agile Samurai author Jonathan Rasmusson. It’s called “Way of the Agile Warrior” and the first one takes on the ten questions you’d be crazy not to ask at the start of any project.

Brian Hogan, author of HTML5 and CSS3, looks at new features in HTML5 that can make it easy to make your sites more accessibile. Jeff Langr and Tim Ottinger, authors of our upcoming Agile in a Flash card deck, talk about what Agile is not. Hew Wolff offers a spirited defense of the thesis that good code tells the truth; Dan Wohlbruck has another history article, this one focusing on the invention of the telegraph; and Jeremy Bingham gets into the spirit of the season by taking us on a shopping trip.

We also have the usual quiz, events calendar, and collection of interesting bits harvested from the fields of tweet. Oh, and John Shade finds a kindred spirit in Linus Torvalds, only to lose him again before column’s end.

So welcome to this issue. We hope if finds you in good spirits.

Next issue, along with the technical articles, we’ll be tackling a subject close to our hearts: writing. We’ll talk with Susannah Pfalzer, who took on the job of Managing Editor for The Pragmatic Bookshelf earlier this year. We’ll ask her what it’s like to write a pragmatic book for us, and how you can get your foot in the door. We’ll delve into what we think makes a good technical book, and offer some writing advice. Who knows, maybe we’ll even include a little fiction or poetry. Watch for it on Wednesday, November 3.

Choice Bits

Tweets as Literature

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 | 1 | Agile Web Development with Rails
2^ | NEW | Pragmatic Guide to JavaScript
3^ | NEW | The Agile Samurai
4v | 3 | The RSpec Book
5 | 5 | HTML5 and CSS3
6v | 4 | Hello, Android
7v | 2 | Pragmatic Guide to Git
8 | 8 | Seven Languages in Seven Weeks
9^ | NEW | Continuous Testing with Ruby
10v | 7 | Programming Ruby 1.9
11^ | NEW | Pragmatic Guide to Subversion

One synonym for to follow is to succeed. Yeah, doesn’t make much sense to us either.

Where (most of) our authors are (by postal code). http://mapalist.com/Public/pm.aspx?mapid=132723 — @pragdave

The Tweeting Writer

I'd like to just sit in my chair / and work on my faraway stare. #couplet #micropoetry — @ldwilkinson

And their words to the root and the rock would echo down, down and the magic would hear and answer, faint as a falling butterfly. — @TwitterFiction

your => you're .... we were just talking about remedial apostrophe training for programmers this morning. — @jimweirich

anyone know how to correctly escape air quotes within air quotes? — @markryall

After you broke up with me, I got a call from imaginary you. She's not afraid of commitment or my family. We're getting married in the fall. — @VeryShortStory

Marriage cast a spell. You were my warlock in wedlock; I was your hitched witch. Time killed all our charms. We became divorced of any magic — @DeadEndFiction

Sadly I found, in her cupboard, / the works of L. Ron Hubbard. #couplet #micropoetry — @ldwilkinson

The Coding Life

Last night I dreamed I had to find a 1pF ceramic capacitor and some solder in time to save the Universe. I wonder what's in store tonight? — @undees

I might just be one of the geekiest people I know. Just help my wife setup a BaseCamp project for our home projects. — @tswicegood

It would never have occurred to me to outsource flirting on dating sites. The future is now! http://tinyurl.com/2a3x29s — @trevorburnham

Druidry recognized as a religion for first time in Britain http://on.cnn.com/d2MxQM — @cnnbrk

Isaac wants a new top level domain .arg in honor of talk like a pirate day — @bdudney

best. client. perk. ever. period. drove a 60-ton semi today at scania. awesome power. — @KentBeck

"Madagascar" and I both take credit for the fact that the toddler now refers to her mother and sister as "giant freaks." — @undees

it's so sad how Dr. Banner keeps getting run out of town, just for being different — @stuarthalloway

Good:

Sitting in a downtown coffee shop, doors open, listening to Dylan, sipping a hot steaming cup of "keeps me awake at night", slinging Grails. — @scottdavis99

Better:

Hanging in Starbucks working on article for prags upcoming October issue: http://pragprog.com/magazines — @jrasmusson

Don't ask me to fix your computer. I'm a software engineer; I break computers. — @unsaturated

Agility and Road Rash

Did #Jrubyconf5k in 33 minutes including < 1/2 mile of limping. At least it is a new type of pain. — @chadfowler

New Skin on road rash ... Stings; not recommended. — @mzarra

My wife just asked me if I've had my bike ride today, in the same tone a sitcom hubby would use to ask his wife if she's had her Midol yet. — @undees

Just realized why lifting the weights was suddenly so hard, they're in Kg and not LB, darn it. — @venkat_s

Loved the Movie, Hated the ’book

The Facebook movie (The Social Network) was well worth it. Seeing wget used appropriately in a mainstream Hollywood movie was nice. — @scottdavis99

Aaron Sorkin did a great job and made a movie which I thought I would despise interesting. Loved the @CoupaCafe reference and I am happy... — @dalmaer

The Social Network soundtrack is great, Nine Inch Nails chiptunes http://www.youtube.com/watch?v=Yczul_609Gg — @codinghorror

The White House is proposing a way to spy on suspects while they're online. The plan is called "Signing them up for Facebook." — @ConanOBrien

If Scorsese makes a movie about Foursquare I'm going to kill myself. — @claytoncubitt

Duly Noted

MYTH BUSTED: The average person does NOT swallow 8 spiders a year while asleep! Where did this myth originate? --> http://bit.ly/bi1SD3. — @OMGFacts

Ever have one of those amazing meetings where everything clicks, people are taking notes and stuff gets done? Me neither. — @shanselman

Personally, I think the user is a better starting point than "requirements". — @ambroselittle

"New Media" experts are just "Old Media" experts trying to survive. — @MrAlanCooper

There always seem to be more drunks in the first class cabin. — @mzarra

Language Warts

Looking through Ruby's standard libraries is like taking a tour around Unix ca.2000. Perhaps it's time gemify some of this stuff. #ruby192 — @pragdave

"When C++ is your hammer, everything starts to look like your thumb." — @focus

every message send in a program built of objects is a case statement waiting to happen — @KentBeck

Ruby's Enumerable module—so called because its methods are barely — @pragdave

(How to Write a (Lisp) Interpreter (in Python)) http://bit.ly/aX6aly – 90 lines of Norvig code, roughly equal to 5k LOC of mortals — @stilkov

On a related note, it seems 21 Peter Norvig Python lines equal 18 Rich Hickey Clojure lines: http://bit.ly/atOkM6 — @stilkov

The Reviews Are In

Dr Dobbs review of iPad Programming: "quite a bargain, given the smart and concise way the authors demonstrate iPad-specific features" — @PragmaticAndy

Heh: The Pragmatic Programmer is the most popular book in the ACM "Programming" Online Bookshelf. Pretty cool... — @pragdave

Today, Pomodoro Technique Illustrated is 2nd in Time Management-Bestseller at Amazon.de. David Allen/GTD is 1st. http://amzn.to/9kKouE (Sept 22) — @staffannoteberg

Today, I'm the top story in CFO World magazine (in Swedish) http://cfoworld.idg.se/ (Sept 29) — @staffannoteberg

Wind in the sails! First review for Agile Samurai from Dr. Dobbs: http://bit.ly/alZMr2 — @jrasmusson

In a Manner of Speaking

I didn't realize all of this talk about "unmanned drones" was actually referring to Congress... — @PragmaticAndy

I cannot express how happy I am that 'Little Bobby Tables' is gaining ground as a nickname for SQL injections — @bscofield

"Servers are melting from all the excitement"?! Not acceptable spin for "our devops can't predict/handle load." — @tswicegood

I'd suggest you stop shooting yourself in the foot, but I'd hate to take the one thing you're good at away from you. — @UrCodinItWrong

You can follow us on twitter.

Guru Meditation

The Programmer’s Rememberall

by Andy Hunt

Your memory isn’t as good as you remember. Here’s how to deal with that.

In the popular Harry Potter series, one of the characters (Neville, if I remember correctly) gets a gift of a Rememberall: a magic ball that glows and swirls with magic energy to remind you that you’ve forgotten something important.

The problem is, it doesn’t have a text display (something many of the magic devices at Hogwarts seem to be lacking). It can only tell you that you’ve forgotten something, but it can’t tell you what you’ve forgotten.

For most of us programmers, this thing would be going off all the time.

Remember the Future

There’s no end to all the little things we think will remember later on in the project. But of course, it doesn’t quite work that way. As soon as you find yourself saying, “oh, I’ll remember that later,” stop. You won’t.

There’s a Chinese proverb that says the palest ink is better than the best memory, and that’s exactly right: human memory is notoriously fallible. From introductory psychology classes to police interrogations, experts can have a lot of fun with people proving that their memory isn’t what they think it is. It’s actually pretty easy for your brain to confuse imagined events with real memories. The problem is that memory isn’t written to some static store in the brain like a gigantic disk drive. Instead, each memory is an active process; a small electrochemical machine that can’t stop running or the memory is lost.

And it’s not static at all: every time you access that memory, the memory will be changed a little bit. This happens so often and so automatically that you might consider that every read is a write. In other words, your memories are constantly rewritten in light of your current context: age, experience, worldview, focus, and so on. That incident at your sixth birthday party? It probably didn’t happen that way, and it may not have happened at all. Those decisions you made back at the start of the project? Or even just last week? Do you really remember why you wrote the code the way you did, or why the architecture took that particular direction? Probably not. Your memory has been modified in the meantime, updated with new data and new perceptions.

The solution is to heed the Chinese proverb and use some ink: start and maintain an engineer’s log of notes from design meetings, coding questions and solutions, and so on. You can use one of those composition notebooks that you might have used back in college, or a nice Moleskine, or just a yellow legal pad. I prefer to use something non-electronic (for one thing, it’s harder to modify and revise original notes.) But you might use a set of text files, or a Wiki, to keep notes. That at least has the advantage of being searchable, and possibly time-stamped.

The rule here is simple: if you need to remember it, write it down.

Wait, what?

Nothing is more irritating than being interrupted during the middle of a long coding or debugging session. Once you’ve been interrupted like that, it can take 20 to 30 minutes to get back into your flow and restore your context.

Interruptions play havoc on your memory. What were you doing? Or more importantly, what were you going to do next? It can be really hard to remember these things once the interruption is over and you get back to the task.

But there is a technique that can help: you need a task resumption cue. You’re sitting there, deep in your task, and the phone rings. The boss is standing next to your desk. Whatever the interruptor, you’ve got about a second or two to act before the interruption takes full hold over you. Use that time wisely.

Drop a resumption cue—some small bit of text that will help you remember your context when you come back. For instance, you’re in the middle of typing a line of code and the boss pops up like a cubicle-farmed prairie dog wanting to talk to you. Quickly, just type out the thought in your head: what you’re doing and what you need to do next. This doesn’t need to be full sentences or even anything that makes any sense to anyone else. You might end up with something in the code like this:

int x= add exp handler chk frozbot and xyzzy

You were in the middle of a declaration, but you had just a second to add some text about what you were doing. Now when your interruption goes away (“fell or was pushed”) you can return to your code and more quickly restore your context and resume your task where you left off: “Oh that’s right, I need to finish the exception handle and then go check these other two modules, Frozbot and Xyzzy”

The programmer’s Rememberall is text, plain and simple. Jot yourself a note, leave yourself a task resumption cue, and you’ll be better off than all the wizards at Hogwarts.

Something to think about.

Andy is a Pragmatic Programmer, author of a bunch of books, 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.

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

Way of the Agile Warrior

Ten Questions You’d Be Crazy not to Ask at the Start of Your Project

by Jonathan Rasmusson

It starts out so hopefully. As you begin the project, you and your team are all on the same page. Or so it seems. Then you start actually building, and you realize that you all had something different in mind. Has it happened to you?

How many of your projects start off like this: You and your team get together at the start of your project thinking you are all on the same page?

And when you start building something, you realize you were thinking something completely different.

This happens all the time on projects: assuming there is consensus when none exists.

While good teams can roll with these punches and adapt as they go, it’s a form of waste that can hurt or kill the unwary before they even get out of the gate.

To nip this problem in the bud, at ThoughtWorks we created a lightweight project chartering tool called “The Agile Inception Deck: 10 questions and exercises you’d be crazy not to ask before starting your project.”

These questions serve two goals: alignment and expectation setting.

Alignment is about making sure you and everyone else are on the same page with regard to why we are here, what we’re trying to do, and how are we going to get there. Basic stuff.

Expectation setting, on the other hand is about you communicating clearly with your team and stakeholders what it is going to take to make this project a success. You are defining the rules of engagement.

“Yes we can build that for you. No it shouldn’t be too difficult. Here is what it is going to take....”

You need to have that conversation early and make sure your customers know what you’ll need to best serve them. Don’t assume. Be explicit and ask.

How do you know what your customers really need? A good place to start is to ask them:

1. Why Are We Here?

You can’t build a great product if you don’t know why you are building it in the first place. Asking why gives you and the team the context you need to make all those smart decisions while executing.

For example, say you were hired by a construction company to create an online road-closure system for mapping which roads were closed by date on a given construction site.

An obvious question that would help you and the team build the solution is asking “why?” Why is the company spending shareholder capital on this project in the first place?

Is it about safety? Is it a regulatory requirement? Or is it to act as a traffic broker for the efficient movement of material and goods on the construction site?

Knowing and understanding the number-one driver behind your project is going to give you the insight to make those balanced trade-offs that inevitably come up during delivery. You can’t do that if you don’t know why.

2. Create an Elevator Pitch

Projects can be a lot of things to a lot of people. This exercise is about making sure they are not.

A good elevator pitch tells people what your product is, who it’s for, and why it’s special in about the time it takes to take a ride in an elevator.

Creating a good one can be harder than you think. But once you get it, it feels great. You can quickly distill a big abstract concept (which is how most projects start) into something tight, real, and concrete.

3. Design a Product Box

Thinking hard about your product from your customer’s point of view is always cool. Not only does building a product box get you in the head of your customer, it’s a great team-building exercise, as you are formally given permission to draw and color at work.

You don’t have to come up with anything elaborate or complex. Just ask yourself:

What are the top three reasons people are going to buy this product?

And if there was one slogan that captured the spirit of this thing, what would it be?

4. Create a NOT List

Saying yes is easy. It’s saying no that is hard. The NOT list starts to put some stakes in the ground and to set expectations around what you are not going to be doing as part of this project.

Saying what you are not going to do is powerful. It eliminates a lot of up-front waste by letting the team focus on the stuff that is clearly IN while ignoring everything that is OUT. It is from the IN column that all of your high-level user stories will flow.

Also, it’s not uncommon to have a lot of things that could be in scope but for whatever reason (usually time and money) aren’t. Better to resolve these now than to leave them till later.

This is really a “big rock” scoping exercise. All you are saying here is: “If we move these big rocks as part of this project we are going to be OK.”

5. Meet Your Neighbors

I once almost lost a project because I didn’t appreciate that your project community is always bigger than you think. It’s easy to think it’s all about you and your core team. But the reality is that most projects require more than just the day-to-day people on the project to be a success (especially in big companies).

This exercise is about getting you and the team thinking ahead of time about who you are going to want to meet and establish relationships with before going live. Not only is this courteous, it lets them prepare for your arrival and be there when you need them.

6. Show the Solution

You pick your architecture when you pick your team so you’d better make sure everyone is on board with your solution before you begin.

This exercise is about telegraphing your punches. If you are counting on solving this project using a certain set of tools or architecture, better to let them know up front. You’d hate to be caught off guard because of some corporate standard.

This is also your opportunity to come clean if you don’t have all the answers (that’s OK too!) Let them know.

7. Ask What Keeps Us Up at Night

There are a thousand things that could wrong on our projects. Some we can handle. Others we can’t. This exercise is about making sure we identify the risks that are worth worrying about and not sweat the ones that aren’t.

For example, you can’t do much to prevent the economy collapsing, or your customer getting promoted to VP of Engineering. So don’t sweat it.

Having full-time dedicated team members, however, is something you can manage and is worth fighting for.

This is your chance to call out the craziness before the project begins and fight for what you are going to need to make this project a success. You may not get everything you ask for, but it never hurts to ask.

8. Size It Up

This exercise is about answering the question: is it bigger than a breadbox? We can’t say exactly how many days it’s going to take to do this project up front. But we can say whether it’s a 3-, 6-, or 9-month’er.

To do this exercise you’ll need to do some high-level story planning and estimation. The NOT list will serve you well here. And you will need to come up with some high-level numbers to at least give your stakeholders some idea of how big this thing is and what they are looking at.

The point here isn’t precision. It’s to determine whether this project is even remotely feasible with the resources you’ve got.

9. Be Clear on What’s Going to Give

All projects have levers like time, money, scope, and quality. Better know going in which of these is most important, and which ones can flex.

For some projects it is all about money. For others it’s all about the date.

You need to have this conversation up front so you’ll know, when push comes to shove, whether you are going to be able to flex on scope (preferred) or whether you’ve got wiggle room around the date.

The other thing you’ll want to discuss is: what is the one thing that would really knock this project out of the park? Is it ease of use? Simplicity? Speed? Flexibility? Safety? Write those things down and make sure they are on everyone’s radar before you start out. These high-level aspirations can be your guideposts when things get dark.

10. Show What It’s Going to Take

This exercise is about the two questions burning on every stakeholder’s mind: how long is this going to take and how much is it going to cost?

If this is a pre-sold piece of work, your budget may have already been set. In this case all you need to do is some simple table napkin math to see if this project is feasible given the cards you’ve been dealt.

This is also your chance to show what kind of team it’s going to take to pull this off. Here you can set expectations around team size, skill set, and the mix of cross functional skills necessary to make this happen.

It’s About Getting the Right People on the Bus

Doing an inception deck for your project isn’t magic. It’s simply a matter of getting the right people in a room, asking them the tough questions, and then sharing the results with your stakeholders and everyone else on the team.

It can take anywhere from a couple days to one or two weeks to complete and is usually good for 3-6 months of planning. But it’s an invaluable tool for setting up-front expectations on your project, and for reminding people what you and your project are all about.

So before starting your next Agile project, make sure you ask the tough questions up front and get everyone aligned going in. You’ll look like a pro and it will set your project up for success long before that first line of code ever gets written.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.

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

HTML5: Accessibility For All

Accessibility, Unobtrusiveness, and Progressive Enhancement with HTML5

by Brian Hogan

As we move to a world where more and more people access web applications away from their desks, accessibility for all is becoming a bigger issue than ever. HTML5 can help.

One in every ten people in the world has some sort of disability. That statistic is brought to you by the International Labor Organization. That’s around 650 million people. That’s 650 million potential users of your software, 650 million potential consumers of your product, and 650 million people you should think about when developing web sites.

When we do think about accessibility on the Web, we almost always start by thinking about the blind. After all, the web is mostly a visual medium. We’ve learned a few tricks over the years, like using the alt attribute on our images to describe the images to viewers who can’t see them, but for the most part we’ve been crippled in our ability to make our dynamic web applications accessible.

All of that changes with HTML5. There’s a lot of noise surrounding HTML5, but if we look beyond the buzzwords and hype, we’ll find some enhancements that we can use to dramatically improve the accessibility of our web applications. Let’s explore some of these, starting with enhancements to markup.

Descriptive Markup

HTML5 introduces quite a few new elements that we can use to better describe our content. Not to belabor the obvious, but HTML is a markup language: when we write documents in HTML, we’re supposed to be using markup to describe the content better. To describe the most important heading on the page, we’d use the h1 tag. Then we’d put each paragraph of our page in p tags. We’d use the em and strong elements to describe things that we want to emphasize. We’d use the div element for—well, for too many things. But these elements are there to give the content meaning.

With HTML5, we can use the new header, footer, and section elements to divide our page into logical regions. These new elements describe parts of a page much better than the much-abused div element ever did.

In addition, we also have the new nav and article elements, which screen readers can use to more easily find navigation and content elements. Take a look at this code:

| <header>
| <h1>AwesomeCo</h1>
| </header>
| <nav>
| <ul>
| <li><a href="about">About</a></li>
| <li><a href="services">Services</a></li>
| <li><a href="contact">Contact</a></li>
| </ul>
| </nav>
| <section id="posts">
| <article>
| <header>
| <h1>Lorem Ipsum</h1>
| </header>
| <p>...</p>
| </article>
| </section>
| <footer>
| <!-- some footer content -->
| </footer>

It’s very easy to identify the content and the navigation. The more accurately we describe our content, the easier it is for assistive technology to interpret that content. The screen readers JAWS, Window Eyes, and NVDA handle these new elements very well in Internet Explorer 8.

This all works pretty well for static sites, but we can improve things for applications too by taking advantage of two attributes that HTML5 borrows from WIA-ARIA.

WIA-ARIA is a W3C specification that aims to make web applications more friendly to the disabled. Many of the features of this specification are supported by existing screen readers and browsers, and a few pieces have found their way into the HTML5 specification. The two most useful pieces are the role and live attributes.

Landmark Roles

The role attribute identifies the specific purpose of the element. Some of these roles, like role="navigation", duplicate features provided by the new HTML5 structural elements, but others help us guide screen readers even further. We can define roles like:

role="application" which says that we’re working with an application,

role="alertdialog" which identifies an alert dialog box,

role="document" which identifies a static document,

role="menubar" which identifies an application’s menu or toolbar,

and many, many more which you can see by referring to the ARIA specification at the site above.

The role="document" and role="application" roles can be very helpful, as they affect how screen readers interpret keypresses. Inside a document, the screenreader may trap keypresses so that the user can navigate around the document with the keyboard shortcuts in the screen reader. Within an application, the screen reader would send those keypresses on to the application.

Live Regions

One of the most difficult tasks we face when developing dynamic web applications is alerting users to changes we make when we use AJAX or other techniques where we don’t refresh the page. We tend to use visual effects to draw attention to these changes, putting people who can’t see out of luck. The aria-live attribute changes that entirely for the better. Add it to any element you plan to change, and supported assistive technology devices will monitor those regions and alert the user when the content changes.

| <div id="shoppingcart" aria-live="polite">
| <p>Your cart is empty.</p>
| <div>

Notice the polite value? That tells screen readers that they should wait to notify the user so as not to interrupt them if they’re in the middle of something else. There’s also the assertive value, which notifies the user at the first opportunity. The WIA-ARIA roles and live regions help us make our applications and content easier for users to navigate, but we can also improve support for user input.

Improved Forms

When users interact with our web applications, they follow links and fill in forms. For the last 15 years, we’ve only been allowed to use text fields, checkboxes, select lists, and radio buttons. We web developers are an inventive bunch, so we’ve whipped up our own date pickers, sliders, spinboxes, and other widgets. But these widgets aren’t really standardized across the board and can be an absolute nightmare when it comes to accessibility and usability. Just ask anyone who’s ever booked a flight or a hotel room about using date pickers.

HTML5 introduces several new form controls that will improve usability and accessibility of sites. These include:

an Email field, which can potentially be linked with your address book and can support one or many addresses

A URL field which you use to easily enter valid URLs into forms

A Date and Time picker

A special data type for telephone numbers

A Number field that lets users enter numbers only and has arrows to increment or decrement the number

A type for selecting a number in a range, which is usually represented as a slider

These new fields help you describe your form’s input types better, which means that user agents can take advantage of that additional information and present alternative interfaces. Browsers can display the same calendar picker across web sites without relying on JavaScript. Screen readers can implement their own methods for making date entry easier.

The iPhone and iPad display alternative virtual keyboards when they encounter email, URL, and number fields. When you select an email field, the virtual keyboard places the @ and .com buttons in a very visible spot so you don’t have to go into submenus to find them. That alone is a good reason to use these new fields. Accessibility isn’t just about “users with disabilities.” By adding these fields, you improve accessibility for your mobile audience too.

Validation

HTML5 forms also let us specify validation rules that user agents can use to provide quick feedback to end users. We typically validate user input on the server side, which is very important because we can’t always trust that client-side validation works. But we know from experience that letting users know what fields are required is very important. We can add the required attribute to our form fields, which user agents can see.

| <label for="project_name">Project name</label><br>
| <input id="project_name" name="project[name]"
| type="text" required>

The specification also introduces a pattern attribute that takes a regular expression, which we can use to provide client-side feedback to users so they can correct their mistakes right away instead of waiting for a trip back to the server. We’ll keep our server-side validation as a fallback, of course, and we’ll make sure to keep any client-side validation in sync with our server-side validation so we don’t confuse our users.

Unobtrusive JavaScript

Once you lay the groundwork for your site with working, valid, and semantic markup using HTML5, you can improve accessibility further with JavaScript.

When I build web applications, I make sure my sites work 100% without JavaScript, which I know that people using assistive technology often disable. When sites use JavaScript to display modal dialogs, it can confuse these users, so they often turn off JavaScript completely. Once I have a working site, I can use HTML5’s custom data attributes and some JavaScript to make my site work differently.

We start with a simple form that submits to our web application:

| <form method="post" action="/projects" data-remote="true">
| <label for="project_name">Project name</label><br>
| <input id="project_name" name="project[name]"
| type="text" required>
| <input type="submit">
| </form>

This form is full of HTML goodness, but take special notice of the data-remote attribute on the form tag. Custom data attributes let us put any attribute we want on an element. Validators ignore these completely. All we have to do is prefix the attribute with data-. We can then use some JavaScript to snag that value and turn any of our regular forms into ones that post asynchronously. Our web framework can then determine if the request was done as a regular POST or via XMLHttpRequest and deliver the appropriate response.

| $(function(){
| $("form[data-remote=true]").submit(function(e){
| e.preventDefault(); // prevent normal submit
| $.ajax({
| type: "POST",
| url: ($(this).attr("action") + ".js"),
| dataType: 'json',
| data: $(this).serialize(),
| success: function(data){
| $('#results').html(data["render"]);
| }
| });
| });
| });

We watch for the form submit event for any form that has the data-remote attribute set to true. We prevent the form’s default behavior and build up an AJAX request to submit the form instead. We grab the form’s action from the existing form markup and append .js so that this form submits to the url http://example.com/projects.js. Our server-side framework can use this to determine how to respond to the form. If you use Ruby on Rails, you can leverage the routing features to easily respond to this event.

We then take the response, which we expect to be JSON, and modify the page’s contents appropriately. Because we built the form up with semantic HTML5 markup, we can use this handler on any form on our web application. It’s then very easy for us to support rich interfaces while still providing useful fallbacks.

Where to go next

We’ve only scratched the surface of accessibility, but I hope you see how useful HTML5 will be as a tool for improving the accessibility of your sites, for users of assistive technologies and also for mobile users. As we move to a world where more and more people access web applications away from their desks, accessibility for all will become a bigger issue than ever before.

My book HTML5 and CSS3 contains many more examples of how HTML5 can improve the user experience. In addition, I’ll be writing more about accessibility on my blog in the coming months.

Brian Hogan has been developing web sites professionally since 1995 as a freelancer and consultant. He’s also built small and large web sites and web applications using ASP, PHP, and Ruby on Rails. He enjoys teaching and writing about technology, particularly web design and development. He is the author of Web Design for Developers and HTML5 and CSS3. He recently came over to the dark side and has become a development editor for The Pragmatic Programmers.

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

What Agile Is Not

Dealing with Cowboys, Dogmatists, and Authoritarians

by Jeff Langr, Tim Ottinger

No two Agile implementations are alike, and no two Agile teams are identical. Jeff and Tim share their experiences in dealing with widely different types of teams.

In determining the core set of cards for our Agile in a Flash deck, we tried to cover all Agile bases, including prescriptive step-by-step lists. This month’s article is about going beyond the cards.

Step-by-step descriptions of Agile practices are useful. The steps we provided are proven and there is no shame in following them precisely. Many highly Agile, highly successful projects strictly follow the exact steps we outline. The only problem is that focusing on practices risks a mechanical and unenlightened interpretation.

Like snowflakes, no two Agile implementations are alike. Scrum and XP differ dramatically in focus, implementation, and feel. Add in some of the Lean and ToC (Theory of Constraints) concepts, perhaps some Domain-Driven Design, and it gets pretty complicated trying to describe the kind of procedure that might be considered Agile.

We’ve visited and worked in dozens of allegedly Agile shops, ranging from rigid and sterile team rooms to wild west cowboy-coding ranges.

Cowboys

In the wild west shops, we promoted team collaboration over rogue hero mentalities. We promoted a team standard and collective code ownership. We taught pairing and test-driven development. When these values were embraced, the teams grew together. Not everyone was willing to switch from rugged code-slinger to pastoral code farmer, but those who stayed learned to improve their quality and deliver more useful code. Some say it was a turning point in their careers or the lives of their products.

In the sterile process-driven shops, we introduced retrospectives and incremental improvement to counter rigidity and stagnation. We promoted the Agile manifesto’s values and principles, especially the value of empowered teams, over the concept of Agile as a strict process composed of phases and steps.

Did we make a difference? Both of us can relate numerous success and failure stories from our attempts to help teams transition. Even where the overall engagement appeared to fail, we could always find small successes, sometimes as simple as “turning one individual from the dark side.” And in even our finest successes, we faced moments of challenge and loss.

Here’s one story:

At a small dot-com, one of us coached an XP team of six developers. Their velocity was consistent and fairly predictable after several iterations, but not quite enough to push through the workload expected by the customer. To help, the company brought on two young, gung ho developers, one of whom quickly expressed considerable disappointment at his team’s throughput. He felt the team wasn’t working hard enough, wasn’t putting in enough hours.

The team came in one Wednesday morning to discover that this whippersnapper was still wearing his same clothes from the day before. Uh oh. “I stayed all night to help bring up our velocity.” The cowboy honestly thought everyone would look at him as the hero. Thankfully the team knew enough to confront him. In how many ways was this a boneheaded move on the cowboy’s part?

The rest of the team felt the cowboy had tried to make them look bad.

The team was also upset because he had broken teamwork rules in acting unilaterally.

The “velocity increase” would only have been sustainable if at least one member of the team were always willing to work overnight for the indefinite future.

The cowboy’s solo, wee-hours-of-the-morning coding skills left the rest of the team struggling with poor code and its impact for the next day and a half. The “velocity boost” was a considerable net loss.

The positive element was that the team spoke up when they had to, and re-asserted their expectations for team behavior. They would not tolerate similar cowboy actions in the future.

We focus on building a team first. More important than specific Agile practices, we seek ways of getting individuals to learn how to collaborate even more.

In another shop, one developer balked at the thought of a shared team coding standard. “I think coding standards stifle individual creativity,” he said. Our Agile coach answered, “Yes. That is what they’re for.” That glib answer opened up a conversation about degrees of freedom and degrees of conformance, teamwork, production, and shared responsibility. The team ended up with a standard they liked well enough, found that it allowed them to work in unfamiliar code more easily, and over time they ended up working together quite well.

Agile is not the cowboy attitude of “do whatever you want because it feels right.”

Dogmatists

On the flip side, we’ve encountered shops where “Agile” is a checklist. The following paragraph, representing a potential set of Agile team rules, is a pastiche of actual strictures we’ve seen in Agile teams.

Thou shalt run stand-up meetings for precisely 15 minutes, during which every participant will speak only their three sentences, and during which uncommitted parties may not speak. Iteration planning meetings are every other Monday for 180 minutes, and retrospectives are every other Friday for 120 minutes. A story must be in the form “As a user, I want to be able to do something, so that I may accomplish some business goal.” Every story card must be formatted with the point total on the upper left corner, and the initials of the person working it on the lower right. Only the project manager may touch cards in these columns on the peg board. All teams must submit a burn-down chart to upper management daily. Pairing is mandated between the hours of 9 am and 4 pm.

There is nothing wrong with these rules, and they might be helpful in many circumstances. On the other hand, one might follow each and every such rule and yet never begin to realize the benefits of Agile development. Done strictly, these processes are merely ceremonies bolted onto a command-and-control structure. [Insert standard warning about teaching pigs to sing here.]

We have both followed all of these strictures and structures and found them good. They are all based on relevant concerns. Yet we’ve also broken almost every such Agile “rule.” Agile development is demanding, insisting on continual delivery in the face of significant challenges, and no rule can withstand every contingency.

A forewarning, however: Each practice is based in one or more Agile values and principles. By discarding a practice, you may be opposing your own success. They are not to be discarded lightly or without measuring the result.

Agile is not a set of rules.

Authoritarians

Perhaps surprisingly, the worst shops we encountered were neither free ranges nor houses of unyielding Agile dogma. The worst we saw were those who wanted to maintain old-style waterfall practices with command-and-control mentality. Often in these cases, authoritarian sorts viewed Agile practices as a way of getting lowly programmers (“coders”) to finish their work faster.

Many of the individuals in these shops lived in fear, both before and after the arrival of Agile. The sad result was that they ended up seeing Agile as just another means for their bosses to cow them into submission.

For an Agile team to succeed, the involved parties—management, sponsors, customers, and the development team—must work as a team toward a common goal. The stated Agile goal is to frequently and continually deliver high-quality software to meet the demands of the marketplace. If management introduces Agile but the development team resists it, Agile will not take root. If the development team adopts Agile as a grassroots effort, but the customer or other parts of the organization undermine the process, Agile will not take root.

Agile is not a command and control structure.

Start with the Values

The advice from Kent Beck and Ron Jeffries for successful adoption of Agile Software Development has always been to start with the values. So we did. Our first section in the Agile In A Flash deck is called The Idea and introduces values and concepts first. The second section deals with The Plan, which helps focus and direct business decisions. The Team section teaches more about living out the values in a community of software developers. Finally, The Code gives specifics on building products in a dynamic environment, covering testing, coding, and quality.

The Agile In A Flash cards are fronted by lists to help you quickly understand Agile ideas, concepts, and practices. We ask that readers view each process card as a starting point. Lessons learned from practicing as-given will trigger other ideas on how to help your team succeed. Remember that you can substitute and evolve practices, provided you remain true to the values.

Next: We’ll talk more about how to grow your Agile team using shu ha ri as a maturity guideline.

Jeff Langr has been building software for over a quarter century. He is the author of Agile Java and Essential Java Style, plus more than 80 articles on software development and a couple chapters in Uncle Bob’s Clean Code. He runs Langr Software Solutions from Colorado Springs and happily builds software as an employee of GeoLearning.

In addition to developing the Agile in a Flash card deck with Jeff, Tim Ottinger has over 30 years of software development experience including time as an Agile coach, OO trainer, contractor, in-house developer, and even a little team leadership and management. 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.

Good Code Tells the Truth

Reflections on Code Quality

by Hew Wolff

My favorite characterization of good writing is from Rust Hills, former fiction editor of Esquire magazine: “clarity of perception and expression.” Hew Wolff is talking about something similar here when he characterizes good code as truthful.

What is good code, anyway? I recently came up with a new take on this.

I took over some code from a former colleague. It was a Java Web application, written with minimal supervision, and it had a distinct and meticulous style. Tricky places, such as a workaround for a library bug, were carefully documented. Whitespace followed strict conventions. He used a standard set of abbreviations in naming database tables—but these names were long and hard to read. There was a homegrown database persistence layer, which was impressive, but it was also probably unnecessary and certainly confusing. Many methods looked suspiciously similar to each other. In short, it was both strong and flawed.

The code was so good in some ways, and so bad in others, that I started debating with my colleague in my mind over the problems in his approach. And I wondered, were these merely pet peeves of mine, or something more universal?

I’ve read many descriptions of good code, which I will boil down to these:

It’s powerful, elegant, and compact.

It’s readable: it’s a pleasure to walk through it, its main names map closely to the problem domain, and it doesn’t have a distracting burden of terminology or comments.

It’s testable: it’s divided up nicely into modules with unit tests, and the production code and tests are responsive, so you can see it working.

Obviously there’s some overlap between these criteria. For example, pretty much everyone hates flagrantly repetitive copy-and-paste code... or worse, big chunks of code that are almost the same but subtly different. Such code violates all three of these criteria. Repetition reduces power by adding bloat. It hurts readability by doubling the burden on the reader. And it undermines testing, although indirectly, when the maintainer fixes a bug in one location but misses the other one.

Truth

But why, on a deeper level, is repetitive code bad? Here’s an idea I haven’t heard expressed: it’s bad because it’s dishonest. It violates a principle of good communication, that whatever you say should be salient. Adding more text that doesn’t add more content is misleading the reader. I think it’s precisely this misleading quality that prevents such code from being powerful, readable, and testable. Good code tells the truth.

I found this idea illuminating. It’s a different angle on the familiar Don’t Repeat Yourself principle. Here are some more examples of this idea of truth in coding.

We tend to agree that a function should be short. Maybe one or two pages long, but you don’t want to keep paging up and down to read it. Why is that? Here’s one possible answer: Imagine you’re listening to a speech, an interesting speech, but it’s going on too long. You start to feel that the speaker is not respecting your time. More than that, you feel that if they knew their point, they would get to it. As they wander farther from a resolution, it seems they must be hiding something. So it is with a long function: it only pretends to know what it’s doing. It should tell you what it’s going to do, and then show you that it’s doing it. It should do one thing and do it well. That means brevity. As Seneca said, “Truth hates delay.”

And there’s a larger point here: all the pieces of a program should be small enough to grasp whole. Not only functions but parameter lists, classes, files, directories, and even names. Kent Beck and Martin Fowler, in their discussion of refactoring and “code smells,” describe a large class as “prime breeding ground for duplicated code, chaos, and death.” Fortunately the basic remedy is simple: look for natural fault lines in the big pieces, and break them up. In a classic refactoring example, there’s a chunk of code with the comment “Configure connection,” which is crying out to be a separate function called ConfigureConnection.

For another example of truth in coding, consider namespace pollution. An unnecessary global variable is not just an invitation to bugs; if it’s overexposed, it’s lying. Its scope should be reduced to match its importance.

A more down-to-earth example is the length of variable names. Most of us like to see variables like i, root_node, user_name, and dirty_invoices. But you’ve probably seen code where these variables would be i0, rn, u1, and invdty. You may also have seen code where they would be integer_request_index, the_root_xml_node, string_name_of_user, and array_of_all_dirty_invoices_in_system, which is painful in a different way. Part of telling the truth is gauging how much information to provide; too much or too little description will distract us from what the code is actually doing. We want the whole truth and nothing but the truth.

Finally, we should not forget the problem domain. Maybe you’ve been on a project where the client is always talking about “playlists,” but the programmers call them “playlists,” “song lists,” “sets,” and occasionally “CD tracks.” In this situation we are literally not sure what we’re talking about. To be accurate, we need consistent terminology. If it’s a playlist, call it a playlist. Don’t call it a set. Tell the truth.

I could multiply examples here, but I’d rather let you try out the principle. Think of something that gets on your nerves, and see how the “truthful code” idea fits. Big switch statements? Deep nesting? Magic constants? Premature optimization? Frivolous comments? And think, on the other hand, of things you like to see. The MVC pattern? The const keyword in C++? Table-driven solutions? Unit tests? Class diagrams?

Talking

To be clear, I’m not talking here about processes for writing good code, although the discussion above leads naturally into refactoring. I’m not talking about how much time to spend on code quality. I’m not talking about a good user experience, either. My focus is the everyday experience of looking at your code and saying, “It runs, but is it good enough?”

We’re not telling the truth to the machine. The machine doesn’t care what we say, and if we get it wrong, the machine will let us know soon enough. No, we’re talking to programmers: our colleagues and our future selves. Just in case you were tempted to forget: coding style is about talking to people. There’s an obvious analogy with the style of expository writing. For example, just think of Strunk and White’s admonition to “omit needless words.”

A sticky point here is that code quality is subjective. You can optimize for short code, or fast execution, or buzzword compatibility; your elegant solution might strike me as an awkward hack. The safest thing is to stick to a style that everyone on the team can live with. Try to see this not as a corruption of your true vision, but as a correction of your excesses.

Another way to look at this is that our colleagues keep our code honest. When we work in isolation it’s easy to fool ourselves into thinking that our weird idea is great. It’s harder to fool the person next to you. Pair programming tends to produce, not ugly compromises, but code that everyone likes. A democracy of professionals helps get our code closer to the truth.

Attitude

I mentioned that style in code is like style in prose, but a better analogy is with the style of mathematical proofs, which we can think of as programs running in the collective mind of the mathematical community. There are many valid proofs for the same result, and which one to use is a matter of taste. Many of the choices are familiar to programmers: how to name variables, when to pull out a chunk of logic into its own subtheorem, whether to go for a narrow focus on the current requirements or for “gruesome generality.” Paul Erdös spoke of the “book proof,” the proof you would see if you could peek into the notebook of the Supreme Being.

I think that’s a good attitude for programmers as well. What drives better code is not a laundry list of dos and don’ts but a conviction that somewhere within your grasp is a beautiful solution. There might even be several of them, all so bold and dazzling that you will only achieve a pale imitation. But you keep trying. Telling the truth is an attitude.

Telling the truth may sound boring. But you still get to be clever and creative. It’s just that you do it with discipline, and stay faithful to the requirements. You remember that cleverness to no purpose, or cleverness that no one else can understand, is empty. You are never simply translating the customer’s requests into code. The customer will not ask you to create multiple threads or to use the Factory pattern; that part is your job. If it’s good, it will be (as someone said about good writing) simple but not obvious. It will have personality, but no ego. It will be true.

Personally, I would not propose myself as a superb stylist. I’ve been lazy about cleaning up my code sometimes. And sometimes I’ve spent way too much time polishing. But on a good day, I feel I’m getting close to a true design. And on a bad day, that goal helps keep me going.

Hew Wolff has worked in software since the Reagan administration. Important distractions include math, garlic, and the work of Joss Whedon. He lives with his wife in Oakland, California. See also his very interesting home page.

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

When Did That Happen?

The Rise and Fall of the Telegraph

by Dan Wohlbruck

Dan’s series on the history of technology continues with this look back over the history of the telegraph.

On October 24, 1861, the first transcontinental telegraph line was completed in Salt Lake City, Utah, when the Western Union Company connected the eastern portion of the line with that from the west. After a few messages to test the connection, the first official telegram from Utah to California was sent by Brigham Young, himself. The first coast-to-coast message was sent from the Chief Justice of California (filling in for the Governor) to Abraham Lincoln, and it contained within it a pledge of California’s loyalty to the Union. No doubt a piece of welcome news at the end of a tough year for the President. Electronic messaging began during the 19th century and Western Union and the telegraph were the kings of communication.

The invention that created the electric message was the electromagnet. In 1825, William Sturgeon demonstrated the first electromagnet by lifting nine pounds with a seven-ounce piece of iron. The iron was wrapped with wires through which the electric current of a battery was sent. The potential of the electromagnet for communication was quickly realized by Joseph Henry who, in 1831, sent an electric pulse through a one-mile wire and caused a bell to sound at the remote location.

It was left to Samuel Morse, however, to realize the dream of the telegraph. Morse developed his code and gave practical demonstrations of the telegraph during the late 1830s, and in 1843 the US Congress appropriated $30,000 to build the first long-distance telegraph line from Baltimore to Washington.

It was completed in May, 1844, just in time for the first news to be broadcast electronically.

The Telegraph and Politics

The Whig party, whose convention was in Baltimore, had nominated Henry Clay as its candidate for President and that news was sent to Washington. Morse and his telegraph had greater success than did Clay.

The famous message, “What hath God wrought?” was sent from Washington to Baltimore on May 24, 1844. It was encoded with (what else?) the dots and dashes of Morse code, and marked the official completion of the Baltimore-Washington line.

Although Morse used private funding to extend the line to Philadelphia and Boston, a number of small companies were formed to serve the rural population. In 1855, two smaller organizations merged to form the Western Union Telegraph Company. Western Union went on to absorb other telegraph companies and to dominate the communications industry in the United States. Western Union was one of the original eleven companies in the Dow Jones Transportation Average of 1884.

The completion of the transcontinental telegraph link enabled the railroads to drive the golden spike at the conclusion of coast-to-coast railroad tracks. The telegraph permitted President Lincoln to keep up with his generals, prodding some and firing others, as the Civil War wound on.

The telegraph informed a disbelieving nation of Lincoln’s assassination and Johnson’s impeachment.

The telegraph and the railroad tamed the Western frontier and brought the country together.

Western Union

Throughout all of this, Western Union prospered. From 1844 until the invention of the telephone in 1877, all electronic messages were sent by telegraph, and most of them by Western Union. The company introduced the stock ticker so that Main Street could keep up with Wall Street, it introduced money transfers and singing telegrams, and it pioneered the use of the teletype.

On June 10, 1871, New York City turned out to honor Samuel Morse with his own statue. At a great celebration held that evening, Morse sent his last telegraph message. From a single telegraph machine sitting on a table in New York, Morse’s keystrokes were sent around the world. In response came congratulatory telegrams from London, Sydney, Hong Kong, New Orleans, and San Francisco. Morse died less than a year later, in 1872.

Western Union tried to remain relevant during the computer revolution of the 20th century. It introduced short-wave networks and it owned the Westar communication satellites, but its profits continued to diminish. By the late 1980s, Western Union had fallen into bankruptcy. On January 27, 2006, Western Union announced that it had sent its last telegram.

It had begun over 180 years ago with electromagnetism and dots and dashes—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.

The Quiz

What’s the Missing Number?

by Michael Swaine

I have a really easy one for you this month. All you have to do is to identify the missing number in this sequence:

19

27

37

?

47

113

114

1138

The answer can be found in many places. It was even, coincidentally, provided in an earlier issue of this magazine. But you should work it out on your own. And to fully solve the quiz, you should also explain what these numbers have in common and what particular significance each number has. I await your solution.

Solution to Last Issue’s Quiz

Alas, I made a few errors in the statement of last month’s quiz, rendering it unsolvable. What a bonehead. Thanks to the ingenuity of certain readers who figured out the problem, corrected the statement of the quiz, and solved it, the mess I created got sorted out on the Forum very quickly. I refer you there for the solution.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

Oct 5–6, Agile Business Conference, London, UK

“Building a Culture of Trust”

Rachel Davies, author of Agile Coaching

Oct 7, Milwaukee Jobcamp 4, Milwaukee, WI

“Effective Interviewing from the Hiring Manager’s Point of View”

Andy Lester, author of Land the Tech Job You Love

Oct 9–10, Twin Cities Code Camp, Minneapolis, MN

“Web Development with Ruby—From Simple To Complex” and c“Building Offline Mobile Apps with HTML5 and Web Standards”

Brian Hogan, author of Web Design for Developers and HTML5 and CSS3

Oct 13–15, Strange Loop, St. Louis, MO

“Outside-In TDD in Clojure”

Brian Marick, author of Programming Cocoa with Ruby and Everyday Scripting with Ruby

Oct 14, Babson, CIMS, Babson Park, MA

“Project Portfolio Management”

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

Oct 14–15, Strange Loop, St. Louis, MO

“Mary Poppins meets the Matrix”

Bruce Tate, author of Seven Languages in Seven Weeks

Oct 14–15, Agile Cambridge conference, UK

Keynote on “Building trust in Agile teams” and workshop on “Creating Agile Environments”

Rachel Davies, co-author of Agile Coaching

Oct 15–16, Software Craftsmanship North America, Chicago, IL

“McDonalds, Six Sigma, and Offshore Outsourcing—Unexpected Sources of Insight”

Chad Fowler, author of The Passionate Programmer

Oct 15–16, No Fluff Just Stuff Twin Cities Software Symposium, Minneapolis, MN

Several talks

Johanna Rothman, the 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

Oct 16–17, Voices That Matter: iPhone Developers Conference, Philadelphia, PA

“Mastering Media with AV Foundation”

Chris Adamson, co-author of iPhone SDK Development

Oct 18, Pacific Northwest Software Quality Conference (PNSQC), Portland, OR

“Document Your Software Project”

Ian Dees, co-author of Using JRuby and author of Scripted GUI Testing With Ruby

Oct 19, Boston SPIN

Speaking

Johanna Rothman, the 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

Oct 19–22, SpringOne 2GX, Chicago, IL

“Grails: Bringing Radical Productivity to the JVM” and “Grails Integration Strategies”

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

Oct 20, MongoDB Conference, Chicago, IL

“PyMongo and Python Development”

Brendan McAdams, author of the forthcoming MongoDB: A Quick Start Guide

Oct 23, Linux Day Ferrara, Ferrara, Italy

“A Metaprogramming Spell Book”

Paolo Perrotta, author of Metaprogramming Ruby

Oct 25–27, Pragmatic Studios, Chicago, IL

Pragmatic Rails Studio with Dave Thomas

Chad Fowler, author of The Passionate Programmer

Oct 25–28, Pragmatic Studios, Chicago, IL

“iPhone Studio”

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

Oct 27, RubyConf Brasil, São Paulo, Brasil

“Maintaining Balance while Reducing Duplication”

David Chelimsky, author of The RSpec Book

Oct 29–30, RubyConf Uruguay, Montevideo, Uruguay

“Maintaining Balance while Reducing Duplication”

David Chelimsky, author of The RSpec Book

Nov 1–4, Much Ado About Agile, Vancouver, BC

“Creating an Adaptable Life” and “Making Geographically Distributed Projects Work”

Johanna Rothman, the 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

Nov 1, ZendCon, Santa Clara, CA

“Cloudy with a chance of PHP” along with Josh Holmes and Eli White

Travis Swicegood, author of Pragmatic Version Control Using Git

Nov 1–4, ZendCon, Santa Clara, CA

“SQL Injection Myths and Fallacies” and “Requirements: The Last Bottleneck”

Bill Karwin, author of SQL Antipatterns

Nov 1–4, Agile Vancouver, Vancouver, BC

“Card, CONVERSATION, Confirmation: Improving Customer Conversations” and “From Big Boss to Steward Leader: Becoming an Agile Manager”

Esther Derby, author of Behind Closed Doors and Agile Retrospectives

Nov 3, Agile Project Leadership Network, Calgary, Ontario, CA

“How You Lead”

Jonathan Rasmusson, author of The Agile Samurai

Nov 3, ZendCon, Santa Clara, CA

“Pragmatic Guide to Git”

Travis Swicegood, author of Pragmatic Version Control Using Git

Nov 5–7, Northern Virginia Software Symposium, Reston, VA

Several talks on Groovy and Grails

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

Nov 7–11, AYE Conference: Exploring Human Systems in Action, Phoenix, AZ

Many sessions

Esther Derby, author of Behind Closed Doors and Agile Retrospectives

Nov 7–11, AYE Conference, Phoenix, Arizona

Several talks

Johanna Rothman, the 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

Nov 10, Øredev, Malmö, Sweden

“Building Trust”

Rachel Davies, co-author of Agile Coaching

Nov 11, RubyConf, New Orleans, LA

“Maintaining Balance while Reducing Duplication”

David Chelimsky, author of The RSpec Book

Nov 11–13, RubyConf, New Orleans, LA

(organizer)

Chad Fowler, author of The Passionate Programmer

Nov 11–13, RubyConf, New Orleans, LA

(keynote)

Dave Thomas, co-author of The Pragmatic Programmer

Nov 12, University of Wisconsin Milwaukee Learning Technology Center, Milwaukee, WI

“Seven Languages in Seven Hours” full day workshop

Bruce Tate, author of Seven Languages in Seven Weeks

Nov 12–14, Great Lakes Software Symposium, Chicago, IL

Various topics

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

Nov 12–14, Great Lakes Software Symposium, Chicago, IL

“Improving Customer Conversations” and several other talks

Esther Derby, author of Behind Closed Doors and Agile Retrospectives

Nov 12–14, Great Lakes Software Symposium, Chicago, IL

Several talks on Grails

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

Nov 15–17, Scrum Gathering, Amsterdam, NL

“A Deep-Dive into Agile Coaching”

Rachel Davies, co-author of Agile Coaching

Nov 14–19, Agile Development Practices East, Orlando, FL

Three Agile talks

Johanna Rothman, the 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

Nov 15–18, Agile Development Practices East, Orlando, FL

“The Value of Value Story Cards”

Jared Richardson, author of Ship It!: A Practical Guide to Successful Software Projects

Nov 19, Italian Agile Day, Genova, Italy

“The BDD Live Show” and “Workshop: Ruby for Java programmers”

Paolo Perrotta, author of Metaprogramming Ruby

Nov 25–27, XP Days Germany, Hamburg, Germany

Keynote on “Resolving Resistance to Change” and “Agile Coaching Skills” workshop

Rachel Davies, co-author of Agile Coaching

Nov 30–Dec 3, The Rich Web Experience, Ft. Lauderdale, FL

“Grails: Bringing Radical Productivity to the JVM”

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

Dec 1–3, Summit 2010 Europe, London, UK

Workshop Seminar: “Agile in the Workplace”

Rachel Davies, co-author of Agile Coaching

Dec 2–3, Agile, Lean & Kanban EXchange, London, UK

Speaking

Rachel Davies, co-author of Agile Coaching

Dec 7–10, Pragmatic Studios, Denver, CO

iPhone/iPad Programming Studio

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

Dec 8–10, Pragmatic Studios, Denver, CO

Pragmatic Rails Studio with Dave Thomas

Chad Fowler, author of The Passionate Programmer

Dec 9, IIBA, Boston Chapter, Waltham, MA

“The Role of the BA in an Agile Project”

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

USENIX Events

Oct 27, Atlanta, GA

CC ’10: USENIX Education on the Road: Georgia: a new program that will bring USENIX-quality tutorials for free to a city near you.

Nov 7–12, San Jose, CA

Lisa ’10: 24th Large Installation System Administration Conference. The 2010 training program includes over 45 classes and they’re again offering series of classes focusing on some of the most important topics you’ll encounter.

Nov 29–Dec 3, Bangalore, India

Middleware 2010: ACM/IFIP/USENIX 11th International Middleware Conference. The Middleware conference is a forum for the discussion of important innovations and recent advances in the design, construction, and uses of middleware.

Other Happenings

Oct 2

The Great Quux is 56.

Oct 4

The Free Software Foundation is 35.

Oct 4

Birthday of John Vincent Atanasoff, one of the inventors of the computer.

Oct 5

Linux is 19.

Oct 6

Adobe co-founder John Warnock is 70.

Oct 12

Birthday of Ole-Johan Dahl, co-creator of the Simula language and thus of object-oriented programming.

Oct 15

David Heinemeier Hansson is now over 30, hence not to be trusted.

Oct 16

Mike Muuss, who invented Ping, was born on this date in 1958.

Oct 17

October Manifesto issued by Tsar Nicholas II in an unsuccessful attempt to undermine the Russian Revolution. (October 30 according to the Gregorian Calendar.)

Oct 19

Steve Peter’s birthday. I had to mention that, because he proofread the issue. If you find any errors, they’re his fault.

Oct 25

Peter Naur, the N in BNF, is 82.

Oct 28

Former software executive Bill Gates is 55.

Oct 29

On this date in 1969, ARPAnet first linked Doug Engelbart’s lab at SRI with Leonard Kleinrock’s at UCLA.

Oct 31

The traditional date for the leaking of confidential internal Microsoft documents outlining strategies for undermining open source software.

Nov 1

This month the OLPC is 5 years old.

Nov 1

Mitch Kapor is 60.

Nov 8

Bill Joy is 56.

Nov 6

Jerry Yang is 42.

Nov 22

Randall Schwartz, aka merlyn, is 49. He may be hoarding helium.

Nov 22

PHP creator Rasmus Lerdorf is 42.

Nov 22

Charles Simonyi’s wedding anniversary.

Nov 27

Andrew Flugelman, inventor of shareware, would have been 67 today.

Dec 3

John Backus would have been 86.

Dec 4

Eric Raymond, aka ESR, is 53.

Dec 9

Grace Hopper’s 104th birthday.

Dec 10

Ada Lovelace’s 195th birthday.

Dec 10

Ada, the programming language, is 30 today.

Dec 16

John Bardeen and Walter Brattain created the first transistor on this day in 1947.

Dec 17

Ken Iverson, creator of APL, would have been 90 today.

Dec 17

Les Earnest, inventor of first spell checker and of the finger protocol, is 80.

Dec 23

Birthday of Bob Miner, who wrote Oracle’s original database software.

Dec 25

Richard Greenblat, famed MIT hacker, is 66.

Dec 26

Charles Babbage’s 219th birthday.

Dec 28

Linus Torvalds is 41.

Dec 30

Bjarne Stroustrup is 60.

Dec 31

Leonard Adleman, the A in RSA encryption, is 65.

Shady Illuminations

October Country

by John Shade

“But then voting season comes and reminds you that all those Americans that are individually sane and normal tend to be collectively crazy.”

October is a special month for Americans. It’s that magical time when we put on a mask in order to take off the mask and embrace our dark side, letting our demons run free for one night of unrepentant intimidation and pillaging. At least that’s what it is to the kids on my block. To whoever edits the events calendar for this magazine, it’s the traditional time for the leaking of confidential internal Microsoft documents outlining strategies for undermining open source software. And that’s still special. To Linus Torvalds, it is

“[t]hat most holiest of holidays, when the whole country comes together, and without regards to race, religion or age, people join a common cause. Namely the gluttonous eating of candy.”

These days Linus is embracing Halloween as he is embracing all things American. You see, he recently became a U. S. citizen. But don’t hold that against him. It probably wasn’t something he wanted to do. I think he was just legitimizing his anchor babies. And being embraced by Linus Torvalds is a mixed blessing anyway. Halfway through his paean to Halloween he starts railing against the quality of American candy, and its “almost total lack of ammonium chloride.”

Where’s he from again?

Finland, right. He blogs about Finnish culture and the sauna championships on his family blog. Apparently the Finns are big on ammonium chloride in candy. And competitive saunaing.

Getting that Stabby Feeling

When I learned that Linus had become an American, I immediately got hold of his family blog and read, with some trepidation, every post, extending back several years. I was pleased to have all my prejudices confirmed. Linus is, as I suspected, a congenital curmudgeon. Which for me goes a long way toward offsetting the whole Benevolent Dictator of Linux thing. Both the dictator and the benevolent. I’m not crazy about dictators. Or benevolence. Some evidence of the Torvalds curmudgeonry:

“[E]very once in a while I get that ‘stabby feeling,’ and yesterday I realized why. It’s ‘Brandi (You’re a fine girl).’ I’m sure that song explains at least half the road-rage incidents out there. A less stable person would quite reasonably decide that rather than change the channel, they just need to stab somebody in the face.”

“I have never found a sport that I find in the least interesting.”

“Some people seem to think that C is a real programming language, but they are sadly mistaken.”

You’re not in Finland Any More

Right after Halloween we Americans go to the polls to perform political triage, deciding which office-seekers get anointed and which get smeared. This promises to be a particularly entertaining episode of our national hope opera, and Linus will be helping us sort the cheat from the whaff. He appears to have mixed feelings about the process:

“But then voting season comes and reminds you that all those Americans that are individually sane and normal tend to be collectively crazy and very odd. And that's when you really notice that you're not in Finland any more.”

Maybe it was the Americans dining in the food court at Costco whom he overheard discussing strategies for driving out demons. But I’m afraid he really does think our whole political system is screwy. Ah well, it’s only to be expected that he’d retain a little prejudice in favor of his native land. He also blogs that Finnish video is big among YouTubers. Sure. But hey, if it makes him happy to think so, where’s the harm?

A True Work of Genius

After a while I started getting a little creeped out reading his blog. I hate agreeing with people. It makes me feel redundant. And then he called a Microsoft product “a true work of genius.”

No, not Windows 7.

It turns out Linus is a big fan of Songsmith, the Microsoft Research project that generates musical accompaniment to match your voice. “The thing that convinced me,” he says, “was hearing Billy Idol’s ‘White Wedding’ as re-interpreted through Songsmith. Nobody will ever convince me that that isn’t just impossibly brilliant.”

First of all, I’ve heard my voice, and matching that is the last thing I want from musical accompaniment. Second, Linus admits that the commercials for Songsmith are painfully cheesy, but he thinks we should ignore that. I’m sorry, but Microsoft went to a lot of trouble creating those commercials and I consider it my responsibility to judge the product by the ad. You’re just wrong, Linus.

There, now I feel better.

John Shade was born in Montreux, Switzerland on a cloudy day in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He hates long walks on the beach and his ambition is to become an acquired taste.

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

Your Halloween Costume

Release Your Inner “Geak”

by Jeremy Bingham

Just in time for Halloween, Jeremy discovers this “Geak” costume. And the price is hard to beat, at least if you buy it at Goodwill.

Have you ever wanted to dress up like a geek for All Saint’s Day, but were concerned that you might not look revolting enough, or that you weren’t getting your daily allotment of unusual substances? Look no further. Courtesy of the Chinese and Goodwill, I present: GEAK Instant.

Do not be forgetting to read the important instructions for maximal usefulosity. I heartily recommend this costume for football games and All Saint’s Day, but your results may vary. Excellent for giving the vital force.

A note from the editor: Whatever humor there is in the above is directed at marketing managers of any nationality who ignore the importance of localization in products intended for foreign markets, not at the Chinese people, who are admirable, numerous, and might want to consider hiring me to help them with localization issues. I’ve lived in the US my whole life, and I work cheap.

The full kit on display at Goodwill. Note the price sticker.

This article was first published in a slightly different form on October 21, 2009 on time.to.pullthepl.ug.

Jeremy Bingham’s “day job” is to be the tech guy at Daily Kos, and he started Time.to.pullthepl.ug (Hey, you can register Ugandan domains!) to post about some of the weird stuff he’s come across working behind the scenes over there. Jeremy is also a co-founder of the SB Nation network of sports blogs, overseeing the technical aspects of that venture. He is an avid amateur historian and enjoys old science fiction books. Jeremy has real tech cred, as evidenced by his very pragmatic A Way to Scale Your Blog advice, published three days before that site posted its twenty millionth comment.

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