PragPub 2014-01: Issue #55

Table of Contents

Features

Automating Android for Your Listening Pleasure

by Mike Riley

Mike teaches his Android to walk and chew gum at the same time.

Clojure and EDN

by Michael Bevilacqua-Linn

The ins and outs of EDN

Leveraging Retrospectives

by Jeff Cohen

Retrospectives are not just for teams.

The Roots of Revolution

by Michael Swaine and Paul Freiberger

The counterculture of the 1960s definitely influenced the personal computer revolution. Exactly how is complicated.

Departments

On Tap

by Michael Swaine

Teaching kids to code, getting Clojure, rethinking retrospectives, and more.

Choice Bits

A month recaptured in tweets and news bits.

Teaching Kids to Code

by David Bock

David reflects on a week teaching kids to code, and asks why we can’t make every week Computer Science Education Week.

Rothman and Lester

by Johanna Rothman and Andy Lester

How to land that dream job.

Pragmatic Bookstuff

Want to meet one of the Pragmatic Bookshelf authors face-to-face? Here’s where they’ll be in the coming months. Also, find out what are the top-selling Pragmatic Bookshelf books and what new books are coming out.

Antonio on Books

All the new tech books of note.

Shady Illuminations

by John Shade

John takes on the Bitcoin phenomenon and offers a modest, though extraterrestrial, proposal.

Rear Window

A Toast to the Hardware Hackers

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

On Tap

An Hour of Code

by Michael Swaine

As revealed in our Top-11 list, the best-selling Pragmatic Bookshelf book for this past month was Andy Hunt’s Learn to Program with Minecraft Plugins. Antonio Cangiano, in his new books column in this issue, highlights Warren Sande’s Hello World!: Computer Programming for Kids and Other Beginners as particularly worthy of your attention. Also in this issue, David Bock reports on his experiences in teaching kids to code during the Computer Science Education Week “Hour of Code” program.

Do you think we’re trying to tell you something?

We are. We think that the ability to code is a survival skill for the 21st Century. And we think that programmers have a unique role to play. Expect to see more articles on teaching kids to code throughout the coming year in PragPub.

Mostly, though, the January issue is about your own programming and your career.

Mike Riley shares a nifty little Android project that exploits an insight into how information processing works inside your head: your ears can multitask. The Android OS can multitask, too, but unfortunately, the text-to-speech apps available for it can’t handle multiple audio streams. So what if you want to get audio notifications while listening to podcasts or having the latest issue of PragPub read to you? Mike Riley to the rescue.

Michael Bevilacqua-Linn continues his series on the Clojure language, this month looking at the ins and outs of EDN. Jeff Cohen has some thoughts on how to use retrospectives in contexts where you might not have thought of applying them. Johanna Rothman and Andy Lester discuss how to land your dream job. And we have David Bock on teaching kids to code, Antonio Cangiano on new tech books, and John Shade on the Bitcoin phenomenon (and on the largest moon of Neptune).

This being January, the magazine does the Janus thing and takes a look back at the early days of personal computing. Thirty-nine years ago this month, that Popular Electronics cover featuring a mock-up of a so-called microcomputer launched the personal computer revolution. It was a strange sort of revolution, coming on the heels of the social revolution of the 1960s.

But the 60s counterculture was only one of the influences on the development of personal computer. An arguably stronger driving force behind the revolutionary change was simply a passion for fiddling with technology. The personal computer really was the triumph of the nerds. Among whom we count ourselves.

This issue looks at both these threads. It tells the story of a dropout who became an entrepreneur, and when he’d achieved success, dropped out of that and became a political activist. And the issue closes with a brief appreciation of the electronics hobbyists who were crucial to the beginning of the personal computer era.

PragPub began a new chapter in 2013, with a subscription model. We are grateful for the support you have shown us this past year, and we have what we think are some exciting plans for the coming year. So welcome to 2014. No doubt it will be an interesting ride.

Cover, istockphoto.com/stevecoleimages; p. 3, Erika anonymous; p. 5, istockphoto.com/stevecoleimages; p. 14, istockphoto.com/ChristopherBernard; p. 24, istockphoto.com/fotosymasfotos; p. 27, istockphoto.com/Izabela Habur; p. 33, Mitch Kapor; p. 44, Antonio Cangiano; p. 48, Roger Melen.

Choice Bits

Drones, Bots, and Bitcoins

A month recaptured in tweets and news bits.

In the past year, Google bought eight robotics companies. The companies are: Boston Dynamics, which makes a mechanical mule; Schaft, working on a humanoid robot; Industrial Perception, maker of robotic arms and eyes; Meka, humanoid robots and robotic arms; Redwood Robotics, ditto; Bot & Dolly, robotic camera systems (featured in the movie “Gravity”); Holomni, which makes wheels for bots; and Autofuss (a little vague). You will now begin wondering what the heck Google is planning. Happy new year. (cheers to Raw Story)

So, communists are on the moon, Americans are spying on everyone, and a large advertising company is expanding into military robots. — @tef

Amazon wants to use drones by 2018. An Australian startup will do it by March. — @mims

I wonder if one day the Amazon drones will start fighting over stuff on Cyber Monday for the people that fight at Walmart on Black Friday. — @RachelAppel

A reader who is still clinging valiantly to whatever anonymity she has submitted this picture she took of a drone that was following her on a California beach.

Can You Mine Bitcoins without Getting the Shaft?

A tiny British island is going to use the Royal Mint to press Bitcoins. — @mims

From @delrey: Bitcoin’s Biggest Bet: Andreessen Horowitz Leads $25 Million Investment in Coinbase. — @karaswisher

Couldn’t USA resolve deficit by using NSA computers to mine bitcoins? — @RonJeffries

Yet another reason the bitcoin bubble is just getting started: most Americans haven’t even heard of it yet. — @mims

A Few Bugs in the System

My confidence in a website is not increased when the password reset page is a 404. — @petdance

All it took to fix MS Outlook was to whack the side of the monitor with the palm of my hand and adjust the rabbit ears. — @MrAlanCooper

Scrum in a nutshell: “Here is a system to make your problems more apparent, devoid of tools for solving them. So work it out.” — @tottinge

“But I haven’t changed anything.” #FiveWordTechHorrors — @PragmaticAndy

So far my re-introduction to the Amazon affiliate program has earned me 12 cents. — @noelrap

I’m ready to certify Node 0.10.22 as ‘Walmart Black Friday Ready’. If you’re bigger than that it’s your problem.” - @eranhammer #nodesummit — @seldo2

Amsterdam gets alcoholics off the street and into jobs by paying them in beer. — @mims

Technically, according to chemistry, alcohol IS a solution. #JustSayin — @RachelAppel

I hate it when my gym clothes are accidentally matchy matchy. — @chadfowler

A co-worker is wearing what may be the world’s only long-sleeved Hawaiian shirt. — @undees

NASA’s latest toy for rolling around on the surface of another world really looks like a toy, and it really rolls. Also bounces, jumps off cliffs, and squunches. NASA’s Super Ball Bot depends on tensegrity for its resilience, maneuverability, and essential goofiness. (cheers to Dvice)

No doubt Google will buy it.

Who Are Those Guys?

First, they’re not all guys. Second, we have to confess that we cleaned up the punctuation and stuff in the tweets. Here’s the list of folks we followed this month: Rachel Appel, Alan Cooper, Ian Dees, Chad Fowler, Andy Hunt, Ron Jeffries, Andy Lester, Christopher Mims, Tim Ottinger, Noel Rappin, Kara Swisher, i am become tef, and Laurie Voss.

Fair’s fair. You can follow us at www.twitter.com/pragpub.

Teaching Kids to Code

Reflections on An Hour of Code

by David Bock

David reflects on a week teaching kids to code, and asks why we can’t make every week Computer Science Education Week.

December 9th through the 15th was Computer Science Education Week in American public schools. Andy Hunt recently had the opportunity to catch up over dinner with David Bock, who had volunteered the entire week at a local elementary school.

Andy: Dave, so how did you get involved in Computer Science Education Week?

David: It started for me sometime in October. I had seen an article about Computer Science Education Week online, and sent an email to my kid’s principal saying that if they’d pull something together in their computer lab, I’d be willing to volunteer for the week to teach kids.

Andy: So the school already has a computer lab?

David: Yeah, it has about 30 PCs in it with educational software, but they are all locked down, so it’s hard to do something interesting with them.

Andy: Does the school teach any kind of programming?

David: Like most of the U.S., my county’s school system doesn’t teach anything like that. I’ve previously commented that they basically teach “20th Century office worker skills.”

Andy: That’s unfortunate.

David: Yeah, but while the curriculum might not be there from the top down, I’ve found that, at my school anyway, the administration, teachers, and kids are eager to make something happen.

Andy: So what happened after the email to the principal?

David: A few emails bounced around about logistics, but nothing solid came of it. Then, just about 2 weeks before the date, I got a rough schedule with teachers, classes, and times of the day. I suddenly felt in over my head.

Andy: How did you decide what you were going to teach them?

David: Luckily there is a bunch of material in support of Computer Science Education Week, including the Hour of Code. That’s a website with several one-hour lessons in computer science—with stuff you can do with kindergartners and graph paper, all the way up to high school level.

Andy: Sounds great! So what did you teach the kids?

David: The lesson plan that was heavily promoted for that week involved a few videos and something akin to turtle graphics, but using characters from Angry Birds and Plants vs. Zombies. You basically have to move a character around with commands like move forward and turn right, and get them to their destination. There are 20 problems, and we had a great time with them.

Andy: And do you think this was a good introduction?

David: At first I had my doubts. The programming is done in a language called Blockly, where you take pre-written snippets of code and snap them together like legos. There is literally a snap sound when you connect the lines. To my cynical self, it seemed too cartoonish, without enough real “stuff” behind it.

Andy: What changed your mind?

David: I did it with my own kids first. I was amazed at how the choice of those two games kept them engaged. Also, I realized the problems they had to solve with the code were legitimately computer logic, but the way Blockly snaps together, the kids don’t have to worry about any language syntax.

Andy: Can you give an example of the “computer logic” they had to code?

David: Sure... in fact, I have 2 examples. In the first seven or so problems, the students have to move an angry bird to the same square a pig is in, using nothing but move forward, turn left, and turn right. The solutions are hard coded for that particular puzzle. But then, they have to start messing around with loops and if tests about their position in the maze. In one of the first puzzles to use loops, they have to repeat move forward, move forward, turn right three times in order to make the bird move around the 3 sides of a square. At first, the kids want to hard code the solution, and they would get frustrated when they couldn’t drag the repeat 3 times block to the trash can. I would explain the problem and then ask “What steps can we do 1... 2... 3... times (drawing my finger along the three sides of the square) to get the bird to the pig?”

At this point you could see the light go on behind their eyes as they’d exclaim “oooohhhhhh!” I joked with the other teacher that “that’s the sound of ignorance leaving the body.”

Another student said to me, “This is fun! It’s hard, but it’s easy at the same time.”

Andy: Cool. You said you had a second example?

David: Yeah—the last problem is a doozy, but the puzzle starts with most of the solution in place... the kids just have to debug it and add a few lines. The solution involves a while loop, and three if-then-else tests along with the commands to move or rotate.

Andy: That sounds pretty complex for an hour intro.

David: Well, the kids actually had less than the full hour, but I’ll talk about that in a minute. Only about ten percent of the kids made it through all 20 problems, but that didn’t dampen their enthusiasm since they could finish it at home. We’d walk through that final solution on the whiteboard/projector at the end of the lab time so everyone could see it. After they understood the solution, I’d point out, “But that isn’t just a solution for this one maze.... We could put that zombie in any maze and he’d be able to follow the path to the solution.” You could see in their eyes when they made the connection that this was more than just more forward, turn left instructions.

One kid said, “So computers aren’t smart... they are just dumb, really, really fast.”

Andy: So you think they learned something valuable about programming?

David: I watched all these kids model a problem while thinking about it from the bird’s position—they were modeling state—“Where is the bird now?” I watched them count the number of blocks their character would have to move, and sometimes forget that turning didn’t actually move one square in that direction (an off-by-one error), then I watched them run their program and correct it based on what happened... that’s debugging.

When a particular student would get frustrated, I’d just reload the page and tell them to “reload their head” too... start over, and I’d explain “there are days I spend debugging a problem only to realize I had a typo in another part of the program. It’s not important that I get it right, it’s only important that I eventually get it right.” And I saw this really touch the kids... At times it seemed like I might have been the first adult that shared struggling on a problem with them.

Andy: So what else did you do with the kids besides the exercises?

David: Well, I love an audience, and I wanted to start with a connection to the kids. So I started by showing them a picture of me at 10 years old with my TRS-80 model 1 in the background, and I’d show them a book of computer games I used to type in.

Andy: Wow... how’d that go over?

David: They looked at me with disbelief that I’d spend hours typing a game just to have my older brother beat me in a few minutes. But I explained that I learned to program by typing in those games, because I learned to change them so I could beat my brother. I then told them that they “were going to learn more about programming in the next hour than I knew at their age,” which is true, and also motivated them.

After the exercises I wrapped up by showing them a program I wrote that plays Connect 4. After the computer would easily trounce the entire class playing collectively, I’d open the code and show them some of the if-then-else statements they had just seen, as well as the few hundred lines of code that actually plays the game. I showed them it was just a more complex example of what they were just doing.

Finally, I’d show them the cover to your book Learn to Program with Minecraft Plugins... Many of them already played Minecraft, and I thought that might be another hook to keep them interested.

Andy: Hah! Thanks for the plug! How many kids did you do this with?

David: Originally our plan was to do it with eight classes of 4th and 5th graders, with about 25 kids in each class. After I went through the plans with the Principal and the Technology Resource Teacher, we decided to do it with the 3rd graders as well. In total it was about 300 kids.

Andy: So what’s next?

David: Well, I’m in a pretty small town, and I’ve already seen some of the kids out in public. One kid introduced me to his mom in the grocery store, excitedly proclaiming, “Mom! It’s the computer guy! It’s the computer guy!” I guess there are worse things to be known for....

Seriously though, I volunteer at my kid’s school about once a month, so I’ll see these kids again. I’m hoping to find kids I really motivated, and maybe create an after-school club through the PTA next spring.

Andy: How can other parents get involved like this?

David: Take a look at the Hour of Code website, and get familiar with some of the examples. Then contact a principal at your local school, show them the links, and volunteer your time. I bet they will be receptive... Computer Science Education week got a lot of positive press, and I see no reason why we have to limit it to just one week.

David Bock is a Principal Consultant at CodeSherpas, a software engineering services consultancy he founded in 2007. He spends his days writing Ruby, Java, and Clojure, and consulting with teams and managers to help them improve their software development practices. He spends his evenings at technical community user groups in the Washington D.C. Metropolitan region, and his weekends attending and speaking at conferences.

In past technical lives, Mr. Bock has been the editor for O’Reilly’s OnJava newsletter, served as a founder and President of the Northern Virginia Java and Ruby user groups, and served on the JCP as a member of JSR 270, defining the contents of the Java 6 platform. He also served as the Technical Director of the Federal Domain at FGM Inc. and was the Chief Architect of the Export Control Program for the U.S. Department of State, Nonproliferation and Disarmament Fund.

You can find Dave on Twitter, LinkedIn, Github, CoderWall, Stack Overflow, and most other social networks as “bokmann”.

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

Rothman and Lester

Landing the Dream Job

by Johanna Rothman and Andy Lester

Landing the dream job

Andy: In our last column, we talked about the age-old question “How can I get my boss to do X?” which has been asked ever since Ogg The Caveman asked “How Ogg get boss buy him bigger club?”

All the time we think about how to convince the boss to do something, but that’s after we’re already working there. Rarely do I hear people ask the question “How can I convince the boss to hire me?” This is different than “How can I get a job?” because it recognizes that you, as the candidate, have an active role to play in getting the hiring process to come out how you want it. It’s all about presenting evidence.

Johanna: It starts with the résumé and cover letter. If you want to separate yourself from the gazillion of other people who just send in a résumé and cover letter, you will have already networked with someone at this company. They will already know you. You will have a warm introduction, either through an employee referral or a recruiter.

Andy: Many people seem to find this sort of introduction distasteful, but it’s far from it. The hiring manager wants these introductions. Given the choice between 100 résumés at random from the general public, and one résumé handed to him by a friend of the candidate, the hiring manager is going to go with the latter. The recommendation is evidence that you are at least worth talking to.

Johanna: Right. He or she is much more likely to be receptive to you and what you want, if the hiring manager knows you from a networked introduction.

Andy: And what goes in that résumé to be convincing? Details. Details are evidence.

Don’t use vague bullet points like “Wrote web applications.” That could be anything. That could be writing a page counter CGI that you copied out of a book from 1996. Tell me about the programs you wrote.

Instead of vague umbrella statements, think like a newspaper reporter. The reporter asks “Who?,” “What?,” “When?,” “Where,” “How,” and “Why?” Your evidence in your résumé should answer many of these questions as well.

For example, you might expand “Wrote web applications” with “Part of a team of three that designed and wrote a web-based call-tracking app for customer service. Finished app was N,000 lines of Ruby on Rails with a PostgreSQL database backend, and serves a department of 20 users every day, allowing us to save $10,000/year in licensing.”

In just those two sentences, you’ve told me details: who you worked with, what the app did, what technology was used, who used it, how many lines of code, and why you wrote it.

Details make your résumé compelling. Details make the story, and you are telling stories about what you did as evidence to show that you can do awesome things in the future, too.

Johanna: I want to hear all about the value of that application. You’ve said it saved licensing fees, but when we discuss this in the interview, when you tell me the story about this app, I’ll ask questions such as, “How many concurrent users does it support?” I’ll expect to hear at least 20. If you tell me more than 20, I’m going to want to hear about the other departments you’re supporting and why.

No matter what, focus on the value of the work you did. Every time, try to translate the value into money or time, if you can. Details make the difference. And details lead to value.

Andy: Sometimes people tell me “I don’t know numbers like dollar savings, or number of users,” so tell what you can. Even if you can’t describe a return on investment in dollars and time, you can still give details and tell a story.

Johanna: So, you’ve figured out a way to get into the company. They have your résumé, and you’ve landed the interview. You’ve thought in advance about your details, and you put the most recent details, at least, on your résumé. You are ready with the stories of the other details for the interview. That way, you can keep your résumé to two pages. Now what?

Andy: Research. Reading the company’s website is the obvious first step, but only scratches the surface. Find news stories and press releases about them. Do they have expansion plans? Or have there been recent layoffs? Have they had new products that are generating a lot of new sales? Or have they had to streamline operations? Think business. You’re going to work for them to solve business problems, so you need to understand their business.

Johanna: So learning their business is key to getting your potential boss to hire you. That’s a transforming idea. You would only do this with a targeted list of companies, right? Not with everyone you interviewed with?

Andy: Yes, with every company you interview with. If you’re going to spend the time to go to an interview, then you spend the time doing the research.

Johanna: Doesn’t that take a long time? How long does it take you to research a company?

Andy: I figure an interview is going to be at least 3 hours of your life, right? So you can spend that long doing some research, too. If you’re going on so many interviews that you’re not able to research properly beforehand, then maybe you’re going on interviews that you shouldn’t be going on.

There aren’t 100 jobs out there that are a good fit for you, so you shouldn’t be going on 100 interviews, and probably shouldn’t be sending out 100 résumés.

Johanna: You are right. Spray-and-pray does not work for résumés or for networking. That’s why it’s so important to target the company first.

Andy: The way I see it, if you don’t even know what the company does, you have no business sending a résumé. So you should be doing basic research before you spend the time to customize and send a résumé.

Johanna: You sent your résumé. You landed the interview. Your résumé shows details with value. You did the research in advance so you know this is a potential place you want to work. Because you are a known quantity, and because you have presented details to your potential boss, it’s easy for your potential boss to say, “Yes” when he or she sees you in person. You are the kind of person same-day offers are made for.

I just spoke to a colleague today who received an offer the same day he had an interview. What did he do? He had networked with the hiring manager at a professional meeting, so he was not a stranger. He had details about his experience on his résumé and stories for the manager. He had done his research on the company, and the company was a great fit for him. He had questions for the hiring manager and team, and he asked them during the interview. He received the offer a few hours after the interview.

Andy: Let me tell you a story about selling yourself in an interview.

A friend of mine, Bill, is a consultant. He and a representative from Bill’s employer go for an interview at the potential client’s office. The client wanted to hire a network administrator, and during the interview, they got to discussing some network problems the company was having. Seems that every day around 1:00 PM, the network would slow to a crawl.

So Bill asks some questions, finds out that X, Y, and Z happen throughout the day. He goes to the whiteboard and draws a sketch of a network layout and says “Your network is set up like this, right?” Interviewer agrees, “yeah, the network is pretty much like that.”

Bill draws another sketch on the whiteboard, and explains that the network might work better if it was set up as demonstrated in his sketch. He explains some of the reasons behind it.

The interviewer is astonished. Interviewer runs to get his boss. Interviewer and boss come back and Bill does some more explaining.

While Bill is talking to interviewer and boss, the interviewer starts copying Bill’s sketch down on paper. Bill’s handler, who has been sitting back watching all this, goes up to the white board and starts erasing the stuff that Bill had drawn. The interviewer gasps and says “Hey, don’t erase that! We need that!” Bill’s handler says “No, you need Bill.”

Johanna: Right!

Andy: That is what you want to do in an interview. You want to show that you can solve the problems that the employer needs to solve.

Now, chances are you’re not going to be handed a clearly-defined problem that you can knock out of the park like Bill did. However, you can talk about the problems and challenges facing the boss, her department, her company.

Ask directly: “What kinds of challenges are you facing in the next six months?” Say the hiring manager tells you “Well, we’re rolling out a new help desk application, and that’s going to be a challenge.” That’s where you latch on to that and explain what exactly in your background you have done that might help with that.

Johanna: Or you can ask “What does success look like in the next 6 months?” You relate how you have done something exactly or close to this. You give the manager something to latch on to. If you provide the details we discussed, and the data, you have allowed the hiring manager to sell him or herself. And that’s how you help your boss hire you.

Andy: “What does success look like?” is a more positive way to look at what I phrase as “What kinds of challenges are you facing?” My preference has always been to look at specific challenges and run with them, but both work.

“Oh, you’re upgrading the database hardware? I just went through a similar upgrade where we upgraded our mail servers, with zero down time. It took a bit of planning and coordination. We had to do X, Y, and Z, and I was responsible for the X part, and I had to... etc., etc.”

Johanna: “Oh, you’re transitioning to agile? We did it, and here’s what happened .... ”

Andy: Exactly right. And you tell the good and the bad. But most of all you tell what YOU did.

Johanna: Your role. What you did, and your value.

Andy: Now, if you’re lucky with your research, you may find some of these things out before you even go in for the interview. You might say “I noticed that Bob Smith from your company has posted a lot on the MySQL mailing list, asking about interfacing MySQL with an Active Directory controller. Can you tell me about that project? How has that worked out?”

Johanna: Or, “I met Jane Williams at a PMI meeting. She was talking about a really interesting enterprise level program. She was trying to use agile, and having some challenges. We spoke and I was wondering how it was progressing.”

Andy: Anything that you can bring to the table is a win, because otherwise you’re just going to be sitting there answering questions like you’re a witness on the stand.

Johanna: Do some preliminary research, to make sure you and this company are a good fit. Then, see if you know someone there. If you do, arrange for an introduction, in the form of some kind of an employee referral. That will do your résumé and cover letter good.

Andy: Absolutely this research can help your résumé. If you find in your Googling around that Bob Smith has been posting to the MySQL list about Active Directory, and you know MySQL and/or Active Directory, then you know you should be highlighting them in your résumé and bringing them up in the interview.

Johanna: Once you do, and you have a date for the interview, make sure you finish your research, and bring your list of questions with you to the interview.

When your interviewer asks, “Do you have questions for me?”, ask away! You will be so impressive, from the beginning to the end, your potential boss will feel as if he or she has no choice but to offer you the job.

Next month, we'll talk about how to get your project manager or your manager off your back.

Johanna Rothman helps leaders solve problems and seize opportunities. She consults, speaks, and writes on managing high-technology product development. She enables managers, teams, and organizations to become more effective by applying her pragmatic approaches to the issues of project management, risk management, and people management. She writes the Pragmatic Manager email newsletter and two blogs on www.jrothman.com.

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 petdance.com, and can be reached by email at andy@petdance.com.

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

Automating Android for Your Listening Pleasure

Books, Music, Messages

by Mike Riley

Mike teaches his Android to walk and chew gum at the same time.

Like many tech enthusiasts, I am a rabid consumer of information. And like many software engineers, I am a person who prefers to live my life as efficiently as possible. I am also constantly on the go, whether it’s commuting to work, exercising at the gym, cleaning the house, running errands, or whatever. I double up on these low-mental energy tasks by listening to podcasts and audiobooks. But what I really like to do is read the latest titles published by the Pragmatic Bookshelf or the new issue of PragPub to keep my mind sharp.

Setting up text-to-speech (podcasts) for book reading/listening is relatively easy to do on an Android device. But there are other events that occur while I’m listening that I need to know about, and I don’t want to have to be inconvenienced every time I hear a notification chime.

With winter weather in Chicago hitting wind chills of 20 degrees below zero, I also don’t want to go through the hassle of removing my gloves, digging for my phone, unlocking it, and fumbling about to find out what message I received only to discover it was a spam email. I also have a habit of zoning out after about ten minutes of listening to monotonous text-to-speech translations. So I came up with the following configuration that solves these issues while maximizing my listening pleasure. It also turns out to be a nice Android project.

Multitask Your Android

This idea works thanks to the true multitasking nature of the Android OS. While concerns regarding impacts to battery life and performance are valid, most of the popular Android apps available from the Google Play marketplace are well behaved. The three programs I rely upon for this technical concoction to work are:

Moon+ Reader Pro (a book reader)

IVONA Text-to-Speech HQ (a TTS synthesizer)

Crafty App’s Tasker (task automation software)

I also prefer using a popular, feature-rich Android music player called Poweramp, although Google’s free Play Music program works just as well. I’ll show you how to install these applications and configure them so you can set yourself up for a hands-free learning experience.

Begin with the IVONA installation by selecting the voice you prefer. You can listen to samples via the IVONA voice selection page, as shown in the next figure.

IVONA voices

Once you’ve identified and installed your favorite IVONA voice, configure Android to use it as the preferred TTS engine in the Text-to-speech settings within Android’s Settings program.

Text-to-speech settings

Next, install Moon+ Reader Pro and either load up one of the free epub-based books that comes pre-installed with the reader or better yet, grab your favorite Pragmatic Bookshelf book and download either the epub or pdf version. Moon+ Reader Pro can read the text from either format. For my example, I loaded the December 2013 issue of PragPub in the epub format. Once the cover is displayed, tap anywhere on the screen to bring up Moon+ Reader Pro’s toolbar. Tapping the speaker icon on the toolbar will display Moon+ Reader Pro’s TTS Options dialog box. This will allow you to modify playback time and content delimiters as shown in the next figure.

Moon+ Reader Pro TTS options

Check the device’s volume and then select the Start TTS button to test the IVONA-assisted TTS playback of the source material. If everything is properly configured, you should hear your preferred IVONA voice read the magazine to you as Moon+ Reader Pro highlights the text being converted to audio.

Moon+ Reader Pro audio playback

Now that we have TTS book/magazine reading configured, we’re ready to create a Tasker task that will convert notifications such as emails and text messages to speech. Unfortunately, we can’t use the IVONA speech engine for both book reading and notifications since the IVONA engine will already be in use. IVONA’s speech engines can only manage reading one block of text at a time. To maneuver around this limitation, we will use Google’s own Text-to-Speech engine instead.

Pure Google Android devices such as their Nexus line already have Google’s TTS engine installed by default. You can also download and install it for free directly from the Google Play marketplace.

Experienced Android users might be wondering why I didn’t opt to use Google’s Play Books and Newsstand applications to read books and magazines aloud. For one, Play Newsstand doesn’t currently support text-to-speech playback of content, which is a bit of a letdown. Google Play Books does support TTS playback but it only works on epub-formatted titles. It also uses precious bandwidth to send audio rendered on Google’s servers to your smartphone. While this does produce a far more pleasing audio experience compared to the accurate but robotic-sounding default Google TTS engine, it only works when a network connection is available. This makes offline reading impractical. That is why I prefer Moon+ Reader Pro for my audio rendering needs. I get to choose what voice I want to hear, and I can listen to both epub and epub documents.

I also don’t have to concern myself with eating up mobile data or requiring an Internet connection just to hear my books.

You should now have at least two TTS engines installed on your Android device. The good news is that these can operate independently of one another. This will allow us to use one for book reading and the other for translating notification texts to speech. To do so, we will instruct a Read Notification task in Tasker to use Google’s TTS rather than rely on whatever TTS engine has been set as the system default (currently set to the IVONA engine).

Crafting the Task

A variety of Android programs can post messages to the notification area, such as new email alerts, Facebook postings, Twitter tweets, meeting/calendar reminders, and instant messaging texts (IM) to name just a few. We are going to create a task in Tasker that will read these new notifications to us. Now we can just listen to the notice without interrupting our book reading playback or digging for our phone to read inbound messages.

Launch Tasker, select the Tasks tab, and create a new task by touching the plus icon on Tasker’s toolbar. Name the task Read Notification. A Task Edit screen will then display. The Read Notification task will consist of a single action—that being to translate a new notification from text to speech. Add the action by selecting the plus icon. This will display the Select Action Category dialog.

Creating a new Tasker action

Select the Misc Action Category, followed by the Say Action. This will bring up the Say Action Edit screen consisting of several parameters ready for you to configure. The first of these is a choice of what text you want to translate to speech. Tasker has already assigned a number of pre-named variables to a variety of Android system references. The one we’re interested in is called %NTITLE, short for Notification Title. The next attribute to configure is very important, since this is where the advantage of using two separate TTS voice engines is realized. Since we have previously assigned the IVONA engine to be our default TTS engine, we need to explicitly assign Google’s TTS engine in this field. Do so by selecting the magnifying glass icon. This will display a list of speech engines installed on your Android device, as shown in the next figure.

Tasker speech engine selection

The next attribute to set is what audio channel you want to play back the TTS translation to. Selecting the list box on this attribute will display several options including Call, System, Ringer, Media, Alarm, and Notification. I recommend using the default stream, Media. Pitch and Speed change the way TTS is rendered. The final option to consider on the Say Action Edit screen to consider is the If statement. While certainly not required to make our project work, I use Tasker’s built-in power of regular expressions to filter out notifications that I don’t want our Read Notification action to read out loud. For example, Moon+ Reader Pro displays a notification each time it starts and stops its TTS playback. This can get annoying after awhile, so my If statement instructs Tasker to not read any notification with a title starting with the word Moon. I’ve added a few other filters to my If statement, as shown in the next figure.

Fintering out unwanted text

Note that we activate the If statement in this task by checking its checkbox, then instructing the If statement to compare the text value of %NTITLE to a regular expression using the Doesn’t Match Regex (regular expression) condition operator. When done, the complete Read Notification task should look like the following figure.

The read notification task

With our Read Notification task defined, save the Read Notification task by selecting the Action Edit left angle bracket icon in the upper lefthand of the screen.

Now we need to tell Tasker to execute this task each and every time we receive a new notification event. Do so by choosing Tasker’s Profiles tab and adding a new Event context by selecting it from the list of first context options that appears when selecting the plus icon.

After doing so, select the UI event category followed by the Notification event. Then assign the Read Notification task we created to the event profile as shown in the next figure.

Configuring the read notification event profile

Notice that when you attempt to do this, Tasker will remind you that it needs to be granted access rights to Android’s Accessibility Services in order for Tasker to be given permission to intercept notification events. To do so, launch Android Settings and select the Accessibility item under the System category. Then tap the Tasker–JB item located in the Services category and move the ON/OFF slider widget to the ON position. The Accessibility screen should look similar to the next figure.

Configuring Tasker accessibility access

Now that all the pieces are in place, we’re ready to fire up the applications and let our ears do the work.

Ready to Rock

Put on your favorite headphones, check your Android volume setting, and launch Moon+ Reader Pro. Load up your favorite reading material (such as this month’s issue of PragPub) and select the speaker icon to start TTS playback. Return to the Android home screen and you should discover that Moon+ Reader Pro continues reading in the background. Launch your favorite Android music player (such as Poweramp) and load up your favorite playlist.

I find that acoustic instrumental music works best. Otherwise, spoken word will clash with singing word, making it hard to concentrate on either. One of my personal favorite artists I frequently listen to is Sweetgrass recording artist Philip Aaberg. Check out his works on the Sweetgrass Music website.

Playing Live from Montana

With the book being read aloud and the music playing in the background, you will happily discover just how much easier it is to listen to TTS renderings, especially when coupling the IVONA voices with instrumental music. Pocket your phone and learn on the go. Of course, you’ll hear a chime and the Google TTS voice kick in whenever you receive a new email message, Tweet, Facebook post, download, or anything else that happens to use the Android notification area to display new information. However, you will never again have to go digging for your phone the next time a new message arrives.

Here’s one more tip to consider. While the stock Android mail application works well, it only notifies that you have received an email; but it doesn’t post the subject of the email message in the notification area. This can be solved by using a popular alternative free email client called K-9 Mail.

K-9 Mail not only posts the subject line to the notification area but can also be automated by Tasker. K-9 Mail also supports a number of other enhancements not found in the stock Android mail client, such as multiple themes and identities, GPG/PGP encryption, keyboard shortcuts, WebDAV support, and more. It’s also entirely open source, with its code repository available on Github.

I encourage you to download a sample audio session of the full listening experience here.

In addition to the PragPub sample rendering and Philip Aaberg’s composition called High Plains playing in the background, the sample also features an inbound email message alert and a talking clock with battery status. Check out my latest book, Developing Android on Android published by Pragmatic Bookshelf, to learn how to build your own talking clock and battery status indicator using Tasker.

While this audio configuration is immensely rewarding and is an example of cutting edge technology in action, there are currently a few limitations. For example, you can pause either Moon+ Reader Pro or the music player with an assigned button press on your headset, but you can’t pause both applications at the same time. That’s because Android can only focus on one audio application at a time.

However, a crafty reader might be able to come up with a Tasker task that can do this reliably. Another constraint is while you can listen all you like to books, music, and messages, you can’t respond to them yet. However, features such as the always on, always listening “OK Google” voice trigger found in Google Glass and some smartphones are a hint of things to come on the Android platform. Eventually you will be able to have an ongoing vocalized conversation with your smartphone. But for now: it’s a one-way communication stream... and a very cool one at that!

Mike Riley is the author of several Pragmatic Bookshelf titles. You can contact him at mike@mikeriley.com or follow him on Twitter @mriley.

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

Clojure and EDN

Closure’s Data Storage and Interchange

by Michael Bevilacqua-Linn

Tagged elements to the rescue

Earlier on, we took a look at Clojure’s reader and saw how it plays a part in Clojure’s powerful macro system. The reader can also be used for the more mundane, but important, task of data storage and interchange. In this way, the reader and the format that it reads can be used much like JSON or YAML.

As a quick refresher, let’s take a look at the reader in action. Here, we use it to read a string that represents a map and retrieve the value for one of its keys.

| => (def foo-map (read-string "{:foo 42 :bar 99}"))
| #'EDNExamples/foo-map
| => (:foo foo-map)
| 42

We could have just as easily read that map from a file stored on disk, or as input from a web service.

In Clojure, it’s common to use a subset of Clojure syntax rather some other format, like JSON, YAML, or XML. This has a few benefits. We don’t need a third party library to parse our data interchange format, and we can be sure that the values represented map cleanly to data structures in the language. In addition, it can be used as part of a streaming format, and because there’s no top level element as there is in XML, forms can be read in one at a time.

Finally, one of the biggest benefits is that Clojure has a simple mechanism for extending its syntax: tagged elements. This is extremely useful for data interchange, as we’ll see a bit later.

However, it’s not all roses. One of the main downsides is that reader syntax is Clojure-specific. While other languages could certainly implement full-on Clojure readers, the reader syntax is really an implementation detail of the Clojure language.

To solve this problem, Clojure’s maker, Rich Hickey, created a spec that details the subset of Clojure’s syntax useful for data interchange.

The full spec can be found here: . It specifies how to represent all the core Clojure data types like strings, integers, vectors, lists, and so on but omits the parts that aren’t necessary, like syntax quote and the @ symbol for dereferencing. So it’s possible to create libraries in other languages that implement just the necessary parts of Clojure’s reader syntax.

Since EDN is just a subset of the Clojure syntax we’ve already experienced, it should be pretty familiar. However, there’s a problem with using the built-in reader as we’ve done in our example. It’s not designed to take input from untrusted sources, so it could be used to execute malicious code.

For instance, Clojure has a simple way to spawn a shell in the clojure.java.shell library. Here, we use its sh function to run the shell command ls. It returns the exit code and the contents of standard out and standard error in a map.

| => (clojure.java.shell/sh "ls")
| {:exit 0, :out "README.md\nbin\nproject.clj\nsrc\ntarget\ntest\n", :err ""}

With just a bit of effort, we can make read-string execute the same code:

| => (read-string "#=(clojure.java.shell/sh \"ls\")")
| {:exit 0, :out "README.md\nbin\nproject.clj\nsrc\ntarget\ntest\n", :err ""}

Listing the contents of my working directory is fairly benign and boring, but we could have just as easily had our code delete files or other arbitrary badness.

To get around this, Clojure provides a specialized reader for reading EDN from unsafe sources. It lives in the clojure.edn namespace, and consists of a read function to read from a string and a read-string to read from a string, much like the standard reader.

Here we use the specialized EDN reader to attempt the same trick we tried earlier, but no dice!

| => (edn/read-string "#=(clojure.java.shell/sh \"ls\")")
| RuntimeException No dispatch macro for: =
| clojure.lang.Util.runtimeException (Util.java:219)

The EDN reader keeps us safe from any of the Clojure features that would allow us to execute arbitrary code, while still allowing us to use the ones that are useful for conveying data:

| => (def foo-map (edn/read-string "{:foo 42 :bar 99}"))
| #'EDNExamples/foo-map
| => (:foo foo-map)
| 42
| => (def foo-vector (edn/read-string "[1 2 3 4]"))
| #'EDNExamples/foo-vector
| => (foo-vector 0)
| 1

This works well for the rich set of data structures that Clojure provides, but what happens when you need to create your own custom data? For that, EDN provides tagged elements.

The syntax for a tagged element is the hash character (#) followed by a symbol. Whatever value that comes after the tag is created by a custom handler that’s registered to handle the tag. The handler takes as input whatever value follows the tag. This might seem a bit obtuse, so let’s look at a concrete example.

Aside from the core EDN data elements, cribbed from Clojure’s core data types, EDN has two built-in tagged elements, one for instants in time, #inst and one for UUIDs, #uuid. In the following snippet, we use the the#inst tagged element to read in a timestamp.

| => (edn/read-string "#inst \"1999-12-12T23:00:00.00Z\"")
| #inst "1999-12-12T23:00:00.000-00:00"

As we can see, this creates a java.util.Date rather than a string.

| => (type (edn/read-string "#inst \"1999-12-12T23:00:00.00Z\""))
| java.util.Date

Behind the scenes, Clojure’s EDN reader recognizes #inst as a tagged element. It then reads in the next value, which happens to be a string, and passes the string to a custom handler which converts it into a java.util.Date .

Clojure programmers can add their own custom tags and handlers.

Let’s take a look at a simple handler that converts from a comma-separated name format "Last, First”, to a simple map based format, {:first-name "First", :last-name "Last”}.

| (defn read-cs-person [cs-person]
| (let [parts (string/trim (string/split cs-person #","))]
| {:first-name (parts 1) :last-name (parts 0)}))

The function splits a string on commas, trims any whitespace, and puts the parts into a map. Here we see it in action:

| => (read-cs-person "Linn, Mike")
| {:first-name "Mike", :last-name "Linn"}

Now, we need to let the EDN reader know about our custom handler. First, we need to create a map from our tagged elements to the handler functions that process them. Custom tagged elements must be represented as fully qualified symbols. Below, we create a map that will handle the tagged element #mblinn/cs-person using the read-cs-person function we created above.

(def custom-readers {'mblinn/cs-person read-cs-person})

Now we can pass in our custom readers using an optional first argument to read-string. This argument takes a map of options, one of which is the map of custom readers we created above. Here, we call read-string passing in the custom readers, and a name in the proper format.

| => (edn/read-string {:readers custom-readers}
| "#mblinn/cs-person \"Linn, Michael\"")
| {:first-name " Michael", :last-name "Linn"}

As we can see, the custom reader function is called, and our string is transformed into the appropriate map.

This extensibility allows the creator of a data format to define their own custom extensions to the base format, along with the appropriate semantics and libraries to parse them.

That’s it for EDN! Join us next time as we take a closer look at Clojure’s sequence abstraction, and the libraries that we can use to work with it.

Michael Bevilacqua-Linn has been programming computers ever since he dragged an Apple IIGS that his parents got for opening a bank account into his fifth grade class to explain loops and variables to a bunch of pre-teenagers. He currently works for Comcast, where he builds distributed systems that power infrastructure for their next generation services, and wrote Functional Programming Patterns. He tweets occasionally at @NovusTiro.

Leveraging Retrospectives

You Have to Look Back in Order to See Ahead

by Jeff Cohen

Retrospectives are not just for teams.

As developers and managers, most of us are always on the go. We’re focused on the next project, the next deadline, the next client. Always looking forward.

Is it ever worthwhile to look back?

I think it is. You’ve heard it said that “hindsight is 20/20.” The infamous “learn from your mistakes.” And of course, “if you don’t know your history, you’re doomed to repeat it.”

But if you’re like me, these phrases remain solidly in the realm of theory and cliché. Let’s face it, it’s not always fun to look back. So we prefer to simply focus on the here and now, believing we will somehow do better next time.

We disregard the value of looking back because we think that’s all it is: looking back.

Hindsight is indeed 20/20, but it also sharpens our picture of the future. If you want to improve something—whether it’s your product, your team’s performance, or your career—you have to look back in order to see ahead.

What Is a Retrospective?

Baked deep into the brain of every Agile team member is the notion of continual improvement. Agile isn’t really about delivering a perfect product as much as it is about delivering a perfect process. It’s about finding ways to improve software outcomes in small steps, and on a continuing basis. The sprint (usually about 2-3 weeks in length) becomes the team’s official unit of time. The team is expected to deliver improved software with each tick of the clock.

Agile teams have a menu of choices when it comes to sprint activities. In addition to coding, teams can incorporate daily stand-ups, estimation meetings, prioritization, release planning, and team retrospectives. These activities are supposed to be the structural beams that undergird the team’s communication and process flow.

If you’re new to the notion of a “retrospective,” it’s simply a designated time at the end of each sprint for the team to take a breather and reflect on the work that’s been done. Together, the team discusses ways in which they would like to improve the next sprint.

But I have found that retrospectives aren’t just for teams. I want to share a brief summary of my personal spin on the team retrospective format, and then describe how I’ve successfully adapted it for improving student outcomes in classrooms, and for personal career growth.

For Agile Development Teams

Retrospectives are strange things. They can be more of an art than a science. Some teams do retrospectives religiously, but for whatever reason, fail to improve from one sprint to the next. Others might begin a project with enthusiasm for retrospectives, but give them up soon after. In the hustle and bustle of a software project, where team members are already loaded to the max with a thousand chores and responsibilities, retrospectives can lose out to other, seemingly higher priority activities.

And that’s a shame. I believe dropping the retrospective is actually the second-worst thing an agile team can do (the first would be dropping the daily stand). If agile is all about continuous improvement, removing the team retrospective almost guarantees the team won’t improve at all. The value gained from a 30-minute conversation once or twice a month far outweighs the perceived cost in time.

Teams that don’t do retrospectives have lost sight of their value. Rather than using retros as a safe place for the team to come together and come up with honest solutions to real problems, they can slip into a blame game. Retrospectives should be enjoyable and insightful. A time for the team to kick back and reflect, be transparent, and make observations.

So let’s get back to basics and common-sense empiricism. If you’ve had bad luck running retrospectives on your team, or never tried them before, here’s a technique that I think will get you off to a good start: the four-quadrant poster. Here’s what it looks like:

Team Board

It’s a simple process. Start with food. Everybody likes food. Then, get this poster up on a wall or projected onto the screen. Everybody takes turns shouting out one-sentence retrospective items that fall into one of these four categories.

Start: Something that you think the team should start doing.

Stop: Something that you think the team should stop doing.

Continue: Something that you think the team should keep doing.

Aha: An insight gained from the previous sprint, no matter how small or how large.

The idea isn’t to come up with as many items as possible. That tends to result in people reaching for things to say that aren’t very important. I have found that most of the time, there will be one or two items from each category that provide real eye-opening value. Time-box your retrospective sessions to 30 or 60 minutes. Don’t let the retrospective devolve into a long problem-solving session. If there’s an item that seems to warrant its own discussion, ask the team if it’s worth a separate meeting for that item. Usually, the threat of another meeting motivates the team to find common ground quickly.

Keep your quadrant poster in a place that’s always visible, as a constant reminder of the ways in which a team has agreed to improve. Remember that thing about not letting history repeat itself? That will happen if people forget what was agreed upon in the retro. Your team will find it encouraging as they witness the evolution of the retrospective quadrants from one sprint to the next.

For Career Growth

The value of the retrospective can be so powerful that it’s worth exploring how it can go beyond the classical agile team setting. I’d like to spend the rest of our time describing two ways in which I have extrapolated it into two other meaningful scenarios: for personal career growth, and in the classroom.

Do you feel like your career isn’t headed in the direction you would like? Perhaps you think you’re headed down the right road, but you wish you could press the accelerator a bit harder?

One of the easiest things you can do to change either your direction or speed is to do a simple career retrospective. I do this for myself once a year, at the same time every year. I do it whether I’m thrilled with my job or not. You might find that every six months is a better cadence, but every month is probably too much. Steering a career can be a bit like steering an aircraft carrier. You can’t always expect to do a U-turn on a dime. Think ahead, and begin your course corrections early. Even a small turn in direction will, over time, result in a large difference in your ultimate destination.

My goal is to try to sum up my current level of satisfaction in a way that can both bring meaningful change, but also remind me of the good things that I might be taking for granted. Without reflection, it’s easy for me to take what I have for granted.

So every time I do a personal retrospective, I consider these things about my current job:

Inputs: Am I being required to use my full brain in a challenging fashion? Or am I just doing the same things over and over? Am I working with colleagues whom I can learn from?

Outputs: Am I getting the results I want? Do I like explaining the effects of my job to my friends and family? Am I helping others? Am I gradually becoming an authority in at least one area? Does my compensation reflect the value I bring to the company?

I find it helpful to graph my feelings, and compare graphs from one year to the next. Here are some example data points I use, graphed on a rough scale of 1-10 for each:

Mission: To what extent am I excited about the company mission?

My Role: To what extent do I like my role within the organization?

Compensation: Is my compensation at a fair amount?

Physical environment: is the workplace conducive to work? Do I enjoy coming into the office?

Culture: Do I feel the culture around me is healthy? Are risks encouraged? Are individuals wrongly blamed when something goes wrong? Is there too much politics instead of honest communication? Are people enjoying themselves and their coworkers?

Check out my Career Board.

Career Board

Plot each of these and connect the dots into a rough curve. You’re not going for detailed accuracy, just a general description. I think you’ll find it a great way to describe how you feel about your current situation.

But perhaps best of all, your retro curve will act as a spotlight, shining light directly on the areas you can choose to focus on for positive change. Ask yourself what it would mean to move every data point up to a 10. Showing your retrospective graph to your boss can be a great way to get an open dialogue started.

In Educational Settings

Finally I’d like to describe how to use a retrospective in a classroom setting. As Chief Instructor of The Starter League in Chicago, I’ve taught about 20 distinct sections of our beginner-focused Web Development course for non-programmers. At the beginning, I knew I wanted to incorporate the concept of retrospectives into the classroom, but I wasn’t sure how. I tried many different formats and experiments, converging on a simple technique that I think every teacher, regardless of subject area, can put into practice. I call it the Aha/Fuzzy board, and it looks like this:

Aha/Fuzzy Board

Here’s the process I use. At the end of each week, I put up the Aha/Fuzzy Board, and for ten minutes students shout items that should go on the board. An “Aha!” is one thing that a student learned that week. One light-bulb. A moment of clarity, no matter how small. In my class, it might be “I know how to put a border around an image!” or “I finally understood how to use the .each method” or “A hyperlink isn’t a magical thing to me anymore.” I encourage students to jot these aha moments down throughout the week so they can be ready for our Friday sessions.

A “Fuzzy” item is anything we’ve covered that’s still, well, fuzzy. Examples are “I still don’t get what a class method is” or “CSS floats never work right for me.”

After ten short minutes, the two columns are full, and we have a goldmine of information. Actually we have two goldmines: one for the students, and one for me!

For the students, the mere act of identifying ahas and fuzzies forces them to reflect on their learning. It’s very easy for students to take for granted what they’ve learned and be discouraged by the most recent challenge. It’s empowering when we can call them out by name.

Sometimes when we start the retro process, there’s silence. No one can think of any Aha moments. Then, finally, one student will break the ice, mentioning one thing they’ve learned that week, no matter how tiny. Then, another student chimes in. Pretty soon it’s an avalanche. Hearing their peers identify the things they’ve learned is so helpful to all the other students. It jogs their memory, and reminds them that even though they might presently be stuck on a problem, they shouldn’t forget all the great things they’ve accomplished so far. And when they identify Fuzzy items, they’ve instantly put their finger on what they should be learning next. Students struggle when they’re not sure where they stand. They can be unsure of where to spend their time. With the Aha/Fuzzy board, it becomes immediately clear what they need to go back and study, and what they don’t.

As the instructor, I find that the Aha/Fuzzy board provides fantastic feedback on how I’m doing as a teacher. I can quickly find out which of my lessons took root, and which did not. Aha moments point to lessons that were crafted well; fuzzies tell me which topics I might want to spiral on again next time. The board gives me food for thought on how to plan the next week.

Moving Forward

For me, taking time to reflect has been vital. It’s been like getting Lasik for my teams, my career, and my classroom.

But these three retrospective boards are just the ones that I use. I’d love to hear how you use retrospectives and how you go about them. Find me on twitter, @jeffcohen, or email me anytime at jeff@starterleague.com.

Jeff Cohen teaches agile web development at The Starter League in Chicago, the University of Chicago and Northwestern University. He is co-author of the book Ruby on Rails for .NET Developers, published by Pragmatic Press in 2008; speaks at a variety of technical conferences throughout the year; and is a Ruby on Rails contributor, teacher, and writer.

He believes in agile software strategies, project-based learning, and opening the world of computer programming to folks from all walks of life, by curating an inclusive, beginner-friendly classroom culture and curriculum.

Jeff started learning computer programming in high school in the mid-1980s by using BASIC on a Commodore PET-32. He then learned 6502 Assembly, Pascal, C, C++, Prolog, PL/1, and a variety of Microsoft architectures including MFC, ATL, and .NET for both Windows-based desktops and ASP.NET web applications. In 2005 he ventured into open source languages and communities, focusing on Ruby and the Rails framework.

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

The Roots of Revolution

Two Stories from Personal Computing’s Early Days

by Michael Swaine and Paul Freiberger

The counterculture of the 1960s definitely influenced the personal computer revolution. Exactly how is complicated.

Walter Isaacson, who wrote the Jobs book, is currently working on a book on the innovators of the digital age. One of the themes he’s stressing, apparently, is the influence of the 60s counterculture on the development of the personal computer. John Markoff tackled the subject insightfully at at length in What the Dormouse Said. And it was a major theme of Fire in the Valley, the history of the personal computer that Paul Freiberger and I started writing back in 1982 and have been tweaking off and on ever since.

But as we’ve been revising our book for its upcoming third edition, it’s becoming increasingly clear that this particular theme is anything but clear. The influence of the 60s counterculture is real, but it’s also more complicated than anybody has articulated, or will ever articulate, probably. Talking to people who lived through those days, we are constantly reminded that the influence we keep seeing was a personal thing for each individual. Which suggests that you can get a better sense of this influence from the story of an individual. Here are two stories, then, about one individual, who was both a child of the 60s and a legend of the personal computer revolution.

Mitch Gets Rich

The industry that IBM was preparing to enter in 1981 was a curious environment, with its own set of values, its own culture, even a kind of mythology.

The story of VisiCalc was a legend in the personal computer industry. Indeed, VisiCalc’s success was one of the chief arguments for it being an industry, rather than merely a market for hobby equipment.

By 1981, it seemed that anyone who had any connection with personal computers could tell you how Dan Bricklin had come up with the idea for the first spreadsheet program while studying business in graduate school at Harvard; how he had recruited old MIT computer science classmate Bob Frankston to develop the program; how they had formed Software Arts; and how in April 1979, Software Arts had contracted with Personal Software (which was a respected personal computer software firm at the time, even if it was just Dan Fylstra and his fiancee selling software out of an apartment) to market their program VisiCalc. And how VisiCalc, developed initially for the Apple II, was a runaway success and became Personal Software’s top seller, running up 1000 unit sales in two years, truly impressive for the time. What Bricklin had invented was a thing of beauty. Not the VisiCalc program itself, but the spreadsheet paradigm. That was the invention, that sliding window on an infinitely large blackboard. The grid of cells whose values can be dependent on one another. The whole idea of doing math in two dimensions. The things left out, or worked out, of the design. The truly uncluttered simplicity of the concept.

And invention was, in those days, what sold.

David Reed, who worked for Software Arts later on, summarized the basic fact of market position back then: “The first generation of product was what succeeded. If something new came along, you could just find gobs of new people to try the thing.”

Reed put it in terms of products and markets, but products can create markets, and in the early days of the PC industry that was more often than not the case with successful products. The success of the first product in a market wasn’t always just a matter of somebody filling an existing niche first. It was sometimes a matter of creating the niche, of inventing a new kind of thing in the world.

When the early personal computer customers were snapping up these new things, they were buying inventions, and rewarding inventors. There was, in those giddy days, often a close conversation between the inventor and the market.

And the spreadsheet was indeed an invention, more so than many software gadgets that have subsequently been granted patent protection. Which made Bricklin’s deliberate decision not to try to patent the spreadsheet concept all the more significant. It left the door open for enhancements to the concept and for the kind of iterative collaboration that in those days fueled software development.

Or it can be put this way: Bricklin’s decision opened the door for Mitch Kapor. The Kapor story, though, starts much earlier—in the 1960s.

The kid, as anyone could see, had promise. There was that computer he built as a science fair project in junior high. All right, so it was really just an adding machine with a rotary phone dial for input. Still, how many kids would even have thought of building a computer in 1964?

He was given every encouragement to live up to that promise. His dad, a successful small business owner, discouraged Mitch from thinking about business as a career. A college professor—that was a worthwhile goal for the bright young kid from Boston. His school gave him every encouragement, too; it offered a course in computer programming, which was highly unusual for a high school in the 1960s. Add to that the National Science Foundation-sponsored enrichment courses in the summer, classes at Columbia University on weekends....

Then, in 1967, came graduation. And along with it a few other things.

It was the Summer of Love, the flowering of Haight-Ashbury in San Francisco, the release of the Beatles’ Sgt. Pepper album. Mitch was going to Yale in the fall, but that summer his mind was 3000 miles away, his event horizon a week out, and his priorities more or less sex, drugs, and rock ’n’ roll.

His parents were not happy.

Oh, Mitch was the good son; he did the Yale thing, got the degree. And he had some further encounters with computers along the way, which both intrigued and frustrated him. He went on to graduate school. But the culture of the 1960s had gotten inside Mitch Kapor.

In the 1960s, dropping out was a viable option. You could live on the fringe, not being a visible blip on the economic radar screen but not starving either. Kapor may have made $12,000 one of those years, but generally it was less. He was drifting, directionless, an “intellectual gypsy” as he later characterized that period of his life. He drifted into teaching transcendental meditation, into a stint as a disc jockey, into work as a counselor in a mental hospital, and into and out of a marriage.

Closing in on 30 years old, low on cash, and without direction, he seized on an old fascination. Pawning his stereo, he bought an Apple II computer and started programming. He became a BASIC hacker.

It was at this point that the random walk of Mitch Kapor’s life intersected the vector of VisiCalc’s success.

Kapor’s relationship with programming was schizoid: he was fascinated with the cleanness and the orderliness of what computers could be made to do, but he was also exasperated whenever he tried to make them do it. He didn’t think he was a very good programmer. He persevered, though, and got good enough that he was able to complete a program that worked with VisiCalc spreadsheets to plot and analyze spreadsheet data.

He had done a good enough job, in fact, that he was able to interest Personal Software. Dan Fylstra, who was flush with cash from sales of the very successful VisiCalc, was looking for new products, and Mitch pitched his creation as a product to fill out a “Visi” product line for Personal Software. He called it VisiPlot/VisiTrend. Mitch went to work for Personal Software for a few months but wasn’t happy when a new management team arrived. In place of equity in the company, Fylstra gave him $1.2 million for his software.

Mitch Kapor, ex—transcendental meditation teacher, didn't actually need $1.2 million, nor did he know quite what to do with it. Finally he decided to start a company. It wasn’t what his father, a businessman who had always wanted his son to become a professor, wanted. For that matter, it wasn’t terribly consistent with Kapor’s own 1960s anticorporate values. He reasoned that having his own company would allow him to do what he wanted, while putting enough money in his pocket so that he wouldn’t feel like a drifter.

He called the company Micro Finance Systems, and its first product was to be called Executive Briefing System. Its trick was to take a graph or plot and organize it into a presentation. It borrowed some of its look and feel from Kapor’s VisiPlot. Mitch conceived and designed the product, but this time he got programming help: a teenaged hacker named Todd Agulnick coded Executive Briefing System. Kapor would later write cogently about his notion of the role of the software designer, as opposed to the role of the programmer, in the development of a software product, but in the early days of Executive Briefing System he was less clear on the concept. He did know, though, that he wanted a better programmer than himself writing his software.

Shortly thereafter, Kapor changed the company name to Lotus Development Corporation, in honor of his days as a transcendental meditation teacher. This was before Executive Briefing System ever shipped. In fact, the product barely shipped at all. Although some sales of Executive Briefing System apparently showed up on the balance sheet during second-round venture financing for Lotus, Kapor never made much effort to sell the product, soon dropping it altogether to put all the Lotus eggs into a different basket.

The inspiration for the second product was a chance meeting at an Apple II user group with a seasoned professional programmer named Jonathan Sachs.

Sachs had his own software company, Concentric Data Systems. Not long before, Sachs had been in charge of a team of programmers writing an operating system at Data General, a minicomputer company, and before that had spent more than a decade studying and developing software at MIT. Concentric was a tiny venture. It was a consulting firm that consisted of Sachs, who was trying to create products, and John Henderson, his former boss at Data General, who was bringing in the real money with contract programming. Together, they wrote a technically spiffy but strategically disastrous spreadsheet for Data General hardware that did nothing for Concentric’s bottom line and contributed greatly to the breakup of their partnership. When they split, they held joint custody of the spreadsheet. Sachs hooked up with Kapor and set to work reimplementing the spreadsheet in the C programming language for a machine with a Z80 microprocessor.

It was soon clear that two things needed to change: programming in C was inefficient compared to working in assembly language, and the Z80 was not the platform of the future. When the IBM PC was released in August 1981, Kapor and Sachs had no doubt what the platform of the future was, and changed direction rapidly.

Out went the C code and the plans for the Z80 implementation. Out went the powerful embedded programming language that Sachs liked. And what had been a simple spreadsheet soon became a three-function program. Mere spreadsheets had been done, Kapor argued; integrated software was the trick. Their program would combine the functions of spreadsheet, graphics, and word processing in one integrated program. And because it did more, Kapor explained, they could charge more for it.

Making money was not the prime motivation behind the increasingly frenetic activity at Lotus, but somewhere along the way it occurred to Kapor that one could make a lot of money on this stuff, which, he decided, would be a “good thing.” Somewhere around this time it also occurred to him that the marketing strategies of current software companies were a little on the quaint side. If personal computer software was going to be a serious business—and the $1.2 million Fylstra had paid him felt pretty serious to him—marketing strategies would have to change.

Meanwhile, Sachs coded. He worked furiously, and he worked at home, coming to the office once a week to run the latest accomplishments past Kapor and get feedback. They were up against a deadline, but they didn’t know what it was. When IBM released its personal computer, whenever that happened, their window would open up. There was no telling how long it would be open.

As Sachs honed the program into a product with Kapor’s design feedback, the original three functions of spreadsheet, graphics, and word processing changed into spreadsheet, graphics, and database management. The word processor component proved just a little too hairy to implement. That turned out to be a nice choice, though: the database capability fit better with the other capabilities. And it was still a three-function program, which Kapor thought was important. They decided to play up the three functions in the product’s name, and called it Lotus 1-2-3.

Abruptly, in 1981, the window of opportunity for this product opened wide and the pace picked up. IBM introduced its PC, and Kapor immediately started talking up Lotus 1-2-3 to potential investors and buyers.

Kapor thought that one potential buyer would be Dan Fylstra, who had already bought his VisiPlot/VisiTrend. Fylstra knew Kapor well and had the money and the market position. Personal Software was at this point the largest personal computer software company, having just grossed $ 12 million that year. But Fylstra passed on the idea, wishing Mitch well.

One potential investor in Kapor’s product was venture capitalist Ben Rosen. Kapor pitched Rosen on this integrated spreadsheet, database, and graphics program that could take advantage of the IBM PC’s 640K RAM. He also pitched him the company. Lotus Development Corporation was going to be a serious software powerhouse.

Rosen didn’t pass on the idea. He kicked in the $1 million seed capital in 1982 to get Lotus Development Corporation off the ground. In April 1982, Lotus was up and running, with eight employees and one product under development. Six months later, in October 1982, Lotus announced 1-2-3 at the Windows on the World restaurant in New York City’s World Trade Center. There was major press attendance, and a story about it appeared in the next day’s Wall Street Journal.

Rosen delivered another $3.8 million in December. This was unheard of. In terms of investment, in terms of rolling the dice and sheer chutzpah, they were all in unexplored territory here. Nobody had put that kind of money into a personal computer software company before. Certainly not into one whose entire sales record consisted of a few copies of Executive Briefing System sitting on a store shelf in West Hartford, Connecticut.

The selling of Lotus 1-2-3 was a remarkable gamble. It was handsdown the biggest marketing blitz to date in the short history of the personal computer industry. To run the campaign, Kapor hired consultants McKinsey & Company, and McKinsey & Company assigned a new hire by the name of Jim Manzi to the job.

Lotus 1-2-3 hit the stores in January 1983. It sold more than 2000 copies in its first year. It took over the top of Softsel’s bestseller list by April and held it for the rest of 1983. That year, the product brought in $53 million in sales to Lotus, making a nice return on Ben Rosen’s $4.8 million investment.

Manzi, the campaign’s hero, joined Lotus as marketing director in May. He took out ads in The Wall Street Journal, a radical move given the skepticism with which personal computers were greeted in corporate circles. In three years, sales went to $300 million. Lotus 1-2-3 took the spreadsheet concept right to its intended audience of business users. Businesses liked 1-2-3, and they liked the company that made it. Lotus Development Corporation, alone among personal software companies, looked to the business community like a real business, not a bunch of lucky hackers.

Along the way, the lucky hacker who invented it learned that what he was selling was a spreadsheet. Silly him; he thought it was integrated software.

That’s one story about Mitch Kapor. Now here’s another.

Mitch Moves On

At the height of his power and influence at Lotus Development Corporation, Mitch Kapor walked away from it all. Lotus had grown large very quickly. The first venture capital arrived in 1982, Lotus 1-2-3 shipped in January of 1983, and that year the company made $53 million in sales. By early 1986, some 1300 people were working for the company.

Working for Mitch Kapor.

It had grown too fast. It was out of control, and it was overwhelming. Rather than feeling empowered by success, Kapor felt trapped by it. It occurred to him that he didn’t really like big companies, even when he was the boss.

Then came a day when a major customer complained that Lotus was making changes in its software too often. That it was, in effect, innovating too rapidly. So what were they supposed to do, slow down the pace of innovation? Exactly. That’s what they did. It was perfectly logical, and met the needs of that customer—and probably of other customers. Kapor didn’t really fault it as a business decision. But what satisfaction was there in dumbing down your company?

Lotus just wasn’t fun any more. So Kapor resigned. He walked out the door of Lotus and never looked back.

This act left him with the question: what now? After having helped launch a revolution, what should he do with the rest of his life? He didn’t get away from Lotus clean. He spent a year completing work on a Lotus product called Agenda while serving as a visiting scientist at MIT. After that, he jumped back in and started another firm, the significantly smaller On Technology, a company focusing on software for workgroups.

And in 1989, he began to log on to an online service called The Well. The Well, which stood for Whole Earth ’Lectronic Letter, was the brainchild of Stewart Brand, who had also been behind The Whole Earth Catalog. The Well was an online community of bright, technosavvy people.

“I fell in love with it,” Kapor said later, because “I met a bunch of people online with similar interests who were smart that I wanted to talk to.” He plunged headlong into this virtual community.

One day in the summer of 1990, he even found himself on a cattle ranch in Wyoming talking computers with a former lyricist of the Grateful Dead.

What led to that unlikely meeting was a series of events that bode ill for civil liberties in the new wired world. A few months earlier, some anonymous individual, for whatever motive, had “liberated” a piece of the proprietary, secret operating system code for the Apple Macintosh and had mailed it on floppy disks to influential people in the computer industry. Kapor was one of these people. John Perry Barlow—the former Grateful Dead lyricist, current cattle rancher, and computer gadfly—was not. But apparently because Barlow had attended something called The Hacker’s Conference, the FBI concluded that Barlow might know the perpetrator.

This Hacker’s Conference was a gathering of gifted programmers, industry pioneers, and legends, organized by the same Stewart Brand who had launched The Well. Hacker in this context was a term of praise, but in society at large it was also coming to mean “cybercriminal”—that is, one who illegally breaks into others’ computer systems.

An exceptionally clueless G-man showed up at Barlow’s ranch. The agent demonstrated his ignorance of computers and software, and Barlow attempted to educate him. Their conversation became the subject of an entertaining online essay by Barlow that appeared on The Well.

Soon after, Barlow got another visitor at the ranch. But this one, being the founder of Lotus Development Corporation, knew a lot about computers and software. Kapor had received the fateful disk, had had a similar experience with a couple of clueless FBI agents, had read Barlow’s essay, and now wanted to brainstorm with him over the situation.

“The situation” transcended one ignorant FBI investigator or a piece of purloined Apple software. The Secret Service, in an operation they called “Operation Sun Devil,” had been waging a campaign against computer crime, chiefly by storming into the homes of teenaged computer users at night, waving guns, frightening the families, and confiscating anything that looked like it had anything to do with computers.

“The situation” involved law enforcement agencies at various levels responding often with grotesquely excessive force to acts they scarcely understood. It involved young pranksters being hauled into court on very serious charges in an area where the law was murky and the judges as uninformed as the police.

Barlow was eager to brainstorm with Kapor about the situation. It did not escape their notice that they were planning to take on the government, to take on guys with guns.

What should they do? At the very least, they decided, these kids need competent legal defense. They decided to put together an organization to provide it. As Kapor explained it, “There was uninformed and panicky government response, treating situations like they were threats to national security. They were in the process of trying to put some of these kids away for a long time and throw away the key, and it just felt like there were injustices being done out of sheer lack of understanding. I felt a moral outrage. Barlow and I felt something had to be done.”

In 1990, they cofounded the Electronic Frontier Foundation (EFF). They put out the word to a few high-profile computer industry figures they thought would understand what they were up to. Ex—blue boxer Steve Wozniak kicked in a six-figure contribution immediately, as did Internet pioneer John Gilmore.

Merely fighting the defensive battles in the courts was a passive strategy. EFF, they decided, should play an active role. It should take on proposed and existing legislation, guard civil liberties in cyberspace, help open this new online realm to more people, and try to narrow the gulf between the “info-haves” and the “info-have-nots.”

The pace picked up when they hired Mike Godwin to head their legal efforts. “Godwin was online a lot as he was finishing law school at the University of Texas,” Kapor remembers. “I was impressed by him.”

EFF evolved quickly from a legal defense fund for some kid hackers to an influential lobbying organization. “In a way it was an ACLU of cyberspace,” Kapor now says. “We quickly found that we were doing a lot of good raising issues, raising consciousness [about] the whole idea of how the Bill of Rights ought to apply to cyberspace and online activity. I got very passionate about it.”

By 1993, EFF had an office in Washington and the ear of the Clinton administration, especially Vice President A1 Gore, who dreamed of an information superhighway analogous to his father’s (Senator Albert Gore, Sr.) favorite project, the interstate highway system. Other organizations were also addressing the issues, such as Computer Professionals for Social Responsibility, which EFF was now partly funding.

Despite EFF access, Clinton administration policy often proved a mere shadow of activists’ expectations, or flouted them altogether. The activists began saying that EFF had sold out.

Kapor may have agreed. “The first major change was when we opened the Washington office and decided to get involved in advocacy work inside the Beltway. That was an educational, if unsuccessful, experience. We wound up being co-opted by Beltway politics rather than changing it.”

The Digital Telephony Act, for example, was not in line with the principles of the organization or what the board wanted. “Wired [magazine] ran a piece about how EFF blew it. On reflection, I agree that we weren’t skillful enough to maintain our principles and be effective. And as a result, we neither kept our principles nor were effective.”

So EFF moved out of Washington and did some soul-searching.

Later, Kapor said, “It’s a little street theater, a little advocacy, a little consciousness raising. And in projects like [those] it continues to be effective.”

He himself moved on to other things. He chaired a commission to investigate and report on the problem of computer crime in Massachusetts. He served on the Computer Science and Technology Board of the National Research Council and the National Information Infrastructure Advisory Council. And he taught classes about software design, democracy and the Internet, and digital community at MIT.

But Kapor hasn’t lost interest in the human issues raised by technological change. As more and more of humanity’s work, play, and intellectual activity move onto the Net, the key issues have become privacy, freedom of speech, security, access, and the locus of political decision making.

“We have to figure out as a culture how to make [the Internet] a place where one would want to spend one’s time. What are the rules of the road? Where’s the power? Classical issues about free speech. What’s the appropriate role for state action? What ought the boundaries be? Those are issues we’ve faced for hundreds of years, and we’ll continue to face in changing circumstances.” They are the issues that engage Kapor these days.

Paul Freiberger and Michael Swaine wrote Fire in the Valley, the seminal history of the personal computer and the source for the movie Pirates of Silicon Valley. This article emerged from the work they are doing to produce the upcoming Third Edition of the book, to be published this year by the Pragmatic Bookshelf. Send the authors your feedback or discuss the article in the magazine forum.

Pragmatic Bookstuff

Here’s what’s up with the Pragmatic Bookshelf and its authors.

It’s a new year! Time to stop by your auto repair shop and pick up a new wall calendar. Or better yet, stop by the Pragmatic Bookshelf site and see what’s new and exciting. Here’s what they’ve released recently.

Recently Released:

Crafting Rails 4 Applications: Expert Practices for Everyday Rails Development

Raspberry Pi: A Quick-Start Guide (2nd ed)

The Agile Samurai (audio book)

Programming Google Glass

Learn to Program with Minecraft Plugins: Create Flying Creepers and Flaming Cows in Java

Remote Pairing: Collaborative Tools for Distributed Development

What’s Hot

Most lists only go to 10. Ours goes to 11!

1^ | NEW | Learn to Program with Minecraft Plugins
2^ | 4 | Agile Web Development with Rails 4
3^ | 7 | Crafting Rails 4 Applications
4v | 1 | Node.js the Right Way
5^ | NEW | Remote Pairing
6^ | 8 | Programming Ruby 1.9 & 2.0
7^ | 9 | Programming Elixir
8v | 5 | Seven Concurrency Models in Seven Weeks
9v | 2 | HTML5 and CSS3
10v | 3 | Functional Programming Patterns in Scala and Clojure
11v | 10 | Programming Erlang

Who’s Where When

2014-01-08, CodeMash 2014

Introduction to the Roku SDK (Half-Day Class)

Chris Adamson (author of iOS SDK Development )

2014-01-09, Codemash

Are branching, null, and attributes all that OO? Let's get weird!

David Copeland (author of Build Awesome Command-Line Applications in Ruby and Build Awesome Command-Line Applications in Ruby 2 )

2014-02-26, Agile India, Bangalore

Keynote on Tacit Knowledge

Dave Thomas (author of Programming Ruby (2nd edition) , Agile Web Development with Rails (3rd edition) , The Ruby Object Model and Metaprogramming , Agile Web Development with Rails 4 , Programming Ruby 1.9 & 2.0 (4th edition) , Agile Web Development with Rails 3.2 , and Programming Elixir )

2014-02-28, NorDevCon, UK

XP at Unruly: a talk about how we use XP and where we've had to make adjustments to adapt to scale.

Rachel Davies (author of Agile Coaching )

2014-04-06, Agile Adria, Croatia

Giving a talk about coaching agile teams.

Rachel Davies

What’s Happening

But to really be in the know, you need to subscribe to the 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.

Antonio on Books

All the new tech books of note.

My pick this month is not a book that is likely to benefit you directly. It’s a book for the kid (or adult) in your life who might be interested in learning how to code. Hello World!: Computer Programming for Kids and Other Beginners is an excellent, gentle introduction to the topic. If you believe in the increasingly popular mantra that states “everyone should learn how to code,” this book might make for an appreciated gift.

Among books that are more likely to directly elicit your interest, I’d like to point out Quality Code, Raspberry Pi Projects, and Distributed Algorithms. Honorable mention also goes to the Express Books by the Pragmatic Bookshelf, which are quick and inexpensive reads. Those on Node.js and Remote Pairing caught my eye in particular.

Antonio’s Pick: Hello World!: Computer Programming for Kids and Other Beginners By Warren Sande, Carter Sande • ISBN: 1617290920 • Publisher: Manning Publications • Publication date: December 19, 2013 • Binding: Paperback • Estimated price: $25.65

Node.js the Right Way: Practical, Server-Side JavaScript That Scales By Jim R. Wilson • ISBN: 1937785734 • Publisher: Pragmatic Bookshelf • Publication date: December 2, 2013 • Binding: Paperback • Estimated price: $13.98

Distributed Algorithms: An Intuitive Approach By Wan Fokkink • ISBN: 0262026775 • Publisher: The MIT Press • Publication date: December 6, 2013 • Binding: Hardcover • Estimated price: $36.54

Raspberry Pi Projects By Andrew Robinson, Mike Cook • ISBN: 1118555430 • Publisher: Wiley • Publication date: December 23, 2013 • Binding: Paperback • Estimated price: $14.99

Programming in Objective-C (6th Edition) (Developer's Library) By Stephen G. Kochan • ISBN: 0321967607 • Publisher: Addison-Wesley Professional • Publication date: December 13, 2013 • Binding: Paperback • Estimated price: $27.16

The Art of Unit Testing: with examples in C# By Roy Osherove • ISBN: 1617290890 • Publisher: Manning Publications • Publication date: December 4, 2013 • Binding: Paperback • Estimated price: $31.13

Programming Google Glass By Eric Redmond • ISBN: 1937785793 • Publisher: Pragmatic Bookshelf • Publication date: December 23, 2013 • Binding: Paperback • Estimated price: $15.30

Microsoft SQL Server 2012 Internals By Kalen Delaney, Bob Beauchemin, Conor Cunningham, Jonathan Kehayias, Paul S. Randal, Benjamin Nevarez • ISBN: 0735658560 • Publisher: Microsoft Press • Publication date: December 9, 2013 • Binding: Paperback • Estimated price: $43.99

Python High Performance Programming By Gabriele Lanaro • ISBN: 1783288450 • Publisher: Packt Publishing • Publication date: December 23, 2013 • Binding: Paperback • Estimated price: $24.28

ZooKeeper: Distributed process coordination By Flavio Junqueira, Benjamin Reed • ISBN: 1449361307 • Publisher: O'Reilly Media • Publication date: December 2, 2013 • Binding: Paperback • Estimated price: $21.94

C Primer Plus (6th Edition) (Developer's Library) By Stephen Prata • ISBN: 0321928423 • Publisher: Addison-Wesley Professional • Publication date: December 6, 2013 • Binding: Paperback • Estimated price: $35.97

Windows 8.1 Apps with XAML and C# Unleashed By Adam Nathan • ISBN: 0672337088 • Publisher: Sams Publishing • Publication date: December 25, 2013 • Binding: Paperback • Estimated price: $37.84

Quality Code: Software Testing Principles, Practices, and Patterns By Stephen Vance • ISBN: 0321832981 • Publisher: Addison-Wesley Professional • Publication date: December 14, 2013 • Binding: Paperback • Estimated price: $30.72

Introduction to Android Application Development: Android Essentials (4th Edition) (Developer's Library) By Joseph Annuzzi Jr., Lauren Darcey, Shane Conder • ISBN: 0321940261 • Publisher: Addison-Wesley Professional • Publication date: December 6, 2013 • Binding: Paperback • Estimated price: $27.67

Creating iOS Apps: Develop and Design (2nd Edition) By Richard Warren • ISBN: 032193413X • Publisher: Peachpit Press • Publication date: December 1, 2013 • Binding: Paperback • Estimated price: $29.98

Windows Runtime via C# By Jeffrey Richter, Maarten van de Bospoort • ISBN: 0735679274 • Publisher: Microsoft Press • Publication date: December 6, 2013 • Binding: Paperback • Estimated price: $19.77

Learn iOS 7 App Development By James Bucanek • ISBN: 1430250623 • Publisher: Apress • Publication date: December 12, 2013 • Binding: Paperback • Estimated price: $28.38

Remote Pairing: Collaborative Tools for Distributed Development By Joe Kutner • ISBN: 1937785742 • Publisher: Pragmatic Bookshelf • Publication date: December 9, 2013 • Binding: Paperback • Estimated price: $14.09

Professional iOS Programming By Peter van de Put • ISBN: 1118661133 • Publisher: Wrox • Publication date: December 4, 2013 • Binding: Paperback • Estimated price: $26.93

jQuery and JavaScript Phrasebook By Brad Dayley • ISBN: 0321918967 • Publisher: Addison-Wesley Professional • Publication date: December 27, 2013 • Binding: Paperback • Estimated price: $17.89

Antonio Cangiano is the author of the excellent Technical Blogging and you can subscribe to his reports on new books in technology and other fields here.

Shady Illuminations

Some Common Sense Regarding Bitcoins

by John Shade

John takes on the Bitcoin phenomenon and offers a modest, though extraterrestrial, proposal.

Opinions about the Bitcoin phenomenon are a drug on the market these days, but they are buying precious little agreement. There isn’t even any settled viewpoint on what this Bitcoin thing is. Is it a currency or an asset? A floor wax or a dessert topping? A democratizing, inflation-fighting new way to pay or a boon to drug smugglers and the market for mercenaries? Is it a good thing or a bad thing? Real or bogus?

On one hand, we have the heartwarming story of a Florida homeless center that “has gone from serving fifty meals per week to nine hundred per week using Bitcoin.” (Thanks for the tip, Al-Jazeera.) On the other hand, entire countries, more populous than the US, are sending skeptical messages about the currency. Overstock is onboard, but US banks are boycotting.

Comparisons are being drawn to the Dutch tulip craze. The Atlantic magazine even asks how many tulips you can buy with a Bitcoin. Meh, I’m not sure that the tulip bubble has a transferable lesson. The Dutch may not be your typical society when it comes to trust. I mean, Holland itself is a bubble. Wall yourself off from the scary stuff and you can believe you're not already under water.

Dashiell Hammett cautioned, in his unfinished novel coincidentally titled Tulip, that you “not try to fool yourself and your customers with colored bubbles.” Which makes as much sense as anything else I’ve read on the subject.

But let’s assume that Bitcoin turns out to be a serious currency and that future, larger bitcurrencies follow, replacing government paper and reshaping the world’s currency. Let’s assume that all the naysayers are wrong and Bitcoin is a total and utter success. There’s still the carbon footprint.

Bitcoin mining is astronomically expensive, measured in processing power required. It’s designed to be. That’s essential to the way Bitcoin creation works. But this means that Bitcoin mining is on track to be an environmental disaster. That’s not cool.

So I’d like to offer a simple, common-sense proposal regarding present and future bitcurrencies, one that completely eliminates the global warming issue and lets us generate all the bitmoolah we want.

We do all of our Bitcoin mining on Neptune’s largest moon, Titan.

Titan is the second-largest moon in the solar system, larger than the planet Mercury. It has an Earthlike climate (if you ignore a few picky details), with a Nitrogen-rich atmosphere somewhat denser than Earth’s and rain and wind that produce Earthlike features, including rivers, lakes, seas, deltas, and dunes. The seas are liquid methane, not water, but you can’t have everything.

Aerospace engineer and author Robert Zubrin says Titan has all the elements necessary to support life, in abundance, and that “Titan is the most hospitable extraterrestrial world within our solar system for human colonization.” I don’t know about that. I try to avoid places where the average daily temperature is measured in degrees Kelvin.

But for industry, that’s a different matter. Titan has virtually unlimited petro resources to exploit. Wikipedia says, “Titan has hundreds of times more liquid hydrocarbons than all the known oil and natural gas reserves on Earth.” Conveniently located in lakes of liquid methane. It’s a petro-rich world open to exploitation. You know it’s going to happen. Industry will come to Titan.

Of course the transportation costs argue against manufacturing physical products, so that limits you to information products. Genome mapping, SETI, Bitcoin mining all require massive processing but produce easily-transportable information. Bits. So long as you’re willing to wait eight hours for a round-trip light-speed transmission. So no help for day traders.

Neither genome mapping nor SETI is sucking up anything like the processing power that Bitcoin mining is. So the wholesale relocation of all bitcoin mining, if not bitcoin miners, to Titan seems like the way to go. It would be a big win for the environment.

Of course the same argument cited against producing physical products argues against transporting great quantities of raw materials or equipment to Titan for this mining operation. The mining computers will have to be built on site, in a recursive cycle of building the factories to build the factories to build the Bitcoin mining machines, and using almost exclusively native raw materials.

But hold on, are the necessary raw materials available? What metals can be found on Titan, and in what quantities, and how easily extractable? Nope, wrong questions. Just keep focused on the petro products that Titan boasts in such wild abundance.

I just want to say one word to you. Just one word. Are you listening?

Plastics.

John Shade was born under a cloud in Montreux, Switzerland, in 1962. Subsequent internment in a series of obscure institutions of ostensibly higher learning did nothing to brighten his outlook. He has a few degrees, but as he points out, so does Neptune’s moon Titan. Follow John on Twitter, send him your feedback, or discuss the article in the magazine forum.

Rear Window

A Parting Shot

Harry Garland and Roger Melen founded Cromemco, an early personal computer company. Photo courtesy of Roger Melen.

Let’s raise our glasses to those who wear them.

Almost forty years ago, a lot of young engineers who were tired of paying rent on their toys started a revolution and launched a multi-billion-dollar industry, but that was never their intention. As Bob Cringely put it, “it happened by accident because a bunch of disenfranchised nerds wanted to impress their friends.”

Dan Bricklin wants to set the record straight about who those pioneers were. “Some of those that participated in making the personal computer happen,” he said in his personal blog recently, “may have been hippies and anti-establishment, but certainly not all were nor did it matter as much as other factors.”

Chief among those factors was having a truly nerdy passion for electronics.

Today the nerds we celebrate are usually programmers. But let’s remember those who started this personal computer revolution, many of whom did their debugging with an oscilloscope and a soldering iron.