PragPub 2011-08: Issue #26

Table of Contents

Features

Make Your Own Video Game System

by Maik Schmidt

Wouldn’t it be fun to build your own classic video game system to play games like Breakout or Asteroids on your TV? The Arduino makes it easy and Maik shows you how.

Hello, ClojureScript!

by Aaron Bedra

Clojure rocks, JavaScript reaches. So why not combine the two?

Decouple Your Apps with Event-Driven CoffeeScript

by Trevor Burnham

Node’s event paradigm provides an elegant way of connecting objects, providing maximum flexibility with minimum boilerplate, and it’s test-friendly.

How Virtuous Is Your Code?

by Tim Ottinger, Jeff Langr

Tim and Jeff spell out the virtues that they think might constitute a universal definition of good.

Code As Dialog

by Brian Tarbox

Brian attends a writer’s conference and finds that elements of screenwriting like truthful dialog and the Show Bible apply surprisingly well to software development.

When Did That Happen?

by Dan Wohlbruck

In this month 24 years ago, Apple introduced a product that influenced the development of the World Wide Web.

Departments

Up Front

by Michael Swaine

We’re looking at CoffeeScript and ClojureScript in this issue, as well as breaking out the wire cutters to build a video game machine.

Choice Bits

The top eleven books this month, plus a few threads unwoven from the garment of tweet.

Guru Meditation

by Andy Hunt

The end of Agile? Lessons from improv.

Calendar

Author sightings, upcoming conferences, and guess who’s turning 40.

Shady Illuminations

by John Shade

John shares six reasons to avoid software development as a career.

But Wait, There’s More...

Coming attractions and where to go from here.

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

Hardware Hacking and JavaScript Alternatives

by Michael Swaine

We’re looking at CoffeeScript and ClojureScript in this issue, as well as breaking out the wire cutters to build a video game machine.

This issue includes articles on both CoffeeScript and ClojureScript, two new languages that allow you to write JavaScript without having to write JavaScript, if you follow me.

CoffeeScript was immediately embraced by the great majority of developers who looked at it, while ClojureScript is being viewed more skeptically. I think this is at least in part because of confusion about what ClojureScript is for. It’s really not trying to do what CoffeeScript is trying to do. (The starting point for any evaluation of ClojureScript is the official rationale.)

The articles are written by Trevor Burnham, who wrote the book on CoffeeScript, and Aaron Bedra, who is cowriting Programming Clojure, Second Edition, which will include coverage of ClojureScript. We hope this issue will encourage people on the fence about one or the other of these tools to explore both and see what problem each is intended to solve. You might decide that both have a place in your toolkit.

You may have another kind of toolkit, one with a soldering iron and wire cutters. Hardware hacking is enjoying a renaissance thanks to the popular Arduino single-board computers. This month our Arduino guru Maik Schmidt, author of Arduino: A Quick-Start Guide, returns with another Arduino project, this time showing you how to build your own video game machine for rediscovering the innocent fun of classic games like Asteroids and Breakout.

Tim Ottinger and Jeff Langr are back with some agile advice on making your code virtuous. In doing so, they shuffle their Agile in a Flash cards and draw out card #42, which you have to figure has the answer to everything.

In fact, all of our writers this month are familar to these pages. Dan Wohlbruck is back with another history article, both Brian Tarbox and Andy Hunt get insights into programming from theater, and John Shade wants to talk to your mother.

Enjoy the issue and be sure to read all the way through to the end to see what’s in the pipeline for next month. Oh, and for those of you in the Northern Hemisphere, we hope the cover images makes you feel cool.

Choice Bits

Patent Nonsense

Maybe I should run a patent search on stringing tweets together in interesting patterns.

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 | Designed for Use
2^ | NEW | The Cucumber Book
3 | 3 | CoffeeScript
4v | 2 | Agile Web Development with Rails
5v | 4 | iOS Recipes
6^ | NEW | New Programmer's Survival Manual
7v | 5 | The RSpec Book
8v | 7 | Programming Ruby 1.9
9^ | NEW | Continuous Testing
10^ | 11 | Crafting Rails Applications
11v | 9 | Seven Languages in Seven Weeks

Patent Nonsense

As it turns out, everything in the world is made of tiny pieces we can’t see with the human eye, called “patent agreements.” — @bindr

How can Amazon patent one click purchase? I think bars invented this hundreds of years ago, it’s called a tab. — @phillryu

#ihavenotolerance for the Federal Gov’t saying cannabis has no medical value, when they own a patent that proves it is medical. — @cannabisstrains

#US grants #patent for submitting and evaluating electronic forms. In 2010. http://bit.ly/osMYLj — @tha_sun

Looks like we won’t be needing a cat anymore: Apple secures patent on preventing headphone tangles. #apple http://tnw.co/nHc08Q — @vrokreddit2

Lodsys claiming “more games” section falls under their patent is just ridiculous. — @loadedwino

Hang on a minute. I knew IBM had a lot of patents, but they appear to have a 2007 patent on patent trolling. http://goo.gl/6tBYS — @fastchicken

How “Patent Trolling” Taxes Innovation: 97% of patent infringement suits are settled before trial. http://ow.ly/5BwDJ — @freakonomics

#Android is in serious trouble after ITC judge finds #HTC in infringement of two very fundamental #Apple patents bit.ly/ndGKQm — @FOSSpatents

These tech-world patent-infringement lawsuits are starting to resemble the Mexican standoff at the end of Reservoir Dogs. — @nkolakowski

2011-2012 will be called as patent war years. Each vendor trying to override patents from others. That’s lawyers’ time. Creators on vacation. — @eldarmurtazin

Congress is on the verge of passing the first patent reforms in 60 years. http://ow.ly/5CnEt — @IncMagazine

Patent Reform Stalled in the Senate Thanks to Debt Ceiling. bit.ly/nY8xNt — @ipwatchdog

When You Put It That Way

...it just makes me want to tweet.

“Well, actually...” is a good way to identify jerks. Other identifying phrases: “Pro tip: ...” and “Uh, no.” — @petdance

Add “We realize you have many choices for” to other such unwelcome phrases as “We need some time apart” and “Mommy and Daddy love you, but.” — @BodyofBreen

I hate the phrase “We apologize for any inconvenience.” You know full well there is an inconvenience, please just acknowledge it. — @chrisjpowers

I’m not sure I’m on twitter for all this “replace word with duck” and “add in your pants” to film titles. — @codemonkeyism

I hate when people say “to coin a phrase” when they’re not. If you’re using a cliché, you’re not coining anything! :[ — @scyrene

I hate the phrase “maintain a web presence”. It sounds like a poltergeist. — @BruceLaBruce

I’ll Link to That

Jul 12, 2011: Happy 1st B’day to Neptune. Discovered in 1846, today marks 1 full orbit since the Sept 24th night it was found. — @neiltyson

Twitter, then called Twttr, opened to the public five years ago today [July 15]. http://t.co/gCEj6JR — @twitter

“Pastafarian” wins religious freedom right to wear pasta strainer for driving license. http://tgr.ph/rmojqf — @marick

LOVE THIS. All the winners of the @google science fair are GIRLS!!!! http://bit.ly/pRv78q h/t to @jomc — @jennydeluxe

Invokedynamic will lead to a rediscovery of dynamic languages on the JVM, and a new renaissance of dynlang implementations. — @headius

Awesome! Directions from Portland, OR to Tokyo, Japan, including “Kayak across the Pacific Ocean.” maps.google.com/maps?saddr=Por… — @rael

Mystery Train Sometime Have Loco Motive

The shuttle is taking a year’s worth of supplies to the ISS. There are no more shuttle missions. Who is manning the ISS? — @alancfrancis

Why would a company called Franco-American make Italian food? — @rit

Why does VanMorrison make me feel so happy? — @tottinge

Received a CSV without the commas. Guess it’s a *.v file? — @brynary

One thing worse than tests mysteriously failing, is when they mysteriously pass. — @david_harvey

Fan Tweets

Great issue of PragPub released today. bit.ly/pSHjkW “The Clojure Issue” — @redinger

So much about #clojure, I love you #pragpub. pragprog.com/magazines/2011… — @blogytalky

Epic issue of the free & awesome PragPub magazine released today by the Pragmatic Programmers. The Clojure Issue. pragprog.com/magazines — @publicfarley

@pragpub It’s a great issue, would be good to see more language dedicated issues in the future! — @matty_jwilliams

This Clojure DSL article by Ambrose Bonnaire-Sergeant is absolutely top-notch. PragPub issue 25 pragprog.com/magazines — @chrishouser

@QualityFrog @AntonyMarcano :-) I was glad to find Michael Swaine at @pragpub and now reminded to find @JerryPournelle. & revisit @judell. — @ponderings

Jerry's here: informationweek.com/byte/ — @pragpub

Enduring Truths

If you’re easily confused, you’ll never be bored. — @scarycookies

Whoever said “you can’t take it with you” clearly didn’t have a minivan. — @PragmaticAndy

Who Are Those Guys?

This month we followed Shannon Prickett, Phillip Ryu, iStrainGuide, Daniel F. Kudwien, vroko reddit2, Daniel Wood, Nic Wise, freakonomics, Florian Mueller, Nick Kolakowski, Eldar Murtazin, Inc. Magazine, Gene Quinn, Andy Lester, Chris Breen, Chris Powers, Stephan Schmidt, Barry Dean, Neil deGrasse Tyson, Brian Marick, Jenna Wortham, Charles Nutter, Rael Dornfest, Alan C Francis, Brendan W. McAdams, Tim Ottinger, Bryan Helmkamp, David Harvey, Chris Redinger, blogytalky, publicfarley, Matty Williams, Chris Houser, Dean Goodmanson, Carole Unter, Andy Hunt, and Bruce LaBruce. You can follow us at www.twitter.com/pragpub.

Guru Meditation

The End of Agile

by Andy Hunt

As of 2011, the codification of the principles that comprise “agile” is now ten years old. Do you think it should survive unchanged another ten? Is this the end of agile?

A few years ago I was giving one of my Pragmatic Thinking & Learning workshops, and we were talking about the value of a wide-ranging education that included the arts, not just the sciences. One of the participants made a revealing comment about how useful those non-technical courses were:

“The theater I did in college has helped me more in my programming career than half of my engineering courses.”—Grant Gainey, Senior Architect Developer

There are many reasons that a theater course would come in handy, not the least of which is learning how to work well with others under sometimes trying and unexpected circumstances. But there’s one aspect in particular that’s worth looking at in more detail.

In her autobiography, comedian Tina Fey (Bossypants, Reagan Arthur Books; 1st edition 2011) explains one crucial part of a theatrical education: improv. That is, improvisational theater. You’re stuck out on stage with one or more other actors, with no script, no goal, no pre-arranged dialog at all. The “plot” and dialog emerge spontaneously as you and the other actors interact. According to Fey, there are two rules to improv:

Rule 1: Agree

Rule 2: Add

First, you have to agree with whatever is going on. If another character has already established that your characters are on the moon, or in a coal mine, or in the catacombs under Paris, you have to go along with that. It’s bad form to say, “No, wait, that’s no moon, it’s a space station!” So the first rule is to agree with what’s been set out.

Next, you have to add something of your own. You can’t advance the plot if you simply agree and stop there: “Yup, this sure is the moon all right.” That kills the dialog dead on the spot.

So you add your own little bit of advancement, which we’ll refer to in shorthand as “yes, and...” In this example, where your characters are on the moon, perhaps you’d add a line such as, “yes, and I think I saw something move over there near the rim of that crater.” Now the other actors have something to go with; they’ll add their own bits, and the act moves forward.

And that’s the important part: moving forward.

Yes, and...

To me, this short idea of “yes, and...” is something we’ve lost track of in agile projects. As I mentioned in the previous column, what we call “agile” is supposed to be ever-changing and constantly adapting. This is one way to keep things moving: follow the rules of improv theater.

Rule one, agree. Don’t reject current agile practices, but don’t accept them as written in stone either. What constitutes your current set of agile practices isn’t “done”: it’s not finished, it’s not established as canon, and it never will be.

Rule two, add your piece. It’s up to you and the rest of your team to evolve your agile practice, to keep it alive and keep it moving.

That was always the intention with what we call “agile.” It was never intended to be a static, fixed set of anything. Remember the very first words of the the Agile Manifesto, that we wrote ten years ago:

“We are uncovering better ways of developing software...”—agilemanifesto.org

We’re still uncovering, still discovering. And you should be, too. What works well for me won’t necessarily work well for you; what works well for you now won’t necessarily work well for you next time.

“Yes,” we’ve got some great stuff, as an industry, we’re adopting better practices than were in common use previously.

“And...” the world is changing.

Windows and the desktop PC is dying. Microsoft’s share of internet-connected devices went from 95% to under 50% in the last three years (Roger McNamee, Elevation Partners). HTML5 isn’t the HTML you grew up with. Social interaction is no longer a pedestrian app to find lost classmates, it’s a required feature. There are new capabilities, new interaction paradigms, different development styles that demand even faster time to market.

As of 2011, the codification of the principles that comprise “agile” is now ten years old. Do you think it should survive unchanged another ten? Is this the end of agile?

The End?

Maybe it is the end of agile as you knew it, and that’s a good thing. Because with an agile approach, there is no end. There’s only “yes, and...”

Something to think about.

(If you are at the Agile 2011 Conference in Salt Lake City next week, find me and let me know what your thoughts are on agile and where your practice is headed.)

Andy is a Pragmatic Programmer, author of a bunch of books including Pragmatic Thinking & Learning, and dabbles in music and woodworking. Follow him on Twitter at @PragmaticAndy, at his blog andy.pragprog.com, or email him at andy@pragprog.com.

What’s a guru meditation? It’s an in-house joke from the early days of the Amiga computer and refers to an error message from the Amiga OS, baffling to ordinary users and meaningful only to the technically adept.

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

Make Your Own Video Game System

Rediscover the Early Days of Video Gaming using the Arduino Single-Board Computer

by Maik Schmidt

Return with us now to those innocent days of yesteryear, when you could identify with the fate of a single pixel in a field of asteroids or up against a wall of bricks.

People use the Arduino microcontroller board for countless different projects. Some use it to create interactive art, some use it automate their home, and some even use it to create games. Often these games are self-contained toys such as remakes of the famous Simon game. For this kind of games you often need only a few LEDs, a piezo buzzer, and sometimes an LC display.

But wouldn’t it be more interesting to create a real video game system—that is, a device that allows you to play different video games like Breakout or Asteroids on your TV? The Arduino makes it surprisingly easy to build such a system and in this article I’ll show you how.

You’ll learn how to generate a monochrome video signal, so you can connect your Arduino directly to your TV set. Also you’ll learn how to hijack a Wii Nunchuk controller, so you can control your games with state-of-the-art gaming hardware. (For the sake of brevity we do not add any sound effects.)

Finally, you’ll learn how to implement a small game. It will be a simulation of the light cycle races from the movie Tron. (We all agree there will always be only one Tron movie and only one Matrix movie, right?)

What You Need

To build this article’s product you only need a few cheap parts. Probably you have most of them at home already:

An Arduino board such as the Uno, Duemilanove, or Diecimila

A USB cable to connect the Arduino to your computer

A Nintendo Nunchuk controller

An RCA cable

Five wires

A 1k-ohm resistor

A 470-ohm resistor

A pair of wire cutters

Tinkering With the RCA Cable

Before we start to generate video signals, we have to connect the Arduino to a TV set. One of the cheapest and easiest solutions for transmitting audio or video signals is an RCA cable (sometimes called cinch cable). In Figure 1 you can see an RCA cable with three connectors. These cables usually transmit sound (red and white connectors) and video (yellow connector). For our purpose a cable with a single connector is sufficient.

Figure 1: Three RCA Connectors

Unfortunately, the Arduino has no RCA jack, so how do we connect the cable to the Arduino? In principle we could add an RCA jack to the Arduino, but we’ll use a less subtle method and instead connect the cable’s wires directly to the Arduino’s pins. An individual RCA cable contains two wires: signal and ground. The signal wire is usually well protected by insulation to shield it from distortions. The ground wire is not a real wire but a mesh of stranded copper. To get access to the wires, cut the cable in half first. Go ahead, snip it!

Now take one of the halves and use the wire cutters again to carfully remove the cable’s outer insulation. You should now see the mesh of stranded copper.

Bring back the mesh into wire shape by rubbing it between your thumb and forefinger, so you can solder it to a solid-core wire later on. After that, use the wire cutter again to remove the inner insulation. From my experience it’s best to put the cable between the wire cutter’s blades, then turn the cable slowly and carefully, increasing the pressure while turning the cable. Be very careful so you do not accidentally cut the signal wire! After you’ve cut through the whole insulation you can easily remove it. You should now see the cable’s signal wire and your cable should look like Figure 2.

Figure 2: Signal Wire and Ground Wire of Our Cable

Now have a look at Figure 3 to see how to connect the RCA cable to the Arduino. First of all, you have to connect the cable’s ground to one of the Arduino’s ground pins. Then you have to connect the RCA cable’s signal (VIDEO) wire to the Arduino’s digital pins 9 and 7 using two resistors. We need pin 9 for synchronizing the sender (Arduino) and the receiver (TV set) and we need pin 7 to emit the video signal.

Figure 3: Connecting an RCA Cable to the Arduino

So we have to connect the two resistors to the RCA cable’s signal wire and it’s not sufficient to simply knot them together. You have to solder them; and while you’re at, it connect the RCA cable’s ground wire to a piece of solid-core wire, so you can easily attach it to the Arduino. (See Figure 4 for the result.)

Figure 4: Our Final Cable

That’s all the hardware we need for generating a video signal, so connect the cable to the Arduino and let’s see how we can bring it to life.

Generating a Video Signal

Generating a clean video signal is difficult, because the output quality heavily depends on a very exact timing. Usually you need a lot of tricky assembler code dealing with nasty topics such as interrupt handling. Fortunately, Myles Metzler went through all the pain already and created the arduino-tvout library. This library not only offers basic functions for drawing lines, circles, and rectangles, it also comes with a convenient toolset for drawing text in fonts of various sizes. Oh, and it even supports sound output.

Of course, you cannot expect a small device such as the Arduino to generate HD graphics, but at least we are able to generate monochrome graphics with a resolution of 128 by 96 pixels for both PAL and NTSC. That’s enough for many useful applications and games and it’s still better than the resolution of my first mobile phone. (and we all had a lot of fun playing Snake back in these days, right?)

Although the arduino-tvout library comes with a really nice demo (it displays some bitmap graphics and even rotates a cube) we will start with our own, to see how the library works:

| #include <TVout.h>
| #include <fontALL.h>
| #include <stdint.h>

| const uint8_t WIDTH = 128;
| const uint8_t HEIGHT = 96;

TVout tv;

| void setup() {
| tv.begin(PAL, WIDTH, HEIGHT);
| tv.select_font(font4x6);
| }

| void loop() {
| tv.clear_screen();
| tv.print(0, 0, " Welcome to our little demo!");
| delay(3000);
| tv.clear_screen();
| tv.print(0, 0, " Let's draw a line:");
| tv.draw_line(0, 10, WIDTH - 1, HEIGHT - 1, WHITE);
| delay(3000);
| tv.clear_screen();
| tv.print(0, 0, " Now let's draw a rectangle:");
| tv.draw_rect(0, 10, WIDTH - 11, HEIGHT - 11, WHITE);
| delay(3000);
| tv.clear_screen();
| tv.print(0, 0, " And here we have a circle:");
| tv.draw_circle(WIDTH / 2, HEIGHT / 2, 20, WHITE);
| delay(3000);
| }

This is a simple program but it shows nearly all aspects of the arduino-tvout library. First of all, we include the library’s main header file, and we include fontALL.h, because we want to output some text. We also include the stdint header file, so we have some nice type definitions for common types. Then we define constants for the width and height of our screen.

In the global scope we define a TVout object named tv. We initialize this object in the setup function calling its begin method. This method expects the video signal type, the screen’s width, and the screen’s height. We chose PAL in this case, but you can safely replace it with NTSC. In addition, we select the font we’re going to use to output our messages.

The loop function demonstrates several of the library’s features. We print a few texts calling print and we draw some lines and shapes calling draw_line, draw_rect, and draw_circle (see Figure 5 for the result of draw_circle). Unsurprisingly, the library also has methods named set_pixel and get_pixel, and this is the right time to read the online documentation.

Figure 5: Our First TVout Demo

All in all the arduino-tvout library offers a very intuitive access to a TV screen. But to play games we also need a cool controller.

Tinkering with the Wii Nunchuk

A vital component of every video game system is a controller, and for our system we could simply create our own using a couple of push buttons. But we are lazy, so instead we’ll hijack a Nintendo Nunchuk controller. It’s a perfect candidate for tinkering, for various reasons. It comes with a three-axis accelerometer, an analog joystick, and two buttons, and it is very cheap (less than $10 at the time of this writing). Even better: because of its good design and its easy-to-access connectors, you can integrate it into your own projects surprisingly easily.

Figure 6: A Nintendo Nunchuk Controller

We’ll use an ordinary Nunchuk controller and transfer the data it emits to our computer using an Arduino. You’ll learn how to wire it to the Arduino and how to write software that reads the controller’s current state. You don’t even need a Nintendo Wii to do any of this—you only need a Nunchuk controller.

Wiring a Wii Nunchuk

Wiring a Nunchuk to an Arduino really is a piece of cake. You don’t have to open the Nunchuk or modify it in any way. You only have to put four wires into its connector and then connect the wires to the Arduino.

Figure 7: The Nunchul Connector

In Figure 7, you can see a diagram of a Nunchuk plug. It has six connectors, but only four of them are active: GND, 3.3 V, Data, and Clock. Put a wire into each connector, and then connect the wires to the Arduino. Connect the data wire to analog pin 4 and the clock wire to analog pin 5. The GND wire has to be connected to the Arduino’s ground pin and the 3.3 V wire belongs to the Arduino’s 3.3 V pin.

Figure 8: How to Connect a Nunchuk to an Arduino

That’s really all you have to do to connect a Nunchuk controller to an Arduino. The controller is powered with 3.3 volts now, and in the next section, you’ll see that the two wires connected to analog pins 4 and 5 are all we need to control the controller.

Talking to a Nunchuk

No official documentation shows how a Nunchuk works internally or how you can use it in a non-Wii environment. But some smart hackers and makers on the Internet invested a lot of time to reverse-engineer what’s happening inside the controller.

All in all, it’s really simple, because the Nunchuk uses the Two-Wire Interface (TWI), also known as I²C (Inter-Integrated Circuit) protocol. It enables devices to communicate via a master/slave data bus using only two wires. You transmit data on one wire (DATA), while the other synchronizes the communication (CLOCK).

The Arduino IDE comes with a library named Wire that implements the I²C protocol. It expects the data line to be connected to analog pin 4 and the clock line to analog pin 5. We’ll use it shortly to communicate with the Nunchuk, but before that, we’ll have a look at the commands the controller understands. (At this site you can find a library that allows you to use any pair of pins for I²C communication.)

Figure 9: The Nunchuk always Returns 6 Bytes of Data

To be honest, the Nunchuk understands only a single command, which is “Give me all your data.” Whenever it receives this command, it returns six bytes that have the following meaning (see the data structure in Figure 9):

Byte 1 contains the analog stick’s X-axis value, and in byte 2 you’ll find the stick’s Y-axis value. Both are 8-bit numbers and range from about 29 to 225.

Acceleration values for the X, Y, and Z axes are three 10-bit numbers. Bytes 3, 4, and 5 contain their eight most significant bits. You can find the missing two bits for each of them in byte 6.

Byte 6 has to be interpreted bit-wise. Bit 0 (the least significant bit) contains the status of the Z-button. It’s 0 if the button was pressed; otherwise, it is 1. Bit 1 contains the C-button’s status.

The remaining six bits contain the missing least significant bits of the acceleration values. Bits 2 and 3 belong to the X axis, bits 4 and 5 belong to Y, and bits 6 and 7 belong to Z.

Now that we know how to interpret the data we get from the Nunchuk, we can start to build a Nunchuk class to control it.

Building a Nunchuk Class

The interface of our Nunchuk class (and the main part of its implementation) looks as follows:

#define NUNCHUK_BUFFER_SIZE 6

| class Nunchuk {
| public:
| void initialize();
| bool update();

| int joystick_x() const { return _buffer[0]; }
| int joystick_y() const { return _buffer[1]; }

| bool left() const { return _buffer[0] < 50; }
| bool right() const { return _buffer[0] > 200; }
| bool up() const { return _buffer[1] > 200; }
| bool down() const { return _buffer[1] < 60; }

| int x_acceleration() const {
| return ((int)(_buffer[2]) << 2) | ((_buffer[5] >> 2) & 0x03);
| }

| int y_acceleration() const {
| return ((int)(_buffer[3]) << 2) | ((_buffer[5] >> 4) & 0x03);
| }

| int z_acceleration() const {
| return ((int)(_buffer[4]) << 2) | ((_buffer[5] >> 6) & 0x03);
| }

| bool z_button() const { return !(_buffer[5] & 0x01); }
| bool c_button() const { return !(_buffer[5] & 0x02); }

| private:
| void request_data();
| char decode_byte(const char);

| unsigned char _buffer[NUNCHUK_BUFFER_SIZE];
| };

This small C++ class is all you need to use a Nunchuk controller with your Arduino. To initiate the communication channel between Arduino and Nunchuk, you have to invoke the initialize method once. Then you call update whenever you want the Nunchuk to send new data. You’ll see the implementation of these two methods shortly.

We have public methods for getting all attributes the Nunchuk returns: the x and y positions of the analog stick, the button states, and the acceleration values of the X, Y, and Z axes. We also have methods for checking if the analog stick is pressed to a certain direction. All these methods operate on the raw data you can find in the buffer named _buffer. Their implementation is mostly trivial and requires only a single line of code. Only the assembly of the 10-bit acceleration values needs some tricky bit operations.

At the end of the class declaration you find two private helper methods we need to implement: initialize and update:

| #include <WProgram.h>
| #include <Wire.h>
| #include "nunchuk.h"

#define NUNCHUK_DEVICE_ID 0x52

| void Nunchuk::initialize() {
| Wire.begin();
| Wire.beginTransmission(NUNCHUK_DEVICE_ID);
| Wire.send(0x40);
| Wire.send(0x00);
| Wire.endTransmission();
| update();
| }

| bool Nunchuk::update() {
| delay(1);
| Wire.requestFrom(NUNCHUK_DEVICE_ID, NUNCHUK_BUFFER_SIZE);
| int byte_counter = 0;
| while (Wire.available() && byte_counter < NUNCHUK_BUFFER_SIZE)
| _buffer[byte_counter++] = decode_byte(Wire.receive());
| request_data();
| return byte_counter == NUNCHUK_BUFFER_SIZE;
| }

| void Nunchuk::request_data() {
| Wire.beginTransmission(NUNCHUK_DEVICE_ID);
| Wire.send(0x00);
| Wire.endTransmission();
| }

| char Nunchuk::decode_byte(const char b) {
| return (b ^ 0x17) + 0x17;
| }

After including all libraries we need, we define the NUNCHUK_DEVICE_ID constant. I²C is a master/slave protocol; in our case, the Arduino will be the master, and the Nunchuk will be the slave. The Nunchuk registers itself at the data bus using a certain ID (0x52), so we can address it whenever we need something.

Figure 10: Message Flow between Arduino and Nunchuk

In initialize, we establish the connection between the Arduino and the Nunchuk by sending a handshake. Therefore we call Wire’s begin method, so the Arduino joins the I²C bus as a master (if you pass begin an ID, it joins the bus as a slave having this ID). Then we begin a new transmission to the device identified by NUNCHUCK_DEVICE_ID: our Nunchuk.

We send two bytes (0x40 and 0x00) to the Nunchuk, and then we end the transmission. This is the whole handshake procedure, and now we can ask the Nunchuk for its current status by calling update. In Figure 10, we see the message flow between an Arduino and a Nunchuk.

update first pauses for a millisecond to let things settle a bit. Then we request six bytes from the Nunchuk, calling Wire.requestFrom. This does not actually return the bytes, but we have to read them in a loop and fill our buffer. Wire.available returns the number of bytes that are available on the data bus, and Wire.receive returns the current byte. We cannot use the bytes we get from the Nunchuk directly, because the controller obfuscates them a bit. “Decrypting” them is easy, as you can see in decode_byte.

Finally, we tell the Nunchuk to prepare new data by calling request_data. It transmits a single zero byte to the Nunchuk, which means “prepare the next six bytes.”

Figure 11: The Video Game System Is Complete

That’s it! Your complete video game system should look like Figure 11 now. We have video output and access to all of the Nunchuk’s data, so let’s create our first game.

Creating Our First Game

Due to a lack of resources we will not be able to create a first-person shooter, but our system is powerful enough to run some entertaining classics. (At nootropicdesign.com you can find Tetris, Asteroids, Breakout, and Space Invaders, for example.)

Figure 12: Our Game’s Title Screen

We’ll create a Tron-like light cycle racing game—that is, two players will fight each other using light cycles that leave a solid trace. Whenever a player hits a wall or a cycle’s trace, the race is over and the other player wins. In our version of the game a human player always plays against the computer and we will represent the light cycles by a single pixel. Let’s start with the Player class: (You can find the article’s code examples at github.)

| class Player {
| public:
| enum Direction {
| NORTH, WEST, EAST, SOUTH
| };

| enum Behavior {
| MANUALLY, PREFERRED_ORDER
| };

| uint8_t px, py;
| Direction direction;
| Behavior behavior;

| void move(void) {
| switch (direction) {
| case NORTH: py -= 1; break;
| case WEST: px -= 1; break;
| case EAST: px += 1; break;
| case SOUTH: py += 1; break;
| }
| }

| bool draw(TVout& tv) {
| if (tv.get_pixel(px, py) == 1)
| return true;
| tv.set_pixel(px, py, 1);
| return false;
| }

| void control(TVout& tv, const Nunchuk& controller) {
| switch (behavior) {
| case MANUALLY:
| control_manually(controller);
| break;
| case PREFERRED_ORDER:
| control_preferred_order(tv);
| break;
| }
| }

private:

| void control_manually(const Nunchuk& controller) {
| if (controller.left()) {
| direction = WEST;
| } else if (controller.right()) {
| direction = EAST;
| } else if (controller.up()) {
| direction = NORTH;
| } else if (controller.down()) {
| direction = SOUTH;
| }
| }

| void control_preferred_order(TVout& tv) {
| if (is_passable(tv, NORTH))
| direction = NORTH;
| else if (is_passable(tv, WEST))
| direction = WEST;
| else if (is_passable(tv, EAST))
| direction = EAST;
| else if (is_passable(tv, SOUTH))
| direction = SOUTH;
| else
| direction = NORTH;
| }

| bool is_passable(TVout& tv, const uint8_t direction) {
| switch (direction) {
| case NORTH: return (tv.get_pixel(px, py - 1) == 0);
| case WEST: return (tv.get_pixel(px - 1, py) == 0);
| case EAST: return (tv.get_pixel(px + 1, py) == 0);
| case SOUTH: return (tv.get_pixel(px, py + 1) == 0);
| }
| }
| };

First we define two enumerations for the player’s possible moving directions and for the player’s behavior. MANUALLY means the player is controlled by a human being and PREFERRED_ORDER means the player is controlled by the computer using a simple algorithm that tries to move into the first possible direction.

After that we define a few public instance variables. px and py contain the player’s current coordinates. In direction you’ll find the player’s direction and behavior stores the player’s behavior.

Then we define three public methods. move moves the player into its current direction by changing the coordinates accordingly. The draw method draws the player onto the screen using set_pixel, but first it checks if the pixel is already occupied. If yes, it returns true and we know that the player has hit something.

The control method actually controls the player depending on its behavior and it delegates its work to two private methods. Controlling the player manually is trivial, so in control_manually we only have to check the joystick’s current position and adjust the player’s direction accordingly. Our approach to artificial intelligence isn’t very sophisticated either. We simply check what’s the next passable direction and take it.

Let’s implement the game itself now:

| class Game {
| public:
| static const uint8_t SCREEN_WIDTH = 128;
| static const uint8_t SCREEN_HEIGHT = 96;
| static const uint8_t FONT_HEIGHT = 6;

| enum GameState {
| INTRO, STARTING, RUNNING, PAUSED, DONE
| };

| void initialize() {
| reset_game();
| _tv.begin(PAL, SCREEN_WIDTH, SCREEN_HEIGHT);
| _tv.select_font(font4x6);
| _controller.initialize();
| }

| void reset_game(void) {
| _game_state = INTRO;
| _player1.px = SCREEN_WIDTH / 2 - 4;
| _player1.py = SCREEN_HEIGHT / 2;
| _player1.direction = Player::NORTH;
| _player1.behavior = Player::MANUALLY;
| _player2.px = SCREEN_WIDTH / 2 + 4;
| _player2.py = SCREEN_HEIGHT / 2;
| _player2.direction = Player::NORTH;
| _player2.behavior = Player::PREFERRED_ORDER;
| }

| void intro(void) {
| reset_game();
| _tv.print(0, 20, " Arduino Light Cycle Race");
| _tv.print(0, 46, " by Maik Schmidt");
| _tv.print(0, 72, " Press Button to Start");
| if (_controller.c_button()) {
| _game_state = STARTING;
| _tv.clear_screen();
| _tv.draw_rect(
| 0, 0,
| SCREEN_WIDTH - 1, SCREEN_HEIGHT - 8,
| 1
| );
| delay(150);
| }
| }

| void pause(void) {
| if (_controller.c_button()) {
| _game_state = RUNNING;
| print_message(" ");
| delay(150);
| }
| }

| void done(void) {
| if (_controller.c_button()) {
| _game_state = INTRO;
| _tv.clear_screen();
| delay(150);
| }
| }

| void start(void) {
| _player1.draw(_tv);
| _player2.draw(_tv);
| print_message("3");
| delay(1000);
| print_message("2");
| delay(1000);
| print_message("1");
| delay(1000);
| print_message("Go!");
| delay(1000);
| print_message(" ");
| _game_state = RUNNING;
| }

| void play(void) {
| _player1.control(_tv, _controller);
| _player1.move();
| const bool player1_hit = _player1.draw(_tv);
| _player2.control(_tv, _controller);
| _player2.move();
| const bool player2_hit = _player2.draw(_tv);
| if (player1_hit && player2_hit) {
| _game_state = DONE;
| print_message("Tie Game");
| delay(1000);
| } else if (player1_hit) {
| _game_state = DONE;
| print_message("You Lose!");
| delay(1000);
| } else if (player2_hit) {
| _game_state = DONE;
| print_message("You Win!");
| delay(1000);
| }
| if (_controller.c_button()) {
| _game_state = PAUSED;
| print_message("Paused");
| delay(150);
| }
| }

| void run(void) {
| _controller.update();
| switch (_game_state) {
| case INTRO: intro(); break;
| case PAUSED: pause(); break;
| case DONE: done(); break;
| case STARTING: start(); break;
| default: play(); break;
| }
| _tv.delay_frame(1);
| }

private:

| void print_message(const char* message) {
| _tv.print(
| 0,
| SCREEN_HEIGHT - FONT_HEIGHT,
| message
| );
| }

| GameState _game_state;
| TVout _tv;
| Nunchuk _controller;
| Player _player1, _player2;
| };

As in most video games, one of the biggest problems is handling the game’s current state, so first of all we define an enumeration containing all possible states: In state INTRO the game will display a title screen and wait for a button press (see Figure 12). If the buttons was pressed, the game enters state STARTING. In this state it draws the playfield and counts down from three to one, so the player has some time to get ready for the race. Then it enters state RUNNING and handles the actual gameplay. If any player hits a wall the game state changes to DONE. If the player presses a button during the game it changes to PAUSED.

Figure 13: Our Game in Action

After that, we have two methods for initializing and resetting the game. These methods initialize our video and controller hardware and they set back the player settings to reasonable defaults. Then we have a single method for every game state and these are all fairly trivial. There are much nicer ways of implementing a state machine, but in this case a few if statements were appropriate. Please note that I did not debounce the Nunchuk button correctly. I’ve only added a delay of 150 milliseconds whenever I’ve waited for a button press, but in this case it’s OK, because video game players usually are not very patient and want to restart a game as fast as possible. Also I did not distinguish between PAL and NTSC, so if you replace PAL by NTSC in initialize the game will run slightly slower.

The only thing left to do is glue it all together:

Game game;

| void setup() {
| game.initialize();
| }

| void loop() {
| game.run();
| }

Isn’t it amazing how clean code for embedded systems can be? So compile and upload the sketch using the Arduino IDE and have some fun!

We could add a lot more stuff easily and evolve our game into something way more professional. For example, we could add a nicer title screen and a high-score list. Also we could add more advanced artificial intelligence and some visual effects such as explosions whenever a player hits a wall. But the point of this article is not the development of professional-looking games. I wanted to show how easy it is to create a minimalistic video game system with the Arduino.

Video Game Shields for the Arduino

If you’re looking for more professional video game solutions or if you do not want to build a video game system yourself, you can choose from several commercial products:

The Hackvision project is a complete video game system based on the arduino-tvout library. It comes with sound and a five-button controller, and it supports two paddles and a Nunchuk.

If you’re looking for a shield that allows you to output text or graphics to a TV, you can use the video game shield or the TellyMate shield. The former even has support for sound output.

And finally, if you’re really thinking about creating great games for the Arduino you should have a look at the Gameduino shield, one of the greatest shields that was ever created for the Arduino. It supports video output of 400x300 pixels in 512 colors via VGA. It has 256 hardware sprites and 12-bit stereo audio output. In addition, it has a co-processor that you can program in Forth and that works in a similar fashion to the Copper in the good old Commodore Amiga.

Maik Schmidt is the author of Arduino: A Quick-Start Guide. He 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 also the author of Enterprise Recipes with Ruby and Rails and Enterprise Integration with Ruby.

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

Hello, ClojureScript!

Clojure Reaches out to the Web through JavaScript

by Aaron Bedra

One thing nobody ever faults about JavaScript is its reach. It goes everywhere. You can’t escape it. If only using JavaScript’s reach didn’t require you to program in JavaScript. If only you could write your code in—oh, let’s get crazy—in the 21st Century incarnation of LISP, for example....

Clojure rocks, JavaScript reaches. ClojureScript is the realized inevitability of Clojure’s expansion to other platforms.

It seems these days you can’t write a web-based application without reaching for JavaScript. That being the case, it has become pretty clear that everyone would like a better JavaScript. This isn’t a new idea, though. Look at the JVM and the CLR. Both are excellent platforms built by very talented people. Both have initial target languages that these platforms were built around. Using these platforms, language developers have built higher-level languages that allow developers to leverage better, more powerful tools. JavaScript’s “platform” has only recently become a solid foundation for languages, and we have seen some interesting things appear as a result.

ClojureScript seeks to address the weak link in the client/embedded application development story by replacing JavaScript with Clojure, a robust, concise, and powerful programming language. In its implementation, ClojureScript adopts the strategy of the Google Closure library and compiler, and is able to effectively leverage both tools, gaining a large, production-quality library and whole-program optimization. ClojureScript brings the rich data structure set, functional programming, macros, reader, destructuring, polymorphism constructs, state discipline, and many other features of Clojure to every place JavaScript reaches.

ClojureScript was released on July 20th 2011, so you can still expect a few rough edges. It is, however, functioning well and certainly worth trying. Since the full power of ClojureScript is still unclear to most, its developers have provided sample applications in the source code repository so that you can pick them up and get started quickly. Let’s take a look at one of them now.

TwitterBuzz

The most complete of the samples is the TwitterBuzz application. It allows you to type in a twitter hash tag, and it reveals information about that hash tag, including who is influencing others as well as who is leading the charge. It will automatically update when possible and let you monitor a hash tag in almost real time as events unfold. It’s a great way to track news or just play around. Let’s play around.

To get started, you will need to have Oracle JDK version 6 installed, as well as git. Unlike Clojure, ClojureScript currently only targets JDK version 6 because of the use of the Rhino engine, which comes packaged in the JDK in this version. Don’t worry about the other dependencies; ClojureScript comes with scripts to help you bootstrap the rest.

First, you need to clone the repository:

git clone git://github.com/clojure/clojurescript

Once you have the source downloaded, you need to grab the ClojureScript dependencies:

script/bootstrap

After the bootstrap process is complete, you will want to do a small amount of setup to make the ClojureScript compiler tools available to your command line. The full set of instructions is available on the Getting Started page of the wiki. After your setup is complete, you can compile the TwitterBuzz code and run it in a browser. From the samples/twitterbuzz directory, use the following sequence to build the application.

cljsc src > twitterbuzz.js

After this is completed, you can open up index.html in your browser to see everything in action. Type in any twitter hashtag and away you go!

What just happened?

If you take a look in the src directory of the example application, you will see a collection of .cljs files. Upon opening them you will notice that they don’t really look any different from the Clojure code you are used to. Feel free to browse around and examine the implementation. There are a few differences between ClojureScript and Clojure, but that discussion is for another time.

After you are through looking through the source of the twitterbuzz application, turn your attention to the out directory at the root of the project. Here is where all of the compiled code ends up. You will notice a few directories. A majority of this is supporting infrastructure, including ClojureScript itself, compiled down to JavaScript. Head in to the twitterbuzz directory to see what the cljs files were turned into.

Here you will find some fairly human-readable JavaScript code. It certainly isn’t what you would write if you were to sit down and do this by hand, but you can still understand what it is trying to accomplish. This code is what was executed when you first ran the example in your browser—this, along with the rest of the code that is in the out directory. By now you may be thinking that this is an awful lot of JavaScript, and you are 100% correct. ClojureScript has an answer for that.

Advanced Compilation

ClojureScript targets Google Closure’s advanced compiler. This piece is what really makes ClojureScript stand out. Demonstration is much more powerful than explanation here, so let’s give it a try. Run the following command from the root of the twitterbuzz project.

cljsc src '{:optimizations :advanced}' > twitterbuzz.js

Open twitterbuzz.js again. The entirety of the twitterbuzz application is now in this one file. The Closure compiler will attempt to evaluate and eliminate all unnecessary code and compact the rest. This is much more than just minification! If you want to see more information about advanced compilation mode in ClojureScript you can do so on the wiki page.

Take a look now at index-advanced.js. Notice the difference at the bottom of the file where the script tags are. We are now down to just one. If you take a look at the size of twitterbuzz.js you can see that it is a mere 120k. It compresses down to 36k. This makes it small enough that delivery to all platforms, including mobile devices, is no longer a pain. There are even ongoing plans to reduce the advanced-mode compilation output even further.

Wrapping Up

You have seen just a tiny sliver of what ClojureScript is capable of. The ClojureScript team has a lot more up their sleeves and will continue to improve the language. You can track those changes on the github project page and follow the discussions on the mailing list.

Aaron Bedra is a developer at Relevance and a member of Clojure/core, where he uses Clojure to solve hard, important problems. He is the co-author of Programming Clojure, Second Edition.

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

Decouple Your Apps with Event-Driven CoffeeScript

How Event-Driven CoffeeScript Can Save You from Dependency Hell

by Trevor Burnham

Trevor shows how to make Node applications as cleanly organized as those in any other runtime environment.

Unit testing is a pain.

Well-tested code is great. That’s what I tell everyone. Who doesn’t? But more often than not, I just don’t wanna do it on my own projects. That’s partly because most functionality is hard to test in isolation. Unless you’re writing a calculator, your application contains a lot of units that each depend on several other units: Your game’s monster unit invokes sound and video components when struck by a bullet; your bug tracker’s issue unit summons email and RSS when a reply is added; and just about every file in a typical Node.js web app could well start with:

| db = require 'db'
| logger = require 'logger'
| markup = require 'markup'
| ...

And so on. Node’s modularity is both a blessing and a curse. While frameworks like Rails make just about every piece of code accessible from everywhere else, Node forces you to make your dependencies explicit. That’s great when you have only a handful of moving parts, but when you have hundreds, it’s a nightmare. And how can anything be tested in isolation when so many dependencies are required?

Fortunately, there’s a way to simplify your application’s structure without simply making everything global: instead of having units communicate through function calls, have them emit events.

Emissions As Transmissions

Node.js is said to be event-driven because it has no threads. Instead, every time a script has finished running, Node checks if any events have been queued (via a method like setTimeout or readFile), and then runs one of the queued functions. The result is often more efficient and less bug-prone code than in other languages where several pieces of code are run “simultaneously” via threading.

But the word “event” has another meaning in Node.js in the form of the EventEmitter API (Full documentation available here.) An EventEmitter can “emit” any kind of event (identified by a string), and when it does, all matching “listeners” (callbacks) are immediately triggered. (If you’re familiar with jQuery or Backbone.js, think of emit as trigger and addListener/on as bind.) EventEmitter is a “class” in the JavaScript sense of being a function with a prototype object attached. That means that you can create EventEmitter instances:

| {EventEmitter} = require 'events'
| emitter = new EventEmitter
| emitter.on 'foo', -> console.log 'bar'
| emitter.emit 'foo' # bar

Or you can make your own EventEmitter subclasses:

| {EventEmitter} = require 'events'
| class Rooster extends EventEmitter
| constructor: ->
| @on 'wake', -> console.log 'COCKADOODLEDOO!'

(foghorn = new Rooster).emit 'wake' # COCKADOODLEDOO!

Or you can “mix in” EventEmitter’s prototype to add its functionality to an existing object:

| sprinkler = waterSupply: 2
| sprinkler[k] = func for k, func of EventEmitter.prototype
| sprinkler.on 'fire', ->
| if @waterSupply > 0
| @waterSupply--; console.log 'fire extinguished'
| else
| console.log 'good luck...'

| sprinkler.emit 'fire' # fire extinguished
| sprinkler.emit 'fire' # fire extinguished
| sprinkler.emit 'fire' # good luck...

Notice that while emit sounds like something that an object does on its own, the method is public and can be called from anywhere. This is key—anything you can do with a function call, you can do by emitting an event instead. (OK, so events can’t return a value, but this is JavaScript; use a callback!) You can pass arguments after the event name:

| cave = new EventEmitter
| cave.on 'echo', -> console.log x for x in arguments
| cave.emit 'echo', 'Hello?' # Hello?

But what makes the events even more powerful than ordinary function calls is that you can “stack” multiple listeners on the same event. The listeners are triggered in the same order they were attached in:

| codeMonkey = new EventEmitter
| codeMonkey.on 'wake', -> console.log 'get up, get coffee'
| codeMonkey.on 'wake', -> console.log 'go to job'
| codeMonkey.on 'wake', -> console.log 'have meeting'
| codeMonkey.emit 'wake' # get up, get coffee; go to job; have meeting

Inverting Dependencies

So, how can event-driven code save us from dependency hell? Let’s go back to that monster example from the start of the article. We want it to do a bunch of things when it gets hit. A straightforward approach would be to write code like this:

| class Monster
| constructor: -> @hp = 1000
| hit: (damage) ->
| @hp -= damage
| if @hp > 0
| audio.play 'monster_hit'
| video.show 'monster_hit'
| player.score += 5
| else
| audio.play 'monster_die'
| video.show 'monster_die'
| player.score += 100
| world.remove this

But look at all the dependencies we have here: audio, video, player, world... That leads to two problems: one is that we have to get references to those objects from every single Monster-like module, leading to lots of code duplication. The other is, how do we test Monster::hit? Surely we don’t want a bunch of monster noises to erupt every time we run our game’s suite of unit tests!

One common approach would be dependency injection, providing some way for Monster to get mock instances of audio and video that have the same properties as the real instances but none of the side effects. Another would be to take advantage of JavaScript’s dynamic nature by directly manipulating the prototypes of objects like audio and video, rendering them inert in test mode. A third would be to special-case those calls with a conditional, something like unless testMode. Of course, none of these workarounds help with the code duplication that comes from explicitly spelling out all dependencies.

What if, instead, we use an event to separate our internal logic code from everything else?

| class Monster extends EventEmitter
| constructor: -> @hp = 1000
| hit: (damage) ->
| @hp -= damage
| if @hp > 0
| @emit 'hit'
| else
| @emit 'die'

Now all we have to do is listen for that event somewhere. Let’s say that the world object is responsible for spawning monsters, and when it does, it emits a new_monster event with the new Monster as an argument. Then in the audio object, we can add:

| world.on 'new_monster', (monster) =>
| monster.on 'hit', => @play 'monster_hit'
| monster.on 'die', => @play 'monster_die'

The video code would look much the same. And the player code would look like:

| world.on 'new_monster', (monster) =>
| monster.on 'hit', => @score += 5
| monster.on 'die', => @score += 100

In many ways, this way of organizing code is more logical. It allows the Monster class to stay more “pure.” To unit test it, all we have to do is create it without emitting the usual new_monster event. And check out how much nicer our dependency graph has become!

Imagine No Dependencies

A lot of Node developers will tell you that attaching things to global rather than exports is a no-no. And if you’re packaging your code as a library, or trying to make your code reusable, then they’re right. But if you’re developing a standalone application, then go ahead and let yourself declare a few globals. In particular, if you’re using the pattern described in the last section, try adding this to your main application file:

global.world = world

Not only is this one line worth a thousand world = require 'world's, but it also makes the world dependency soft and easy to replace. At the top of your application’s tests, you could put this:

| global.world = {
| eventListeners: {}
| emitCounts: {}
| on: (event, func) -> (@eventListeners[event] ?= []).push func
| emit: (event) -> @emitCounts[event] ?= 0; @emitCounts[event]++
| }

Now none of the listeners attached to world will ever actually be fired, and you can easily run assertions on how many listeners are attached for a given event and how many times that event has occurred.

Alternatively, you can take the lighter tack of simply adding additional listeners for testing and selectively using EventEmitter::removeListener to halt those persistent monster screeches during unit testing. You might take advantage of the once method for your assertions, which acts just like on except one-time-only:

| nasa = new EventEmitter
| nasa.once 'land_on_moon', -> console.log 'Wow!'
| nasa.emit 'land_on_moon' # Wow!
| nasa.emit 'land_on_moon' # (silence)

Conclusion: Making the Most of Modules

Despite Node’s reputation for complexity, I’d argue that it’s possible to make Node applications as cleanly organized as those in any other runtime environment. The event paradigm provides an elegant way of connecting objects, providing maximum flexibility and minimum boilerplate. It’s test-friendly, and encourages application code to be split up more by categories of functionality and less by imperative order. There’s nothing else quite like it.

JavaScript has become the world’s most important language. And I, for one, welcome our new event-driven overlords.

Trevor Burnham is the author of CoffeeScript: Accelerated JavaScript Development, new in print from The Pragmatic Bookshelf. As a proponent of beautiful code, he runs @CoffeeScript on Twitter and spoke at RailsConf 2011. As a freelancer, he's available to work on exceptionally interesting projects. He lives in Cambridge, MA.

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

How Virtuous Is Your Code?

Can there be a timeless and universal definition of “good” for software?

by Tim Ottinger, Jeff Langr

That code you thought was so good last year doesn’t look so virtuous today. Were you just wrong then, or has the meaning of “good” changed?

Want to get in an argument with a developer? Tell them their code isn’t very good. The hackles rise, adrenaline kicks in, and then you get that “how dare you” look. But even though we may defend the quality of our code today in passionate arguments and reasoned apologetics, three years in the future—or even three weeks later—we may look back on it with embarrassment.

Disgust with past code is the sure indicator that we’ve learned since then.

We’ve been through myriad definitions of “good code” in the past, some defensible and some quite dubious:

Good code is code that gets the right answer

Good code is written perfectly to spec

Good code is written defensively

Good code uses the language’s features the most elegantly

Good code is expressive

Good code complies to local style guides

Good code is well-commented

Good code uses patterns

Good code can be read by non-programmers

Good code passes its tests

Good code is anything not written here

We find that our definition of “good” doesn’t always transfer as we move from statically typed languages to dynamic, from procedural languages to functional, from waterfall methods to agile, or even between contracting and product development. Perhaps we were good at writing code perfectly “to spec,” but now that our needs are always changing, we collaborate instead of depending on detailed specs. Maybe our code was highly defensive, and now we see such overzealous effort as waste. Did we change, or did “good” change? Were we really writing good code to begin with, or was it self-congratulatory nonsense?

Can there be a timeless and universal definition of “good” for software? It’s like looking for the answer to life, the universe, and everything, but Agile in a Flash offers a possible answer with card #42 (hat tip to Douglas Adams).

We present each virtue in two parts: the virtue and its opposite. Why? Because the words on the left side are not very crisp in common usage. By providing the opposite for each virtue, we help programmers to arrive at our intended meaning quickly and clearly.

Working, As Opposed to Incomplete

That code should work seems to state the glaringly obvious. Yet working is a virtue that generates the most heat as the discussion continues. Here is our favorite formulation of the rule:

“Code that works now is superior to code that may work some day.”

Perhaps you have diagrams of an astrotecture for a future system that, once written, will never have to change again. However cleverly considered, this planned system is far inferior to the prototype your neighbor has already written over the weekend. Perhaps the brilliantly designed and planned software will be superior when it is built, perhaps not. Perhaps by the time the planned system is built, the prototype will have evolved through use and feedback into an amazingly useful program that leads the market for decades. All we can say is that working code now is better than code that is planned to work someday.

Consider also:

“Code continually proven to work is better than code that may once have worked.”

Code that is written without a solid suite of tests may work, or may have worked once, but virtue is more clearly displayed by code that passes a battery of tests many times per day. Automated tests not only demonstrate this virtue, but in the course of writing tests programmers usually have to improve the simplicity and clarity of code, not to mention the removal of duplication. We have become so accustomed and even habituated to TDD that we tend to see untested code as incomplete.

A real-time system is one in which timeliness is a component of correctness. In a real-time system, there is a barrier at which being one microsecond later will render an answer useless or wrong. When the time budget is so tight that it strains our software technology and computer architecture, dire measures may be required to meet computational deadlines. In such a situation, working may be the one virtue that matters. In more workaday situations, however, working is just a starting point.

Sadly, some programmers assemble code from various files in the project, reach some semblance of a working state, and then walk away. This is programming at its lowest, basest state. Once your code works, it becomes a matter of raising the signal-to-noise ratio in ways that are useful to the team. To help guide the improvement process, we provide the remaining six virtues.

Unique, As Opposed to Duplicated

Code wants to be a unique little flower in the universe, just like most people do. Code that’s replicated like stubborn little dandelions throughout your system not only detracts from its beauty, but is very difficult to eradicate once you let it grow rampant. Pluck the dandelion by its head—clean only the surface of the code problem—and it ultimately grows back, and stronger too.

Now that we’ve exhausted the analogy, let’s look at some duplication issues and then see how we might resolve them.

In a popular plugin for a CI tool, the Python code has five near-identical copies of these seven source lines:

| if self.key is None:
| raise APIKeyError("Your have not set an API key.")
| if data is None:
| data = {}
| if build_data:
| self._build_data(comment, data)
| url = '%ssubmit-spam' % self._getURL()

Programmers copy and paste for many reasons. The jump-start that copying code gives us may make code duplication seem like a virtue, but we find the goodness of copying ends before you check in, and the trouble it causes extends years into the future. A change to copied code (in our example, imagine a new choice of exception) will have to be made to many places, and missing one might have expensive repercussions.

Because duplication is so easy to create, so rampant in the typical system, and so costly, we list the unique virtue second only to working.

What about the following chunk of code?

| data.setdefault('referrer', os.environ.get('HTTP_REFERER', 'unknown'))
| data.setdefault('permalink', '')
| data.setdefault('comment_type', 'comment')
| data.setdefault('comment_author', '')
| data.setdefault('comment_author_email', '')
| data.setdefault('comment_author_url', '')
| data.setdefault('SERVER_ADDR', os.environ.get('SERVER_ADDR', ''))
| data.setdefault('SERVER_ADMIN', os.environ.get('SERVER_ADMIN', ''))
| data.setdefault('SERVER_NAME', os.environ.get('SERVER_NAME', ''))
| data.setdefault('SERVER_PORT', os.environ.get('SERVER_PORT', ''))
| data.setdefault('SERVER_SIGNATURE', os.environ.get('SERVER_SIGNATURE', ''))
| data.setdefault('SERVER_SOFTWARE', os.environ.get('SERVER_SOFTWARE', ''))
| data.setdefault('HTTP_ACCEPT', os.environ.get('HTTP_ACCEPT', ''))
| data.setdefault('blog', self.blog_url)

Looks pretty good, right? Something is unique about every line. But what if it looked more like this:

| for (key,value) in [
| ('permalink', ''),
| ('comment_type', 'comment'),
| ('comment_author', ''),
| ('comment_author_email', ''),
| ('comment_author_url', ''),
| ('blog', self.blog_url),
| ]:
| data.setdefault(key,value)
| for (key,env,default) in [
| ('referrer', 'HTTP_REFERER', 'unknown'),
| ('SERVER_ADDR', 'SERVER_ADDR', ''),
| ('SERVER_ADMIN', 'SERVER_ADMIN', ''),
| ('SERVER_NAME', 'SERVER_NAME', ''),
| ('SERVER_PORT', 'SERVER_PORT', ''),
| ('SERVER_SIGNATURE', 'SERVER_SIGNATURE', ''),
| ('SERVER_SOFTWARE', 'SERVER_SOFTWARE', ''),
| ('HTTP_ACCEPT', 'HTTP_ACCEPT', ''),
| ]:
| data.setdefault(key,os.environ.get(env,default))

“Wait, that’s actually longer!” Yet paradoxically there is still less to read because more of the content is unique. The for loop that unpacks the data also tells you the meanings of the columns, adding a bit of the clear virtue for free. (We leave further reduction of duplication here as an exercise for the reader.)

Duplication is a tough enemy. The first challenge is to spot it, not always easy in a large code base. Once you’ve spotted it, getting rid of it requires either a lot of tests or a strong stomach for the high risk of shipping potentially defective code. After all, we want the code to still exhibit the working virtue.

Simple, As Opposed to Complicated

Whenever a developer says “simple,” a dozen of his peers nod their heads but very few of them have the same understanding of the word. People may mean “easy to read” or “easy to write” or “uses no advanced features.” We have a different definition.

We like to think of simplicity as a measurable attribute, consisting of the number of unique names and operators in a given code component (class, method, function, subprogram, etc.). Some people have suggested that we call this virtue “structural simplicity.” That works for us.

If a function has dozens of variables and hundreds of operators with dozens of paths, it is not simple even if it is clear and works. Code that is well-named is not necessarily simpler than code that is ill-named, because naming doesn’t affect the number of operators and entities in the passage of code.

Likewise, copied code is usually no simpler than hand-written code. Terse code can be simple, or a plethora of operators and side-effects may make it quite complicated. Working code may be simpler or more complicated than nonworking code. These virtues are pretty much orthogonal.

Complexity may be moved, but can seldom be entirely removed from a system. Here are examples of techniques for taming complexity:

The null object pattern can eliminate dozens and dozens of if..else statements. Fewer paths is simpler.

Refactoring to replace switch..case statements with polymorphism can take a decision that is duplicated throughout a code base and replace it with a decision made once on object construction.

Using the strategy pattern instead of flags can likewise reduce the number of decision points in a program.

Grouping variables into classes and structures can result in code that manipulates many fewer symbols and is simpler even though the new class absorbs the collection of variables.

Treating any set of two or more attributes as a list can reduce copied-and-edited sections of code with a simple loop.

Extracting functions can move operations into a new, small, simple method and reduce the caller’s complexity. This often enhances clarity and reduces duplication in addition to simplifying the caller.

Unneeded architectural layers can be collapsed.

An array of objects is simpler than cross-indexing a number of arrays that use the same index. It is less primitive, and yet simpler.

There are many other techniques, but these are commonly used to good effect.

Clear, As Opposed to Puzzling

Uncle Bob once mentioned the notion of a new quality metric: WTFs per minute. (We will claim the delicate expansion of the acronym here: What’s This Foolishness? … ) A WTF is the very opposite of clear, causing its readers to scratch their heads in puzzlement.

Here is an example of code that is not clear in its intent:

| list1 = []
| for x in theList:
| if x[0] == 4:
| list1 += x
| return list1

And here is a version that is much clearer without being any less complex (algorithmically, in terms of symbols being manipulated):

| flaggedCells = []
| for cell in theBoard:
| if cell.isFlagged():
| flaggedCells += cell
| return flaggedCells

The second version differs in the following ways:

Variable names are more expressive (variable naming affects only clarity).

A primitive integer type is replaced with a class (see developed, below).

Its introduction of an explanatory function isFlagged eliminates an index and magic number comparison, making code both clearer and simpler.

There are really no good excuses for not constructing your code so that other developers can understand and maintain it easily, but we’ve heard plenty:

“I’m in a mad rush.”

“I couldn’t find a good example out there.”

“You’ll figure out what I meant, just study it a while longer.”

“I don’t really care about this section of code.”

“I was experimenting, but I didn’t have the chance to reimplement it.”

“It just needs to work” (aka “one virtue is good enough for me”).

All else being equal, at least developers don’t usually try to argue that puzzling code is better than clear and obvious code. The argument is usually about the trade-off between clarity and other virtues. In such a case, it’s good to experiment with naming, introducing explanatory variables or explanatory (inline) function calls. There may be ways of improving clarity that do not sacrifice other virtues at all.

Is clarity a matter of making the code more “English-like?” Not necessarily. This example does show improved clarity with its implementation that reads fairly well as English prose. But in our unique example above, we changed a step-by-step approach into one arguably less English-like and yet clearer.

Easy, As Opposed to Difficult

Software projects, agile or otherwise, may experience schedule pressure. There is a lot of eagerness among customers for new features, and developers have an eagerness to produce them. Eagerness for features and awareness of costs are healthy drivers.

We want to write, test, and release code more quickly so we can fulfill our promises, but often we don’t get past the wishing phase. We don’t always go to the trouble of making our systems more easily workable. For instance, what if the programmer in the first example (unique) had taken a little time to put his data in tables and to write subroutines instead of copying code? It would be easier to add data to the table than to add commands the old way, and it would be easier to create a new interface point if there was less code to copy and test. The payback would have been immediate, and the changes are simple, but they were “not what he was here to do.”

Oddly, we find people more willing to add complexity in the form of if statements, switch statements, unnecessary design patterns, and bloated architectural ideals than to invest a fraction of that time to make code more maintainable.

A little syntactic sugar can often turn a difficult, problem-fraught job into a simple and pleasant one. When Python or Ruby metaprogramming is done well, the code is easier to write. When it’s done badly, it confounds problem-solving (making it less easy).

In a system with the easy virtue, everyone on the team moves a little faster. It’s not hard or tricky to add new code, and nobody is wrestling with obscure bugs or tedious syntax.

How much time does your entire team spend in a month to make their jobs easier?

Developed, As Opposed to Primitive

The word developed in this context means that a good set of supporting mechanisms has been created and groomed. (Think “well-developed.”) It may be a set of functions, classes, libraries, or even servers.

In an undeveloped system, the programmer is doing everything by hand. Instead of using a list comprehension, he must write a for loop with an integer index. Instead of walking through a list of tuples, he has to correlate a number of arrays on the same index variable. Instead of creating an XML node and adding properties, he must write angle brackets and strings to a stream. In this way, a developed language system has virtue over one that is less rich in mechanism and data types.

This virtue is an enabler to the virtue of easy, and indeed may be a side-effect of unique and simple. One difference that makes developed stand out is the choice of moving complexity out of user code and into service routines.

Where the underlying system is underdeveloped, developers will often create code generators or resort to copy-and-edit programming. One can hardly blame them for not wanting to deal with primitive containers, primitive variables, and the like.

When we say developed, we’re measuring the amount of aid a component provides, not the number of hours of effort that have been put into it. A large, complex system may have had many man-years of development activity, yet provide little aid to programmers. Such a system may actually be net-negative, costing more in frustration and development time than it saves. We find a developed system to be rich in mechanism, with just enough policy to help programmers do a good job without restricting them to preconceived use cases.

Brief, As Opposed to Chatty

If we never had to maintain code, code would need only the virtue of working. However, the vast majority of programming work requires some level of maintenance to existing code. As a considerate developer, then, we take care to craft our code to say exactly what we mean, nothing more. Prolix code requires more comprehension time and generally more maintenance effort.

Remember that brief does not mean cryptic, however. Brief code must remain easy, simple, and clear if it is to retain all of the necessary virtues.

Here is a semi-virtuous example from earlier:

| flaggedCells = []
| for cell in theBoard:
| if cell.isFlagged():
| flaggedCells += cell
| return flaggedCells

Our C# friends are about to write follow-up comments telling us that this is a good place to use LINQ. Pythonistas are ready to suggest list comprehensions. We agree. Such features allow us to put code like this into a single statement:

return [ cell for cell in theBoard if cell.isFlagged() ]

The non-Python, non-LINQ, non-FP folks may find it puzzling at first glance, and then realize with a start that this terse code is actually more readable than the longer, explicit loop above.

The more terse code allows us to see the entire algorithm in a glance. We do not have to wade through a sea of variables and operators. This is the kind of brevity that we look for (and for which we expect to see many followups from functional programmers).

The virtue of brevity speaks directly to the concept of abstraction in programming. We seek for our code to quickly express its intent, by emphasizing more of what it is doing and deemphasizing how the code is accomplishing it.

Warriors Of Virtue

As developers, our first job is to make the code work. Yet our task does not end there. We accept that sometimes one virtue may be locally diminished a bit for the sake of other virtues, but code that merely works (or is merely easy to write) is not going to serve developers as well as code that is virtuous in many ways.

Our employers and clients need us to build systems that are economical to amend and improve. If we churn out great heaps of steaming refuse that worked once, we are neither serving their interests nor our own.

As programmers over the magical age of 40, having survived bubbles and downturns and recessions and corporate takeovers, we have learned that your reputation for good work is the only real job security. Writing virtuous code serves us in the long term as well as the short.

Are these virtues a universal definition of good? We think they might be, but we welcome your suggestions, arguments, improvements, and corrections.

Tim Ottinger is the originator and co-author of Agile in a Flash, a contributor to Clean Code, and a 30-year (plus) software developer. Tim is a senior consultant with Industrial Logic where he helps transform teams and organizations through education, process consulting, and technical practices coaching. He is an incessant blogger and incorrigible punster. He still writes code, and he likes it.

Jeff Langr has been happily building software for three decades. In addition to co-authoring Agile in a Flash with Tim, he’s written over 100 articles on software development and a couple books, Agile Java and Essential Java Style, and contributed to Uncle Bob’s Clean Code. Jeff runs the consulting and training company Langr Software Solutions from Colorado Springs.

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

Code As Dialog

Insights on Software Development from a Writer’s Conference

by Brian Tarbox

Can principles of fiction writing improve your code?

I recently attended a writer’s conference at Wesleyan University, my alma mater, which touched off a series of thoughts about writing software.

One of the common questions at the conference was, “So, what kind of writing do you do?” When I answered that I wrote software, the reaction was interesting. I got either puzzlement (how is that writing?) or sage understanding. To assuage the first group I started answering that I hoped I was writing non-fiction.

Code As Dialog

The workshop that stuck with me the most was a discussion about writing dialog. The author leading the workshop asked the class why some dialog didn’t work. He gave as an example the dialog from a Honda advertisement.

Person1: I just bought a new Honda.

Person2: Wow, is that the one with great gas mileage and a 5 star government crash test rating?

Hands, please. How many feel that this bit of dialog works?

Right. Neither do I. Neither did the workshop leader. But the interesting question is, “Why doesn’t it work?”

The workshop leader’s explanation was that this dialog didn’t work because the participant was lying—his character simply wouldn’t normally talk that way.

Dialog that isn’t true to the characters won’t work.

I’ve always been a big fan of the notion that creativity comes from taking ideas from one domain and seeing what happens when you put them into another domain. So I decided to think of my code as dialog and see how well this rule about dialog applies to code.

Think of your classes as the actors in a drama. Is your dialog believable? Would that class really say that? If your class is making a “special” call to another unrelated class, perhaps it isn’t just a case of bad coupling—perhaps your class is lying!

The mandate to “decrease coupling and increase cohesion” has been around for so long that it seems to have lost its meaning. I know lots of people who can quote it but then admit they have no idea what it really means. Perhaps thinking about your classes as actors in a drama can make it more real.

Think of the movie Tron (the original or the recent sequel). Many of the characters in that movie were computer programs. I remember that in the original, one of the programs was an accounting program. When he introduced himself to the title character, Tron, he said something like, “I’m an accounting program. You know, it feels good to know I’m helping improve people’s financial health.” The line was striking because it was totally in character: it was just what you’d expect an accounting program to say if it talked to you!

What would your programs say if Tron ran into them? “Hi, I’m a side-effect manager; I’m supposed to do thread scheduling but sometimes I randomly update the printer queue.” Poor Tron would tilt his head and say “huh?” He’d be dealing with an inconsistent character, one not true to itself.

Taking this analogy a step further, let’s talk about the Show Bible.

The Show Bible

At the same writer’s conference I attended a talk about writing for a TV series. Many such series accept third-party scripts. The challenge for the freelancer pitching a story to an established series is that the series is a little world with all kinds of rules about how the characters act and speak.

To give the freelancer a better chance of writing something that will work, one of the things they give you before you create a story for them is the Show Bible. This document describes the universe of the show: “Monk can touch money but needs a wipe after shaking hands,” “Star Fleet officers don’t need money but normal people in the Federation do,” “Spike (on Buffy) can drive a car in the daylight even though he is a vampire.”

So can the idea of the Show Bible be applied to software development projects? I think it can; in fact, I think the Show Bible is very much like a project architecture document—or perhaps a group’s Design Philosophy guide. It spells out the rules for the universe of the creation, what’s acceptable and what’s not. You can certainly violate the rules on occasion, but to the degree that you don’t, your story will be better—whether it’s the story you’re pitching to the TV series or the story your code is telling.

We spend our time worrying that our code is doing the right thing rather than trying to make it elegant or beautiful, as if the two concerns were unrelated. Perhaps if we tried to write better stories we'd end up with fewer bugs.

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

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

When Did That Happen?

HyperCard, Hyperlinks, and Grunge

by Dan Wohlbruck

24 years ago this month, Kurt Cobain and Bill Atkinson released products that are still remembered fondly.

In 1987, Kurt Cobain, Krist Novoselic and Dave Grohl founded the rock group Nirvana. Their 1991 album, Nevermind, helped Nirvana move into the mainstream and start something then called “grunge.”

At the MacWorld Conference & Expo held in Boston, Massachusetts, in August of that year, Apple introduced a product called HyperCard. The system was created by Bill Atkinson and its programming language, HyperTalk, was implemented by Dan Winkler. HyperCard allowed people who had never written a line of code to create applications in its cards-in-a-stack metaphor. Although it used a single-computer database, information in the cards could be linked via clickable text or images or buttons, with the links working within a stack or between stacks. A kind of hyperlink.

One person influenced by the simplicity and power of HyperCard was Robert Cailliau. In an interview with Computing Now, he recalled:

“I had been developing document handling systems at CERN, and I had also been toying with Hypercard. We had all buildings connected with Appletalk, and it was just conceivable that we could get something done with hypertext over the network.”

Cailliau worked with a colleague at CERN, one Tim Berners-Lee, who was also a HyperCard fan, and who also saw great potential in the idea of hypertext. In March 1989, a memo titled “Information Management—A Proposal,” written by Berners-Lee, was distributed at CERN. In its understated introduction, he said that he would summarize his short experience with a non-linear text system called hypertext. Berners-Lee called his proposed solution a system of linked information and he went on to summarize such a system:

“In providing a system for manipulating this sort of information, the hope would be to allow a pool of information to develop which could grow and evolve with the organisation and the projects it describes. For this to be possible, the method of storage must not place its own restraints on the information. This is why a ‘web’ of notes with links (like references) between them is far more useful than a fixed hierarchical system. When describing a complex system, many people resort to diagrams with circles and arrows. Circles and arrows leave one free to describe the interrelationships between things in a way that tables, for example, do not. The system we need is like a diagram of circles and arrows, where circles and arrows can stand for anything. We can call the circles nodes, and the arrows links.”

The memorandum proposes a solution: hypertext. He says, “Hypertext is a term coined in the 1960s by Ted Nelson which has become popular for these systems, although it is used to embrace two different ideas. One idea (which is relevant to CERN’s problem) is the concept: ‘Hypertext’: Human-readable information linked together in an unconstrained way.” The memorandum suggests that hypertext could be used to make hot spots in documents. Hot spots were described as being “...like icons, or highlighted phrases, as sensitive areas. Touching a hot spot with a mouse brings up the relevant information, or expands the text on the screen to include it. Imagine, then, the references in this document, all being associated with the network address of the thing to which they referred, so that while reading this document you could skip to them with a click of the mouse.”

Berners-Lee then cataloged the requirements of a documentation system at CERN. He identified the need for remote access across networks, the desire for heterogeneity which he said would permit the system to address data from different systems, and the ability to include access to existing data. Berners-Lee finished his list of system requirements by saying that users of the system must be able to add their own private links to and from public information.

The proposal came to this conclusion: “We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities. The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards. The result should be sufficiently attractive to use that it the information contained would grow past a critical threshold, so that the usefulness of the scheme would in turn encourage its increased use.” CERN decided to proceed with the proposed system but even Berners-Lee could not envision how attractive it would become.

Like Grunge, it would take several years for Berners-Lee’s idea to become a phenomenon. On Christmas Day 1990, the new system accomplished its first successful communication link between a Web browser and server. The components of the first successful transmission were the hypertext markup language (HTML), a browser to interpret HTML coding, and a server capable of supporting HTML by executing the hypertext transfer protocol (HTTP).

HyperCard, although still in use, is no longer supported by Apple. Its creator, Bill Atkinson, once lamented that had he foreseen the power of the network he would have expanded HyperCard beyond a single processor. The World Wide Web, however, just like Nirvana, goes on and on.

Grunge and HyperCard started almost 25 years ago. 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.

Like this article? Hate it? Think Ted Nelson deserves more credit? Or Vannevar Bush? Send the author your feedback or discuss the article in the magazine forum.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

Who’s where, and what for.

Aug 3–5, JRubyConf, Washington, DC

“JRuby, not just for hard-headed pragmatists anymore”

Ian Dees, author of Scripted GUI Testing with Ruby and coauthor of Using JRuby

Aug 8–12, Agile/XP 2011 10th Anniversary, Salt Lake City, UT

Celebrating, we assume

Andrew Hunt, author of Pragmatic Thinking and Learning

Aug 8–12, Agile 2011, Salt Lake City, UT

“Agile In a Nutshell” and “The Surprising Science behind Agile Leadership”

Jonathan Rasmusson, author of The Agile Samurai

Aug 8–12, Agile 2011, Salt Lake City, UT

“Budgeting Black Hole: Predicting the Unpredictable ”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Aug 8–12, Agile 2011, Salt Lake City, UT

Tim will be talking about whether pairing will ruin your company and also giving the fundamental agile apologetic.

Tim Ottinger, co-author of Agile in a Flash

Aug 8–12, Agile2011, Salt Lake City, UT

Facilitating Open Jam

Rachel Davies, co-author of Agile Coaching

Aug 11, Agile 2011, Salt Lake City, UT

“The Only Agile Tools You'll Ever Need”

Jeff Langr, co-author of Agile in a Flash (with Tim Ottinger) and Agile Java

Aug 12–13, Cocoa Conf, Columbus, OH

Keynote: “Your Code: The Director’s Cut” plus sessions “Mac OS X for iOS Developers” and “The Key to Blocks”

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Aug 12–13, Cocoa Conf, Columbus, OH

“Introduction to AV Foundation” and “Advanced AV Foundation”

Chris Adamson, author of iPhone SDK Development

Aug 12–13, Cocoaconf, Columbus, OH

“Understanding View Controllers ” and “Drawing with Core Graphics on iOS ”

Bill Dudney, author of Core Animation for Mac OS X and the iPhone and iPhone SDK Development

Aug 12–13, CocoaConf, Columbus, OH

Emcee

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

Aug 20, Madison Ruby Conference, Madison, WI (Brian says: “And seriously, if you’re not going to this conference, you’re going to miss out on a lot of fun. I’ll buy a beer for any other Prags author/editor/publisher who says hello.  Come on! Come to Wisconsin before it gets cold again!”)

“Building A Gem From Scratch”

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

Aug 22–25, Pragmatic Studios, Denver, CO

iPhone Studio

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Aug 28–Sept 2, Problem Solving Leadership, Albuquerque, NM (Email her for the registration form)

“Problem Solving Leadership”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Sept 2, Reaktor Dev Day, Helsinki, Finland

“Regex in Scala”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Sept 2, Reaktor Dev Day, Helsinki, Finland

“Pomodoro Technique—Can you focus for 25 minutes?”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Sept 7, JavaZone 2011, Oslo, Norway

“Regex—The Future Programming”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Sept 7–9, Heartland Developers Conference, Omaha, NE

“Unleashing your Inner Hacker”

Aaron Bedra, co-author of Programming Clojure, Second Edition

Sept 7–9, ALE2011, Berlin, Germany

Opening Keynote

Rachel Davies, co-author of Agile Coaching

Sept 9–11, New England Software Symposium, Boston, MA

“Hello Groovy!,” “Grails: Bringing Radical Productivity to the JVM”

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

Sept 11–14, SpeakerConf, Rome, Italy

David says, “Knowing me, I’ll be able to report on what I talked about after the fact and not much sooner. :)”

David Chelimsky, co-author of Thje RSpec Book and contributor to Advanced Rails Recipes

Sept 12–13, Agile Program Management, Berlin, Germany

“Agile Program Management”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Sept 15–16, Agile on the Beach, Falmouth, UK

“Surfing the Agile Wave”

Rachel Davies, co-author of Agile Coaching

Sept 15–16, Agile Program Management, Amsterdam, Netherlands

“Agile Program Management”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

Sept 16, Innovate Virginia, Richmond VA

Keynote

Andrew Hunt, author of Pragmatic Thinking and Learning

Sept 16, Innovate Virginia, Richmond VA

“Building Analytics with Clojure”

Aaron Bedra, co-author of Programming Clojure, Second Edition

Sept 16, Innovate Virginia, Richmond VA

“Tightening Your Feedback Loop”

Jared Richardson, author of Ship It!

Sept 18–20, Strangeloop, St. Louis, MO

“Clojure Part 2: Building Analytics with Clojure”

Aaron Bedra, co-author of Programming Clojure, Second Edition

Sept 18–20, Strange Loop, St. Louis, MO

“Airplane-Mode HTML5: Is your website mobile-ready?”

Scott Davis, author of Groovy Recipes

Sept 18–20, Strange Loop, St. Louis, MO

“Skynet: A Scalable, Distributed Service Mesh in Go”

Brian Ketelsen, author of The Go Programming Language

Sept 18–20, Strange Loop, St. Louis, MO

“Functional Thinking”

Neal Ford, coordinating the forthcoming Thoughtworks Anthology 2

Sept 19, Strangeloop, St. Louis, MO

“Skynet: A Scalable, Distributed Service Mesh in Go”

Brian Ketelsen, author of The Go Programming Language

Oct 2, Oracle OpenWorld, San Francisco, CA

“SQL Injection Myths and Fallacies” and “Maatkit Tools—Like a MySQL Guru in a Box”

Bill Karwin, author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming

Oct 2–6, Java One, San Francisco, CA

He’ll be representing Clojure in the script bowl.

Aaron Bedra, co-author of Programming Clojure, Second Edition

Oct 10, Web 2.0 Expo, New York, New York

“The New Startup Stack”

Trevor Burnham, author of CoffeeScript: Accelerated JavaScript Development

Oct 17–20, Zend PHP Conference, Santa Clara, CA

“SQL Injection Myths and Fallacies” and “MySQL 5.5 InnoDB Tuning”

Bill Karwin, author of SQL Antipatterns: Avoiding the Pitfalls of Database Programming

Oct 24–27, Pragmatic Studios, Reston, VA

iOS Studio

Daniel Steinberg, co-author of iPad Programming: A Quick-Start Guide for iPhone Developers and author of Cocoa Programming: A Quick-Start Guide for Developers

Oct 30–Nov 4, AYE Conference, Cary, NC

“Project Bloat Doesn't Float,” “Replacing Management Myths with Effective Practices,” “Influence and Authority: Using Your Personal Power to Get Things Done,” “Adapting to Change in Your Life,” and a one-day workshop: “Making Geographically Distributed Projects Work”

Johanna Rothman, author of Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects, Manage It!: Your Guide to Modern, Pragmatic Project Management, and Behind Closed Doors: Secrets of Great Management

O’Reilly Events

Upcoming events from our friends at O’Reilly.

Sept 17–18, World Maker Faire, New York, NY

World Maker Faire

Sept 19–23, Strata NY, New York, NY

O’Reilly Strata Conference: Making data work: “With hardcore technical sessions on parallel computing, machine learning, and interactive visualizations; case studies from finance, media, healthcare, and technology; and provocative reports from the leading edge, Strata Conference showcases the people, tools, and technologies that make data work.”

Oct 9–11, Android Open, San Francisco, CA

Android Open Conference: “Android Open is the first conference to cover the entire Android ecosystem. Whether you’re a developer, IT pro, business decision-maker, or marketer, you’ll find the latest and best information for maximizing the power of the Android platform.”

Oct 11, TOC Frankfurt, Frankfurt, Germany

Tools of Change Frankfort: “Tools of Change Frankfurt returns for a third year on... the eve of the Frankfurt Book Fair (12-16 October)—connecting the people, content, and conversations along the cutting edge of global publishing and technology.”

Oct 10–13, Web 2.0, New York, New York

Web 2.0 Expo NY: “At the next Web 2.0 Expo, we’ll reveal the key pieces of the digital economy and the ways you can leverage important ideas for your own success. We’ll look specifically at web success stories in the New York startup ecosystem.”

Oct 17–19, Web 2.0 Summit, San Francisco, CA

Web 2.0 Summit: “Once each year, the Web 2.0 Summit brings together 1,000 senior executives from the worlds of technology, media, finance, telecommunications, entertainment, and the Internet. For 2011, our theme is ‘The Data Frame’—focusing on the impact of data in today’s networked economy.”

USENIX Events

What’s coming from our USENIX friends.

Aug 8–12, USENIX Security ’11, San Francisco, CA

The 20th USENIX Security Symposium. “USENIX Security ’11 brings together researchers, practitioners, system administrators, system programmers, and others interested in the latest advances in the security of computer systems and networks.” Not to mention a bunch of collocated conferences: 2011 Electronic Voting Technology Workshop/Workshop on Trustworthy Elections, 4th Workshop on Cyber Security Experimentation and Test, USENIX Workshop on Free and Open Communications on the Internet, 5th USENIX Workshop on Offensive Technologies, 2nd USENIX Workshop on Health Security and Privacy, 6th USENIX Workshop on Hot Topics in Security, and Sixth Workshop on Security Metrics.

Other Happenings

Aug 9

Alfred Aho, co-creator of AWK language, is 70.

Aug 11

Steve Wozniak is 61.

Aug 20

Game developer John Carmack is 41.

Aug 21

Linus Torvalds announces Linux project, 1991.

Aug 29

Boy genius Stephen Wolfram is 52.

Sept 1

This month the GNU Project turns 28.

Sept 2

First message sent over Internet, 1969.

Sept 2

sendmail creator Eric Allman is 56.

Sept 4

LISP creator and AI pioneer John McCarthy is 84.

Sept 9

C creator Dennis Ritchie is 70.

Sept 10

Space tourist Charles Simonyi is 63.

Sept 27

Perl creator Larry Wall is 57.

Oct 2

The Great Quux is 57.

Oct 4

The Free Software Foundation is 36.

Oct 4

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

Oct 5

Linux is 20!

Oct 6

Adobe co-founder John Warnock is 71.

Oct 12

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

Oct 16

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

Oct 25

Peter Naur, the N in BNF, is 83.

Oct 28

Former software executive Bill Gates is 56.

Oct 29

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

Oct 31

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

Shady Illuminations

Mamas, Don’t Let Your Babies Grow Up to Be Coders

by John Shade

John shares six reasons to avoid software development as a career.

I know, I know, all your friends write software and you wouldn’t be uptight if one of the kids will.

And you read in the Times Book Review that geek is chic and you figure all of your babies’ friends will think they’re cool if they code. Cool like that Mark Zuckerberg. So cool.

And Johnny did such a great job on your website.

But I want you to consider the consequences if you let your babies grow up to be coders.

Six Reasons to Avoid Software Development as a Career

1. They’ll create something cool and get sued for it.

The recent story in The Guardian, the British newspaper that has bigger mountains to topple, is just the tip of this particular iceberg. The story is all about non-US app developers staying out of the US market for fear of being sued.

It’s all about software patents. Software patents are being routinely granted for ideas that are either obvious, trivial, or absurdly broad. Patent trolls build business models around acquiring software patents to use to squeeze money out of independent developers. The only way to guard against being sued is to pay more in patent search costs than you’re likely to ever recoup from your app. Not that being in a position to defend against a lawsuit will keep you from being sued anyway. And many an entrepreneur has been put out of business by the cost of successfully defending against a lawsuit.

An iOS app is a rowboat off the coast of Antarctica in iceberg season. Don’t let your babies grow up to be rowboat captains among the icebergs.

2. They’ll make an off-by-one error and get thrown in jail.

In an essay in InfoWorld that was so well received that it got republished in JavaWorld, InfoWorld senior contributing editor Paul Venezia campaigns to have bad coding made a felony. This is a brilliant idea and I’m amazed that nobody else has thought of this great technique for motivating quality code development. Would paired programmers share a cell? But that’s just a detail.

Anyway, you can see how the possibility of hard time in Leavenworth would make the profession a little less rewarding. I mean all in all, netting it out. Don’t let your babies grow up to be code criminals.

3. Their brilliant ideas will never take off in an industry that is still focused on imitating filing cabinets and typewriters and slide projectors.

A recent O’Reilly Radar blip describes what might be called the tyranny of files. The file metaphor is just one of the chains that bind software development to the rotting corpse of a dead idea, but it’s one of the ripest. But the true horror is that this attack on files will be a new idea to so many people, when Ted Nelson said it all forty years ago.

To those who believe that good ideas will eventually drive out bad ones, I have one word: QWERTY. Don’t let your babies grow up to be bitter old failures.

4. Even if they do invent something awesome and it does take off, it’ll probably rot our brains.

Tim Berners-Lee and those guys at Darpa invent this Internet/Web thing and the world beats a path to, well not necessarily to their doors, but there’s a lot of path beating being done. And now it turns out that this great invention gives you brain cancer. No, wait. That’s cellphones, that other great invention. The Interweb just makes you stupid.

Aside from the bad karma, this is a classic negative feedback loop. Coding requires intelligence; coding produces technologies that reduce intelligence. A self-limiting system. High school guidance counselors advise against careers that are self-limiting systems. If you babies won’t listen to you, surely they’ll listen to their guidance counselor.

5. Scarier than just rotting our brains, your babies as coders might destroy all life on earth.

The really cool programmers today aren’t coding in Ruby on silicon, they’re recoding the DNA of living organisms. You can read about it in Technology Review.

Notice anything interesting about that article? It’s subtle, but if you read carefully you’ll pick it up. The magazine thinks this is a great idea. Cripes, haven’t MIT’s editors ever heard of grey goo? Don’t they know what Craig Venter is an anagram for?

Your babies don’t need the total destruction of all life on earth on their consciences. Being a doctor is OK. Let ’em be doctors and lawyers and such. Just don’t let your babies grow up to be Dr. Frankenstein or Dr. Strangelove.

6. Even more terrifying, they might bring about the Sex Singularity.

Let’s not even go there. These are your babies we’re talking about.

On the Other Hand

But if your babies have it in them to become coders, then they aren’t the sort of babies who are going to pay any attention to mama’s advice. So your best play is to hope that your baby grows up to be the world’s most famous programmer and a billionaire and then retires to be a benefactor of mankind. And knowing what a silly twit your baby is, you can count on him still managing to make himself look ridiculous.

John Shade was born under a cloud in Montreux, Switzerland, in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He’s just glad he got a chance to say a word about the coders and the mothers from codeville. Send the author your feedback or discuss the article in the magazine forum.

But Wait, There’s More...

Coming Attractions

This may be the last page, but that doesn’t mean it’s the end of the conversation. Keep up with what’s going on in the Pragmatic universe by subscribing to our newsletter and drop by the Pub again next month for more Pragmatism. We’ll keep a seat warm and a mug chilled and a candle burning in the window.

Coming Soon in PragPub

In September we hope to launch a new feature that will take you inside the dark recesses of the mighty Prag machine. And Jeff Cohen is working on a thoughtful essay on the importance of dev community values.

Coming Soon on the Bookshelf

Watch for Cutting an Agile Groove, a video series by David Hussman.

But to Really Be in the Know...

...you need to subscribe to our weekly newsletter. It’ll keep you in the loop, it’s a fun read, and it’s free. All you need to do is create an account on pragprog.com (email address and password is all it takes) and select the checkbox to receive newsletters.

While you’re waiting for the next issue of the newsletter or of PragPub to come out, you can follow us on twitter at @pragpub, @PragmaticAndy, or @pragdave. Or on Facebook at facebook.com/PragmaticBookshelf. Or email us at michael@pragprog.com.