PragPub 2012-02: Issue #32

Table of Contents

Features

Interfaces of Change

by Mike Riley

Computers are developing new ways of interacting with the world, and you need to master these new paradigms.

Ten Tips for Agile Leaders

by Jonathan Rasmusson

Even if you’re not the leader in name, if you’re trying to be agile, you should read these tips.

Ten Sales Tips for Freelancers

by John Bresnik

You’re not a salesperson, but if you have ever had to deal with a client, you should read these tips.

Scala for the Intrigued

by Venkat Subramaniam

In this sixth installment of his series on Scala, Venkat shows how to create your own higher-order functions.

When Did That Happen?

by Dan Wohlbruck

Dan describes the contributions of Grace Hopper.

Departments

Up Front

by Michael Swaine

Change is coming. In fact, it’s already here.

Choice Bits

Drinking from the Twitter firehose.

Meet the Team

Meet Jackie Carter, development editor and opera buff.

The Quiz

A monthly diversion at least peripherally related to programming.

Calendar

Author sightings, upcoming conferences, and other events of note.

Shady Illuminations

by John Shade

John reflects on the Ultrabook hype and thinks he sees ulterior motives.

But Wait, There’s More...

Coming attractions and where to go from here.

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

Embracing Change

by Michael Swaine

Change Is Coming

Actually, it’s already here.

Change is inherent in the career you’ve chosen. If you’re a software developer, you have little choice but to embrace change. You’re in the business of making change. Not like the guy in the toll booth on the Bay Bridge, but—oh, you know what I mean.

Chances are you have already had several jobs in software development. If you haven’t, you will. Moreover, you’ll probably have several kinds of jobs. It’s common in this field to move freely from small startup to corporate megalith, from team member to team leader, and back again.

What this means is that you spend a lot of your time learning, feeling like a newbie in an unfamiliar situation. Two authors this month offer advice that may help.

Maybe you never thought of yourself as a salesperson, but now you realize that you need to sell yourself or your project, and you could use some tips. John Bresnik has your back.

Or maybe you never asked to lead a team, but this agile project needs some direction and you see clearly what should be done, but could use some tips on team leadership. Jonathan Rasmusson has your back.

But even if you feel secure in your niche, you should be aware that the niche is changing around you. Mike Riley invites you to step back and think about the implications of some of the new ways that computers are interfacing with the world, and what they mean for your work.

Dave and Andy advised in The Pragmatic Programmer that you learn a new language every year. If Scala isn’t checked off your list, Venkat Subramaniam’s article in this issue could be a good place to start that change.

Of course, the more things change, the more they stay the same, and Dan Wohlbruck demonstrates that again with another technology history article, this one dealing with Grace Hopper.

For more advice on keeping up with change in your career, check out the the Pragmatic Bookshelf books on Career Development.

Choice Bits

Thoughts on Change and Self

Plumbing the depths of the twitterstream and keeping our feet dry.

What’s Hot

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

1^ | 4 | Agile Web Development with Rails
2^ | NEW | Deploying Rails
3 | 3 | Lean from the Trenches
4^ | NEW | Web Development Recipes
5^ | 6 | The Cucumber Book
6v | 1 | iOS SDK Development
7v | 5 | Mac Kung Fu
8v | 2 | Seven Databases in Seven Weeks
9v | 7 | Programming Ruby 1.9
10 | 10 | The RSpec Book
11v | 9 | Rails Recipes

Changes

Change is inevitable—except from a vending machine.

Make sure your daughters know how to change a tire. — @SaintBoogie

[The new year is] the best time to change all your passwords. gizmo.do/ymyVWI — @TweetSmarter

Mixed jihadi metaphor: “All regimes are standing in a vacuum and on the edge of a collapsing cliff closer to experiencing winds of change.” — @DaveedGR

“When you’re finished changing, you’re finished.”—Ben Franklin — @WarrenWhitlock

“A small group of thoughtful people could change the world. Indeed, it’s the only thing that ever has.”—Margaret Mead — @Epic_Women

Ingesting small doses of ink over an extended period of time will change your eye color slightly. — @WhatTheFFacts

@tomwaits ...Small change is still getting rained on!! Keep it coming Tom!! badasme.com/news/ — @mikehallart

It’s hard to watch people change.... especially when they have the blinds closed. — @MrJChrist

@ClimateCentral features @NASA’s breathtaking video showing over a century of climate change in 26 seconds. ow.ly/8Heq0 — @ClimateReality

#cc12 Sec Donovan: “Change is a returning sailor sharing a first kiss with her girlfriend.” — @GLADLaw

You cannot change the past unless you have a DeLorean. — @ChorePush

It looks like I’ll be going to RSA this year. It’s been years. — @kevinmitnick

Good to Know

An excuse to use my favorite Angelina Jolie quote (NSFW).

Rational beliefs behave well under tensor products. ow.ly/7yZ6r — @ProbFact

Before picking up the litter box to clean it, make sure there isn’t a cat in it. — @spiderwebwoman

According to #Benford’s law, the #probability P that a number in lists of numbers starts with digit D is P=log(1 + 1/D) — @giancarlodurso

Why Twinkies are cheaper than carrots. youtube.com/watch?v=p9cSPe… — @RichLouv

Snedecor’s F distribution is usually just called the F distribution, though “F” is hard to search on by itself. — @ProbFact

Self-identification

If you don’t google yourself regularly, how do you know who you are?

Geek vs. Nerd: The Infographic geeksaresexy.net/2012/01/04/gee… <- I’m def a geek although I like the “nerd” movies more. — @sarahcuda

Google.com/history says the first 3 words I looked up definitions of this Winter were: Fungible, arrears, & veltschmertz. Hat tip @karlastarr — @marshallk

You might be a probabilist if you notice you say “given” (as in conditional probability) often in ordinary conversation. — @ProbFact

Who Are Those Guys?

Well, Kevin Mitnik is this guy. And as for the rest, they’re not all guys. Also, we have to confess that we cleaned up their punctuation and stuff a little. OK, who they are: Chore Push, Jesus Christ, Climate Reality, Giancarlo D'Urso, Epic Women, D. Gartenstein-Ross, GLAD, Mike Hall, Marshall Kirkpatrick, Sarah Lacy, Richard Louv, Kevin Mitnick, Probability Fact, Tai SaintBoogie, spiderwebwoman, TweetSmarter, What The F Facts, and Warren Whitlock. You can follow us at www.twitter.com/pragpub.

“I put a dollar in one of those change machines. Nothing changed.”—George Carlin.

Meet the Team

Development Editor Jackie Carter

Each month we profile a member of the Pragmatic Bookshelf team. This month it’s development editor Jackie Carter. Here’s Jackie’s story, in her own words.

Jackie Carter, Development Editor

“For much of my working life, I’ve been a developer, a DBA, a consultant. Sometimes clients would ask for something that meant I had to learn a new language or technology, so I’d go to the bookstore. After roaming through the aisles, I’d settle on a book I thought I could use and take it home. Often, while reading it, I’d run into confusing organization, incomplete examples, and things that just didn’t work. I’d think ‘If only I could talk to the author, we could make this a good book!’

“Well, now I can.

“After the dotcom crash, I decided I wanted to do something else and I was looking around. I stumbled into editing through a series of coincidences and I found I really enjoyed working with authors to develop their ideas into books. After a few years, I heard about the Pragmatic Bookshelf. I was immediately intrigued—it sounded like the perfect place for me. I contacted Andy and Dave and soon I was working for them. We’ve got a great team here and it’s very gratifying to be able to work with them and the authors to create good books.

“When I’m not working, I like to spend my time exploring the Northern California coast (and whale-watching at certain times of the year), gardening, and of course, reading.

“And then there’s music. When I was consulting, the most interesting client I had was the San Francisco Opera. I’ve always loved music, and I’ve played classical piano and flute, but I didn’t think I liked opera. Over the years, listening to the glorious music that was piped into the computer room during afternoon rehearsals and watching performances, I grew to love opera and I really missed it when I left. I don’t go to as many operas these days since it’s a bit of a trek, but it’s still my favorite performing art. I love the way it synergistically combines the story, orchestra, chorus, ballet, and of course the wonderful arias in one production.”

Email: jackie@pragprog.com

Interfaces of Change

Don’t Be Blindsided by the Future

by Mike Riley

Mike Riley takes a look at some exciting new paradigms of interaction. Don’t misinterpret Mike’s enthusiasm. He’s not cheerleading. He just wants you to realize how radically these paradigms could change your work and life.

There is a groundswell of change happening today in the world of client computing. Just as the mouse forever changed the way people interacted with graphic user interfaces, new models for interaction are disrupting the way programmers will develop for and test their applications. Let’s take a brief look at these new-world interface paradigms, and consider how they are changing the face of computing for the masses—and begin to think about what they could mean to you as a developer.

See Me

Visual input, usually referred to as Computer Vision or CV for short, has been in development for years. But now that processors are fast enough to interpret the huge stream of incoming visual data, the technology implied by Hal’s eye in 2001: A Space Odyssey is now a reality.

Game consoles like the Playstation 3 or the XBox 360 have motion cameras with APIs designed to capture and interpret gross-level gestures. While these recent attempts are still crude in their motion detection and tracking algorithms, improvement is accelerating at a faster pace thanks to the market acceptance and fascination with synthetic eyes connected to a computer brain.

With Microsoft’s formal release of Kinect for Windows and their further refinement of motion tracking and gesture interpretation, this modality of user-computer interaction will continue to evolve at a much faster pace than it has in the past. It isn’t inconceivable that such sensors will be embedded into tablets one day, perhaps sooner rather than later. Imagine the tracking optics on the face of a tablet watching a presenter for gestures to advance slides in a presentation, trigger video playback events, or move graphic primitives on screen without the need to physically touch the screen.

From a developer’s perspective, we’re talking about a radical change here. Developing interfaces for such a disembodied experience is far different from using a mouse or finger to click on a graphic. Yet as more and more of these interactive means are used in everyday applications, you will be expected to know how to develop, autonomously test, and debug this computer’s eye-CPU connection.

Two good references for further research in this area are Gestures and Tools for Kinect and How to Do Gesture Recognition With Kinect Using Hidden Markov Models (HMMs) by Jonathan C. Hall.

Hear Me

Think voice input today and you probably think of Siri. Apple made a big splash in the voice input space with their Siri beta on the iPhone 4S. Even though Google had text-to-speech results on the Android platform prior to the Siri introduction, it was not as prominently featured or sexy as Siri. Google’s implementation also suffered from a grating, raspy TTS engine that sounds uncomfortable and unnatural. Compare this to the TTS engine used by Apple with its more human-sounding tone, inflections, and even breathing cadence patterns, and it’s no surprise that Apple’s cloud-based Siri application has been embraced by early adopters.

In sober fact, when someone combines the current state of the art in computer vision seamlessly with voice recognition and current remarkably human-like TTS, HAL9000 will have arrived. Perhaps someone at the University of Illinois is currently working on such as system as I write this, and teaching that system how to sing a song.

But let’s look at a more practical implication: What does such a system mean for search? If Google has become Apple’s new Microsoft, Siri must be seen as a Google search replacement on iOS devices.

And Apple actually has a jump on the competition, because it is amassing a huge refined database of vocalized queries from around the world. This Siri-aggregated global inference engine they are building could be a way to make Google’s interface (and all their AdWords advertisements) irrelevant. Basically, there is a new, conversational way to ask a computer for information. Combined with agents and preferences, this dynamic level of interaction will eventually offer to be a driving companion, a running coach, a social assistant—and a pair programming mentor.

Let’s look more closely at what’s already happening in one of those areas: the driving companion. Automobile maker Ford has been running commercials showing non-technical consumers boasting about how they can talk to their car and “it talks back!” Having set the industry standard expectation for voice-activated in-car services, Ford’s SYNC system, based on Microsoft’s Windows CE OS, is motivating other automobile manufacturers to at least be at parity with Ford’s system. Some of these competitors are Android-based while others are a mishmash of proprietary embedded systems. Still others assume that the car owner will be an iPhone user and thus will hook into whatever services are available to the iPhone via an app. Once Apple releases a Siri API to developers, these iOS-friendly auto makers will undoubtedly create and provide voice-enabled apps for their appropriate line of cars.

It’s easy to imagine that when a customer buys a Gran Turismo from BMW, there could be an adhesive QR code label on the car’s steering wheel that takes the customer to the appropriate Apple App Store or Android Market location to download and install the custom app for that car. After entering a series of security codes to pair the phone’s app via Bluetooth with the car’s on-board hardware, drivers will be able to interact with a respectable “eyes-on-the-road” experience while asking for directions; being informed about the car’s fuel, charge, or temperature conditions; scheduling a car maintenance appointment with a local certified service center; and who knows what else.

Here are two good references on voice input: Android: How to implement voice recognition, a nice easy tutorial, and Ford SYNC Applink Mobile App Developer Network.

Touch Me

Apple (yeah, I know, them again) changed the computing world with the commercialization of the computer mouse, and they have done it again 30 years later with the multitouch interface. Just as the mouse proved to be the catalyst of the personal computing revolution, the multitouch interface is the catalyst of the mobile computing revolution. Tablets, phones, interactive whiteboards, multi-point touch pads and displays are all growing examples of this new world. Instead of the PC’s disembodied mouse-screen connection, touch interfaces provide immediate spatial feedback, which explains why people from 8 months to 80 years can usually interact with touch computing interfaces with little or no training.

And we’re just starting to see what can be done with multi-touch. Things get more interesting when more than just one digit is involved. Multi-touch is where people’s eyebrows raise in surprise and—if the interface is designed correctly—delight. More sophisticated touch capabilities, exceeding support for four simultaneous touch points, bring a whole new dimension to graphic manipulation, input, and acknowledgement.

Current iOS and Android devices have only just begun to utilize the full potential of what touch has to offer. Add a third dimension, depth, to the touch experience, and you get the ability to quickly flip through screens, but even more—to navigate through complex molecular assemblies, rapidly sort through a virtual stack of documents, or video-capture a three-dimensional world for playback manipulation that would make the VR gloves in science fiction movies look downright primitive.

Three good web references for multitouch are Multi-touch GIS API for TableTops (click on “Learn about the design of the API”), Python Multitouch Toolkit, and Gesture Toolkit.

Heal Me

Each one of these interfaces has the opportunity to forever change the way we use and develop applications for computing devices in the near future, and they all deserve your attention. Think about what’s involved in abstracting your own rich client applications to an MVC design to take advantage of these technologies by mapping inputs and outputs to the optimal interface of choice.

I know, we haven’t completely mastered testing on our traditional two-dimensional X/Y coordinate GUIs, let alone the complexity that voice and gesture interaction entail. But the future is ready for you to hack, and any one of these interface choices holds great potential for the ones who best master developing for them.

Mike Riley is the author of Programming Your Home, published by Pragmatic Bookshelf.

Illustration created by Marielle Riley with MyPaint running on Ubuntu Oneiric Ocelot.

Like this article? Hate it? Send the author your feedback or discuss the article in the magazine forum.

Ten Tips for Agile Leaders

A Framework for Leading Agile Projects

by Jonathan Rasmusson

Even if you’re not the leader in name, if you’re trying to be agile, you should read these tips.

Leadership is one of those personal things I find hard to give advice on. As if there were merely 10 things you needed to do to successfully lead your agile team. I feel no more qualified to tell you how to lead your software project than I do telling Wayne Gretzky how to play hockey.

Having said that, there are things there are things really I’ve seen good team leads do that enable them to:

make the delivery of ‘bad news’ a non-event,

tell very early whether their project is going to ‘make it,’

create and maintain a culture of excellence from day one on the project,

and make coming in to a work a joy while being able to sleep at night not worrying about the craziness of tomorrow.

Not everything on this list is going to work for you. Like I said, leadership is personal and everyone has got their own style and way.

But if you are looking for a starting point on how to lead your agile team, you could do a lot worse than starting with these.

Ask the Tough Questions Early

Go Spartan

Make the Truth Self-evident

Set the Bar High Early and Keep It There

Deliver Fiercely

Make Yourself Obsolete

Make the Team Accountable

Cheerlead

Give Up Control

Accept Three Simple Truths

Let me expand on each of these points a little.

1. Ask the Tough Questions Early

Working Down Under, I had the opportunity to ride shotgun with one of ThoughtWorks’ top salespeople—a gentleman by the name of Keith Dodds. One of the many things Keith taught me was the importance of asking the tough questions at the start of any new engagement or sale.

How much experience does your team have?

Have you ever built a search engine before?

Do you foresee any problems with two analysts and thirty developers?

At the beginning of your project you want to do the same thing. You want to get all the skeletons out of the closet and into the open. What’s the single most important thing this project needs to do? Anything keeping you up at night? Everyone clear on what success looks like?

It’s about alignment and making sure you’ve got the right people on the bus, and everyone understands the direction we’re headed.

My favorite tool for doing this is the inception deck, a lightweight project chartering tool consisting of ten questions you’d be crazy not to ask before starting any agile project.

However you do it, call out any craziness and deal with it before the project begins.

2. Go Spartan

This is one of the best strategies I know for setting expectations around dates, and determining whether you’ve got schedule risk with your project.

The premise is pretty simple. When you start delivery, build the simplest, most spartan, stripped-down, bare-bones version of the system you can. Build a couple of critical end-to-end stories and see how long that takes.

Why? Because if after three or four iterations of this it becomes apparent the date is out of whack, delivering that message after you’ve gone spartan is way easier.

“Even going flat out, delivering the most simple stripped-down version we can, there is no way we are going to able to that date. What do you want to do?”

Going Spartan is great because it enables you to have this conversation from a place of integrity, honesty, and conviction. Something has to give. No drama. No need to get crazy. Just a case of too much to do and not enough time. In other words, the state of any interesting project.

By doing this, you are also making the truth self-evident.

3. Make the Truth Self-evident

No one likes being the messenger of bad news. Fortunately, agile makes it easy to let the facts speak for themselves by tracking and making visible things like:

team velocity

projected delivery dates

blockers keeping the team from delivering

You don’t ever have to say: “The project is late.” It will be obvious the project is late! Everyone can see it. You’d look foolish trying to ignore or deny it. No wishful thinking required. Just acceptance.

And if you did the inception deck, you will have already had the conversation about what you were going to do when this happened. You can cut scope, push out the date, or something else. But at least you are dealing with it. No one is hiding it, or denying it, or setting someone up for failure later.

By creating a visual work space, and showing and making the true state of your project obvious to all, you won’t have to be the bad guy. You are simply showing that which is.

How management deals with this news is up to them, not you. So don’t take it personally. It’s just our duty to make sure they know early enough so they can do something about it. Which is why we like to deliver the bad news early.

4. Deliver Fiercely

Some people are afraid of spiders. Others, snakes. Those things don’t really scare me so much (snakes maybe a little). Nope. My greatest fear in life (and software projects) isn’t failing. It’s not trying.

Failing I can deal with. I fail all the time. I write blog posts that don’t resonate. I write software no one cares about. I regret how I handle certain situations and conversations.

But I try. And as long as I know I did my best, I’m good. That’s what lets me sleep at night.

Success is peace of mind attained only through self satisfaction and knowing you made the effort. Do the best of which you are capable. Don’t try and be better than someone else. Just make the effort to be the best you can. Don’t expect to make tremendous improvements each day. Make a little each day. Make each day your masterpiece. -Basketball coach John Wooden

This is what I call fierce delivery.

It’s showing up every day ready to work. It’s demoing the first version of your software two weeks into your project. It’s being a professional—even when you don’t feel like it.

Delivering fiercely does two things:

It builds trust with your client.

It makes everything easier.

When you’re busting your hump, iteration after iteration, your customer is going to notice, and they are going to like it. Trust me. There is no better way to build street credibility and trust than to simply rock up and deliver.

If they are like most customers I know in large, slow, bureaucratic organizations, they aren’t going to be used to this level of service. You are going to blow them away. Then with all that trust and goodwill you’ve built up, everything suddenly becomes easier. Your customers are going to be more forgiving on schedule. They’re going to give you the benefit of the doubt when you screw up. They are going to trust you to do the right thing and get things done.

It’s a way more fun way to work, and once you’ve earned that trust you are never going to want to lose it. It’s better than money.

Display your intent—deliver fiercely.

5. Set the Bar High Early and Keep It There

It’s way harder to correct bad behavior late, then to set good behavior early.

Take testing. If you don’t make it clear that writing automated tests is part of development for a story, some developers won’t.

Or continuous integration. If people don’t understand why it’s important to keep the build pristine, production ready, and working 100%, they’ll see no problem with checking in on top of a broken build and not getting excited when it fails.

Production readiness, quality as a team responsibility, refactoring, whatever is important to you and the team, make it explicit and set the bar high at the beginning of the project so everyone knows what the rules are going in.

6. Make Yourself Obsolete

#6. Teams work best when they can take initiative, solve their own problems, and think for themselves. They can’t and won’t do that if they are highly dependent on you.

The best-led agile teams I have seen are the ones where the leader could disappear for a week and no one’s the wiser. It’s not that the leaders aren’t valuable, or they aren’t contributing. It’s more that they do such a good job setting the project and team up for success that they aren’t needed day to day.

Put yourself in your customer’s shoes. Would you rather have a team lead who can set his or her team up for success, teach them how to take initiative, and fend for themselves if he or she stepped out? Or would you want that guy who hoards information, takes all the credit, and entrenches himself so deeply in your world that having him leave would kill your project?

I am not saying you can’t lead and be valuable. But if you want to serve your customer well while freeing yourself up to move on to bigger and better things, make yourself obsolete.

7. Make the Team Accountable

You still with me in this article? Good. Because you know what? There are a lot of people, in a lot of companies, who don’t care about software the way you and I do. I know it’s shocking, but it’s true.

Good teams don’t have a problem with accountability. They make themselves accountable. You couldn’t stop them if you tried.

Other teams, however, need a little help. That’s why, if I suspect that a team I’ve got is lacking the accountability gene, one good way to instill it is to have them personally demo their software.

How many times do you think a team will show up unprepared with:

no demo environment,

no test data,

that looks terrible,

that crashes on startup?

Once is usually enough.

When teams know they are the ones who will be giving the demo, and that they are the ones who will explain why things do or don’t work, they’ll become accountable. And if they don’t, that’s a different problem.

8. Cheerlead

When you’re delivering fiercely, and pumping stories iteration after iteration, it’s easy for the team lose sight of the great work they’ve been doing, and the difference they are making to the lives of their customers.

Remind them.

Give them boost. A sincere hug. A pat on the back, or just appreciation and acknowledgement for a job well done.

Companies don’t do this nearly enough—so sometimes you need to do this for them.

How? Call out people who do exceptional things at standups. Make your team look good in front of the customer when demoing. Remind people of how cool the technologies and tools are that we have to work with, and how lucky we are to have jobs!

Injecting life, pulling peoples’ heads above the clouds, and a box of donuts can go a long way to lightening things up and making people feel good about themselves. Which leads to better work.

9. Give Up Control

This is the hardest point on the list. It’s counterintuitive, it can be highly contextual, and yet when done right it can lead to outstanding results even with average teams.

It stems from the understanding and acceptance that everyone who works for you is a volunteer. They don’t have to be there. They could be doing something else, and if you don’t serve or lead them well, your best and brightest are going to leave.

Don’t believe me? Try holding on to great talent today.

Our industry’s best and brightest crave three things above all else: autonomy, mastery, and purpose. You take away a their autonomy and you’ve taken away a huge motivational lever.

What does giving up control mean? It means letting teams take initiative and figure things out for themselves.

Don’t have a server? Go get it.

Need some feedback from the customer? Make the call.

Pushing code live becoming a pain? Hmmm, what could we do to fix that?

That’s doesn’t mean you don’t contribute your best ideas or stop teams from going off a cliff. It just means that you understand that people are going to take way more responsibility and ownership if they solve problems themselves instead of constantly having someone (like you) tell them what to do.

Self-organization is big part of agility. It’s what enables teams to get quality stuff done fast. But it only works if teams are empowered and trusted. And that means you’ve got to loosen the reins.

10. Accept Three Simple Truths

It is impossible to gather all the requirements at the beginning of a project.

Whatever requirements you do gather are guaranteed to change.

There will always be more to do than time and money will allow.

Once you accepte these three simple truths, leading agile projects becomes a lot easier.

You don’t stress as much about schedules (we know we’re already late!) You stop trying to own problems that are outside your sphere of control. And you just accept that there is always going to be more to do than time and money allow.

You stop taking things personally.

And software is personal. You put a lot of yourself into a software project, and it’s easy to take feedback, criticism, and things like schedule pressure personally.

But accepting these simple truths frees you from all that. It allows you to see that which is clearly, and to not try and change something that can’t be changed.

Bonus point:

11. There Is No Leader

This list makes a big assumption: that there is a single leader on an agile project. That is rarely the case.

That doesn’t mean that agile projects are leaderless. There can be many leaders on agile projects, and they may all lead at different times and in different ways. You can have the strong vocal expectation setter who watches the bottom line, and makes sure the customer is getting the greatest bang for their buck. You can have the quiet, behind the scenes analyst, who doesn’t say much, but when she speaks everyone listens. Then you’ve got the developer who refuses to let any bugs into production and whose diligence and attention to detail causes everyone to raise their game.

The point I am making here is that leadership on an agile project is more about meritocracy and less about titles and roles. So don’t get stressed, if you’re the leader in title, but find others are leading in fact. Agile teams are generally flat, and leadership is something to be earned (not taken or assigned). In fact some of the best projects I have been on have had no explicit leader. Just a team, a customer, and a commitment to getting things done.

Enjoy the ride.

Leadership is one of those topics that is hard to give advice about because it’s so contextual. For every point I just made on that list, I am sure you can think of examples where it won’t work. Great leaders make it up as they go, and you are going to have to do the same on your project.

But that’s a good thing. You are going to have your own style, charm, personality, and strengths, that make you effective in your own way. Work with that. Everyone leads differently, and what worked for Walt Disney and Steve Jobs won’t work for you and me.

Take what you need from this list. Ignore the rest. And find your own voice and way.

Really, the best advice I can give is:

Follow your gut. Serve your team. And be prepared to get out of the way.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.

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

Ten Sales Tips for Freelancers

Pragmatic Sales Advice for the Freelance Developer

by John Bresnik

You’re not a salesperson, but if you have ever had to deal with a client, you should read these tips.

After ten years of doing sales in a variety of roles, from freelancer to running a small shop, I’ve made a few observations and come to a few conclusions. I’ve compiled these as a series of sales tips for the freelance developer. While they are drawn from sales experience and are geared generally toward software development, many of them are relevant to any situation where you are dealing with clients.

Show Me the Money

Keep the Cycle Going

Use Your Open Source Cred Strategically

Move First and Fast

Respond

Don’t Keep Them Waiting

Know When to Give Up

Ask a Lot of Questions

Be Conscious of Past Relationships

Know When to Fire the Client

1. Show Me the Money

It’s not rude to ask them to show you the money. It’s essential. You can put it in more polite terms, but you must try to determine what the budget is for this project. You can do this by simply asking, what is the budget for this project? and whether or not this person has the money right now. There are 3 basic scenarios to avoid:

No Money

Not Enough Money

Too Much Money

No Money: This is the case of that very nice person who may have a potentially great idea but who is expecting to find someone who will work for Sweat Equity, or the promise of great fortune someday. Unless you can pay your electric bill in shares of “The Next Google,” you’ll likely come to ruin in short order. Avoid these people. Although to their credit, they are almost universally honest about their intentions right from the start.

Not Enough Money: This is much harder to spot than No Money. Get to the point early: Do you want flat rate or hourly? If hourly, does [X currency units per hour] work? If you get a response like one that I got a few years ago—I have a guy in India that is offering ten dollars an hour; can you match that?—then there’s little doubt. I should have replied, Only if you can convince my landlord that I should be paying the same rent as they do in Mumbai, but I didn’t. Sales is fundamentally about managing your time and effort effectively. Don’t get caught up in social discord. Prospects are objects, and in your salesperson persona you need to objectify them—nothing is personal. If it’s still not clear, ask for a deposit of something simple to get the blood flowing. Not because it’s a percentage of the overall effort, but because you want to see some money.

Too Much Money: This case is generally recognizable in the form of: Yeah, we got a 200 thousand dollar budget for this otherwise tiny project that in the real world would cost about 2 thousand to implement. These people push things into the unbelievable in an attempt to get you to believe. The advice here is the age-old adage things that seem too good to be true usually are. Move on.

2. Keep the Cycle Going

Attaining a sale is a cyclical process. It’s important that you word your response in a way that solicits a further response from the prospect. Be proactive about setting up the first (or next) meeting, respond with Let’s talk tomorrow at 3 instead of Let me know if you have some free time and maybe we can chat or something. Always be setting up the next contact.

3. Use Your Open Source Cred Strategically

From a sales perspective you need to be involved in open source first and foremost to satisfy the dreaded send me some code samples request. Since you can’t legally or morally send code from another customer for whom you likely signed an NDA, make sure to have a variety of open source examples you can provide.

But beyond that, tailor your open source bragging to your audience. Most non-technical people don’t really have a clue what open source is, except that they can get it for free. So what would greatly impress your developer buddies in terms of your open source prowess will likely go right over the head of your average prospect and get them to tune out in short order. No need to overdo it.

4. Move First and Fast

As soon as you see a posting or advertisement that looks like a good prospect, move on it. I have no scientific data to support this claim, but some people just go with the first person they talk to. Be prepared with a handy file of common responses, your portfolio, and open source involvement. Never, ever, ever use form letters; they are a big turnoff and suggest you are too busy to talk to this person and you probably always will be—personalize every message with specifics about yourself and a reference to the project itself.

5. Respond

It’s critical to respond to a prospect in a reasonable amount of time. The basic rule of thumb is within 24 hours. That said, it’s better to respond right away. It suggests that you are proactive and motivated to help this person in their endeavors. Don’t worry about responding too fast: it will never come off as desperate.

6. Don’t Keep Them Waiting

It seems like an obvious thing to say, but first impressions are lasting. If you show up to your first sales meeting five minutes late, the prospect is going to get the impression that they are not the priority. It’s important in any services business to keep the communication lines open and prompt.

7. Know When to Give Up

Sales is lot like dating: as soon as you come off as desperate, it’s over. But more importantly, chasing a sale that will likely never happen is a huge waste of time and effort. A lot of people, for admirable reasons, don’t like making other people feel bad and will drag out a rejection until you give up rather than just telling you, straight out, they’re not interested. The psychological reasons why people do this isn’t important.

Giving up is seen in western culture as failure, but when it comes to sales, never giving up will lead to ruin every time. We’ve all been on both sides of liking someone who doesn’t like you and it’s never worked out in the long run.

The good news is, there’s a fairly simple protocol to follow. Regardless of specifics, when a prospect falls off the radar, send one message to the tune of just checking in. That usually wakes them up and things get back on track. People do get busy and you’re momentarily a lower priority. If they don’t respond, move on. Don’t linger, don’t get spiteful. Refocus.

8. Ask a Lot of Questions

I once worked alongside a very competent developer whose only flaw was that he estimated every task to take two weeks. Copy change? Two weeks. Build Rome? Two weeks. Don’t be that guy.

In a service business the most critical mistake is to underestimate the scope of the work. Understanding the scope of the work means asking a lot of questions. Jot down a list of basic requirements. Try to quantify the totality of what this person wants, and more importantly ask yourself do they understand what exactly they want? If not, you need to clarify it. If so, do you understand it? Once you understand it you can quantify it, and once you can quantify it, it’s possible to predict the scope of the overall effort.

9. Be Conscious of Past Relationships

Sometimes a prospect will immediately mention a bad experience in the past, say with a deadbeat developer who promised the world but never delivered much beyond excuses and delays. Be conscious of this because it may signal what will prove to be a difficult working relationship: the person won’t trust you, will want to have everything delivered before paying invoices, or worst of all, will require multiple daily status meetings. These are not the attributes of a good working relationship.

10. Know When to Fire the Client

Knowing when to fire a client is a critical part of the overall cycle of business.

For whatever reason, some clients get abusive. Don’t take it. Software development isn’t indentured servitude. A project is just a project. Here are the techniques I’ve found useful in dealing with abusive situations:

First, be direct but professional: I’m concerned about the abusive tone that things have taken lately. And leave it at that. Most of the time that cools things down, but occasionally it gets ugly again, and in that case you must go straight to the nuclear option right away. Because allowing abuse to subside momentarily and then continue will roller coaster you right into giving up programming for a nice snug white jacket with trendy clasps.

The nuclear option is simply this: Unless this stops I will have to leave the project. This should not be a bluff. Recognize that it’s entirely possible you will have to follow through on it and fire the client. In that case, remain professional, give a few weeks’ notice, and offer to be available for consultation with the next poor bastard that comes along.

Not in those exact words, of course.

John Bresnik worked as a freelancer rolling his own sales for many years before joining the illustrious Barbarian Group in 2009. He lives in New York City, has no loyalties to any language or framework and, like all developers, is actively involved in music and the grand appreciation of form follows function.

Like this article? Hate it? Send the author your feedback or discuss the article in the magazine forum.

Scala for the Intrigued

Creating Higher Order Functions

by Venkat Subramaniam

In this sixth installment of his series on the Scala programming language, Venkat shows how to create your own higher-order functions.

In the December installment of this series we discussed higher-order functions in functional programming, and in the January installment we looked at the higher-order functions in the Scala collections API. In this sixth article of this series, we’ll learn how to write our own higher-order functions.

You may recall that higher-order functions can accept other functions as parameters, can return functions, and allow you to create functions within functions. In Scala, these functions that can be passed around are called function values.

In OO programming, classes (or objects) abstract and encapsulate behavior and data. Function values also abstract and encapsulate behavior. And rather than holding on to state, they can help transform state.

Now let’s look at two examples where function values come in handy.

Continuing with the stock prices examples in this series, you’re asked to write a function that will total the prices given in a collection. You figure a simple iteration is sufficient, and you write:

val prices = List(10, 20, 15, 30, 45, 25, 82)

| def totalPrices(prices : List[Int]) = {
| prices.foldLeft(0) { (total, price) =>
| total + price
| }
| }

In the totalPrices function, the foldLeft method of the list is used to compute the total in a functional style with pure immutability. You pass a function value to the foldLeft method. This function value accepts two parameters and returns the total of these two parameters. The foldLeft method invokes the function value as many times as the number of elements in the list. The first time, total and price are bound to the value 0 (passed in as parameter to the foldLeft method) and the first element in the list, respectively. In the second call, total is bound to the total returned from the previous call to the function value and price is bound to the second element in the collection. The foldLeft function iterates this sequence of calls for the remaining elements in the collection.

Exercise your totalPrices function to see the result.

| println("Total of prices is " + totalPrices(prices))
| //Total of prices is 227

Before you could declare this done, you’re asked to write one more function, to total only prices that are greater than a given value. Clearly you could reuse most of the code from that little function you just wrote. Looking at your watch (you have those pesky meetings to attend) you say to yourself, “there’s a reason God created copy-and-paste,” and you end up with the following function.

| def totalOfPricesOverValue(prices : List[Int], value : Int) = {
| prices.foldLeft(0) { (total, price) =>
| if (price > value) total + price else total
| }
| }

Sadly, the demand for features seems to be relentless today and you’re asked for yet another function, this time to total only prices that are less than a given value. You know that copying and pasting code anymore is morally wrong, but you decide to make this work for now and refactor it to make it better right after that meeting you have to run to.

Right after the meeting, you stare at the following version of the code:

val prices = List(10, 20, 15, 30, 45, 25, 82)

| def totalPrices(prices : List[Int]) = {
| prices.foldLeft(0) { (total, price) =>
| total + price
| }
| }

| def totalOfPricesOverValue(prices : List[Int], value : Int) = {
| prices.foldLeft(0) { (total, price) =>
| if (price > value) total + price else total
| }
| }

| def totalOfPricesUnderValue(prices : List[Int], value : Int) = {
| prices.foldLeft(0) { (total, price) =>
| if (price < value) total + price else total
| }
| }

Let’s exercise it.

| println("Total of prices is " + totalPrices(prices))
| //Total of prices is 227

| println("Total of prices over 40 is " +
| totalOfPricesOverValue(prices, 40))
| //Total of prices over 40 is 127

| println("Total of prices under 40 is " +
| totalOfPricesUnderValue(prices, 40))
| //Total of prices under 40 is 100

You have good intentions to make it work and make it better, but you want to quickly refactor it to remove the duplications, before your colleagues accuse you of revealing your dark side through this code. Function values to the rescue here.

If you slightly modify the first function, to if (true) total + price, then you notice the only difference between the three function bodies is the conditional expression in the if statement. You can extract this condition as a function value.

This extracted function value would accept an Int as parameter and return a Boolean. You can express this as a mapping or transformation from Int to Boolean, or selector : Int => Boolean. Just as prices : List[Int] represents a reference prices of type List[Int], selector : Int => Boolean represents a reference selector of type function value that accepts an Int and returns a Boolean.

Now you can replace the three previous functions with one function:

| def totalSelectPrices(prices : List[Int],
| selector : Int => Boolean) = {
| prices.foldLeft(0) { (total, price) =>
| if (selector(price)) total + price else total
| }
| }

The function totalSelectPrices accepts as parameter a collection and a function value. Within the function, in the if condition, you call the function value with the price as parameter. If the selector function value returns a true, you add that price to the total; ignore the price otherwise.

Exercise the code and ensure that this version produces the same result as the three functions in the earlier version.

| println("Total of prices is " +
| totalSelectPrices(prices, { price => true }))
| //Total of prices is 227

| println("Total of prices over 40 is " +
| totalSelectPrices(prices, { price => price > 40 }))
| //Total of prices over 40 is 127

| println("Total of prices under 40 is " +
| totalSelectPrices(prices, { price => price < 40 }))
| //Total of prices under 40 is 100

You pass both the collection and the function value as parameters, within the parentheses (), to the totalSelectPrices function. You can also pass the function value outside of the parentheses; however, you have to do a bit more work for that.

It’s time to meet multiple parameter lists. We’re mostly used to single parameter lists with multiple parameters. However, in Scala you can also have multiple parameter lists, each with multiple parameters.

| def totalSelectPrices(
| prices : List[Int])(selector : Int => Boolean) = {
| prices.foldLeft(0) { (total, price) =>
| if (selector(price)) total + price else total
| }
| }

In this version of the totalSelectPrices function, rather than accepting two parameters in one parameter list, you have two parameter lists, each with one parameter. This allows you to invoke the method using the following syntax:

totalSelectPrices(prices) { price => price > 40 }

You’re attaching the function call to the end of the method call, like it is a parasite (in a good way) on the totalSelectPrices function. This syntax is a common way to pass function values to functions.

Scala allows you to pass function names in place of function values. So, if you have to pass the same function value to multiple functions, you have a few options, as shown below:

| Console println "Total of prices over 40 is " +
| totalSelectPrices(prices) { price => price > 40 }
| //Total of prices over 40 is 127

| val returnTrue = { price : Int => true }
| Console println "Total of prices is " +
| totalSelectPrices(prices)(returnTrue)
| //Total of prices is 227

def isLessThan40(price : Int) = price < 40

| Console println "Total of prices under 40 is " +
| totalSelectPrices(prices) { isLessThan40 }
| //Total of prices under 40 is 100

In the first call to totalSelectPrices you pass a just-in-time created function value. In the second call you pass returnTrue, which is an immutable reference to a function value. In the third call, you use yet another way: you pass a function as a function value. You can use either the () or the {} syntax to pass returnTrue and isLessThan40.

You saw different ways to create function values and pass them to functions. Let’s take a look at one more example of the use of function values.

Suppose you have a Resource class:

| class Resource {
| println("Creating Resource")
| def someop1() { println("someop1") }
| def someop2() { println("someop2") }
| def close() { println("cleaning-up...") }
| }

If an instance of Resource takes up significant resources outside the JVM, like database connections, open files, handles to external systems with significant memory usage, etc., you’d want to clean up the resource quickly after use. You can’t rely on the JVM’s garbage collector (GC), as you can’t predict when it would run and your memory usage within the JVM may be too low to trigger the GC reasonably soon to clean up the external resources. Users of your class may be tempted to write code like this:

| val resource = new Resource
| resource.someop1()
| resource.someop2()
| //forgot to call close

| //Creating Resource
| //someop1
| //someop2

In this case, forgetful programmers like me will omit the call to the close method. Even if they remember, a simple call to close is not sufficient. An exception before the code reaches close will prevent proper cleanup. So the right way to approach this would be:

| val resource = new Resource
| try {
| resource.someop1()
| resource.someop2()
| } finally {
| resource.close()
| }
| //Creating Resource
| //someop1
| //someop2
| //cleaning-up...

This is too verbose and taxes the forgetful programmers even more each time an instance of your Resource class is created.

(As an aside, Java 7 has a feature named Automatic Resource Management (ARM) to make this less verbose; however, it still requires the programmers to remember to do the right thing.)

If the resource has to be cleaned up quickly, why not do it for the programmers rather than expecting them to remember? You can do that using function values.

You can force (kindly) the programmer to use your class in a certain way, so they don’t have to suffer the consequences of forgetting, but instead can be guided by the compiler to do the right thing.

First, let’s make the constructor private. This will prevent the users of your class from creating an arbitrary instance. Make the close method private as well; that way they don’t have to worry about calling it, as you’ll take care of it. That leaves only the instance functions like someop1() and someop2() public.

| class Resource private {
| println("Creating Resource")
| def someop1() { println("someop1") }
| def someop2() { println("someop2") }
| private def close() { println("cleaning-up...") }
| }

With this change, calls like new Resource() will result in a compilation error. It’s time to manage the creation and cleanup of the instances of Resource.

| object Resource {
| def use[T](block : Resource => T) = {
| val resource = new Resource
| try {
| block(resource)
| } finally {
| resource.close()
| }
| }
| }

You created a companion object (see Scala for the Intrigued: Cute Classes and Pure OO in the November edition of this magazine) for the Resource class. The use method accepts a function value, called block, as a parameter and returns whatever the block returns. You specify that the block should receive an instance of Resource and may return anything, expressed as parametric type T.

Within the use method, you create an instance of Resource. Remember companion objects have full access to the companion class, so the constructor and the close method being private is not an issue from within here. Then within the safe haven of the try-finally statements, you pass the Resource instance to the function value. In the finally block, you call close to clean up the instance.

Users of your Resource can now use an instance and have it automatically cleaned up with ease, as follows:

| Resource.use { resource =>
| resource.someop1()
| resource.someop2()
| }
| //Creating Resource
| //someop1
| //someop2
| //cleaning-up

By using the function value, you’ve made it easy for the programmers to do the right thing. They don’t have to endure the consequences of forgetting to clean up; you’ve done it for them. This approach is called the loan pattern, and it also goes by the name execute around method pattern. Next time you write a method, add a little spice to your code, and see how you can benefit from function values.

Dr. Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., and an adjunct faculty at the University of Houston.

He has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia, and is a regularly invited speaker at several international conferences. Venkat helps his clients effectively apply and succeed with agile practices on their software projects.

Venkat is the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy: Dynamic Productivity for the Java Developer and Programming Scala: Tackle Multi-Core Complexity on the Java Virtual Machine. His latest book is Programming Concurrency on the JVM: Mastering Synchronization, STM, and Actors.

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

When Did That Happen?

Grace Murray Hopper and Automatic Coding

by Dan Wohlbruck

Grace Hopper calls for a library of programming routines.

On February 16, 1955, Dr. Grace Murray Hopper, then the Director of Programming Research at the Remington Rand Corporation, delivered a paper titled “Automatic Coding for Digital Computers” at a conference at Louisiana State University. Her paper began by enumerating six steps which every problem must go through. As described by Dr. Murray, those steps are:

Analysis

Programming

Coding

Debugging

Production Running

Evaluation

Although these steps are familiar, this is the coding task as understood by Dr. Hopper in 1955:

“It is then the job of the coder to reduce the flow charts to the detailed list of computer instructions. At this point, an exact and comprehensive knowledge of the computer, its code, coding tricks, details of sentinels and of pulse code are required.”

By 1955, it was already understood that coding the program was the most troublesome step. Grace Hopper wanted an automatic coder that would draw on previously written routines that could then be linked together to make a single program. She believed the benefits of such automatic program generation to be:

“If a routine is produced by a master routine from library components, it does not require the fourth phase—debugging—from the point of view of the coding. Since the library routines will all have been checked and the compiler checked, no errors in coding can be introduced into the program.”

Dr. Hopper was a lady of her word. Later that year, a team that she led at Remington Rand introduced something called Flow-Matic, the first programming language designed for business users that expressed computer commands in something like the English language. Flow-Matic was used by Rand engineers for two years before being made available to the public in 1958.

But Dr. Hopper didn’t stop there. Since Flow-Matic was designed for use by Sperry Rand computers, by 1959 it became obvious that something like it was needed for more general use. A meeting was held at the Pentagon on May 28 and 29, 1959, where it was decided that during the next few months a committee should be formed to recommend a short-range approach to a common business language. Grace Hopper was appointed as the technical advisor to the committee. By the end of the year, the committee delivered its first specification and, after editing and approval by the parties involved, the COBOL 60 Report was issued by the US Printing Office in June 1960.

From that date forward, all computers ordered by the US government would have to be delivered with a COBOL compiler.

As a result of her pioneering work, Dr. Hopper was named the 1969 Computer Sciences “Man of the Year” by the Data Processing Management Association. In 1971 Grace Hopper retired from Sperry-Rand. Because Dr. Hopper had served in the Navy during World War II, she was reactivated in a White House ceremony in 1983 and promoted to the rank of commodore and then rear admiral. In 1985 she became simply Admiral Hopper and in 1990 she was awarded the National Medal of Technology.

On January 1, 1992, Grace Hopper died at the age of 85. In a tribute to her placed in the Navy’s website, the following is reported:

“One dream Hopper didn’t fulfill was living to the age of 94. She wanted to be here December 31, 1999 for the New Year’s Eve to end all New Year’s Eve parties. She also wanted to be able to look back at the early days of the computer and say to all the doubters, ‘See? We told you the computer could do all that!’”

Admiral Hopper was one of a very small number of people who was instrumental in making the computer “do all that.”

It all started in February 1955—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? Send the author your feedback or discuss the article in the magazine forum.

The Quiz

This Month: A Simple Cryptogram

In keeping with this issue’s theme of change, here’s a really easy cryptogram puzzle. The encrypted words in the first sentence can be rearranged to form the encrypted words in the second sentence. Decrypt the two sentences.

How long before BKGK GMHWDFMB Google for search?

The only book in the dining car was GDKWB GMFKHMB.

Good luck.

Solution to Last Issue’s Quiz

Last month’s puzzle was a Sudoku with letters instead of digits. Hidden within it was a name that any computer scientist should be familiar with.

O
N
Y

H
J
T

K
U
E

E
H
K

Y
U
N

T
J
O

J
U
T

E
O
K

Y
H
N

Y
H
K

N
E
O

U
T
J

O
E
T

U
K
J

H
N
Y

N
J
U

T
Y
H

O
K
E

E
Y
N

J
O
H

T
K
U

K
O
H

N
T
U

J
Y
E

U
T
J

K
E
Y

H
N
O

The hidden name is JOHN TUKEY in row 8. Tukey was a famous statistician, but his work has real significance for software development. Not only did he develop the Fast Fourier Transform, but he also coined the term “bit” and was the first person to use the word “software” in print.

Calendar

Author sightings, partner events, and other notable happenings.

Here’s what’s coming up in the next three months:

Author Appearances

Who’s where, and what for.

Feb 13–15, Jfokus, Stockholm, Sweden

“Regex Applied—when regex is a winner”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Feb 17–19, Agile India 2012, Bangalore, India

topic TBD

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

Feb 24–25, NFJS Madison, Madison, WI

topic TBD

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

Feb 28, Manchester Java User Group, Manchester, NH

topic TBD

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

Feb 28, Softdevon III, Crakow, Poland

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

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Mar 2–3, Twin Cities Software Symposium, Minneapolis, MN

Multiple talks on JavaScript, HTML 5, Scala, Concurrency, and automated testing

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

March 6-9, Pragmatic Studio, Denver, CO

iPhone/iPad Programming

Daniel H Steinberg, Dim Sum Thinking

Mar 8, Scandinavian Agile Conference, Helsinki, Finland

How to approach Refactoring?

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

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

Multiple talks on JavaScript, HTML 5, Scala, Concurrency, and automated testing

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

Mar 12-14, 2012, Belgium Testing Days, Brussels, Belgium

Tutorial: “Influence and Authority: Using Your Personal Power to Get Things Done,” Keynote: “QA or Test? Does it Matter? You Bet it Does!”

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

Mar 15, Devlin 2012, Linköping, Sweden

“A3 reports—processing change proposals”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Mar 15—17, Mountain West Ruby Conference Workshop, Salt Lake City, UT

Mountain West Ruby Conference Workshop: “Advanced Rails Design: Use Fancy OO Techniques Without Turning Ruby into Java”

Noel Rappin, author of Rails Test Prescriptions: Keeping Your Application Healthy

Mar 16, Agile Japan 2012, Osaka, Japan

Keynote

Jonathan Rasmusson, author of The Agile Samurai

March 16–17, CocoaConf, Chicago, IL

“Core Audio Cranks It Up” and “Core What?”

Chris Adamson, co-author of iOS SDK Development

March 16-17, CocoaConf, Chicago, IL

Storyboarding, Testing, and a Keynote

Daniel H Steinberg, Dim Sum Thinking

Mar 19–20, Software Passion Summit 2012, Gothenburg, Sweden

“Advanced Regex”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

Mar 19–21, 33rd Degree Conference, Krakow, Poland

Keynote and talks on Concurrency, Scala, and JVM languages integration

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

Apr 10—12, Percona Live MySQL Conference & Expo 2012, Santa Clara, CA

“SQL Injection Myths and Fallacies” and “Full Text Search Throwdown”

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

Apr 10—12, Emerging Technologies for the Enterprise, Philadelphia, PA

“The CoffeeScript Edge”

Trevor Burnham, author of CoffeeScript: Accelerated JavaScript Development

Apr 17—18, Working Effectively In Geographically Distributed Agile Project Teams, Pleasanton, CA

Public Workshop: “Working Effectively In Geographically Distributed Agile Project Teams”

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

Apr 17—20, Great Indian Developer Summit, Bangalore, India

Keynote and talks on multiple topics

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

Apr 23–24, Agile Sweden 2012, Stockholm, Sweden

“Inclusion over Integration”

Staffan Nöteberg, author of Pomodoro Technique Illustrated

April 27—29, Northern Virginia Software Symposium, Reston, VA

Multiple talks on JavaScript, HTML 5, Scala, Concurrency, and automated testing

Venkat Subramaniam, the author of .NET Gotchas, the coauthor of 2007 Jolt Productivity Award winning Practices of an Agile Developer, the author of Programming Groovy, Programming Scala and Programming Concurrency on the JVM

O’Reilly Events

Upcoming events from our friends at O’Reilly.

Feb 13–15, TOC, New York, NY

O’Reilly Tools of Change for Publishing Conference 2012: “O’Reilly’s TOC Conference is where the publishing and tech industries converge, as practitioners and executives from both camps share what they’ve learned from their successes and failures, explore ideas, and join together to navigate publishing’s ongoing transformation.”

Feb 28–Mar 1, Strata Conference, Santa Clara, CA

O’Reilly Strata Conference: “Strata brings together practitioners, researchers, IT leaders and entrepreneurs to discuss big data, Hadoop, analytics, visualization, and data markets.”

Mar 18, TOC Bologna, Bologna, Italy

Tools of Change Bologna: “TOC and the Bologna Children’s Book Fair will team up once again, this time producing an unparalleled event featuring sessions, demos, workshops, and keynotes covering the art, craft, and business of storytelling in the digital age.”

Apr 2—4, whereconf, San Francisco, CA

Where Conference: “The O’Reilly Where Conference is where the people working on and using location technologies come together to explore best practices and emerging trends in software development, tools, business strategies, and marketing.”

USENIX Events

What’s coming from our USENIX friends.

Feb 5–8, NDSS 2012, San Diego, CA

19th Annual Network & Distributed System Security Symposium: “The Network and Distributed System Security Symposium fosters information exchange among researchers and practitioners of network and distributed system security.”

Feb 14–17, FAST ’12, San Jose, CA

10th USENIX Conference on File and Storage Technologies: “FAST ’12 brings together storage system researchers and practitioners to explore new directions in the design, implementation, evaluation, and deployment of storage systems.”

Apr 10—13, EuroSys 2012, Bern, Switzerland

EuroSys 2012: “EuroSys has become a premier forum for discussing various issues of systems software research and development, including implications related to hardware and applications.”

Apr 24, Hot-ICE ’12, San Jose, CA

2nd USENIX Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services: “The second Hot-ICE workshop builds on the success of the first workshop last year and seeks to bring together researchers and practitioners working on network and service management in the Internet, cloud, and enterprise domains.”

Apr 24, LEET ’12, San Jose, CA

5th USENIX Workshop on Large-Scale Exploits and Emergent Threats: “Now in its fifth year, LEET continues to be a unique forum for the discussion of threats to the confidentiality of our data, the integrity of digital transactions, and the dependability of the technologies we increasingly rely upon.”

Apr 25—27, NSDI ’12, San Jose, CA

9th USENIX Symposium on Networked Systems Design and Implementation: “NSDI '12 focuses on the design principles, implementation, and practical evaluation of large-scale networked and distributed systems.”

Other Happenings

Feb 4

Ken Thompson is 69.

Feb 5

Brad Fitzpatrick, author of memcached, is 32.

Feb 7

Leslie Lamport, creator of LaTeX, is 71.

Feb 8

MIT professor Gerald Jay Sussman is 65.

Feb 12

Phil Zimmerman, author of PGP, is 58.

Feb 15

Niklaus Wirth is 78.

Feb 22

Bill Jolitz is 55.

Feb 24

The Ruby programming language was conceived on this date in 1993.

Feb 27

Grady Booch is 57.

Feb 29

Seymour Papert turns either 84 or 21 today.

Mar 1

Yahoo (as a corporation) is 17.

Mar 3

GNOME first came out of its burrow on this date in 1999.

Mar 9

Jef Raskin would have turned 69 today.

Mar 11

J.C.R. Licklider would have turned 97 today.

Mar 13

On this date in 1986, Microsoft went public, creating four billionaires.

Mar 15

A-life pioneer Craig Reynolds, who worked on the first Tron, is 59.

Mar 15

It’s the Ides of March. Beware.

Mar 16

Richard Stallman is 59 and MINIX author Andy Tanenbaum is 68.

Mar 24

It’s Ada Lovelace Day, honoring women in technology and science.

Mar 24

Mac OS X is XI today.

Mar 25

On this day in 1995, Wiki went worldwide as Ward Cunningham installed WikiWikiWeb on the Web.

Mar 26

Larry Page is 39.

Mar 31

Evan Williams, co-founder of Twitter, is 40.

Apr 6

MacOS co-creator Andy Hertzfeld is 59.

Apr 5

Inventor Dean Kamen is 61.

Apr 9

ENIAC co-inventor J. Presper Eckert was born on this date in 1919.

Apr 9

SQLite architect D. Richard Hipp is 51.

Apr 14

Ruby designer Yukihiro Matsumoto (Matz) is 47.

Apr 20

Chief Yahoo David Filo is 46.

Apr 24

Champion of modelessness Larry Tesler is 67.

Apr 28

Mathematician Kurt Gödel was born on this date in 1906.

Apr 30

Information theory pioneer Claude Shannon was born on this date in 1916.

Apr 30

Colossal Cave Adventure creator Don Woods is 58.

Apr 30

The World Wide Web is 19.

Shady Illuminations

The Ulteriority of Ultraness

by John Shade

John reflects on the Ultrabook hype and thinks he sees ulterior motives.

“It was thanks to Ultra that we won the war.” -Winston Churchill

I’m on Twitter now. Bad idea. I no sooner sign up than I read this post by Gina Trapani on the downside of web fame. Fortunately I haven’t done any of the things that Gina has, so I doubt that I’m in danger of become one of the web one percent. Anyway, I’m @JohnShade1.

I ought to come up with a playlist for this column. Music to listen to while reading. “Not Dark Yet” by Dylan. “Paint It Black” by the Stones. “Dirt in the Ground” by Tom Waits. OK, make that any Tom Waits. Pretty much any music that’s cheerfully dark. All of Brecht and Weill. Nina Simone’s version of “Pirate Jenny.” Like that. Maybe I’ll get around to it someday. For now, the headings in this column are all song titles from Depeche Mode’s “Ultra,” so if you want to put yourself in the right mood while reading it, that’s what you should be listening to.

Useless

Right after CES, two articles on the Ultrabook phenomenon arrived in my inbox. One told me to pay attention to it. The other said to ignore it. So they net out at zero information. Useless, right? I don’t see why they had to appear in my inbox at all. In an ideal world, two messages with opposite information would cancel each other out, like a particle and an antiparticle, consuming zero bandwidth and their interaction doing some Feynman time-reversal deal so they were never sent.

I guess if I were smart I’d just ignore them. The trouble is, these Ultrabooks have interesting specs and will probably sell very well. So I guess I have to pay attention to Ultrabooks even though the name makes my flesh crawl like being followed by people obsessed with photographing cats. Why did I have to enter the world of twits?

Insight

On second thought, though, what about that name?

“Ultra” has various shades of meaning, but essentially it means “beyond.” Ultraviolet is beyond violet, past the tweakiest color of the visible spectrum. The ancients allegedly carved ne plus ultra in the Pillars of Hercules at the Strait of Gibraltar. Yes, they carved it just like that, in italics. They were italic, so of course they wrote in italic. That’s why the Leaning Tower of Pisa leans. Anyway, the italics were warning sailors that there was “nothing more beyond.” They’d reached the end of the ancient world.

So is Intel saying that there is nothing more beyond this spec? That this is the end of the line? They wouldn’t be alone in concluding that the personal computer has no future. That we’re moving on to other platforms. And Intel is always looking at least one generation beyond the vision of the OEMs.

Is the Ultrabook the ultimate personal computer, the final embodiment of the concept before it is displaced entirely by tablets manacled to the clouds?

The Love Thieves

What is an Ultrabook, anyway? Besides trending on Twitter?

I decided to research that question. Using the best practices of journalism today, I googled up a random blog post and scrolled through the comments until I found something that I liked.

As someone calling himorherself dicobalt put it whereever it was that I found this, “They are thin... and they are light. They are thin AND light. With the advantage of being thin and light! While still being thin and light.”

That seemed clear enough. In fact, everthing else I read from OEMs claiming to have an Ultrabook only muddied the waters. I’d just about decided to settle on dicobalt’s definition when I came upon this:

“Neither AMD nor ARM will be able to use Ultrabook branding.”

I’m not the sharpest knife in the drawer when it comes to understanding marketing strategies. But I get this one, because I’ve seen it before.

When you come up with “the first and arguably most successful ingredient-branding program” ever, you don’t abandon it easily. You figure maybe you can get some more mileage out of it if you change the label.

The Bottom Line

The one defining feature of an ultrabook is that it uses Intel technology. Ultrabook means one thing for sure, and that’s the thing that matters:

Ultrabook = Intel Inside. Case closed.

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. 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

We’ll be interviewing Antonio Cangiano about blogging. Antonio just finished his book Technical Blogging and Mike wants some pointers on how to improve his blog. ;-) Venkat will continue his series on the Scala language, and we’ve got an article on pair programming by Zee Spencer and something JavaScript-related from Noel Rappin.

Coming Soon on the Bookshelf

The Developer’s Code: What Real Programmers Do is in print, as are Rails Recipes: Rails 3 Edition, Technical Blogging: Turn Your Expertise into a Remarkable Online Presence, and Programming Your Home

Right. 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.