I’ve had some very interesting experiences when calling customer support, but last week a call to Comcast resulted in a whole new experience for me. After being on hold for about 5 minutes, listening to some of the most awful music you could possibly round up, a girl picks up. She greets me and then tells me apologetically (I hope) that her PC has got very slow and so she’s going to reboot it and will I please wait? For a profound few seconds, I stood there in incredulous shock. Though to be fair to her, she did come back after 3-4 minutes (pretty slow machine if it takes that long to boot) and she did help me out, and I somehow managed to resist making some weird joke asking her if she’d mind if I rebooted my PC as mine was getting a little slow too.
Recently I had the task of deploying an MFC application suite along with its dependencies via ClickOnce. Visual Studio does not directly support deployment of MFC applications (even if it’s compiled with /clr) and one of the suggested solutions I found on the web was to have a stub C# executable which would launch the main MFC application. That way you could take advantage of Visual Studio’s built-in deployment functionality. My friend Rama Vavilala had a better suggestion for me – he asked me to try putting in a dummy cpp file into the main project that was compiled using /clr. If ClickOnce accepted such an executable as a .NET assembly, then all I would have to do would be to create the required manifest files on my own. Well all I can say is hats off to Rama for his elegant solution – because it actually did work. This article is a step-by-step pictorial on how you would deploy an MFC application using this trick.
The CEO of my first company (who was an old time assembler/C programmer even before I was born) liked to periodically quote, “you either get pointers or you don’t”. I believe I’ve seen variants of that on the web – but I just did some Googling and could not find out who made the original quote (if there’s indeed someone who this is attributed to). Anyway I am not really talking about pointers here – I am talking about design patterns. The first time I read the GOF’s Design Patterns, I remember thinking that some of those patterns did look familiar and that I’ve used them without knowing what they were formally called. But I also remember thinking that some of the structural and behavioral patterns described in the book didn’t seem particularly useful – in fact I thought that it was just a big pile of complicated sounding text. But since the rest of the smart programming world accepted these patterns I remember worriedly pondering over whether I was one of those unfortunates who simply didn’t “get” design patterns.
Anyway I have re-read the book a few times now, some parts of it several times, some parts of it maybe a couple of times, and with each iteration I ended up with a “hey that makes sense now” feeling. I spent the last few days of this Christmas/New Year holiday re-reading the entire book and this was probably my best experience so far. I instinctively recognized familiar patterns that I had seen in use in MFC and the .NET class library, and I also began to understand certain patterns better (even those that I was previously sure I understood). I don’t think I’ve fully got it even now, but I have concluded that the key to getting design patterns is probably to apply them in many different scenarios and perhaps occasionally coming back to the book and giving it a quick read (1-2 hours should be good enough to scan the entire book and refresh your memory). And though design patterns is a subject that has been covered once too often in various blogs and articles I may occasionally blog about my attempts at applying known patterns to specific problems. That I guess would be my new year resolution (or at least one of a dozen others).