I cut my teeth developing for the windows platform with Windows++ by Paul Dilacia. It was about building a framework to wrap the Win32 api. Because of the elegance of Windows++, I never ever liked MFC. I disliked it so much that when I joined Microsoft, one of my ex-coworkers remarked “But you hate Microsoft” to which I replied “No, I hate MFC.”

Anyway, even though most people have moved on to managed code now, Microsoft continues to ship updates to the Windows Template Library. WTL is an extension to the Active Template Library that supports typical Windows applications (controls, dialogs, frame windows, GDI objects, etc). The new 7.1 version support VS.NET 2003, Windows XP and Windows CE.

I wish I had had access to WTL back in the day. I liked it so much better than MFC.

…but to really screw up, you need a computer. Or in the case of the BCS, you need seven of them.

I’m sure the Nokia Sugar Bowl officials are really excited about hosting “The Battle for Second Place”

SQL Service Broker is probably the least known new feature of SQL Server “Yukon”, but I can’t wait for it. It makes messages a first class object in the database. If you’ve ever had multiple processes banging on your database or you’ve ever used a flag on a row to indicate if it’s been processed or not, you want SQL Service Broker too.

While there is huge disagreement as to exactly what “Service-Oriented Architecture” is, I think there is some general consensus around the fact that it is an asynchronous message driven model rather than a synchronous RPC model. This means that the thread you receive a message on will never be the same thread that you process the message on. In fact, typically you will write the message to a persistent data store (hello, Yukon native XML support) in order to be handled by a thread in a different process and probably on a different machine. Today, kicking off the thread to handle the message is a pain in the ass. You probably want lots of threads across lots of machines to handle the incoming messages (assuming you’re getting lots of incoming messages). In order to synchronize message processing across machines, you need a mechanism to make sure each incoming message is handled once and only once. Today, the closest solution is message queue technology like MSMQ (or MQSeries). However, since that’s a different data store from where the data lives (i.e. the database), now you need two phase distributed transactions to get that done. However, since messaging is going to be such a huge piece of architecture going forward, it makes sense to have the concept of messages baked right into the database.

With Service Broker, when the message is received, it is placed into a service broker queue. (It’ll probably get stored for archival and retry avoidance reasons, but that’s a different blog entry.) Now I can have processes that, within the scope of a local transaction, receive the incoming message, make whatever data changes that message implies and send off any new messages. This is both more productive (manually handling local transactions for async processing is this kind of a scenario much easier than using serviced components) as well as more performant.

It may not be original anymore, but I set up a weblog for my wife Julianne. She’s always sending email out to all our friends with updates about our son, her job and other general goings-on, so I thought writing a weblog would be a good way for her to keep everyone up to date. She picked the name TechieWife in order to inspire the wives of techno-geeks everywhere. 😄

I noticed she got the address of my weblog wrong in her inaugural entry. What’s funny is that my friend Chris Church (no weblog yet) is so lazy that he bought devhawk.com and set it to redirect to devhawk.net. Now he can use IE’s ctrl-enter shortcut key to get to my weblog.

A few months ago, one of my first enhancements I made to dasBlog was to change the way the CommentView page is rendered. Previously, it was rendered using the item template. However, I don’t include the entry post date in the item template, since it’s in big bold letters on the day template. So I changed the CommentView to render the single entry being displayed using the day template. This makes the CommentView page consistent with the Permalink page, which also renders the single entry using the day template.

However, when I made the change, I introduced a bug that shipped as part of the v1.4 release. When I called ProcessDayTemplate, I passed in the entry’s CreatedUtc time as the day to render parameter. This caused an issue where the CommentView would not render the entry when the day of the CreatedUtc did not equal the time-zone adjusted created date. For example, if I posted a new entry at 8pm PST, that is 4am UTC the following day. So if I ask to render the UTC based date, the time-zone adjusted entry does not fall on that day, and thus doesn’t render. So I changed the call to ProcessDayTemplate to use the entry’s CreatedLocalTime property instead of the CreatedUtc. I tested, all seemed good, so I submitted the fix, which made it into the v1.5 release.

Today, I noticed a thread on the dasBlog GDN workspace indicating the bug was still there. A little bit of tracking down and I discovered that what the server thinks is the local time does not always match what dasBlog thinks the local time is. CreatedLocalTime is based on the server local time. If you run your server in a different time zone than dasBlog is configured for, you run into basically the same issue as before. Of course, since I run my dev server in the same timezone as dasBlog, I never noticed it. However, since my production server is on the east coast and I’m on the west coast, the issue showed up on my production machine.

I posted a code fix over on the GDN Message Board Thread. Basically, I calculate the correct time based off the dasBlog configured time zone. Seems to have fixed the problem on my dev and production machines. (I’m running my dev machine in a different time zone now). Let me know if you run into any more issues.