Beerd Silvertip New Zealand Pale Ale

More Anderson Valley

Oatmeal stout. Not very dark, again well balanced. Again, probably best warmer.

No lingering malt, could handle more. Hops are not very distinctive. But an enjoyable beer.

For style, 7/10. Overall, 7/10.

Last night, at Willow Street Pizza in Los Gatos, I tried the Anderson Valley Heelch O'Hops Double IPA.

The Double IPA was very fruity (as expected) but not overly bitter, surprisingly. It was well balanced, but not balanced in the "hellishly sweet and hellishly bitter", more subtle on both. It got a lot better when it got warmer, and if I had it again I would definitely let it warm; served very cold it was refreshing but lost a lot of its depth of character. The warmth brought out the richness of the sweet and the depth (again not just bitter) of the hops. It was more carmel than I expected, and the fruit was grapefruit and not too citrus.

Photography Advice

I thought about this for a while, and here are the steps to learning that I recommend to make learning a DSLR non-daunting. This is pretty close to the process I followed during my learning process. Each step could be a half day if you're intensive with it, and you don't need to complete each step before going onto the next one. But this is the order in which you're likely to comprehend what's going on. Think of these as progressively more difficult techniques for your new instrument!

Step 1: Full Auto
Put your camera on full automatic and see what it can do - shoot into the sun, try to focus on something non-intuitive, see how contrast works... experiment. It's just digital memory. As my dad says, the secret to taking good pictures is to take a lot of bad ones! Right now, don't use your flash, since your flash will confuse the learning process. If you need to get some pictures in bad lighting, use the flash, but don't make it part of your learning yet.

Step 2: Time Priority
Once you get a bit bored with that process (and you don't have to have mastered it), try time priority. It's pretty simple - you give the camera a hint on how long to keep the shutter open, and it computes the other variables for you (and it'll do the best it can if you're way out of range). Take the same picture with multiple time exposures. Run through the entire range of times - longest times in low light, highest times in sunlight. Try to shoot something that's always running and play with the blur effect: waterfalls and fountains are best, but cars will also do.

This technique is used to master the art of capturing blur.

Step 3: Aperture
This is the step where you'll get some really neat results that you just couldn't do with smaller cameras. Try aperture priority. Take multiple shots, experimenting with "depth of field". (See the pictures here: http://en.wikipedia.org/wiki/Depth_of_field) Get a hang for "large aperture or low f-stop = shallow depth of field and lots of light" and "small aperture or high f-stop = deep depth of field and little light".

This technique is used to master the art of 'framing' the shot by choosing how to draw the viewer's eye through selective focus.

Step 4: Timing
Get addicted to your shutter speed by trying to catch something at just the right time - a car passing by in the right place, or catch a water droplet from your sink. Your DSLR is MUCH more responsive from button press to picture. See if you can exploit this by finding the exact right time.

This technique - along with the other two - are used to capture just the right shot at just the right time. The correct time slice of the smile, or the perfect fleeting composition.

Step 5: Shoot, shoot, shoot (aka practice, practice, practice)
Master those things above. When you don't have your camera, think about how you'd line up the shot - roughly what parameters you'd use, and whether you'd do full-auto, timing or aperture priority.

Leading Change

Reading "Leading Change". It's a rare business book, immediately practical, based on lots of serious research *and* fun to read.

Complex Event Processing & Rules Engines

I'm currently investigating complex event processors and rules engines.

Windows XP embedded has a rules engine available (through the Windows Workflow Framework). I'm currently trying to figure out what I may have to add to be able to move it into a complex event processor. I think the only thing I need is "state".

But what's state, other than remembered transactions from the past? Therefore, if I simply add a rule that allows some results of the rules engine to persist for a while after processing...

For example, if I need event A and B to happen "close" to each other, I can write something like:

within (1 min)
{
event A condition;
event B condition;
} result (create side effect C)

... is that all I need for a simplistic CEP? If so, why don't more people do it this way?

Still learning...

Diagnostics

I have just been put on a 5-person team that is writing diagnostics for a not-super-huge system.

That should raise alarm bells.

Not that their intention is bad. Not that they aren't following typical practices. Not that diagnostics aren't vital to any and every system.

Just that it's not that interesting.

To me, diagnostics should be one of those boring problems that just falls out when you have good design. Decouple, use standardized interfaces, and inter-class communication just becomes well-designed points where you can insert a multiplexer for logging, etc. - all on the fly. You use the interfaces to find points of diagnostics and you can even do this all on the fly (especially in languages/runtimes that support reflection).

So why should this be difficult? In my current case, it's totally legit - we're interfacing with legacy components that are inherently not very easy to log. 90% of our work is in refactoring the legacy code to easily log its data, not in the diagnostics code itself. Think of how easy logging/diagnostics/monitoring (all the same thing, really) would be if that legacy code were modular.

(Interesting side question - if "legacy code" is "modular" and therefore it can adapt and live, would it ever be "legacy"? Of course entropy would eventually age it towards legacy, but its lifetime would be much, much longer.)

So design well. Decouple often. And never, ever write diagnostics aspects.