Preston L. Bannister { random memes }

For the record, I completely agree Jon Udell, both in regarding Monad (aka MSH) as a brilliant piece of work, and as having spent a fair amount of time battling antibodies myself. Episodes I remember:

• “You have to write in assembly for efficiency, not Pascal!” When writing an application in Pascal that ended up more efficient than it’s competitors written in assembly.
• “Why can’t I have a main program in my application, instead of event callbacks?” When writing a GUI framework (long before Windows).
• “Why do we need encryption and authentication?” When working on a distributed system long before widespread use of networks.
• “Writing upwards/downwards compatible client/server applications is too hard.” Right after having done just that at a prior job.
• “Web applications just cannot be practical.” When pointing out that most applications can and should end up as web applications.

Jeffrey Snover’s Monad is a brilliant piece of work (wish this guy had a website). It really does capture the strength of shell scripting in Unix, and takes things to a whole new level.

Doubtless the Unix folks can and will replicate this new abstraction in shell scripting, but in this case someone at Microsoft got there first.

Bought new toy — a “Roomba” robot vacuum. It is bumping it’s way around the downstairs now on it’s first run. It is a little noisy, though certainly not as noisy a regular vacuum. Will have to see if it can find the way back to the charging station. The downstairs is sort of H-shaped.

Yes, and the commercial is amusing

iRobot – Robots for the Real World : Commercial WM

Was curious how the dog would react. So far he just looks a little puzzled, and moves whenever this noisy little object heads his way.

Watching this thing bump it’s way into corners, under tables, and under the dining room chairs … I am starting to think this thing might actually be useful.

Update: Nope – it didn’t find the charging station. Will try a different location.

Update: Next morning let it loose upstairs. The upstairs with the doors to the kids’ bedrooms closed off is a bit smaller than the downstairs, and was badly in need of cleaning (more than a week since the last vacuuming). The poor little thing bumped around until it’s battery was exhausted, and the dust bin and insides were choked with dust. Bit of an unfair test, but I wanted to see how well it would do. To the credit of the designers, it did not get stuck once (though it did unplug one of the floor lamps). The upstairs could definitely use another pass, though I have to note the machine got into and cleaned places I do not normally reach with the vacuum.

My only (minor and tentative) criticism is that the thing either needs to have a bigger battery, or be a bit smarter about finding it’s way back to the charging station. Wearing the designer’s hat I would choose the second option. If you have a bigger battery, then you likely need a bigger dust bin. With a bigger battery and dust bin the manufacturing costs increase, and if the unit gets bigger it cannot get into the smaller places to clean. People with smaller places do not need the bigger battery. In larger places for the little beast to go back, recharge, then continue it’s run, seems entirely acceptable. Making the device a bit smarter should not increase manufacturing costs.

Update: Moved the charging station to a different location, and let the thing loose downstairs. The charging station was in one corner under a ~2′ square table. At the end of the run it clearly was trying to get to the charging station, but it just could not get past the opposite table leg. Moved the charging station to under the center of the table (no longer on the diagonal) and it found the charging station just fine.

Update: Let it loose again upstairs. It didn’t really finish the job last time (not a criticism as the upstairs was overdue). Opened the door to the hall bathroom, which it cleaned, but could not find it’s way out (stopped on the bathroom tile to hall carpet transition). Used a laundry basket (no batteries needed) to block it out of the master bedroom, so it would have a better chance at doing a thorough job.

Ouch!! It just fell down the stairs!! A short fall on carpeted stairs, so no damage. After the crash it made a little “uh-oh” noise (cute). It made quite a few passes at the top edge of the stairs before falling, so the algorithm used almost works . A bit later it almost went over the edge, but stopped just in time.

On reflection, cleaning the dusty innards is a bit more trouble than I’d like. Used a compressed air can to blow out dust where I could not reach (and got a nose full of dust). The filter assembly built into the dust bin is a bit flimsy and just a shade more trouble to reassemble than I would recommend for the general population. Might be better to put the filter on a hinge, with a “pull me” tab on one side.

Turns out the proper name for what I am attempting to do with isapi_reward is a “reverse proxy”. I want users to be able to access a number of web applications through a single machine, with the web applications possibly deployed on different machines.

Specifically I am interested in one particular use-case. I want to write web applications in Java, and be able to deploy those applications on a company intranet. I want the web applications able to run stand-alone (as sometimes that is all you need). I want those web applications work well on a company intranet, and most of the time that means support for NTLM authentication. I would also like to allow the web application to reside on it’s own machine, and be accessible to users through a common website with a stable (permanently bookmarkable) address.

By using IIS as a front-end we get first-class support for NTLM authentication. We also get efficient native-code SSL (https) support — Java code doing encryption is just not a good idea if you want to scale.

Note this spins the design considerations in a number of ways. I am not interested in caching by the proxy. I am interested in only the highest possible server throughput. I am interested in only the highest possible stability under load and over time. I am not interested in extraneous features that compromise throughput or stability.

This means supporting only HTTP/1.1 between the proxy and backend servers. This means keeping the connection(s) between the proxy and backend servers open for long periods of time, and multiplexing requests from different users over the same common backend connections (looks like this makes HTTP 1.1 pipelining dubious).

Got the re-write to use I/O Completion Ports working. I still find it spooky when large chunks of newly-written code work the first time . The connection-maker thread makes the connection, and passes the connection to the background I/O thread. There can be any number of connection-maker or I/O threads, but I suspect one of each is optimal or near-optimal for nearly all websites. Stepped through most of the code with the debugger (one of those “best practices” I find worthwhile). The request/response cycle between the client and the backend server through the proxy works, and headers are rewritten as I understand they should be.

That last is the current problem. Clearly I need to do something so the (relative) links in the response are interpreted correctly by the web browser. I think this means using the Content-Location and Location headers, but I still am unclear as to the exact semantics.

Also I am not interested in attempting to re-write HTML links inside the response (this just seems like a generally Bad Idea).

Reading the RFC is not enough to make this bit clear. Guess it is back to Google and a bit of experimenting.

Why is it that recipes always call for the same set of oven temperatures? Why does the 350° (Fahrenheit) temperature (plus or minus 25°) show up in so many recipes?

Cooking is a minor hobby, and lately I have been trying various approaches to cooking meat — of late specifically roasting meat.

I have experimented with higher temperatures. Sometimes the results are decent or interesting, but less than inspiring. Of late I am trying lower temperatures, and it seems the lower the oven temperature the better the results. Naturally the cooking times are longer, and to hit the desired internal temperature a temperature monitor (with alarm) is essential. I have done several small cuts of beef aiming first for 130° (good results), then 140° (better results). The flavor is rather nice, and the longer times the seem to make the meat tender.

Understand that I hate the taste of overcooked beef, so this meat is coming out nicely done.

Watching a cooking show I suddenly understand why so many recipes call for the same temperatures. Many recipes originate with resturants. Resturants need to perform their cooking in the shortest possible time. Resturants also leave their ovens on all the time, so they really need all their food to cook at the same temperature (though they might have more than one oven, each set at different temperatures). Naturally resturants will use the highest temperatures that deliver decent results, and will only use one or two different oven temperatures in their recipes.

Duh. Of course….

I have a 12 pound beef roast (the market had a half-price deal during the holidays) in with the oven set at 220° and the alarm set to 140°. Doubtless the cooking time will be long for this heavy piece of meat — but then I am not in any hurry.

I am tempted to try even lower temperatures. The digital control on my oven goes down to 170°. What I do not know about is safety. If the temperature is too low in the oven, will the meat spend too much time at temperatures where bacteria can multiply?

While writing this a possible answer came to mind: Use a higher 220° oven temperature until the internal temperature reaches 130° (at which point I believe we are safe from bacteria) then lower the oven temperature for the remainder of the cooking time.

When the internal temperature reached 130° I dropped the oven temperature to 190° to prolong the cooking time. Shut off the oven when the internal temperature reached 140°. With the oven off the temperature stayed at 140° for about another hour.

Result is decent. Going to have to buy more meat….

Guess it all depends on timing — and on who crunches the numbers.

One man’s retirement math: Social Security wins | csmonitor.com

The note about Britain’s retirement shortfall should snag your attention.

From Don Box Yet Another 2005 Prediction List:

Sun Microsystems will embrace Eclipse.
Eclipse 3.x is now way above the “good enough” bar and has IBM’s deep pockets behind it. In 2005, Sun will cut its losses on Netbeans and do the right thing for Java by unifying on a common tool platform.

Well, I suspect Sun has too much ego invested in NetBeans for this to happen. Maybe this is what Tim Bray is saying, though perhaps not intentionally .

Don’t get we wrong. NetBeans is a pretty interesting product, and each successive release knocks out some of the rough spots. Yet after trying each and every release of NetBeans, I just do not find any real advantage over Eclipse. Since I only recently returned to Java programming, I only recently adopted Eclipse (and used mostly JDeveloper during the last round of Java work – a few years back).

Competition between IDEs is a great thing, and if Sun wants to spend money on NetBeans … nothing wrong with that in itself.

What is wrong is when this causes fragmentation in the surrounding development community. Eclipse accepts plugins, and the plugins are largely developed by folks outside the Eclipse group proper. NetBeans accepts plugins, and doubtless many of the useful plugins are not developed by Sun. If building a plugin for Eclipse is too different from building a plugin for NetBeans — this is not a good thing.

If Sun wants to spend money building a better IDE — this is great.

If Sun fragments the surrounding development community more than absolutely necessary — this is uncool.

Of particular note are the Eclipse plugins to support languages other than Java, or frameworks other than those built by Sun. It is not reasonable (and not efficient) to ask those third-party developers to build completely different plugins for NetBeans — and NetBeans is the poorer for this.

My hope is that Sun will invest some effort in arriving at a “common tool platform” at the plugin level. This will contribute to making everyone more efficient.

Turned off comments today. The WordPress built-in checks for too many links in one comment, or certain common “spam” words worked well for a while. More recently Kitten’s Spaminator did an excellent job of suppressing the last wave of automated comment spammers.

Today a couple comments appeared with one link per comment, and none of the common spam words. I don’t want to make a hobby of cleaning up after spammers, so comments are off.

Seems that with “trackback” there is a lot less need for comments. On the other hand, I do not know if trackback (either outgoing or incoming) works with my WordPress installation.

Restarted work on the isapi_reward ISAPI filter/extension mentioned earlier.

The trick seems to be to handle outgoing connections (for forwarded requests) in an efficient and scalable manner. Started out using non-blocking sockets and events, but the WaitForMultipleEvents() call puts a hard upper limit of 64 on the number of active sockets. While it is rather unlikely that many sites would need that many back-end connections, I was not happy with the hard limit.

Turns out I had mostly forgotten about IO completion ports on Win32, as I had never had an application that called for their use before. Using IO completion ports removes the hard limit – though I have to wonder if Windows has limits on the number of associated handles (sockets).

Was a bit stumped at first about how to do the initial connect() or WSAConnect() as there was no mention of behavior when used with IO completion ports – then found a reference to ConnectEx(). which performs overlapped connections using completion ports – but only works on Windows XP and later. Guess that answers the question.

Since I’d like to support Windows 2000, looks like I will need separate thread(s) to perform blocking connect() calls. Likely this is not an issue, as the number and rate of connect() calls should not be an issue in expected usage. Might even be a good means to limit the connection rate when a back-end server is misbehaving.

One more re-write…