Air Traffic

Handle Your Errors!

<vent>
It's about 7:30, and I'm still at work.  Why?  Because I've been tracking down a bug and have been really close for several days now, but haven't quite gotten it.  Unfortunately, I can't just leave it for tomorrow, because I may not be able to work on it again for over a week, with CFUNITED this week and the 4th of July holiday this weekend.  Fortunately, I just found it: an unhandled WSAEWOULDBLOCK in one of the packages we're working with.  I've run across a couple others and I thought I got all of them, but apparently I missed this one.
</vent>

Live Demos of Project Aardvark

Live in the greater DC area? Planning a trip to Our Nation's Capital for July 4th weekend? Why not stop by CFUNITED and see what the Project Aardvark interns are up to?

CFUNITED is the ColdFusion developers conference, which is going to be held just outside of DC at the Bethesda North Marriott, also known as the Montgomery County Conference Center, next week, from June 29-July 1. I'll be giving the keynote speech on Wednesday and also doing a session on The Joel Test on Thursday.

On Wednesday and Thursday, in the Fog Creek booth, the Aardvarks will be doing the first public demos of their product, SidePilot. Yep, it's basically working, although still rather unpolished. If you're a Joel on Software reader you can register FREE for an "exhibit only" pass to come see the demo.

The Fog Creek booth will be open:

Wednesday, June 29
9:30am - 1:00pm and 2:00pm - 7:00pm

Thursday June 30
9:30am - 10:50am and 11:50am - 5:45pm

I'll be there, too, and so will Brett, one of the FogBugz developers, so if you'd like to talk in person to someone about FogBugz here's your chance..

To register for CFUNITED:

• If you just want a free pass to the exhibit area, use code X3545, Visa card 4444, expiration date 11/11.
• For the full conference use code S1515089 to get a $50 discount
• In either case write "Joel on Software Reader" in the comments section

See you there!

Backwards Whatatibility?

The past couple days I have been trying to track down a bug that I have been having trouble reproducing.  I can only get it to show up when I run it on a virtual machine, but since I do not have Visual Studio set up on that virtual machine, I can't debug it there.  Not being able to create the bug on my own machine (due to application focus issues) I decided use a laptop so I could have two computers run it on, without any focusing issues.  This should be really easy, considering that machine already has VS .NET.  So I set it up on my desk this morning, copy the files over, open the project, and get welcomed by "Your project file version is '7.10'.  Visual Studio .NET can only load version 7.0 project files."

What?!

So what they're saying is that because my project files are one minor version newer, it can't open them?  Ok, so I only have VS .NET on the laptop, while we have VS .NET 2003 on the development machines, fine.  But are there really that many changes from 7.0 to 7.10?  Adobe Photoshop 6.0 can load .psd files that were created in Photoshop 7, why can't Visual Studio do it?  Especially since they just invested so much in creating .NET (and breaking previous backwards compatibility) it seems like they could have designed the new system to work backwords, at least within one minor version.

Ok, I'll upgrade it.  If it's only one minor version change, it should be pretty easy, right?  Nope.  I get to install it all from scratch, which just happens to be the exact thing I was trying to avoid on the virtual machine in the first place.  Grrr...

1...2...3...

When we first arrived at Fog Creek we were asked to create a plan for escaping from the Fog Creek offices to the adjacent building in case of fire.

Our ideas have included grappling hooks, ladders, Ethernet cable, air ducts, and the one that caused the most controversy, jumping the gap. After some debate, we finally decided to measure it off and see if it was possible. It’s about 15 feet across the chasm and about 10 feet down. After some whiteboard physics, we decided that it is probably feasible, but not something to be tried if we could avoid it. Overall it took us about an hour, but I can finally close that stupid bug!

On the topic of real work, encryption is finally working in the app.  There are still a few odd timing issues, but they only have a minor impact.  Now I just need to address the issue of creating and distributing keys for that encryption safely, but I don't think that'll be too much of an issue.  Of course, since this is all GPL, this will all be in the public domain, and since it has been something on the To Do List of the main developers of this app, hopefully they'll be able to include the security enhancements that I've made.

UPDATES

I made four posters for the CFUNITED Conference. Two are for Aardvark, one is for Joel’s latest book, and the fourth is for FogBugz 4.0. For Aardvark I made one poster that has a preliminary screen shot of the opening interface with various taglines above and below the image. The other poster has a chart comparing the features Aardvark has with those of the free alternatives. This poster also has a group shot of us at the bottom and some other copy and logos. The poster for Joel on Software is just the cover of the book blown up (I didn’t use this image but rather scanned the original) . For the FogBugz poster I took the layout and copy from the website and rearranged it fit on the poster. The problem was that I’m printing to an 18x24 poster and as such the compressed images from the web won’t do. So I had to reproduce all the images from the high resolution originals. It came out pretty good. The hardest part was making the top banner, from the original image. The result can be seen here (UPDATED 6/20, typo fixed, antialiasing effects by Tyler). I replaced “Click for a tour!” image with several screenshots of FogBugz taken from the tour itself. On Monday I’ll take the files over to Kinko’s. I’ve been doing the image work with Photoshop and the layout with Publisher which has been an educational process in and of itself. 

 

I finished several table-tents for the conference as well that label the different hardware components of the Aardvark infrastructure for use in the demo. A new laptop that will be used in the conference demo came in today. I’ll have to set that up later and get all the other components hooked up as well. I contacted Wired, CNET, Inc, Business 2.0, Craine’s, Entrepreneur.com and Entrepreneur magazine about possible news pieces covering the internship. So far Entrepreneur.com has replied, telling me that the internship would make a great story for the magazine but not the online edition and gave me the correct contact at the print magazine (whom I incidentally had already e-mailed anyway). Hopefully I’ll hear back from the others Monday. If not I’ll probably just go out and contact others. 

 

I made a deal with LogoWorks to begin conceptual design on our product logo. They created the Fog Creek logo and have a great design process. I’m pretty excited to see the different initial designs they come up with. I’ve also been in close touch with our graphic designer, Dave Shea, located out in

Vancouver

over the CFUNITED brochure. Hopefully we can bring that over to the printers by Wednesday at the very latest.

 

On the name front we had a meeting today and decided on the final name.  It's all registered and a preliminary site is even uploaded.   Good luck finding it :-P

 

Oh, and has it been two days already? I suppose it had. So here goes

 

Aardvark Super Secret Disclosure #2: Version 1 of Aardvark utilizes 24-hour Day Passes as its pricing model.

End-to-End Demo

At some point in the construction of a skyscraper, the last steel beam is put in place on the top floor and you have what's called a "topping out" ceremony. Traditionally this is marked by putting a small tree on the top beam, sometimes accompanied by a flag. The building is nowhere near done yet; walls and floors are missing, not to mention windows, doors, air conditioner vents, the candy stand in the lobby, and the dead guy in cement in the basement who tried to smuggle a non-union electrician onto the work site, but you've hit the top and the building never gets any higher.

I think the equivalent in a software project is what I call the "end to end demo." That's the very first time you can demo your entire project working in some way. Maybe it only works on one machine; maybe it doesn't quite handle encryption properly, yet, and maybe it crashes after ten seconds because it really doesn't like it when you, say, move the mouse, or do anything unusual. Doesn't matter. The end-to-end demo is that magic moment where you go from having a program that's under construction to a program that's basically done, it just happens to have a really large number of bugs. Before that moment, you're building something new. After that moment, life consists of filling in cracks and fixing bugs.

Our first end-to-end demo was on Wednesday, when Michael wandered into my office to say they were ready to show me everything working.

The first time you give an end-to-end demo to the boss, it always fails, and everyone scurries back to their desks to figure out what the heck it is about showing a demo to the boss that makes software which has run successfully 10,000 times before suddenly crash inexplicably, with an error message that is usually no more helpful than "remote side closed connection." And the boss chuckles, and goes back to his office to practice golf putting, while the developers flail around wildly trying to get their code to run in even the most basic way again.

And that's what happened.

But then, suddenly, you find the problem, and you run the demo again, and it works!

Rubber Band Fight!

As with all software development, there comes a time when you've beaten your head against the wall too many times on one problem and it's time for a break.  What better way than with a cross-office rubber band fight?

Despite my last few posts, we really are working and are getting very close to finishing the main feature set.  My latest hangup has been integrating security with some shady sockets programming, specifically using the peek flag, which is currently number 12 on the Windows Sockets Lame List.  The Lame List has provided some useful information and seems to be a pretty good list of How-NOT-To's, but is most notable for its comic value (see item 11).  (Fun project - write a working FTP server/client pair that is as lame as possible, that is, they break as many of these rules as possible.)

Our Work Environment

So I thought you all might like some photos of our corner of the office. Also, Tyler challenged me to make the final executable smaller than the total size of this website, including pictures, so I'm going to skew things in my favor.

All of us chilling in the main office. I think this was about two weeks ago when we were just getting started. New Jersey is out the window.

Michael working away on the e-commerce engine.

Yaron deep in thought about naming possibilities.

Tyler testing the latest security enhancements while listening to the company iTunes repository.

Tyler and Michael. To the back right you can see the main office.

Me working on making GPL code do what we want.

Fixing Other People's Code

It’s almost a truism that programmers would rather write new code than modify existing code. The truth of that adage is doubled when talking about modifying someone else’s existing code. Unfortunately, that’s exactly what Tyler and I have been doing nonstop for the past two weeks, and let me tell you, it has not always been pleasant.

After we got the source code the GPL component to compile in VS.NET, the next few days were spent, more than anything else, simply getting a feel for the code base. Different programmers have different conception of what orthogonal design entails; the degree of separation, the function of different components, the interfaces between classes, all vary dramatically from coder to coder and company to company, and invariably your conception is not quite the same as the fellow next to you. Understanding the design of the existing base, then, becomes very important to ensure that when you start making extensions, you do it right.

The problem is that when you’re first getting started, the chance of getting it truly right the first time—especially if you’re making large-scale modifications—is very low. In Aardvark, for example, I initially attached some new connection-specific handshaking code inside a class that controlled the windows taskbar icon for our program. That probably sounds a bit silly, but it actually made a reasonable amount of sense. The taskbar class was where connections were created and destroyed. Since that code was written for multiple connections, and I was restructuring it to allow only one connection, adding in some handshaking code into the new connection code there seemed as if it made sense at the time. It also had the benefit of keeping all Aardvark-centric modifications in just one class.

Needless to say, that was a bad call and caused problems down the road when Tyler started adding encryption code and needed to hook it in after the connection had been started and after Aardvark handshaking, but before any other communications took place. So that had to be refactored heavily. Thank heaven that Subversion lets you move files while preserving history.

It’s doubly a problem when two coders are trying to come to grips with the code base at the same time. While I was on one end of the room, adding handshaking code and modifying the interface, Tyler was on the other side of the room trying to make the connections use secure sockets. That meant we were each trying to modify the same section of code at once, and because we each had different concepts of what the original programmers had in mind from a style perspective, we stepped on each other’s toes a lot even with Subversion’s assistance to keep things straight. Despite our best efforts, checking in code that worked fine on one machine but that broke the other’s code base became a frequent occurrence.

(Thankfully, Subversion has numerous features—such as repository-wide versioning that lets you revert the entire source tree to the way it was at a specific point in time, powerful change tracking tools to figure out quickly which lines of code broke the program, and solid merge support—that made this far less painful than it could have been. And, of course, Subversion integrates very well with FogBUGZ, letting us track easily which check-ins fixed which bugs. Without Subversion, it would have taken us much longer to get here.)

Even if we had instantly made all the right decisions, though, stylistic variations would have hit us in another way. Large projects tend to have multiple standard styles for different components. The TightVNC project is a great example of this. vncviewer, which is the part of VNC that lets you control other machines, codes directly against the Winsock API in its ClientConnection class, whereas the sibling WinVNC server has a VSocket class that abstracts all socket communication and uses that class in vncServer and vncClient classes. WinVNC likewise makes extensive use of Windows’ Unicode string manipulation functions, whereas vncviewer codes against the ANSI functions. Classes in WinVNC are normally called vncFooBar or VNCFooBar, whereas classes in vncviewer are called just FooBar with no prefix. WinVNC makes extensive use of a pattern for dialog boxes that relies on threads; vncviewer lacks such a pattern.

This is not a problem in any real way; both code bases are solid, fairly consistent internally, and most importantly, as anyone who’s used TightVNC can tell you, very reliable. It’s just a bit confusing if you’re working in a project that has two fairly different styles to keep your coding appropriate, and the different high-level designs increases the chance that you’ll make a bad design decision by applying one project’s architecture to the other.

Would it be worth cleaning up? Almost certainly not. It would take a lot of time to get everything refactored to have a consistent style, and would come at no benefit whatsoever to the end-user. It does perhaps emphasize, though, that large projects (including Aardvark, thankfully) can benefit by having standard coding conventions to ease moving around the code base.

OpenSSL vs. GPL

Tyler’s been working on the encryption end of our product and asked me to look into a problem. The initial intent was to use OpenSSL encryption. The problem arose when we noticed the following clause in OpenSSL’s ambiguous usage license:

"Redistributions of any form whatsoever must retain the following acknowledgment:
'This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit'"

Well, Project Aardvark is built over an existing project licensed by the GPL which conversely states:

"You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
…
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
…"

There’s a contradiction here. Sure, we can put the OpenSSL acknowledgement in our distribution, but we also have to maintain the freedoms of the GPL in the sense that anyone who downloads our source must be able to modify whatever they want and then redistribute…i.e. they have the right to remove the OpenSSL acknowledgement and redistribute it. Requiring users to agree to keep the acknowledgement before downloading would conflict with the GPL.

OpenSSL’s FAQ has a question dealing with something similar, but it’s vague and doesn’t address our situation. I e-mailed the OpenSSL core team about the problem, requesting a limited license that would “forego this requirement, if only for future redistributions, of which we have no control”.

  I got the following response:
“That is unfortunately not possible. While the OpenSSL part of the library is under our control the SSLeay portion (which has a similar requirement) is not.”

I understand where they’re coming from. It’s only natural to want an acknowledgement to be included in any distribution of your software. But this conflict is a significant one. There are pretty good odds that a developer incorporating OpenSSL into his or her product might need to incorporate it with GPL source. It’s interesting that their website doesn’t address this issue more.

Rather than look for a loop hole, try to find a working agreement, or attempt to purchase a license beyond the GPL, we instead went with MatrixSSL, an open source project that Tyler found without any conflicting terms. When asked,
“So Tyler, you like MatrixSSL right?  It works really well?” he responded,
“Yeah you could say that.”

So I guess it’s working!