Dullroar

I've finally gotten the gumption and spare time together to release a tiny little logging library I've put together for formatting debugging messages and writing them to disk. It's called Quicklog, and it's aimed at C++ users on Linux.

What's so great about Quicklog? Its interface is very much like C++'s iostreams. If you can work with cout and cerr, you're already familiar with Quicklog's syntax. Many other logging packages use printf-style syntax, and working with that is just painful. My idea is that the easier it is to log, the more logging will be done, and then the easier it'll be to debug the system from the logs later.

Quicklog's other cool feature is that it's, ummm, quick. Especially on slower CPUs, the bottleneck in log writing is converting all those integers and floating point values into ascii representations. I fixed that by splitting the logging task: at runtime, ints and floats get written to disk in binary format, and then later, there's a postprocessing step to translate the binary numbers back to human-readable format. This split reduces logging overhead by about 80% for the workloads I've been using.

You can download Quicklog here. I hope that someone will find it useful, even though it lacks a bunch of features right now.

By the way, Quicklog has no relation to Quickdog, which was a dotcom startup. In the interest of full disclosure, I should say that my old company, 61C Networks, bought Quickdog's LCD projector when Quickdog went bankrupt. Therefore, I'm dedicating this first release to that LCD projector, which was acquired by yet another company after 61C's assets were liquidated.

Posted by Andy at 06:55 PM | Permalink

A while back, Kottke wrote an article making web-based apps work even when a user is disconnected from the network. I thought that it'd be a lot easier to get more net connectivity than it would be to make online apps work offline. However, Kottke has several good reasons for believing that offline is still important. I think his best point is that as we move more to online apps, our tolerance for disconnection will decrease.

Ok, so let's assume we want to build this offline web app support infrastructure. What's the minimum that a client machine has to provide to make it possible? I'm thinking just storage. Let's put a thing that looks like a web cache between a user's browser and the network. A web app can query for and then signal to the cache to ask it to pre-fetch, store, and retrieve records. Apps would also need to put a lot more application logic into the piece of the app that runs on the browser. I'm going to need to do some research on javascript/AJAX/etc. to figure out just how much pain this would be.

Posted by Andy at 02:20 PM | Permalink

Paul Graham's released another great essay called Ideas for Startups (that I saw while reading Joel). It contains some really good, practical advice about what it takes to go from two guys staring at each other over a cup of coffee to two guys with an idea. Here's an excerpt:

The initial idea is just a starting point-- not a blueprint, but a question. It might help if they were expressed that way. Instead of saying that your idea is to make a collaborative, web-based spreadsheet, say: could one make a collaborative, web-based spreadsheet? A few grammatical tweaks, and a woefully incomplete idea becomes a promising question to explore.

Wait, did I just say you should be talking to customers before you have something to sell them? Absolutely. Perhaps this is more true when selling to enterprises (as opposed to selling to consumers), but either way, it can save you months. I usually feel like the first couple conversations with customers are in a foreign language. The customer and I are talking about the same thing, but from very different perspectives. But it's vital to bridge the language gap in order to build up a model of how the customer thinks about the problem you're solving. And hey, he might even tell you that someone's already built the very idea you've been thinking about -- not a very pleasant thing to hear about, but it beats not knowing.

But how do you find potential customers who want to talk to you? What do you tell them? And when they inevitably tell you that your idea stinks, what do you do? Those are all hard questions, and I'll put off giving answers to other posts (and other people). I'll only say that it's difficult even finding customers to talk to (who wants to waste their valuable time on a product that doesn't even exist yet?), but the key idea is that it's more about listening well than pitching your ideas well.

Posted by Andy at 05:11 PM | Permalink