PragPub 2010-05: Issue #11

Table of Contents

Features

The Bruce Tate Interview

interviewed by Michael Swaine

Behind the scenes with the author of Seven Languages in Seven Weeks.

The Floating Finish Line

by Brian Tarbox

Life isn’t fair, information is never complete, and goals change in mid-project. So why does programmer education pretend otherwise?

The Virtues of Mockery

by Noel Rappin

Mock objects can be very useful in test-driven design, but they need to be used wisely.

When Did That Happen?

by Dan Wohlbruck

Dan surveys the history of photography in a series of verbal snapshots, and Kodak appears in almost every shot.

Departments

Up Front

by Michael Swaine

Bruce Tate and Michael tackle Bruce’s book Seven Languages in Seven Weeks—in eighteen questions.

Choice Bits

A little knowledge that is perfectly safe.

The Working Geek

by Andy Lester

When the deck seems stacked against you, you can still win if you play your cards right.

Swaine’s World

by Michael Swaine

Remembering Ed Roberts, whose Altair computer kicked off a revolution that brought computing power into the hands of ordinary people.

The Quiz

by Michael Swaine

A monthly diversion at least peripherally related to programming.

Calendar

Author sightings, partner events, and other notable happenings.

Shady Illuminations

by John Shade

Larry Ellison owns Sun. That may be good, it may be bad, but it will definitely be interesting.

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

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

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

ISSN: 1948-3562

Up Front

Seven Languages in Eighteen Questions

by Michael Swaine

In The Pragmatic Programmer, Dave and Andy recommend learning a new programming language every year. In Seven Languages in Seven Weeks, Bruce Tate cranks the challenge up several notches.

Why would you want to take on Bruce’s challenge? Well, he points out that by learning several languages one right after another, you have an unparalleled opportunity to compare them side-by-side. Which can be highly enlightening. Plus, and this is perhaps even better, you may learn something about learning a language, so that the next time you need to learn a new language, you’ll be able to get to competence quickly and efficiently.

That’s the premise of Bruce’s book, but the tricky part for the author is that he also has to learn seven languages in a very short time, learn them well enough that he can teach them. Well enough that he can devise good example programs that capture the unique aspects of each language, that are challenging enough to provide a good learning experience, and that run error-free.

I wanted to know how he accomplished that, and I found out in this issue’s interview.

Also in this issue are an article by Brian Tarbox that advocates teaching student programmers with unfair assignments, another history feature by Dan Wohlbruck, and an essay on the virtues of mockery by Noel Rappin.

Our columnists are particularly thoughtful this month, with Andy Lester offering advice on how to get that job when the odds are stacked against you in “The Working Geek,” my Swaine’s World column remembering computer pioneer Ed Roberts, and John Shade doing his thing.

And there’s more. You can see where our authors are appearing and track other events of interest in our Events Calendar. You can test your wits against our monthly Quiz, which this time searches for meaning in bizarre headlines. And our Choice Bits department serves up some tasty morsels from the Twitterverse.

Choice Bits

We Thought You Might Like to Know...

Is it ten past eight already?

What’s Hot

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

1^ | NEW | Agile Web Development with Rails 4th Edition
2^ | NEW | iPad Programming
3^ | NEW | Rails Test Prescriptions
4v | 1 | Seven Languages in Seven Weeks
5^ | NEW | Driving Technical Change
6^ | NEW | Cocoa Programming
7v | 3 | The RSpec Book
8 | 8 | iPhone SDK Development
9v | 2 | Hello, Android
10v | 4 | Agile Web Development with Rails, Third Edition
11 | 11 | Programming Ruby 1.9

Sips from the Twitter Stream

Tweets from Kent Beck, Tim Bray, Chris Breen, Mike Clark, Cory Doctorow, John Dvorak, Chris Espinosa, Scott Hanselman, David Heinemeier Hansson, Penn Jillette, Mitch Kapor, Steven Levy, David Pogue, Jay Rosen, Robert Scoble, Nate Silver, Larry Tesler, Dave Thomas, Nick Turner, Jon Udell, Dean Wampler, Wil Wheaton, Tom Waits, Steve Wozniak, and others.

Epigrams and Ephemera

Doing metaprogramming in Java. Fighting generics. Feeling excited but slightly sordid.        — @timbray

maybe the reason for the devaluation of reputation is as much over-supply as it is under-demand — @kentbeck

since nobody can agree on singleton vs eigenclass vs metaclass, i propose we call it simpleton (it has a very narrow view of the world) — @deanwampler

We Do iPad

Reading a #pragpub on the #iPad. Wished that #pandora could be playing in the background. — @sigsegv

Our minds put new things in old categories. So iPad is a color backlit Kindle/Big iPod Touch/Newton sans writing/Alan Kay’s Dynabook/etc.#in — @nomodes

Loving reading the latest issue of the PragPub magazine on the iPad, just grab the ePub and sync to iBooks, @pragprog — @_DavidSmith

If Titanium from http://www.appcelerator.com/ becomes collateral damage in Apple’s war on flash, I’ll help paint the picketing signs. — @dhh

Very cool. iPad Voiceover works with our epubs, reading them aloud. — @pragdave

It is clear that Apple is making the most interesting moves in the industry now. I can’t see a way anyone tears away mindshare from them. — @Scobleizer

No one was writing about the iPad so I thought I’d say something. http://bit.ly/c8LqOZ — @stevenjayl

Scary Stuff

When corporations weaponize copyright to use against civilians, they use artists as human shields #debill — @doctorow

Apparently the #earthquake was upgraded to a 7.2, but I’m still seeing a 6.9 from the Russian judge. — @wilw

The wild parrots of Cupertino just came screaming through our parking lot. — @cdespinosa

Brief Dialog

@pragdave No opds for PragPub yet? — @TrevorBramble

@TrevorBramble pragpub.com/magazines.opds — @pragdave

Need to Know

In Claradon, Texas, it's illegal to dust any public building with a feather duster. — @tomwaits

This article in Apr. PragPub http://bit.ly/cat6kt articulates my frustrations with the Rails eco-system lately. Seaside is *slightly* better — @futuremint

It’s nuts that #JSON doesn’t define a literal syntax for dates and times. Every time I run into that, I want to lie down and take a nap. — @judell

I currently have a world-record 85 Microsoft EXCEL files open at the same time. — @fivethirtyeight

Many readers on the Internet are not so bright, so be sure to type s-l-o-w-l-y. — @FakeAPStylebook

@shiubox it’s a mispronunciation—my name is Dvorak NOT Dvořák. Note the difference. The two are pronounced differently. Pay attention. — @THErealDVORAK

Psyched that @pragprog has their monthly PragPub magazine in HTML format! http://bit.ly/cqVr5X Catching up on last month’s javascript content — @ben_anderson

Footnote: Pungle was passed down to me by my mother and part of everyday speech. I’ve used it for years and every editor has queried it. — @BodyofBreen

Sufis say: “No answer is also an answer.” Modern equivalent: “No tweet is also a tweet.” #nonduality #sufi — @mindheart

@WilliamShatner Hey Bil. Leonard here. Following you. Hope to see you soon — @TheRealNimoy

Reading tweets tagged #me less interesting than I'd expected. — @pragpub

Location, Location, Location

@SuperCoolTnicki you want me to tweet loud to see if anyone’s in downtown la? — @shanselman

“By being everywhere, yet in no exact place, WikiLeaks is, in effect, beyond the reach of any institution or government.” http://jr.ly/yijk — @jayrosen_nyu

Deep Thoughts

Some publishers need Amazon & Apple because publishers have no relationship with their readers. But… — @pragdave

…Amazon and Apple are _why_ some publishers have no relationship with their readers. Chicken, meet egg. — @pragdave

I saw Groundhog Day on cable again. Ironically, it was exactly the same as last time. — @mkapor

MTV has moved the air date for my “Cribs.” Maybe they figured out that easter is more traditionally basketball than Atheist magicians. — @pennjillette

Is it the end of a decade? Doesn’t feel like it. 2010 just feels like its going to be ten past eight. — @GarlicT

segway sundays can’t be beat — @woz

You can follow us on twitter here.

The Working Geek

Getting the Job in Spite of a Disadvantage

by Andy Lester

When the deck seems stacked against you, you can still win if you play your cards right.

Sometimes you’re looking for a job, and you’re at a disadvantage from other candidates. Then it’s time to focus on those parts of the job hunt that matter most to your specific circumstances: a portfolio of your work, and a network of contacts backing you up.

In my session on resumes and interviewing at the Palmetto Open Source Software Conference, there were about a dozen people who were part of vocational rehabilitation. Many states have vocational rehab programs to help retrain people who need to make career changes.

Three of these people were in wheelchairs, including one man, Joey, who apparently couldn’t move his arms or legs, but could write programs on a computer with voice control. A few had had injuries that knocked them out of their chosen careers, forcing a career change into another industry, in this case IT.

Joey told me of going on job interviews where he had the knowledge required for the job, but would be told on arriving that the position had just been filled. Whether or not he was facing conscious discrimination in these cases, he still faced a disadvantage. Even subconsciously, we tend to gravitate more towards people who are like us, and that applies to potential employers.

Dealing with a Disadvantage

There are many different sorts of disadvantages we can face when job hunting. For example:

Physical challenges (limited mobility; deafness)

Physical differences (being very short or tall; missing an arm)

Having been out of work for a while

Making a career change

Just starting in the job market

Whether or not these are actual problems for the candidate, I’m talking about potential prejudices and perceptions about the candidate. Discrimination may be wrong and illegal, but it still exists. It might not even be intentional. A potential employer might not consciously think, “No way I’d hire someone in a wheelchair,” but might still be uncomfortable with the idea subconsciously. The disadvantage to the candidate may be subtle, but it’s still there.

When you’re facing this kind of situation, your two best tools are a solid portfolio and your network of contacts. A portfolio is always important to show your work, but in the case of someone like Joey, he can use it as a tool to sell his programming skill before he even meets with the hiring manager.

For anyone in a technical field, however, a portfolio is a powerful tool to demonstrate the work you can do. It’s a way to show a future employer the results of your skills. If a picture is worth a thousand words, then printed copies of your code must be worth at least that. Instead of saying to an employer, “Yes, I’ve worked with Ruby and Rails,” you can show a working Rails application that says it all for you, and far more convincingly. For system administrators, substitute network diagrams and procedure documents.

In the case of Joey, where his physical limitations freak out employers when he arrives, he should create an impressive portfolio that sells employers on his skills before they ever meet him. He needs to have employers fall in love with his work, and be falling over themselves to get him in for an interview. The goal is to have an employer so excited to perhaps be hiring him that they’ll overlook any misgivings they may have about hiring someone in a wheelchair.

New graduates especially should create a portfolio of work that showcases their skills. New grads often say, “This job wants work experience, but how can I get experience if they won’t hire me?” A portfolio isn’t time spent on the job, but it’s the next best thing if you have no time on the job.

Build Your Portfolio

So what goes in a portfolio?

You fill it with work that shows that you’re able to do the work that an employer wants, or at least that you can write code. And if you don’t have any code? Create some from scratch. It doesn’t need to be creative, or ingenious. But it does need to be an example of what you’re capable of doing.

The other comment I hear when discussing code portfolios is that work created for your day job is not available as open source, or is covered by an NDA, or is for some other reason not to be disclosed. Creating your own code specifically for a portfolio gets around that problem. You’ll want to create your code as open source and host it on a public service like github or Google Code.

Here are some ideas of what you could write to show your programming abilities:

Rewrite grep in your favorite language

Create a blog application

Write a program to analyze your web page’s server logs

Fetch your Twitter stats and graph them over time, or analyze your Twitter feed lexically

Create a command-line to-do list manager, or rewrite Task Warrior in your favorite language

The key is not to show your ingenuity at coming up with a new tool or project, but to show your ability to write solid code. I’m also suggesting that you not use exercises like the Code Kata at codekata.pragprog.com. While such exercises are a great way for you to learn more about programming, they are not the sort of example that will give an idea of what your working applications will look like. You want to show working applications and tools, not just exercises.

When you create your applications for your portfolio, be on your best coding behavior. Your portfolio is supposed to represent your best work, not some code you slapped together in an afternoon. Comment liberally. Take no shortcuts. Create the best code you can.

This portfolio creation might seem silly. You might balk at the idea of writing code that you might not actually need. I suggest you look at it this way: If you’re out of a paying job, then your actual job is to get a paying job. You can spend your downtime playing World of Warcraft or reading Slashdot, or you can create code that will impress your next employer.

Work Your Network

The other tool to work on when you’re at a disadvantage is your network of contacts.

You need to have them as allies to help talk you up to potential employers. If Joey has a contact at a company that he’s pursuing, it’s a huge help if the contact can talk up Joey to the hiring manager. A resume and code portfolio hand-delivered by a current employee can do wonders for your hiring prospects.

You’ll need to have a wide-ranging network to get those contacts.

Get to every user group meeting you can to meet people who can some day help you out in your job search. Better yet, give a talk at a user group meeting (see my articles in PragPub #8 and #9) to show people your skills. Work by attracting people to your social circle, not recruiting them.

Address Disadvantages Head-on

Finally, don’t try to hide what it is that you’re working with.

Just as in political scandals, addressing the problem head-on is always preferable to trying to cover it up. Don’t play your situation for sympathy. Just explain it plainly, and address potential concerns. For example, a candidate might say, “I’m in a wheelchair and have been for the past seven years. The only accommodations I would require are a slightly higher desk, and a special USB keyboard and mouse that I bring with me.”

If your perceived disadvantage is something about your situation, then talk about it like you would discuss any other business situation. Address the potential negative as a positive. Face it head-on, instead of trying to hide it, but don’t bring it up too early lest you give them a chance to exclude you.

When the interviewer asks about your abrupt shift from car sales to network administration, explain “I’d been wanting to leave the sales world for a while, and the downturn in the market gave me my chance. I took advantage of the state vocational rehabilitation program and my local community college to learn about network administration. I’ve been doing server and workstation upgrades for my church, and I’m eager to get some real experience.” You explain the situation, how you’ve worked past it, and where you’re wanting to go.

What’s Your Story?

We all face challenges when searching for jobs. What’s the biggest challenge you’ve had to overcome when landing a tech job, and how did you do it? Let me know in the Forums.

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

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

Swaine’s World

Remembering Ed Roberts

by Michael Swaine

His Altair computer kicked off a revolution that brought computing power into the hands of ordinary people.

Ed Roberts died on April 1 of this year. I only met the Father of the Personal Computer once, but he made a big impression on me—not so much for what he accomplished in technology, but for how, at the height of his achievement, he walked away from it to pursue his real childhood dream.

The dream had been to be a doctor, but electronics held another kind of fascination for the boy in 1950s’ Florida, and the Air Force provided a path to studying electronics. In 1968, while the Air Force had him stationed in Albuquerque, New Mexico, Ed started a small company with a couple of other officers to build and sell radio transmitters for model airplanes. They called the company Micro Instrumentation Telemetry Systems, or MITS.

Within a year Roberts had bought out his partners and was running the company on his own, exploring other hobbyist electronics products. Back then, semiconductors were the hot new technological breakthrough, and Roberts was eager to find a way to make money from them. The most obvious thing was to wrap some hardware around a processor to turn it into a calculator, and back then calculators cost enough that you could imagine building a business around them. Roberts figured he could sell calculator kits to his mail-order customer base of electronics hobbyists.

And it worked—until the semiconductor companies decided they wanted a piece of the action. Texas Instruments started making calculators in 1972, and priced them so low that they effectively eliminated the possibility of a third-party calculator market. Ed Roberts and MITS were facing bankruptcy.

Somehow Roberts managed to talk the bank into lending him money rather than shutting him down. I say “somehow” because the pitch he presented hardly seemed calculated to win over a banker. He proposed developing a computer that he intended to sell through mail-order in kit form for a few hundred dollars. In 1973. Somehow he got the banker to overlook the fact that his mail-order electronics business was failing, that neither Roberts nor anyone else had ever sold a computer through the mail, and that it was a good bet that the market for a kit computer existed only in Roberts’s mind.

The January issue of Popular Electronics had a picture of the MITS Altair on the cover and an article about the computer inside. Once the issue hit the stands, the orders started coming in. Thousands of orders. Roberts had bet the company and won.

In the process, he kicked off many of the pieces that made up the early personal computer industry. David Bunnell, who wrote documentation for MITS, launched many of the important early magazines. Bill Gates and Paul Allen got a big boost in their nascent career. Standards like the S-100 bus and dozens of new computer companies were inspired by MITS. An industry was born.

But three years after shaking up the world with the Altair, Roberts sold MITS to Pertec for something like six million dollars, bought a farm in Georgia, and enrolled in medical school. In 1984, when Paul Freiberger and I visited him in rural Georgia to interview him for our book Fire in the Valley, he had fully re-invented himself as a small-town doctor.

When I heard that he had died, I posted a few words about Ed on a website, and received the following email:

Mike,

I had a couple of chances to meet Dr. Roberts and I thought you might find this story interesting.

In 1990–1991, I was a student at Middle Georgia College in Cochran, Georgia. This stop was after a failed attempt as a student at Georgia Tech, where I was woefully unprepared for the delicate balance between social activities and studies. MGC was a wonderful environment for me to re-learn how to study and appreciate my education.

During my first year at MGC, I broke two fingers during a flag football tourney and was sent to the regional “hospital” in Bleckley County not far from campus. I was administered pain meds and some $2.00 finger splints with a pat on the back from your esteemed friend, Dr. Ed Roberts; he was the on-call doc that afternoon. He was a rather portly man and somewhat gruff, but he had a “no nonsense” approach in his bedside manner and I appreciated the candor and tough love. During this visit to his office, which was in an outbuilding on the hospital campus, I noticed he had a small collection of gadgets in his office but didn’t give it much thought once I was on my way.

Two semesters later I came down with a severe case of mononucleosis, causing me to be bedridden for the better part of six days. Upon my initial visit to Dr. Ed, his demeanor was the same as my previous experience. [He] prescribed some commonsense remedies and sent me on my way. What happened two days later was completely unexpected.

Dr. Roberts showed up at my dorm (Harris Hall) to check my status. I was basically quarantined at the time from my fellow students and friends, so having a visitor was a nice surprise—even better that it was a small-town doc looking to see how his patient was faring. He noticed an old text on my bookshelf from my days at Georgia Tech on logic gates and switches. The conversation changed from my health to his passion and he left two hours later. It was a remarkable conversation on a broad range of tech topics, but seemed to mainly focus on calculator design (I think I had an old HP engineer’s calculator on my desk).

I originally wanted to be a “businessman” of sorts after college and I mainly went to Georgia Tech because of my father’s love for the institution. When I left and went to MGC, I thought the engineer in me was dead, and a career in accounting or the family insurance business would be my calling, but those two hours with Dr. Roberts changed everything. I went on to get a degree from University of Georgia in Economics, but in my free time I was constantly tinkering with computers and software. Thanks to Dr. Roberts’s advice: he encouraged me to follow my instincts and pursue the career that felt natural.

Today I am enjoying the best of both worlds. I’m the IT guy... in the family business. I’ve never had any formal education with a particular software application or platform, but through Dr. Roberts’s encouragement twenty years ago, I tinkered and broke and fixed enough to learn my skill set.

Thought you might like to know that even as a Doctor “in the sticks,” your friend continued to influence and shape young minds to be creative and explore.

And I did not learn that he personally developed the Altair until I read a feature in the Atlanta Journal-Constitution in 1997. He never shared that with me, only his love for technology.

Sean Cavin, Atlanta, Georgia

I thanked Sean for sharing his story, and told him that it really brought back to me the Ed Roberts I had met that summer in Georgia. A truly remarkable man.

Michael Swaine is the editor of PragPub.

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

The Bruce Tate Interview

How Do You Dive Deeply into Ruby, Io, Prolog, Scala, Erlang, Clojure, and Haskell in One Book?

interviewed by Michael Swaine

Behind the scenes with the author of Seven Languages in Seven Weeks.

In Seven Languages in Seven Weeks, Bruce Tate took on an audacious goal: to take readers on a meaningful exploration of seven languages within the pages of a single book. His plan was to dive down to what’s essential and unique about each language, and in the process maybe even uncover some insights about how to learn any new language.

Bruce wasn’t interested in just giving readers a flavor of each language, I knew. He was going to ask a lot of his readers, and intended to reward their efforts with a deep understanding of each of the languages through useful hands-on experience in coding. The project seemed so outrageous that I decided I had to talk with him about the writing of the book. I wanted to know why he took on this challenge, surely one of the hardest writing challenges this award-winning writer has ever attempted. And I wanted to ask him why he chose the languages he did, how he approached each language differently to get at its unique strengths and style, and what he himself learned from taking on this challenge.

I found what he had to say fascinating, and I hope you do, too.

ms: Chef Tate, what was your inspiration for today’s battle? (Sorry; I was channeling the Chairman from “Iron Chef” for a minute there.) Make that: what inspired you to write this book?

bt: I think it’s just an interesting time for programming language models. We’re seeing the emergence of functional concepts in object-oriented languages. Concurrent distributed programming is exploding. Twitter got some relief from their scalability problems by moving part of the application from Ruby to Scala. The cloud database CouchDB uses Erlang, which was inspired by Prolog and uses a completely different concurrency strategy. We’re doing more and more coding within the browser and we’re even seeing JavaScript creep over to the server side, which has prompted a resurgence of interest in prototype languages. But there’s no one programming language that will rule them all.

ms: Chad Fowler once said, “The best reason to learn a new programming language is to learn to think differently.” Did you also have something like that in mind?

bt: I firmly believe that we expand our minds by exposing them to different ideas. The ultimate exercise for someone learning about the world is learning new spoken languages. Learning a new programming language does very much the same thing. The whole exercise shapes the way you think, and in the very best ways. Learning Haskell will make me rely less on mutable variables, learning Erlang will increase my interest in better messaging and monitoring, and learning Prolog will open my eyes to rules-based logic constraint problem solving, a very important set of programming strategies that I never knew existed.

It’s just a great exercise. The only question to me was whether I had enough knowledge to pull it off.

ms: It is as though you chose to write seven books.

bt: I decided early on to lean hard on the community around me, and I am liking the result so far.

ms: It does seem like an ideal book for the Prags Beta book program, letting you draw on the full range of programming knowledge among the readers. How did you select the languages to cover? Didn’t you also involve the community in that part of the project?

bt: I started with a good idea about three or four languages in the book. I picked Ruby because I wanted an object-oriented language that’s easy to learn so I’d have a common basis to compare the other languages to. I then threw out a vote to my audience with the help of the Prags. (Ruby was the one on top.) I picked the top ones, with a few exceptions.

I dropped JavaScript because it was a little too popular and not really pure enough, so I looked at other prototype languages. I picked Io from Lua, Io, and Self. I’m really glad that I did. I also dropped Python because it was a second object-oriented language, and I didn’t need two. Python would have been fun, though. It’s a great language. I pulled the ninth language on the list, which was I think Prolog.

So I wound up with four different programming paradigms. Ruby is object-oriented, Prolog is logic-based, Io is a prototype language, and the last four are functional languages. I had a mix of very dynamic typing (Io, Ruby, etc.) and static typing (Scala and Haskell). I had languages spanning five decades, sort of. Clojure is a Lisp dialect, with roots in the 1950s, Prolog was created in the 1970s, Erlang’s first version was, I think, in 1986. Haskell’s 1.0 version was in the 1990s, as was Ruby. Io and Scala were both invented in this decade.

And buried in that pile are seven distinct languages with vastly different idioms and philosophies. I’m pleased with the mix, but I have to give the credit to the Prags readers who answered the polls.

ms: So you had your seven languages, and all you had to do was discover and communicate the essence of each one. What was your thought process in deciding how to approach this monumental job of introducing readers to seven very different languages? In fact, what was the process?

bt: It wasn’t easy. Languages have personalities, and I found that I needed to quickly change the mindset of a reader from one language to another. I compared each language to a pop culture movie character. Erlang is Agent Smith from The Matrix, Ruby is Mary Poppins (a spoonful of sugar). I know that sort of thing is not for every reader, but an author has to have a voice and have fun in the process of writing. And there were also two major concerns.

The biggest decisions were whether to have seven days of focused instruction or less, and how much work to do on installation and support. For the first problem, I had intended to do five days of instruction. That was wholly impractical. I found that I needed unfocused play time to let concepts jell, and I bet my readers will too.

ms: And what about support?

bt: I decided that I was not capable of supporting installation across all of the languages, and the most recent versions, on all of the platforms supported by my readers. I feel slightly guilty about that, but it was the only practical solution.

ms: OK, then what?

bt: The next decision was how deep I should dive. That’s a dance. For most chapters, I initially bit off too much. With Prolog, I tried to build a scheduler, and Joe Armstrong, creator of Erlang, talked me off of that ledge. In Clojure, I wanted to create a queuing system, but Stuart Halloway guided me in a different direction, after he finished laughing, I’m sure. And in Io, I didn’t dive deep enough for the concurrency problems. Steve DeKorte, inventor of the language, shared some examples with me.

ms: You also went to the developers of many of the languages for interviews. Personally, I find that the interviews add to my understanding of the languages, but what was your thinking in including interviews?

bt: I wanted to lend some credibility to the book that I couldn’t provide, and some insight from the designers of the various languages. I’m humbled to have people responsible for creating six of the seven languages discuss the features they like the best and the least, and give us the true inside scoop.

Of course, my biggest fear is that my novice code in these languages will stand out for the wrong reasons. I can only hope that my great support network of reviewers, editors, and sounding boards will keep some of those mistakes to a minimum.

ms: Let’s talk about the languages. What did you want the reader to take away from the Ruby chapter?

bt: The Ruby chapter was interesting for two reasons. First, there are a ton of people who know the language, and know it well. Second, few people can push Ruby through all of its paces. I tried to use Ruby as a basis for comparison for the other languages in the book. And of course, it was great to interview Matz. I was at a conference in Japan where he was the chair, and we got to talk at one of the events that the conference had planned for the speakers. I asked him to do an interview for the book then, and he agreed. We finally completed the interview over email. He’s a wise man, and he’s achieved an amazing balance as a steward of the language. I’m working on Haskell right now, but you can code a monad in Ruby. And the syntax of the language is just beautiful to me. Ruby is still my chosen language, and long after I've eventually moved on, I’ll always remember Ruby fondly.

ms: A lot of programmers today know Ruby, so I can see why you started with it. How was the experience of writing about a lesser-known language like Io?

bt: Lesser-known is right. Io is probably the least-known language in the book. I approached Jeremy Tregunna about getting rolling with Io, because it wasn’t compiling on Snow Leopard at the time. He quickly shuttled me to Steve Dekorte, Io’s inventor. We spent, I think, a Friday evening messaging back and forth until he was able to help me limp through a Snow Leopard installation. He also reviewed the Io chapter, and had some great ideas for improving it.

But the main thing I want to say about Io is that it is fun. Steve is a wise man, for such a young language designer. I’d call Io the Lisp of the prototype languages. There’s barely any syntax; the messaging model is perfect, with evaluation at the right time; the syntax and semantics are all wide open. You can do anything with it that you want. And the concurrency is right. Sometimes great languages make it and sometimes they don’t. I’m not sure that Io will make it, but it’s a special language, and learning it made me smarter.

ms: What language gave you the most trouble?

bt: That would have to be Scala, but not because it’s poorly designed. Scala probably embraces Java better than any other language in the book. I had a hard time with the strong, static typing. It didn’t feel quite right to me. But boy, could I see the power. Scala makes it easy for Java programmers to do the right thing. The actor model is a much stronger model than Java’s basic concurrency model. Also, the focus on immutability is a much-needed step in the right direction.

ms: Did Prolog give you trouble too?

bt: It did at first, for sure. I have to admit, I can’t really take the credit for including the Prolog chapter, or how well the chapter turned out. In the first writing, I missed many of the most critical concepts in Prolog. Joe Armstrong is a huge fan of Prolog, and used it to implement some of the earliest Erlang prototypes. He really took me under his wing and helped me understand the beauty of the language. I finally had what Joe calls a Prolog moment. I described the rules of a Sudoku, and out pops the solution. I had to ask myself, where’s the program?

ms: The Prolog moment. I know what you mean. The moment when you realize that coding in Prolog is all about formulating the question, and if you do that right, the answer just falls out.

bt: It was a cool moment. Since then, I’ve recalled dozens of problems that took me weeks that I could have done in Prolog in a day or less. It’s an amazing language.

ms: I have to say I share your respect for Joe Armstrong. Why did you pick him to write the foreword?

bt: He is such a rational thinker. I mean, everyone else was saying that objects would help your programs be more readable. Joe was thinking about the side effects and mutable state. Everyone else was saying that great reliability has to start with strong, static typing. Joe made Erlang dynamically typed. In an Erlang program, when bad problems happen, you just let it crash and start a new one, letting the excellent monitoring and isolation due to functional programming principles kick in. His ideas were just ahead of their time. Now, we’re realizing a lot of the ideas he’s been promoting for a very long time. When you need scalable, distributed, fault-tolerant systems, Erlang has something to teach you.

ms: You picked Clojure from all the other Lisp variants. What makes Clojure special?

bt: Three main things. First, it’s taken some of the classical Lisp lessons to heart. There are too many parentheses in Lisp, so Clojure replaces some of them syntactically with brackets and makes some others optional. Little things like that help.

Second, Clojure is on the JVM, and embraces Java classes. That’s a huge benefit. You have access to the many libraries that the Java platform provides.

Third, Clojure gets concurrency right. The STM is brilliant, really brilliant. Software Transactional Memory takes the same approach that many of the best databases use, and applies it to each memory access. You get concurrency without blocking, and that can lead to huge performance boosts, and much more reliable software systems, with very little cost.

ms: Which brings us to Haskell. Here’s the question you’ve dreaded. Can you explain monads?

bt: No, of course not. But I’m going to try.

Seriously, Haskell is so powerful and rich that it is hard to do it justice. I think the Haskell chapter is the second longest in the book, and I could easily have made it longer. Monads are the tool Haskell uses to capture some important concepts, like how to manage input/output in a language that does not support side effects. The concepts are extremely abstract. I’m still struggling with how to get that right. So the language makes some easy things hard.

But Haskell also makes some hard things very, very easy. The type system is amazing. Everything is inferred. If I had a type system like this on many of the statically typed languages that bugged me, I think I would enjoy them more.

ms: OK, that’s seven. So you took on this challenge of writing about these seven languages and now you’re nearly finished. What would you say you’ve learned in the process of writing this book?

bt: Mostly, I’ve learned that I don’t know very much at all. But the best experience of writing this book has been meeting all of the cool people. Talking to both the readers of the book and the language inventors has been an absolute blast.

ms: Well, it’s been a pleasure talking with you, Bruce. Thanks for your time.

bt: My pleasure!

Bruce Tate is a kayaker, mountain biker, and father of two from Austin, Texas. An international speaker and prolific author, Bruce’s primary focus through the years has remained steady: rapid development of web applications with small, effective teams. He is the chief architect behind several commercial websites including changingthepresent.org, classwish.org, and most recently, digthedirt.com. His books through the years have included the Jolt-winning Better, Faster, Lighter Java and the controversial Beyond Java. He is also the author of From Java to Ruby.

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

The Floating Finish Line

Programmer Education Should Be Less Fair and More True to Life

by Brian Tarbox

Life isn’t fair, information is never complete, and goals change in mid-project. So why does programmer education pretend otherwise?

An issue that many of us struggle with is the fact that some developers “get it” and some just don’t. The “it” that is or isn’t gotten varies. Some developers never really understand threading, others never grok agile, others never accept test-first development.

I’ve thought a great deal about one of these not-get-its: the inability of lots of developers to understand the notion of shifting requirements and the need to design software with that notion in mind. We’ve probably all seen developers who won’t write a line of code until the Requirements Document has been written and blessed.

Back to School

I think that a primary cause of this mindset is our university courses. If you set the Wayback Machine and remember your Programming Projects class you may see what I’m talking about. Or you can take a ride in my Wayback Machine....

At my school we developed a plan for a semester-long programming project. The entire class consisted of (1) defining the problem and then (2) implementing the solution. The notion that the problem might change midstream, as so often happens in the real world, was never even brought up. If anyone had brought it up, I think it would have been considered heresy.

In most (all?) university classes, the assignment is pretty much cast in stone once it is assigned.

I suggest a much different type of project class. In this class students are given a series of assignments but are also given the heads-up that the assignments might change at any point. I’d envision the following set of “surprises”:

an assignment is scheduled for four weeks, but three weeks into it, you demand a “customer” demo of whatever code has been written so far

halfway through the assignment you remove a significant requirement

halfway through the assignment you add a large new requirement

the assignment is clearly too large for the time allowed, and you tell students they’ll find out which parts are mandatory several weeks into the assignment

Some students might try to game the system waiting to code anything. These students would be trapped by the first surprise. Other students might build a rigid system and get trapped by the second surprise. Still other students might build a limited system and be trapped by the third surprise.

The successful student would use the knowledge that the requirements would change and would design a flexible system. These students might be pretty rare but they’re the ones I’d like to work with.

Back in the Wayback Machine again, if you please.

Moving Target

About that semester-long programming project at my school: My project was a little unusual. My team implemented the timing and scoring software for the Head of the Connecticut Crew Regatta. We had a very clear deadline: the date of the race was unmovable. On the other hand, we quickly learned that many things were going to be fluid. The number of races, the number of racers, and the order of the races was going to change until right before the race date.

We also knew that as the official scorers we needed to provide challengeable results. To that end we stored all raw result data in human-readable form. We also provided a very simple and flexible user-input system. This was put to the test during the actual race.

The regatta was going fine until the Finish Line buoy got cut. Suddenly the finish line started drifting down river! A contestant approaching the finish line shouted to the scorers on the river bank “what do we do?” We told them, “keep rowing!” and captured several alternative “finish times” for that boat. That was not a scenario that we had in any way anticipated, but the flexibility we had designed into the system accommodated this unexpected event.

So that’s my simple proposal: changing goals in student projects. I think that if more students had exposure to real-world projects—or at least projects whose requirements changed midstream—we would end up with better engineers.

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

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

The Virtues of Mockery

A mock is like a stub with attitude.

by Noel Rappin

Mock objects can be very useful in test-driven design, but they need to be used wisely.

A mock object is a testing tool that acts as a stand-in for a “real” object during testing in much the same way as an Elvis impersonator stands in for the real King. The impersonator is cheaper, easier to access, and most likely lighter weight.

Mock objects have a lot of uses in a test-driven process, including replacing unreachable external resources and speeding up tests. One of the most important uses of mock objects in a test or behavior-driven process is to help design and specify the application as you write it. In particular, mock objects can be used to define the API between different layers of your application. In this article I’ll use core Rails testing features plus the Mocha mock object gem to demonstrate how mock objects can be used as design tools.

A Brief Field Guide to Mock Objects

There are two primary types of mock objects, most commonly called stubs and mocks. Think of them as passive versus aggressive ways of specifying fake values. Stubs are passive: when you declare a stub, you specify an object, a method, and a value. In Mocha, a stub declaration might look like this:

thing.stubs(:name).and_return("Fred")

From that stub declaration forward, when the thing#name method is called, the value "Fred" is returned, and the actual declaration of the method is not touched. That’s a helpful feature if the actual method calls PayPal, or some other remote or dangerous object. (Mocha has a lot of options to augment the method and return value declarations, but for our purposes here we can ignore that complexity.)

When I describe a stub as “passive,” I mean the stub doesn’t care whether you actually use it. If I make the above declaration, but never call thing.name, nothing particularly bad happens. In contrast, a mock is more aggressive. (Yes, “mock” is used both as the name of the class of objects as a whole, and the name of one particular type. Yes, it’s confusing.) You can declare a mock in mocha with a very similar syntax:

thing.expects(:name).and_return("Fred")

When you use the expects method, the behavior of the object in the test changes. When the mock expectation is declared in a test, if the thing.name method is not called in that test, the test will fail. Unlike a stub, a mock actually does care whether it is called as part of the test—you are not just specifying a value for the method; you are making a testable assertion about the behavior of your application.

While the difference between stubs and mocks may seem subtle, it leads to significant change in the structure of your test. Since the values returned by the mock are placed there by you, they are useless in determining whether your application is achieving a desired state. Instead, the mere fact of the call to the mock becomes a test about the behavior of your application, and the correctness of the method being called is deferred to a test that actually focuses on that method. Do it correctly and you get faster tests that have a clear separation of responsibilities. You also get a better application design.

A Messy Test

One of the best places to use the mock style of testing is to keep tests from jumping between layers of the Rails stack; specifically, keeping controller tests from being dependent on the model layer. Using a non-mock style, your controller methods under test inevitably call the model layer. Here’s an example from a hypothetical program that is showing status for all members of a project.

| test "project timeline index should be sorted correctly" do
| set_current_project(:huddle)
| get :show, :id => projects(:huddle).id
| expected_keys = assigns(:reports).keys.sort.map{ |d| d.to_s(:db) }
| assert_equal(["2009-01-06", "2009-01-07"], expected_keys)
| assert_equal(
| [status_reports(:ben_tue).id, status_reports(:jerry_tue).id],
| assigns(:reports)[Date.parse("2009-01-06" )].map(&:id))
| end

If you’ve done controller testing from Rails, you are probably familiar with the basic style. The test does some setup, calls a controller action, and then makes assertions about the state of the system after the controller call.

What’s interesting for our purposes is the dependency between this controller test and the model layer. This test says nothing about the API of the model object being called, but is presumably dependent on the behavior of that model object to create the state being verified in the last lines of the test.

In a mock testing setup, that dependency between the controller and the model is flipped exactly backward. You actively want the controller test to specify that the API between the controller and model is simple and clean. Conversely—and this is the tricky part—the controller test shouldn’t actually care about the behavior of the model in order to pass.

As written, this test cannot pass without the model method written and working. In a TDD environment, that means you’re going to need to write model tests that would largely duplicate the behavior of this controller test. It’s a duplication of effort, and it increases the number of tests that will fail if the model method is broken.

Mocks to the Rescue

Let’s try the test again, this time using Mocha to define mock objects:

| test "mock show test" do
| set_current_project(:huddle)
| Project.any_instance.expects(:reports_grouped_by_day).returns(
| {Date.today => [status_reports(:aaron_tue)]})
| get :show, :id => projects(:huddle).id
| assert_not_nil assigns(:reports)
| end

At first glance, it seems as though there’s almost nothing going on in this test: it barely seems to be asserting anything other than the idea that the reports variable is assigned to... something. The trick to this test is the mock expectation on the reports_grouped_by_day method, This test validates that the controller method runs without error and calls the model method reports_grouped_by_day exactly once. The test is validating a behavior of the controller method, not the state that results from making that call.

What this test doesn’t do is attempt to validate features that are actually the purview of other tests. It doesn’t validate the response from the model method; that’s the job of the model test itself. What the view layer does with this value is the job of a view test. This test validates that a particular instance variable is set to a value using a known model method, on the theory that the job of the controller method is to produce a set of known values for use by the view. But validating the exact value of the :reports variable would be pointless (at least in this case), since the value is completely generated by the mock expectation. Validating the reports method would be testing the state of the application, but in the mock style, the state is provided by the test itself.

As promised, the mock test flips the dependencies of the standard test. The mock test doesn’t care about the return value of the model method—it doesn’t even care if the model method exists. At the same time, this test makes a statement about the model classes API and, by extension, the design and structure of your application.

Caution: Danger Ahead

One of the features of the mock controller test is that it’s isolated from the behavior of the model method. This is good, in that it makes the test more focused. But if the test passes even if the model method doesn’t exist, well, what’s to prevent us from shipping the app without the model method? Not this test, that’s for sure.

Acceptance testing, automated or otherwise, is one way to avoid this problem. You need to have some way to do an end-to-end verification of your system. Another is just to trust the process and let the existence of this mock expectation drive the creation of the model functionality in the same way that a failed test might.

When using a mock object style, it’s critically important to remember that you are designing your classes through your tests. If it seems like the test needs too many mock expectations to run, that’s a strong sign that your code needs to be refactored; often, multiple mocks are a sign there’s an abstraction that needs its own class, or a method all to itself. The more mocks in your tests, the more brittle they are against changes or refactoring in your code. Luckily, minimizing the mocks you write effectively minimizes the points of contact between parts of your application, leading to low-coupling designs that are easier to maintain and extend over time. However, the mock style of testing can be difficult to apply to a legacy system, in which poorly structured relationships between objects may already be built into the code.

Try It Yourself

If you’ve never tried a strictly mockist style of testing, you’ll probably find it a challenge at first. Just remember the guidelines for a strict mock style: everything outside the method under test should be represented by a mock; no single code error should break more than one test; and use the shape of the mocks you create to inform the structure of your application.

Take a simple coding problem, from rubyproblems.com or projecteuler.net or someplace similar. Look up the full Mocha API at mocha.rubyforge.com, and mock away.

Noel Rappin is a Senior Consultant at Obtiva. A Rails developer for five years, Noel has spoken at RailsConf and Windy City Rails, and is the author of the forthcoming Rails Test Prescriptions. A blog relating to this book can be found at www.railsrx.com.

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

When Did That Happen?

The Camera and the Photograph

by Dan Wohlbruck

Dan surveys the history of photography in a series of verbal snapshots, and Kodak appears in almost every shot.

On May 8, 1840, Alexander Wolcott received the first US patent for an American camera. Patent number 1582 was awarded for a device that would “take likenesses by means of a concave reflector.” The concave lens was a big improvement over Louis Daguerre’s and Joseph Niepce’s daguerreotype process, which created photos using a copper plate with a silver lining. Although Wolcott’s invention wasn’t the first camera, it was a major landmark in the history of photography—and he does have the distinction of opening the world’s first photography studio in March 1840.

Wolcott called his New York City studio a Daguerrean Parlor. Photographic portraits taken by Wolcott’s camera were very popular even though the pictures were only two inches square. In 1841, Wolcott sold his patent rights to Richard Beard, who opened the first studio in Europe a year later. Wolcott died in 1844, surviving his invention by a scant four years.

A year earlier, Volney Palmer opened the world’s first advertising agency, and before the year was out, he created the world’s first advertisement that used a photograph.

Color

With the exception of Daguerre, these photographic innovators’ names may be unfamiliar to you, but I guarantee that the next name won’t be. The first color photograph was produced in 1861 by the scientist who created the electromagnetic theory, Scottish physicist James Clerk Maxwell. Maxwell photographed a tartan ribbon three times using red, blue, and yellow filters before recombining the images into a single color composite.

And then George Eastman released the Kodak camera in 1888. You’ve heard that name, too, and with good reason.

For the next 85 years, the history of the camera was largely the history of Eastman and his Kodak Company. The first Kodak camera was sold with enough film for 100 exposures. The camera cost 25 dollars and the cost to develop the film was 10 dollars. The camera was sent to Kodak, where they developed the pictures, loaded a new roll of film into the camera, and returned the pictures and the camera to the customer. Eastman’s slogan was, “You press the button, we do the rest.”

Kodak introduced the one dollar Brownie Camera in February of 1900. The original Brownie Camera was only in production for about two months, but it was quickly followed by the improved Brownie 2. The Franklin Institute says this about the Brownie:

“The Kodak Brownie camera made its debut at the turn of the twentieth century and sold for one dollar. One hundred thousand of them were purchased during the first year alone. The Brownie helped to put photography into the hands of amateurs and allowed the middle class to take their own snapshots as well.... The name Brownie was chosen primarily because of the popularity of a children’s book of cartoons of the same name, and partly because the camera was initially manufactured for Eastman by Frank Brownell of Rochester, New York.”

Over the years, Kodak made the Baby Brownie, the Boy Scout Brownie, the Brownie Bullet and the Brownie Chiquita. The last Brownie, the Fiesta, was discontinued in 1970. On March 14, 1932, George Eastman committed suicide after leaving a note that read, “My work is done. Why wait?”

Digital

It was a Kodak researcher, Steven Sasson, who developed the first digital camera in 1975. The Associated Press described it as weighing eight pounds and looking like a toaster. Texas Instruments had designed a filmless but analog-based electronic camera in 1972 but Sasson relied on a new chip called a CCD (charge-coupled device) developed by Fairchild in 1973. A CCD is an image sensor that converts light into the electrons that make photography digital. Unfortunately, it would take the Kodak Company more than 25 years to release a digital camera commercially.

The reason for the delay was economic, not technical—the primary source of Kodak’s profit was film.

Although there seems to be some argument, it is generally accepted that the first digital camera for the consumer market was the Apple QuickTake 100, released in 1994. The QuickTake connected to the Mac by way of the serial port. It was Kodak—who else?—that made the QuickTake 100 for Apple.

From Wolcott’s 2x2 portraits to Apple’s 2x2 digital thumbnails took about one hundred and fifty years. It all started in May 1840—and that’s when it happened.

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

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

The Quiz

Headline Obfuscation

by Michael Swaine

American headline writers take the prize for writing cryptic phrases. No spy, programmer, or politician can match them. Why American specifically? Because they are aided in their campaign of obfuscation by the polymorphic overloading of English words.

Just about any English word can be coerced into a part of speech its mother never intended. You can pretty up your sentences with adjectives turned into verbs, make a funny by turning an adjective into a noun, accept our invite to make a noun of a verb, or turn it around and verb a noun. Turn an exclamation into a verb and you’ll surely wow them, and if you’re willing to jiggle gender as well, you can him a her, in the process turning a pronoun into a verb. You can knob it all the way up to ludicrous.

Now add to this confusion the not-helpful practice of leaving out most of the articles and other short words in your writing, and you have a fair description of what headline writers do routinely:

Promulgate obfuscation.

The headlines at the head of this issue’s quiz, however, are fake. We designed them just for this quiz, and we designed them carefully. Hidden in these four headlines are several things that should be meaningful to any software developer.

Can you find the hidden meaning in the four cryptic headlines?

Because we’re sure it won’t help you, we’ll tell you that we used Wolfram Alpha to construct this quiz.

Solution to Last Issue’s Quiz

Don Knuth graduated in 1960 from Case Institute of Technology, and currently has no email address. Mitch Kapor graduated in 1971 from Yale, and was a radio DJ. Charles Simonyi graduated in 1972 from UC Berkeley, and is a space tourist. John Backus graduated in 1949 from Columbia, and had a metal plate of his own design in his head. Tim Paterson graduated in 1978 from University of Washington, and drives a Porsche.

No one could be expected to know this, but the title of that quiz, “The Mystery of the Five Programmers,” was my recycling of a title I used once before. It was the title of my first published puzzle, a logic puzzle in the form of a mystery story, published on the back page of InfoWorld in 1981. It kicked off a series of such puzzle stories that featured the puzzle detective Mr. Usasi and appeared weekly for a couple of years.

Calendar

Author sightings, partner events, and other notable happenings.

Author Appearances

May 2–7, Albuquerque, NM

Problem Solving Leadership (public workshop with Esther Derby)

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

May 10–11, Agila Sverige 2010, Stockholm, Sweden

“Timboxed Thinking”

Staffan Nöteberg, the author of Pomodoro Technique Illustrated

May 11–14, Chicago, IL

“Pragmatic Studio iPhone Programming”

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

May 11–14, Obtiva's Ruby on Rails TDD Boot Camp, Chicago, IL

Teaching

Noel Rappin, the author of Rails Test Prescriptions

May 12–14, GeeCON 2010, Poznan, Poland

“Pomodoro Technique”

Staffan Nöteberg, the author of Pomodoro Technique Illustrated

May 12–14, Reston, VA

Clojure Programming Studio

Stuart Halloway, the author of Programming Clojure and Rails for Java Developers

May 14–15, Open Agile conference, Bucharest, Romania

“Coaching Agile Teams”

Rachel Davies, author of Agile Coaching

May 16–19, Software Practice Advancement 2010, London

“Customizable UIs with Naked Objects”

Dan Haywood, the author of Domain-Driven Design Using Naked Objects

May 18, Software Practice Advancement 2010, London

“Retrospectives Refactored”

Rachel Davies, author of Agile Coaching

May 18–21, Tek X, Chicago, IL

“Getting Git” and “Real-Time Applications with XMPP”

Travis Swicegood, author of Pragmatic Version Control Using Git

May 18–21, TEK-X PHP Conference, Chicago

“SQL Injection Myths and Fallacies” and “Models for Hierarchical Data with SQL and PHP”

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

May 23, Gateway Software Symposium, St. Louis, Missouri

“Grails Deep Dive” and “Grails Takes Care of the REST”

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

May 26–28, Helsinki, Finland

“Secrets of Agile Teamwork”

Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

May 31–June 1, Agile France

Keynote: “Self-help for Self-organizing Teams” and workshop: “Lifting the Veil: How Visible and Invisible Structures Drive Organizational Behavior”

Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

June 1–2, DevSum 2010, Stockholm, Sweden

“Pomodoro Technique”

Staffan Nöteberg, the author of Pomodoro Technique Illustrated

June 1–4, XP2010, Trondheim, Norway

Workshop: “Trust and Culture”

Rachel Davies, author of Agile Coaching

June 1–4, Open Source Bridge

“Give a Great Tech Talk” (with Josh Berkus)

Ian Dees, author of Scripted Gui Testing with Ruby

June 6–11, Better Software Conference/Agile Development Practices, Las Vegas, NV

“It’s the People, It’s Always the People”

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

June 7–10, RailsConf, Baltimore, MD

“System Testing Rails Itself”

Sam Ruby, author of Agile Web Development with Rails, Fourth Edition

June 7–10, RailsConf, Baltimore, MD

“Acceptance Testing with Cucumber”

David Chelimsky, author of The RSpec Book

June 7–11, Better Software/Agile Development Practices

Keynote: “From Big Boss to Servant Leader,” tutorial: “Agile Retrospectives,” talk: “Card, Conversation, Confirmation: Interviewing Skills for Agile Requirements,” and talk: “The Art of Giving and Receiving Feedback ”

Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

June 7–11, Better Software Conference

Keynote and workshops

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

June 8, UniForum, Chicago

“What’s New in Perl 5.10 and 5.12”

Andy Lester, the author of Land the Tech Job You Love

June 8, Embedded Systems Conference, Chicago, IL

“Testing Embedded User Interfaces”

Ian Dees, the author of Scripted GUI Testing With Ruby

June 8, Sacramento Java User Group

“Grails Integration Strategies”

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

June 14–17, UberConf

“The New Work of Management in Agile Organizations” and “Working with Complex Adaptive (Human) Systems”

Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

June 14–17, UberConf, Denver, CO

“Test Driven Development in Java: Live and Uncensored,” “Continuous Testing on the JVM,” and “Iteration-less, Value-Based Planning”

Ben Rady

June 14–17, UberConf, Denver, CO

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

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

June 14–17, UberConf, Denver, CO

“Clojure,” “Introduction to Functional Programming with Clojure,” and “The Best of OO: Clojure Types and Protocols”

Stuart Halloway, the author of Programming Clojure and Rails for Java Developers

June 14–17, UberConf, Denver, CO

“Transforming to Groovy,” “Scala for Java Programmers,” “How to Approach Refactoring,” and “TDD Regular Code/Multithreaded Code!”

Venkat Subramaniam, the author of Practices of an Agile Developer, Programming Groovy, and Programming Scala

June 14–17, UberConf, Denver, CO

Talks and a workshop

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

June 20–22, OGF29 Cloud Interoperability

“Demo of DataCloud interoperability”

Krishna Sankar, author of the forthcoming Building Clouds with Amazon Web Services

June 22–24, Portland, OR

“Secrets of Agile Teamwork”

Esther Derby, author of Behind Closed Doors: Secrets of Great Management; Agile Retrospectives: Making Good Teams Great

June 23, DevDay for iPhone, Geneva

talk: “Core Animation” and tutorial: “Programming the iPad”

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

June 25, DevDay for iPhone, London

talk: “Core Animation” and tutorial: “Programming the iPad”

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

July 9–10, Agile Coaches Gathering, Bletchley Park, UK

“Facilitating Open Space”

Rachel Davies, author of Agile Coaching

July 16–17, Ruby Midwest, Kansas City, MO

“Pragmatic Guide to Git”

Travis Swicegood, author of Pragmatic Version Control Using Git

July 19–23, OSCON

“Building a NoSQL Data Cloud”

Krishna Sankar, author of the forthcoming Building Clouds with Amazon Web Services

USENIX Events

June 23–24, USENIX Federated Conferences Week, Boston, MA

WebApps ’10 is a new technical conference filled with the latest research in all aspects of developing and deploying Web applications. The diverse 2-day conference program will include invited talks by industry leaders including Adam de Boor, Google, on “Gmail: Past, Present, and Future,” a variety of topics and new techniques in the paper presentations, WiPs, and a poster session. Since WebApps ’10 is part of USENIX Federated Conferences Week, you’ll also have increased opportunities for interaction and synergy across multiple disciplines. Register by June 1 and save up to $400! Additional discounts are available.

O’Reilly Events

May 25–27, Washington Convention Center, Washington, DC

Gov 2.0 Expo: “Gov 2.0 Expo will showcase the real-world application of Web 2.0 technologies in government and municipal sectors, featuring a practical program that will teach government employees and contractors how to apply technology best practices to foster greater transparency, efﬁ ciency, and collaboration.”

June 7–10, Baltimore, MD

RailsConf is the largest official event for the Ruby on Rails community. If you’re passionate about Rails and what it helps you achieve—or are curious about how Rails can help you create web applications better and faster—RailsConf is the place to be.

June 22–24, Santa Clara, CA

O’Reilly’s Velocity Web Performance and Operations Conference gives attendees access to speakers and the in-depth, technical content that will move the dial furthest for Web Ops and Development professionals most responsible for the health of their company’s IT infrastructure.

July 19–23, Portland, OR

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

Other Happenings

May 6–7, Oklahoma City, OK

Red Dirt Ruby Conference

May 17

Alan Kay is 70.

May 19

James Gosling is 55.

May 19–20, San Francisco, CA

Google I/O

May 26

Ward Cunningham is 61.

June 8

Tim Berners-Lee is 55.

June 23

Vint Cerf is 67.

June 30

Lynne Jolitz is 49.

July 9

Marc Andreessen is 39.

July 16

Dan Bricklin is 59.

Shady Illuminations

Notes Toward an Unauthorized Biography of Larry Ellison

by John Shade

Larry Ellison owns Sun. That may be good, it may be bad, but it will definitely be interesting.

Bill Gates must be the most boring billionaire in the world. With the most annoying voice. And what’s even more annoying, he wasn’t born boring. He used to crash computers deliberately and go joy-riding in his Porsche or in stolen earth-moving equipment. But somewhere along the way, it seems like noblesse oblige overcame him—I’m guessing it was around his 22nd birthday—and he’s been boring ever since. Fortunately, some billionaires understand that when you have so much money that you can do anything, you have an obligation to do just that. You can not be boring.

Larry Ellison is never boring. While Bill Gates appeared in a Microsoft commercial with Jerry Seinfeld—and that’s post-Seinfeld Seinfeld—Larry Ellison had a cameo in Iron Man II playing himself. He could be that guy Carly Simon wrote about.

You’re So Vain

Larry has a drained swimming pool in the back yard of his Woodside, California, home that he uses as a sub-woofer for his stadium-scale home entertainment center.

He races yachts. He races cars. He flies jets. He performs nose-bleed-inducing low-altitude aerobatics in his Soviet-era MiG-29 fighter jet.

He owns almost as many houses as John McCain. He’s trying to find a cure for aging, although not specifically for John McCain.

He’s the one and only Larry. Really. Oracle employees say that nobody else in the company can be called Larry. If that’s your name, you have to become a Lawrence, or a Daphne, or whatever. Oracle can have only one Larry.

Why Can’t Gaza Be More Like Woodside?

But I have to say, it gives me hope for peace in the Middle East when I observe a Muslim and a Jew being such close friends. Steve Jobs even acted as the official photographer at his best bud Larry Ellison’s wedding. And Larry was the ring-bearer at Steve’s coronation in The Return of the King.

I realize that Steve and Larry both seem to think that they’re Buddhists, but I say that’s an affectation. I don’t believe they’re real Buddhists, like Richard Gere. Steve’s birth father was Syrian and Larry’s birth mother was Jewish, so I say they’re a Muslim and a Jew and I’m sticking with that until I see their papers.

I guess it’s not surprising that Steve and Larry should be pals. When you’re a born-out-of-wedlock faux-Buddhist billionaire computer industry founder/CEO, you naturally gravitate toward other born-out-of-wedlock faux-Buddhist billionaire computer industry founder/CEOs in the neighborhood.

Embrace Your Inner Pyromaniac

Apparently space has a smell. Astronauts report that articles that have been in space, when returned to atmosphere, have a distinct smell. They smell like gunpowder. If napalm is the smell of victory, gunpowder is the smell of space. Which can’t help but please Larry.

“I’m not a guy who just blows stuff up in the desert,” Mike Workman told Forbes Life magazine. “This really is an art. The sky is a canvas, and you get to paint.” Workman heads Pillar Data Systems, a company that Larry Ellison’s venture capital firm funded, but data processing is not the only thing the two have in common. “When Larry Ellison found out about my fireworks habit,” Workman said, “he was thrilled.”

Well, why wouldn’t he be? Larry’s into pranks. “It was an adolescent prank,” he said in another context, “I highly recommend it.”

Culture Clash Wedding

Which makes me think that the culture clash with the Sun managers might not be that bad. Sun has historically had a culture of high-concept pranks. And of course “the network is the computer,” at least sounds like support for the Network Computer.

Satori with the engineering staff might be harder to achieve.

While Larry might be confident about the future of Solaris, he’s not sharing his plans, and that makes people nervous. The OpenSolaris developers don’t trust Oracle and are on the verge of forking the code base. The MySQL community isn’t buying Oracle’s assurances and anticipates changes that they arent’t going to like. Java developers aren’t in active revolt, but Elvis has left the arena. And the once-free-wheeling Sun employee blogs have been shut down.

I don’t even want to ask what’s going on with ZFS.

Vertigo Integration

So why did Larry want to buy Sun, anyway?

Vertical integration, we’re told. Sun’s server and storage technology plus Java combined with Oracle’s database software, middleware, and applications, let Oracle place its hand much deeper in the customer’s pocket. Larry wants to pack up everything you need to sell gold coins and bars or splice genes or cap oil spills, whatever your business is, in something called an “industry in a box.”

All he wants is everything: the Whole Enchilada, total control of the entire profit pump in an end-to-end, top-to-bottom, soup-to-nuts, cradle-to-grave strategy so vertically integrated it makes your head swim and your nose bleed. The model for this, of course, is the shiny 21st Century Apple. Whose model is in turn stodgy nobody-ever-got-fired-for-recommending-it mid-20th Century IBM.

Vertical integration? Really? Color me skeptical, but don’t trust my opinion. I’m probably wrong. It’s just that Larry’s high-flown ambition leaves me a little dizzy, wondering if I’m not catching just a whiff of gunpowder.

Who Do You Think You Are, Larry Ellison?

But this stratospheric vision could work. Larry Ellison generally gets whatever he wants. He got the America’s Cup. He got his own rules for flying out of the San Jose Airport. He got the biggest yacht in the world. He got Steve Jobs as his wedding photographer. He got Pepper Potts to say to Tony Stark, “Who do you think you are, Larry Ellison?”

Oh, so now James Gosling quits on him? I’m sure he’ll just get a new James Gosling. You know, like Stark got a new James “Rhodey” Rhodes. Snap his fingers and suddenly Don Cheadle is the new Father of Java. The real father. James Gosling was just its birth father.

Larry Ellison is his own paradigm. He’s lean and agile, yet proven to scale. Even when he’s wrong (the Network Computer), he can stubbornly keep flogging the bad idea until the world changes and it becomes a good idea. His ego, a thing of legend, is probably by now too big to fail. As I said, he’s never boring.

At least that’s how it looks from my barstool tonight.

John Shade was born in Montreux, Switzerland on a cloudy day in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He approves of the negativity of NoSQL and wishes readers to know that if they find any errors in this article, they are #nickcleggsfault.

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