Debugging a Shower

The big extravagance at the house this year is replacing the cheapest looking vinyl shower you ever saw with a very nice tile and glass block version. A friend of my wife's built it over the course of a month; it's beautiful. The babies have been learning the joys of showers over baths, and I've been spending much of my time pondering development problems from the built in granite seat.


Unfortunately, it's started leaking and in tracking down the leak, I've realized how broadly applicable the skills we pick up debugging software can be applied to the physical world.

Initial Bug Report.

After a lengthy bout of baby cleaning, my wife noticed a wet spot growing from the hallway wall shared by the new shower. She reported the bug to me as a high priority.

Observation of Bug's Behavior

The bug only manifested itself after a shower. And a shower of the babies.

Initial Conclusions

If the copper pipes inside the shower were leaking, then using the shower would be irrelevant; it would leak regardless of use. The only exception to this would be a leak in the pipe from the valve to the shower head. So no need to rip out the walls to get to the water pipes.

Experimentation

Working on the assumption that if the shower was leaking, it was doing so near the wet spot, and most likely at the most complicated part of the shower: the granite seat. So, I took my morning shower with the spray pointed away from the seat. Result: No wet spot. Conclusion, the seat was not properly sealed. There was a seam through which water could get through and into the outside world. This meshed well with the initial bug report, as the babies would tend to stand on the seat and have the spray directed at them there for long periods.

Rejected Alternative Hypothesis

Someone suggested that perhaps the flow was overwhelming the drain and a path to the outside was being reached from the bottom. This seems unlikely as the flow into the drain should be the same or less when the spray was pointed towards the seat. And 15 minutes of water directed directly at the drain disproved it.

Final Conclusions

Have to reseal all the joints, and re-grout the tile beneath the seat till we find the bad seam.

Visual Studio 2005 C++ and the ? : operator

One thing you want in C++ compilers is consistency with other C++ compilers. Especially if you are doing cross-platform development work. I want the VS C++ compiler to interpret what I tell it to do exactly the same way that gcc interprets it. That way, I don't have to special case my compilations, and I don't create a bunch of platform specific bugs in my platform neutral code. And usually, the two compilers do agree.


However, I discovered today (Friday) that if you compile something like:
double x = (false) ? 0 : 1.4;
that x will not equal 1.4 as most people (and the gcc compiler) would think, but rather it will equal 1.0. Why? Because it sees 0, interprets it as an integer and decides that if both halves of the : have to have the same type, then that type will be integer. The fact that this is in the middle of an assignment to double means nothing.

In order for x to equal the expected 1.4, you have to write:
double x = (false) ? 0.0 : 1.4;


I'm not even saying that Visual Studio is wrong. It's different from gcc which leads to platform specific bugs, and it's unexpected so the unaware coder will type in the unwanted form and not know something could possibly go wrong.

[Update: Russell Finn goes into more language lawyer parsing of this, and believes VS C++ is wrong. (I don't know Mr. Finn, I just like to read my Site Meter page to see how people get to my blog.)]


[Update 2: And don't let me get started about how VS C++ allows you to put the closing angle brackets of a nested template declaration without a space, as in:
vector<pair<string, int>> myVectorOfPairs;

]

News of the Not News: People Like Free iPhone Apps

This is one of those blog posts where the author has two data points and has to write an entire entry about those points. Here is the data: My iPhone app to help HDHomerun users align their antennas, Signal GH, went 5 days without a sale. This despite getting a favorable mention on a well known podcast on Friday. So I temporarily started giving it away to boost exposure and reviews. A day later, I had 205 downloads from the U.S..

So $2.99 equals 0 unit sales per day == $0.00 profit
And $0.00 equals 205 unit sales per day == $0.00 profit

At least I'm breaking even.

I believe a large number of these downloads are pointless, as you have to have an HDHomerun to do anything at all with Signal GH. There are people who troll the back pages of the utilities section of the App Store, downloading everything free. I just hope these people don't write reviews.

Thankful to be a Cocoa Programmer

The company I work for is interested in Microsoft's .NET framework; I am not. But, I was scrounging for free content on iTunes the other day and came across the .NET Rocks podcast, and out of idle curiosity downloaded a few episodes. They are well done, and put together by friendly people with an unflagging enthusiasm for Microsoft technologies. And they make me very happy to spend much—unfortunately not all—of my time working on Macs and iPhones.


Apparently, the target audience is comprised of developers putting together custom business applications; the kind of vertical apps corporate America (and apparently Dubai) consume by the megalines of code. Not the general purpose, high degree of finish, large user base applications I've spent much of my career writing, but database frontends and the like. It's the Bizarro world out there, where right justifying labels is considered a major advance in GUI development.


Any iPhone developers would be well served listening to the recent cast on Windows Mobile. As someone who was scrounging for work when the Mac had 3% market share, I can sympathize with the pathos of a product manager for Windows Mobile trying to put a brave face on disaster, but come on. This exchange pretty much sums up the level of wishfulness and straw grasping:
Host: So let me ask the question a different way: the next version, whatever it's called; should Apple be scared?
Rob Tiffany: Very scared.
Hosts: (laughs) YES!
Rob Tiffany: Very scared.
Hosts: I knew it.
Rob Tiffany: Yeah, yeah, we're working on some secret sauce out there.
Host: Not too secret anymore!

I will congratulate the hosts for not being blind to WinCE's current flaws: they gave Rob a hard time about how the phone app on their phone was glacially slow; I'm just amazed they think it will get better. That old saying about a second marriage being the triumph of hope over experience..


And the episode on complying with the corporate governance rules of the Sarbanes Oxley law... If I had to do that sort of thing, I'd seriously consider going to work at Home Depot. How does one show up at work every day doing that sort of thing?


And that's the thing. I'm nearly always happy either going into work—assuming I won't be spending the whole day fixing OLE bugs on the PC—or pulling out my MacBook and add a refinement to an iPhone app. Life is sweet. I get to work in an application framework which was designed right from the start; light weight and powerfully elegant. I'm not one of a hundred cogs living in a condo in Dubai; I'm a sole practitioner, or an unblended part of a small team. I write software people don't have to be paid to use. I don't have to wait for the secret sauce which never comes. I am a Cocoa programmer, and for that I am thankful.

The Loss of Homogeneity: iPhones on the Network

Developing for the iPhone and iPod Touch is nice: limited hardware differences leads to reliability. If it works on my iPhone running the 2.1 OS, it should run well on your iPhone. They are pretty much the same. Homogeneity is good when it comes to testing for program errors.


So your iPhone is the same as mine, but your network is not.

I submitted a new version of Remote Remote GH for OS X Touch to Apple a week ago. It had been gradually gestating and stabilizing has I had time to improve it. The last several weeks, it had been quite stable, and had never been much of a crasher to begin with. Thursday night, Apple notified me that the new version was available for distribution on the App Store; Friday morning RRgh crashed on me on launch. Wha?

Backing up. I had been playing with the XBox Media Center (XBMC) for the AppleTV, and last night I had tried turning on its UPnP (Universal Plug and Play) server and client. The new RRgh's big feature is support for auto-detecting MythTV frontends via UPnP, so having another UPnP device on my network meant my code had to check to see it wasn't a MythTV. Unfortunately, this revealed a latent crashing bug where I was expecting a string, got a NULL pointer instead, and boom, boom crash. (No actual audio percussion, just a silent quit.)

An early updater experiencing (what I assume is) the same problem figured out my e-mail address and let me know that I wasn't the only one.

So, I had to quickly remove RRgh from distribution pending a 1.1.1 release, as I have no wish to get a deluge of negative reviews from whatever small fraction of the populace would be affected by this. Which means, there is no RRgh currently available for download, as I don't have the option to revert to the 1.0 binary.

If you are one of the people who downloaded 1.1, I hope it isn't crashing on you, but I've submitted an updated binary which should be out within the week.

News of the Not News: QuickDraw Printing is Dead

As I occasionally let on, my day job is the care and feeding of an ancient, semi-well known, Carbon application (and worse its Win32 doppleganger, and worse still its Win32 doppleganger's OLE interface). One "perk" is the occasional confrontation with the living dead. The dead in question is how we print. We print using a very old and elaborate system of QuickDraw calls spiked with embedded Postscript. This creates very nice output. On Postscript printers. From PowerPC Macs.
For Intel Macs, not so good. Why? Because there is no embedded Postscript in Quickdraw printing support for Intel Macs. It didn't make the cut of creaky technologies Apple bothered porting over during the Intel transition. So, yes, text and polygons look OK, if imprecisely positioned, and that's most of our output; but anything splined based is bad as there are no splines in QuickDraw only very big polygons.
So, users of ancient Carbon applications: check out the printing on your shiny new Intel box.