Wednesday, May 30, 2007

Medium Rare: warm and pink takes discipline

Tonight for dinner we had some leftover hamburgers and hot dogs. It got me thinking about the burgers and dogs we had this weekend. My father in-law used to be a cook and actually has some formal education in this area, although I believe he mastered the grill on his own time - and he HAS mastered it. These burgers were not from this world. Surely they were flown down by angles on fluffy cloud plates and the Lord looked down and said, "It is good." They were cooked perfectly, juicy and flavorful - the melted cheese glistened like dew on a flower at sunrise. It hit the spot in the truest sense of the word, and I was especially proud because I was asked to do the grilling on this particular occasion.

And then, in a moment of brilliance, I uttered, "Grilling a burger is a lot like writing software."

No... wait... come back! I know it sounds like a silly thing to say, like "Weasels make good rain coats." Just let me explain first.

Have you ever met someone who was really passionate about what they do? Someone who was on a quest for the perfection of their chosen craft? I think one of the traits of people like this is that they are very particular about things that most people would find irrelevant. To follow the analogy - watch a Food Network special on BBQ champions. They are particular about everything in their pursuit for grilling nirvana: the type of charcoal they use, how much charcoal they use, how the charcoal is placed in the grill, how the charcoal is lit, how long the grill is lit before they cook, how hot the grill is, what kind of grill they use, what kind of meat they cook, how it is seasoned, what kind of spice rub is used, what kind of cooking method is used, what method is used to determine when the cooking is done, and the list goes on and on and on...

Now think about someone who isn't so passionate about creating a perfectly grilled piece of meat (which I consider to be medium rare). Perhaps they would just light some newspaper (because they were out of lighter fluid), throw on a chimney log (no charcoal and they needed something to keep it goin) and hang a grate over it (because they were out of aluminum foil). Now I suppose this cook might turn out a good piece of meat now and again (Hey, I've been there before. In college, we once opened a bottle of wine with a power drill because we didn't have a cork screw.), but I bet it's not nearly as often as our friend in the above section.

I don't know about you, but I don't enjoy eating "Cajun style" burgers that look like hockey pucks and taste only slightly better than the charcoal they were cooked on. Nor do I enjoy a squishy "play-dough" burger that isn't cooked at all. Not cold, fresh off the grill but rested just long enough so the juice doesn't run out when you bite into it. Not overly seasoned so that the meat loses it 's flavor, but not bland either. A burger that's had some thought put into it, cooked to perfection, served fresh, and made with a dedication to burger refinement that can only be rivaled by Macho Man Randy Savage's seeming love for "snapping into a Slim Jim" (viewable in I.E. - mac users click the download link). Ohhhhh yyyeeeeaahhhhhh - that's the kind of burger all of us crave.

I said all that just to say this: I won't make the rest (or really any) of the analogy for you. Dustin Diamond said "He who speaks doesn't know, and he who knows doesn't speak." So you can see why I stopped writing as soon as I was made aware, but I hope I you got you thinking about how you develop your software. Why shouldn't you develop your software with the same social awareness you grill your burgers? Would you be proud to serve your code to a stranger as they watch you make it fresh? Now if only the baggers at my grocery store would approach their jobs with some discipline - perhaps we'd all get the buns home without them getting smashed.

Waiter. Yes, hi. I'll have my code medium rare.

Note: I am not saying that being particular about aspects of your craft should mean that it takes longer to achieve your desired result or require more effort on your part to do so. In fact, I would argue that the reason people in the know are particular in the first place is that in their experience doing things in a particular way gets the desired result faster, or easier, or more consistently, or all of the above.

Thursday, May 24, 2007

Rockin' Like "Skin"ard

I started messing around with skinning and themes today in Flex. I'm not a graphics designer, but apparently I play one on TV. It was incredibly easy, as easy as CSS in an html page. It's pretty cool how you can take your bland, yet functional, flex application from zero to hero in just a few minutes. If you download a pre-built theme (scalenine is my favorite site for Flex themes), it's literally like 30 seconds to make your app da numba one stunna.

After a long day of reading and playing with graphics and styles, I went to my in-law's for dinner. The race is this weekend and my wife and I helped clean up a little and get things ready for all the guests. They live right by the track, so my father in-law always has a fantastic spread of food - they're probably the best host's I've ever met. People spend the night, go to the race, we pig out, go swimming, and then pig out some more (people usually start getting inebriated about this time). Then Erinn and I (and the rest of the fam) are left to clean up the mess (not that we mind - after all we helped make it).

So on the way home I was thinking over the day and it hit me - wouldn't it be nice if I could put apply a skin, style, filter, theme, etc... to my life whenever it suited me. I could put on a nice shiny skin when I need to impress someone, or downgrade to a more disheveled skin when I don't want to act too arrogant, or put on my goin out theme (the one with the cool filters) for, well...., goin out.

I sure am glad people like me for who I am. I mean, I think I'm a cool guy. Right Cool Guys?...

Guys?....

Monday, May 21, 2007

Cairngorm: Cares are gone?

The last couple of days I've been playing with Cairngorm. It's a "microarchitecture" framework from Adobe for developing enterprise level Flex applications. (If you develop web applications, desktop applications (checkout Apollo), or are looking for an easy way to put a front end on some software and haven't fiddled with Flex yet, you should definitely check it out.) After I rewrote some code using Cairngorm I compared it with the old code. There was much less code and more classes but the code was much cleaner and better organized. My initial impressions were good.

There is one thing that I haven't discovered how to do well in the Cairngorm framework: how to manipulate the view in more compilcated manners. For example, we have a login window that we implemented using PopupManager - it provides modality, grays out the background nicely, etc. But how should the model notify the view to remove the login window? The best I could find was the Observe tag by Alex Uhlmann (download) which allows you to "observe" a piece of data by binding to it and executing a function when the data changes.
What to do when the data hasn't changed though? Let's say I have the property

[Bindable]
public var isAuthenticated:Boolean = false;

in the data model. The problem is: what if the user actually failed the authentication? Setting this property to false will not update the view (no change occurred). I need a "tri-state" Boolean... yeah that's it! I'll call it a troolean. (Just kidding, don't email me about a "troolean".)

I thought about having the commands call a function in the view to take care of it directly, but then I realized that it defeats the point of the architecture. It makes the view and the commands too tightly coupled. What if the login window isn't being displayed or isn't set to a reference (it was implemented as a pop up, remember)?

I finally settled on letting the command display an alert to the user, so I didn't have to worry about it. If anyone has a better way of handling these types of scenarios, please let me know.

In the meantime, I think this framework is a huge step forward in my thinking about event driven architectures. But I don't think it's solved all my problems yet.