I can be such an idiot sometimes ... or, put in other words, the right way to solve a problem is often much, much easier than the wrong way.

For example, if you're doing woodworking, you may use a modern steel clamp to hold a part tight to work on it. That sounds good and does the job. Of course, when you need to change the position of the part you must unscrew it, reposition the part and rescrew the clamp.



So far, so good ... but, according to David Petersen, the author of Mouse Guard, there is a better way. Petersen researched medieval woodworking equipment for his Eisner-award winning comic and found there was a simpler scheme involving a foot pedal and a lever, which had equal gripping power but could release and reapply pressure in seconds just by lifting your foot.

Moral: newer and more complex is not always better.

Fast forward eight hundred and fifty years. Robert Kroese, a colleague at the Search Engine That Starts With A G, has his own book that he's working on, and an associated web site Mercury Falls. On that site he has a form to enter an email list, and I thought, what a great idea! I should have a form where someone can send me an email list on the Dakota Frost site.

So I started looking into it. To make the form work, you need not only a web form, which is easy to set up, but also some kind of server program on the back end which can accept the results of the form and a database to store it.

Historically, I've had bad luck with scripts and databases on my web sites: Earthlink / Mindspring basically welched on the scripting features of their web hosting that I was paying for, and my next provider, Tophosting, screwed up one of my databases.

So I was hesitant, and I started thinking. Then it hit me...



... there was a simpler way.

Instead of creating a form and the backend plumbing that goes with it, I should use the existing plumbing I had to achieve the same effect. What plumbing was already in place? A web site, a hosting provider, an ability to forward emails to a given address ... and a mail client with filters.



To make this work, I went to the GoDaddy control panel for Dakota Frost and set up a forwarding email: contact at dakota frost dot com. I had that sent to one of my catchall email accounts, and in Gmail I then set up a filter which collected all those email addresses into a single folder. Bam: problem solved.

Even if I want to do something more complex, this solution still works, as long as I keep looking at simple tools that are already available. For example, if I want an official email address list as a separate file, I could always download those email messages to the mail client of my choice, filter the messages to a folder, and grep over the email addresses in the file. For the scale at which I need to do it right now, the problem is still solved.

Moral of the story: the more you overthink the plumbing, the easier it is to stop up the drain. Keep it simple, and things should just keep flowing without effort.



Or, to translate this back into development speak: there are two kinds of solutions: solutions which are easy to think up, but take a lot of coding effort to make work, and solutions which require thought, but which can be implemented in staggeringly small amounts of code.

In this one, we have an extreme example: to make this problem work the "no thinking way" would require an HTML form, a CGI script, a database, and considerable configuration on the server side of my hosting provider. To make this problem work the "no effort way" required some thought, but in the end less configuration of my hosting provider and a few minutes setting up some email filters.



You see the same thing in software libraries: really good libraries don't take a lot of code, but that doesn't mean that they didn't take a lot of work. What happened behind the scenes was a lot of thought, wherein the library author searched the space of possible designs until he found a great one before ever publishing the library. You as the consumer don't see that effort, no matter how short or long it took: you only see the pure, parsimonious, elegant efficient piece of code that remains.

If you don't put thought into what you're doing, you might try it sometime. You'd be surprised how little thought can get you substantially improved results.

-the Centaur

Labels: Dakota Frost, Development, Webworks

My current excuse for not posting (other than feverishly trying to finish Blood Rock) is attending San Diego Comic Con 2009, the largest comic convention in the world. Here I'm seeing talks, meeting friends, working on Blood Rock, leaving flyers for Dakota Frost: Frost Moon, and enjoying the fantabulous nightlife in San Diego's Gaslamp Quarter:



You cannot explain how large Comicon is; you must see it yourself. I could show you the mammoth Exhibit Hall / Show's Floor / Noah's Ark of a Dealer's Room, but it is hard from a single picture to get the scale:



I could show you the external architecture, the huge steps and rounded escalator leading out of the upper levels (actually, the round escalator had just moved out of the picture at this point), but it is still hard to get the scale:



Perhaps only by showing the huge tide of people leaving after the Dealer's Room had closed can you truly see how large the San Diego Comic Con is:



It can take up to thirty minutes to reach your car in the parking lot, as we unfortunately found out today when we joined for lunch some friends who had driven. Halfway to the parking lot, you can see the length of the Convention Center, and can see why it takes up a significant part of the city on Google Maps:



Comicon has been held 40 times over the last 39 years, making it a cultural event only slightly younger than I am. This year is also Green Lantern's 50th anniversary, and the Con and its attendees are celebrating with special T-shirts, movie premieres, and of course, fan costumes:



It's all sold out this year, officially 126,000 but rumored to be as many as 140,000 strong ... but if you have even a passing interest in comics, movies or other popular arts, you should make at least one pilgrimage to check it out.

More later. Must crash.
-the Centaur

Labels: Sith Park

So I've mentioned before that I like pound cake, and that I'm working on a recipe. To make this go faster, for a few months I made pound cakes at home, cut them in half, and served half to my coworkers. Based on feedback from me, my wife, my friends, and coworkers (too dry / too moist / just right; more vanilla / less vanilla / you use vanilla?), and based on events during the cooking (collapses, crust cracks, etc.) I made changes to the recipe, which I tried the next time.

At first I thought of this as the scientific method, or at least engineering. And in one sense it is: I'm doing the minimum required to perform science, which is identifying a subject matter, establishing a procedure to study it, taking careful notes about the study procedure, and recording the results. And I'm doing the minimum required to perform engineering, which is identifying the is

But later I realized that my procedure is more like alchemy: tweaking something again and again without a true theory in the hope that tweaking it will somehow make gold.

To truly make it "scientific", I'd need much more. At a minimum, I'd need to make my independent and dependent variables explicit. The independent variables are the things that I control, like the recipe, whereas the dependent variables are the outcomes, like whether the cake collapses and how it tastes. To determine the true sources of power, I'd need to change just one independent variable at a time, such as the number of eggs. To control for confounding factors in ingredients, I'd need to make two cakes at the same time, one "control" cake with the old recipe and one "experimental" with the new recipe. Furthermore, the evaluation should be double blind: I should give slices of the cakes to someone without either me or them knowing at the time which recipe they got, so taste and texture would be evaluated without the knowledge of how the results "should" turn out. Each recipe comparison should be done multiple times to control for the small-n factor. And going beyond this, other things ought to be varied, like temperature, cooking time, egg and flour varieties, etc...

Ultimately, the goal of many such experiments would be a working theory of pound cake baking: what pound cakes are, how they are baked, and what role each ingredient and each baking step has in producing the cake. Only with such a working theory could you actually do true engineering. Engineering is not science; its goal is not understanding. Instead, the goal of engineering is to take a problem description - produce a good pound cake that satisfies my late-night sweet tooth - and use the best available understanding to produce the best possible solution to the problem. Unlike a scientist digging into the unknown, an engineer's task is to think through all the implications of the known for any potential solution to the problem. With a working theory of pound cake baking, an engineer can tell me how large a cake I can bake, whether it is feasible to bake a cake in the ovens that are likely to be available to me, and perhaps even the optimium size of pound cake for the heating characteristics of my oven. If this was a real engineering problem, a well-trained engineer would automatically go further, inquiring about the rate of pound cake consumption and the expected shelf life of baked cake, and might end up suggesting that I bake a smaller (or larger) cake so that I get the most pound cake for the least baking effort, while still ensuring that I eat it all before it goes stale.

Obviously, I'm not going to do all that. I'm going to tweak my recipe until it works right, then bake that cake and eat it. But if somehow I get tossed over into the Groundhog Day universe, I've got a plan to make the Best. Cake. Ever. All it will take is ten thousand trials...

-the Centaur

Labels: Pound Cake, The Killer Cookbook of Marie Curie