Follow by Email

Friday, March 26, 2010

Happy Birthday, Akira Kurosawa

Being away from home for eleven days is hard, especially when your wife and dog don't come with you. I had a two-day offsite scheduled by my employer, and a technology conference (for which I had to give a presentation and run an after-hours session.)

Fortunately I had a wonderful weekend chock full of fun, and I managed to see several friends (you know who you are, friends!) but, and I hope people don't mind me saying so, the best damn part of this whole trip was the Akira Kurosawa film festival at the Stanford Theater in Palo Alto.

The last time I managed to attend a Kurosawa film festival was at the Aero Theater in Santa Monica back in 2008, and it was superb. At the time I saw the great films Ran, The Bad Sleep Well, Dersu Uzala, and Dreams, all of which I recommend unreservedly. But I have yet to find such film festivals in New Jersey, and I missed that part of California. Upon discovering this festival, I set up my viewing calendar. Fortunately, they repeated the same two movies per night over several nights, which meant I was never under pressure to go to the theater every night.

The first night I saw the two films Throne of Blood and The Bad Sleep Well. Throne of Blood was a fun visual experience, a solid recreation of Macbeth, but left something to be desired. What was missing was a hook that forced us to hang on to the story. It was clear this was missing because The Bad Sleep Well was clearly that kind of movie.

The second night had Kagemusha and Sanjuro. I missed Sanjuro because it was starting so very late, but Kagemusha was sublime. I've commented on this at work which spawned a rather lengthy discussion comparing it to Ran, which is entirely appropriate.

Tonight I saw The Lower Depths and The Idiot. Be prepared for those movies, though, because they're both very heavy. The Lower Depths is an ensemble film full of well-cast characters. It's a fairly depressing story about very poor, out of luck losers, all with their own special problems, fortunately punctuated by two fun, drunken song-and-dance scenes. The Idiot, an adaptation of the Dostoyevsky novel, had the sadness of The Lower Depths, only 50% longer, minus any respite that may come from drunken song-and-dance. Seriously, the story is split in to two parts:

Part 1: Love and Suffering.
Part 2: Love and Loathing.

Nonetheless, it was wonderfully shot, and, except for some horrible editing in the beginning poorly made up by adding long blocks of text, it was a compelling film. That I may never see again.

What a great, great way to spend my free time.

The Lower Depths

The Organ Player from Intermission

The Idiot

Friday, March 19, 2010

Learn about how Google uses Eclipse

Hey EclipseCon attendees,

If you're interested in how Googlers use Eclipse to develop some of the products you use, come to our talk on Tuesday, 4:15PM:
Eclipse in the Enterprise: Lessons from Google 
Providing Eclipse tools to thousands of engineers at Google is a satisfying job, but it's not always easy. In the last two years supporting Eclipse at Google has gone from casual support by enthusiasts in their spare time to a dedicated team mandated to make engineers' lives better. We will talk about the plug-ins we've written and processes we've established to provide features, enterprise deployment and support, and even share some of the pitfalls discovered along the way. 
And then, come to the Eclipse In The Enterprise BoF on Tuesday at 7:15PM for an opportunity to discuss how Eclipse is used at your organization!
Hey, you! Yes, you -- don't you work for that big company? Are you supporting hundreds, maybe thousands of your Eclipse-using colleagues? Are upgrades and environmental consistency your problem, too? Are you constantly struggling with fitting your company's build system to the IDE and Eclipse builders? Is your source code base so large that you're continually fooling Eclipse into thinking it's smaller?

Then come meet your peeps at the "Eclipse in the Enterprise" BoF. Let's share war stories and ideas. Impress everyone with your clever solutions and work-arounds! We're all facing the same issues, so come, let's talk.

Sunday, March 14, 2010

The Fourth Annual Computer Competition (Part 4 of 4)

(Introduction and Part 1Part 2, Part 3, Part 4)

The fourth question, Question #5.

Question #5: Senior Division

Compact Disks (CD's) offer the latest advantages in digital sound. Each disk is capable of prividing almost 75 minutes of music. You are currently creating a catalog of your disks (on your computer, naturally) that will list the total time (in hours:minutes:seconds) fro each CD. Unfortunately, while most disk labels list the time for each selection, many do not list the total time for the complete album (although must CD players display this information when you first insert the disk prior to playing it.)

Write a program that (a) asks for the number of selections on the disk (b) asks for the time of each selection in the exact format [minutes:seconds] -- including the colon and (c) outputs the total time of the CD in the format [HH:MM:SS] (Hours:Minutes:Seconds). NOTE: 00:63:29 would be wrong. 01:03:29 would be correct,etc,

IMPORTANT INFORMATION: You may assume that no selection is over 59 minutes and 59 seconds long [59:59] and that the judge will input the data with no spaces between the numbers and the colon. However, the judge may or may not input the minute information with a leading zero. For example, your program should be able to handle 2 minutes and 12 seconds input by the judge either in the form 2:12 or 02:12. Finally your output must be in the format HH:MM:SS or it will not be judged correct. That is, there must be two digits for each position (hours, minutes and seconds) and the output must not have any spaces between the digits and the colons. Some example include (see the SAMPLE RUNS for others):

00:07:3300:7:3302:13:1202 : 13 : 12









The Fourth Annual Computer Competition (Part 3 of 4)

(Introduction and Part 1Part 2, Part 3Part 4)
The third question, Question #4.

Question #4: Senior Division

The integers 12, 21, 13 and 31 have the following characteristic:
12 times 12 = 144 and 21 times 21 = 441
13 times 13 = 169 and 31 times 31 = 961
Write a program that identifies all 3-digit integers (if any) between 100 and 400 for which this same kind of relationship holds. (That is, a 3-digit number whose square and the square of its "reverse" are mirror images.)

Important notes:

The number and its "reverse" must:
(a) both be true 3-digit numbers
(b) not be identical.
Examples: the following integers (among others) do not qualify:
100 (because its reverse integer is 1)
120 (because its reverse integer is 21)
121 (because its reverse integer is identical)


When your program is RUN by the judge it should list all the integers between 100 and 400 that qualify or state that no integers qualify, if that is the case.

The Fourth Annual Computer Competition (Part 2 of 4)

(Introduction and Part 1Part 2, Part 3, Part 4)

Question #3: Senior Division

Write a program that accepts a sentence for input and outputs the sentence with the letters in each word arranged in alphabetical order, and the words in order of length. Words must still be separated by spaces. If two rearranged words are of equal length they are to be placed in alphabetical order of the output "sentence".

NOTE: The judge will input only upper-case letters and will terminate the sentence with a period. This will be the only punctuation in the sentence and must remain at the end of the output sentence.





The Fourth Annual Computer Competition (Part 1 of 4)

(Introduction and Part 1Part 2, Part 3, Part 4)


During my junior and senior years at high school I participated in a county-wide computer programming competition.

The day before the first competition, my junior year, the president of the computer club challenged me to a quick on-paper coding competition to see who should go. I beat him handily, and he was kind enough to give me the spot. Charles was a brilliant guy who I'm sure did just fine without the competition on his resume.

Both years, the competition went like so: every student was allocated an observer-judge. The judge was responsible for resetting the programming environment, clearing code and data, watching the student during the test, and then, when the student was done, would test the program with a predetermined data set. Correct exact results meant the student earned one point. Any incorrect result meant zero points.

The junior year I tied for third place with four other kids, resulting in a sudden-death run-off. (I remember getting at least one question incorrect. Did I get two wrong? My ego is struggling with the possibility.) I'm positive that had I not paused to test my program during the run-off I would have taken third-place, and the TRS-80 would have been mine. Alas.

The senior year's competition was the day after my prom, and I chose not to attend the prom in order to get a good night's rest. (This is a lie; I didn't attend the prom for plenty of reasons, most of which was I didn't fit in. My girlfriend and I had dinner at Gasho of Japan instead.) I don't remember doing well enough to win or place.

Tonight, while going through some old boxes in the basement, I came across one of the competition packets. There's no year on the packet, so I can't tell for which competition it was. There are four questions, labeled two through five, meaning that one of the questions is missing.

I'll publish the four questions, each as its own blog post. I won't include sample answers, because mine were built and destroyed quicker than sand sculptures. Plus they were written in BASIC, and I love you, but not that much.

The first question, Question #2.

Question #2 Senior Division

Write a program that will ask for six 3-digit numbers (without signs) to be input one at a time. ANY 3-digit number is valid. (Examples: 123, 049, 899, etc...). If anything else is input (letters, etc.) the program MUST output the EXACT error message "PLEASE INPUT THREE DIGITS ONLY", and then request the number again. After SIX 3-digit numbers are properly input the program is to tally the digits according to their position and output a table listing how many times a particular number appears at each position (hundreds, tens and units place.) See the SAMPLE RUN for clarification.

1. Try to make your output table easy to read, but do not worry about all numbers lining up perfectly since various computers differ slightly in formatting. [The judge will be looking for accuracy of output, not formatting of output.]
2. To make your task a bit easier you may assume that the judges will NOT attempt to input any commas or quotation marks. Any other input, however (letters, numbers, +/-, etc.) is "fair game", so make sure to test your program thoroughly.

3-DIGIT NUMBER 4? 8994

-----   ----    ---     ----
ZERO     1       1       2
ONE      0       0       0
TWO      0       0       1
THREE    1       0       0
FOUR     2       1       1
FIVE     1       0       0
SIX      0       2       1
SEVEN    1       0       1
EIGHT    0       1       0
NINE     0       1       0

Thursday, March 11, 2010

Google, thanks for your dog policy.

I want to take a moment and thank my employer, Google.

See, Google has a policy that permits its employees to bring their dogs to work. Now whether you can bring your dog to your office depends on many factors: whether your building allows dogs, whether your teammates tolerate dogs, whether your dog is well behaved, healthy, and so on. In fact, the possibility of bringing a dog to work made it easier to decide that, yes, we could get one. (Note: it was not part of my plan to rely on bringing a dog to Google, it just helped with the decision. You can't predict a rescue dog's personality.)

And then we got Maggie, whom I like to call "the world's best starter dog." Superbly well behaved with only a penchant for barking at strangers a little more frequently and loudly than I'd prefer, taking her to work quickly became one of the very best parts of my job. In the morning we would walk the 2 miles to work, with a couple of walks in the afternoon, and play-time at 5PM, on the dot. She made people in the office happy. She made me happy.

And then we moved to New Jersey.

Dogs are allowed in the Google New York office. But, they're not allowed on the train, at least, not without a crate, and we never managed to successfully crate-train Maggie. That means the only choice is to drive her into New York City. Since my wife works from home most days, there's just a natural predisposition to leave her home. Unfortunately this means she gets much less socialization than she did in California.

I once brought Maggie the NYC office, on Bring Your Dog To Work Day. It didn't go well. Traffic jams dominated the trip in. Maggie was perpetually frightened. Frightened by the highway, the tunnel, the loud, twitchy freight elevator, the noise around my desk, the open cubicle area. She couldn't relax and neither could I. Taking her on a walk was out of the question. No, instead we left for home at 2PM, both of us stressed and sorry, and relieved to be getting out of there.

But this week my wife is away, so I decided to try again. Would things be different?

You bet.

I brought her in on Tuesday. Maggie still hates the freight elevators, but she's hating them less with every ride. The traffic still sucks but I'm beginning to assemble a plan that might help me beat it. My office mates were very happy to have her there. Maggie wasn't afraid of the office, she got lots of much needed human attention and socialization. We found an abandoned part of the office floor, a perfect place to throw a ball. We even managed to go on a walk in the afternoon, complete with a poop! I didn't get a lot of work done, but I brought her in yet again today, and managed to do a solid day's work. Just like when we would hang out at the Santa Monica office.

The traffic, the higher travel cost, the restricted walking, it was all worthwhile.

All of this is to say: Tuesday was my happiest day at work since moving back east. Thank you, Google.

Maggie and me, chilling on the carpet.

Tuesday, March 02, 2010

Advice On Running an Engineering Reading Group

This is an edited version of an internal document I wrote for other engineers at Google about leading an engineering reading group. While much of it meanders into standard tips for managing meetings, they bear mentioning.

Feedback is appreciated!

Advice On Running an Engineering Reading Group

1. Thank you!

First, leading a reading group provides value to you, your colleagues and your company. It's more work than just showing up, and comes with frustration, particularly when attendance is low or someone dominates the conversation. So, thank you.

2. Selecting the book

As the leader, you get to choose the book. If anyone challenges you, ask them to talk to me. It's hard for anyone else to be enthusiastic about the material if you aren't either. Your own self-interest is the best way to generate excitement, ensure you will complete the book and provide ideas. Also, your interests are a fine gauge for other people's interests.

If this is your first reading group, start with an easier book (such as Head First Design Patterns), or one with a reading group guide (such as Joshua Kerievsky's Design Patterns reading group guide.) The harder a book is to understand, the larger number of people will read less, and eventually fall behind and drop out of the group. If anyone complains that the book is too simple, invite them to champion the next book.

By the way, you don't have to be the topic master. Personally, I select books that require the social pressure of leadership for me to finish. When I realized I forgot most design patterns, I led a group in design patterns. Months later, I got stuck half-way through Java Concurrency in Practice, so it became the next reading group book. Both led to successful and engaging reading groups.

3. Do not let the community choose the book.

This was a hard-earned lesson. When you let the community choose the book, you run the risk of the book's most ardent supports disappearing. Leader gets to choose, no question.

4. Purchasing books

Any approval for buying books is probably something you need to discuss with your manager or director. If you have a director willing to take the cost, or perhaps company approval to purchase en masse, great. But while buying individual books can be a logistic hassle, it brings up an important issue:

5. Participants should purchase the books themselves.

After leading several of these groups, I've learned that people who express interest but wait for someone else to get them a book are the ones who tend to be passive participants, or show up for no more than two sessions. Putting participants through a purchasing a hurdle has the benefit of self-selecting the most interested participants.

You might ignore this advice and provide material for attendees. If you want to start with a larger group, or if the reading group is new, then perhaps it's more appropriate to set a welcoming tone. And to be fair, some people for whom I purchased books became the best participants. But take note who sticks around.

6. Set and communicate your expectations.

Make sure you know what kind of reading group you want, and communicate your expectations up-front. Three areas where expectation management can matter:
  • Reading requirements: If people are required to complete reading assignments, those that have not will have difficulty following the conversation. This is okay if you can accept a smaller number of dedicated participants. Or, you can spend the meeting time reviewing the material as if it was not read by the majority. You may wind up with more passive participants, but you may also get more questions.
  • Computers during the meeting: I've never enforced a no-computer policy, but sometimes wished I had. People will keep their focus on a laptop or mobile phone for the entire session. Are they paying attention? Are they encouraging other participants to disconnect? This is a tricky one which comes with existing social pressure. (Update: See the addendum below about actually implementing this.)
  • Tardiness: When you've only got 60 minutes a week to discuss a book and most people show up ten minutes late, you're group's value drops 15%. Communicate the expectation up front, and consider demonstrating it by starting the conversation with whomever is in the room.
Whatever you decide, remember: nobody has to attend, so you'll do better being polite than a draconian jerk.

7. Be Prepared

My wife taught me a lesson from her law school days : you can't always be the smartest person in the room, but you can always be the most prepared. This applies to leaders in particular. Read and understand the content. Come to sessions with conversation openers. The most engaged Java Concurrency in Practice session we had was one where I brought in sample code; a broken task pipeline, and fixed it in front of everyone.

There's another reason to be prepared: to master the material! Isn't that why you chose to lead a reading group, instead of waiting to participate?

8. Set the tone, and then share the leadership role.

Being a book's champion or the reading group leader does not make you responsible for generating interesting content from week to week, and in fact it's better to ask other participants to take the role of leading the group for single sessions. This is most valuable after a reliable leader spends two to three weeks setting the group's tone.

9. Encourage quiet people to participate or even lead for a week.

Part of the leader's job is to draw all participants into the discussion. Keep a few loud people from dominating the conversation. Draw out quieter people, preferably with open-ended solicitations of opinions or observations. Avoid  pop-quiz challenges; the goal is to expose a broad range of views, not intimidate shy people.

When you can get a quiet person to lead the discussion for one meeting, now that's a win.

10. Manage how far you drift off-topic.

Drifting off-topic can distract the group from more relevant material, but it can also provide the most interesting content. Conversations about concurrency can lead to conversations about testing which eventually take you to complaints about the build system. That's okay. Keep your eye on the clock, use your judgment, and don't be afraid to cut conversations off after a while. Remember to do it with kindness.

11. Always ask for feedback.

Ask the other participants how you're doing. Ask why they aren't speaking up. Ask how improve the sessions. Mostly you'll hear what a great job you're doing. Thanks! Now ask someone else. You're about to spend several weeks with everyone: keep an active two-way conversation channel.

That reminds me: ask drop-outs why they left. People tend to feel bad about leaving. I've had drop-outs hide from me after they leave. Go find out what happened. They might have useful feedback, they might even return for the next book.

12. Mistakes are good!

People already respect you for dedicating your time to take charge. Don't worry when you make mistakes your first time. You'll learn so much that leading the second book will be a cinch in comparison.

Addenda September 25, 2012:

Addendum regarding the no-laptop policy

 My most recent group had a no-laptop policy. We set it up before the first meeting by general consensus, and it worked really well. It allowed us to stay focused, and also, to have the authority to ask new visitors to close theirs, as well as their phones, by association.

Gauging Comprehension

Here's a useful tip: a good opening question is to find out how well people comprehended a chapter. (This also applies to individual sections within a chapter.) The way to gauge interest is to ask everyone to demonstrate their comprehension as a range, not unlike a volume meter. If the participant understands the content fully, the arm and hand point straight up. If the participant didn't understand it at all, the arm is parallel to the floor. From there, people can use the range in between 0 and 90 degrees to demonstrate comprehension. Then as the leader you can get a quick sense of the room, not just from the positions of their hands, but of the looks on their faces. Find someone whose hand is in the middle and ask the person to go into detail about their experience.