PragPub 2009-11: Issue #5

Table of Contents

Features

- The Agile Coach
interviewed by Michael Swaine
Agile coaches Rachel Davies and Liz Sedley share advice on coaching your Agile team.

- The Pompatus of Pomodoro
by Staffan Nöteberg
Make time an enabler rather than the enemy who always wins.

- Bonjour, iPhone
by Bill Dudney
Bill walks you through building a rudimentary multiplayer game for the iPhone.

- Stretching Stripes
by Frederic Daoud
Fred shows you how to create Stripes extension classes to customize the framework to your needs.

- Interrupt Mood
by Brian Tarbox
Are people always interrupting you with dumb questions?

Departments

- Up Front
by Michael Swaine
Our fifth issue mixes code, self-improvement, and a prize.

- Choice Bits
Tweets, posts, and chatter on programming, publishing, people, and paradoxes.

- How Do We...?
by Dave Thomas
People often ask how we do what we do. This series explains…

- Get a Life
by Daniel Steinberg
Daniel invites you to rediscover the art of letter-writing.

- Swaine’s World
by Michael Swaine
Improving your spelling is all about learning new habits.

- Shady Illuminations
by John Shade
Greatest iPhone annoyance: spammers or Flashers?

- The Quiz
by Michael Swaine
A monthly diversion at least peripherally related to programming.

- Calendar
by Jackie Carter
Author sightings and other notable events.

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

Better All the Time
by Michael Swaine
Our fifth issue mixes code, self-improvement, and a prize.

A good picture tells a story. Here are three pictures that have something to say:

- This chart by Mary Meeker shows that small is big,

- Dave’s chart of royalty earnings may surprise you, and

- this animation of job losses in the US is not for the squeamish.

The November issue of PragPub also has something to say, I hope, about software development and the bigger story of the life of a software developer. And it also includes a prize!

Rachel Davies and Liz Sedley chat with us about what it takes to be a good Agile team coach, and offer some advice on how to handle some of the thornier problems you’ll face in Agile coaching. Staffan Nöteberg takes on a different coaching challenge: how to coach yourself. The Pomodoro Technique scales Agile practices down to the individual, and Staffan shows how, using Pomodoro, you can be your own coach and master time.

Brian Tarbox returns this month with a somewhat different take on what’s getting in the way of your productivity. It’s other people. Brian suggests some ways to get them out of your hair. In that same spirit of self-improvement, your editor offers some advice on improving your spelling.

In a more technical vein, Bill Dudney shows how to use Apple’s Game Kit to develop multiplayer games for iPhone, and Frederic Daoud demonstrates just how customizable the Stripes Web application framework really is.

But wait, there’s more! Daniel evokes the lost art of letter-writing, Dave explains how we automate the sending of email, RSS, and Twitter notifications, John Shade explores another dark corner of computing, and we get cryptic with another quiz—and this one has a prize. Solve the puzzle and you’ll earn a 25% site-wide discount on any of our Pragmatic Bookshelf titles. You’re welcome!

And don’t forget about our PragProWriMo writing project.

Choice Bits

Overheard on the Intertubes

Wading into the chatterstream in hip boots, we wield the Axiom of Choice with gleeful abandon.

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^

NEW

Pomodoro Technique Illustrated

2^

4

iPhone SDK Development

3

3

Agile Web Development with Rails, Third Edition

4v

2

The RSpec Book

5^

8

Core Data

6^

7

Language Implementation Patterns

7v

1

Beginning Mac Programming

8^

10

Programming Clojure

9^

NEW

Hello, Android

10v

5

Programming Ruby 1.9

11^

NEW

Source Control Made Easy

And Here’s What Folks Are Saying…

Let’s not pretend that we know what time it is because we know what we saw last time we checked our watches. — Guy English, KickingBear

The more things change...

Facebook updates home page, irks users (again). — Michael Sim

Journalism today...

Circulation declines at major newspapers—some of them huge—will strengthen the paywall advocate's hand. — Jay Rosen

Journalism is so important that leaving it to a group of people in an office downtown is irresponsible. — Clay Shirky

So far, our editors meeting has featured a whip, a walking brain, and an editor wearing a false nose. — Dave Thomas

Things you weren’t planning to think about...

[T]here are more chickens than people in the world. — Ed Yourdon

Imagine how annoying it would be if your computer constantly made the same sounds tv/movie computers make. — Chad Fowler

If a group of sorors is a sorority, why isn’t a group of jurors a jurority? — Pat Rice

In 1945, the very first bug was found in a computer and taped to the log book. What unit test were they running when they found the bug? — Andy Hunt

Fixing the blame...

[U]sers will only read the absolute minimum amount of text on the screen necessary to complete their task. — Jeff Atwood, Coding Horror

[L]etting the consultant pick your technology is like letting the undertaker pick your medicine. — Kent Beck

Latest rpt re: ban of SocMed channels by CIOs... indicates most CIOs R mired in fear/contempt stage of acceptance. — Peter Salvitti

People worry that China’s autocracy is run by engineers. Well, how would you like to live in a country run by lawyers? — Stewart Brand

Moderating the forums today was just like teaching preschool. Except for the poo. Far more poo in the forums. — Chris Breen

You just need to push yourself more...

Ok—I just wrote an entire first pass of a chapter in 25 minutes using Pomodoro Technique as outlined by @staffannoteberg. Wow! — Travis Swicegood

My new Icelandic trainer's rule: what you ask of your horse, YOU must be able to do. I've been riding up hills, fast. I'm toast. — Kathy Sierra

Endorphins are the best drug ever. — Mike Clark

No, you need to relax more...

Wealth is the ability to fully experience life. — Henry David Thoreau rt @SharonHayes

[M]irrors + puppies = endless entertainment. [I]t eventually feels a bit like torture, but not enough to stop. — Kent Beck

Forget pair programming! I want to learn pair guitaring. — Jim Weirich

But isn’t fast food an oxymoron?

Is there any food greater than Pringles? I don't think so. — Andy Lester

“Slap Ya Mama” Cajun seasoning has slapped a lawsuit for trademark infringement on an upstart spice company marketing under the name “Punch Ya Daddy.” — WWLTV, Louisiana

Oh well, as long as you have your health...

The “opt-out” public health care plan will allow red states to cut off their noses to spite their faces and not have the procedure covered. — John Gruber

Your hu-man medicine will do no good here, European! Our bodies are made of strange stuff only treatable by market forces. — Cory Doctorow

Los Angeles moves to cloud (a short trip?)...

The Los Angeles City Council today voted unanimously to “Go Google,” approving a $7.25 million contract to outsource the city’s e-mail system to Google’s cloud and transition some 30,000 city employees to the cloud over the coming year. — ZDNet

Other observations...

Microsoft does not need to be servicing a Dell laptop retuned by a customer now blaming Microsoft for its failure. — John C. Dvorak, re Microsoft stores

[S]cala: all the ease-of-understanding of haskell combined with all the flexibility and rapid development of java. — Randal L. Schwartz

So cool that the White House is now using open source CMS Drupal. — Andy Lester

My next post... will be people who unfollowed me and look interesting. — Tim Bray

How Do We...?

How Gerbils Make Sausage
by Dave Thomas
People often ask how we do what we do. This series explains…

This month's question: How do you send email, RSS, and Twitter notifications?

Our online store can send notifications (such as “thank you for your order”) via email, RSS, and Twitter. It was important to us that we encapsulated this functionality behind a tidy, abstracted, interface—when new ways of sending notifications come along in the future, we don’t want to have to go changing the application in lots of places. In the end, all of the notification stuff is hidden inside one library class and one Rails model.

Let’s track that “new order” message as it makes its way from the code to the user.

When the checkout process is complete, we convert what was the shopping cart into a full-blown order. At the end of that process, there’s the following line of code.

Notifier.new_order(cart.email, user, cart)

The Notifier is the central dispatcher for all notifications. It contains a public method for each of the different notifications we send out. These methods are basically responsible for extracting all the various parameters needed to construct the notification before calling a common, private method that does the work. The new_order method looks like this:

def new_order(email, user, order)

do_notify(:new_order, email, user,

:title        => "Your Order ##{order.number}",

:link         => homepage_url(user),

:category     => RssCategory::ORDERS,

:order        => order,

:download_url => order_downloads_url(:order_id=>order,

:token=>order.token))

end

The first parameter is the base name of the template we use to generate the actual notification message. For each message, we typically have both HTML and plain text variants. We use the Rails ActionMailer to format a multipart email using these templates. Inside the do_mailer method, you’d find the code

mail = NotificationMailer.send("create_#{event}", email, params)

The first parameter creates an email based on the name of the template, and the last parameter is the hash passed to do_notifier. These are the values to be substituted into the template.

The good news is that we don’t actually have to write separate create_xxx methods inside the mailer model for each message type—Ruby metaprogramming to the rescue. Here’s our entire mailer:

class NotificationMailer < ActionMailer::Base

helper :application

def method_missing(name, *params)

email   = params[0]

assigns = params[1]

from        "The Pragmatic Bookstore <support@pragprog.com>"

sent_on     Time.now

recipients  email

subject     "[Pragmatic Bookstore] #{assigns[:title]}"

body(assigns)

end

end

Back in the Notifier class, we then look at the user’s preferences to see whether to actually send the email we just created. If the email is wanted, we just call NotificationMailer.deliver and off it goes. But why go to the trouble of creating the email if the user doesn’t want us to send it? It’s because ActionMailer is a great way to render Rails templates without going to the trouble of faking out a whole controller environment. And we want the HTML version of the message, because we’ll use it to create the RSS notification for the user.

html_part = mail.parts.find {|p| p.content_type == "text/html"}

user.add_rss_entry(params.merge(:description=>html_part.body))

ActionController::Base.expire_page(rss_feed_url(user, true))

Finally, we see if the user has registered a Twitter name with us. If so, and if the notification says it’s appropriate, we send off a quick tweet.

When we first started doing this, our volumes were fairly low, and we sent email in the foreground. That didn’t scale, so Michael Koziarksi (Koz) added a wonderful hack to the notifier. He changed all the notification methods into instance methods. He then implemented this:

def self.method_missing(name, *args)

send_later(:send_notification, name, *args)

end

def self.send_notification(name, *args)

new.send(name, *args)

end

When you call the class method new_order, the method_missing intercepts and uses the wonderful DelayedJob plugin to invoke the send_notification method at some point in the future. When that happens, a new instance of the Notifier is created and its new_order instance method is invoked. Because all the notification code is encapsulated inside this one class, the switch to making all notifications asynchronous didn’t affect any of the main application code.

As well as handling email, RSS, and Twitter notifications, we also use the notifier to update a couple of private Campfire rooms with a log of internal application events.

The notification system in our store is a great example of how the flexibility of Ruby can lead to some nicely decoupled, easy-to-maintain code.

Dave Thomas is one of the Pragmatic Programmers.

Get a Life

The Lost Art of Letter Writing
by Daniel Steinberg
Here’s a letter from Daniel. Now it’s your turn.

Somewhere in my basement I still have my favorite rejection letter. The program director at WAAF-Worcester sent it to me my senior year of college and it still makes me smile.

Then as now, I only applied for jobs that I wanted. (I admit there was a time in the middle when that wasn’t quite true.) I thought the applications through carefully and targeted my résumé and cover letter specifically for the position I was applying for.

There were two sorts of jobs I was applying for: I wanted to be a high school math teacher and I wanted to be a radio DJ. I decided to bury my education at the bottom of my radio résumé and fill the top with my on-air experience. I didn’t have a lot of content, so I dressed it up with a gimmick: I typed it all in caps like it was news copy coming off of the AP or UPI news wire. I used datelines at the front of each entry and I used ellipses in place of punctuation just like the radio copy I’d been writing for years.

In those days we didn’t have personal computers. I didn’t have a wide variety of fonts and sizes and other tricks to make my résumé look just right. I had to go down to the local printer and rent their IBM Selectrix typewriter for fifty cents an hour. There were very few variations available on the Selectrix, but you could swap out the element to vary the font slightly. Every time I had a couple of jobs to apply for I would head down to the print shop and type up a cover letter that matched the style of my résumé. I had had the résumé printed on a nice weight of paper and had ordered twice that many blank pages so that my cover letter would match.

I recorded demo tape after demo tape and bundled each one up with my résumé and custom cover letter and sent them to radio stations that I should have known would never hire me. After decades in and out of radio I can tell you that I’ve never gotten a job that way. I did, however, get my favorite rejection letter of all time.

Rejection Letter

It wasn’t particularly nice, or warm, or encouraging, or anything like that, but it was written in all caps. This wasn’t the form rejection letter I had been getting. This was from someone who had noticed my submission material and was rejecting me because he didn’t like what I had to offer. He took the time to mock my application—and it meant the world to me.

We each put time and effort into our communication and there were layers of conversation in what was otherwise a simple application and rejection.

I’ve only recently started to put that sort of effort into my communication again. Technology has made me lazy. It’s so easy to dash off an email “Hey, thanks for lunch. See you soon.”

What about you? When is the last time you sat down and wrote a thank-you letter? What about a hand-made greeting card? Growing up, we always made cards for birthdays and holidays. I think there’s something positive about slowing down to mark an event or to say thank you—and I want you to try it.

First Letter

Think of this as your November Thanksgiving project. At least once a week between now and Thanksgiving I want you to move up the hierarchy when you give thanks. If you accept this challenge, you are going to send four notes this month—and you’re going to make a small difference in five people’s lives.

There are times when it’s appropriate to just send someone a casual email or spot someone on IM and wish them a happy birthday. (It could be a little creepy to go over the top with someone you hardly know.) So find an online site that has greeting cards. Scan through them until one makes you think of someone in particular—someone who’d enjoy it, someone who’d appreciate it, or someone who needs it. Send it to them.

That’s it. I thought it best if we started with an easy one. You’ll probably hear back from your friend and there’s a good chance they’ll send you a card. But that’s not why you sent it. Expect nothing back.

Second Letter

OK, it’s week two: are you ready to step things up? This week, find some reason to send someone a card that you buy in a store and send in the mail. It could be an event like a birthday or a reason for congratulations or condolences. It might be someone you haven’t heard from in a while that you want to reconnect with just to say you’re thinking of them.

You can draw inspiration by searching for Kevin James’ card buying skit. He mimes someone agonizing about the perfect card. They read every word and consider it from the point of view of the person receiving the card. You should do that—but ideally with less drama than James.

Before you send it, you need to write a sentence on the card that begins, “This reminded me of when,” or “I was thinking of you because.” Personalize the card in some way, sign it, and send it.

Again, you may or may not hear back. If it’s been a while since you sent a card in the mail, the wait may drive you nuts. Online, you expect to hear back within seconds, minutes, or in the worst case in an hour or so. When you send a letter, it has to get to the other person and they have to be in the location where you sent it. If you send me an email while I’m off teaching in Denver, I’ll still get your email within an hour or two. If you’ve sent me a letter, it will have to wait until I return.

You may also not get the response you expect. The person receiving your card may call you urgently to make sure that you’re all right and that you’re not dying and putting everything in order before you go. Reassure them that you’re not and remember to at least find an online card to send them thanking them for their concern.

Third Letter

So far you’ve sent two cards and written little more than a sentence. In week three you need to write someone a letter. Don’t ask me how many words, single spaced or double, what the font and margin sizes are. It doesn’t have to be a long letter, but you must write it by hand on a blank card or on a piece of stationery.

One thing I love about writing a letter by hand is that the rhythm is different from email or even a letter that I craft using a word processor. When I write with a computer, I can dash out a few sentences and then fix them. When I write a letter to a friend with pen on paper, what I write stays on the page. This slows me down. I stop and think about the friend more as I write to them. I think differently about what I’m saying. The act of putting something down on paper by my own hand makes me pause first to think of something to say that is worth capturing this way.

You may find that it takes a long time to get started writing this letter. It feels like the thank-you notes you had to write when you were a kid. “What is there to say?” Pause when you’re finished to see how you feel. You can wait to mail it if you like. The rhythm of mail is so different. But sometime during the third week be sure and drop it in the mail.

Fourth Letter

Are you ready for your final test? This week you are going to send someone a card that you draw yourself. It doesn’t matter how well you draw. Have fun with it. Draw a picture of anything. It could be an animal with a thought bubble, it could be people you and the recipient know in a familiar scene, or it could be a picture of a place you’ve been meaning to visit.

My daughter recently drew a booklet full of pictures for a good friend’s birthday with scenes from each year of their friendship. When the friend sent a thank-you note, it was topped with a picture in the same style as my daughter sent, with a sketch of her, her sister, and my daughter wearing matching striped gloves that they had bought together.

That’s a thank-you note I’ll remember as long as I remember my favorite rejection letter.

And don’t forget about our PragProWriMo writing project.

Daniel is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple’s ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple’s Worldwide Developer Conference, MacWorld, MacHack, and other Mac developer conferences. Daniel has produced podcasts for Apple featuring the work of developers and scientists working on the platform. He has coauthored books on Apple’s Bonjour technology as well as on Java Programming and using Extreme Programming in Software Engineering classes.

Swaine’s World

A Crash Course in Spelling
by Michael Swaine
Improving your spelling is all about learning new habits.

You may write code for a living, but how good a living you make depends in part on how well you write prose. Resumes, blogs, comments on wikis, emails, reports, user stories—you probably write more prose than you think. Everybody writes prose, and most people do it ineptly. The most obvious and embarrassing failing in most people’s prose is bad spelling.

Does it matter? In some contexts, not much. Nobody really cares if your tweets are models of good spelling. But in any kind of serious professional written communication that you do, or anything bloglike where you stretch out and express yourself, people are judging you on your spelling.

And that’s a scary thought, or should be, even if you think that you spell very well, even if you think of writing as your second profession. Trust me, even professional writers are not entirely immune to bad spelling.

The good news is that you can drastically reduce the number of spelling errors you make—not just fix them, but largely quit making them in the first place. I’m going to show you how. It’s remarkably easy. The key is to understand that bad spelling is not a character defect or inherited trait, but just a bad habit.

Kicking the bad spelling habit requires only a few tools: whatever spell checker is convenient for you, Google, and your attention. Are you paying attention? Then let’s start.

What Spell Checkers Are Good For

You start improving your writing by reading it. That’s where your attention comes in. You have to proofread your writing. If you write code, you already know that reading for meaning is a different activity from reading for errors, or proofreading. Proofreading is a skill, and you have to rely on that skill because there are fewer automated tools for catching errors in prose than there are for catching errors in code. Prose is distributed in source form and compiled on local hardware. When you write it, you not only have to get it to compile on your hardware, you have to ensure compatibility with a multitude of different brains. Fortunately, there is at least one tool to help you: a spell checker.

I used to deride spell checkers. They don’t catch all spelling errors, so you still have to look at every word. I used to think that the fact that they didn’t really eliminate the need to manually check your spelling meant that spell checkers were useless. But I was wrong: a spell checker is a powerful tool.

That power is realized when you use the spell checker not to fix errors in spelling or typing, but to eliminate such errors in your writing. Your goal is not to swat the immediate mosquito but to implement a mosquito abatement program. When used to fix errors, a spell checker is a crutch. When used to help you stop making errors, it is a learning tool.

Here’s how to use a spell checker to help you stop making spelling errors.

Look It Up

When your spell checker flags a word, look it up. Don’t just fix the error, at least not the first time. Look it up.

Looking it up can be as simple as typing define: theword into Google. Don’t worry about what dictionary you’re using; for your purposes, almost any will do. But read what the dictionary says.

What you’re trying to do is to get familiar with the words you misspell. Look the word up, read the definition, check the spelling, note the pronunciation, say it to yourself. If it isn’t pronounced the way it’s spelled, let yourself notice that. Let it sink in. Get to know the word. Do this even if you know at a glance what the spelling error was. That doesn’t help you. The only way you’re going to avoid making that mistake again is to get to know the word, to make it your own.

I’m not just talking about unfamiliar words. The word crayfish or crawfish takes on more meaning when you realize that it’s related to crevice. Many words in English are spelled in a way that seems to make no sense. Making a word your own doesn’t mean that you have to like its counterintuitive spelling, just that you recognize that it is counterintuitive, and in what way.

Do this even if you absolutely know how to spell the word, because you didn’t spell it correctly, did you? Something went wrong. I promise you it’ll go wrong again if you don’t do something to change your habits. Remember what Einstein said about doing the same thing over and over again and expecting different results? You need to get out of that groove. Looking the word up is an opportunity to give yourself more connections with the word, more neural pathways to the correct spelling.

Teach Your Fingers

You’ve looked up the misspelled word. Now highlight it and type it correctly. Don’t shortcut this. If you’ve transposed two letters, don’t just fix those two letters. Retype the whole word. Transposition errors are almost always typing errors rather than word-knowledge errors. This is your opportunity to teach your fingers how to spell the word, and they have to know, too. It’s not enough to get the word right in your brain. Much of the time when you make spelling errors, it’s your fickle fingers betraying you. Give them every chance to learn. And there’s only one way to do that: type the word. You don’t just want to break the bad habit; you want to replace it with a good habit.

Your investment in your fingers’ education will pay off. Your fingers are remarkably smart. Even if you type with two fingers, those two fingers are perfectly capable of telling you, with startling accuracy, that they’ve just hit the wrong key. Feeling your typing errors as you commit them is an acquired skill, but anyone can acquire it. All it takes is paying attention. When your finger tells you that it’s hit the wrong key, believe it: it did. Trust that proprioceptive feedback. It’s probably even telling you exactly how many keystrokes you’ve typed since that mistake. You can use that information. Your fingers are willing and able to help.

You want to get your fingers on your side. Give them every chance to habituate correct spellings and to extinguish bad spelling habits. And learn to listen to what they are telling you. In their sphere, they are a lot smarter than you. They think faster. Use them. Get them working for you and not against you.

Things You Must Know

Yes, but. As I’m sure you realize, you can do all of this and still look like an illiterate boob. There are some extremely common errors that most spell checkers don’t catch. The biggest category is correct words used incorrectly. So, as I foreshadowed at the beginning, you do have to proofread your prose for spelling errors even after the spell checker has done its work and you’ve corrected all the errors it found. The good news is that you can eliminate 90-plus percent of these spell-check-resistant errors by studying a few tricky cases. Learn these cases, then follow through by monitoring your prose for these cases, because just knowing what’s right won’t guarantee that you won’t occasionally type there when you mean they’re, or leave out the apostrophe in the contraction it’s.

But there are so few of these extremely common misuses that there’s no excuse for not just learning them and getting them out of your way. So here is the list. Learn these, learn them well, check for them routinely in your prose, and you’ll eliminate most of the post-spell-check errors in your writing.

- it’s vs. its

- you’re vs. your

- they’re vs. their

- who’s vs. whose

The first word in each of the above pairs is a contraction; the apostrophe indicates letters left out: it’s is short for it is or it has, you’re is short for you are, they’re is short for they are, who’s is short for who is.

The second word in each pair is the possessive: “Your cat is biting its tail; people can’t believe their eyes.” Why do pronouns defy the rule that possessives are formed using an apostrophe? Probably because the whole purpose of a pronoun is to abbreviate, but take it as arbitrary and learn it by rote. It’s just one rule: no apostrophes in possessive pronouns. You can memorize it.

Oh, and don’t write her’s. There is no such word. The word for belonging to her is hers. Same reason, same rule: no apostrophes in possessive pronouns.

-ible vs. -able

Visable or visible? Oh, that was too easy? How about illegable vs. illegible? Negligable or negligible? Debatable or debatible? Permissable or permissible? In general, when do you use able and when ible?

Most of the time, this rule works: if the part before able or ible is a word (you might have to add a silent e), use able; otherwise use ible. Easy to remember because able is a word and ible isn’t.

- accept vs. except

- advice vs. advise

- affect vs. effect

- complement vs. compliment

- led vs. lead

- loose vs. lose

- passed vs. past

- peak vs. pique

- principal vs. principle

- sight vs. site

- to vs. too

- than vs. then

I won’t give you any clever rules for these confusable pairs of words, because I don’t know any. You just have to learn them. If I thought there was a chance of it working, I’d advise you to look up every one of these words right now. But I’ll settle for this: if you can’t clearly articulate the difference in meaning and usage of any of the pairs of words, look them up.

I know. This is beneath you. You know how to spell. You know what to means. But that’s not the point. You do make spelling or typing errors; we all do. The idea is to notice when this happens and then to retrain your habits. This is how you improve your spelling.

And don’t forget about our PragProWriMo writing project.

Michael Swaine is the editor of PragPub.

The Agile Coach

An interview with Rachel Davies and Liz Sedley
interviewed by Michael Swaine
You need more than a whistle to coach an Agile team.

Rachel Davies and Liz Sedley are recognized experts on Agile coaching. The release of Agile Coaching, their definitive book on the subject, inspired this interview with these two coaches.

ms: Shall we start by defining our terms? Maybe you should tell us what an Agile coach is, and what one does in carrying out the role of an Agile coach.

ac: Sure. An Agile coach works with software development teams to help them improve their performance and get the benefits of applying Agile principles to their work. The way we do this is by guiding the team to become more aware of their workflow and of ways to collaborate more effectively. An effective coach brings to the team knowledge of how to apply Agile techniques, and should be able to help a team acquire competence in Agile techniques.

ms: Can a project manager also be the Agile coach for the team?

ac: One can, yes. A coach has to serve the team and be available to all team members. Some are player-coaches and take on a team role, like developer or project manager. But you may find that taking on responsibility for project deliverables distracts you from coaching your team.

ms: Are there specific skills or personal traits that are necessary or desirable for a coach?

ac: You have to be pretty passionate about being Agile. You also need some experience in applying Agile practices before you attempt to coach people in them. You need to have good people skills and enjoy working with teams. Communication skills are especially important. Problem solving skills help too, so you can help the team spot opportunities for change. You’ll also need to keep your ego in check: the team gets the credit for success, not the coach!

ms: What’s your take on electronic boards and Agile planning software?

ac: We like to keep it simple. We prefer a physical board in the team workspace. We appreciate that distributed teams will need to rely more on electronic plans, but even then spreadsheets and wikis are usually fine. Agile planning software is expensive and often leads to over-complicated plans. Liz has written a sidebar on this in the book entitiled “Agile Planning Software Won’t Help.”

ms: You are seasoned experts in coaching, and teach people how to become Agile coaches. You can talk to people at all levels of experience. For what audience did you write your book? Future coaches, experienced coaches, mere team members?

ac: We wrote this book for the people we used to be—coaches learning how to coach Agile teams. We didn’t write for an expert audience—although we’ve heard from a few who picked up useful tips from our book. What we say in the Introduction is, “It’s for anyone who wants to coach their team in Agile development—whether you are a manager, a technical lead, or simply working in a software team.” That’s who we wrote it for.

ms: What flavor or flavors of Agile development does the book address?

ac: We don’t want to get into debates about which flavor of Agile is best. There’s no definitive answer, because it all depends on the context it will be applied in. So throughout the book we talk about vanilla Agile—a generic mixture of Scrum and XP with a sprinkling of Kanban.

ms: Your book goes beyond the basics to address problems that will come up in Agile teams and what to do about them. I’d like to ask you to talk about some of those instances where things don’t go according to plan or best practices, and you have to be light on your feet and, I guess, agile in your Agile coaching. For example, problem customers: the customer that doesn’t know what it wants, or the customer that isn’t there, meaning that there is no on-site customer.

ac: The role of customer/product owner is critical to the success of Agile projects. If you don’t have someone willing to take on this role then you’re unlikely to get the full benefit of an Agile approach. Where the customer has limited availability, the team needs to make the best possible use of the time they have with him/her. As a coach, your role is to focus on building a strong relationship between the customer and the team, to create a sense of shared commitment.

ms: What do you do if the customer has a hard launch date and the team is asked to overcommit?

ac: If you see that the team is about to commit to far more than their velocity/history shows they’re likely to achieve, alert the customer to the risk that all the stories may not be delivered. If the team insists that they can do it, encourage them to slice the user stories down quite finely, so that for each area of functionality they have something that they can really deliver.

ms: What about really awful organizational challenges, like your team just isn’t assembled on Agile principles? For example, the company organizes by discipline and your team doesn’t have members from different disciplines? Or the team is too big? How does the coach deal with situations like these?

ac: You may be wasting your time coaching a team to try Agile when faced with these impediments, so seriously consider whether you attempt an Agile approach. Our recommendation in situations like this is to take a step back and work on educating the organization about what it means to be Agile first.

ms: What about problems within the team? For example, what can a coach do to head off or resolve problems stemming from cultural differences among team members?

ac: A coach doesn’t necessarily need to step in to resolve these situations. You can educate the team so they become more attuned to cultural differences by running a workshop to explore Geert Hofstede’s Cultural Dimensions (at www.geert-hofstede.com).

ms: And other team problems, like a member of the team being ostracized by the others, or meetings getting overly emotional, or teams that just plain hate planning, or team members who hate pair programming?

ac: The focus of an Agile coach is to help the team work productively together. So you don’t necessarily need to jump in to play the peacemaker. Where the issue concerns team process rather than individual motivation or capability, you can bring up your concerns in the team retrospective. Where a situation is more personal, consider consulting HR and involving line management.

ms: What about when the team fails? The software doesn’t run in the demo, or you don’t get to “done” for all the stories by the end of the iteration?

ac: We encourage the team to get to the bottom of why this happened in their retrospective. Ask the team for their ideas to prevent this happening again. Remember that it’s also likely to affect how much work the team can reliably commit to next time. We talk about both these situations in the book.

ms: In your experience, what’s the most common problem you encounter in working with Agile teams?

ac: One common challenge is that the team doesn’t feel empowered to change things. For example, they feel they’re not allowed to stick their plan on the wall. In this case, what you as coach need to do is to encourage the team to think big and consider what they can do. Most people don’t like change and hang back from it. Expect this. As their coach, you’re there to guide them along on their Agile journey. In our book, we include lots of tips that you can use to encourage teams to become more Agile. But the most important thing you can do is to be a role model and inspire them to keep experimenting and learning.

Rachel Davies works as an Agile coach helping teams adopt and improve their Agile delivery capability. She has a wealth of experience in a range of Agile methods, including XP, Scrum, Lean/Kanban, and DSDM. Rachel supports the Agile community both as a long-serving director of the Agile Alliance and as an organizer of many Agile conferences. Find out more at www.agilexp.com.

Liz Sedley is both a .NET Developer and an Agile coach, which means that she delivers software while improving team culture and process. She lives in London, UK, with her husband and 3 kids, but she’s orginally from Wellington, NZ, and she says she still has an awful accent.

The Pompatus of Pomodoro

Can a cute kitchen timer change the way you work?
by Staffan Nöteberg
In the last few months a technique based on a kitchen timer has caught on worldwide.

It all started when a student in Italy, frustrated with his lack of focus in his studies, challenged himself: can I study, and only study, for just ten minutes? Looking around, Francesco Cirillo’s eyes fell on a tomato-shaped kitchen timer. To him, it symbolized those ten minutes of uninterrupted effort. In Italian, tomato is Pomodoro.

In the Pomodoro Technique as it has developed since then, the usual unit of uninterrupted effort has become 25 minutes and is called one Pomodoro. The genius of the Pomodoro Technique is the way that this commitment to a fixed unit of work time, no matter how many lines of code or artifacts you produce, turns the notion of time upside-down, and rather than time being the enemy who always wins in the end, time becomes your ally.

The genesis of the Pomodoro Technique happened ages ago, in Agile years. Scrum was presented at OOPSLA 1995 and Kent Beck’s first book on XP was published in 1999, but Francesco defined the basic rules of the Pomodoro Technique in the early 1990s. He has now been teaching Pomodoro Technique for over a decade, and in the last few months Pomodoro has become really big in Europe, North America, and East Asia.

As I’ll try to make clear in this article, the Pomodoro process is similar to Agile software development processes, but downscaled to one person. Iterations, PDCA-cycles with retrospectives, signboards showing the current state, timeboxing, commit-reward, value pull over push—all these concepts also have their place in the Pomodoro Technique.

And all you need to implement it is three simple sheets of paper and a mechanical kitchen timer.

A Pomodoro Iteration

Consider how a Scrum team operates. The team follows a recurring pattern every day. At the morning meeting, the team prioritizes what in the Sprint Backlog is to be done today. Then they focus on those, and only those, tasks. When the day is over, everybody goes home and has guilt-free play.

It’s a rhythm, and deliberately so. Rhythms make us feel safe: we breathe every second, we sleep every day, we celebrate holidays in the same seasons every year. The daily cycle in the Scrum-rhythm is: prioritize-focus-rest.

The same pattern applies to the rhythm of the Pomodoro Technique, but a cycle is only half an hour.

- First, you prioritize the activities that you selected in the morning. Choose the one that creates the most value.

- Second, you wind up the kitchen timer for 25 minutes and focus only on that activity. When the clock rings you stop immediately.

- Third, you have guilt-free play for 3-5 minutes.

When you return after the break, you choose whether you should continue with the same activity or switch to something else. One Pomodoro Technique iteration of 25-minute effort is called a Pomodoro.

A Pomodoro Technique Day

In the 1950s, Edwards Deming popularized Walter Shewhart’s PDCA cycle. Many companies in the manufacturing industry subsequently started to practice it to improve their business processes iteratively. PDCA is present in Agile software development processes as well. A Sprint in Scrum, ending up in a retrospective meeting, is an example of a PDCA cycle.

PCDA cycles are present in the Pomodoro Technique, too, but here a cycle takes just one day:

- P stands for planning. You start your Pomodoro Technique day with planning. You select the activities that you want to have completed during the day. There should be a reasonable amount, so that you know that you have a commitment.

- D is Do. You seamlessly track statistical data while you work on the selected activities.

- C means Check. At the end of each Pomodoro Technique day, you summarize your tracked data. Then you compare it with your expectations in order to find discrepancies.

- A is the Act. You analyze the discrepancies and try to understand the root causes. Sometimes you decide that you want to customize your personal process based on that analysis.

As should be clear, Pomodoro Technique is an adaptive process. At the end of each day you have the ability to customize how you want to work tomorrow. This adaptation is based on empirical knowledge.

Artifacts

In Scrum, the Product Backlog keeps track of all possible future features. Before the start of each Sprint, a subset of the Product Backlog is selected. This subset is called the Sprint Backlog. These are the activities that the team will focus on during the upcoming Sprint.

In the Pomodoro Technique, the coarse-grained backlog is called the Activity Inventory sheet. It is one of the three sheets of paper that I mentioned before. Every time you realize a new activity, you add it here. The Activity Inventory becomes an unprioritized list of activities. Every morning, you select a realistic number of activities from your Activity Inventory sheet and write them on your To Do Today sheet—the second sheet.

“Realistic” means as much as it is reasonable to expect that you can complete in one day. This is your commitment. You want to make a commitment that you have a good chance of meeting. To meet a commitment, i.e. to deliver what you have planned, creates a positive feeling, and makes you more effective, better equipped to meet future commitments.

Interruptions

Do you get distracted by all the interruptions in your work life? Edward Hallowell coined the term Attention Deficit Trait (ADT) to describe a stress state created by modern office life. People aren’t born with ADT. It is caused when we become extremely busy attending to many, many inputs and outputs. We become increasingly distracted, short-tempered, impulsive, impatient, and, over the long term, underachieving.

When you practice the Pomodoro Technique, you accept the interruptions, you visualize them, you have a process to deal with them, and you work consciously to reduce them over time.

Here’s an example: In the middle of a Pomodoro iteration, you remember that you must call your sister. Instead of calling her immediately, you note it as “Call sister” in your backlog. Then, you intensify your effort to complete the task that you focused on before this thought intruded. To call your sister is an activity just like any other. You shouldn’t do it just because you got a sudden impulse. It will be planned and prioritized like any other activity.

Pomodoro Technique emphasizes the difference between internal and external interruptions. Internal interruptions are caused by instincts or other internal motives: I have to read e-mail, I want to drink coffee, or I must make a call. External interruptions are initiated by other people or systems. My email client beeps, my phone rings, someone comes into my room and asks a question. (See Brian Tarbox’s essay in this issue for another take on external interruptions.) You have to try to protect your Pomodoro. When someone is calling, ask if you can call back later—a promise that you obviously need to keep. Then add that activity to your inventory. Context switching is expensive and you can only afford it if the interruption is caused by something very important.

Recording

Throughout the day, you track events seamlessly. You may write an X on your To Do Today sheet every time the kitchen timer rings and you have completed one Pomodoro. You may write an apostrophe every time you have an internal interruption, and a dash each time you have an external interruption. You choose what you want to measure.

At the end of the day you transfer your tracked data to your Records sheet—the third sheet. There you can compare it with the tracked data that you gathered yesterday, the day before that, last week, etc. This is also the time when you can see whether it meets your expectations. If it doesn’t, you may want to tweak your process a little bit for tomorrow, in order to make you even more effective and efficient.

There is much more depth to the Pomodoro Technique than this brief sketch has shown. But if you implemented just these basics of the technique, you would find that time can become your ally and not your enemy.

Staffan Nöteberg is the author of Pomodoro Technique Illustrated. He has 20 years of experience as a freelance software developer, Agile coach, and conference speaker. He lives in Stockholm, Sweden and Istanbul, Turkey. And he’s not only focused on his own productivity; he’s also passionate about helping all kinds of office people to improve their personal time management.

Bonjour, iPhone

Using Game Kit to Network iPhone Apps Easily
by Bill Dudney
Bill walks you through building a rudimentary multiplayer game for the iPhone using Apple’s Bonjour-based Game Kit technology.

A phone is a communication device. The iPhone is an application platform. Some of the best-selling applications are games. So what’s more natural than to create a multiplayer game that two or more people can play on their iPhones?

Unfortunately, adding networking to an app can be a major pain.

Fortunately, the iPhone has some great technology to make that job much easier. From the beginning (all 18 months ago) the iPhone SDK has included zero-configuration networking via a technology called Bonjour. With Bonjour you can broadcast services offered by your app, and other apps can find those services easily. But much of the code to get that started and send data back and forth between the two instances can be tedious and error-prone.

Enter iPhone SDK 3.0 and the Game Kit. Built on top of Bonjour, Game Kit removes the tedious setup and communication code required to connect two applications to each other. It makes building multi-player games much easier.

And in fact, the typical use case for the Game Kit is to connect two instances of a game together for multi-player action. Let’s do that.

We are going to build a really simple game that displays colored disks on two iPhones. When the user taps on one of these disks, the disk will spin and fade out on both devices. A really simple game, to be sure; but the stuff you learn here can easily be transferred to your real application to allow it to network your users together.

There are three phases to using Game Kit:

1. First, you have to connect the two instances of the application.

2. Next, you process data received from the other application to reflect state changes on the other instance of the application.

3. Finally, state changes on the first instance of the application have to be packaged up and sent to the other instance.

Get Them Talking

There are a couple of ways to initiate the connection with Game Kit. The approach you take depends on how much control you need over the process or how much customization you want to do with the user interface. Of course the easiest way is to let Game Kit take care of the UI and all the details. We will take this approach in the application we build here.

Use the GKPeerPickerController to initiate the connection sequence. The code to kick it off is really simple: just create an instance, set the delegate, and tell the picker to show itself.

- (void)startPeerPicker {

GKPeerPickerController *picker =

[[GKPeerPickerController alloc] init];

picker.delegate = self;

[picker show];

}

When the picker appears, it will let the user know that it’s looking for other instances via an alert that looks like the first figure. Behind the scenes, the picker is doing all the tedious Bonjour configuration for us. I love how simple this is.

After we show the peer picker, it turns around and asks us (the delegate we provided) for the Game Kit session it should use to connect to other instances with.

- (GKSession *)peerPickerController:(GKPeerPickerController *)picker

sessionForConnectionType:(GKPeerPickerConnectionType)type {

return [[[GKSession alloc]

initWithSessionID:@"_com.prapprog.examples_"

displayName:nil

sessionMode:GKSessionModePeer]

autorelease];

}

The session id (_com.pragprog.examples_ in this case) is used by the application to find other instances that are compatible. So you will want to use unique names here for applications that would not understand each other. If you want to register your name to ensure that it is unique, you can do so on this site.

There are three modes the session can be in: client, server, or peer. You would use server mode if you wanted to connect up to four instances of the application, with one being the server and the other three being clients in client mode. Peer mode is better suited when you have just two instances of the application connecting. Since our game is just one-on-one, we’ll use the peer mode.

Now that we have the first instance of our application looking for peers, let’s start calling it instance A so we can distinguish it from the second instance, which we will imaginatively call B.

When instance B’s peer picker starts its game session, we will then have two instances of our application looking for each other. Since they both have the same session id, _com.pragprog.examples_, they can find each other. As each instance finds the other, the peer picker changes the UI to reflect peers that have been found. The peers will show up in a table view that looks like the second figure.

The next step in the two instances of the app getting connected is for one of the users to tap on one of the rows in this table view. When that happens, the other instance will get a prompt asking the user if they want to accept the connection. The prompt looks like the third figure.

Assuming that the user clicks the Accept button, the peer picker will then pass ownership of the session back to the application by calling another delegate method. Here is the code for that method.

- (void)peerPickerController:(GKPeerPickerController *)picker

didConnectPeer:(NSString *)peerId

toSession:(GKSession *)session {

if([peerId hash] > [session.peerID hash]) {

_status = kServerGameStartedClientStatus;

} else {

_status = kServerGameStartedServerStatus;

}

self.peerId = peerId;

self.gameSession = session;

self.gameSession.delegate = self;

[self.gameSession setDataReceiveHandler:self

withContext:NULL];

[picker dismiss];

picker.delegate = nil;

[picker autorelease];

}

The first part of this method is a really simple method to figure out which peer should be responsible for creating new disks to show up. The peer with the highest-hashing peer identifier will be placed in server status, the other will be placed in client status. Keep in mind that this does not affect the Game Kit session mode that we started with (peer in this case): the client and session states here are merely part of this simple game. In a more sophisticated game you’d probably want to have both peers responsible for the game state.

Next, we take ownership of the session by setting the gameSession property to the session passed into this delegate method. We also become the session’s delegate so we get notifications of interesting things happening on the session.

We also set this object as the data receiver handler. That means that as the other instance (A or B) sends data over the network, this object will get a message call with the data. We will look at that code in just a minute.

Finally we dismiss the picker and nil out its delegate. Congratulations! The two processes are now connected and ready to start sending data to each other.

Let the Games Begin!

Now that A and B are connected and ready to send data back and forth to each other, we need to listen to the session and inform the user if the connection is lost. Since we are the session’s delegate, we get the following callback if the connection is lost.

- (void)session:(GKSession *)session

peer:(NSString *)peerID

didChangeState:(GKPeerConnectionState)state {

if(_status != kServerPickerShownStatus) {

if(GKPeerStateDisconnected == state) {

// got disconnected from the other peer

NSString *message =

[NSString stringWithFormat:@"Could not reconnect with %@.",

[session displayNameForPeer:peerID]];

UIAlertView *alert = [[UIAlertView alloc]

initWithTitle:@"Lost Connection"

message:message

delegate:self

cancelButtonTitle:@"End Game"

otherButtonTitles:nil];

[alert show];

[alert release];

}

}

}

The session tells its delegate about all state changes for all connected sessions, so we could also use this callback to let the user know if new peers become available. In this simple game, though, we don’t care about anything but the other instance dropping. When the drop happens, we give the user an alert panel, and when they click the “End Game” button, the alert panel calls us back with this message:

- (void)alertView:(UIAlertView *)alertView

clickedButtonAtIndex:(NSInteger)buttonIndex {

// index zero is the 'End Game' button, the only one

if(buttonIndex == 0) {

_status = kServerNotStartedStatus;

}

}

All we do it switch back to the “not started” status. When the game is in this state it will show the peer picker UI again.

Now that we have seen the code for the mechanics of getting connected, we need to take a look at the game’s execution loop.

The game loop is what drives the game. In our case we will push new disks into the game or take old hit or un-hit disks out of the game. It is important that our game loop does not execute faster than the refresh rate of the screen, as a lot of extra action could be going on that the user would never see.

In the iPhone SDK 3.0 release, Apple added a new class to Core Animation called CADisplayLink that makes it easy for us to coordinate with the display refresh. The code looks like this:

- (id) init {

self = [super init];

if (self != nil) {

...

self.link = [CADisplayLink displayLinkWithTarget:self

selector:@selector(gameLoop)];

self.link.frameInterval = 2;

...

}

return self;

}

- (void)start {

[self.link addToRunLoop:[NSRunLoop mainRunLoop]

forMode:NSDefaultRunLoopMode];

}

We create the display link in the init method, then some time later our game object is told to start. On start, the link is placed onto the main run loop. Then its selector is fired on the main thread at the appropriate time.

As I said earlier, the gameLoop method is responsible for the action of the game. Here is the code for our really simple game loop:

- (void)gameLoop {

_loopId++;

if(kServerNotStartedStatus == _status) {

_status = kServerPickerShownStatus;

[self startPeerPicker];

} else if(kServerGameStartedServerStatus == _status) {

if(0 == (_loopId % _diskFrequency)) {

srandom(_loopId);

long x = random() % 300 + 10;

long y = random() % 460 + 10;

CGPoint location =

CGPointMake((CGFloat)x, (CGFloat)y);

long colorIndex = random() % _colors.count;

NSMutableData *data =

[NSMutableData dataWithBytes:&location

length:sizeof(location)];

[data appendBytes:&colorIndex

length:sizeof(colorIndex)];

[self sendMessageTypeID:kServerNewDiskMessageType

data:data];

UIColor *color =

[_colors objectAtIndex:colorIndex];

[self.delegate diskAtPoint:location

withColor:color];

}

}

}

If the game is in “not started” status, then we display the peer picker. If the game is in “server” status, then we create a new randomly located disk, push it to the other instances, and display it.

Sending the data is easy, thanks again to Game Kit. Here is the code for pushing data to the other peer:

- (void)sendMessageTypeID:(ServerPacketTypeId)packetTypeId data:

(NSData *)data {

NSMutableData *sentData = [NSMutableData data];

[sentData appendBytes:&packetTypeId

length:sizeof(packetTypeId)];

[sentData appendData:data];

[self.gameSession sendData:sentData

toPeers:[NSArray arrayWithObject:self.peerId]

withDataMode:GKSendDataUnreliable

error:nil];

}

First we put the type of packet into the data we are going to send. On the other side, we use this first entry to determine how to decipher the data and what to do with it once it’s unpacked. We then add the data to send to the package and push it over the game session to the other peers. (Or peer: in this case it’s just one.)

We’re sending the data in the unreliable mode simply to show how it’s done. In unreliable mode the data goes out over UDP, which means that it might not ever arrive or might arrive in a different order than it was sent. The other possibility is to send the data in reliable mode, which uses TCP, ensuring that the data arrives and that it arrives in the correct order.

Now that we’re sending data, let’s look at the code that processes that data as it’s received on the other side of the connection:

- (void) receiveData:(NSData *)data

fromPeer:(NSString *)peer

inSession:(GKSession *)session

context:(void *)context {

ServerPacketTypeId typeId;

[data getBytes:&typeId length:sizeof(typeId)];

if(kServerNewDiskMessageType == typeId) {

CGPoint point;

NSRange range;

range.location = sizeof(typeId);

range.length = sizeof(point);

[data getBytes:&point range:range];

NSUInteger colorIndex = 0;

range.location = range.location + range.length;

range.length = sizeof(colorIndex);

[data getBytes:&colorIndex range:range];

[self.delegate diskAtPoint:point

withColor:

[_colors objectAtIndex:colorIndex]];

} else if(kServerSmashMessageType == typeId) {

...

}

}

Recall that our game object is the data receiver for the session. Each time the session receives data, it packages it up and sends it to us via this method.

We decode the message by looking at the type of the message. When a new disk message is received, we pull the location and color from the data, then pass that off to our delegate to create a new instance of the disk for this application.

And that’s it. As you can see, getting two instances of an application connected is simple with Game Kit. Looking at the bigger picture, this handy framework provides us with a simple abstraction that makes it easy to send and receive data between iPhones.

Bill Dudney is co-author of iPhone SDK Development. He is a software developer and entrepreneur currently building software for the Mac. Bill started his computing career on a NeXT cube with a magneto-optical drive running NeXTStep 0.9. Over the years Bill migrated into the Java world where he worked for years on building cool enterprise software. But he never forgot his roots and how much fun it was to write software that did cool things for normal people. Bill is back to AppKit to stay. You can follow him on his blog.

Stretching Stripes

One Parameter, Endless Possibilities
by Frederic Daoud
Fred shows how to customize Stripes, a Web application framework that you can learn in a day or two.

Stripes is a Java web application framework that minimizes configuration, keeps things simple, and helps you get your work done without getting in your way. But by tapping a powerful feature of Stripes, you can adapt the framework in just about any way that you need.

You can get started with Stripes in a day or two, and keep learning new features as you need them. And you can definitely get great web applications up and running with what comes out of the box. But Stripes makes it easy to just tweak a few minor things or completely remold certain modules and effectively build yourself a customized web framework. That’s what I’m going to show you.

Modularized design and effective use of the strategy pattern makes this possible, and the Resolver makes it surprisingly easy. One configuration parameter, and you can customize just about anything that you want!

Stripes extensions are classes that you write to add and change the framework’s behavior. A single parameter in the web.xml file tells Stripes where to automatically discover your classes:

<param-name>Extension.Packages</param-name>

<param-value>com.example, org.library</param-value>

Here we’ve told Stripes to look for extension classes in the com.example and org.library packages, and all subpackages of those packages. So you can add, modify, or remove extension classes in those packages without needing to keep any configuration in sync; Stripes automatically discovers your classes at startup.

Note that org.library could very well be the parent package of a plugin that a third party has provided. To enable the features of that plugin, you’d only need to add the org.library package to your Extension.Packages parameter, and the library’s JAR file(s) to your application’s class path.

Here are some examples of functionalities that you can add and modify by writing extension classes:

- How to convert a String request parameter to any type, and how to format any type back to a String

- What to do at different stages of a request (interceptors)

- How to decide the locale for the current request

- Which resource bundle(s) to use

- How to handle exceptions

- How to map request URLs to Action Beans and event handler methods

- How to bind request parameters to Action Bean properties

- How to resolve validation metadata

- ...and more.

As you can see, you can customize just about anything about how Stripes works.

Effective Use of the Strategy Pattern

Modular design and effective use of the strategy pattern are what makes Stripes so easily extensible. For every significant chunk of functionality, there is an interface that defines what needs to be done and a default implementation that says how it is done. In the default implementation, each step of the algorithm is broken into a protected method. This makes it very easy to tweak behavior by overriding the method that corresponds to the step that you want to customize. Finally, by virtue of your placing your class in one of the packages that you defined in the Extension.Packages parameter, your class will automatically be discovered by Stripes and used instead of the default implementation. In this way, Stripes is effectively using the strategy pattern by selecting algorithms at runtime.

Taking Advantage of Stripes Extensions in Your Own Plugins

Not only does Stripes allow you to customize the framework using extensions, but you can easily take advantage of the extensions mechanism to let other developers customize the use of plugins that you write to enhance the Stripes framework. This is where the extension mechanism really shines!

Let’s say that you are writing a nifty plugin that adds integration with a third-party framework. Obviously, this functionality does not belong in the Stripes core, because you wouldn’t want to bloat the framework. On the other hand, users of that third-party framework will certainly appreciate the integration. So you provide a plugin.

Now, as you are writing your plugin, you realize that you are making some arbitrary decisions about how things will be done. You have some sensible defaults, but you’d like to let users tailor your plugin to their own needs, and with minimal effort.

To this end, you can create an interface and a default implementation for each module of your plugin that you want to make easily customizable. Your users can adjust the behavior of a module either by implementing the interface from scratch, or by extending your default implementation and overriding the appropriate methods.

The beauty of this comes when it’s desirable to decide at runtime which implementation to use for each module. You’d like your users to be able to add their extensions to your plugin in the same way that they add extensions to Stripes itself: just by placing their custom implementations in one of the packages that they defined in their web.xml file. Here’s how you do exactly that:

public static  T resolve(Class type, String initParam, Class defaultImpl)

throws Exception

{

Configuration config = StripesFilter.getConfiguration();

T resolved = null;

Class resolvedClass =

config.getBootstrapPropertyResolver().getClassProperty(initParam, type);

resolved = config.getObjectFactory().newInstance(

resolvedClass != null ? resolvedClass : defaultImpl);

if (resolved instanceof ConfigurableComponent) {

((ConfigurableComponent) resolved).init(config);

}

return resolved;

}

This method takes as parameters the interface of the module that you want to resolve, the name of the initialization parameter, and the class of the default implementation. The body of the method uses the Stripes bootstrap property resolver to look for an implementation of the interface in the extension packages. The initialization parameter gives the user the option of defining the implementation in the web.xml file instead of taking advantage of the autodiscovery mechanism. Finally, the default implementation is used if no other implementation is found.

Voilà! By using this resolve method for each interface of your plugin, you’ll take advantage of any extensions that your users provide, and fall back as necessary to your own default implementations. Your users can use your plugin’s out-of-the-box features, and, with minimal configuration, provide their own customizations.

The Stripes framework is not only an excellent web application framework, it is a great example of putting the strategy pattern to good use by modularizing the key parts of the framework into interfaces that have default implementations and that can be customized easily by users, with minimal configuration. Some resources to help you learn more about Stripes are the Stripes Framework, Stripes ...and Java Web Development is Fun Again, the Stripes book blog, and the Strategy Pattern Wikipedia entry.

Frederic Daoud is the author of Stripes ...And Java Web Development Is Fun Again. He is a software developer who has been using Java since 1997 and developing web applications since the “pre-JSP” days of just Servlets. A web framework junkie, he learned a dozen of them before Stripes became his favorite. Currently a Stripes committer, he is active on the Stripes mailing list, answering questions and helping new users. Freddy lives in Montreal, Canada, where he shares the roasting hot summers and freezing cold winters with his beautiful wife Nadia and their two cuties, Lily and Ruby.

Interrupt Mood

Simple Strategies for Avoiding Dumping Your Mental Stack
by Brian Tarbox
They say there are no dumb questions, but there are plenty of unnecessary questions.

I know you’ve had the experience: you’re deep into a programming problem when you’re suddenly brought up short by a someone asking you some trivial question. It takes you five seconds to answer the question and twenty minutes to rebuild your mental stack.

As a software engineer I’ve spent too many years trying unsuccessfully to educate managers and co-workers that interruptions like this are expensive. I’m not talking about legitimate questions, ones that only you know the answer to, ones that truly block the person asking. I’m talking about the silly questions that common sense or thirty seconds with Google could answer. These interruptions impair productivity on top of being just plain annoying.

Here’s my all-time “favorite” example; see if it reminds you of a similar experience. I was working feverishly on a critical bug that might sink the company. I was deep in the code. I had put on headphones and barricaded my cubicle door to forestall intrusions on my mental space. Naturally, despite these clear signals that I really didn’t want to be interrupted, a co-worker did just that. Are you all barricaded in there, he wanted to know, because you’re working on that big bug? “Yes,” I said, seething, “So what do you want?” To which he replied, and I’m not making this up, “Oh, nothing. I was just wondering what you were up to.”

They never did find his body.

In the Air and Under the Sea

Wearing head phones, putting tape across our cube doors, looking annoyed at frivolous questions, these clear signals do not seem to faze the people bent on interrupting us. All right, let’s accept the fact that techniques like these don’t work. When something doesn’t work it’s time to try something else. The trick, of course, is discovering a promising “something else” to try. I find that drawing analogies is a powerful way to discover and import solutions from other domains that I can try out to see if they can be usefully applied.

Trying to find such an analogy to the problem of interruptions for knowledge workers, I thought about various types of workers who are successful in not being interrupted. Yes, such workers actually exist. Let’s consider a few of them and see how they perform this miraculous feat. We can then see if they have come up with any tricks we poor software engineers can borrow.

The first type of worker that comes to mind is an underwater welder (to my mind, that is: I used to live in Hawaii). If someone wants to ask an underwater welder for a status update or to attend a meeting or to answer “a quick question,” they are going to have a wait on their hands. Absent an underwater communications line, the interrupter will have to cool their heels (perhaps, under the circumstances, literally) while they wait for the diver to decompress, return to the surface, and remove some dive gear before they can get an answer to that “quick question.”

Another example is a construction crane operator on a high-rise. While it’s possible or even likely that this crane operator has a walkie-talkie, consider the case where his manager wants a face-to-face meeting (because managers like that sort of thing). Once again, the manager is going to have to wait for the crane operator to set down whatever object he’s moving, climb down to a location where there’s an elevator, and descend to the ground. As before, the person asking the question has to wait a substantial time before getting what they want.

Now compare these examples with the case of a manager interrupting a thought worker. Here’s that scenario in full:

The manager walks in and starts talking.

The manager gets basically instant gratification of their desire for communication. The thought worker sits there in frustration and spends the next twenty minutes trying to reload their brain cache with what they were doing.

The advantage that the diver and crane operator have is that the burden of delay is shared between them and the person asking the question. Yes, the worker is delayed, but so is the manager wanting to talk to him. This manager is aware that asking the question is going to cost him thirty minutes. He probably doesn’t have any idea how much time it will cost the worker, but he has to know that there will be some cost. This presumably makes him think about interruptions before perpetrating them.

The people interrupting us generally have no such awareness. The cost to them of the interruption is effectively zero. They do not see the recovery time we have to expend, they just see that interrupting us was free to them.

Sharing the Pain

An obvious question is, how can we make these people aware of the cost they are inflicting upon us? Although obvious, it turns out that this is the wrong question, which is why solutions predicated on this question tend never to work. A better question is, how can we offload some of the cost onto the interrupter so that it becomes in their own best interest to limit their interruptions?

One technique that some of us use, probably without being especially aware of why we do it, is to hold up a hand when the person starts talking to us, and to continue to do our work for a moment or two. This simple trick can be surprisingly effective. When it works, we are forcing the person to wait for a few seconds while we finish the sentence, trace one more statement, or in general try to page ourselves to memory.

It’s educational to observe the reaction of people you put on hold in this way. They generally act surprised by this unexpected turn of events. It’s almost as if your hand has pinned them to the spot. They can’t very well keep talking, as you’ve made a completely reasonable and civilized request for a very short delay. They also seem to feel that they can’t just walk away, as the conversation has already started.

(Would I be bad if I admitted that I sometimes extend this moment, enjoying a slight discomfort on the part of the person interrupting me? I would? Then never mind.)

Imagine if this technique were formalized and that we went so far as to install a timer at the entrance of our cube. Imagine that a questioner had to press a button and hold it for thirty seconds—or one minute, or two minutes. At the end of this time a bell would ring and they could then start talking. The social rule would be that you were free to ignore them until the bell rang, but after that you had to give them your complete attention. We would have accomplished the goal of sharing the pain of the interruption with the interrupter.

I can imagine work environments where such a device and rule could be implemented successfully. I can also picture work environments where it would never fly. But even there perhaps some different implementation of the same principle would work.

How many fewer questions you would get if people knew they had to wait for a minute before they could interrupt you? I’m willing to bet that the number of in-person questions would drop dramatically while the number of questions by email or IM would increase—although not by the same amount. Some portion of the questions wouldn’t get asked at all. Knowing that they would be subject to a pause before asking the question might encourage people to do a quick Google search rather than interrupting you.

Hiding Out

There are many other ways to share the pain. I recently implemented one by moving my cube to an unused area of our office that’s about a thirty-second walk from most of the other developers. This little thirty-second cost to ask me a question has dramatically cut down on the number of “quick questions” that I get.

A more drastic version of this is to disappear. At one point my manager suggested that I take my laptop and find an unused conference room or spot in the lab to hide out in. For me, that tactic wouldn’t have worked. Aside from it being a tacit admission that our developer culture was broken, it would also have forced me to leave my development environment. I’m blessed with dual 19-inch LCDs on my laptop (to read specifications, JavaDocs, Google etc.), plus another pair of big LCDs on my Linux development box for Eclipse/Mylyn. I didn’t want to leave all that for a laptop screen sitting in the corner of a closet.

But hiding out does work for some people. The editor of PragPub tells me that he has two offices: one among other people where it is understood that he can be interrupted, and another about thirty seconds away in a separate, otherwise unoccupied building with LAN and internet connections but no phone, where he goes to work uninterruptedly.

And despite my total lack of luck with them, you can always try the sign on the door or the tape across the cubicle opening or the sliding mesh barrier. Each of these relies on the good will and common sense of the interrupter. This means that they should work in some settings—but in my experience they only work with the people who wouldn’t be likely to ask a frivolous question in the first place.

Of course, we need to be interruptible some of the time. I’m not antisocial: I run a technical book club in my group and am generally seen as a mentor for developers. I actually love answering questions—but only after the person has invested at least a minute trying to answer the question themselves.

Here’s one more perspective that you might find useful. Think of interruptions in terms of negotiating. To me, and probably to you, time and attention are really the true currency. Anytime someone wants some of my limited time and attention, we enter a negotiation. An interruption is a tacit statement that my time is less valuable than the time of the interrupter. So it’s in general a bad deal, but I am far more willing to accept interruptions from people who have provided information to me in the past. The trade routes are open, so to speak. I’ve told a select few people in my company that they can always interrupt me, even if my headphones are on and the door is closed, because they’ve saved my butt in the past.

These are some of the strategies I have come up with to reduce interruptions. You may know of others. If you find a good one, be sure to share it with your co-workers. Just don’t interrupt them.

Brian Tarbox is a Principal Staff Engineer at Motorola where he designs server side solutions in the Video On Demand space. He writes a blog on the intersection of software design, cognition, and Tai Chi at briantarbox.blogspot.com.

Shady Illuminations

Smartphone Pyrotechnics
by John Shade
Greatest iPhone annoyance: spammers or Flashers?

This fall, Adobe did something supposedly earth-shattering regarding Flash and the iPhone. They made it possible to write Flash apps for the iPhone. Wow. Are you shocked? Does this change your life? Yeah, that’s what I thought.

I mean, I meant to freak out over this news, it was on my to-do list to freak out about it, but I was busy freaking out over the fact that we blew up the Moon.

Did you know that we blew up the Moon? It was in all the papers.

NASA wanted to know if there was significant water under some crater, so they set up a mission to crash a rocket motor near the Moon’s south pole and see if it stirred up ice crystals. Frantic bloggers ranted that mad scientists were going to knock the Moon out of orbit, alter the tides, cause mass extinctions, and annoy the moon people. The scientific illiteracy of the average American may be problematic for scientists, but it’s endlessly entertaining for those of us who think of ourselves as professional audience members for the ongoing comedy.

Me, I think that pyrotechnics on the moon is great theater. Only it can’t be pyro on the Moon, can it? No fire on the Moon, no matter what Norman Mailer thought. I never did hear how the whole thing came out. Was there water under that crater? I’m guessing there isn’t now.

Of course I didn’t actually panic over our bombing the Moon; in fact, it evoked fond memories of my childhood. The idea of setting off explosions to expand your store of knowledge was familiar to me at the age of eight. How high will Mom jump if I set off this cherry bomb behind her chair? There was a lot of that kind of research in my development.

The Flash Affair

I didn’t panic over the Adobe announcement either, and not just because I didn’t understand the issues. I’m sure if I educated myself about the politics of smartphone development I’d be properly scared. I scare easily. But even after researching the Flash Affair, which I’ve decided to call it, I’m not impressed.

As I understand it, the big deal is this: Adobe committed to release full versions of its Flash Player for every major smartphone platform except the iPhone. The missing iPhone version was hardly surprising given that Steve Jobs seems to think that Flash is a combination virus vector and artistic abomination.

Well, actually, no. That’s not the big deal.

The big deal is that Adobe has now released, initially in private beta, a compiler for Flash code that produces first-class iPhone native code. Not a Player, not a runtime that allows anyone to run interpreted code not vetted by Apple on the iPhone. No, this tool produces real iPhone native code.

This is supposed to be frightening not because it will compromise security on the device, which it won’t, but because it will lead to crappy software being offered in the iPhone App Store.

Which has never happened before.

The reason this will lead to crappy software is that these apps will bypass Apple’s UI tools and roll their own user interface. Or because the apps won’t support integration with other Apple technologies, not even cut-and-paste. Or because Flash developers are crappy programmers. Could be a combination of the three. Crappiness is often overdetermined. At any rate, it will lead to some crappy software, and we know this because the apps that Adobe put forward to show how cool this is are all crappy. At least that seems to be the general reaction of early commenters.

And the reason we should panic over crappy software for the iPhone is... I don’t know. Why exactly should you be concerned that other programmers might use inferior tools? I mean, you’re not going to use them, right?

Unless you are. If you’re a Flash developer, and are still reading this after I said you were a crappy programmer, the question would seem to be, how else are you gonna get your programs on the for-the-moment hottest mobile platform? So this is an imperfect solution? So you futz with it until you get something adequate, and anyway you’ll have an answer to those who say it isn’t real if it’s not on iPhone. Meanwhile, you focus on becoming an expert in Android apps.

The Android Invasion

Which apparently everybody is doing. At Motorola, co-chief executive Sanjay Jha trash-canned the entire Symbian line of phones, axed plans to line up with Microsoft Windows mobile, and went all in with Android. Gartner Group is predicting that Android will be the second-place smartphone operating system by 2012, behind Symbian. Everybody’s doing it, apparently.

Oh, you folks developing real apps with Cocoa and Objective-C: the Flash people may write slower apps than you, but that may not matter if they write them faster. Flash is a RAD. So best stake out your space by appstoresquatting.

To me, the concern that Flash apps on iPhone will be crappy is bizarre. I mean, look at the typical Flash app on the Web: there’s the bar, and it’s not very high.

In the end I suspect that what all this Flash brouhaha means is that you should be developing for Palm. Not because it’s a hot platform, but because it isn’t. Your efforts will be appreciated: Palm is hungry for developers. They’re number six in a three-horse race. And let’s face it, you’re probably not going to make any money selling smartphone apps anyway, so why not develop for a platform where you’ll get some love?

I’m sorry, I shouldn’t have said you weren’t going to make any money selling smartphone apps. You’ll probably be the exception. Of course you will. And if you do decide to develop for Palm, do it because you like their HTML5 support, do it because you identify with the underdog, do it because Jon Zilber asked you to, just don’t do it because I suggested it. The only good piece of advice I’ll ever give you is, never follow my advice.

John Shade was born in Montreux, Switzerland in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning left him with a generally dark view of all things shiny, although he is rather fond of the Moon.

The Quiz

Cryptic Witticisms
by Michael Swaine
Solve the puzzles and win a prize.

Below are seven witty or semi-witty quotations, each with its author indicated, and each having something to do with programming, computers, or programming life. They are encrypted with a simple letter-substitution cipher, a different cipher for each quote. Punctuation and numerals are not encrypted, and each of these cryptoquotes includes at least one numeral, which should help you in cracking the codes. Other clues to solving are single-letter words, double letters, letter frequency, and the formation of words, including the author names.

And guess what? This time, there’s a prize for solving!

Solve the first cryptoquote below, remove the space in the author’s name (like GenePitney or HeddaGabler), and it becomes your Pragmatic Bookshelf coupon code. Enter it during checkout at our site to secure a 25% site-wide discount on any purchase (excluding titles we do not publish, such as The Pragmatic Programmer and titles from our friends at SitePoint. Offer good for the first 250 responders; the coupon code expires 11/30/2009). Just a little extra motivation.

Here are the cryptoquotes:

1. “Dgy mbsld 90% pm dgy ipfy tiipavdl mps dgy mbsld 90% pm dgy fyjyzpcnyvd dbny.  Dgy syntbvbvu 10% pm dgy ipfy tiipavdl mps dgy pdgys 90% pm dgy fyjyzpcnyvd dbny.” -Dpn Itsubzz

2. “Msnibh tlltr wdhwkym mftlf tf 0 nl 1? Qr knqvlnqwmy ng 0.5 jtm lyeykfyh jwfsnif, W fsnixsf, vlnvyl kndmwhyltfwnd.” -Mftd Zybbr-Pnnfby

3. “Kn xti pmxcsclkdi tpj ncddcvij xti wpsi jigidczsirx uoudi pw xti ucszmxih, p Hcddw-Hcoui vcmdj xcjpo ucwx $100, bix 1,000,000 skdiw zih bpddcr, prj iqzdcji crui p oiph, fkddkrb igihocri krwkji.” -Hclihx Q. Uhkrbido

4. “Uswj rs rvcgi sz cr, rvjhj nhj nfhjnkx 1,000,000 wsgijxl sg 1,000,000 rxtjbhcrjhl, ngk Yljgjr cl gsrvcgp fcij Lvnijltjnhj.” -Mfnch Vsypvrsg

5. “Ewn lsed’v lnzeyfg ljbcieny ejgk dji? Y2K2, dji uzjr aneeny ewfz ej eyive f veyfzhn ljbcieny!” -L3CJ

6. “Uli zf tmfvmrwwnmc rburic wjx kt Lrbbfunng rgz Olmjcqwrc? Ynorkcn Foq 31 ndkrbc Zno 25.” -Rgfgiwfkc

7. “1d x0s z4j n34e 7p15, x0s n34iix j33e 70 637 4 i1d3.” -Gjhjxlhst

OK, one more hint. Two of the quotes have the same author name. Since each quote has a different encryption, the author names won’t look identical, but they will have the same length and pattern.

Answer to Last Month’s Quiz

Last month we asked you to resolve some mother-child relationships. Here are our mother-and-child reunions:

Mother

Child

1. Black, Estrada, Coronado, Collins, and Zappa

T. Invention

2. Grace Murray Hopper

L. COBOL

3. Mary Lou Jepson

O. One Laptop Per Child

4. Mamma.com

Q. Search engines

5. Ada Lovelace

N. Computer programming

6. Jean E. Sammet

H. FORMAC

7. Adele Goldberg

R. Smalltalk

8. SNOBOL

K. Icon language

9. Fortune

P. Wendi Shasta Leonardo

10. Personal communicators

A. All markets, according to John Sculley

11. A computer

J. N. Katherine Hayles

12. A demo in 1968

F. DEMO Conference

13. Actress Angelina Jolie

I. Grendel

14. Actress Celeste Holme

E. Ted Nelson

15. Actress Hedy Lamarr

S. Spread-spectrum crypto

16. The ’60s

M. Steven Paul Jobs

17. Susan Kare

C. Chicago

18. HyperCard

B. WikiWiki

19. Time

D. Truth

20. Mobo

G. DIMM

Here is the logic behind the non-obvious ones. Black, Estrada, Coronado, Collins, and Zappa were the original members of the band The Mothers of Invention. Mamma.com is a metasearch site, billed as “The Mother of all Search Engines.” Wendi Shasta Leonardo is the protagonist of Norman Spinrad’s novel Child of Fortune. Katherine Hayles wrote a book My Mother Was a Computer. Douglas Engelbart’s 1968 demonstration at the Fall Joint Computer Conference is always called “the mother of all demos.” Angelina Jolie played the mother of Grendel in the movie Beowulf. Ted Nelson’s mother was indeed Celeste Holme and his father was director Ralph Nelson. Actress Hedy Lamarr holds a patent on spread-spectrum crypto technology. Jobs? Well, if you did LSD, went to India, and became a Buddhist, surely you’re a child of the 60s. Susan Kare designed the Chicago font for the original Macintosh. WikiWiki is the child of HyperCard according to Ward Cunningham himself. “Truth is the daughter of time, not of authority,” according to Bertolt Brecht in his play Life of Galileo. The Daughter of Time is also a novel by Josephine Tey, but you need the Brecht connection to find out who that daughter is. Among the daughtercards of a motherboard (aka Mobo) is almost always a DIMM module.

Calendar
by Jackie Carter
Author sightings and other notable events.

- Nov 2-4, Agile Vancouver
Tutorial: Building a Two-Way Relationship with Coaching; Lean/Agile Project Portfolio ManagementJohanna Rothman, author of Manage It! Your Guide to Modern, Pragmatic Project Management, Behind Closed Doors: Secrets of Great Management, and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

- Nov 5, 757 Studios Conference, Norfolk VA.
Pragmatic Thinking and LearningAndy Hunt. Conference is sponsored by the Pragmatic Bookshelf.

- Nov 6-8, Las Vegas, NV
7th Annual UFO Crash Retrieval Conference

- Nov 7, Bletchley Park, Milton Keynes, UK
ACCU Security Yesterday, Today, and Tomorrow

- Nov 7-8, JSConf.eu, Berlin
“Prototype and script.aculo.us;” “Track B session on Sprockets”Christophe Porteneuve

- Nov 8-12, AYE conference
Topic TBAJohanna Rothman, author of Manage It! Your Guide to Modern, Pragmatic Project Management, Behind Closed Doors: Secrets of Great Management, and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects

- Nov 9-13, Orlando FL
Agile Development Practices Conference 2009

- Nov 9-13, Agile Development Practices, Orlando FL
“Pragmatic Thinking and Learning”Andy Hunt

- Nov 9-13, Agile Development Practices, Orlando FL
Several topics in the testing sub-conferenceJared Richardson, author of Ship It!

- Nov 12, Agile Development Practices Conference 2009
“Focused Continuous Testing”Rod Coffin

- Nov 14, Chippewa Valley Code Camp
“Ruby on Rails: The Third Age”Kevin W. Gisi

- Nov 14, Chippewa Valley Code Camp
“Testing Your Sites in English with Cucumber”Brian Hogan

- Nov 14-15, Greater Boston Chapter of ACM, in Boston, MA
Craig Walls is sharing the stage for two days with Ken Sipe doing an overview of Spring, covering much of the Spring portfolio.Craig Walls, author of Modular Java

- Nov 15-17, International PHP Conference, Karlsruhe, bawue, DE
Topic TBATravis Swicegood, author of Pragmatic Version Control Using Git

- Nov 16-17, Antwerp
“Introducing Scimpi”Dan Haywood, author of Domain-Driven Design Using Naked Objects

- Nov 16-20, Devoxx09, Antwerp
“Pomodoro Technique”Staffan Nöteberg

- Nov 17, Microsoft Tech Days, Calgary Roundup Center
“Test Driven Development Techniques”Jonathan McCracken

- Nov 17-19, Los Angeles
Microsoft PDC09

- Nov 20, Redmond, WA
Microsoft Windows’ birthday

- Nov 20, Italian Agile Day, Bologna, Italy
“SOAP is dead, long live REST”Paolo Perrotta, author of Metaprogramming Ruby

- Nov 22, JRubyConf, San Francisco, CA
JRubyConf State of the UnionCharles Nutter and Tom Enebo

- Nov 22, JRubyConf, San Francisco, CA
“The JRuby Testing Story”Ola Bini

- Nov 22, JRubyConf, San Francisco, CA
Ian Dees has signed up to do a “JRuby Deployment Made Trivial: a Single-jar Sinatra App” lightning talkIan Dees

- Nov 22, JRubyConf, San Francisco, CA
JRuby Core Team PanelCharles Nutter, Tom Enebo, Nick Sieger, and Ola Bini

- Nov 25-27, iCE Amsterdam
Topic TBAMarcus S. Zarra, author of Core Data

- Dec 1-3, Long Beach, CA
Pragmatic Studio, Ruby on RailsDave Thomas and Chad Fowler, author of The Passionate Programmer

- Dec 1-4, Long Beach, CA
Pragmatic Studio, 4 day “how to” for iPhone SDK developmentBill Dudney, author of Core Animation for Mac OS X and the iPhone and iPhone SDK Development, and Pragmatic Bookshelf editor Daniel Steinberg

- Dec 2-3, Agile ’09, Copenhagen
“Pomodoro Technique”Staffan Nöteberg

- Dec 5
ARPANET expanded to four nodes 40 years ago today, while the Grateful Dead played live at Fillmore West

- Dec 3, Online session using DimDim conferencing
“MySQL University: Practical Full-Text Search in MySQL”

- Dec 7-8, XPDay in London, UK
Workshop on “Trust and Project Culture” and she facilitates OpenSpaceRachel Davies

- Dec 10, London Geek Nights, London
“Naked Objects 4.0”Dan Haywood, author of Domain-Driven Design Using Naked Objects

- Dec 10
Ada Lovelace’s birthday

- Dec 16-19, Kochi, India
International Conference on High Performance Computing

- Dec 25, Canada, USA
“The Imaginarium of Doctor Parnassus” opensWriter and Director, Terry Gilliam; starring Heath Ledger, Christopher Plummer, Tom Waits, Johnny Depp, Colin Farrell, Jude Law

- Jan 10
Donald Knuth’s birthday

- Jan 13-15, CodeMash 2010, Sandusky, OH
KeynoteAndy Hunt

- Jan 13-15, CodeMash 2010, Sandusky, OH
“Introduction to iPhone SDK Development;” “How Do You Do That on iPhone?;” “Oh Crap! I Forgot (or Never Learned) C!”Chris Adamson, co-author of iPhone SDK Development

- Jan 13-15, CodeMash 2010, Sandusky, OH
“A Taste of Cocoa” (An intro to Mac OS X development); “Come for the Phone Stay for the Mac”Pragmatic Bookshelf editor and author Daniel H. Steinberg