Tuesday, June 28, 2005 posted by Yaron Guez
or rather from the hotel the night before...
The booth is all set up, and everything is good to go. It looks a little bit like a high school science project but that's not neccesarily a bad thing. It should prove to be an exciting day, or at the very least an interesting one. We're obviously going to have to disclose the product at the show so here's your 6th and last
Aardvark Super Secret Disclosure: Aardvark is a support tool.
my next post will be a full on out product description so stay tuned!
Monday, June 27, 2005 posted by Tyler Griffin Hicks-Wright
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.
Monday, June 27, 2005 posted by Benjamin Pollack
I want to encourage all of you who are in the DC/Baltimore area to come and check out Project Aardvark at CFUNITED. You can talk to us, check out our software, and just chill. Instructions for how to get a free pass to the Fog Creek booth are available at Joel on Software.
Also, rather than do more long entries, I thought I'd try something a little bit different. Quite a few of you have tried to get in touch with me through various means, including posting in various forums, filing reports with Fog Creek Customer Service, and emailing other poor saps who happen to be named Benjamin Pollack. (Incidentally: my name is Benjamin, not Ben.) I don't really get any of those, except in rare circumstances, which is frustrating for both of us. Rather than force you to go through all of that effort just to have your email lost, I'm inviting all of you to email me at my actual address, bpollack.fogcreek@com (flip @ and .). I'll read through your mail (or at least what I have time for; if I get deluged, I'm going to have throw out what I can't get to) and post an article after CFUNITED responding to some of the more interesting messages. If it goes well, I'll consider having mailbag days on a more regular basis.
Just to be clear: "going well" does not mean I get all nice emails (although I certainly welcome them!). It means that the ones that are criticism are well-written and informative. I certainly don't have any misconception that I've had anywhere near the experience of Joel or Eric or the other big bloggers; my entries are about how a senior in college with eight years of hobbyist experience views the world. If you feel that I'm clearly off in left field, email and explain why! The worst-case scenario is that I still disagree, and either way, you've got a chance to make your case in front of 30,000 readers.
So send me your feedback! I look forward to reading it.
Friday, June 24, 2005 posted by Yaron GuezAardvark Disclosure #5: Though Aardvark connections are routed through our servers in order to work through any office or home firewall, 128-bit encryption will ensure that your data will be kept private from us or any eavesdroppers out there.
Friday, June 24, 2005 posted by Michael Lehenbauer
I’ve gotten complaints that I’m not posting enough. So to prove to everybody that they in fact really don’t want me to post more, I’ve written a long boring post about ASP.Net ViewState and localization. If you’re not into ASP.Net, you might want to just move along. =]
Since we apparently are amassing a pretty large readership, I’m going to take the opportunity to ask for feedback. If you happen to know of any good solutions to this problem, feel free to contact me at MJL at fogcreek.com. Thanks!
What is ViewState?
ASP.Net ViewState is pretty neat. The essential idea is that every page or control has a ViewState property which is just a hashtable that gets persisted between postbacks via a hidden input control. So if you had a webpage that was mimicking a wizard interface, you might do something like ViewState[“CurrentStage”] = “3” to indicate that you are on page 3 of the wizard. Then ASP.Net magically combines everything you’ve put in ViewState into a single hidden form input on your page. When the user clicks next, you can check ViewState[“CurrentStage”] to figure out what page of the wizard to show next. Pretty cool! (If you want a more detailed description, check out Understanding ASP.Net View State)
Why does it stink for localization?
Okay! That’s fine and dandy. The problem with ViewState is how it’s used. Every built-in WebControl in ASP.Net stores its properties in ViewState (hence the name). So if you do lblWelcomeMessage.Text = GetLocalizedString(“WelcomeMessage”), that localized string is now stored in ViewState. If you’re localizing an entire page like this, you’ll essentially end up with an entire copy of your page stored in ViewState which gets rendered to a ridiculously large hidden input field on your webpage. Lovely!
There are really only two ways to avoid this. The easy method is to disable ViewState. You can turn off ViewState for any control or for the entire page by setting its enableViewState property to false. The obvious problem with this is that then you can’t use ViewState!
The second method is to do all of your property setting in the Render stage. If you look at the ASP.Net Control Execution Lifecycle, you’ll notice that “Save state” occurs directly before “Render.” So any changes made during the Render stage will NOT be part of the ViewState on your page. So you can just override the Render() method, do your localization there, and your ViewState remains unbloated. Yay!
But this latter way gets ugly. Let’s say we need to perform validation on the inputs in our wizard. We only need to perform validation if they click "next." If they click "back", then it doesn't make sense to do validation. So ideally we'd trigger the validation from the next button's onclick event handler. But that will get called during the "Raise Postback Event" stage which happens before "Save state" which means when we do lblEmailError.Text = GetLocalizedString(“EmailRequiredError”), we're bloating our ViewState. Boo! =[ So instead, we have to set a flag like fDoValidationLater = true which we check during the Render stage when we can safely do the validation without bloating ViewState.
Currently, I really have no good solution. For the aardvark website I used the latter workaround, but am starting to regret it. Things are kind of messy in a few places. I think I might go back and just disable ViewState globally. I’ll have to rewrite some code and use my own hidden input fields, but I think the end result will be cleaner.
Another possibility is to not use the built-in ASP.Net WebControls. I could create my own LocalizedLabel user control that doesn’t store its Text property in ViewState. This would be okay, but I wouldn’t really want to create new versions of every WebControl I use (buttons, drop downs, etc.). Additionally, if I create my own user controls, I won’t have the nice Windows Forms designer support… I really like being able to create a control like <asp:Label id=”lblEmailAddressPrompt” runat=”server”>[localizeme] Email Address:</asp:Label> and then see the actual text when I look at it in the designer.
I’ve heard that ASP.Net 2.0 has new localization features. I haven’t looked into this much, but hopefully it addresses these sorts of problem, because it’s a real pain. Again, if anybody has any suggestions (or any burning questions about Fog Creek internships or whatever), feel free to email me at MJL at fogcreek.com. Thanks!
Friday, June 24, 2005 posted by Joel Spolsky
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..
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!
Thursday, June 23, 2005 posted by Benjamin Pollack
FIX AND CONTINUE
Firstly, thanks to the numerous people (including Joel) who pointed out that VisualStudio.NET does support fix-and-continue for C/C++ and has since Visual C++ 6. Oops. The reason I didn't know that was that incremental linking was turned off, since the project was created by importing a Visual C++ 4 project, and fix-and-continue requires incremental linking in order to function.
My new question, though: when incremental linking is disabled, and you modify a file in a running program, the dialog box that pops up just says something along the lines of, "VisualStudio needs to restart the program for your changes to take effect." Since there aren't a ton of compilers that support fix-and-continue, it never struck me as particularly odd that VS.NET would be incapable of it. Why can't the dialog box say, "This program was not compiled with incremental linking, so VisualStudio must restart the program if you want your changes to take effect immediately" with the options "Restart With Changes," "Stop," and "Continue Without Changes"? That would at least give enough information to know that there is this thing called incremental linking that means I don't have to restart the program, and my new message is no longer than their existing one. Using verb-based buttons instead of Yes/No/Cancel would also mean that you could skip the text if you really wanted and still figure out what you need to do based on buttons. Just my two cents.
BRANCH FOR CFUNITED
And in other news, Tyler and I are about ready to tag one of our builds as the official CFUNITED build. We're hoping to do that about lunchtime. Yesterday made me very confident about the build we'll be using; I managed to shut almost ten bugs that have been nagging me for a couple of weeks and get things like user-friendly error messages up that contribute to users thinking a program just "feels right." I'm pretty confident that everything will be working well for CFUNITED.
After the conference, I'll be turning my attention back to the UI of one of the client programs. One of the programs is basically done at this point; it's been refactored, looks nice, has internationalized error messages, works pretty well, and as of yesterday is basically feature-complete. (It's missing one feature that I'm adding today, but that's it.) The other one works OK, but needs a heavy refactoring in order to make some superficially trivial UI changes, and then I need to just shred both executables until they get smaller (they're 500 kB and 300 kB; I want to get them both under 200 kB). It's nice to finally see everything pulling together into a cohesive product that people will actually be able to use.
Thursday, June 23, 2005 posted by Tyler Griffin Hicks-Wright
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."
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...
Wednesday, June 22, 2005 posted by Yaron Guez
I did a whole lot of copy work today. I've also been back and forth between our graphic designer and Kinko's several times. Leerone came with me to Kinko's to proof the poster and place the initial order for the brochure yesterday. He lasted about 5 minutes before the manager yelled at him to stop filming. That was amusing. I mean after all, there's a whole world of FedEx Kinko's enemies out there eager to see the their inner workings, right? I went back this afternoon to proof the brochure and pick up the posters. The posters ran into a problem during printing and have to be redone but the brochure looks great.
I've also been corresponding with our quality control person, sending her pieces of copy as I finish them. She's been actually really helpful. I wrote up a product release for CFUNITED and looked over the registration packet they sent.
I did some more press relations yesterday, following up those that haven't got back to me with phone calls. The ones I got in touch with gave me some updates. They all sound pretty receptive and told me who they had referred the story to for further consideration.
We finalized a negotiation today that is pretty sweet to not have to worry about anymore. More on that later.
Aardvark Disclosure #4: Aardvark works through all home and office firewalls, requires no installation, no configuration, and takes 30-seconds or less to download.
Wednesday, June 22, 2005 posted by Tyler Griffin Hicks-Wright
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.
Wednesday, June 22, 2005 posted by Benjamin Pollack
For the past few weeks, I’ve been working almost all of the time in C++. Every once and awhile, someone files a new bug against the Reflector, and I go in and work in C# for an hour, but by and large it’s all C++. Not only that, but the C++ code I’m working with is was fairly poorly designed; it’s very hard for me to check in more than a couple hundred lines per day on a very good day, simply because so much of my time is spent trying to figure out how exactly to modify the code we’ve got to do what I want.
Just as a random example about what I mean, one of the applications currently does not display its main window until after a lengthy connection procedure. I want it to display its main window immediately. This ends up being a very, very complicated change due to a bunch of assumptions in the code about when the window gets displayed, but I’m not even focusing on that. I’m focusing on figuring out what code to modify. There are variables called m_hwnd and m_hwnd1 and WNDPROCs named WndProc and WndProc1 that represent entirely different things. Moreover, just for fun, though m_hwnd and m_hwnd1 are different window classes and represent radically different functionality, their respective WNDCLASSes are given the same WNDPROC. To fix that problem, the programmer changes the WNDPROC on a per-window basis eight lines later by calling SetWindowLong and passing in the actual WNDPROC. Why? I don’t know. There are no comments in that method. Even if there were, this obfuscation makes it needlessly difficult to figure out which window is which. After carefully reading through a printout of the code for 40 minutes yesterday evening and scribbling notes all over, I renamed the variables m_hwndViewport and m_hwndMain. But really, why weren’t the variables just given sensible names to begin with?
That’s actually not what drives me most insane about working in C++, though. What drives me nuts is the lack of a REPL.
REPL stands for read-evaluate-print loop, and refers to an interface that takes a line of programming code, executes it, prints a result, and immediately returns. It’s basically just a fancy name for a command line. Most dynamic languages have a REPL, or something similar. Ruby has irb, the interactive Ruby interpreter, Python fires up in interactive mode by default, and so on.
The thing is that a language based around a REPL actually changes how you go about developing code. When you work on C++ (or any language without a good interpreter), generally your development procedure goes like this:
- Write a core piece of functionality
- Litter it with print statements if that’s your thing
- Compile (this still takes 30 seconds for our unoptimized 400 kB program)
- Fire it up under a debugger
- If the program starts behaving oddly, put in some breakpoints
- Start stepping through code when you hit one, inspecting variable contents and paying careful attention to the call stack
- Discover suddenly what you did wrong
- Quit the running program and make some trivial modifications
- Recompile (another 30 seconds) and try again
There are three problems here: firstly, you keep having these breaks where you need to recompile the program to integrate your change. Sure, they’re “short,” but it’s enough to break your flow for a few moments and make you lose track of exactly where you were going with your train of thought.
Secondly, there’s no quick check for ensuring that your fix actually works; you have to make your best attempt to patch the code based on your understanding of the error and start the process over again. If you analyzed the problem correctly, your chance of getting it right is very, very high, but you still may have made a fairly bad mistake if you even slightly misunderstood the error domain. (Tyler and I, for example, had an incredibly taxing couple of hours yesterday simply trying to figure out which program was causing one of our bugs, and we misdiagnosed the issue several times in the process.)
Thirdly, you can’t easily write and test just a small amount of code. In most languages, your only option if you want to do this is to write a test suite for your class protocol, which takes a lot of time during development and probably isn’t necessary for a lot of smaller stuff.
Developing with a language centered on a REPL is a totally different experience. Here’s basically what developing in Smalltalk looks like, for example (though Common Lisp and Scheme work basically the same way):
- Add or modify a few methods in a couple of classes
- Open up a Workspace (Smalltalk’s REPL) and print out the results of some arbitrary code that tests what you just wrote
- If you hit a bug, you can easily inspect any value in the entire system to find the error
- Once you find it, make the change, massage any “damaged” data back to pristine state by hand using the Workspace, and then resume execution where the breakpoint happened to see whether your fix worked
Notice: there’s no compile phase, it’s trivial to work on small pieces of code, and hitting a bug does not mean rapidly switching gears, but instead means you to try your fix in the running code right at this very second, and you get immediate feedback on whether your fix was correct. Step 4 has been rechristened fix-and-continue and has appeared in a more limited way in some more traditional languages, such as Java 1.4, C# in .NET 2.0, and C and C++ in Apple’s versions of GCC, but the other parts of the process simply don’t really exist.
The good news is that you can approach a REPL style of development in .NET by using an interpreter. Although I don’t quite buy that .NET is language-neutral (write in any language, as long as it’s object-oriented and has no more or fewer features than C#!), that mantra has brought forth tools like IronPython, a Python implementation that runs on .NET and takes full advantage of .NET’s toolchain. When I was working on the Reflector, the fast compile speed of C#, combined with IronPython’s ability to load assemblies on-the-fly, meant I got very, very close to REPL-style development using traditional tools. I would write some code in C#, hit compile, jump to IronPython, reload the assembly, and check out the code I’d just written. When I found bugs, I’d run some code against the problem classes, try out a fix or two in Python, then move that fix to C# when I was convinced I had properly diagnosed the problem. The constant shift between Python and C# was a little bizarre, but eventually my brain just got used to the concept that debugging was in Python and new code was in C#. The ability to so rapidly test and diagnose errors played a big part in letting me get the Reflector done as quickly as I did and actually having the result work.
If you’ve not tried REPL-style development before, but are afraid of or don’t have time for languages like Smalltalk and Common Lisp that are built around them, I’d still strongly encourage you to give a tool like IronPython a try. IronPython 0.7.5 runs on .NET 2.0 beta and is available from Microsoft. IronPython 0.6 runs on .NET 1.1 and is what I’m using here. And, if you like it, consider trying out one of the REPL-based languages. I have a hunch you’ll find it highly addicting.
Monday, June 20, 2005 posted by Yaron Guez
All the hardware necessary for the tradeshow next week is set up. It's all labeled and laid out nicely. I also designed an icon for our demo. I put together a better version of the Overview section of our product website than the one I had written a couple weeks ago and put the Terms of Service in there as well. This morning I brought the poster files over to Kinko's and set that all up. Our brochures should be ready tomorrow to bring to the printer as well. I also did a bunch of stuff I can't talk about yet...but on that note...
Project Aardvark Ultra Super Secret Disclosure Numero Tres: Aardvark is not something that the average user will use regularly. But when you do need it, you'll be very thankful it's there.
Friday, June 17, 2005 posted by Yaron Guez
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
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.
Friday, June 17, 2005 posted by Joel Spolsky
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!
Thursday, June 16, 2005 posted by Benjamin Pollack
More miscellaneous updates (I'll post a coherent thing tomorrow maybe; I just don't have the attention span for it right now):
PREVIEW OF HEROES OR ZEROS
Not for you; for us. Lerone sent us the first few minutes of the documentary he's working on. It's extremely weird to see yourself in a movie, but it's actually looking pretty good.
The clip Michael posted, incidentally, is not from the documentary. He's been videotaping like nuts on our DV, so that's what that's from. (Lerone's filming in HD on a very nice Sony that he nevertheless feels perfectly happy sticking out taxi windows for good shots.)
Today, we demoed a complete end-to-end run of Aardvark for Joel. It crashed in a way it's never done before, and we can't replicate it. So that stank. I'm spending the rest of the day now systematically trying to reduce the number of bugs assigned to me in FogBugz to zero, which, according to my best estimates, is about 18 hours of work. Hopefully, that estimate is more liberal than it needed to be. I'm also doing really hard things, like adding a Fog Creek logo to the about boxes. Man, some days...
I finally concluded today that I like the current Windows API over the old classic Macintosh API that Apple had in Mac OS 9 and earlier. So if I ever develop a time machine, go back to the late nineties, and get into programming on Windows NT and 2000, this would be my platform of choice.
I think I've honestly gone out more evenings over the past week than I went out last semester at Duke. New York is just so much better for that kind of thing (go New York subway!). Friday was Broadway; Saturday was a movie; Monday was something I don't remember right now, but it was good; Tuesday was hanging out with a friend from Duke and his 7 closest high-school pals; and last night I had a spectacular dinner with a good friend of mine I hadn't seen in a long time. In case that's not enough, tonight Fog Creek's all going out to the Yankee's game, Saturday all of us interns are going to a comedy club, and there's a very high chance I'll get stuff lined up for Friday or Sunday too. That I'm still coherent at work is somewhat amazing to me sometimes.
So, I rambled off earlier on how specs make life a lot easier, and I still stand by it. We're keeping the spec up-to-date religiously, so at any given point it's a superb reference to see how things ought to work. Occasionally, though, the spec can lead to a lot of confusion if you don't use it right. For example, we added some challenge/response stuff to the protocol. Tyler and Joel worked out how that would go, and added it to the spec. I then modified the Reflector to obey the spec. In the process, I found some slight ambiguity in exactly how things should be implemented, so I picked a way, modified the spec appropriately, and promptly forgot about it. The next day, I forgot that I'd tweaked the spec, remembered only the original passage, and implemented the challenge/response in the client programs in exactly the wrong way. It was very quick to fix, but also a bit annoying to realize what I'd done. So: if you're going to keep the spec religiously up-to-date, make sure you also read it, or it won't do much good.
Why is New York insanely hot for a week, then, when it finally cools down for a baseball game (perfect!), it rains. This is not fair.
AND FINALLY, A SHAMELESS PLUG
To any comp sci majors or minors at Duke who are reading this blog regularly and looking for a half-credit course, I would strongly encourage you to sign up for my house course (HOUSECS 79.04: Open-Source Design and Methodology). There are still 15 seats left, and Drew and I would love to have you there. We won't have iPods for ya, but I promise it'll be a tremendous amount of fun. I'm hopeful we'll actually build a real open-source product and "ship" it before Winter break (that part will be optional though if we do). Best of all, it's pass/fail, so you can't go wrong.
Thursday, June 16, 2005 posted by Yaron GuezI blame the subject of the last post entirely on the awesomeness of Batman Begins and the morning after effects of a midnight premiere. Oh, and I'll get Michael back. Just gotta think of something good.
Thursday, June 16, 2005 posted by Michael Pryor
Fog Creek is one of the top companies to work for as a software developer. Even the interns here have cushy jobs ... Maybe too cushy.
Wednesday, June 15, 2005 posted by Yaron Guez
I finished our brochure for CFUNITED the other day. It looks pretty good but I still sent it to our graphic to make it more professional looking. I ended up using Photoshop and Publisher with images from the blog and came up with a tri-fold that reveals our product, in detail, for disclosure at the conference. I wrote up a full marketing game plan for the rest of the summer outlining the things we need to get done and how we should go about doing them, as well as details for our booth at CFUNITED. I’ve got several ideas that will help get the word out. I really liked the Apple promotion where they gave free iPods with class schedules to the entire freshman class at Duke. Getting an entire class hooked on your product as soon as they start college is a great way to lock in a target market. I’ve got a similar idea for our product that I can pitch through my job at school. I’ll worry about the logistics of that once we get version 1 done, which isn’t all that far off!
Yesterday I had an interview with a freelance writer who’s written for the New York Times, Details, and Financial Times. He sounded really interested and said he’d get something to pitch to his editor and get back to me. I’ve been getting in touch with several other news outlets, playing up the small-company-big-internship aspect of the project to get us into the business world niche. What’s especially nice about this job as opposed to marketing projects I’ve done in the past, is that I don’t have to spin anything to make it sell. It’s genuine to say that that this project would make a very interesting news piece, just as it’s genuine to say that the result of this project will be an incredibly useful product.
I made plans with our graphic designer to start thinking about our website, but the real dialogue will take place once the brochure is finished. I’m going to call around a bit more to see if I can get a better price on the printing than the one we have right now.
I’ve settled on a name for the product as well. We have a first choice and a backup. I’ve been talking with a lawyer who’s currently looking into the trademark implications of our first choice name, which, if secured, would result in a rather pricey domain transaction, as opposed to our backup name which we’ve already registered and can use immediately if need be. It’s a little frustrating that I spent so much time designing logos, mascots, and concept web art for names that we didn’t end up using. But that’s the nature of the game, I suppose.
The pricing model is pretty much set at this point, with various nuances that I’ll discuss in later posts. I can’t mention a lot of the stuff planned for you know, marketing, reasons, but I certainly don’t plan on, nor have I been enforcing the others towards, total radio silence.
Wait, what? Letting out details about the product before its release? What are you trying to do, generate buzz? Well, I don’t think Joel likes that very much. Well, Joel may pay the bills but this is our project and me thinks buzz = good. Sure, the product isn’t out yet, but does that mean any buzz generated now is wasted? I don’t think so. What good is a project blog if no one reads it? We can only be completely vague for so long before everyone loses interest, and once you lose a reader, it’s a lot hard to get him or her back. Yes, there is the competition factor to worry about, especially as our actual code can be replicated by any talented group of programmers (wait, was that another clue? Yes, I believe it was). But the fact is competition is inevitable. A slow leaking buzz might give some rival team out there a head start of a few weeks, but at the same time it will provide us with the leg up we need to secure the market before the competition launches their product. Marketing rule number one, get their first. I’m not too worried.
So, in accord with the above, I will “leak” something new about Project Aardvark here every other day from now until launch. Unlike the more recent subtle disclosures these will be explicit. So without further ado, I give you,
DISCLOSURE #1: Project Aardvark will be awesome.
Ha, no but seriously: Project Aardvark is more of a service than a product.
Chew on that for awhile =)
Tune in next time, same time, same channel, for disclosure number 2, and thanks for visiting!
Wednesday, June 15, 2005 posted by Michael Lehenbauer
There’s been a lot of posting lately, but I know what you’re thinking: What about Michael? What’s the status of the website!? I NEED TO KNOW AND I NEED TO KNOW NOW!
Well, fear not, your wait is over. I’ll fill you in! The main page of the website is basically done (though it’ll remain kind of ugly until we have it prettified by a graphic designer). I've started work on the code for handling payments, but we’re shifting our focus to getting a functional demo ready for the CFUNITED conference, so for now I get to pretend that Aardvark is free! So yesterday I spent some time writing code to modify executables on the fly before handing them off to the customer for download. Fun stuff!
Overall, things have been going pretty well, but a bit slower than I’d like. ASP.Net is cool, but it can be kind of frustrating if you don’t know exactly what’s going on under the hood. I’ve used it in the past, but it turns out I had some pretty major gaps in my knowledge. I’ve learned all about the ASP.Net page lifecycle, why ViewState doesn’t usually do what you want, the inflexibilities of the form validation controls, why VS.Net and subversion don’t like each other, and lots more. It’s slowed me down a bit, but I’m starting to feel like I have a pretty good grasp of ASP.Net which makes me happy.
Incidentally, .Net Reflector (not to be confused with our C# Reflector or .Net Reflection) has been incredibly valuable. It disassembles the .Net Framework libraries (or any .Net assembly you throw at it) and provides a very nice interface for navigating the disassembled code. Documentation is nice, but sometimes you really just want to see the code…
In unrelated news, one of my favorite New York activities so far has been running. In the past, running has on occasion become slightly boring. This is definitely not a problem in Manhattan during rush hour! Dodging strangers left and right, jumping over bags of trash piled in the sidewalk, sprinting to make it across the street before the light changes... It’s like an obstacle course! Way fun.
Tuesday, June 14, 2005 posted by Tyler Griffin Hicks-Wright
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.)
Tuesday, June 14, 2005 posted by Yaron Guez
After 2 weeks living in New York City I have to say that the stereotype of New Yorkers being rude is pretty unfounded…with one major exception.
Subway etiquette. Now, I don’t know, it might just be a
But yeah, other than that, and a very obnoxious series of encounters with the sales people at Harry’s Shoes on Broadway while trying to buy sandals that won’t destroy my feet, New Yorkers have been cool.
But the Yankees still suck.
Tuesday, June 14, 2005 posted by Benjamin Pollack
Tyler and I are getting into a routine whenever we have inexplicable crashes in our C++ code. First, check to see whether an instance variable is getting trampled. If it is, copy files modified since you last checked in somewhere else; blast the entire directory; do a fresh checkout from Subversion; and then copy the files back. Simply clicking "Clean Solution" is not sufficient. Any ideas on what's going on here? (And yes, we were smart enough to check for invisible files.)
GOOD CODE DESIGN
For the love of...something, if you're going to take the time to write classes, then please make at least some attempt to split your user interface code from your implementation code. This class I've been working on for the last two days is 4000+ lines long and is basically the entire program. I wish they'd just used procedural C instead; it'd be a lot easier to work with.
On a similar note, if you have two procedures literally named "Proc" and "Proc1", with no comments about what they do, you may need to get out more.
Over the weekend, my family was in town, and we had a chance to see Wicked. Watching a Broadway show truly on Broadway, instead of on tour, is a truly awesome experience; I'm trying to figure out now which to go to next.
I also saw a movie with a friend of mine at this theater called the Ziegfeld. The Ziegfeld is a digital movie theater that looks like a concert hall with a screen instead of a stage. The theater is truly beautiful, the seats are spacious and comfortable, and the sound system is awesome.
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.
Monday, June 13, 2005 posted by Benjamin Pollack
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.
Monday, June 13, 2005 posted by Yaron Guez
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!
Monday, June 13, 2005 posted by Tyler Griffin Hicks-Wright
About 11:45 last Friday I was diligently working on refactoring some code when Michael asked me if I had read Joel’s e-mail. I said I hadn’t, so he informed me that the office would be closing in 15 minutes and that I should wrap it up. I checked my inbox to find this wonderful message:
I thought it might be fun to go to a movie instead of working...
We have 12:45 lunch reservations at Chevy’s in Battery Park City and 2:25 reservations for the opening of Mr. & Mrs. Smith, so let’s officially close the office at noon today.
Not that I'm not enjoying my work. In fact, I was a little disappointed that I wouldn't be able to finish what I was doing in time, but I'm certainly not about to turn down an afternoon off, especially one filled with pre-approved, sponsored fun.
(BTW The movie is very entertaining, just don't expect some sort of cinematic genius.)
Thursday, June 9, 2005 posted by Yaron Guez
We narrowed our name list even further and actually secured a couple of possible domain names. I’m still waiting to hear back from a few domain squatters as well. In the meantime I wrote out a Terms of Service contract built on a template that I made with bits and pieces of other similar contracts. I’ve been making various adjustments to our copy and FAQ based on the program changes we’ve gone over in the past few days. I also wrote a general marketing strategic game plan to get us through to the trade show at the end of the month. That should be a lot of fun. I have a few friends in DC I’m looking forward to meet up with.
I’m getting the hang of this big ol’ city more and more with each day. I’m a big fan of hanging out on roof tops, getting some sun and looking at the SimCity-esque view of the mammoth city around me. Coming from the Boston area I especially love the 24 hour subway system here as opposed to the T back home that shuts down at 12:30 (!!). It’s a great feeling having an unlimited metro card and just knowing that I can go anywhere in the city whenever I feel like it regardless of the time of night.
It’s been kind of a hassle to meet new people in my building as there’s no central lounge or lobby area to hang out in. The only place you really meet anyone is on the elevator and you have all of 30 seconds to get their name, where they’re interning and what room they’re in before they disappear to their floor, never to be seen again. Actually, I’ve had good luck meeting people through those sharing music on iTunes using their AIM screen name as their shared name. Go figure.
Ben, Ben’s friend Ilya, a guy named Steve who I met through iTunes, and I went out Tuesday night for the seemingly simple task of getting some pizza. Dissatisfied with the pizza places in our neighborhood we decided to get on the subway and head to the village. It was all well and good except that none of us are from
Ben and Ilya headed back home after dinner while Steve and I decided we had come too far to just settle on pizza so we kept trekking in the other direction looking for something of interest. I spotted a couple of girls that I thought I recognized from school and flagged them down with “hey do you guys go to Yale??” Sure enough they did and we tagged along with them to one of those trendy (read “expensive”) clubs that you hear about in the movies that don’t have a name or banner, in the meat packing district (for some reason I thought that was just an expression. Nope. Lots of meat warehouses), with crazy covers and a guy you have to tip to get a paper towel when you go to the bathroom. Long story short we get back around 3:30 from a 7 and a half hour “dinner” excursion.
Yeah, this city’s for me.
Thursday, June 9, 2005 posted by Benjamin Pollack
I've been sick and not sleeping well for the past few days, and it's finally catching up to me, so this will be short, but I want to take a moment to give a hat-tip to the Ethereal project. Ethereal is an open-source tool that lets you monitor all Ethernet communications. It has a decent GUI, provides robust filtering, runs very efficiently, and has been invaluable over the last couple of days in finding bugs in our code. I fixed three or four major crashers today, including one that's been nagging me for over a week but that I haven't been able to troubleshoot due to lack of data. Getting rid of that bug made me feel much better (and also solved some superficially unrelated problems as a side-effect).
The good news is that Tyler's making great progress on his security code, the e-commerce extensions are looking good, the Reflector's getting increasingly robust, and with these major crashers in the clients gone, I'm free to focus on the GUIs and enhancing usability. We've had various levels of prototypes running with increasing robustness over the past week, and I've got great confidence that we'll have a solid product ready for CF United. We'll undoubtedly have lots of bugs to fix in the beta cycle, but it's nice to be getting to the point where we could almost demo Aardvark all the way through and have everything work.
Tuesday, June 7, 2005 posted by Yaron GuezAh, nothing quite like playing the waiting game on all those domain name sale requests. Good thing i have a stack of marketing books to read.
Tuesday, June 7, 2005 posted by Benjamin Pollack
Last week, I promised that I would post about how you can get a REPL in .NET and why you care. I failed to actually follow through on that promise, largely because I forgot, but also because I have been spending an awful lot of time attacking heisenbugs that result from my still rather gap-strewn conception of how Windows message processing works in multithreaded applications. So I’m sure that everyone will be very excited to see that I remember my promise, and today will happily follow through by writing instead some random musings about New York City. This is the fourth in a six-part series. I will be writing entries five and six next, and then go back and write the first three entries at some later point when I feel like it.
(Hey, I can’t blog on technology all the time, but if you’d at least like something computer-related, I’ll point you to Maciej Ceglowski’s response to Paul Graham’s famous “Hackers and Painters” essay. (Note: essay is not for the humor impaired or people who like to show how “mature” they are by getting offended.) Otherwise, stay for the chat.)
I come from a small town near Indianapolis, Indiana. I have always liked Indianapolis. The city, especially in the last ten years, has grown tremendously, yet it’s still very easy to drive for ten minutes and get to rural suburbia. Another ten minutes can usually put you in at least fields and usually small forests, if you know where you’re going.
Duke is in an even more rural setting. The Triangle actually has a fairly sizeable population, but it’s spread over such a wide area that the overall feel is that you’re never really in an urban area. Downtown Durham, Raleigh, and Chapel Hill are far less developed even than Indianapolis, which has a small but surprisingly vibrant city center.
So it shouldn’t be much of a surprise that trying to live in New York at first was like having a massive caffeine IV jammed into your carotid artery 24/7.
Joel gave us each a book, Time Out in New York, that lists lots of stuff to do in the city. The book is as thick as AAA guides for some of the states I’ve visited. In the book’s introduction, it states something along the lines of, “New York has a reputation for being this insanely packed metropolis where everyone is always in a hurry and small children end up being shoved off the sidewalk into sewers where they are devoured by rats the size of some of the smaller models of Toyota. This is in fact not the case anywhere, except maybe on Fifth Avenue, and even then only during peak business hours, and besides, many New Yorkers have domesticated sewer rats as exotic pets.”
This is a lie. Not only have sewer rats not been domesticated; the sidewalks really are packed everywhere. At least half of the city generally seems to be on the same sidewalk as I, going in exactly the opposite direction with such rapid speed and with such concerned expressions that I have to assume they have severe problems containing their bowel movements and are in urgent search of a restroom. That, combined with New Yorkers’ love for using their horns to convey such messages as, “We are stopped,” “we are moving,” “my car is turned on,” and “I have a horn” meant that I was pretty much on sensory overload for a few days.
Once you get past that, though, and get used to the fact that the city is always moving, New York is awesome. The same fact that makes the sidewalks packed also means that there are a tremendous number of people to meet and that anyone who complains of nothing to do is just being lazy. Within one block of where we live, there are probably two dozen restaurants, numerous bars, a large shopping complex, and a posh gym. All the theater you could ever want is just a short subway ride away, and the subway runs efficiently and generally is easy to use (except at 3 AM, when the subways switch over to Random Track Mode, but that’s another story).
The buildings, too, are kind of incredible. The first week I was here, I was living on 33rd St. and First Avenue, and I actually commuted to Fog Creek on foot. Part of the fun of doing that was that I got to walk under the Empire State Building every day, which, at least if you haven’t grown up here, is truly an awesome experience. Indeed, height is everywhere; the apartment in which we’re staying is taller than any building on Duke’s campus, and would probably leave a decent mark on Indianapolis’ skyline. The city is one giant mechanical marvel.
New Yorkers have also been very friendly; everyone I’ve talked to has been more than happy to answer questions about the city, and some people, especially on street corners and on the subway at night, are even willing to provide me advice without my asking. Seriously, I know that New Yorkers have a reputation for being rude, but my experience has led me to think that that stereotype probably dates from a different decade. People have universally been helpful and curteous. The city also feels surprisingly safe, and it should; crime in NYC is among the lowest of the big cities in the United States.
What do I miss? For one thing, grass. There’s not nearly enough of it. Central Park is nice, but it feels (and is) artificial, a kind of oasis in the middle of a world defined by brick, mortar, concrete, steel, and a faint scent that smells suspiciously like pee and oil. There are no forests. I can frequently look up and see trees in penthouses, Brett maintains a tomato plant in the office, and I have a nice orchid on my desk, but it’s just not the same as being able to wander around real wooded trails a mile from your house. I also kind of miss silence when outdoors: although Fog Creek’s offices and our apartments are quiet except for the air conditioning (and when I’m cooking, the fire alarm), it is very, very hard to find any place outdoors where you cannot hear music, cars, or both.
Despite that, New York has been incredibly exciting, and I honestly think it makes a great place to live. I’m really looking forward to being able to explore more of what New York has to offer over the coming nine weeks, and have little doubt that I will be very sad to leave NYC in the fall and anxious to return.
Until then, sadly, it’s me versus heisenbugs. If you’ll excuse me...
Tuesday, June 7, 2005 posted by Tyler Griffin Hicks-Wright
Yesterday we finally got a project that made us feel like real interns: Re-wire the office. Due to some hardware changes and an existing desire to upgrade the wiring to CAT-6, we had to pull almost all of the existing network cables down and replace them with the new stuff. Fortunately, Joel forsaw this as happening at some point in the future, so he made sure that the office had a nice wire tray that runs from the server room to all the offices. If you haven't checked it out, read about the "Bionic Office" on Joel's website. With the trays, we were able to replace over 300 feet of cable in just a little over an hour.
Today, I am continuing to work on the security protocols of Aardvark. It took a while to find a suitable open source package that had a GPL compatible license, but I finally ran across one last Friday, and have been able to implement it pretty quickly. It's an interesting (read frustrating) caveat of the GPL, that a very minor and sensible requirement of other open source libraries, such as including the developer's name(s) in distributions, creates a licensing nightmare. Gotta love the law of unintended consequences.
Monday, June 6, 2005 posted by Yaron Guez
We had a product name brainstorming session this afternoon. I gave all the names I had come up with and wrote down a bunch more that others threw out there. We narrowed the list down to about ten names. We avoided generic sounding names that straight forwardly convey the product’s purpose but at the same time we didn’t settle on any no-meaning words. We ended up somewhere in between with a few positive sounding compound words that have somewhat to do with our product but aren’t explicit about what it does (vague much? Yeah I know). I’m not overly crazy about any of them but we should be in good shape with any one of them. Since then I’ve been looking up domain information, and, surprise surprise, they’re all taken. I’ve contacted all the domain contacts and have already heard back from one (with an absurd opening offer I might add), so I guess I’ll just wait and see.
In other news, the party at Michael’s place Friday night was a blast. Lots of interesting people and lots of expensive booze. We definitely left a man down but I got a mildly reassuring thumbs-up before abandoning our fallen comrade on the bathroom floor and making the drunken trek back to our apartment. Good times were had by all. At least from what I remember….
Monday, June 6, 2005 posted by Michael Lehenbauer
As an added bonus, if I ground the aluminum foil, it'll block Microwave Mind-Programming Signals!
Saturday, June 4, 2005 posted by Joel Spolsky
Decaffeinated: "Names don’t build brands. Brands build names."
Saturday, June 4, 2005 posted by Michael Pryor
It's 3AM saturday morning and the party is officially over. I think someone scored a date with the other interns who showed up at the party. Someone else is passed out on the bathroom floor (no names please - let's allow the guilty to presume to be innocent). A whole day's worth of food and who knows how much liquor has disappeared. Thank goodness Lerone, the film director, stopped filming after the first hour or we would have embarrassed ourselves silly for the whole world to see.
I'll call that a success.
Thursday, June 2, 2005 posted by Joel Spolsky
The guys are making good progress. I think we'll probably have something ready to demo at the ColdFusion conference in DC (June 29th - July 1st). No, Aardvark has nothing to do with ColdFusion, although the kind of people that go to that conference are probably in our target audience, so we'll be able to get a lot of early feedback on features, positioning, etc. by showing it to attendees of the show at the Fog Creek booth.
Thursday, June 2, 2005 posted by Yaron Guez
I’ve been spending a lot of time looking at competitor’s websites. I’ve put together a document outlining their different price models, features, prospective targets, and pitches. It appears that there are relatively few, if any, products approaching the specific niche that we’re targeting, which is good to know. The basic functionality of our product has a lot in common with many alternatives, but what will set it apart is our target audience as well as our approach to a specific problem. Pricing is going to be a significant issue to address, as whichever scheme we end up going with will have a drastic effect on how this thing fairs.
I’ve been shooting around different name ideas. I’ve put together a list of different words that can be grouped in various combinations for a good name. I’m torn between a two word combination that conveys the products functionality and a one word name that is irrelevant to the functionality but which stands out in the customers’ minds more (think Internet Explorer vs. Firefox, ShareScan vs. Kazaa, Coca-Cola vs. Pepsi, etc). At this point, I’m leaning a bit more towards the one-word irrelevant name since there are so many similar products out there, a functional name might get lost in the mix. But it’s definitely still up in the air.
I’ve started writing out a FAQ for the website. I’ve also been reading Al Ries and Jack Trout’s advertising bible, Positioning: The Battle for Your Mind that Joel gave me. It’s a really interesting book and has a lot of pertinent information that will help set our product apart in the minds of our customers.
I feel this product has a lot of potential to do very well. This project is proving to be a very interesting undertaking.
Wednesday, June 1, 2005 posted by Michael Lehenbauer
In case you’re keeping track, there are indeed four interns. Yesterday my major accomplishments included installing/configuring a bunch of applications and spinning around in my (rather spiffy) chair, so I decided to refrain from posting about my exciting day.
Today I started digging into the website portion of Aardvark. Since Fog Creek doesn’t have a great deal of ASP.Net code, I went ahead and wrote my own routines for basic templating and localization. Now (pending a code review) I should be able to plow through most of the website pretty quickly (it’s not too big). After that, I’ll have the pleasure of integrating with the Fog Creek payment system. Should be fun!