Project Aardvark

Nirvana

Wednesday, July 13, 2005 posted by Benjamin Pollack

After days of frantic debugging, an empty web page never looked so good:

The Saga of Doug

Monday, July 11, 2005 posted by Benjamin Pollack

Jill, our blackbox tester, is currently in the office pounding Aardvark in preparation for our private beta, and man is she finding a lot of bugs. The overwhelming majority of them are trivial or quick (“Fog Creek Copilot needs a service mark,” “Message text clipped in Windows 98,” “‘Oy gevalt’ is not an acceptable window title,” etc.), but a few of them are proving to be annoyingly massive (“Helper cannot be quit if you disconnect, begin reconnect, and then attempt to quit, but it does quit at any other point” being the one to earn the title “Least Favorite Bug of All Time” (LFBOAT)).

So of course this is a great time to take an hour out of my day and tell you about the Saga of Doug.

When I was in high school, my physics teacher was Mr. Mervis. Physics in high school was really fun, not only because we got to hear one of the senior football players shriek like a little girl when he touched a fully charged Van de Graaff generator, and not only because my best friend John and I made a Rube Goldberg contraption that helped Scooby Doo capture Osama bin Laden (scale models only, sadly), but also because Mr. Mervis would frequently share random stories that, technically speaking, had nothing to do with physics.

One such story involved the girlfriends of a friend of his whom I’ll call Bob, more because I don’t remember Bob’s actual name than to protect his identity. (I could call him Darth Vader, I suppose, but that’s trademarked, and calling him Ishmael would make this story sound fishy.) Anyway, Bob had a girlfriend whom I’ll call Susan, because I don’t remember her name, either. To cut a long story short, Bob and Susan eventually broke up, though Susan continued being friends with Bob and Mr. Mervis. The problem was that Bob dumped Susan for another girl named Susan. This threatened to lead to extremely confusing conversations, such as, “I saw Susan and Susan last night, and you’d never believe, Susan was with George! It’s a good thing Susan was there to keep her in line, or Susan really might have done something rash.”

So Mr. Mervis decided that Susan 2 would henceforth be named Doug.

Susan protested at first, of course, but you know how social pressure works. Soon, everyone was calling her Doug. Short, sweet, and clear. No one would ever confuse Doug and Susan. Not unless he were on heavy drugs, anyway. Problem solved!

Thus was born the Saga of Doug.

Ever since then, whenever I have more than one person named the same thing and it starts getting confusing, one of them gets renamed Doug. I usually dodge this with my own name by jumping from Ben to Benjamin and back again as needed, but for everything else, I can use those four magical letters that trumpet out with all the grace and charm of a crate of sardines landing on a wooden pier in the fog of night. Doug is the ultimate renaming tool.

Why did I tell you all that, you ask? Because I need to you to understand how Lerone, our dedicated filmmaker who would never, under any circumstance, make me look like an idiot on camera unless he happened to have film at the time, came to be named Doug. Basically, he and Yaron forced my hand. You might think that Lerone and Yaron are really distinct, but they both get pronounced basically as “erOWN,” leading to quite a bit of confusion. So several weeks ago, frustrated for the last time about calling out “Lerone” and getting two “What?”s (grammarians, shut up; you punctuate that right), I decided that Yaron would henceforth be named Doug. Lerone, however, in a fit of irony with a side dish of masochism, misheard “Yaron” as “Lerone,” and therefore accepted the title of Doug himself.

There’s been some resistance, of course, such as that I occasionally get called Bert, but overall, I think the change has gone over swimmingly. It’s a rare day when someone calls out, “Hey, Doug, need some more X-rated footage?” and Yaron thinks someone’s talking to him. I’d really have to call the program a smashing success.

So, Doug, I just want to thank you so much for being the source of inspiration for me to call Doug Doug, and I’m sure Doug appreciates your contribution, too. He may may not yet realize it, but we will forever be in your debt.

Focus, Focus, Focus

Wednesday, July 6, 2005 posted by Benjamin Pollack

Today, the topic is the law of unintended consequences as it applies to modifying software.

Since we’ve now revealed what Fog Creek Copilot is, I can talk in a lot more detail about exactly what I’m up to. At the moment, I’m wrapping up some GUI improvements that have been the source of two weeks of misery for me. As you all know by now, we’re using TightVNC as our code base. We’re diverging more and more from that starting point (we stopped complying with VNC’s protocol weeks ago and will break a lot more in about a week when I change the compression mechanism), but the fact it’s our base means that certain design decisions made for TightVNC affect the design of Aardvark.

One of the design decisions that vncviewer (the TightVNC client) made was an extreme usability headache. Specifically, there is no way to quit vncviewer until the connection has fully succeeded or fully failed—i.e., you cannot abort the connection during handshaking. This manifests itself in the UI by giving you a tiny window that pops up that says “Connecting…” and has a button marked “Hide.” The “Hide” button does exactly that: it hides the window. You may think that vncviewer has quit, since it no longer has any open windows or taskbar icons, but it’ll actually still continue trying to make the connection. This results either in a window popping up unexpectedly several seconds later or in a seemingly random message box telling you that a connection couldn’t be established. Either one is surprising and confusing if you thought that vncviewer had been closed for several minutes. We found this behavior totally unacceptable, so the spec called for displaying a normal window immediately and allowing the user to quit at any time.

Unfortunately, vncviewer had some design decisions that made fixing this extremely difficult. All of the negotiations occurred in an independent thread that could not be stopped once it was launched. No useful feedback came out of the thread (it updated some text, but didn't pass any messages). The viewing window assumed that, if it were displayed, it had a valid connection, which meant that it would complain when it tried to send data to a nonexistent socket.

Just under two weeks ago, I started the process of tackling these issues. I broke up most of the worker thread into chunks handled by Windows messages, and I modified what was left of the negotiation thread to use message passing and flags to let the user quit cleanly. That solved about 50% of the problem. There were a tremendous number of bugs, but I was able to fix the overwhelming majority of them over the next few days without any major problems.

Except one. This heavily modified program, which was for the first time called Aardvark Helper in our internal emails instead of vncviewer, had a tendency of closing the connection during the negotiation cycle. A lot. The problem was that it wasn't easily reproducible. It was certainly pervasive—it happened constantly—but there were no replicatable sequences that would cause the bug to surface. Usually, launching Aardvark Helper and then WinVNC caused a crash, but sometimes it didn’t, and occasionally launching WinVNC and then Aardvark Helper also crashed. Frequently both orders would be fine several tries in a row. Most frustratingly, stepping through handshaking in the debugger fixed the problem. Doing that was the one surefire way to guarantee that everything would work just peachy.

I scoured the way I’d broken up handshaking looking for any clue of what was going wrong. Inconsistent crashing during code that you know is threaded is usually a sign of a threading issue, so at first I thought that the handshaking wasn’t proceeding linearly or was restarting itself at some point. Yet a collection of printfs quickly assured me that my refactored negotiation code was running just fine, even when the program was crashing, which removed that possibility from the table. Unfortunately, this happened running up to CFUNITED, so I couldn't stay focused on just this one bug. In fact, I couldn't even focus on just this one code base: we had forked everything a few days earlier for the show and had a policy of fixing bugs in those builds by any means necessary (which at one point meant adding a line in code that basically read "if you can't open the file, pretend you could and wing it"). So I had a very hard time actually focusing on any individual bug for very long.

Literally the day before CFUNITED, I discovered yet another bug: Aardvark Helper wouldn’t send mouse movements unless the window lost focus and then got it back. I was too busy to deal with this quirk at that point, so I simply filed it in FogBUGZ and figured I’d attack it later.

Yesterday, I got back to attacking the crash-during-negotiation bug. As I toyed for the umpteenth time to see whether I could reproduce it reliably, I was also scanning open issues in FogBUGZ, and suddenly, I realized something. Aardvark Helper wasn’t sending messages unless the window lost and regained focus. The crash normally happened if I launched Aardvark Helper, then WinVNC. When I did that, I usually, but not always, then reselected Aardvark Helper, which meant…

Which meant that reselecting the Aardvark Helper window and then moving the mouse would cause the program to send VNC data during handshaking. Which causes the programs to quit because they get corrupt data during the handshake.

I’d thought to ensure that Aardvark Helper’s window wouldn’t send data when the socket was invalid, but I’d neglected to make a distinction between a valid VNC-like connection and a simple socket connection in the middle of handshaking. Oops.

A mere 25 lines of code later, the bleeding-edge version of Aardvark Helper now has the stability of the CFUNITED build, in single-window form. So now the applications run smoothly and stably, and for the first time in weeks, I can honestly say that neither Aardvark Helper nor Aardvark Host have any known operational bugs. It was a headache getting here, but at least I’m pretty confident now that when we start the private beta in a few days, the clients will be ready.

The Big Guns

Friday, July 1, 2005 posted by Benjamin Pollack

I would like to talk a little bit about the Marymount Apartments where we have been staying for the past month.

You know, Duke is not in the best place in the world. Oh, don't get me wrong. I love the campus. The buildings are beautiful, the gardens are serene, the young ladies are gorgeous and charming, and the classrooms are very well wired. Durham, though, is not what most people would think of when challenged to envision the phrase "picturesque city." We're certainly in competition with New Haven and Hyde Park for ugliest fricking neighborhood for a major university.

So you'd sure think that Duke's regulations for student housing would be a heck of a lot more stringent than the Marymount apartment where we live, on the grounds that the Marymount is in a rather posh section of New York City where your biggest threat is a person having a deeply moving philosophical conversation with deaf-mute invisible people in another dimension, rather than getting mugged at gunpoint. But noooooo.

At Duke, I can have as many people in my room as I want, so long as I'm not breaking the fire code. As long as everyone's 21 or over, I can have copious amount of liquor. If I want to let people stay over, I can buy some futons and set them up. So far as I know, the basic rule at Duke, both de facto and de juris, is that as long as you're not breaking the law, damaging property that doesn't belong to you, or disturbing the neighbors, Duke couldn't care less.

But the Marymount is an entirely different matter.

If you want an apartment that does not trust its tenants to bring more than two people to their room at the same time, then I recommend the Marymount.

If you are concerned that having someone over past midnight is a surefire path to sin, the Marymount can protect you.

If you are afraid that having more than six beers (or one bottle of wine) in an apartment shared by four people is a recipe for trouble, then the Marymount deserves your attention.

But wait! There's more!

Worried about people organizing events? The Marymount will ensure you lead a boring life by forbidding you from posting fliers!

Concerned about malicious hackers? The Marymount blocks everything except plain old web and chat, ensuring that you don't have to worry about pesky things like the iTunes, IRC, or even email!

Can't stand foot odors? The Marymount will even protect you from people who are not wearing footwear in the laundry room!!!

A week ago, my roommates and I got busted for considering having a party on the weekend. Not for having the party; for considering having the party. We were hauled down to the office and given cute little xerox copies of pages that are in our handbook that tell us parties and nonstandard religious practices are illegal and punishable by castration. The pages even had our names written on top in bright red marker like when your kindergarten teacher scribbled "Needs work" on a drawing you made by sucking paint out of a bottle and spitting it systematically on newsprint.

Well, I've had it. So you know what? In violation of the handbook, my roommate and I have purchased A CARPET-LIKE OBJECT (a bath mat) and TWO PIECES OF FURNITURE (trash cans), and WE ARE NOT AFRAID TO USE THEM. Moreover, left unchecked, we may buy light bulbs, pencil holders, and (gasp!) FUZZY DICE.

Should we be allowed to continue unchecked? Do we pose a danger to society? Only time will tell. For now, though, we remain the bold rebels in the night, skirting the oppressive fingernail of authority wherever it may scratch.

George Washington would be proud.