November 2007 Archives

sudo defaults write /System/Library/LaunchDaemons/com.apple.WindowServer 'EnvironmentVariables' -dict 'CI_NO_BACKGROUND_IMAGE' 1

That is all.

Sometimes, when working with a certain codebase or API, you find yourself working on a problem or feature that just won't fit given the constraints of said codebase. I ran into such a problem the other day working with the MFC CRecordset class and probably spent a full day thrashing against it's walls, trying in vain to figure out a way around it's limitations. This is fighting an API.

I find that it's usually a good idea to take a walk for a bit to clear your head and maybe think about taking another approach, because when you're spending that much time working around an API, you're doing something wrong--your overall design is probably flawed and you're just going to run into more problems like this down the road.

But what to do if you can't backtrack and redo your flawed design due to time constraints and legacy concerns? This is the situation I found myself in right now--we were using autonumbers is an odd way that just wasn't going to work. I eventually found a pretty ugly workaround, but it's only going to be a losing battle from here on out with this app. Hopefully, I'll get the chance to rewrite this thing and do it right.

I picked a new Airport Extreme yesterday to replace an aging and somewhat flaky Linksys WRT54G. I never really believed that the Apple touch could extend to routers (it's a router, how much design does could it possibly need?), but now I'm convinced, and as always the most impressive thing is the software accompanying the hardware.

When I first set it up, I noted with some dismay the lack of a web administration interface, which I thought was pretty standard on most modern home routers. What you get instead is this nifty little application:

Short version:

Did the Bluetooth module on your Mac disappear after running Comcast's modem activation software? Zap the PRAM (restart and hold down Command-Option-P-R).

Long version:

Having immense difficulties doing a video chat with my dad, I went to the handy Circuit City Connect store near me to swap my cable modem for a new one assuming that it may be a network problem. The Comcast people complied and even rejiggered my plan to give me a $20/month discount to boot. Good deal. The trouble started when I plugged the new modem into my existing network and tried to get back on the Internet.

As it turns out, Comcast's network somehow detects a new modem and forces you to a re-activation page when you load your browser. Fine, I get it, they don't want people swapping cable modems willy-nilly. They provide you a link to a program that, according to the page, must be run on your local machine to complete the process. This was the first red flag.  The second red flag was the installer needing administrative privileges. My impatience got the best of me and I entered my credentials allowing it to continue and restart my computer. I opened Safari and attempted to navigate to a site. Only problem was, my keyboard wasn't working. Odd, I thought. Opening System Preferences told me the whole story.

The Comcast software had somehow managed to delete the Bluetooth module from my Mac. Which was a problem, seeing as how I needed to, you know, type things from time to time. Luckily I had a spare USB Bluetooth dongle that worked as a temporary fix. Shutting down, and pressing the Command-Option-P-R keys on my keyboard forced the PRAM to be cleared and that seemed to force my machine to re-discover the internal module. I then noticed in the Network Preference pane that the Comcast installer had completely dicked up my network settings and deleted all my network connections. Yikes. Way to test your software guys.

I code in C++ a lot at my job. Well, more like MFC, which is technically a set of C++ wrappers around Win32, but is about as far from plain-vanilla standard C++ as you can get. And I find myself raising my fists like little balls of rage to the heavens every few days when I see something like this:

class SomeBigClass
{
    private:
       HelperClass *m_pHelper;
       ImportantPointer *m_pImportant;
    public:
       ImportantPointer *GetImportantPointer()
       {
           return m_pImportant;
       }

       SomeBigClass() 
       {
       	   m_pHelper = new HelperClass(this);
	   m_pImportant = new ImportantPointer();
       }
       
       void DoSomethingInteresting()
       {
           m_pHelper->DoSomethingHelpful();
           m_pImportant->DoImportantOperation();
       }
}

and then, lo and behold after many access violations, wailing, and gnashing of teeth, the following is discovered in the source for HelperClass:

HelperClass::DoSomethingHelpful()
{
    // blah blah blah
    // ...
    delete m_pSomeBigClass->GetImportantPointer();
}

Now, the argument could and should be made that a helper class should never be deleting pointers that it doesn't own--this is just bad design. But what does one do when encountering such a problem? Refactor? Work around it in the consuming code?

I don't think there's a good answer, at least not without having more information about the context. But now that I have a few years of experience under my belt as a software-talking-guy, I understand that half the battle is simply recognizing these anti-patterns and just dealing with them.

This problem's an easy one. Refactor it. Work around it. Rewrite the method. But I've learned that if you want to be something more than a junior developer toiling away in the junior developer salt mines, you have to take the initiative and fix stuff that's broke when you see it.