The Thanksgiving Weekend is full of fullness

Snowman!

Thursday, I awoke to a house full of purpose. We'd had a sudden snowfall this week, certainly bizarre for a place that gets very little snow ever, usually only every third year in late December through early February. The kids made a snowman while Omaha cooked her heart out, and I mostly stayed out of the way and tried to handle the laundry and cleaning.

We had two friends came over for dinner, and between the turkey, wild rice stuffing, mashed sweet potato casserole, handmade bread rolls, gravy, and gods recalls what else, we were stuffed to the gills.

And after all that, Omaha went to bed at 10pm and woke up at 2:30am to do that horrible Black Friday thing. She went out and shopped for ten solid hours, returning late in the afternoon with a lifetime supply of stuff, including a new TV. I was generally opposed to the idea of a new television, after all the old one was okay although it was a late 2001 behemoth that sucked down a huge amount of power and required two burly men to lift, whereas the new one could be picked up by a small girl with one hand, required less than a third the electricity, and had direct SVGA hookups, so Omaha and I tinkered with hooking up various portable computers to it and I'm satisfied that it's a fine purchase for the price.

I also worked Friday, but only a little. Dinner was leftovers. I've now eaten turkey four days in a row, and at least two of those days ate it twice in one day. Oddly, I'm not sick of it yet.

The entire house smelled of cooking, as I also put the bird carcass, drippings, and vegetable odds and ends into a pot and let it simmer for six hours, then cooled the pot in a bath of ice water, skimmed and bagged a gallon of the richest turkey broth ever. It's amazing stuff. Omaha asked me to keep one quart of it aside for next year's gravy.

Omaha, Kouryou-chan and I played card games in the evening. The kid was a handful to get to bed, though, mostly because her sleep schedule has been disrupted by the extra days off.

Saturday, Omaha and I spent the morning cleaning, and then went to the aforementioned friends' house for their Thanksgiving feast, which involed more people and yet another turkey. There was fun and alcohol and conversation. Thanks to our hostess!

Sunday was supposed to be downtime, but Omaha announced that we had all become fat and lazy, and we should go do something athletic. That "something" was to go to the swimming pool and spend two hours in the water. I did a quarter mile and felt okay doing it, not great, which tells me that both my general stamina and my upper-body strength are shot.

Of course, after doing something like that, we must compensate by a greasy meal at an American-style seafood restaurant that will remain nameless. Let's just say these people are ubiquitous, American, and think the Monterey Bay guidelines make for a poor bottom line.

A good four days of relaxation, more or less.

[Geekery] Have I latched on to a kook?

I've taken a temporary contract with another company, short-term, to provide a JSON-based front end, with a RESTful API, and one of the topics that came up was the RESTful management of lifecycle objects, those that exist only for a period of time before being dismissed.

The back-end architect and I went back and forth on defining a "task" and then launching a "job": the full RESTful method would involve asking the task for an empty job slot with a job ID via POST, then PUTting the job declaration there. I thought just launching the job via sending the task a POST would be sufficient: it defined the what, and it fits within the RESTful model.

Tasks, after all, have jobs; jobs are an element of the task state. Most people get this wrong about the difference between PUT and POST. POST is very broad: you're sending a message to an object at the service end that says "Change your state." That's all POST does. PUT is narrow: your message is "PUT this object at the location specified in the URL." You can do that many times, and it will always be the same; PUT is idempotent (multiple applications of the operation do not change the result).

But I thought it would behoove me to better examine the way REST handles lifecycle objects. Along the way, I stumbled upon the website of Jean-Jaques Dubray who, for lack of a better word, comes across as a kook.

That's not to say he's wrong. His meta-language, WSPER, a textual descriptor for lifecycle objects in service-oriented architectures (SOAs) is actually kinda brilliant, and caused me to consider hard the kinds of things I'll be facing dealing with client-server REST issues like describing lifecycles and managing race conditions.

Business process lifecycle management is a hard problem in REST. It's 2010 and we're still arguing about how to do it. Dubray is convinced that the problem is in the word "process"; what we're really looking at, he says, is an entity, an instance of a business policy that needs to be treated like any other resource, except that it has a lifecycle. He's created an entire architecture to describe the class-ification and instantiation of "business entity lifecyle" (BEL) objects and the meta-language WSPER to describe the way they transition from one state to another cleanly.

As I said, it's kinda brilliant. But Dubray's attitude toward the rest of the SOA world, especially Web Service Business Process Execution Language, is basically, "Those fools! Those fools! Don't they understand!? WSPER and BEL is the future! If only those fools at the academy would understand!"

That last link's entry is missing only the requisite "I'll show them! I'll show them all! Muahahahahahah!" Although maybe Dubray is practicing to be an evil overlord, and is appreciative of Directive 20.