PragPub 2010-07: Issue #13

Table of Contents

Features

- Meet the Arduino
by Maik Schmidt
The Arduino lets us get hands-on again with computers in a way we haven’t been able to since the 1980s.

- Not Quite New in iOS 4
by Daniel H Steinberg
Three unsung developer features of iOS 4 will make your life easier and change your code dramatically: blocks, gestures, and properties without ivars.

- TDD on iPhone: DIY
by Eric Smith
If you’re trying to do quality iPhone development, TDD is not optional. Fortunately, it is also not impossible.

- BDD on iPhone: iCuke
by Rob Holland
Almost a year ago in these pages, Ian Dees showed how to use Cucumber to test your iPhone apps. Now iCuke makes it even easier.

- When Did That Happen?
by Dan Wohlbruck
In the 1960s, a network was conceived that would change computing in fundamental and far-reaching ways.

Departments

- Up Front
by Michael Swaine
You could call this our iPhone issue, if it weren’t for the movie reviews, the career advice, and the Circuit Cellar flashback.

- Choice Bits
A little knowledge that is perfectly safe.

- The Working Geek
by Andy Lester
You need a Geek Disaster Preparedness Kit, and you need it now. By the time you realize you’re getting canned, it’s too late to start it.

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

- Calendar
Author sightings, partner events, and other notable happenings.

- Shady Illuminations
by John Shade
Increasingly, tech companies use video to present themselves. Really bad video.

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

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

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

ISSN: 1948-3562

Up Front

Your Own Devices
by Michael Swaine
Developing for iPhone or other mobile platforms can give you flashbacks to an earlier era of programming. Eric Smith says in this issue that it reminds him of a previous life writing C and C++ code on Windows. So now that mobile devices seem to have become the center of the software development universe, don’t you need all the development tools and paradigms that you’ve come to depend on in your computer software development work? Sure you do. In this issue we reveal a bounty of tools and techniques for TDD and BDD and MakingYourLifeEasierDD app development for iPhone.

Eric jumps right into iPhone Test-Driven Development with an article that will convince you that, by golly, it can be done. Rob Holland spins off from an article Ian Dees wrote for us last year and shows how iCuke can make Behavior-Driven Development (almost) easy for iPhone. And Daniel Steinberg reveals some really useful features of the brand-new iOS 4 that are not really new, but have come to iPhone for the first time.

At this point you’re muttering to yourself, “What’s with all the iPhone stuff? Has PragPub become an iPhone-only magazine? What about Android? Are you giving up on computer application development? And while I have your attention, are you ever going to write about Groovy?”

OK, you need to stop muttering. First, we’re going to continue to cover all the platforms, languages, and subjects we’ve been covering up to now; this issue just took on an iPhone theme as it came together. Second, the other people in Starbucks are beginning to stare at you.

And by the way, our lead article is not about iPhone, but about a smaller device that may also give you flashbacks: the Arduino Single-Board Computer. I dunno about you, but I’ve always been a software-only guy, not that comfortable with a soldering iron—but this device makes me want to build something. It calls to mind Steve Ciarcia’s “Circuit Cellar” column in the early Byte magazine. Maik Schmidt walks you through a simple project and makes it clear how easy it would be to build all sorts of devices with this cool tool. The possibilities, as they used to say back in those Circuit Cellar days, are limited only by your imagination.

Also in this issue: Dan Wohlbruck’s article on ARPAnet is another kind of flashback, Andy Lester helps you build your geek disaster preparedness kit, John Shade reviews movies, plus there’s the Quiz, the events Calendar, and Choice Bits from the Twitterstream.

And yes, we do plan to write about Groovy.

Choice Bits

Hey Andy, did you hear about this one?

A few selected sips from the Twitter stream.

What’s Hot

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

1

1

Agile Web Development with Rails

2^

NEW

HTML5 and CSS3

3^

NEW

SQL Antipatterns

4^

5

The RSpec Book

5v

3

iPad Programming

6v

4

Hello, Android

7v

2

The Agile Samurai

8^

NEW

Test-Drive ASP.NET MVC

9v

7

Seven Languages in Seven Weeks

10^

NEW

iPhone SDK Development

11v

10

Programming Ruby 1.9

Good to Know

The incomparable wisdom of the tweet.

Counting packets is the new counting cycles. — @mtnygard

One snapshot of a code base doesn't tell you much. Two snapshots and you have a vector. Three or more and you have trends. — @mfeathers

alligator cell tower: “all mouth no ears” rabbit cell tower “all ears no mouth” — @codinghorror

My next book will be ‘Wikipedia Brown,’ about a boy detective who solves crimes by getting his friends to do all the work. — @cshirky

Art critics can study brush strokes for 100s of years but only the artist knows how the smell of paint guided the work. — @WardCunningham

completed tdd screen casts two weeks ago, they came out yesterday, & prags cut my first royalty check today. are you listening pearson? — @KentBeck

Every time I get irritated with OpenOffice, it just makes me more impressed at how well it emulates MS Office. — @hardtaught

Who exactly promised us flying cars back in the day, and why is it the only thing we've managed to remember for more than 20 years? — @shelly

Cloudy with a Chance of Vuvuzela

Sleepless in Seattle?

The sky over Portland is the color of television, tuned to a dead channel (in 1983). — @wilw

I just realized that it is all too obvious why cloud computing is at home in Seattle. — @jeffbarr

Post vuvuzela hell, the patter of heavy summer rain outside my window feels like thousands of angels massaging my eardrums. — @craigmod

Which is more annoying: The vuvuzela or discussion of them? — @petdance

Note: I did not invent the ASCII vuvuzela. I am merely a player. — @jkottke

Vacation Tweets

Everybody’s summer vacation is different.

Now up, a v3-ized map of all the toilets in Australia, complete with clustering, tile layers, and simplified polys. #devfestau — @pamelafox

Got out of Powell's for $30. I'm extremely proud of my restraint, and commitment to keeping my suitcase under weight when I fly home. — @wilw

Incredible trip to Nigeria – determined & getting closer to eradicating polio. Government, partners & Nigerians are committed & inspiring — @BillGates

Safely made it to Bedford, IN. Let the good times roll! — @squarepegsys

Crimes and Misdemeanors

Hiring advice from the AP Stylebook.

Illegal immigrant is the preferred term for someone who has entered the country illegally. Do not use an illegal. — @APStylebook

Best thing about coffeescript: You will not be shot on sight if you don't use CamelCase. — @burkelibbey

When “Anna Chapman” bought her untraceable cellphone on Saturday, she gave a false name, and the address “99 Fake Street.” #TooGoodToBeTrue — @maddow

As appropriate as it may seem, references to the game "Frogger" have no place in pedestrian death stories. — @FakeAPStylebook

The Horror

Using a modified version of the kind of spectral imaging technology developed for the military and for monitoring agriculture, research scientists have reconstructed the long-lost first draft of K&R (&L).

Playing the game of Tetris that is my email inbox and losing. They're coming in faster than I can make them disappear! — @ginatrapani

It’s amazing how burpy you can get after a trip to the dentist. So much air swallowed! — @petdance

The C Programming Language, Brian W Kernighan & Dennis M Ritchie & HP Lovecraft http://bit.ly/7gy7Db — @alexey_r

Retweeted is the New Slashdotted

This month we eavesdropped on the twitterflow of a whole bunch of folks—possibly including you—and gathered tweets from AP Stylebook, Jeff Atwood, Jeff Barr, Kent Beck, Shelly Brisbin, Ward Cunningham, Fake AP Stylebook, Michael Feathers, Pamela Fox, Bill Gates, Mike Hostetler, Jason Kottke, Andy Lester, Burke Libbey, Rachel Maddow, Craig Mod, Travis Nelson, Michael Nygard, Alexey Romanov, Clay Shirky, Gina Trapani, and Wil Wheaton.

So Long, and Thanks for All the Tomatoes

Class is over. They finished in 3 tomatoes. They done good. — @squarepegsys

Yeah, we follow some odd tweeters, and you can follow us on twitter.

The Working Geek

Geek Disaster Preparedness Kit
by Andy Lester
You need a Geek Disaster Preparedness Kit, and you need it now. By the time you realize you’re getting canned, it’s too late to start it.

Last night while I was playing Super Mario Galaxy 2 with my daughter, the lights flickered a few times, then went out. “Please go grab the flashlight,” I asked her. She threaded her way through the gloom to the kitchen, opened the first drawer, took the Maglite from its permanent home and lit up the living room. “Remember how I always make sure that if you use the flashlight, you have to put it right back in the Critical Drawer?” I asked her. “This is why.”

You get in the car, and before you turn the key, you put on your seat belt. Even if you’re only going a few blocks, and you’re not going very fast, you put it on. You may never need it, but if you do, and you don’t have it on, you’re screwed. No matter how good a driver you are, there may be times that you need a seat belt, and by the time you realize you’re going to be in a crash, it’s too late to do anything about it.

As I discussed in last month’s column, you can get fired, laid off and otherwise relieved of your employment for just about any reason. No matter how good a worker you are, there may be times you need a Geek Disaster Preparedness Kit, and by the time you realize you’re getting canned, it’s too late to start it. The time to start is now.

Your Master Résumé

What’s the first thing most people think when they have to find a new job? From my experience, it’s always “I need to get my résumé up-to-date.” Good thought, but there are two problems with that.

First, when you’ve lost your job, it’s the worst time to work on your résumé. You’re panicked. Your mind is occupied with a million things. You’re not going to be doing your best thinking. Worse, you’re facing time constraints. You want to get résumés out as soon as possible, and chances are you’re going to forget things about your past that would make fantastic selling points.

Second, you don’t have a single résumé. Each résumé you send to apply for a job is going to be crafted carefully for the specific position. The easiest way to do that is by having an exhaustive master résumé.

There’s an old joke about how it’s easy to carve a statue of an elephant. Get a big block of stone, and chip away everything that doesn’t look like an elephant. Your master résumé is going to be that block of stone. It will include every potentially cool thing you’ve done, no matter how obscure. It’s going to be two or three times as long as an actual résumé that you’d send out. Then, when you’re ready to send out a résumé, you’ll make a copy of your master résumé and whittle away everything that’s not relevant to the job for which you’re applying. This way, you have a powerful résumé with only your best material on it, but you haven’t had to play the panicked game of “What did I do at Amalgamated Widgets? I only have two bullets for them!”

An extensive master résumé takes time to build. You’re not going to build it overnight. You’re going to add to it a little bit every month or so with work you’ve done at your current job, and you’ll add older items as they come to mind. It is an eternal work in progress. That’s why you need to have it up-to-date well before the day you get canned.

A good master résumé is exhaustive. Maybe your expertise is with Oracle databases, but noting the little MySQL projects you did along the way may be helpful evidence of your skills for a MySQL-heavy shop. That little Perl program you whipped up to poll the company’s bank balance may help you in the door when you’re applying at a financial services firm. Keep track of each scrap of work you’ve done, and you’ll never have to rack your brain for it in the future.

The best way to keep your master résumé current is to add to it regularly. Set a monthly task in your to-do software to add a new bullet to your résumé. You can list the current project you’re working on, or a new technology you had to use. And if you don’t have something to add once a month? Then you’re not exercising your skills enough and it might be time to be moving on anyway.

Portfolio of Projects

Along with a résumé that tells of your achievements, it’s good to have a collection of work products that demonstrate your abilities for a future employer. Given the choice between two candidates who are equally matched, but one of them has code samples that show his ability to do the work, a hiring manager is going to see the one with code as less of a risk.

Assemble a collection of your work that you can print at a moment’s notice. When you go on an interview, you’ll want to be able to bring a sheaf of printouts of your code, network diagrams, project schedules, whatever. Don’t pass it off on the interviewer by saying “All my code is on github, my ID is slackerprogrammer, oh, except that I have some on SourceForge. I’ll mail you the URLs.” Instead, print out your best work and bring it with you.

What goes in your portfolio? Work products that show your ability to do and understand work that the employer will want. Maybe this will include:

- Source code listings

- Database schemas

- Testing plans

- Network diagrams

- Security policies

- Web pages

Your portfolio should not include proprietary information, of course. If you don’t have material that’s OK to use, then make some. Write some programs that do work similar to what you’ve done in the past. Open source is an ideal solution to this problem, because you can license it yourself and show whoever you want.

Few interviewers ask for code samples. Even fewer techies think of bringing code samples or other work products to interviews without being asked. Whether your portfolio includes work you did for an employer, or that you created for the portfolio itself, it can create a powerful impression on your employer-to-be, especially when you’re the only candidate who thought to bring one.

Network of Contacts

Having a good résumé and portfolio won’t do you much good if you can’t find the job openings, and your contacts can help you here better than anyone. Fewer than 10% of job openings are filled through use of job boards like Monster and CareerBuilder, so they’re of limited value in your search. Around two-thirds of jobs are filled through personal contacts. That’s where your network will help you.

Your network is that group of people who know you, know your skills, and like you enough to be willing to help you out. They’re also people you know about, where you’re familiar with their backgrounds, so that you know who is most likely to be helpful in your hunt.

The best people to have in your address book are people who:

- Like you personally: They are willing to help you with your job search, even if it’s just answering email.

- Are well-connected: They know what’s going on in your industry, your town, or your online community.

- Have worked with you: This could be on the job or in an ad-hoc community like an open source project, or maybe a business group in your town.

These sorts of connections take months or years to cultivate, and have to be maintained over time. Someone you haven’t talked to in ten years isn’t likely to want to help you in your time of need. It’s also not helpful if he doesn’t know your current skills.

Don’t forget that your personal network is entirely opt-in. Nobody’s going to help you out unless she wants to, and unless you’ve proven yourself to her in the past. You can’t just ask someone you only barely know for help and expect much of a positive response.

Specifics

So what does your kit look like? Are you prepared if the axe falls?

- Is your master résumé at least four pages long, or two pages if you have less than 5-7 years of work experience?

- Is it exhaustive? Does it include side work that you’ve done on the job besides your regular duties? Are you a programmer who was pressed into stringing cable during a building expansion? Put it in there!

How about your network of contacts? Can you name in the following list people whom you know well enough that they’d be willing to help you out? Can you name:

- Five people at your current company who are able to attest to the quality of your work?

- Five people outside your company who know what you do?

- Five people who are regularly pursued by headhunters or other companies?

- Five people held in high regard in their field?

Do you have current email and phone numbers for the people listed above? If they got a call from you asking for help, would they be willing to go to bat for you?

I was once fired at 11:30 AM on a Tuesday. By 2:00 PM I had skimmed my address book, fired off emails to the most likely candidates, and had an interview lined up from one contact and promise of part-time freelance work from another. That’s the power of contacts.

Start Today

The three main parts of your disaster kit (master résumé, portfolio, contacts) all take time to create and maintain. They’re not going to be something you can power through in a day or two when the manure hits the ventilator. You certainly won’t be doing your best work when you’re under the stress caused by losing your job. You want it ready when you need it, like the flashlight in the kitchen drawer.

There’s a saying that my friend and inspiration Bill Odom taught me: “The best time to plant a tree is twenty years ago. The second best time is right now.” If your disaster kit isn’t ready now, start planting.

Appearing Live in Your Area (if Your Area Is Chicago)

If you’re in the Chicago area on July 13th, 2010, I’ll be speaking at Uniforum Chicago in Wheaton, IL on what’s new in Perl 5.10 and 5.12. I hope to see some PragPub readers there!

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. He blogs at theworkinggeek.com, and can be reached by email at andy@theworkinggeek.com. Send the author your feedback or discuss the article in the magazine forum.

Meet the Arduino

The Open Source Hardware Platform that Is Empowering a New Generation of Hardware Hackers
by Maik Schmidt
You can create your first Arduino electronic project in a matter of minutes.

Arduino is an open source project consisting of both hardware and software. It was originally created to give designers and artists a prototyping platform for interaction design courses. Today hobbyists and experts all over the world use it to create physical computing projects, and you can too.

Although the Arduino is way more than a toy, it’s mostly about fun! We spend so much time in front of our computers every day. The Arduino lets us get hands-on again with computers in a way we haven’t been able to since the 1980s, when you could build your own computer. And Arduino makes developing handcrafted electronics projects ranging from prototypes to sophisticated gadgets easier than ever. Gone are the days when you had to learn lots of theory about electronics and arcane programming languages before you could even get an LED blinking. You can create your first Arduino electronic projects in a few minutes and without needing advanced electrical engineering coursework.

In the first figure you can see an Arduino Duemilanove board and its most important components. With the USB port you can not only power the Arduino, you can also program it, and you can communicate with it serially. Using the digital and analog input and output pins you can connect a great number of sensors and other electronic parts to the Arduino. For example, you can attach temperature sensors, motors, LEDs, or alcohol sensors.

In this article I’ll show you how to take your first steps with an Arduino. You’ll get to know the most important tools first and at the end you’ll build a remote control that you can operate using your computer’s serial port.

The Software You Need

To make it as easy as possible to get started with the Arduino, the Arduino developers have created a simple but useful IDE (Integrated Development Environment). It runs on many different operating systems and before you can create your first projects, you have to install it.

Installing the Arduino IDE on Windows

The Arduino IDE is available for all the latest versions of Microsoft Windows, such as Windows XP, Windows Vista, and Windows 7. Installing the software is easy, because it comes as a self-contained ZIP archive, so you don’t even need an installer. Simply download the archive and extract it to a location of your choice.

Before you install the IDE you have to make sure that the drivers for the Arduino’s USB port are installed. On the most recent versions of Windows this happens automatically as soon as you plug the Arduino into a USB port. Lean back and watch the hardware wizard’s messages pass by until it says that you can use the newly installed USB hardware.

Older versions of Windows don’t find the drivers on Microsoft’s update sites automatically. If the hardware wizard asks you for a path to the right drivers after plugging in the Arduino, point it to drivers/FTDI USB Drivers in the Arduino installation directory.

After the drivers have been installed, you can start arduino.exe from the archive’s main directory by double-clicking it. Follow the instructions on the screen to install the IDE.

Please note that the USB drivers don’t change as often as the Arduino IDE. Whenever you install a new version of the IDE, check if you have to install new drivers, too. Usually, it isn’t necessary.

Installing the Arduino IDE on Mac OS X

The Arduino IDE is available as a disk image for the most recent version of Mac OS X. Download it, double-click it, then drag the Arduino icon to your Applications folder.

Before you can use the IDE with your Arduino you have to install drivers for the Arduino’s serial port. You can find them in the disk image, too, and they are available for both PowerPC Macs (FTDI Drivers for PPC Macs.pkg) and Intel Macs (FTDI Drivers for Intel Macs.pkg). Double-click the pkg file for your platform and follow the installation instructions on the screen.

You can check what kind of Mac you have by clicking the “About this Mac” menu item in the Apple menu at the top left corner of your screen. Chances are good that you have an Intel Mac, because the PowerPC Macs are getting old.

When installing a new version of the Arduino IDE you usually don’t have to install the FTDI drivers again (only when a more recent version of the drivers is available).

Installing the Arduino IDE on Linux

Installation procedures on Linux distributions are still not very homogeneous. The Arduino IDE works fine on nearly all modern Linux versions, but the installation process heavily differs from distribution to distribution. Also, you often have to install additional software (the Java Virtual Machine, for example) that comes pre-installed with other operating systems.

It’s best to check the official documentation and look up the instructions for your preferred system.

A First Look at the IDE

In our next figure you can see what the IDE looks like. It has no advanced features such as a debugger or code completion. You can only change a few preferences, and as a Java application it does not fully integrate into the Mac desktop. It’s still usable, though, and even has decent support for project management. Its toolbar gives you instant access to the functions you’ll need most. Their meaning—from left to right—is:

- With the Verify button you can compile the program that’s currently in the editor. So in some respects “Verify” is a bit of a misnomer, because the program is not only verified syntactically but also turned into a representation suitable for the Arduino board.

- The Arduino can communicate with a computer via a serial connection. The Stop button stops the serial monitor.

- The New button creates a new program by emptying the content of the current editor window. Before that happens, the IDE gives you the opportunity to store all unsaved changes.

- With Open you can open an existing program from the file system.

- Save saves the current program.

- When you press the Upload button the IDE compiles the current program and uploads it to the Arduino board you have connected to your computer.

- Pressing the Serial Monitor button opens a serial monitor window that allows you to watch the data sent by an Arduino and also to send data back.

The Hardware You Need

Now that we have the drivers and the IDE installed, we need some hardware to build this article’s projects:

- An Arduino board such as the Duemilanove or the Diecimila.

- A USB cable to connect the Arduino to your computer.

- A regular LED.

- An infrared LED.

- A 100 Ohm resistor.

- A breadboard.

- Some wires.

That’s all we need to get our first projects up and running. You can find these parts at electronic shops such as Makershed, Adafruit, Digikey, Mouser, Radioshack, etc. Sometimes they do not have them all, so you might have to buy from more than one of them. Also it’s often advantageous not to buy a single part but a whole collection. For example, you can often get a whole box of LEDs or resistors for only a few bucks.

<blink>Hello, world!</blink>

To get familiar with the IDE we’ll start with the “Hello, world!” of Arduino programming; that is, we’ll make an LED (light-emitting diode) blink. LEDs are cheap light sources that you can easily integrate into electronic circuits.

The LEDs that we need are through-hole parts; you can see some in the figure. They are named through-hole parts because they are mounted to a circuit board through holes. That’s why they usually have one or more long wires: first, you put the wires through holes in a printed circuit board. Then you usually bend, solder, and cut them to attach the part to the board. Where available you can also plug them into sockets as we have them on the Arduino or on breadboards.

The next figure shows how to attach an LED to an Arduino. Connect the short connector of the LED to the ground pin (GND) and the longer one to pin 13.

Connect the USB cable to the Arduino and plug it into one of your computer’s USB ports. Then enter the following code in the IDE’s editor:

arduino/HelloWorld/HelloWorld.pde

1  const int LED_PIN = 13;

-  const int PAUSE = 500;

-

-  void setup() {

5    pinMode(LED_PIN, OUTPUT);

-  }

-

-  void loop() {

-    digitalWrite(LED_PIN, HIGH);

10   delay(PAUSE);

-    digitalWrite(LED_PIN, LOW);

-    delay(PAUSE);

-  }

Let’s see how this works and dissect the program’s source code piece by piece. In the first two lines we define two int constants using the const keyword. LED_PIN refers to the number of the digital IO pin we’re using and PAUSE defines the length of the blink period in milliseconds. Digital pins act as a kind of switch and can be in one of two states: HIGH or LOW. If set to HIGH, the output pin is set to 5 Volts, causing a current to flow through the LED, so it lights up. If it’s set back to LOW, the current flow stops and the LED turns off.

Every Arduino program needs a function named setup and ours starts in line 3. Arduino calls setup once when it boots, and we use it for initializing the Arduino board and all the hardware we have connected to it. We use the pinMode method to turn pin 13 into an output pin. This makes sure that the pin is able to provide enough current to light up an LED. The default state of a pin is INPUT and both INPUT and OUTPUT are predefined constants. See the official documentation.

Another mandatory function named loop begins in line 6. It contains the main logic of a program, and the Arduino calls it in an infinite loop. Our program’s main logic has to turn on the LED connected to pin 13 first. To do this, we use digitalWrite and pass it the number of our pin and the constant HIGH. This means the pin will output 5 Volts until further notice, and the LED connected to the pin lights up.

The program then calls delay and waits for 500 milliseconds doing nothing. During this pause, pin 13 remains in HIGH state and the LED continues to burn. The LED is eventually turned off when we set the pin’s state back to LOW using digitalWrite again. We wait another 500 milliseconds, and then the loop function ends. The Arduino starts it again and the LED blinks.

Before you compile and upload a program to the Arduino you have to configure two things in the IDE: the type of Arduino you’re using and the serial port your Arduino is connected to.

Identifying the Arduino type is easy, because it is printed on the board. Popular types are Duemilanove, Diecimila, Nano, Mega, Mini, NG, BT, LilyPad, Pro, or Pro Mini. In some cases you also have to check what microcontroller your Arduino uses. Most Arduinos use an ATmega168 or an ATmega328; you can find the microcontroller type printed on the microcontroller itself. When you have identified the exact type of your Arduino, choose it from the “Tools -> Board” menu.

Now you have to choose the serial port your Arduino is connected to from the “Tools -> Serial Port” menu. On Mac OS X, the name of the serial port starts with /dev/cu.usbserial (on my MacBook Pro it’s /dev/cu.usbserial-A60061a3). On Linux systems it should be /dev/ttyUSB0, /dev/ttyUSB1, or something similar depending on the number of USB ports your computer has.

On Windows systems it’s a bit more complicated to find out the right serial port, but it’s still not difficult. Go to the device manager and look for a “USB Serial Port” below the “Ports (COM & LPT)” menu entry (see illustration). Usually the port is named COM1, COM2, or something similar.

After you have chosen the right serial port, click the “Verify” button and you should see the following output in the IDE’s message area (the Arduino IDE calls programs “sketches”):

Binary sketch size: 888 bytes (of a 14336 byte maximum)

This means that the IDE has successfully compiled the source code into 888 bytes of machine code that we can upload to the Arduino. If you see an error message instead, check if you have typed in the program correctly.

While modern computers load programs from a hard drive, microcontrollers usually have to be programmed. That means you have to load your software into the microcontroller via a cable, and once the program has been uploaded it stays in the microcontroller until it gets overwritten with a new program. Now press the “Upload” button and after a few seconds you should see the following output in the message area:

Binary sketch size: 888 bytes (of a 14336 byte maximum)

This is exactly the same message we got after compiling the program, and it tells us that the 888 bytes of machine code were transferred successfully to the Arduino. In case of any errors, check if you have selected the correct Arduino type and the correct serial port in the “Tools” menu.

During the upload process the TX and RX LEDs will flicker for a few seconds. This is normal and it happens whenever the Arduino and your computer communicate via the serial port. When the Arduino sends information it turns on the TX LED. When it gets some bits it turns on the RX LED. Because the communication is pretty fast, the LEDs start to flicker and you cannot identify the transmission of a single byte (if you can, you are probably an alien).

As soon as the code has been transmitted completely, the Arduino executes it. In our case this means that the LED starts to blink. It turns on for half a second, then it turns off for half a second, and so on. Congratulations! You have just finished your first physical computing project!

Making LEDs blink is fun, but it’s more or less useless, right? Not if you let the right LEDs blink at the right frequency. If you replace the regular LED by an infrared LED and make it blink at the right frequency you can use it to control nearly every remote-controllable device in the world. So now I’ll show you how to control Apple’s Front Row with an Arduino. You can generalize this project to other kinds of remotes.

Build Your Own Remote Control

To control a device such as a TV set wirelessly you need a sender and a receiver. The receiver usually is built into the device to be controlled and the sender is part of a separate remote control. Although you can choose from a variety of technologies such as Bluetooth or WiFi, most modern remote controls still use infrared light for communication.

In the next figure you can see a circuit diagram for a simple infrared sender. You might ask yourself why we could not simply replace the LED from our “Hello, World!” example with an infrared LED and why we have to use a resistor, a breadboard, and some wires now.

There are many reasons for this. First of all, we no longer can use pin 13, because the library we’re using later on expects the infrared LED to be connected to pin 3. The distance between pin 3 and the next ground pin is too big for regular LED connectors, so you cannot directly plug the LED into the Arduino board. So we have to use a breadboard and some wires.

Why do we have to add a resistor, and what is a resistor? A resistor limits the amount of current that flows through an electric connection. In our case it protects the LED from consuming too much power, because this would destroy the LED. You always have to use a resistor when powering an LED! By the way: when we connected the LED directly to the Arduino we did not have to use a resistor, because pin 13 comes with an internal one.

Connecting parts such as LEDs directly to the Arduino is only an option in the most trivial cases. Usually, you will prototype your projects on a breadboard that you connect to the Arduino. A breadboard “emulates” a circuit board. You don’t have to solder parts to the board; instead, you can simply plug them into it.

Although the circuit looks more complicated now, you shouldn’t worry. Working with breadboards is very easy. They come in various types and sizes, but they all work the same way. They have a lot of sockets that you can use for plugging in through-hole parts or wires. That alone wouldn’t be a big deal, but the sockets are connected in a special way. In the next figure you can see how.

As you can see, most sockets are connected in columns. If one socket of a column is connected to a power supply, then automatically all the other sockets in this column are powered, too. On the bigger board in the photo, you can also see four rows of connected sockets. This is convenient for bigger circuits. Usually, you connect one row to your power supply and one to the ground. This way you can distribute power and ground to any point on the board.

So build the circuit, that is plug all wires and parts into the breadboard and into the Arduino. The direction of the resistor is irrelevant, but be careful with the LED. Connect its longer connector to the wire that goes into pin 3. Now we only need some software to bring our remote control to life!

The Remote Control Software

Using infrared light for transmitting signals has several advantages. It is invisible for human beings, so it does not disturb you. Also you can generate it cheaply with infrared LEDs that can be integrated easily into electronic circuits. So, for many purposes such as controlling devices in a typical household it’s an excellent choice.

But it also has some drawbacks. For example, it does not work through walls or doors and the distance between the remote control and the operated device is fairly limited. Even more important: the infrared signal is subject to interference with other light sources.

To reduce possible distortions caused by other light sources to a minimum the infrared signal has to be modulated. That means that you turn the LED on and off at a certain frequency, usually somewhere between 36 KHz and 40 KHz.

In practice it’s complicated to build a robust infrared remote control. The biggest problem is that many vendors invented countless incompatible protocols. They all use different frequencies and they all interpret data differently. For example, some interpret “light on” as a 1 bit while others treat it as 0. Also they all define their own commands that have different lengths, too.

We could try to generate the infrared signals ourselves, but that’d be tedious and error-prone. It’s better to use the existing implementation in the IRremote library. It hides all the nasty details and supports the most popular infrared protocols.

Many libraries for many different purposes are available already for the Arduino. Installing them is easy, because usually you only have to unpack a ZIP file and copy it to a certain folder. So download and extract the IRremote library file, copy the directory IRremote to ~/Documents/Arduino/libraries (on a Mac) or My Documents\Arduino\libraries (on a Windows box). Then restart your IDE.

Now we will use the IRremote library to create our own AppleRemote class that encapsulates all the gory remote control protocol details. The class looks like this:

arduino/AppleRemote/AppleRemote.pde

#include <IRremote.h>

class AppleRemote {

enum {

CMD_LEN = 32,

UP      = 0x77E15061,

DOWN    = 0x77E13061,

PLAY    = 0x77E1A05E,

PREV    = 0x77E1905E,

NEXT    = 0x77E1605E,

MENU    = 0x77E1C05E

};

IRsend mac;

void send_command(const long command) {

mac.sendNEC(command, CMD_LEN);

}

public:

void menu() { send_command(MENU); }

void play() { send_command(PLAY); }

void prev() { send_command(PREV); }

void next() { send_command(NEXT); }

void up()   { send_command(UP);   }

void down() { send_command(DOWN); }

};

As you can see the Arduino actually understands C++. People sometimes seem to be a bit irritated when it comes to the programming language they have to program the Arduino in. That’s mainly because the typical sample sketches look as if they were written in a language that has been designed for programming the Arduino. But that’s not the case; it is C++ (which implies that it supports C, too).

The code starts with an enumeration that contains all the constants we need; that is, the length of each control code (Apple Remote codes are 32 bits long) and the control codes themselves. I have used an infrared sensor and an original Apple Remote to detect the control codes. To learn more about this process have a look at my upcoming book Arduino: A Quick-Start Guide.

After the enumeration we define an IRsend object named mac that we’ll use to send commands using the send_command method. send_command uses IRsend’s sendNEC method because the Apple Remote uses the NEC protocol. This is only one of countless infrared protocols and for every remote control you want to emulate you have to check which protocol it uses (IRremote supports NEC, Sony, RC5, and RC6).

Now that we have established the basis we can implement all commands with a single function call, so implementing methods such as menu, play etc. is a piece of cake.

Using the AppleRemote class is easy, too. In the following sketch we use it to control a Mac via a serial port:

arduino/AppleRemote/AppleRemote.pde

AppleRemote apple_remote;

void setup() {

Serial.begin(9600);

}

void loop() {

if (Serial.available()) {

const char command = Serial.read();

switch(command) {

case 'm':

Serial.println("menu");

apple_remote.menu();

break;

case 'u':

Serial.println("up");

apple_remote.up();

break;

case 'd':

Serial.println("down");

apple_remote.down();

break;

case 'l':

Serial.println("prev");

apple_remote.prev();

break;

case 'r':

Serial.println("next");

apple_remote.next();

break;

case 'p':

Serial.println("play");

apple_remote.play();

break;

default:

break;

}

}

}

We define a global AppleRemote object named apple_remote and in the setup function we initialize the serial port. We set it to a baud rate of 9,600 calling the begin method of the Serial class. This is a standard class that comes with the Arduino software. It allows you to easily send and receive data via a serial port, that is the USB port you have connected the Arduino to.

In loop we wait for new data on the serial port calling available. Whenever a new byte arrives we read it by calling read and then we check if it’s one of the characters m, u, d, l, r, or p. Depending on the character we have received we send the control code for menu, up, down, previous, next, or play accordingly. Also we output the name of the key we’re emulating to the serial port.

Compile and upload the sketch and you can control a Mac using a serial terminal. You could use any serial terminal such as screen or Putty, but we’ll use the one that comes with the Arduino IDE. Click the right-most icon in the IDE’s toolbar. An empty serial monitor window will open. It allows you to send data to the Arduino. You only have to enter some text and press the “Send” button.

In the next figure you can see how the serial monitor looks after I have navigated to my favorite playlist in Front Row. I had to enter m, d, d, p, d, d, d, d, d, d, d, d, d, d, p, p. Don’t forget to press the “Send” button or hit the return key after entering every character.

So point the infrared LED to your Mac (you can bend it to a right angle, if you want to) and enter some commands. If it doesn’t work you should reduce the distance between your Mac and the LED. Also you should unpair any other remote controls in the security area of the Mac’s system preferences menu.

Where to Go From Here

In this article we could only scratch the surface of the exciting field of physical computing. Still you should know now what the Arduino project is all about. With minimal effort and costs you can build your own electronic gadgets that might even serve a useful purpose.

Making LEDs blink is only the beginning and you can build quite sophisticated projects ranging from toys to robotics or home automation. Also there are countless extension shields available for the Arduino. They make it extremely easy to add Ethernet or even an OLED touch screen to your project.

So the next time you think “It’d be cool if someone would build this,” just do it! Build it!

Maik Schmidt has worked as a software developer for more than fifteen years, creating solutions for large enterprises. He frequently writes book reviews and articles and is the author of Enterprise Recipes with Ruby and Rails and Enterprise Integration with Ruby. He is finishing Arduino: A Quick-Start Guide as this issue goes to press. Send the author your feedback or discuss the article in the magazine forum.

Not Quite New in iOS 4

Three New-to-You Features for iPhone Developers
by Daniel H Steinberg
Three unsung developer features of iOS 4 will make your life easier and change your code dramatically: blocks, gestures, and properties without ivars.

Apple has released iOS 4, the latest version of its mobile operating system, and by now you’ve heard over and over that iOS 4 has multitasking. You’ve also heard about iAds and a handful of other features that Apple is focusing their message on. But there are three unsung developer features of iOS 4 that will make your life easier and change your code dramatically: blocks, gestures, and properties without ivars. All of these are new for iPhone developers. The first was introduced with Mac OS X Snow Leopard, the second with the iPad release, and the third is the result of a change in the iPhone simulator.

iVar-Free Properties

Properties without iVars? That may sound like a minor change, but it’s really freeing. Let me show you what I mean.

I’ve created a simple view-based project for iPhone 4 and named it “MoveMe.” I’ve set the view’s background color to be black and added an image view at the top left of the screen containing a PNG of last month’s PragPub cover.

We’re going to animate a few properties of the view and the image view, so we need an outlet for the image view. Here’s how you would have added the property in the old days. You would have declared an instance variable and the corresponding property in the view controller’s header file like this:

#import <UIKit/UIKit.h>

@interface MoveMeViewController : UIViewController {

UIImageView *imageView;

}

@property(nonatomic, retain) IBOutlet UIImageView *imageView;

@end

All that’s left is to synthesize the property in the implementation file and connect the outlet in the nib and you’re off and running. You can communicate with the image view and move it around the screen, change its opacity, etc.

One advantage in the Xcode 3.2.3 release that accompanied the iPhone 4 SDK release is that we now have a simulator built on the modern runtime. The result is that we can declare the property without specifying the underlying ivar, like this:

#import <UIKit/UIKit.h>

@interface MoveMeViewController : UIViewController {

}

@property(nonatomic, retain) IBOutlet UIImageView *imageView;

@end

The runtime will synthesize the instance variable for you. You should, however, take care to address the property and not the underlying variable. In other words, for the most part you should use self.imageView and not imageView to send messages to the image view.

It turns out that you could always do this for iPhone development if you were only running your apps on the device. This feature was not available on the simulator until this most recent release. Feel free to leave out the backing ivars even if you are targeting iPhone 3.1.3 or below so long as you are using the latest simulator.

If you use the latest release of LLVM for development you can also configure your project to synthesize your properties by default. In other words you won’t even have to include the @synthesize to get the compiler to generate your getter and setter in the implementation file. There is currently a bug in LLVM that prevents you from addressing the synthesized variables (which you need to do, for instance, in the dealloc), but a fix is on its way.

Gestures

For the next step in our little animation project, let’s look at gestures. Eric Freeman, my co-author on our iPad book wrote a great chapter on Gestures. The same APIs introduced for the iPad are now available on the iPhone.

Imagine you wanted to implement a horizontal swipe before the new Gesture APIs were introduced. You would have had to implement the delegate methods touchesBegan:withEvent: and touchesEnded:withEvent. You’d then have had to check that the user moved their finger enough to the right or to the left and not too much up or down so that it truly was a swipe. There was no standard way of doing this, so a swipe in my app and a swipe in your app might be completely different motions.

One benefit of the new Gesture APIs is that Apple has standardized what these common gestures feel like to the end user in all apps. This brings a uniformity to the user experience on the iPhone. A second benefit is that it is much easier to respond to a swipe. Here’s how we’d create and register a swipe to the right:

-(void) registerSwipeToTheRight {

UISwipeGestureRecognizer *rightSwipeRecognizer =

[[UISwipeGestureRecognizer alloc]

initWithTarget:self

action:@selector(userDidSwipeRight)];

rightSwipeRecognizer.direction = UISwipeGestureRecognizerDirectionRight;

[self.view addGestureRecognizer:rightSwipeRecognizer];

}

This creates a swipe gesture recognizer that will call the method named userDidSwipeRight. We configure it to respond only to horizontal swipes to the right and add it to the view. Next let’s look at what sort of animation you might add when the user swipes right.

Blocks

We’ll take advantage of blocks when we implement the animation in our project. Apple is introducing blocks almost everywhere they can. We saw this last year with the Snow Leopard APIs, and this year the iPhone 4 APIs are following suit. I’ve written an entire chapter on blocks in my Cocoa programming book but I’d like to show you a simple example of how you might use them.

Suppose when the user swipes to the right we perform the following animation. Let’s take two seconds to change the view’s background color from black to white and move the cover down to the bottom right corner in the userDidSwipeRight method:

-(void) userDidSwipeRight {

[UIView beginAnimations:@"swipe right" context:nil];

[UIView setAnimationDuration:2];

self.view.backgroundColor = [UIColor whiteColor];

self.imageView.frame = CGRectMake(220, 320, 115, 146);

[UIView commitAnimations];

}

This is a pretty familiar-looking animation. The animation consists of two actions: changing the view’s background color to white and changing the image view’s position to the bottom right corner of the screen. We set the animation to last for two seconds and then we enclose it all in between beginAnimations and commitAnimations.

I’m not going to explain blocks at all—I just want to show you this example and hopefully you’ll think “wow, that’s cool” and head off to learn some more about blocks. With blocks, the previous animation is implemented like this:

-(void) userDidSwipeRight {

[UIView animateWithDuration:2

animations:^{

self.view.backgroundColor = [UIColor whiteColor];

self.imageView.frame = CGRectMake(220, 320, 115, 146);

}];

}

This time we use the animateWithDuration:animations method and we pass in a block as the second argument (the ^ signifies the beginning of the block). All that is to be animated is contained between the curly braces. Look back and forth between the two versions of the animation and I think you’ll begin to see how blocks turns some of your traditional coding patterns on their head.

You can get a lot fancier. Suppose, for example, you want to chain two animations together. Use the animateWithDuration:animations:completion method and put the second animation in the completion block. You can continue the pattern and chain as many animations together as you like. Here I’ve faded the cover image as I’ve moved it and then set the alpha back to one when the first animation is complete:

-(void) userDidSwipeRight {

[UIView animateWithDuration:2

animations:^{

self.view.backgroundColor = [UIColor whiteColor];

self.imageView.frame = CGRectMake(220, 320, 115, 146);

self.imageView.alpha = .3;

}

completion:^(BOOL finished){

[UIView animateWithDuration:2

animations:^{

self.imageView.alpha = 1;}];

}];

}

If you’re not familiar with blocks, they will look odd at first. But take the time to get familiar with blocks, as Apple has added methods all over the Cocoa frameworks that are built to handle blocks. You’ll pass blocks off to collections to sort them or perform the same operation on the various elements. You’ll use blocks with Game Center and iAds, and familiar APIs such as the animation methods we’ve looked at here now have variants that can take blocks.

I’ve used this simple example to show you how to drop the ivars that back your properties, how to use the new gesture recognizers, and how to begin the path of embracing blocks. Enjoy.

Daniel is a podcaster, author, coder, and trainer at dimsumthinking.com. He is the co-author of the Prags’ iPad book and author of the book on Cocoa programming. He teaches iPhone and Cocoa programming for the Pragmatic Studios. Mostly he loves hanging out in the kitchen or the back yard with his wife and daughter. Send the author your feedback or discuss the article in the magazine forum.

TDD on iPhone: DIY

You Really Can Use Test Driven Development in Creating iPhone Apps
by Eric Smith
If you’re trying to do quality iPhone development, TDD is not optional. Fortunately, it is also not impossible.

Test Driven Development (TDD) has an uncertain relationship with iPhone development. OCUnit and Unit Test targets were not added to the XCode development toolkit until late in the game and much of the Cocoa and UIKit frameworks used by iPhone developers every day were not developed with unit testing in mind. A look around the web will find you developers who have become so frustrated with the process they simply gave up.

The situation is unfortunate and familiar. In the years before I came to my senses I wrote C and C++ code on Windows, and it was hardly easy to write tests then. When developers wrote their first Win32 program did they say, “Unit Testing isn’t integrated with the environment. I give up!” Well yes, many of them did, but not the good ones, and now the developer working in those languages and on that beloved platform no longer has to worry about too few options, but too many.

The same process is repeating itself in iPhone development. OCUnit now runs on iPhone, and is built into XCode. Even before that the Google Toolbox for Mac (GTM) had been released, and for a unique implementation you can try out GHUnit, which displays the results on the phone itself. OCMock worked on the iPhone almost immediately, and Cocoa itself actually isn’t as resistant to unit testing as originally thought, if you’re willing to be patient.

To demonstrate, let’s work through a fun sample application on the iPhone.

Prerequisites

To get started with your first Test Driven iPhone application you’ll need a Mac with a few things installed:

- XCode—preferably the most recent version.

- The iPhone SDK, again hopefully the most recent version.

This is not an article on Objective-C or iPhone development, so I’ll assume at least a cursory familiarity with the toolset. Hopefully even iPhone novices will be able to follow along, and this article is meant to be done with a computer in front of you. At times I’ll be skipping simple steps, so just copying the code snippets isn’t going to produce a working program and besides copying and pasting the code is just cheating. Do cheaters ever prosper? Don’t answer that.

Setting Up Unit Testing

There are several options for unit testing iPhone applications. My personal preference is the Google Toolbox because it gets features faster than OCUnit, but that isn’t to denigrate either of those other excellent projects, or any other Unit Testing framework I may have missed. It’s simply the one I’m most comfortable with. In addition I’ve made a couple of Unit Test templates that will make getting set up with GTM a snap. To install the templates from my git repository, run the following at the command prompt:

git clone http://github.com/paytonrules/iPhoneTemplates.git

cd iPhoneTemplates

sudo ./install_template

The sudo is necessary because the templates are installed in a system directory. Now we can easily create a new project with Unit Testing built in. Start up XCode and create a New Project. That screen will give you your choice of projects, and you should see a new category under iPhone OS called Google Toolbox. Choosing it will show you two templates for Unit Testing (OpenGL ES and View Based Application). Why only those two, and not the plethora of other templates offered by Apple with Unit Tests attached? Because I’m selfish—these are the templates I use. If you someday make your own, please make a pull request on the github repo.

Some Ping Pong

Create a View Based template by selecting it and clicking choose, then name your project PingPongScorer, since we’ll be writing a simple program to score a ping pong game. It will keep track of score, serve, and display a winner. Go ahead and build the project; you should see no errors and no warnings.

Let’s make the front end of this application look the way we want it to. Open the file MyCurrentViewLocationViewController.xib and make your view look something like this:

I can think of a few stories to implement:

- When you touch either score, increment the point total by 1.

- When any two points occur, the serve should switch sides.

- When either player reaches 11 points, there should be an alert announcing the winner.

- New Game should set both players points to 0 and the server to player 1.

None of this should be particularly difficult to do, especially for smart guys like us, so let’s get started by creating a test case. Choose File->New and select the GoogleToolbox entry under iPhoneOS, then select the Google Toolbox test case. We’ll start by writing tests for the controller since it responds to the touch events and we’re working outside-in. Name the file PingPongScorerViewControllerTest and make sure the file is only in the Unit Test target. Now build the project again and you should see the build fail. If you open the error you’ll see that the code compiles but the template we’re using starts with a failing test. Note that in GTM all test cases inherit from GTMTestCase and all tests are methods that begin with the word test. So when you built your program it ran all the unit tests as a post-build step and failed.

We’ll replace that test and start by writing the test that seems simplest to me—incrementing the score for player one. Let’s call scorePlayerOnePoint once, and verify that the new score is 1.

-(void) testScorePlayerOnePointUpdatesPlayerOneTextOkay

{

PingPongScorerViewController *controller =

[[[PingPongScorerViewController alloc] init] autorelease];

controller.playerOneScore = [[[UIButton alloc] init] autorelease];

[controller scorePlayerOnePoint:nil];

STAssertEqualStrings(controller.playerOneScore.currentTitle,

@"1", nil);

}

You’ll get an error because the property playerOneScore doesn’t actually exist yet, and another because scorePlayerOnePoint doesn’t exist. Normally I would have stopped at the method call, then implemented just enough to compile, then come back and finished the test, but for the sake of brevity I’ve done this all in one step. Let’s look at the assertion STAssertEqualStrings, one of the many built into GTM. It takes the actual value for its first parameter, and the expected value for the second. In this case we are checking against the UIButton playerOneScore’s currentTitle field. That’s a read-only property on UIButtons, and I’ll show you how to change it in a second. I also pass in nil for the third argument, which is an optional string format for the error message. If you pass in nil you’ll get the default, which is usually good enough. I’ve also gone ahead and added this controller to the autorelease pool for now, since this the only place I’m using it. Looking at the scorePlayerOnePoint message you’ll see I pass in nil; that’s because all Cocoa actions take the sender as a parameter, but I don’t actually care what the sender is for my implementation. Let’s make this pass in the simplest way possible.

-(void) scorePlayerOnePoint:(id) sender

{

[playerOneScore setTitle:@"1" forState:UIControlStateNormal &

UIControlStateHighlighted & UIControlStateSelected];

}

That’s a mouthful for simple isn’t it? To set the title for a UIButton you actually set it for a state—but in this case we want to set it for all the states (normal, highlighted and selected) so we bitwise and the flags together. The simple part is the hard-coded “1”. That was pedantic of me, wasn’t it, but this is an excellent example of why I do that. I didn’t have the API for setTitle memorized and had to try it several times before I got it right. By hard-coding in a one I was able to narrow down the reasons why the test wasn’t passing to just the API call. This is also why we don’t mock out UIKit objects: we really do need to know it’s calling the real object and working correctly. Now I’m going to write another test to triangulate—what happens when the player scores twice?

-(void) testScoreTwiceUpdatesPlayerOneTextToTwo

{

PingPongScorerViewController *controller =

[[[PingPongScorerViewController alloc] init] autorelease];

controller.playerOneScore = [][[UILabel alloc] init] autorelease];

[controller scorePlayerOnePoint:nil];

[controller scorePlayerOnePoint:nil];

STAssertEqualStrings(controller.playerOneScore.currentTitle,

@"2", nil);

}

Aha, a failing test, now I can write the real implementation.

-(void) scorePlayerOnePoint:(id) sender

{

int newValue = [playerOneScore.currentTitle intValue] + 1;

[playerOneScore setTitle:[NSString stringWithFormat:@"%d", newValue]

forState:UIControlStateNormal & UIControlStateHighlighted

& UIControlStateSelected];

}

We now have a simple way to make player one score, so I’ll go ahead and make player two score now so I can wire this up in Interface Builder (IB) and see some action. Here are my tests and code:

#import "PingPongScorerViewController.h"

@implementation PingPongScorerViewController

@synthesize playerOneScore, playerTwoScore;

-(void) scorePlayerOnePoint:(id) sender

{

int newValue = [playerOneScore.currentTitle intValue] + 1;

[playerOneScore setTitle:[NSString stringWithFormat:@"%d", newValue]

forState:UIControlStateNormal & UIControlStateHighlighted

& UIControlStateSelected];

}

-(void) scorePlayerTwoPoint:(id) sender

{

int newValue = [playerTwoScore.currentTitle intValue] + 1;

[playerTwoScore setTitle:[NSString stringWithFormat:@"%d", newValue]

forState:UIControlStateNormal & UIControlStateHighlighted

& UIControlStateSelected];

}

-(void) dealloc

{

[super dealloc];

}

@end

#import "PingPongScorerViewControllerTest.h"

@implementation PingPongScorerViewControllerTest

-(void) setUp

{

controller = [[PingPongScorerViewController alloc] init];

controller.playerOneScore = [[[UIButton alloc] init] autorelease];

controller.playerTwoScore = [[[UIButton alloc] init] autorelease];

}

-(void) tearDown

{

[controller release];

}

-(void) testScorePlayerOnePointUpdatesPlayerOneText

{

[controller scorePlayerOnePoint:nil];

STAssertEqualStrings(controller.playerOneScore.currentTitle, @"1", nil);

}

-(void) testScoreTwiceUpdatesPlayerOneTextToTwo

{

[controller scorePlayerOnePoint:nil];

[controller scorePlayerOnePoint:nil];

STAssertEqualStrings(controller.playerOneScore.currentTitle, @"2", nil);

}

-(void) testScorePlayerTwoTwiceUpdatesPlayerTwoTextTwoTwo

{

[controller scorePlayerTwoPoint:nil];

[controller scorePlayerTwoPoint:nil];

STAssertEqualStrings(controller.playerTwoScore.currentTitle, @"2", nil);

}

@end

Ohhh the duplication, it burns—but before we fix that, let’s look at a few things about this. Take note of the setUp and tearDown methods. Like many other XUnit based frameworks, GTM will allow you to create a setUp method that will be run before every test, and a tearDown that is executed after. If you name the methods that they are called as you’d expect. The controller itself is now defined as an iVar in the class definition so that we stop defining it in every test. This means we need to do a proper alloc and release rather than using autorelease. It also turns out my hunch was right—what I really want is a controller that contains two player classes and that shuffles the data between the players and the UIButtons. At this point we have several options. We can do the extract class refactoring, and keep the tests here. We can test-drive new objects, then insert them, then switch these to mocks. We can throw this out and start over even, I suppose. This isn’t a straight extract class refactoring however, so what we’ll do is start writing the Player interface through a mock object, then change the previous tests to use the stubs instead of doing math and converting back and forth. This has the advantage of demonstrating one way to use mocks when doing TDD on the iPhone. Here’s the next test.

-(void) testPlayerOneIsScored

{

controller.playerOne = [[[MockPlayer alloc] init] autorelease];

}

This time we really will stop when the test doesn’t compile. The reason is that this test fails is that I don’t have a playerOne property or a MockPlayer class. Let’s make the first half of that pass. Here’s how my playerOne object is defined in the controller class.

@interface PingPongScorerViewController : UIViewController

{

...

NSObject<Player> *playerOne;

}

@property(nonatomic, retain) NSObject<Player> *playerOne;

...

@end

See how the player is defined—NSObject<Player>. That means this is an object of type NSObject conforming to the protocol Player. A protocol is just Objective-C for interface and is made up of a list of methods that this object will respond to. I could actually define this object as a type of id, which means it could be anything as long as it conforms to the protocol, but I use NSObject instead. The reason is that I know I’ll be using at least one NSObject method on this class, release, and all objects in Cocoa inherit from NSObject anyway.

Let’s go ahead and create the Protocol using File->New->Cocoa Touch Class->Objective-C protocol. XCode only recently added the protocol choice to that menu, so if you don’t have it just choose a C header file. Name it player, and if you chose the Objective-C Protocol the file should contain the code below. If it doesn’t already, add it.

#import <UIKit/UIKit.h>

@protocol Player

@end

You’ll also need to import the player in the header file for PingPongViewController. This should leave you with one error after building—MockPlayer undeclared. Go ahead and create the class, making sure it inherits from NSObject and implements the Player protocol. It also should only belong to the Unit Tests project. The new class doesn’t have any methods because we haven’t had a reason to create them. I’ll point out now that the reason we’re hand-rolling this mock object instead of using OCMock is entirely personal preference. I have used OCMock before, and it’s an excellent framework, but its use is outside the scope of this article.

Let’s test-drive this object’s interface into existence. When the action scorePlayerOne is called, I want player one to...score. That’s simple. I’ve made the earlier incomplete test into this.

-(void) testPlayerOneIsScored

{

MockPlayer *player = [[[MockPlayer alloc] init] autorelease];

controller.playerOne = player;

[controller scorePlayerOnePoint:nil];

STAssertTrue(player.scored, nil);

}

One of the advantages of rolling your own mocks is that you can still have the setup, execute, check order in your tests. We’ve got a new assertion too, STAssertTrue, which is the root assertion from which all others spring forth. You’ll get a compiler error because scored isn’t set on the mock object, so let’s set that up with a simple property. Once you create the property you should see a failure again. You’ll see on STAssertTrue that the default error message really isn’t good enough—it says something like

error: -[PingPongScorerViewControllerTest testPlayerOneIsScored] :

'player.scored' should be TRUE.

That's pretty generic, and for true false assertions I like to put i some more readable text. Change the assertion to read as follows:

STAssertTrue(player.scored, @"Player should have scored, but didn't.");

You’ll still get that ugly error message from before, but the message you wrote in will be appended to the end of it. To make this test pass, let’s go ahead and write a little method called score that just sets the Mock object’s scored property. This method is in the MockPlayer.

-(void) score

{

scored = YES;

}

Do you see what we did there? We just defined a method we’ll need in our interface, in the terms of the code using it, without actually implementing the real object. Very cool. Let’s get the method into the protocol:

@protocol Player

-(void) score;

@end

That was tough. Our test is still failing, so call score in the scorePlayerOnePoint method.

-(void) scorePlayerOnePoint:(id) sender

{

int newValue = [playerOneScore.currentTitle intValue] + 1;

[playerOneScore setTitle:[NSString stringWithFormat:@"%d", newValue]

forState:UIControlStateNormal & UIControlStateHighlighted

& UIControlStateSelected];

[playerOne score];

}

Next we need to make sure that we call score and then set the button’s text to the not-yet-existent currentScore property on the PlayerOne object. Doing that will mean breaking the previous tests, and I don’t want to do that, so now I’m going to test-drive a CurrentPlayer class, which will also use the Player protocol. That’s a very straightforward class so I’m not going to go step by step through it right now. I trust you can do it; just remember to keep CurrentPlayerTest in only your UnitTests target, but put CurrentPlayer in both targets.

Are you done? Let’s start integrating our new player object with the code. Change the testScorePlayerOnePointUpdatesPlayerOneText in the view controller to read as follows.

-(void) testScorePlayerOnePointUpdatesPlayerOneText

{

MockPlayer *player = [[[MockPlayer alloc] init] autorelease];

[player setCurrentScore: 10];

controller.playerOne = player;

[controller scorePlayerOnePoint:nil];

STAssertEqualStrings(controller.playerOneScore.currentTitle, @"10", nil);

}

Now in this test we set the current score on the mock object, and we verify that’s what the button’s title is changed to after the call. We’re using an explicit setter for the currentScore because we’re going to define currentScore as readonly in the protocol. That’s not strictly necessary but there’s no reason to add a setter on the real object either since only the tests want to explicitly set the score. We immediately get a warning that player may not respond to this message, so let’s go implement it.

@protocol Player

...

@property(readonly) int currentScore;

@end

// The new method on MockPlayer

-(void) setCurrentScore:(int)newScore

{

currentScore = newScore;

}

@interface MockPlayer : NSObject<Player> {

BOOL scored;

int currentScore;

}

@property BOOL scored;

-(void) score;

-(void) setCurrentScore:(int)newScore;

Now indeed upon reflection these mocks are a little close to the implementation of the real objects, and I could have used real objects for testing, but I’m going to stick with the mocks because a) it’s an exercise and b) it’s decoupled the implementation of scoring from the controller. When we make this test pass, the controller will no longer know that the score is worth a point, and that decoupling is worth a small amount of indirection. Speaking of which, let’s make it pass.

-(void) scorePlayerOnePoint:(id) sender

{

[playerOneScore setTitle:

[NSString stringWithFormat:@"%d", playerOne.currentScore]

forState:UIControlStateNormal & UIControlStateHighlighted

& UIControlStateSelected];

[playerOne score];

}

When we make this test pass, the testScoreTwiceUpdatesPlayerOneTextToTwo fails because it doesn’t make sense anymore. The View Controller doesn’t do math, so you can delete that test. I assume you have a similar test in your Current Player class. You do, right? Unfortunately this passing code is still wrong because score needs to be called before the text is set. We can encode that into the mock. The currentScore getter (Objective-C novices—properties are just getters and setters generated for you by the compiler) will always return 0 unless score is called first.

// Make sure you do not @synthesize

// the currentScore property anymore.

-(int) currentScore

{

if (scored)

{

return currentScore;

}

else

{

return 0;

}

}

When we do that, testScorePlayerOnePointUpdatesPlayerOneText fails as it should. Let’s flip the order of the calls to score and currentScore to see the tests go green. Once again I will leave updating Player2 up to you. You may want to use a method like updateScreen to update both screen items from their player objects.

-(void) updateScreen

{

playerOneScore.titleLabel.text =

[NSString stringWithFormat:@"%d", playerOne.currentScore];

playerTwoScore.titleLabel.text =

[NSString stringWithFormat:@"%d", playerTwo.currentScore];

}

Now we have a true controller that updates objects and refreshes the screen. We only have one more thing left to deal with before we wire this up. Experienced Objective-C programmers are banging their heads against the table right now muttering, “but... but... the memory!” and yes, it’s true that this program has memory leaks. None of the objects on the controller are released as they should be. Test-driving memory management in Objective-C can be done in two ways. The first is to add memory leak detection to your test suite, which GTM has built in, but the problem is that many of Apple’s own frameworks leak or get reported as leaks, so it can become impossible to discern the real leak you created. Instead we’ll be checking the retain count of each object after we delete the controller. Here’s our next test.

-(void) testPlayerOneIsReleasedWhenTheControllerIsReleased

{

NSUInteger expectedRetainCount = 1;

MockPlayer *player = [[MockPlayer alloc] init];

controller.playerOne = player;

[controller release];

controller = nil;

STAssertEquals([player retainCount], expectedRetainCount, nil);

[player release];

}

This test is pretty complicated, so let’s take a minute to explain. This test creates a player and sets it on the controller. When we call alloc the retain count of the object is set to 1, and when we set the playerOne property, the retainCount goes to 2 because the property is declared with the retain flag. When we release the controller it should release the playerOne object in its dealloc method because it retained it, but it doesn’t, so our test fails. We’re using STAssertEquals here, which checks an actual value vs. an expected value. Finally we release the test’s copy of the player after the assertion. To make this pass, just release the playerOne object in the controller’s dealloc method.

Once you have that passing, write tests for playerTwo, playerOneScore and playerTwoScore. We should encapsulate that check into the method below.

-(void) assertOwnedObjectisReleased: (NSObject *) object

{

[object retain];  // Retain the object to guarantee we own it

NSUInteger expectedRetainCount =  [object retainCount]—1;

[controller release];

controller = nil;

STAssertEquals([object retainCount], expectedRetainCount, nil);

[object release];

}

I’ve cleaned it up a little bit from the original implementation and with a little more work we could probably turn this into a generic exception we use everywhere. Then each of the tests for deletion is just one line of code.

-(void) testPlayerTwoIsReleasedWhenTheControllerIsReleased

{

[self assertOwnedObjectisReleased: controller.playerTwo];

}

The errors will show up in the editor in the assertOwnedObject method, and not in the test as we’re accustomed to, but if you look at the build output you can see where the error actually occurs.

The controller is releasing all the objects it owns, so we’ll have to create both the buttons and the players in the setUp method, which is appropriate since when we run the application it will do the same thing.

Seeing the app

Let’s wire up the view in IB with the objects we have and see how the program is working so far. In order to do that in IB we’ll need to add some macros to the PingPongScorerViewController.h file so that it can see our outlets and actions. Here’s what PingPongViewController.h looks like after the changes:

@interface PingPongScorerViewController : UIViewController

{

IBOutlet UIButton *playerOneScore;

IBOutlet UIButton *playerTwoScore;

IBOutlet NSObject<Player> *playerOne;

IBOutlet NSObject<Player> *playerTwo;

}

-(IBAction) scorePlayerOnePoint:(id) sender;

-(IBAction) scorePlayerTwoPoint:(id) sender;

...

When you build and run the tests, you won’t get a failure because IBAction and IBOutlet don’t actually change any behavior, they just make it possible for IB to find them. Now go ahead and open up PingPongScorerViewController.xib. One of my favorite things about it is that you can add any objects to the XIB file, not just UI objects. This means we can inject any dependencies here: our code is none the wiser. Dependency Injection without XML, hooray! In the Library, choose the Object type, and drag it over to the Document window. Double-click that object to open its Inspector, click the Identity tab, and change the class to CurrentPlayer. Do this a second time for player two. You can use the name field to make the two objects easy to tell apart. Your Document window should look something like this:

Now when this view controller is loaded, those two players will be created and we just connect them to the view controller. Hold Ctrl and drag from the File’s Owner object, which is our PingPongScorereViewController, to Player One. You should get a little dialog with outlets and playerOne should be a choice. Do the same for Player Two, and both buttons. Finally we need to create actions for both buttons, so again Ctrl-Drag from each button to the File’s Owner and select scorePlayerOne and scorePlayerTwo as appropriate. Open the File’s Owner inspector and click the outlets icon. If you’re wired up correctly you should see something like this.

Now build and run the app. When you click the buttons in the simulator they should increment. Story number one complete!

Conclusion

Sadly our time here is up, but I’ll be continuing this app on my github account at github.com/paytonrules/PingPongScorer.git. We’ve taken a bit of a circular route to get here, we’ve done some refactorings, we’ll do more. We’ve tested memory leaks, we’ve used Protocols, and we’ve written the beginnings of an application in iPhone. Hopefully it’s clear that if you’re trying to do quality iPhone development that TDD is not optional, nor is it impossible or really much more difficult than normal development.

Exercises for the Reader

- Continue implementing the stories above, naturally.

- Try doing the implementation by extracting the class instead of test-driving a new object, and see where it leads you.

Upon writing the two player models I realized I still had duplication, just of a different sort, between the objects and the buttons. Rather than manually shuttling the value from the player object to the view, we could solve this by setting up key-value observing. This is a more advanced test, but is definitely doable. The key is to remember you’re testing that when the observed changes then the observer is changed.

Eric has over ten years software development experience, going back to when he started a web design company in college with a $500 scholarship. After graduating he took his first “real job” at the now defunct Mission Studios where he worked on JetFighter IV: Fortress America. After the company dissolved he moved on to Siemens Building Technologies, where he developed Windows applications both large and small on a two million-line legacy code base. He gained professional experience in C, C++, C# and learned Ruby. Since joining 8th Light Eric has worked on projects in Java, C++, and Ruby on Rails projects, and is pursuing his Masters Degree in Software Engineering at DePaul University. Send the author your feedback or discuss the article in the magazine forum.

BDD on iPhone: iCuke

iCuke Gives iPhone the Cucumber Treatment
by Rob Holland
Almost a year ago in these pages, Ian Dees showed how to use Cucumber to test your iPhone apps. Now iCuke makes it even easier.

Aslak Hellesoy’s Cucumber has seen huge success helping developers and project owners clearly communicate desired behavior in the Ruby on Rails arena.

Using the same concepts that enable Cucumber to test Web applications, Unboxed Consulting’s iCuke now makes it easy to test iPhone applications by providing a Web interface to the iPhone simulator and some predefined steps for common user actions such as typing text, tapping, or swiping.

Despite the growth of the iPhone development platform, there still aren’t many aids for integration testing, and what aids there are mostly require compiling extra code into your application and writing tests in Objective-C. Apple UI Automation instrument in SDK 4.0 is a start, but even it requires manual operation—and it’s no use in CI environments.

iCuke is different from previous solutions in that it doesn’t require compiling extra code into your application or adjusting your Xcode project to add new targets. Once you install the iCuke gem, you can start writing tests straight away, without any changes to your application.

If you’ve used Capybara or Webrat to test Web applications with Cucumber, you should be right at home using iCuke.

For this article I’ll assume that you’re familiar with Cucumber. But if you haven’t used it before, you can find a wealth of information at the Cucumber website.

Getting started

To get started testing your iPhone application with Cucumber, just install the iCuke gem and then run icuke . (note the period: that’s “icuke .”) in the iPhone application’s directory. This will set up Cucumber for the project with an example feature file to give you an idea of what is possible.

Let’s give it a go using one of Apple’s sample iPhone applications called QuickContacts. You can find QuickContacts by searching for it in the Xcode help system. Click the “Open Project in Xcode” button and choose somewhere to save the project.

Once you have the project open, hit Build and Run, and Xcode should compile the application and then launch it in the simulator.

Now that we have an application, let’s get iCuke installed and start writing some tests for it.

Find your way to the application directory in Terminal and run icuke .. It will add a features directory with a feature file in it (along with the support and step_definitions directories, which we don’t need to touch just yet).

The example story won’t make much sense in relation to the application we’re working on, as it’s just a generic example. As the application is to manage contacts, a good first story might be to test adding a contact.

Have a quick look at the features/example.feature file to get a feel for the kind of stories you can write, but then you can delete the file.

Open up a new file features/add_a_contact.feature in your editor and paste this feature in:

Feature: Adding a contact

In order to remember my friend’s phone number

As a forgetful user

I want to add my friend to my contact list

Background:

Given "QuickContacts.xcodeproj" is loaded in the simulator

Scenario: Adding a contact

When I tap "Create New Contact"

And I type "Joe" in "First"

And I type "Bloggs" in "Last"

And I tap "Done"

And I tap "Display Picker"

Then I should see "Joe Bloggs"

Save the file and then try running cucumber from the application directory. You should see the application loading in the simulator and performing the steps in the story. When it’s done, cucumber should happily report that everything went as expected. Our first story passes!

You may notice, however, that if you run the story again, there are now two Joe Bloggs in the address book. This is because the iPhone simulator doesn’t wipe the address book between runs. In order to fix that, we’ll need to use an iCuke module, which we’ll discuss later on.

Getting more involved

Now that we have our first story passing, let’s make sure we can look up a contact again.

Open up a new file features/searching_for_a_contact.feature in your editor and paste this feature in:

Feature: Searching for a contact

In order to find my friend’s phone number

As a forgetful user

I want to find my friend in my contact list

Background:

Given "QuickContacts.xcodeproj" is loaded in the simulator

Scenario: Finding a contact

When I tap "Create New Contact"

And I type "Joe" in "First"

And I type "Bloggs" in "Last"

And I tap "Done"

And I tap "Display Picker"

And I type "Joe" in "Search"

Then I should see "Joe Bloggs"

Save the file and run cucumber again. That story should pass as well, so we can find a contact that we’ve added. But what if we had 20 people in the contact list? We could change the story so that we go through the motions of adding 20 contacts, but that would make the story quite long. We could wrap the steps up into a new step so we’re able to say “Given there are 20 contacts”. That would clean the story up, but it would take a long while to do all the tapping and typing to enter those contacts. If we want to speed things up we can take advantage of the fact that iCuke supports loading application-specific modules written in Objective-C.

As an aside, you will notice that iCuke seems to pause quite a lot between actions. This is because it’s very difficult for iCuke to know when the application has finished transitions between views or updated the screen in reaction to an event. Unfortunately, this means being very conservative speed-wise to ensure that we don’t try to begin an action before the application is ready. Hopefully future versions of iCuke will be able to reduce the pauses. It seems like the new UI Automation code from Apple may be helpful in this regard.

Adding a contact to the iPhone address book

In order to add a contact without using the iPhone UI we need to use something like the following Objective-C:

#import <AddressBook/AddressBook.h>

ABRecordRef record = ABPersonCreate();

ABAddressBookRef addressBook = ABAddressBookCreate();

ABRecordSetValue(record, kABPersonFirstNameProperty,

CFSTR("Test"), NULL);

ABRecordSetValue(record, kABPersonLastNameProperty,

CFSTR("User"), NULL);

ABAddressBookAddRecord(addressBook, record, NULL);

ABAddressBookSave(addressBook, NULL);

The problem is getting iCuke to call some custom Objective-C code. This is where module loading comes in.

iCuke talks to Cucumber via an HTTP interface that is loaded into the iPhone Simulator alongside your application.

iCuke’s module loading system enables you to add code to the HTTP server so that it can perform actions specific to your application in response to HTTP requests. In our case we want to add a module to create a new contact when we GET “/add_contact”. We can pass data to the module via the HTTP query using JSON. To add a contact “John Smith” we could use “/add_contact?{‘first_name’: ‘John’, ‘last_name’: ‘Smith’}”.

Note: This isn’t really how HTTP is supposed to work. As we are changing the state of the application, this should really be a POST action. A future iCuke release may fix this.

In order to wrap the required Objective-C code into an iCuke module we need to add some HTTP interface structure around it. As well as adding a contact, let’s add the ability to wipe the address book. This is what the finished module looks like:

#import <AddressBook/AddressBook.h>

#import "iCukeHTTPServer.h"

#import "iCukeHTTPResponseHandler.h"

#import "JSON.h"

@interface ContactResponse : iCukeHTTPResponseHandler {

}

@end

@implementation ContactResponse

+ (void)load

{

[iCukeHTTPResponseHandler registerHandler:self];

}

+ (BOOL)canHandleRequest:(CFHTTPMessageRef)aRequest

method:(NSString *)requestMethod

url:(NSURL *)requestURL

headerFields:(NSDictionary *)requestHeaderFields

{

if ([requestURL.path isEqualToString:@"/add_contact"] ||

[requestURL.path isEqualToString:@"/wipe_contacts"]

) {

return YES;

} else {

return NO;

}

}

- (void)startResponse

{

NSString *json = [[url query]

stringByReplacingPercentEscapesUsingEncoding:

NSUTF8StringEncoding];

id contact_data = [json JSONValue];

ABRecordRef record = ABPersonCreate();

ABAddressBookRef addressBook = ABAddressBookCreate();

if ([url.path isEqualToString:@"/wipe_contacts"]) {

CFArrayRef people = ABAddressBookCopyArrayOfAllPeople(addressBook);

for (int i = 0; i < CFArrayGetCount(people); i++) {

ABAddressBookRemoveRecord(addressBook,

CFArrayGetValueAtIndex(people, i), NULL);

}

}

else if ([url.path isEqualToString:@"/add_contact"]) {

ABRecordSetValue(record, kABPersonFirstNameProperty,

[contact_data objectForKey: @"first_name"], NULL);

ABRecordSetValue(record, kABPersonLastNameProperty,

[contact_data objectForKey: @"last_name"], NULL);

ABAddressBookAddRecord(addressBook, record, NULL);

}

ABAddressBookSave(addressBook, NULL);

CFHTTPMessageRef response =

CFHTTPMessageCreateResponse(kCFAllocatorDefault,

200, NULL, kCFHTTPVersion1_1);

CFHTTPMessageSetHeaderFieldValue(response, (CFStringRef)@"Connection",

(CFStringRef)@"close");

CFDataRef headerData = CFHTTPMessageCopySerializedMessage(response);

@try

{

[fileHandle writeData:(NSData *)headerData];

}

@catch (NSException *exception)

{

// Ignore the exception, it normally just means the client

// closed the connection from the other end.

}

@finally

{

CFRelease(headerData);

[server closeHandler:self];

}

}

@end

Save that to a file features/support/modules/contact.m

Then we need to compile the module. iCuke provides a helper script for this so you can run icuke-module 4 contact.m from the features/support/modules directory and iCuke should compile the module into a dynamic library contact-sdk4.dylib. The 4 argument to icuke-module tells it which SDK to compile against. If you are working on a 3.1 application you’d need to use icuke-module 3 contact.m.

To add steps that create address book entries using the new module, create the directory features/step_definitions and save a new file features/step_definitions/contact_steps.rb:

Given /^the address book is empty$/ do

simulator.get ’/wipe_contacts’

end

Given /^a contact named "[^\"]*"$/ do |name|

first_name, last_name = name.split(’ ’)

simulator.get ’/contact’, :query => { :first_name => first_name,

:last_name => last_name }.to_json

end

Given /there are (\d+) contacts named "[^\"]*"$/ do |count, name|

count.to_i.times { Given %Q{a contact named "#{name}"} }

end

Now we can rewrite our contact search story (the line broken here for publishing purposes should be entered as one line):

Background:

Given "QuickContacts.xcodeproj" is loaded in the simulator

And the module "features/support/modules/contact" ¬

is loaded in the simulator

And the address book is empty

Scenario: Finding a contact

Given there are 20 contacts named "Anna Bloggs"

And a contact named "Joe Bloggs"

When I tap "Display Picker"

And I type "Joe" in "Search"

Then I should see "Joe Bloggs"

There, that’s concise and quick to run. You can use this technique to set up any fixture data your app requires in order to test scenarios quickly without having to crawl through the same UI repeatedly.

Troubleshooting

Sometimes stories won’t work as you expect, and it might not be clear why. It’s because iCuke uses Apple’s accessibility API to detect what is on the iPhone’s screen.

For an example of this, try adding: But I should not see “Anna Bloggs” to the end of the “Finding a contact” scenario. You’ll notice that it fails, even though it should pass, considering what is really on the screen.

Unfortunately this is one of the times that the accessibility API misleads iCuke. The standard search result interface overlays the search results over the unfiltered table, so they still appear in the view hierarchy (as you can see from the XML in iCuke’s error message). There is no way, as of this writing, for iCuke to tell if the cells below the search results are really visible, so “should see” and “should not see” can’t be 100 percent accurate.

Hopefully this kind of issue will be handled by iCuke better in a future release. Please feel free to file issues on github for any such problems!

Rob’s main focus is writing and improving development tools, streamlining the development workflow and making it easier to test code. He strives to be pragmatic, although perfectionism often creeps in. He enjoys the challenge of learning new open source code and working with the authors to adapt it or improve it, via his consultancy, The IT Refinery. Send the author your feedback or discuss the article in the magazine forum.

When Did That Happen?

Project MAC, the Internet, and Interactive Computing
by Dan Wohlbruck
In the 1960s, a network was conceived that would change computing in fundamental and far-reaching ways.

In July 1963, a little-known agency of the Department of Defense entered into an agreement with MIT to fund something called Project MAC. In 1962, J.C.R. Licklider had moved from MIT to the Department of Defense as head of the Information Processing Techniques Office of the Advanced Research Projects Agency (ARPA). Licklider took a more aggressive approach to computing than the agency expected and when he received a proposal from Robert Fano of MIT for something called Project MAC (multi-access computing), Licklider decided to fund it. On July 1, 1963, ARPA entered into a contract with MIT to develop what would ultimately become interactive computing. Project MAC included money for the expansion of CTSS, MIT’s early time-sharing system, into what was intended to be a community-wide computer utility. Project MAC became a computer industry project within a year. In 1964, MIT joined with GE and ATT in a project designed to develop a new computer and a time-sharing operating system. The project was called Multics (Multiplexed Information and Computing Service).

ARPAnet and the Internet

Licklider left ARPA in 1964 and eventually rejoined MIT as Project MAC’s director in 1968 but the aggressive approach to funding technology projects he had started at ARPA continued in his absence. Licklider was followed first by Ivan Sutherland and then by Robert Taylor. It was Taylor and his assistant Larry Roberts who succeeded in creating the predecessor to the Internet, a new kind of network known as ARPAnet. By 1967, ARPA had decided that their network would use AT&T’s existing wires by, in essence, having the mainframe computers call each other and never hang up. Taylor and Roberts also determined that the existing technology could not support a continuous stream of data without error. Accordingly, they determined to use smaller, less error-prone packets of data which could easily be re-transmitted, if needed. Finally, ARPA directed that their be no central computer or routing site. The ARPAnet was to be decentralized and, therefore, more sustainable.

Multics and UNIX

While the network was being successfully built, the Multics project was looking more and more like a failure. Its goal of true interactive computing was so ambitious and so general that the project floundered in discussion and debate. It was of little surprise when ATT withdrew their money and manpower from the project in April 1969. Ken Thompson and Dennis Ritchie, two AT&T computer scientists with little to do after their departure from Multics, decided to build their own operating system. Thompson designed the new system to be less ambitious but still provide many of the tools that they had to leave behind. With Ritchie’s help they had a working version of their operating system—called UNIX as a play on the name Multics—installed at AT&T by the end of 1970.

The C Programming Language

The growth of UNIX and the need for a better programming language with which to program the UNIX kernel led Ritchie to develop the small, elegant, C language. C begat C++ when it supported classes and, ultimately, objects.

The ARPAnet had its own success in the early 1970’s. The first email message was sent in 1971, FTP was implemented in 1973, and new sites were being added each month. It wasn’t until 1975 and the introduction of the personal computer that what we know as the Internet became inevitable.

The World Wide Web

The latest piece of the puzzle was placed in December 1989 when the first web page of what would become the World Wide Web was published by Tim Berners-Lee on a server in Switzerland. By December 1999, the one billionth web page had been published.

What started in July 1963 with Project MAC had become the most successful federally-funded research project of all time. All of it had taken less than 40 years—and that’s when it happened.

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

The Quiz

Name That Book
by Michael Swaine
How familiar are you with the titles of Pragmatic Bookshelf books? Here’s your chance to find out. The seven sets of blanks below represent the titles of seven of our books. We’ve left out spaces and punctuation, so the only clue you have for each title is the number of blanks: that’s the number of letters in the title. You get six chances to guess what letters are in the titles. You’re on your honor to use just six guesses. (You might want to print the puzzle so you can fill in the blanks as you go.)

You find out whether your guess was right by consulting the Table and the Key. Here’s how that works:

The Table contains one row for each letter of the alphabet and one column for each of the book titles. Say you guess that the letter E is in title 1. Look in the Table in column 1 and row E, and note the symbol you find. It’s A. That’s the key symbol. Look it up in the Key, and it will tell you the positions, if any, where the letter E appears in word 1.

For key symbol A, you find an entry of 0, which means that the letter E doesn’t appear in title 1 at all. So don’t guess that. Guess some other letter. And then another, writing the letters in the blanks, until you have either figured out the title or used up your six guesses.

Keep track of the number of guesses you use. Your final score is the sum of the number of guesses you used on each of the seven titles. If you solved the title, this will be a number between 1 and 6. If you use all six guesses and still don’t know what the title is, your score for that title is 7. If you skip a title, your score for that title is 7. So your total score will be a number between 7 and 49, the lower the better.

Whatever your score is, send it to us. We’ll announce the lowest scorer in the next issue. If that’s you, you’re a true Pragmatic Bookshelf browser.

The Books

1. — — — — — — —

2. — — — — — — — — — — — —

3. — — — — — — — —

4. — — — — — — — — — — — —

5. — — — — — — — — — — — —

6. — — — — — — — —

7. — — — — — — — — — — — — —

The Table

1

2

3

4

5

6

7

A

B

D

I

I

C

3

4

B

A

C

G

J

M

D

M

C

D

G

A

J

L

B

5

D

E

J

A

V

G

H

D

E

A

D

T

C

Y

F

H

F

J

P

M

D

A

M

G

G

M

O

D

G

A

J

6

H

J

A

D

B

G

M

O

I

H

A

G

P

Z

D

7

J

M

A

G

D

M

J

M

K

D

K

J

A

G

M

M

L

J

A

D

X

F

G

F

M

G

D

H

J

M

M

A

N

I

R

A

K

G

D

Q

O

K

D

A

W

J

C

K

P

D

A

G

J

O

M

M

Q

A

G

J

M

D

M

M

R

C

G

A

N

1

E

D

S

D

G

A

J

2

M

M

T

A

H

U

G

D

K

J

U

F

S

G

A

J

D

M

V

G

A

J

D

M

M

M

W

M

M

D

A

M

G

J

X

G

D

E

M

J

A

M

Y

J

D

M

G

M

M

A

Z

M

A

D

G

M

J

J

The Key

Find the key symbol from the Table and look it up here to find the position or positions in the book title where the letter appears. A position of 0 means that the letter does not appear in the title.

A=0; B=1; C=2; D=0; E=3; F=4; G=0; H=5; I=6; J=0; K=7; L=8; M=0; N=9; O=10; P=11; Q=12; R=4,9; S=1,3,6,8,12; T=2,8; U=1,4,7; V=8,12; W=5,10; X=3,4; Y=7,11; Z=3,9; 1=1,6; 2=5,12; 3=6,8; 4=1,8; 5=6,9; 6=2,13; 7=3,11.

Solution to Last Issue’s Quiz

Last month we presented a Sudoku puzzle with a couple of twists—it used letters instead of digits, and there was a hidden message. In one of the rows or columns of the solved Sudoku, we hid what Lisa was to Apple.

And what was Lisa to Apple? That’s answered in the center row: it’s a BACKRONYM. A backronym is an acronym created in reverse: you come up with the acronym itself, and then you invent an explanation for what the letters are supposed to stand for. In the case of Apple’s Lisa computer, the name allegedly stood for “Local Integrated Software Architecture,” although the machine was almost certainly named after Steve Jobs’s daughter. There are probably a lot more backronyms than are admitted to. BASIC, which supposedly stands for “Beginner's All-purpose Symbolic Instruction Code,” is surely a backronym. You can probably think of others.

Here’s the Sudoku solution:

C

N

B

A

Y

R

M

O

K

Y

K

M

O

C

N

B

A

R

O

R

A

B

M

K

Y

C

N

N

O

R

Y

B

M

C

K

A

B

A

C

K

R

O

N

Y

M

K

M

Y

C

N

A

R

B

O

A

Y

N

R

O

B

K

M

C

R

C

O

M

K

Y

A

N

B

M

B

K

N

A

C

O

R

Y

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

- July 9–10, Agile Coaches Gathering, Bletchley Park, UK
“Facilitating Open Space”Rachel Davies, author of Agile Coaching

- July 13, Uniforum Chicago
“What’s New in Perl 5.10 and 5.12”Andy Lester, author of Land the Tech Job You Love

- July 13, Agile Yorkshire in Leeds, UK
“Building Trust on Agile Teams”Rachel Davies, author of Agile Coaching

- July 17, Ruby Midwest, Kansas City, MO
“Pragmatic Guide to Git”Travis Swicegood, author of Pragmatic Version Control Using Git

- July 19–23, OSCON
“Building a NoSQL Data Cloud”Krishna Sankar, author of the forthcoming Building Clouds with Amazon Web Services

- Aug 9–13, Agile 2010, Orlando, FL
“Improving Customer Conversations” and “Manager as Work System Designer: 13 Essential Questions”Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

- Aug 9–13, Agile 2010, Orlando, FL
“Agile Coaches Dojo” and “Refactor Your Retrospectives”Rachel Davies, author of Agile Coaching

- Aug 9–13, Agile 2010, Orlando, FL
“Exploring Coaching From Multiple Dimensions and Levels,” Agile Managers: The Essence of Leadership,” and “Agile Program Management: Another Approach to Large Projects” Johanna Rothman, the author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

- August 10, Uniforum Chicago
“Crash Course in Git”Andy Lester, author of Land the Tech Job You Love

- Aug 28, RubyKaigi 2010, Tsukuba, Ibaraki, Japan
“A Metaprogramming Spell Book (for Ruby and Rails)” Paolo Perrotta, author of Metaprogramming Ruby: Program Like the Ruby Pros

- Sep 24, JAX London in London, UK
“Coaching Teams over Acceptance Testing Hurdles”Rachel Davies, author of Agile Coaching

USENIX Events

- Aug 11–13, 19th USENIX Security Symposium, Washington, D.C.
Whether you’re a researcher, a system administrator, or a policy wonk, come to USENIX Security ’10 to find out how changes in computer security are going to affect you. The 3-day program includes an innovative technical program, starting with a keynote address by Roger G. Johnston of the Vulnerability Assessment Team at Argonne National Laboratory; invited talks, including “Toward an Open and Secure Platform for Using the Web,” by Will Drewry, Google; a refereed papers track, including 30 papers presenting the newest advances; and a Poster session displaying the latest preliminary research. Gain valuable knowledge on a variety of subject areas, including detection of network attacks, privacy, Internet security, Web security, and more. Register by July 19 and save! Additional discounts available!

O’Reilly Events

- July 19–23, Portland, OR
At OSCON you’ll participate in hundreds of sessions covering open source languages and platforms, practical tutorials that go deep into technical skill and best practices, inspirational keynote presentations, an Expo Hall featuring dozens of the latest projects and products, fun networking events and activities, and the best “hallway track” around.

Other Happenings

- July 9
Browser pioneer Marc Andreessen is 39.

- July 16
VisiCalc co-creator Dan Bricklin is 59.

- Aug 9
Alfred Aho, co-creator of AWK language, is 69.

- Aug 11
Steve Wozniak is 60.

- Aug 20
Game developer John Carmack is 40.

- Aug 21
Linus Torvalds announces Linux project, 1991.

- Aug 29
Boy genius Stephen Wolfram is 51.

- Sept 1
This month the GNU Project turns 27.

- Sept 2
First message sent over Internet, 1969.

- Sept 2
sendmail creator Eric Allman is 55.

- Sept 4
LISP creator and AI pioneer John McCarthy is 83.

- Sept 9
C creator Dennis Ritchie is 69.

- Sept 10
Space tourist Charles Simonyi is 62.

- Sept 27
Perl creator Larry Wall is 56.

Shady Illuminations

Must-See Videos for Masochists
by John Shade
Increasingly, tech companies use video to present themselves. Really bad video.

Whenever I start to worry that the suits have taken over all the tech companies and that nothing remains of the vision of the nerdy founders, I look at the way these companies present themselves, and I am reassured. Because the only way those commercials and product demo videos can be that bad is if engineers are writing them.

Video is the new thing. No, really. Kinda. Let me explain. Some of you may be old enough to remember when companies presented themselves and their products by mailing press releases to the news media. More of you will remember the crazy old days when the company Website was the medium of choice for companies to present themselves. That was back before they discovered that where they really needed to be was on Facebook. Or in Second Life. Or that the company could best be presented by letting the employees blog about it. All brilliant ideas, as any fool can plainly see. But increasingly these days, companies are presenting themselves and their products through video. Yes, you in the front row with your hand up, video predates the Web, so it can’t be new. What is new is how easy it is to produce video today. Which of course means a lot of really bad video. So that’s what’s new. Constant progress. Makes you proud.

And we’re not just talking about commercials. We’re talking about technology demo videos hacked together by some twisted nerd in the lab. At least I am. I draw this distinction, by the way, for the sake of any corporate types reading this. Those suits think that commercials and hacked-together jokey videos by the lab team are different things, and who am I to disillusion them? The rest of you are perfectly aware that most people will encounter both these things as videos on YouTube, so there really is no difference. But the suits invested in those commercials, so let them think what they need to think. Life is too short to face facts.

Video has some close cousins in the family of product presentation media. You’ve got your PowerPoint presentations, your TED talk, your Demo demo, your performance art piece. You’ve got that annoying icon that pops up when the user is having difficulty with your software and offers bad advice. Whatever the medium, it’s possible to use it to send potential customers running for the exits. As can be demonstrated....

Viral Video and Other Diseases of the Eye

The most annoying commercial on television today may be that Staples commercial where they guy keeps screaming about low prices, but tech companies are fully capable of producing stuuningly obnoxious or clueless video.

For some reason a lot of people complain about those Cisco commercials featuring Ellen Page. I don’t know what their problem is. I know that when I’m in the market for network equipment, I’m going to check Ellen’s Facebook page for her recommendations, because nobody knows more about routers than an actress best known for playing a teen-aged unwed mother. My issue with the commercials is that I imagine some executive in a marketing meeting saying, “Let’s get that spacey Ellen What’s-her-name from the Apple Switcher commercials. We make switches. And I remember she was popular for some reason.”

Another commercial that a lot of people make fun of is the one for the BT Slimtel. Cheesy music, dancers in leotards, zero connection to the product except the claim that it let you redial the last number dialed by pressing one button. But you have to cut them some slack: they’re British. It’s a nation of nerds.

Sometimes bad can be good. YouTube came out with a new video editor and got the brilliant Yeshmin Blechin to explain it. I’ll go so far as to say that that may be one of the best video product demos I’ve ever seen. And that’s pretty far. One thing that the video demonstrates clearly is that YouTube is not Microsoft.

Why Are Microsoft’s Commercials So Bad?

I think an argument could be made that, frame for frame, Microsoft produces more crappy tech product video than any other tech company. I have a theory about why Microsoft has such trouble presenting itself. It’s because Apple did such a great job of defining them in those “I’m a Mac... and I’m a PC” ads. The John Hodgeman character is an accurate representation of one facet of Microsoft. To be fair, there are other facets. But the Hodgeman facet is the most appealing.

That might explain the Seinfeld commercials. Personally, I don’t see Jerry Seinfeld as Justin Long, but if I pretend I’m a marketing executive at Microsoft and squint just right, I think it makes a grotesque kind of sense. If you buy that, then the purpose of the commercials was to show the PC character (played by Bill Gates) being accepted as a friend and equal by the Mac character. I mean, the commercials must have had some purpose, and I haven’t heard any other explanation.

If you don’t like that, I have another theory, also involving Apple. Apple does such a great job of defining itself that you lose by comparison if you try to emulate their image crafting. So you have to define yourself out of the space that Apple leaves. Stay clear of the image Apple claims for itself: elite, cool, stylish, smart, easy. Anything else is fair game.

Which ought to work well for Microsoft, since its target market actually is everything non-Apple. So they self-define as the company of awkward geeks who develop products for people with no taste.

If that theory is correct, then Microsoft’s ads don’t deserve to be trashed as bad advertising. Bad art, yes. But I’ll go ahead and trash them anyway, because my theory is probably wrong. They usually are.

What’s the worst Microsoft product video ever? Many would point to that promo for Microsoft Songsmith. Awkward, geeky, and it characterizes Microsoft’s customers as talentless losers. Dad’s in a sucky job, but his tone-deaf daughter saves him by showing him how a Microsoft product is just what he needs to compose a jingle worthy of the crappy product he’s hired to promote. Wonder where they came up with that idea. The title of that video, by the way, seems to be, “Everyone Has a Song Inside.” And that’s a fine place for it.

But the O.M.G.I.G.P. commercial directed by Bobcat Goldthwait is a tough competitor. The failure of that video isn’t that it’s gross, it’s the picture it paints of Microsoft’s customers. Your husband, the video tells its women customers, is watching porno online that is so disgusting that it will make you puke. You’ll puke three times. Well, that and the fact that we are left trying to imagine something really disgusting, and the memory of that image is what we will think of the next time we hear the phrase “Internet Explorer.”

Talk about a video that cries out to be redone in 3-D, though.

My choice? An early video for Microsoft Kinect. You won’t find it at that link. The video’s been removed and I can’t find it anywhere. It’s not inherently worse than the Songsmith video, but I give it higher marks partly because the technology is actually pretty interesting. But leave it to Microsoft to take an interesting technology and sell it like processed cheese spread.

The message seems to be, “The family that dances together awkwardly on the shag carpeting in the family room stays together, because let’s face it, who else is going to spend time with these losers?” I especially like the bit at the end with Dad slumped in his recliner, gesturing like a mime trapped in an invisible box.

Which is an appropriate metaphor, because the people in the video seem to be trapped in the box. Controlling cartoons with their bodies, they seem to be turning into cartoons. Does driving a cartoon avatar with your movements cause you to move like a cartoon, as the people in this video do? Will the phenomenon extend beyond the game? Will Kinekt users be permanently Mario’d?

The director of this little gem may not be the Uwe Boll of product videos, but he’s in the running.

I said that a tech company can’t emulate Apple’s approach to representing itself, but of course it can. One excellent example of how this works out is that notorious Palm Pre video Is Palm’s target market really eyebrowless vegan mystics? Or did a Palm executive commission an Apple-like ad from an agency that had nothing but scorn for Apple?

It’s Not Bad, It’s Art

Then there’s performance art as product promotion. Both IBM and Sony have paid grafitti artists to deface city streets. It didn’t end well either time. You wouldn’t think that after you seeing another big tech company embarrass itself publicly with a half-witted publicity stunt, your reaction would be, “Wow! We gotta do that!”, but you’d be failing to reckon with the level of hoof-in-mouth at Sony.

Still, grafitti is not in the same realm of stupidity as setting up a launch event that involves a dead goat. Sony again.

Microsoft is better known for atrociously bad commercials and demo videos—and PowerPoint presentations and sales meeting pep talks by Steve Ballmer channeling that gorilla in the suitcase commercial—than for performance art catastrophes, but it’s pretty hard to top Bill Gates releasing a horde of live, hungry mosquitos on the audience at a TED conference. Angelina Jolie was among the victims. Yep, she of the bee-stung lips left TED with a mosquito-bit something. I can’t be more specific because the particular part of her anatomy that got bit was left out of the story. What passes for journalism today.

Let me leave you with this example of art imitating life, if life is a transcendently catastrophic software demo. If you enjoy it as much as I did, I apologize.

John Shade was born in Montreux, Switzerland on a cloudy day in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. John would like to apologize to Joe Barton. Also to joebartonwouldliketoapologize.com. Send the author your feedback or discuss the article in the magazine forum.