Paul’s Journal

Bloglines is looking for a engineering manager. Daily doses of Linux, C++, big clusters of machines, a website with massive growth, and more. As an added bonus, you can be working and read all of your unread items in Bloglines, all at the same time!

Interested or know someone who might be? Drop me a line: paul.querna at ask.com.

I will be at Gnomedex in Seattle, Thursday, Friday, and Saturday of this week.

From Alpha-Geek.com:

I was even able to find a blog of one of their workers – Paul’s Journal – though he doesn’t seem to talk about his $job too much.

It is hard to post about $job, because very little of Bloglines backend architecture is considered public information. For example, from the companies Blogging Policy Document:

“It is the Company’s policy that all employees, agents and contractors must keep confidential all information about IAC Search & Media or any IAC company’s operations, products and business activities that has not been made public …”

Which I believe pretty much includes how our custom distributed filesystem works, or how Bloglines is scaling (other than saying that memcached is awesomr, which is public), or even the details behind our new Atom Parser. It isn’t something I am too concerned about really, you don’t see anyone from Google posting the technical details behind Google Reader. It is just a standard in so many coporations to keep information close.

As Requested in the $job Blogging Policy Document: “The views expressed in this blog are my own and do no necessarily reflect the views of my employer.”

I started growing corn on my apartment’s deck a few weeks ago. I haven’t killed it yet. Only problem so far is the density — I planted too much corn in the pots. I think it will still turn out all right.

While this isn’t much corn compared to the Querna Family Farm*, I think its a good first crop.

EDIT: The link to the Querna Family Farm doesn’t work in Safari, since its not supported by Ask Maps. Here is the Google Maps Link

Look in the source to see it. heh.

The Economist has a new article up talking about Ask, Google and Friends.

Quote from Jim Lanzone:

…”we’re using search aikido”…

Chris Sherman of SearchEngineWatch:

… thinks that Ask is as good as Google for general web search—but better than Google for finding online maps and images. Ask, he thinks, is therefore starting to resemble Apple in the computer industry…

The Apple of Search?

Not quite yet.

There were 350 graduates from Mead High School(*) in 2003.I was one of them. There are are 106 MySpace profiles that claim to be graduates from that year too. 30% penetration in a group of 20-21 year olds.

I don’t have a MySpace profile. Maybe I am missing something important.

(*)Shocking side note, the Mead High School website is still running same stuff I coded for them in 2001.

I have been doing lots of ‘Web Development’ in C/C++ in the last year.

The current workflow currently isn’t that bad, mostly because we use ClearSilver to do many of the hard parts.

Now, ClearSilver is an okay template language, nothing amazing, but its pretty damn fast, and it works. However, ClearSilver also includes a “CGIKit” API, which tries to handle many of the hard parts of running a writing a CGI in C. I would rate the CGIKit as only mediocre, and I have had to dig through it a couple times to extend things or even figure out what the heck it is doing.

I have been thinking about writing a replacement for the CGIKit portion of the API, and using the Electric Template Language from Garrett.

For the API, I am trying to decide between a Monolithic approach, or a more modular one. A simple question: should the API create the concept of Handlers based on URI prefixes, or should you do that yourself?

For example, if the Toolkit was more Monolithic, you would have an API like this:

pwt_register_handler(”/one”, one_handler_func);

pwt_register_handler(”/two” two_handler_func);

pwt_run_handler();

Which would then call the appropriate function handler if the prefix was matched.

On the other hand, a more modular approach would look like this:

if (pwt_prefix_match(pwt, “/one”)) {

one_handler_func(pwt);

}

else if (pwt_prefix_match(pwt, “/two”)) {

two_handler_func(pwt);

}

Now, the second example is more flexible, allowing you to put hacks in as needed, but it means more code is written.

Of course, now you say, if you design the API correctly, you can do both, and easily degrade into the more modular method when you need that control, which isn’t the common case. Right, I have no doubts about that, it just means iterating on the API more before much is finalized, to find those points that need to be able to ‘degrade’.

The other challenge in the API design is that I want it to support a CGI mode, FastCGI Mode, and possibly a native Apache Module Handler Mode. I am pretty sure with some macro-magic that can be done — and hopefully without hurting either method significantly.

Lastly, I am having an internal debate on if it should be pure-C, or use C++. I think several parts could be made easier with C++ — for example you could make you own Classes based off a base PWTHandler and subclass them as needed to your own situation. I believe many C++ ‘libraries’ do correctly have a stigma to them — it is too easy to say, well, i need XYZ, and then just #include boot/foobar.hpp. And now you depend on Boost. C Libraries have a consistent history in open source of working well. While C++ is exactly the opposite for the most part. To people who read my blog, do you care which language it is in? Does either one matter to you?

I have little doubt that all of my goals can be accomplished in straight C, but I think it will end up abusing Macros in ways that I hate to get the lines of code per new handler down to the same number as in C++.