PragPub 2009-12: Issue #6

Table of Contents

Features

Automating Screencasts

by Jason Huggins

Are you ready for your closeup?

Going Naked

by Dan Haywood

Take a stroll down the Naked Objects path.

Forgive and Remember

by Paul Butcher

Paul offers some advice to make debugging a learning experience.

Our Daily Bread

by Steve Peter

Take control of what goes into this fundamental food and enjoy your own bread fresh from the oven.

Departments

Up Front

by Michael Swaine

Meet the people who make the magazine.

Choice Bits

Tweets, posts, and chatter on programming and life.

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 gets a jump on his January diet with an Agile approach.

The Working Geek

by Andy Lester

For a guy who is fond of saying “Life is too short to work a crappy job,” Andy gives surprising advice in his new monthly column on the working life of a techie.

Swaine’s World

by Michael Swaine

Tell us a story—even if you’re just introducing a new systems language.

The Quiz

This Month: The Return of the Text Sudoku.

Calendar

by Jackie Carter

Author sightings and other notable events.

Shady Illuminations

by John Shade

Google releases a new programming language and John Shade finds a bit of Python in it.

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

It Takes a Team

by Michael Swaine

Meet the people who make the magazine.

Welcome to the December issue of PragPub. There should be something for everyone in this one.

Dan Haywood invites you to go naked, while Jason Huggins argues for dressing up. Steve Peter wants to bulk you up with home-made bread, while Daniel Steinberg wants to put you on a diet. Andy Lester, who usually advises people on how to get good jobs, suggests how to hang onto a bad one. Dave Thomas has our cover process covered, I write about writing, and John Shade ponders whether Google’s Go is a goer. Oh, and I mustn’t forget: Paul Butcher reminds us all to forgive and remember.

But you know, as the year winds down and I put the sixth issue of PragPub to bed, it occurs to me that I have yet to acknowledge all the people it takes to put together an issue. Let me rectify that.

Every member of the Pragmatic Programmers editorial team plays a part in creating the magazine, from writing a regular column (hi, Daniel!) or assembling all the writer appearances for the calendar (Thanks, Jackie!) to catching all the mistakes I missed (ouch, Steve; brutal, Susannah). It’s an honor to work with Jackie Carter, Janet Furlow, Andy Hunt, David McClintock, Steve Peter, Susannah Pfalzer, Daniel Steinberg, Jill Steinberg, Dave Thomas, and Colleen Toporek. And in a further demonstration that distributed teams work, if you need one, we live in over a half-dozen different states and rarely see one another.

And then there are our writers. Over the past six months we have been graced with the words of Chris Adamson, Kent Beck, David Bock, Ed Burnette, Paul Butcher, Rachel Davies, Ian Dees, Frederic Daoud, Scott Davis, Bill Dudney, Chad Fowler, James Edward Gray II, Stuart Halloway, Dan Haywood, Rich Hickey, Dave Hoover, Jason Huggins, Andy Hunt, David Koelle, Andy Lester, Staffan Nöteberg, Steve Peter, Johanna Rothman, Liz Sedley, John Shade, Daniel Steinberg, Brian Tarbox, and Dave Thomas.

In 2010, will we add your name to this list?

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^ | 4 | Agile Web Development with Rails, Third Edition
2^ | 3 | The RSpec Book
3v | 1 | Pomodoro Technique Illustrated
4v | 2 | iPhone SDK Development
5^ | NEW | Metaprogramming Ruby
6^ | 10 | Programming Ruby 1.9
7^ | NEW | Debug It!
8v | 7 | Language Implementation Patterns
9^ | NEW | Web Design for Developers
10v | 5 | Core Data
11^ | NEW | Cocoa Programming

And Here’s What Folks Are Saying…

Getting someone to switch because you offer more of what they were looking for when they choose the one they have now is essentially impossible. — Seth Godin

Ahh, now we learn what is meant by “locked down.” You will only be able to run Google’s Chrome OS on new machines made for it. — Robert Scoble

Kindle versions of non-bestsellers will cost you a lot more than $9 or $10. Try $16. — Shelly Brisbin

Things that are not your father’s Oldsmobile...

Miami installed the first ATM machines for rollerbladers. — Ed Yourdon

AirTran to sell ads on seatbacks. Does this apply to 1st class and Biz class or just coach/steerage passengers? — Roy Robinson

Example from Japan of QRCodes is placing them on Taxi stands. Cell users scan QRCode to get a cab right to them. — Chris Kieff

For those of us who want the convenience of sleeping at the airport... there’s these amazing things right here! “Sleep Box” they go by the name of.... — Chris Burns

Six degrees of bacon...

These Bacon-Flavored Rolling Papers are available individually or in a box of 36. Single packs are $1.95, while the bulk pack will set you back $30. — GearFuse

Do we really need bacon flavored envelop[e]s? — Jason Mosley

Hi all, and welcome to my blog project. I plan to do 365 different nail designs in 365 days.... Today... in honor of my love and devotion for bacon, I chose to do bacon fingernails. — The Daily Nail

In the weeks leading up to our upcoming launch event for J&D’s Bacon Ranch Dip & Dressing Mix, BaconPOP bacon-flavored microwave popcorn and our newest but still top secret invention, we thought it would be fun to take a stroll down memory lane and recap the story of last year’s launch event gone wrong for Baconnaise. Namely, Mayonnaise Wrestling. — BaconSaltBlog

We like to think of it as refactoring...

Twitter ditching suggested users list. — Guy Kawasaki

In a move that continues to shake the Second Life community of content creators, merchants, and consumers, Linden Labs has declared that free virtual content will no longer be searchable without listing payments on their website portal.... — Outland Traveller

Twitter has stopped asking users the completely uninteresting question, “What are you doing?” — Jared Newman

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 generate the different cover images on pragprog.com?

We use book covers all over the Pragmatic online store: on the book pages, in the order summary, on your bookshelf listing, and so on. We display the images in five different sizes, from 40x48 thumbnails up to full-size 72dpi images. And, to make life even more interesting, we overlay those images with variable little icons to show that the book is in beta, that an eBook update is available, and so on.

Being pragmatic (read “lazy”) we didn’t want to manage all those combinations manually, so Mike Clark and John Long cooked up the software and CSS to make it all automatic.

It all starts on my desktop machine, where I use InDesign to create the covers that I’ll send to the printer. As a part of that process, I export full-size 72dpi and 300dpi JPEG versions of the front cover. Our production folks check these images out of our repository and upload them to our admin system.

Perhaps surprisingly for those used to modern Rails, we don’t use a library such as PaperClip to do this upload. Even if it had been around when we wrote the store, we do enough custom processing that I’m not sure it would have added much value. Instead we just use a raw file_field_tag to upload the full-size JPEG.

We save the original covers away—you can view them by clicking on the large cover image on the main page for each title. We then feed the cover through ImageMagick to create the scaled versions. We could have done this using library calls, but we were concerned about reported memory leaks, and so preferred to shell out:

| def create_all_sizes
| base_name = File.basename(path_to_original)
| geometries = ['40x48', '75x90', '120x144', '140x168', '190x228']
| geometries.each do |geo|
| FileUtils.mkdir_p(File.join(COVERS_DIRECTORY, geo))
| cmd = "convert -resize #{geo} #{path_to_original} " +
| "#{COVERS_DIRECTORY}/#{geo}/#{base_name}"
| system cmd
| end
| end

Next, we create the versions of the covers that have the eBook, beta, and the PDF-out-of-date stamps. There’s a version of each stamp for each different cover size (we tried scaling them down from a large master, but they looked horrible). Here’s the code that generates the two sizes of cover with the eBook stamp:

| def create_ebook_overlays
| # small_ebook
| create_cover_with_overlay(
| :overlay => File.join(IMAGES_DIRECTORY, 'ebook-28.png'),
| :file => path_to_small,
| :output_dir => File.join(COVERS_DIRECTORY, '40x48', 'ebooks'))
| # medium book
| create_cover_with_overlay(
| :overlay => File.join(IMAGES_DIRECTORY, 'ebook-46.png'),
| :file => path_to_medium,
| :output_dir => File.join(COVERS_DIRECTORY, '75x90', 'ebooks'))
| end

The code that does the overlaying uses some RMagick magic:

| def create_cover_with_overlay(options)
| FileUtils.mkdir_p(options[:output_dir])
| base_name = File.basename(options[:file])
| images = Magick::ImageList.new(options[:file], options[:overlay])
| x_offset = images[0].columns - images[1].columns
| y_offset = images[0].rows - images[1].rows
| images[1].page =
| Magick::Rectangle.new(images[0].columns, images[0].rows,
| x_offset, y_offset)
| images.
| flatten_images.
| write(File.join(options[:output_dir], base_name))
| end

A little processing up front, and we have 16 versions of a book cover all ready to serve in the store. A wee post-deploy hook symlinks the master covers directory into the application each time we update it.

Dave Thomas is one of the Pragmatic Programmers.

Get a Life

Holiday Eating

by Daniel Steinberg

Daniel gets a jump on his January diet with an Agile approach.

Every once in a while I catch myself doing things just because it’s “that time of the year.” I put together a summer reading list in June, think about what my wife should plant in our garden in April, and in turn she prepares my New Year’s resolutions in time for the first of the year.

I reserve the time between Thanksgiving and New Year’s Day for indulging in unhealthy snacks eaten between overly large meals. This five weeks of unhealthy conditioning gets me in shape for the start of my yearly diet in January. It also helps set me up for certain failure.

That’s why I’m starting my diet now.

I know that’s just crazy. No one starts their diet now. You wait until New Year’s Day. No, wait a minute, I’ve got plans for New Year’s Day, I’ll start on the second. Then again, what day of the week is that. You can’t just start a diet any old day—you have to wait until Monday. If you’re going on a diet you need time to eat the foods you’re going to be giving up.

This is not that sort of diet. That sort of diet is a Waterfall diet. That’s the diet with big up-front planning and a delivery date. That’s the diet where you need to lose a certain number of pounds by your next class reunion, or by summer, or before your birthday. That’s the diet that tends to fail.

It’s funny. We know this from our experience with software projects by now and yet we haven’t really moved the things we’re trying to accomplish in our lives from Waterfall to Agile.

In an Agile diet, we have small, achievable goals. These are user stories that we can test to see whether or not we did them. They must be tasks we can totally control. In most diets you set goals based on how much weight you want to lose this week or month. You can’t directly affect that. That’s not a task you will set in our Agile diet. You’ll set a task such as “I will eat oatmeal for breakfast every day this week.” Success or failure with this task is completely within your grasp. You can measure how you did.

You still may be skeptical about starting a diet at this time of year. You don’t want to give up all of the holiday parties and feasts. Don’t worry. You won’t be. We’re going to start out slow. We’re going to take little steps, and when January first comes we’ll just keep going, tweaking little by little as we go.

Last month PragProWriMo was a great success. Many of you spent the month writing eighty pages of a non-fiction book. I used the Prag Life blog to provide daily tips and reminders. I didn’t nag. I’m not going to nag you every day about your diet, either. Each week I’ll introduce our goals for the week and invite you to comment on how things are going for you.

We’ll begin the Agile diet with the simplest but most important of goals: log what you eat. Write down everything you put in your mouth. This first week, I am not asking you to eat less or even to change what you are eating. Just write it down.

How’s that for a diet?

The second week we’ll start to ask “do I want to eat this” before we eat anything. If the answer is “yes,” then eat it.

Simple, small, measurable steps. Steps that you can take and practices you can continue forever. You’re not eating something unusual or giving up all of the foods you love. You won’t lose weight as quickly as you might on a more traditional diet, but you’re also more likely to stay on it.

I’m going to try to lose some weight on my diet but there are plenty of other kinds of diets. I’ve started diets where I’ve tried to eat “closer to the ground.” I won’t buy strawberries in December because they don’t grow near me in December. I try to support local farmers and think about where my food comes from. I’ve started diets where I notice just how much coffee and pop (depending on your part of the country you may call this “soda” or a “soft drink”) I’m drinking. Anything that Kimmy-the-wonderwife’s doctor told her not to drink during pregnancy is something we probably should drink less of.

In fact, let’s broaden diet a bit more to include physical activity. I could resolve to walk the dog twice a day or to work my way up to jogging two miles.

Whatever I decide to do, it must be something I can resolve to do for the next several years if not the rest of my life. I’m sure you could devise a diet based on eating nothing but yogurt and hot dogs, but you couldn’t stay on it for very long. Don’t start any diet you can’t foresee yourself staying on for at least half a year.

You can even wait until Monday to start, but I’d really like you to stop somewhere today and pick up a small notepad you can carry with you, and start writing down everything you eat. You don’t even need to wait until morning. You can start right now. Join us at praglife.com.

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.

The Working Geek

Keeping the Job You Don’t Like

by Andy Lester

For a guy who is fond of saying “Life is too short to work a crappy job,” Andy gives surprising advice in his new monthly column on the working life of a techie.

“Keeping the job you don’t like?” That’s probably not advice you’d expect from the author of Land The Tech Job You Love, but right now, that might be what you need to do.

Jobs are down. The economy sucks. And on top of that, we’re going into the season of the year when it just doesn’t make sense to try to go get another job. It’s in times like these that you may just need to muddle through as best you can, while trying to keep your sanity. This month, I’m offering you some advice on how to do that.

Keep Your Current Job

My most important piece of advice is, don’t quit in a snit. Even when the economy isn’t in the middle of a terrible hiring slowdown, it may take you months to find your next job.

If you can possibly avoid it, don’t quit in the wrong season. The holiday months of November and December are the toughest time to land a new job. One November I quit a job at a company where I was very unhappy. I knew I had saleable skills, so I figured I’d get another job no problem.

That bit of impulsivity cost me big, not only because I didn’t have another job lined up, but also because December is the worst time to try to get anything done in business. It’s bad enough in the best of times trying to wrangle meetings and interviews with multiple people, but around the holidays when so many people are off on vacation, it can be next to impossible. I spent the month of December waiting for my future boss to be able to push approval to hire me through Human Resources. If only I’d stuck it out at the old place, I’d have been frustrated but at least I’d have been getting paid.

Identify the Source of Your Frustration

Once you’ve resolved to stay put (for now) for the sake of your finances, start examining the problems that you’re up against. What is it that makes your situation unbearable? What specifically drives you nuts? Usually job frustrations lie in one of three areas: projects, people, or the place.

If your frustrations are mostly about the projects you’re doing and the type of work that these projects involve, there’s good news: these are usually the easiest to handle. Even the worst death march project has to end sometime, and you can keep your eyes on the light at the end of the tunnel.

When the problem is with the type of work you’re doing, such as having to work in PHP when your heart belongs to Ruby, consider ways to get future projects headed in a more appealing direction. If you think using Ruby would be a better choice, help move the development direction of the group. Of course, it’s not enough just to say “We should use Ruby.” You’ll need serious plans and solid evidence to help change the group’s direction. But it can happen. Just don’t expect it overnight.

People issues are the most acute. If you’ve got a jerk co-worker, you may dread the prospect of going to work and having to deal with him. Worse, these jerks tend to amplify the jerkiness of other jerks. They feed off the negativity of one another.

The good news here is that people problems are usually short-lived, because people come and go at organizations all the time. Don’t fall into that drama trap of trying to “get someone fired,” and don’t try to get out of having to work with the jerks. This will come across as antisocial behavior on your part (which it is), and that’s not good for business. The jerks usually get pushed out or leave. In general, don’t leave a job because of a single person that is a problem.

Organizational problems are the ones where you actually should consider leaving, because they rarely get fixed. The problems infect the company as a whole, not just part of it. For example, having an obnoxious co-worker who doesn’t get any work done is certainly a problem, but is probably an acute one. However, if the company tolerates it, the problem is organizational.

How can you tell if you’re in a bad company? Consider some of these questions: Is the company successful at what it does? What do they value, as evidenced by the projects they pursue? Is everyone a jerk, or just a few people that you’re currently frustrated with? Does the company have a strategy, or is management shooting from the hip?

If your problems are not truly organizational, seriously consider riding out the current wave of annoyance and frustration.

Improve Yourself

So you know you’re sticking at the job, doing the work as best you can. You want to go somewhere else, but not now. The upside to look for here is that you are in an ideal position to start improving yourself.

OK, maybe not ideal. Chances are that if you’re in a job you don’t like, it’s not a job where you’re given time for training or working on fun little side projects, so you’re going to have to take that time out of your own life. It might not be how you want to spend your evenings, but the responsibility is still yours for your own career.

The number one way to improve yourself is by learning a new technical skill. It might be as simple as picking up a new Perl module from the CPAN or investigating a new sysadmin log analysis package. It could be as complex as installing BSD when you’ve only used Linux, or learning Google’s new Go language. Whatever it is, learn it, then start using it.

If self-improvement like that is too daunting, at the very least pick up a book on a new subject and read it. I mean actually buy a book. Recognize that you are making an investment in yourself and your future, not just reading Slashdot. I also suggest that you buy a physical ink-and-paper copy of the book because they’re harder to ignore then a PDF file on your book reader of choice. Don’t just read the book, either. Read it, take notes in the margins, and think about the cool concepts that you’d like to apply to your working life.

Start a Side Project

The first place to start using these new skills, and thus improving yourself and your chances of getting a better job, is on your regular day-to-day work. This may mean that you have to pick less adventurous projects, but it may be worth it to get in practice.

Start a little side project that helps you in your daily work life, even if it’s not officially sanctioned by your boss. The key is to pick a tool that you’ve never used before, and apply yourself to getting it working.

Write a tool in Ruby to manage your time tracking.

Use a backup tool like Amanda or Bacula to back up your workstation to a separate machine.

Start using Git to sync your home directories across multiple machines.

In all these cases, you’re improving your work life and learning at the same time. You’re going to learn much more writing a tool with Ruby than you would just reading a book, and a tool is easy to justify to your boss. (When I wanted to learn COBOL back in 1989, I wrote a Star Trek game. Yes, it was painful.)

Side projects like this may also get you out of the rut you find yourself in. Maybe you’re not getting all that much job satisfaction slogging away on CRUD apps or wiring cabling. Maybe that job that’s “20% sysadmin / 80% programming” is more like 80/20. Working on a project for self-improvement may help your outlook on the rest of the job.

These little side projects are also an excellent way to get traction for new technologies. Maybe your boss has been wary about Ruby as a language, but if you can show a new tool that you created, and can show how easy it was to do with Ruby, you’ve got a big selling point. Nothing succeeds like success.

Best of all, working on side projects to grow your skills shows your current boss—and future employers—that you take initiative and like to solve problems. Whatever you decide to work on, consider adding it to your résumé as an achievement.

Find Your Next Job

Far be it from me to encourage you to stay indefinitely in a job you don’t love. Even as you’re staying employed and drawing a paycheck, you’ll probably want to be looking for another job. Just make sure you don’t do anything to jeopardize the one that’s paying you.

The first rule of job hunting is: Never bring your job hunt to work with you. That means not surfing job boards, not printing résumés, and not sending out hunt-related email on company time. Never mind the ethics of searching for a new gig while you’re getting paid by your current one, doing your search at work is likely to bite you. Murphy’s Law dictates that even if you surf Monster “just for a minute,” someone’s going to see you doing so, or you’ll leave a résumé on the printer, and word will get around. Keep it at home, or at the very least on a device not owned by the company.

Networking at work is also a dangerous proposition. Interpersonal connections are the best source of job leads you have, but it can be risky to use co-workers as potential contacts. Telling a co-worker that you’re looking for a new job raises the potential of him letting it slip to the wrong person. Best to keep your networking out of the workplace.

Instead, increase your visits to user groups and technical seminars. Make a point of spending more time reading mailing lists and online boards, and especially answering questions. Building a reputation as someone knowledgeable in a specific area can pay huge dividends in opportunities later.

Some of you reading this might be thinking “but I’m not a very social person!” That may be, but it’s something you’ll need to overcome if you’re going to get an edge on the other job seekers out there.

Stay Sane

Most of all, keep yourself sane. Chances are that the frustration of an unsatisfying job is still going to be less than the frustration of not being able to find a new job. It certainly pays better.

When things get really frustrating and you’re about ready to chuck it all, look at your job in simple dollar figures. Figure what you’re getting paid for an hour of time. Divide your yearly salary by 2,000 to get your hourly rate. If you’re making $60K/year, you’re making $30 an hour. If someone on the street offered you $30 to sit and be bored for an hour, you’d take it, right?

Improve your skills and start a side project to exercise them. Keep your job while looking for the next. Things will improve and you’ll find a job that you love.

Andy Lester has developed software for more than twenty years in the business world and on the Web in the open source community. Years of sifting through résumés, interviewing unprepared candidates, and even some unwise career choices of his own spurred him to write his nontraditional book on the new guidelines for tech job hunting. Andy is an active member of the open source community, and lives in the Chicago area.

Swaine’s World

How I Wrote a Novel in 30 Days (Maybe)

by Michael Swaine

Tell us a story—even if you’re just introducing a new systems language.

As if I didn’t have enough to do.

Enough writing to do.

Granted, over the past few years my to-do list had expanded beyond writing. For years before, nearly all the items on my to-do list had been in the categories of writing, editing, and research. I’m not complaining; just the opposite. It was Confucius, a quick Internet check tells me, who said, do something you love and you’ll never work a day in your life. That’s me. I love writing and editing and research.

But I’m not complaining, either, about the change my life took a few years ago, when my partner Nancy moved us to Oregon, where she took on the running of a farm and restaurant (and now a bakery). A few supportive chores fell to me, so now my to-do list includes items like:

Let chicken out in field and gather eggs

Edit and post employee blogs to website

Process online gift certificate purchases

Tend bar

Still, most of my work time on any given day is writing, editing, or research, just as before. So, according to Confucius, I’m not working a day in my life. But that doesn’t keep my to-do list from growing to unmanageable lengths. I love my work, but it fills my days.

So when I committed to write a novel in thirty days I must have been crazy.

NaNoWriMo

NaNoWriMo, or National Novel Writing Month, takes place every year in November. Tens of thousands of people take part. Participants begin writing on November 1, and the goal is to write a 50,000-word novel by midnight, November 30. One thousand six hundred sixty-seven words a day, on average.

I’d been kicking around some ideas for a mystery novel for years. Why not, I thought, use NaNoWriMo to push me to get something done on it? It could be just the motivation I needed. Of course, motivation without a plan of action is like fuel without an engine, or like that line in “Baby You Can Drive My Car”:

| I got no car and it’s breakin’ my heart,
| But I found a driver and that’s a start.

I had my driver: NaNoWriMo. Now all I needed was a car. I needed a plan.

With the right plan, surely I could fit another 50,000 words of writing into my schedule without adversely impacting my regular work. Surely.

In my many years of writing, I’d come across a lot of writing techniques and tricks that I knew from experience actually had value. I just needed to pick the right techniques, the right plan, for this particular project. I narrowed it down to three.

Pomodoro Technique

I was actually using the Pomodoro Technique for some of my writing and editing. I wouldn’t say I’d mastered it, but I was exploring it and finding it useful. Could I use Pomodoro to write the novel?

“The Pomodoro Technique,” its creator Francesco Cirillo explains, “was created with the aim of using time as a valuable ally to accomplish what we want to do....” It encourages you to see time in a different way, as a natural succession of events rather than as a river rushing past you. Staffan Nöteberg wrote about the technique here last month.

Ultimately, I couldn’t see how to apply Pomodoro to the project. I could see that I needed to generate a certain amount of copy (1600-plus words) every day to have a hope of finishing. My mind would be on that word count, and that didn’t seem to fit well with the Pomodoro Technique’s focus on simply working productively for the next n minutes. My short-sightedness, I’m sure.

800-Word Scenes

This is a technique I picked up from science fiction writer A. E. Van Vogt, who got it from somebody else. Van Vogt claimed to write all of his novels and stories using scenes of (more or less) 800 words.

Van Vogt was a self-described systems person; he constantly sought out systems to organize his life and work, from the Bates eye exercises to Dianetics. Throughout his writing life, he had himself awakened every ninety minutes during the night so that he could record his dreams and use them in his writing. I wasn’t going to emulate that, but his 800-word scene system looked like a good idea, especially given that two 800-word scenes would just about meet my daily word-count quota.

And there were other reasons to embrace the 800-word scene. It seems to be a good minimum length for establishing a setting, the characters involved, the problem, some development, and an outcome, whether it is a resolution or a cliff-hanger. It also seems to be enough for a reader to swallow in a single gulp. And I’ve always thought that it was one of the secrets of Van Vogt’s popularity. His writing was far from perfect: one editor even built his reputation as a critic on tearing Van Vogt’s writing apart. But somehow it resonated with readers, and I think it was partly because of the pacing those 800-word scenes gave his work.

So I’d do 800-word scenes.

But there’s a huge gulf of structure between 800 words and 50,000. I needed a technique for structuring the novel as a whole.

I’ve used a lot of different techniques for structuring writing, but one that I thought might work well for this novel was to scrupulously follow Jon Franklin’s advice on how to write for story.

Writing for Story

In his book Writing for Story: Craft Secrets of Dramatic Nonfiction by a Two-Time Pulitzer Prize Winner, Jon Franklin shows how to use fiction techniques to write nonfiction. But Franklin’s approach would work as well for fiction as for nonfiction, and I was familiar with it. I thought I could see how to use it to structure the novel I’d been thinking about.

The idea that fiction techniques could be relevant to nonfiction writing will not be news to writers of Pragmatic Bookshelf books. Dave Thomas has pointed out that technical writing can have a narrative. A good technical book can follow a Hero’s Journey.

Franklin spells out a—dare I say—formula for writing stories, whether fiction or nonfiction. And it actually works: follow his formula and you are going to produce a well-structured, engaging story. Seriously. Franklin’s technique doesn’t take any of the work out of the process, but it ensures that you’re headed toward your goal rather than wandering in the narrative wilderness.

There’s a lot to Franklin’s method—he wrote a whole book about it, after all—but the core of the method is the outline. Not just any outline, though, and most definitely not the kind of outline you were taught to come up with in that expository writing class you took in college. Franklin means something very specific by outline. He means:

A meaningful complication that confronts a sympathetic character.

Three developmental focuses, in which the story is developed.

The resolution of the complication.

Each of these five outline components (complication, three developmental focuses, resolution) is a focus in Franklin’s terminology. The idea is the same as the focusing that a filmmaker does in zooming in on a face in a crowd. But Franklin talks about focuses at several different structural levels. At the lowest level, like the filmmaker’s zoom, the focusing of the audience’s attention is obvious. But even at higher structural levels in a piece of writing there is an analogous focusing of attention, and that’s what he’s talking about here. The outline is a device for focusing the audience’s attention.

Each of these focuses also has to meet certain strictures. Each should be a subject noun-verb-object noun clause, with a strong active verb and the protagonist in either the subject or object position. The resolution must clearly resolve the complication. Each developmental focus has its own role: the first, for example, is the only place in the structure where you can place a flashback. Anywhere else it will be too jarring. I can’t do justice to the method here, and have even simplified what I’ve presented, but this example should give the flavor of the desired outline (modified from Franklin):

Complication: Company fires Joe.

Developmental Focus 1: Depression paralyzes Joe.

Developmental Focus 2: Joe regains confidence.

Developmental Focus 3: Joe sues company.

Resolution: Joe regains job.

If this sounds trite, it should. Franklin points out that when you are dealing at the structural level of a story, what would be a cliché at the sentence level becomes something more universal. Good outlines look sort of simple-minded.

This structure works for anything from a brief article to a long book, but for longer lengths, like my novel, you need to introduce sub-complications, with their own developmental focuses and resolutions, inside the developmental focuses of the main outline. Same basic structure, just recursively elaborated.

So I had a plan: at the day-to-day level, I’d write (roughly) 800-word scenes, and finish (on average) two per day. At the structural level, I’d sketch out, and refine as I went, a Franklin-model outline for the novel, and check each day that I was following the plan.

Finding My Structure

I developed my outline in parallel with writing the scenes. That sounds wrong, but you can imagine how it worked by reflecting on your software development experience.

It might help if I actually show you the structure I was developing, as it appeared ten days into the month. It was changing every day, but on November 10, it looked like this:

Major Complication: Killer challenges Ralf.

Semimajor Complication: Ralf seeks Weasel.

Developmental Focus 1: Ralf begins search.

Developmental Focus 2: Ralf develops leads.

Developmental Focus 3: Ralf narrows search.

Interlocking Complication: Police charge Roman.

Semimajor Resolution: Ralf finds Weasel.

Semimajor Complication: Police charge Roman.

Developmental Focus 1: Landis represents Roman.

Developmental Focus 2: Ralf deepens investigation.

Developmental Focus 3: Ralf closes in.

Interlocking Complication: Ralf pursues killer.

Semimajor Resolution: Ralf clears Roman.

Semimajor Complication: Ralf pursues killer.

Developmental Focus 1: Paintings trouble Ralf.

Developmental Focus 2: Ralf pursues killer.

Developmental Focus 3: Killer threatens Ralf.

Major Resolution: Ralf catches killer.

Ralf is my protagonist. What any story needs to do is to get a sympathetic protagonist into and out of trouble. A good reason to write a how-to article as a second-person story is that you automatically have a rich and interesting sympathetic protagonist. Everybody wants to read about themselves.

Despite appearances, the basic structure of this novel is simplicity itself: Killer challenges protagonist, protagonist pursues killer through several steps, protagonist catches killer. That’s the structure of virtually every murder mystery. Within this outer story there are three sub-stories: the novel has an episodic structure typical of sagas or Hero’s Journeys.

Finding My Schedule

With techniques borrowed from Van Vogt and Franklin, I thought I was prepared for managing the novel itself, but there remained the parallel challenge of managing myself. If I were to be able to devote the required time to this novel without it adversely impacting my regular daily work, I needed a schedule. And years of experience had taught me that it needed to reflect the realities of my life and metabolism.

What I figured I could give to the novel were my evenings, early mornings, and the odd moments of inspiration throughout the day. The rest of my day belonged to my regular work. I built a writing schedule based on those constraints.

After dinner every evening, I wrote. I wrote with a pen on a yellow pad, lying on the couch watching The Daily Show or House or some NetFlix selection. The following morning before I walked the dog or gathered eggs or combed my hair, I keyed in what I had written the night before. I also entered any changes I’d come up with the day before to the outline, read what I’d typed, fixed typos, and recorded the day’s word count.

During the day, whenever inspiration struck, I wrote down thoughts about the next two scenes I’d need to write that night, or about the outline. Because I only did this as ideas came to me, I rarely gave this process more than half an hour out of my day. There were two things that I tried to accomplish in the course of the day: to come up with half a dozen key points that had to be covered in each of the next two scenes, and to develop my thinking about the current sub-story or about the novel as a whole. But it was in the back of my mind all day that I needed to be ready to start writing those two scenes the minute I picked up the yellow pad that night.

Progress Report

So how did it work? I can’t tell you. As I write this, I’m only a third of the way through the month. But I can give you, as I have given myself, a status check.

On Wednesday, November 11, after keying in the previous night’s writing and correcting a few typos, I did a word count. 16668 words.

Although it was the morning of the 11th, I counted it as the 10th, since I had done the writing the night before. Ten days out of thirty: one-third. One-third of 50,000 words: 16666-2/3. I had cleared the bar by 1-1/3 words.

Will I complete this 50,000-word novel by November 30? Only time will tell, but I know as I write this that I’m on track.

Now whether it’s readable or complete garbage, that’s another question altogether. Time will tell about that, too.

Afterword

This story would be more interesting if it had some implications for nonfiction writing of the sort we publish in our books and in PragPub. I think it has, and that, I guess, is the moral of the story. Jon Franklin’s approach is based on fiction but intended for nonfiction writing, and I used it to write this column. Here is my Franklin-style outline for this column:

Complication: Novel challenges Mike.

Developmental Focus 1: Mike explores techniques.

Developmental Focus 2: Mike implements technique.

Developmental Focus 3: Mike implements schedule.

Resolution: Mike finishes novel.

I also used the Pomodoro Technique in writing this column, but if I told you how many Pomodoros the writing took, Dave and Andy would want to cut my salary. Because that statistic wouldn’t include all the false starts and discarded drafts that I went through before I found my approach. And that’s part of writing, too.

Michael Swaine is the editor of PragPub.

Automating Screencasts

There’s no longer any reason for screencasts to be hard to create or boring to watch.

by Jason Huggins

Are you ready for your closeup?

One simple question underlies all software testing: “Does the app work?” Answer that question, and you’re done. Simple, right?

Five years ago, I created Selenium as an answer to that “simple” question. Selenium is a toolkit for testing the functionality of web applications. I use it to write scripts that click and type their way through an online process just as a user would. Selenium lets me watch all the tests run in real time, in a real web browser, giving me the confidence that everything truly is working as a user would expect it to. Automating all these tests lets me push new code to production with a reasonable amount of confidence that I won’t be embarrassed with breakages in features that I thought were working yesterday.

Scaling Up

For the past three years, I’ve worked on the scaling problems that appear when a project has many Selenium tests to run. The common complaint is that a large test suite is too slow—although the definition of “too slow” varies widely. Some cry foul after two minutes, others after two hours. The pragmatic solution is to throw more hardware at the problem. If you have 60 tests, instead of running all the tests in sequence on one machine, find 60 machines and run all the tests in parallel, one test per machine. With this new parallelism, you get the results in one minute instead of one hour—a huge boost in productivity.

Well, maybe. But parallelism comes with its own unique problem—finding and maintaining those 60 machines is not easy. This is a problem that cloud computing services, like Amazon EC2, elegantly solve. As a test engineer at Google, I worked on a similar solution on the “Selenium Farm,” providing access to a large number of machines for the Google Apps and Gmail teams to run their tests in the fastest way possible. And I’m now applying those same techniques in my own startup, Sauce Labs, with the goal of enabling all developers to not have to worry about scaling or maintaining their own cloud of test machines.

So let’s see, you’ve got that confidence-boosting assurance that comes with automated functional testing, and you are getting your test results fast. You now have no more software testing problems to solve, right?

Well, there is a problem in software testing that not enough people are consciously aware of. Software tests, especially the log files and reports they generate, are boring. How lame is it to run a suite of 60 tests that ultimately creates a plain-text log report saying “60/60 tests passed. OK.” Yawn. Instead of that, do something cool with those tests, and get people excited about your software.

The Cure for Boredom

Screencasting is one such technique for getting people excited about software. Screencasting was popularized by David Heinemeier Hansson in 2004, when he created a screencast [1] for his new web framework, Ruby on Rails. Scads of developers have watched this video, where he creates a complete database-backed blog in less than 15 minutes. There were many innovations revealed in Rails at the time, but using a screencast to market software was something no one had done so effectively before. In the wake of Rails’ success, screencasting has gone from a novel nice-to-have to de rigueur software practice.

Screencasting as a software practice is following an adoption path similar to that for test automation. People are creating screencasts to show off their apps today, but screencasting is still mostly a manual activity done with expensive tools by a few people late in the development cycle. Just as test automation became more common as the tools got more capable, less expensive, and easier to use, I expect the same thing to happen with screencasting.

I hope to see software testing move in the direction of the way Apple markets the iPhone. An iPhone commercial is a short, 30-second movie showing off the phone just doing its thing. [2] Open an app, type, click, do something, then exit—that’s it. And that’s all test automation is, too. But as developers, we don’t dream of transforming our tests into miniature Hollywood screenplays for producing snazzy 30-second commercials showing off our cool applications.

I think we should.

Automating Screencasts

If you were to combine user interface test automation tools (like Selenium) with screencasting software, you could automate your screencast videos. Each time your code changed, so could the video demos you create to show off each feature. As each screencast is combined with a test framework, screencasting can become an everyday activity, available to the entire development team.

Let’s take a look at how they do it in Hollywood.

On a typical Hollywood film set, the day’s raw film footage, aptly called “dailies,” is gathered up for viewing. Dailies primarily function as an aid to directors, so they can make sure they got the right shot. But they also have other benefits, as Wikipedia explains:

“Dailies are also often viewed separately by producers or movie studio executives who are not directly involved in day-to-day production but seek assurance that the film being produced meets the expectations they had when they invested in the project.” [3]

Similarly, with automated video clips showing off all the features in your app, your software project’s sponsors (e.g. your boss, your investors, and your customers), like those movie studio executives, will be happy to see your progress even when they’re not “on the set.”

Great Minds Think Alike

I’m not the only one to think about the implications of combining automation and screencasting. Jon Udell, who coined the word “screencast,” [4] wrote in a 2007 blog post titled “From screencasting to automation” that he sees a huge benefit in having a screenplay script to go along with screencasts:

“Today, I can share software-related task knowledge in a social manner by creating and posting screencasts. But you can only watch a screencast. If I could instead share that task knowledge in the form of standardized high-level scripts, you wouldn’t need to watch the screencast. Of course, you might want to, for other reasons, but not simply to get the procedural knowledge transferred from my brain and fingers to yours.

“Given how popular screencasts have become in three years, I’ve got a hunch that taking things to that next level would be huge.” [5]

I’ve found several independent implementations of the automated screencast idea. In 2006, Manfred Stienstra, a web developer at Fingertips in the Netherlands, used his “Screenager” [6] to show off some features in Rails’ ActiveSupport::Multibyte library in a simulated interactive Ruby session. The most complete implementation of the idea was created in 2008, by Joseph Pearson at Inventive Labs in Australia. Called “Castanaut” [7], it combined Ruby scripting, screencasting software iShowU, and Mac OS X’s built-in Text-to-Speech engine to add voice-over narration. A sample movie [8] and the screenplay [9] used to generate the movie are available online.

From my own research, I concluded that having an easy-to-use, cross-platform, open source screen recording library was one of the key missing pieces for easy screencast automation. So earlier this year, I released “Castro” [10], a small fork of another library called pyvnc2swf [11] by Yusuke Shinyama at New York University. Pyvnc2swf acts as a remote desktop client, and works by connecting to a running VNC server. Instead of showing the remote desktop to your screen, Pyvnc2swf records the screen to a flash swf file or the more popular flv flash video format. The specific improvement Castro brings to Pyvnc2swf is the ability to start and stop recording programmatically via a simple Python API. Castro also includes cleanup routines needed for posting videos online on your own site in Flash video players like FlowPlayer or JW Player. In the future, I’d like to add more APIs for mixing in music, narration using text-to-speech engines, subtitles, and other demo-specific features.

Here’s How It Works

Armed with Castro, you have everything you need to create your own automated screencast. It can be as simple as:

Install and launch a vncserver. (Hint: Google it.)

$ [sudo] easy_install castro

Write a simple Python script:

| from castro import Castro
| c = Castro()
| c.start()
| # Do something awesome!
| c.stop()

Of course, you would replace “# Do something awesome!” with your own code, which could be a Selenium test you want to record.

Take a Look

For this article, I wrote a test script that shows how you can convert a simple Google search into an automated screencast. The test script is written using the Selenium 2.0 API. In Selenium 2.0, the WebDriver project is merging with the Selenium project.

The video can be viewed online, as can the screenplay that generated the video. I still had to manually upload the video to Vimeo. Perhaps you can help me improve Castro to automatically upload to video services like YouTube and Vimeo?

At Sauce Labs, we use Castro to record a video of every Selenium test run in our cloud. (And we’ve now recorded hundreds of thousands of tests in production.) We’re just at the beginning of what we can do in this space, but already, customers have embedded these video results into their continuous integration systems. When the tests fail, the videos serve as debugging aids. When the tests pass, the videos give visual confirmation the features work as designed.

With tools like Selenium and Castro, plus a little imagination, you now have the power to transform “plain old tests” into something far more exciting and even more useful. And from now on, remember, you’re not a “tester” anymore, you’re a “screenwriter.” If screencast automation catches on, they’ll need to create a new Emmy Award for test automation.

References

[1]: http://media.rubyonrails.org/video/rails-0-5.mov

[2]: http://www.youtube.com/watch?v=8kwmEIctuUw

[3]: http://en.wikipedia.org/wiki/Dailies

[4]: http://jonudell.net/udell/2004-11-15-name-that-genre.html

[5]: http://blog.jonudell.net/2007/11/13/from-screencasting-to-automation/

[6]: http://www.fngtps.com/2006/10/screencast-scripting

[7]: http://gadgets.inventivelabs.com.au/castanaut

[8]: http://art.inventivelabs.com.au/castanaut_demo.mov

[9]: http://pastie.org/150567

[10]: http://pypi.python.org/pypi/castro/

[11]: http://www.unixuser.org/~euske/vnc2swf/pyvnc2swf.html

Jason Huggins co-founded Sauce Labs and currently leads product direction. Prior to Sauce Labs, Jason was a Test Engineer at Google where he supported the grid-scale “Selenium Farm” for testing Google applications such as Gmail and Google Docs. Jason’s experience also includes time at ThoughtWorks in Chicago as a software developer. While at ThoughtWorks, Jason created the Selenium testing framework out of the need to cross-browser test a new in-house time and expense system. When not programming in Python or JavaScript, Jason enjoys hacking on Arduino-based electronics projects. Jason has spent time in New York City, LA, and the Bay Area, but Chicago is his kind of town.

Going Naked

Get Down to Business with Naked Objects

by Dan Haywood

Dan reveals all the secrets of Naked Objects.

Naked Objects is a Java framework that lets us build enterprise applications from the domain model out. Dan makes the business case for Naked Objects and walks us through what it’s like to go Naked.

If, like me, you spend your working time developing enterprise applications then I’m sure you’ve encountered the layered architecture: presentation, application, domain, and infrastructure (or persistence). Separating out these concerns gives us modular, maintainable applications.

Now of these layers, the bit that matters most to the business is the domain layer; after all, it’s the domain model within that distinguishes our business from our competitors. Sure, the app has to look nice, and has to handle transactions and workflow and stuff, and of course the data needs persisting somewhere, and we may need to integrate with other systems in the enterprise … but these are all supporting functions, not ends in themselves.

No. What the business stakeholders want when they pay for an enterprise app is something that reflects their way of doing (or wanting to do) business. It should automate the mundane stuff, and also handle any complex rules, while providing enough flexibility to let the app’s end users exercise their discretion for edge cases. That’s quite a high bar.

Building an app the traditional way requires us to implement all of those layers, but of course that means it’ll take us that much longer to implement a user story to demo to the business. Slower velocity means it’s gonna take us longer to discover the critical insights into the domain, as well as more to rework if we discover we were going down the wrong track.

Worse still, it’s easy to misplace logic that should be in the domain model into those lovingly hand-crafted presentation and application layers. Not only have we broken the modularity we were aiming for, that demo to the business isn’t really demonstrating the domain concepts, because they’ve been distorted or obscured by the layers above.

What to do?

The Hexagonal Architecture

The trouble with the layered architecture is that it makes us think of one layer stacked on top of another. A few years back Alistair Cockburn came up with an alternative view, which he originally called ports and adapters, but is more often called the hexagonal architecture [1].

The hexagon emphasizes the fact that there are multiple entry points—or ports—both into the system and out of it. The presentation layer adapters use the primary ports, while the secondary ports allow the system to interact with the adapters in the infrastructure layer. So for example an HTML viewer adapts the application for use over the web.

With this approach, we can start focusing on the domain model without getting distracted by the other layers. We can use FitNesse [2] or other agile acceptance-testing tools to exercise the system from the application layer down, without getting bogged down by widgets, data transfer objects, and all that other stuff that comes with the presentation layer. And we can switch out the RDBMS, with all the hassle of dealing with database schemas and managing data, for a simpler implementation, say an in-memory object store.

So where does that leave us?

Well—if you’re on the same page as me—it leaves us looking for something to take care of all that stuff for us and let us focus on the domain model. Obviously that would need to be some sort of framework, but we wouldn’t want it to be invasive, because we wouldn’t want our code to have dependencies on such a framework. In fact, it would need to be flexible enough to play with any of our own runtime GUI frameworks or infrastructure. Or, if we hadn’t gotten around to writing our own infrastructure, it should just be a full stack framework to use out of the box. Now wouldn’t that be cool?

Focusing on Just the Bit That Matters

Naked Objects is an open source Java framework [3] (commercial on .NET [4]) that lets us build enterprise applications from the domain model out. With Naked Objects we write our domain model as plain old Java objects (pojos). What the framework then does—at runtime—is to create an object-oriented user interface to allow our end users to interact with those domain objects.

You can think of it analogously to object-relational mappings (ORMs) such as Hibernate [5]. Hibernate builds a persistence metamodel from your domain objects, and uses this metamodel to persist your pojos into an RDBMS. Naked Objects likewise builds a presentation metamodel, and uses this to render your objects in the presentation layer, either in a client/server Swing-like UI (we call it the drag-n-drop viewer), or an HTML web viewer.

This metamodel is built up using rules similar to Hibernate, too. Naked Objects uses getters/setters to identify a class’s properties or, if they return java.util.Collection, then collections. Any public methods “left over” are actions allowing arbitrary business operations to be performed on the domain objects. These are exposed using menu items or (on the web) links or forms.

For example, here’s the drag-n-drop viewer running a simple expenses application:

Each window within the frame corresponds to an instance of a domain object, and the whole thing is generated automatically at runtime. So, the Claim class has a description property defined like so:

| // {{ Description
| private String description;
| @MemberOrder(sequence = "1")
| public String getDescription() {
| return description;
| }
| public void setDescription(String description) {
| this.description = description;
| }
| // }}

Similarly, the Approver property is:

| // {{ Approver
| private Approver approver;
| @Disabled
| @MemberOrder(sequence = "5")
| public Approver getApprover() {
| return approver;
| }
| public void setApprover(Approver approver) {
| this.approver = approver;
| }
| // }}

There are similar properties for Date, Status, and Claimant. Meanwhile, the Items collection is:

| // {{ Items
| private List<ClaimItem> items = new ArrayList<ClaimItem>();
| @MemberOrder(sequence = "6")
| public List<ClaimItem> getItems() {
| return items;
| }
| public void setItems(List<ClaimItem> items) {
| this.items = items;
| }
| // }}

So far so good, but there are lots of other frameworks out there that can also automatically let us build CRUD-style applications out of “know-what” responsibilities. However, Naked Objects goes further by also exposing actions that encapsulate “know-how-to” responsibilities. In the screenshot, you can see there’s a submit action on the menu item for the Claim object. Here’s the code that gives rise to that:

| // {{ action: Submit
| public void submit(Approver approver) {
| setStatus("Submitted");
| setApprover(approver);
| }
| public String disableSubmit() {
| return "Submitted".equals(getStatus()) ?
| "Already submitted" : null;
| }
| public Object default0Submit() {
| return getClaimant().getApprover();
| }
| // }}

This is a really simple action, but in principal it could be arbitrarily complex. There’s a similar block of code for the add item action.

I mentioned that Naked Objects provides an HTML viewer, too. Here it is running the same application:

Obviously it looks somewhat different, because HTML has a different interaction idiom from desktop apps. But we’re still looking at a Claim object, and we can see the same properties, collections, and actions.

Meanwhile, here’s the entire codebase for this app:

There are no controllers, no Swing forms, no JSPs, no DTOs, nada. This particular app is entirely made up of three main classes (Employee, Claim, and ClaimItem), two simple interfaces (Approver and Claimant, both implemented by Employee) and two repositories that provide access to existing objects (ClaimRepository and EmployeeRepository). For a closer look, you can download this example from Naked Objects’ SourceForge project page.

Pojos++

In the code samples, you might have noticed a number of annotations (such as @Disabled and @MemberOrder). So, yes, I lied; we aren’t quite writing pojos. These are pojos++.

If we write a method in a public API that could be called from possibly untrusted code, then there are two things it should do. First, it should ensure that the object is in a valid state to be interacted with; in other words, that the class’s invariants are satisfied. Second, it should also check that the arguments passed in are valid before we go ahead and execute the rest of the method.

These business rules are intrinsic to the domain model. The @Disabled annotation just specifies a very simple class invariant: it says that the object cannot be interacted with through the annotated class member at all. Naked Objects interprets this by rendering the property as non-editable (or preventing an object from being added to a collection, or by graying out a menu item for an action).

We can also specify validation rules for arguments. For example, because the submit action’s Approver parameter is not annotated, as @Optional means that it is required. Naked Objects will interpret this rule by graying out the action’s OK button until an approver is supplied.

The metamodel built by Naked Objects doesn’t only rely on declarative semantics. We can also capture business rules imperatively. Looking back at the code you’ll see a disableSubmit() method, returning a String. Any non-null value is interpreted as the reason why the corresponding member (the submit action in this case) is disabled. And again, Naked Objects interprets this by disabling the class member in the GUI. In this case, the user won’t be allowed to submit a claim once it has been submitted. Of course, there are also some semantics that are entirely for presentation concerns.

See It? Use It? Do It?

Earlier on I drew an analogy with Hibernate. Once upon a time we used to use Hibernate’s .hbm.xml files to describe the persistence metamodel, and some people still do. But the alternative approach—and the JEE standard—is to use JPA annotations, with the metamodel built out from there. For example, @Entity (in the javax.jpa package) indicates that a class is persistent, @Id specifies the primary key, and @ManyToOne identifies a foreign key relationship. Taken together, these annotations extend the semantics of the domain classes, and in so doing allow the JPA provider (Hibernate) to take care of the persistence for us.

In the same way, then, annotations such as @MemberOrder extend the semantics of the domain model to capture presentation concerns. @MemberOrder tells Naked Objects the order to display fields in the UI; it’s basically a rendering hint. Some others are @Named (to override the name inferred from the class member), and @DescribedAs (a longer description, for example represented as a tooltip).

Let’s go back to those business rules. Class invariants and validation are two types of rules that are intrinsic to the domain, each of which Naked Objects represents in the GUI by disabling links, etc. But if we think about exposing that method as an action in the UI, there is another check we should make: whether the class member (action, property, or collection) is visible.

So Naked Objects basically asks three questions: is the class member visible (can you see it?); if so, is it enabled (can you use it?); and if so, are the proposed values/arguments to change the state OK (can you do it?). The first two of these enforce class invariants, the last is validation in the traditional sense. And each of these rules can be implemented declaratively using annotations or imperatively using supporting methods.

For example, suppose I have a security management system and the security administrator sets up a new account. We might allow her to specify an initial password before the account is persisted, but we wouldn’t want her to see that password after it has been persisted. Here’s how we do that:

| // {{ Password
| private String password;
| @MemberOrder(sequence = "3")
| @Hidden(When.ONCE_PERSISTED)
| public String getPassword() {
| return password;
| }
| public void setPassword(String password) {
| this.password = password;
| }
| // }}

Here we use the @Hidden annotation to selectively tell Naked Objects when the property should be visible, based on the persistence of the object. Which Naked Objects can do because it also is a full stack and so tracks the persistence of all domain objects.

Thus far we’ve only talked about how Naked Objects removes the need for us to write a custom presentation layer. But the Naked Objects metamodel in effect also removes the need for a custom application layer. This “see it? use it? do it?” mnemonic effectively summarizes the protocol between the application layer and the domain layer. Naked Objects not only implements a generic object-oriented UI, it implements a generic application layer.

Fixing It Up

So far we’ve only focused on the layers in front of the domain layer, but if we want an application to demonstrate to the business, then we also need to deal with the persistence layer.

Naked Objects is compatible with Hibernate and provides an object store implementation that uses Hibernate under the covers [6]. But while we’re exploring the domain, we want something that we can turn around somewhat faster. For this we use an in-memory object store (indeed, this is the default when running Naked Objects in “exploration” mode).

Of course, any objects stored in an in-memory object store will disappear when we close down the application, so we need to populate the object store on startup. For this we use fixtures:

| public class ClaimsFixture extends AbstractFixture {
| @Override
| public void install() {
| …
| Employee tom = createEmployee("Tom Brown", fred);
| Claim claim = createClaim(tom, -16, "Meeting with client");
| addItem(claim, -16, 38.50, "Lunch with client");
| addItem(claim, -16, 16.50, "Euston - Mayfair (return)");
| }
| …
| private Claim createClaim(Claimant claimant,
| int days, String description) {
| Claim claim = newTransientInstance(Claim.class);
| claim.setClaimant(claimant);
| claim.setDescription(description);
| Date date = new Date();
| date = date.add(0,0, days);
| claim.setDate(date);
| persist(claim);
| return claim;
| }
| …
| }

The install() method is called by the framework during initialization, and then populates the object store as required. For larger applications, we usually arrange fixture classes into a hierarchy using the composite pattern. This allows us to easily compose different fixture sets for different scenarios we want to demonstrate to the business, running the app using a command-line flag:

--fixture com.mycompany.myapp.fixtures.ClaimantWithNoApproverFixture

A common approach is to separate static (reference, standing) data from transactional data. When we get to integrating with a production RDBMS object store, we can use the reference data fixtures to populate the database.

Which is nice. But suppose we want to move out of exploration and into something a little more formal, with user stories, acceptance test criteria, all that good stuff. Indeed, our fixture scenarios ought really to be developed with respect to those user stories. How do we go about testing our domain model?

Fit for Purpose

Here’s how. We use FitNesse, an agile acceptance testing tool. After all, FitNesse is just another viewer in the presentation layer.

In FitNesse we write our acceptance test scenario using a wiki. FitNesse then calls out to adapter code which in turn exercises our application. In traditional applications this adapter code must be written by the developer, but with Naked Objects we have nothing to write. Instead, we get generic adapters that—using the metamodel—allow us to interact and inspect domain objects for free [7].

For example, suppose we wanted to test the logic that a claim can’t be submitted again once it has been submitted. Here it is working in the GUI:

And our FitNesse acceptance test script lets the business user verify this same functionality:

If the business user wants, they can run the application alongside the test script to check that it performs as advertised. But the point of FitNesse is that both the representation of the tests and the results are friendly to a non-technical domain expert, so there’s generally no need.

How Do We Measure Up?

Let’s go back to that “wishlist” again. That framework shouldn’t be invasive? Yup, we use pojos plus some annotations. It should also be flexible? Well, yes, actually Naked Objects does provide an API to allow you to replace its programming model conventions with any other conventions as you want. It should also be usable out of the box? Yup, Naked Objects does that, too, providing a Maven archetype to get you started. Oh, and it’s about as extreme an example of the DRY principle as you might hope to meet.

Now you’ve see what Naked Objects can do. But what if you want a half-way house? Let Naked Objects do its stuff early on, but skin the app using custom presentation layer later—implemented in Wicket [8], say—once the domain concepts are firming up. That’s even, dare I say, the kind of thing you could outsource; after all, enterprise application developers are notoriously bad at putting together good-looking GUIs.

All of this talk of domain objects might also have put you in mind of Eric Evans’ domain-driven design [9], in which case, go to the top of the class! Naked Objects is a natural bedfellow for domain-driven design, and uses DDD concepts such as entities, values, repositories, and factories. Its use of the hexagonal architecture also makes it great for tackling more strategic DDD ideas such as bounded contexts, domain services, and infrastructure services.

As I said before, Naked Objects is open source on Java, under the Apache License v2. It provides Maven archetypes to get you started, and it has a bunch of sister projects that extend its capabilities into FitNesse and Hibernate (as discussed) as well as REST. Oh, and there’s a book about it ;-) So, cast aside your inhibitions and get naked. Your business users are gonna love you for it.

References

[1]: Hexagonal Architecture, Alistair Cockburn

[2]: FitNesse

[3]: Naked Objects for Java

[4]: Naked Objects for .NET

[5]: Hibernate

[6]: JPA Objects (Hibernate for Naked Objects)

[7]: Tested Objects (FitNesse for Naked Objects)

[8]: Apache Wicket Web Framework

[9]: Domain Driven Design, Eric Evans

Dan Haywood is a freelance consultant, agile coach, and developer based in the UK. He’s been involved with Naked Objects since 2002, and is an advisor to the Irish Government for a 600+ user system administering pensions and other state benefits, built with Naked Objects. He is also the author of Domain Driven Design using Naked Objects, published this month at Pragmatic Bookshelf.

Forgive and Remember

Learning from Your Mistakes without Blame

by Paul Butcher

Don’t let fear keep you from getting all the benefits of your mistakes.

You’re recovering from a major operation—which nursing unit do you choose? One that reports an error once every 500 patient days, or one that reports an error once every 50 days?

What if I were to tell you that in the first unit, which on the face of things makes 10 times fewer mistakes, nurses don’t report errors because they’re concerned that “heads will roll.” Would that change how you feel? How many errors are being swept under the carpet? Do you think that they’re likely to be learning from their mistakes or repeating them over and over again? (This example comes from Hard Facts, Dangerous Half-Truths & Total Nonsense by Jeffrey Pfeffer and Robert I. Sutton, Harvard Business School Press, ISBN: 1-59139-862-2.)

In software, we have our own name for mistakes—we call them bugs. And every bug is an opportunity to learn.

Learning from Bugs

The fact that a bug crept into the code in the first place means that something went wrong somewhere in your process. Perhaps the requirements were ambiguous or misunderstood? Maybe there was an oversight within the architecture? Were your tests inadequate? Or perhaps the bug was even in the tests in the first place?

That’s why the debugging process comprises four phases: Reproduce, Diagnose, Fix, and (the phase we’ll be concentrating on here) Reflect:

By reflecting on how the bug got into the software, you can identify the source of the error and learn the lessons necessary to ensure that it can never happen again.

Fear is the Enemy

But this learning won’t happen in a climate of fear. Yes, someone somewhere probably screwed up, but we all make mistakes occasionally. Pointing the finger is unlikely to be productive or helpful.

If they fear that they will be pilloried or punished for their mistakes, your colleagues will start worrying more about how to protect their backs than about what’s best for the team or wider organization. In the worst cases, this can even lead to lying, setting up fall guys, and other dysfunctional behavior.

So how do you strike the balance? How do you remorselessly unearth the lessons of each bug without descending into a blame culture? It’s tempting to suggest that you should “forgive and forget,” but in fact you should aim to forgive and remember.

Forgiveness is crucial—as anyone who has ever worked on a non-trivial software project knows, bugs are inevitable. No matter how hard we try, some problems will always slip through the cracks. But remembering is also vital; otherwise we’re doomed to repeat history.

The great thing about software is that, often, we can build that memory directly into the software itself.

Software that Remembers for You

Here’s an example: I currently work on a large Ruby on Rails application. Our controllers are divided up into several modules—we have an Admin module, for example, that contains all the controllers that implement our administrative interface.

Unsurprisingly, these controllers share quite a bit of functionality—each should check, for instance, that the user has administrative privileges. So we factored this common functionality into a base class called AdminController.

All great, except that we found that occasionally we would create a new administrative controller, but forget to ensure that it derived from the right base class (Rails’ code-generation wizards always create controllers that derive from ApplicationController). We could have addressed this by having a checklist of things to do every time we create a new controller. But we can do much better.

Here’s how we guaranteed that we’ll never make the same mistake again—the following test automatically checks that we derive from the right base class in all of our admin controllers:

| class Admin::AdminControllerTest < ActionController::TestCase
| def test_derivation
| 1 Admin.constants.each do |klass_name|
| 2 klass = Admin.module_eval(klass_name)
| 3 ancestors = klass.ancestors
| if ancestors.include?(ApplicationController)
| 4 assert ancestors.include?(Admin::AdminController),
| "Bad derivation for #{klass}"
| end
| end
| end
| end

How does this work? On line 1, we use Ruby’s reflection to iterate over the names of all the constants defined in the Admin module (in Ruby, class names are constants in their containing module). Line 2 converts the name to a Class object and then on line 3 we find out which classes it derives from. Finally at 4, we check that all controllers (classes that derive from ApplicationController) also derive from Admin::AdminController. Can you always build this kind of thing into the software? Unfortunately, you can’t. And even when you can, it’s occasionally more trouble than it’s worth. But you might be surprised by just how often it’s possible, and how often it saves your blushes once you start thinking in this way.

A Healthy Culture

The most far-reaching way to ensure that you learn the lessons of each and every bug is to foster a healthy team culture. You’re aiming for simultaneous forgiveness, in which people are willing to admit and discuss the inevitable errors, and critical introspection, in which you act as though bug-free software is an attainable goal, leaving no stone unturned and ignoring no tool or technique that might get you closer.

In Hard Facts, Dangerous Half-Truths and Total Nonsense, Pfeffer and Sutton suggest that there are several types of people who help sustain this kind of learning:

Noisy complainers repair problems right away and then let every relevant person know that the system failed.

Noisy troublemakers always point out others’ mistakes, but do so to help them and the system learn, not to point fingers.

Mindful error-makers tell managers and peers about their own mistakes, so that others can avoid making them too. When others spot their errors, they communicate that learning—not making the best impression—is their goal.

Disruptive questioners won’t leave well enough alone. They constantly ask why things are done the way they are done. Is there a better way of doing things?

What can you do to help your team develop this culture? Leading by example is particularly powerful, for good or for ill. If you start ranting about the culprit after tracking down a particularly sticky problem, other members of the team are likely to adopt the same behavior. If, by contrast, a problem of your own making comes to light, own up and admit mea culpa to demonstrate that there’s nothing to be ashamed about. And then do everything you possibly can to eliminate any chance that you or someone else can make the same mistake in the future.

Paul Butcher has worked in diverse fields at all levels of abstraction, from microcode on bit-slice processors to high-level declarative programming, and all points in between. Paul’s experience comes from working for startups, where he’s had the privilege of collaborating with several great teams on cutting-edge technology. He is the author of Debug It!: Find, Repair, and Prevent Bugs in Your Code.

Our Daily Bread

by Steve Peter

Take control of what goes into this fundamental food and enjoy your own bread fresh from the oven.

There is nothing quite as good on a cold morning as a hot piece of bread with butter or jam. Actually, there’s nothing quite as good on a cold afternoon or a cold evening, either! Without a doubt in my mind, the best bread comes straight from the oven, usually still too hot for me to hold as I slice it.

Why do I bake my own bread, aside from the wonderful taste? I like to be able to control precisely what goes into this, the most fundamental of the foods I eat. A while back, my doctor told me (like many Americans) to watch the salt in my diet. No problem, I thought. I don’t have a salt shaker at home, and I cut down on the obvious culprits like potato chips. Boy, was I shocked to find that the bagels I was eating (sometimes a couple a day) had over 700 milligrams of sodium each. That’s almost a third of what you should maximally have any given day. (Chips, on the other hand, aren’t so bad. They taste saltier, because the salt is on the outside.)

Will you save money? Probably not if you’re currently buying the generic store brand. If you buy the good stuff, perhaps, but that’s not my primary motivation for baking.

Loafing

So, let’s make a simple loaf of sandwich bread, which is something I do about two or three times a week during the winter. Along the way, I’ll pass on a couple of tips and help you avoid some pitfalls. (But I’m far from flawless. I hurriedly threw together a loaf last week, kneaded it, put it in the pan, and watched it not rise. When I replayed the steps in my mind, it dawned on me I had never added the yeast. Matzo, anyone?)

The equipment you’ll need for this is pretty basic: a mixing bowl, a loaf pan, a fork, and a place to knead the dough. The ingredients are likewise super simple: flour, water, sugar, and yeast (don’t forget the yeast!). You might find it useful to gather everything together before you start in on your first loaf. (You’ll need 4 cups or so of flour, plus more for the kneading, 2 cups of water, a tablespoon or so of sugar, and 2 teaspoons of yeast or a packet.) After you get the basics down, you can play with using different flours like spelt, millet, amaranth, and teff.

First, add a bit of sugar to the mixing bowl. I used sugar in the raw here, which affects how much I use, so I’m not going to give a specific amount. Sometimes, I use maple syrup, but you can use whatever you have handy.

Then, add two cups of hot water. This will probably be the only time I will give an exact amount, since I tend to cook by feel, rather than precisely by a recipe, but two cups works just right for my loaf pan. Your loaf pan may be bigger or smaller, in which case you’d need to adjust your amount up or down.

If you are using regular dried yeast, wait until the water has cooled to a temperature where you can stick your finger into the water comfortably, and add the yeast. I buy jarred yeast, which seems to be available only in the “bread machine” incarnation. The upshot is that I don’t wait for the water to cool, and I add my yeast later, unless I forget. The other advantage I find to using jarred yeast, as opposed to the packets, is that I can easily adjust the amount up or down, depending on the properties of the flour I’m using. For example, last week I baked a loaf of dark rye, which had quite a bit of dark rye and pumpernickel flour in it, so I added a bit more yeast to keep the loaf on the airy side.

At this point, you can add a pinch of salt if you want. (In theory, the salt will help preserve the loaf, but the unsalted bread in our house never lasts long enough for me to test this out.)

Add about a cup and a half of flour and mix it in. You should get something that looks like more or less like pancake batter. What kind of flour? Experiment with the various flours available in your local supermarket. I personally use Hecker’s, which is readily available in New Jersey. Eventually, you’ll find one that works well for you.

Now for the first helpful tip. If you don’t like kneading the dough so much, you can shorten that phase by whipping the “batter.” Take the mixing bowl in one hand, tuck it under your arm, and whip until your arm feels like it’s going to fall off. (You must suffer for your craft.) At this point, I add the yeast. For a sandwich bread, a light dusting on the surface of the batter does just fine. If I were to measure it, I suspect it’d come close to 2 tsp.

Now add more flour, until the dough becomes rather difficult to mix with your fork, probably another 2 and a half cups. You’re now ready to be kneady. Dust some flour on your work surface, and dump the contents of your mixing bowl. There shouldn’t be very much left behind in the bowl, so scrape and get all the flour and dough out. (When I first started making bread, in the form of pizza dough in college, I always had a huge mess to clean up, which was a good sign that I was doing it wrong.)

Now comes the part where you get to work out all your aggression. Imagine you’re beating that image that wasn’t in the proper format. (Hey, I typeset Pragmatic Bookshelf books.) When I was still very small, my grandmother tried to teach me to cook and bake. I got the fried potatoes down right, but her advice on bread was a bit cryptic: “knead the dough until it feels right.” And that would be how? Well, I’m here to tell you: knead the dough until it feels right. Yes, grasshopper, you must try and try and try until you know how it should feel. Just like riding a bike, there will come a day when it suddenly hits you, and you cannot not know how it feels.

That said, when the dough is ready, it won’t stick to your hands, and the surface will essentially be clean. In the picture below, I did not otherwise clean up, though it does help to have marble countertops. (One other tip at this point: some bakers recommend a 10-minute break about halfway through the kneading, to allow the flour to absorb the moisture. I’m usually too impatient.)

Now, put the dough in your breadpan. I have a non-stick pan, which meant that the first time I used it, the bread so thoroughly fused to the pan that I couldn’t tell where bread ended and pan began. Now, I lightly grease the pan before I put the dough in. Cover it with a clean cloth (or a paper towel, if your kitchen towel is threatening to walk away) and wait for about half an hour. After half an hour, turn on your oven to 370°F, and allow the bread to continue rising. (If it’s still completely flat, you forgot the yeast; not that that’s traumatic or anything....)

Once the oven is fully pre-heated, and roughly an hour has gone by, the dough will have risen to resemble a loaf of bread. If yours looks like a Ford Edsel, you’ve done something seriously wrong. Place the pan on the center rack and let it bake for an hour. (Start checking on it at about 40 minutes. If your oven runs hot, you may need to reduce the heat.)

Now comes the hardest part of all. Take the bread from the oven and put it on a wire rack to cool. No, you can’t have any yet. I know I said that the best bread comes straight from the oven, but that was rhetoric, and these are instructions. You should probably take a walk around the block to avoid temptation.

Back from your walk? Okay, now you can slice your piping-hot bread and enjoy what you have wrought.

Once you’ve got the basic recipe down, it’s time to experiment with variations. One of the favorites in our house is to use maple syrup as the sugar and to add a bit of oats to the sugar water. Let it set for a few minutes before you start adding the flour. Millet also makes a great addition to the flour. I simply add it when I add the yeast.

Another grain I’m fond of is teff, which is an Ethiopian grain high in iron, calcium, fiber, and protein. It imparts a warm, nutty flavor when mixed in small amounts into the dough. (It’s amazingly good in pizza dough for zucchini and/or eggplant pizza!) You can find most of these grains in the natural foods section of your local supermarket.

Variants

If you want a challenge, try making bagels. The process is the same through kneading the dough, although some people like to add a bit of oil to the dough. For bagels, you need to work in as much extra flour as you possibly can. If your hands ache, you’ve probably done it right! Divide the dough into a dozen or so balls. Flatten each ball into a disk and poke a hole in the center. Set them aside to rise for about 20 minutes, during which time, bring a large pot of water to a boil. (If you’ve got some malt syrup handy, add a bit to the pot.) Drop the bagels into the pot and boil for about a minute, then flip them with a slotted spoon, and boil for another minute. Drain the bagels and put them on a greased cookie sheet and bake them for 20—30 minutes at 400°F.

And if that was too easy for you, try pita next. This time around, it’s essential to add oil to the dough as you’re mixing. Then, after the dough is kneaded, divide it into small balls and roll them out into .25—inch-thick pancakes. While these are resting, put the rack of your oven at the very bottom, and put a pizza stone in. Heat the oven to 500°F. Bake each pita for 4 minutes or so, then flip and bake for another 2 minutes.

Whatever you do, have fun, experiment—and play with your food!

Steve is the typesetter for the Pragmatic Bookshelf. When not coaxing kerning pairs or reining in overfull hboxes, he likes to spend time in the kitchen baking and brewing. He also makes his own typefaces, but you can’t eat those.

The Quiz

This Month: The Return of the Text Sudoku

This month we present another Sudoku puzzle with a twist—it uses letters instead of digits and hidden within it is the name of a kind of document sometimes written by software developers.

X
X
X

X
O
X

I
X
T

X
F
X

M
X
A

O
X
X

X
X
X

X
X
X

M
A
E

E
M
X

N
X
X

X
X
I

N
X
X

X
A
X

X
X
T

T
X
X

X
X
F

X
M
N

F
I
A

X
X
X

X
X
X

X
X
O

S
X
F

X
E
X

N
X
S

X
I
X

X
X
X

Simply fill in the empty cells with the nine letters A, E, F, I, M, N, O, S, and T, so that each row, column, and small square contains each of the nine letters once.

Answer to Last Month’s Quiz

Each of last month’s quotations had something to do with programming or computers. They were encrypted with a simple letter-substitution cipher, a different cipher for each quote. Punctuation and numerals were not encrypted, and each cryptoquote included at least one numeral.

Cryptoquote

Decrypted quote

“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

“The first 90% of the code accounts for the first 90% of the development time.  The remaining 10% of the code accounts for the other 90% of the development time.” -Tom Cargill

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

“Should array indices start at 0 or 1?  My compromise of 0.5 was rejected without, I thought, proper consideration.” -Stan Kelly-Bootle

“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

“If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get 1,000,000 miles per gallon, and explode once a year, killing everyone inside.” -Robert X. Cringely

“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

“Come to think of it, there are already 1,000,000 monkeys on 1,000,000 typewriters, and Usenet is nothing like Shakespeare.” -Blair Houghton

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

“The city’s central computer told you?  R2D2, you know better than to trust a strange computer!” -C3PO

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

“Why do programmers always mix up Halloween and Christmas? Because Oct 31 equals Dec 25.” -Anonymous

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

“1f y0u c4n r34d 7h15, y0u r34lly n33d 70 637 4 l1f3.” -Anonymous

Calendar

by Jackie Carter

Author sightings and other notable events.

Dec 1-3, Long Beach, CA

Pragmatic Studio, Ruby on Rails

Dave Thomas and Chad Fowler, author of The Passionate Programmer

Dec 1-4, Long Beach, CA

Pragmatic Studio, 4 day “how to” for iPhone SDK development

Bill 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 3, MySQL University: Practical Full-Text Search in MySQL

Online session using DimDim conferencing 16:00 UTC (8:00 AM PST)

Bill Karwin

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 OpenSpace

Rachel Davies

Dec 10, CocoaHeads meeting, Ann Arbor, MI

“Introduction to Core Audio”

Chris Adamson, co-author of iPhone SDK Development

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” opens

Writer and Director, Terry Gilliam; starring Heath Ledger, Christopher Plummer, Tom Waits, Johnny Depp, Colin Farrell, Jude Law

Jan 10

Donald Knuth’s birthday

Jan 11-14, Obtiva, Chicago IL

I’ll be running Obtiva's Ruby on Rails TDD Boot Camp

Noel Rappin

Jan 13-15, CodeMash 2010, Sandusky, OH

Keynote

Andy 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

Jan 13, Inman News ConnectTech NYC

Tips and Tricks for Working with the iPhone SDK

Mike Mangino

Jan 21, Grand Rapids Java Users Group

Driving Behaviour w/Cucumber on the JVM

Zach Dennis

Jan 28-29, Japan Symposium on Software Testing

Keynote and a tutorial

Johanna 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

Feb 9-11, Speakerconf 2010, Aruba

TBA

Brian Marick

Feb 11, Moscone Center, San Francisco

Macworld Expo

Steve Jobs?

Feb 12

Darwin Day: Charles Darwin is 201.

Charles Darwin

Feb 17-18, PyCon 2010 Atlanta, Georgia

Tutorial session: Test Driven Web Development

Travis Swicegood

Feb 22-24, JAX London conference

“Agile Coaching Secrets”

Rachel Davies, coauthor of Agile Coaching

Feb 24

Steve Jobs is 55.

Feb 29

Celebrate Herman Hollerith’s 150th birthday.

Shady Illuminations

Is Google’s New Language a Goer?

by John Shade

Google releases a new programming language and John Shade finds a bit of Python in it.

Google has graduated a new programming language from its twenty percent program, the corporate scheme to turn moonlighting into yet another track of Google R&D by sidetracking employees’ natural inclination to bootstrap their own startups on company time.

It’s called Go. Ah, I bet it does. Say no more. Clearly they are not ripping off the author of the Go! language, because Google’s Go doesn’t have an exclamation point at the end. It’s exactly as if Google had created a web portal and search engine and called it Yahoo. No problem at all. The mascot, though, is a gopher, and I foresee a messy lawsuit by the University of Minnesota.

Go is being described as some sort of unsanctioned offspring of C++ and Python, and the question that naturally leaps every blogger and tech writer’s lips is, will Go join the long list of Google failures? You know, like Google Catalog Search, Google Answers, or Google Lively.

ComputerWorld thinks Google Chrome will be in that failure list because it is already failing to deliver what Windows delivers. By CW’s logic, the fact that Google has designed Chrome explicitly not to compete directly with Windows makes it a failure in competing with Windows. If I tried to follow that logic I’d need a chiropractor for my brain.

But see if you can spot the common theme in those failures. Got it? None of them was a released product. Not in the sense that, say, Windows Vista is a released product. Google Catalog Search was a “demonstration;” Google Lively and Google Answers were “experiments.”

Google doesn’t release products. Google moves technologies from unsupported internal project to unsupported leaked project, or from experiment to public beta, and then stops. If you never release a product, you can’t fail. If you never even announce a product, you can’t even slip.

Google has achieved the miracle of appearing invincible while lowering expectations to the vanishing point. This has led to Google technologies being routinely described as replacements for, or killers of, Microsoft products by everyone but Google. Google doesn’t release, and Google doesn’t compete.

Same with Go. “I don’t think we’ll replace anything,” Go co-creator Rob Pike said of the language. He doesn’t say that the number of people using C++ or C# won’t decline if adoption of Go takes off, he just doesn’t draw a connection.

So will Go take off? What virtues does it have that justify the creation of Yet Another Language?

Let’s see, rapid development, lightning fast compilation, so-called goroutines to make concurrent programming easy, garbage collection and runtime reflection. It embodies a model for building system software on multicore machines. And it’s open source.

Rather than ask of what use that particular set of virtues might be and to whom, the blogosphere rushes to brand it a failure because it isn’t the D language. Or because it has a complicated syntax, or because it has pointers.

Some of the criticism would make more sense if Go weren’t explicitly designed to be a systems language.

Then there’s the simplicity thing. Those who think Go isn’t simple or elegant enough may have overlooked two facts: (1) Google just released a language for Android development called Simple; this one has to differentiate itself; and (2) they did name it for a game that takes five minutes to learn and a lifetime to master.

You’d almost think that the inventors of Unix, Plan 9, and the Java HotSpot compiler had designed this language for themselves. But nah, that couldn’t be. Let’s just ignore the fact that the designers of Go have said explicitly that they built it for themselves. Or that they designed it for “the kinds of programs written by Google engineers.” Or that “We’re systems software people ourselves. We wanted a language to make our lives better.” No, they must have designed it to do whatever we think a new language ought to do, and that’s the proper standard to hold it to.

Google’s approach to technologies is to release them into the wild and let them find their ecological niche. It’s not an approach the lends itself to naming winners and losers. Betting on any given Google technology is a crap shoot, but betting against Google is as close to a sure losing bet as you’ll find.

This just in: AOL changes its name to BSOD, adopts solid blue screen as its logo.

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 his fellow man and the firm conviction that a nod’s as good as a wink to a blind bat.