The lagging edge

I was taking my daily glance through MacSurfer when I was struck by a press release from WaveMetrics announcing a new version of Igor, the data graphing program. That brought back memories, Igor was my absolute favorite graphing program back when I was in Chemistry grad school in the early 1990s and it could always be depended upon to make the slickest output of the myriad Mac or Windows programs used at what was then called the Center for X-Ray Lithography. I have not seen it since graduating in 1995, and it is good to see it is still alive.

But what really caught my eye, that it is now in 2009 that Igor has moved to Quartz rendering from QuickDraw. According to Wikipedia Quartz was first demonstrated at the 1999 WWDC and has been the recommended mode of rendering on OS X since its introduction. Such is the inertia in the software business that an application as graphically intensive as Igor, a program which would benefit hugely from the modern features one gets for little effort with Quartz, takes 10 years to make the transition.

I wonder if the proximal cause of this laggard transition is the impending doom of Snow Leopard, where QuickDraw using 32-bit apps are distinct second class citizens. A "Pro" graphing app, might well benefit from 64-bit status, and to do that every single QuickDraw call must be expunged. Apple had spent enough time on carrots in making Quartz a beautifully clean API generally superior to QuickDraw in every way, and is now bringing down the stick of enforced obsolescence to bring the last stragglers into the fold.

I will be doing this transition over the course of the summer, myself. I'm down to 800 or so deprecated symbol warnings, so I've a ways to go before the day job application sees 64-bit nirvana.

Star Trek Lessons for Safari

A little noted part of Monday's WWDC keynote was the final feature set for Safari 4. Safari now has searching of browsing history. This reminds me of this exchange in the first season of Star Trek: The Next Generation:

Cmdr Riker: "Data, I need help in locating some library-computer information. All I have is a vague memory of reading somewhere about someone taking a shower in his or her clothing."
Lt. Cmdr Data: "Ah. The body Geordi discovered."
Cmdr Riker: "And I believe it may have happened before."
Lt. Cmdr Data: "To 'someone,' 'somewhere.'"
Cmdr Riker: "Should be easy for someone written up in biomechanical texts."
Lt. Cmdr Data: "About that... did the doctor believe I was boasting?"
Cmdr Riker: "Probably. This may take some time?"
Lt. Cmdr Data: "At least several hours. But what I said was a statement of fact."

It would take Data several hours to search all of Star Fleets records for instances of people showering in their clothes. Such records are quite voluminous. Searching for "shower clothes" gets 23,200,000 hits on Google now, it must be many times more in Data's day.


However, the proper data set to search is every bit of text that Riker had ever read, a much smaller set. As every viewer knows, Star Fleet personnel rarely read paper books, those tend to be kept in glass display cases; they read Kindles. And it wouldn't take much programming to keep track of every page that was ever displayed on a Kindle, or displayed in the browser on your computer.


If I remember seeing a bit of information I now need, like the name of the product manager for Keynote (yes I happen to want to know this), it would be quicker looking in web pages I've seen than it would be googling against all of man's knowledge. I doubt I read as many as 100 pages a day. My browser history says I visited 120 URLs on Monday, and that was a heavy day. Humankind as a whole must be writing 10s of millions of English text pages a day, and has been doing so for quite some time.


But to be truly useful, this data set has to be maintained over one's entire life, and include computers, smart phones, Kindles, and every other gadget that tells us something. So, history search is in Safari, but that's only a start.

The Wonders of the iPhone Star Rating

So, I have my free MythTV remote in the iPhone App Store and it only has a 2 star average rating.



Not exactly a Gaussian distribution.

I think that there are a class of iPhone users who download every free app they can get their hands on, whatever it's description of use, and then later tidy up, delete the app and give it a 1 star rating. For free apps, you should only go by the ratings of people who bothered to write a review.

Of course, reviewers can be pretty picky. Here are some nearly representative 1 star reviews for RRgh:

“Trop compliqué, pas ergonomique, trop cher.. bref! tout faux. A déconseiller fortement." (Google translates this as "Too complicated, not ergonomic, too expensive .. short! all wrong. A highly recommended.” 1 Star

“I love this because of it's ease of use. All who done know time consuming getting myth to work the way you it is so this application come is a fresh breath of air. I use myth on my 64bit Suse 11.0 box an it took me less than 3 minutes to set up my box to work with the app. I want to note that mymote has not worked for me yet which is disappointing because I think the interface looks better. Just remember that your default port is 6546 and your ip of your myth box. After that just enable it in the setup/utilities -- setup -- general option.” 1 Star

“A virtually flawless app I use it all the time, no more looking for the remote, it's always in my pocket! My only suggestion is to add the ability to schedule recordings if possible
Thank you
Dave” 1 Star

I will freely admit that out of 10 reviewed 1 star ratings, 7 didn't like the app, mainly because they didn't know MythTV. Fair enough, MythTV is not for the casual computer user, or someone who gets paid by the hour. My major point, if I had a point, is you should read the reviews of free apps, their star rating is not generally helpful.

On the Motivation for Updating a Free iPhone App

When I sat down to learn iPhone development, I settled on writing a remote control for MythTV as a first product. And thus Remote Remote GH for MythTV or RRgh came into existence. As MythTV users are pretty adamant about not paying for software, I decided not to charge for it, and considered it only a teaching exercise. And that worked out pretty well. I learned a lot and other people have paid me a good hourly wage for writing custom apps with the experience thus gained.


But now I have an app with 76,307 downloads and no revenue. What do I owe the users? Most of them, I'm pretty sure, just downloaded it because it was free, and promptly deleted it—and typically gave me a one star rating, ugh—when it didn't do anything useful without a MythTV frontend. But there are people out there who use it, and I'd like to give them a little goodwill. How to justify it?


1) Advertising for other products.
I can put a splash screen that announces my paying apps. Right now that would be mainly Signal GH, which a great number of MythTV users will find useful, and which I sold a grand total of $10.50 of product just this last week. But I've ideas for other products in the pipeline.


2) Further Learning.
After reading Clean Code I've been scouring my code for ways to improve its readability. The code for RRgh was written when I was just getting a handle on using Objective C 2.0's properties extension, and is a good target for cleaning. And cleaning code is sort of fun in a mechanical washing the dishes sort of way.


3) Just to be Nice.
Hey, I like having users, and it makes me happy thinking they are happy. There were some rough edges around RRgh and I think my users would be happy for me to sand them down.


So I sat down and started cleaning. As I said, my major problem was with inexperienced usage of properties. I went through and made sure I was creating, accessing and disposing all the properties in the app properly.

And then I went after the interface. I had had this idea of having a defiantly plain interface using just standard OS widgets. Turns out people didn't appreciate what I was going for. So, following popular demand, I opened up Photoshop Elements and started drawing a black on black interface for my remote controls. The idea being something that wouldn't be too distracting in a darkened home theatre room, and which would look reasonably tasteful. I used a variety of button shapes to keep things consistently themed, but not oppressively so. Plus I took the opportunity to improve the spacing and sizing of the various controls, in particular, I felt it important to make the Play/Pause button easier to hit by making it a double size.


I also went through the reviews people had submitted. Someone had wanted a record button on the LiveTV remote, etc. Perfectly reasonable and easily done.

Before and After:

Then I took the Object Allocation Instrument to the running code in the hopes of finding code that was leaking. Turns out the system image picker (UIImagePickerController) is hard to dispose, so I ended up just reusing one. Result: the app doesn't crash after setting the logo for a dozen or so networks.


In total, I gave my users about 10 hours of my time sanding down rough edges, and made RRgh a noticeably nicer product. I hope they find it useful.

On the cost of USB versus Analog Headsets

I have children. Children love to destroy audio headsets, whether it be tearing out the ear padding, chewing up the wind guard, or taking a scissors to the cord, they will get the job done. And headsets can be expensive, especially if they have a USB connection. Searching for Logitech headsets on newegg.com, in 3.5 mm and USB varieties (and tossing out the most and least expensive in both categories) we can clearly see that analog headsets cost about $16 while USB headsets cost about $36 on average. This USB premium is something that has to be paid every time a headset is replaced.


However, there are USB devices with 3.5 mm headphone and microphone jacks which allow the user to use analog headsets. They cost about $20 (no surprise). As children are unlikely to destroy those, you just have to buy the one, and afterwards just buy a cheaper analog set to replace the one Junior split in two.

The Kindle iPhone App and the Return of Reading

Here is a picture of good intentions.

It's my little bookshelf of mainly technical books, right next to the big desk in the basement. And I regret to say, I haven't gone through even a few chapters of most of these books. Some of them are just odd choices, what was I thinking buying Linux Device Drivers? But, most are in domains either interesting, or profitable to know and yet they sit unread. The fact of the matter is that books are inconvenient and they require concentration. I'm a busy guy, and what free time I have ends up in some combination of web surfing or watching TV, usually both at once.


But like everyone, I find myself in the odd 10-20 minutes here or there. Lying in bed after the babies finally nodded off, waiting for the dentist, in a meeting starting late, etc. where I could be reading if I had a book at hand all bookmarked and ready to go. And here is where the Kindle App for the iPhone comes into play. It's always available (pockets in my PJs), no worries about lighting, always on the right page. If I activate my iPhone looking for something to do, the icon is right there on the main page. Basically, a low impedance situation to encourage me to read, and I do. I read the inspiring Clean Code cover to cover in the first week, and am halfway through Working Effectively with Legacy Code.


Not that reading a book on the iPhone is perfect. Code listings tend to be littered with confusing hyphens, and are generally hard to read. I'm sure a real Kindle is a better pure reading experience. But the thing is, I am not going to be carrying another device bigger than an iPhone on my person, ever. I'm certainly not keeping it in my pajamas. The iPhone is a good enough reader, and it's there. I could see buying a Kindle for my bedside, and relying on the automatic syncing with my iPhone, but that is way down on my spending list. What is important is that I am reading and getting the personal and professional growth which comes from reading.


Give a person a book and you change their lives.

AppleTV + iPhone Better than Mac for AirTunes

As I described in my last post, I've setup an Airport Express and a ceiling speaker to deliver music to my bathroom. This is cool technology, but after a week of it, it had the feeling of technology which was not going to become part of my daily routine. The major problem being that I had to remember to start the music playing from my MacBook before heading to the shower, and remember to shut it off afterwards. Several times, my wife made a special trip downstairs just to close the lid of my MacBook.


Then I realized this is just the sort of thing the Apple Remote app for iPhone is supposed to make easy, as I can control the music from wherever I might be in the house. And I further realized that I didn't have to leave my MacBook running all the time. The AppleTV in the living room is always on, contains my complete music collection, can be controlled by the Apple Remote app, and it can be told to send music to any AirTunes speakers on the network, including the Airport Express hooked to my bathroom speakers.


This has the major benefit of giving my wife equal control over the speakers as her iPhone can control the music as well as mine, and in a simple form her technological indifference won't mind.


So yeah, this seems right.

iTunes to Shower Speakers

[Update: I've posted a video about installing a bathroom speaker using an Airport Express as part of an Amazon review of a
SpeakerCraft CRS6 One in ceiling speaker. If you like it, I'd appreciate helpful votes.]

As I’ve mentioned before, the big new thing at the house the last year was a much improved moderately large shower in the basement. It’s become a locus of activity, as the babies have taken to bathing there making ad hoc bath basins out of plastic toy bins.


One thing missing would be a source of music. It occurred to me that if I could get an Airport Express mounted near the ceiling over the shower, I could use its AirTunes capability to stream music while I bathed. This would have the advantage of also allowing my wife to stream music or radio programming from her computer as well. Refurbished Airport Expresses go for $79 at the Apple online store with free shipping. Plus, I’d have another wireless N source.


[Update: Did you know that if you have an iPod Touch or iPhone, and an Apple TV, and an Airport Express, you can configure the Apple Remote for iPhone to tell the Apple TV to send its music to the Airport Express. And yes, I have all those things, and yes, Apple makes more money off me than the State of New Hampshire.]


According to the AVS Forum’s speaker section, a good in-ceiling speaker for the high humidity environment of a shower's ceiling is the Jamo 6.52DVCA2. I have done no comparing, so I cannot personally attest to how it sounds versus other in-ceiling products. It sounds fine to me, and it turns out is easy to install due to its well thought out mounting hardware. This speaker integrates both a left and right channel, so I only needed the one, and made do without much separation. This was found online for $78 shipped. [Update: Be sure to point both tweeters at where your head will be. I made the mistake of pointing one at the tiled wall, resulting in a muffled, echoey sound. Also, you might want to put some silicon sealer between the dry wall and the plastic bevel of the speaker.]


Finally, I needed a small amplifier to bridge the unamplified output of the Express with the 8Ω inputs of the speaker. Again, I am not an audio person, but I found a small 2×15 W stereo amplifier on Amazon, a Pyle Pro PCA1 Mini 2×15W Stereo Power Amplifier for $36 shipped. I didn’t suppose the small enclosed space of the shower would need any more power than that. And I was right. The system is plenty loud with the volume knob set at one quarter maximum. The amp's inputs are male RCA jacks, requiring a female RCA to mini jack adaptor. I wrote a short Amazon review on this amp, and I'd appreciate any helpful votes.


Remember, the Airport Express is not a "line out" analog device. The loudness of the output can be controlled via the volume slider in iTunes or the Apple iPhone Remote app depending on the setup. While this results in somewhat less than optimal sound, it is extremely convenient.


My original thought had been to install an electrical socket in the space above the shower and plug both the amplifier and the Airport Express there. But the only advantages to that plan would be to marginally improve my home’s WiFi coverage, and to limit any noise caused by runs of analog signals in stereo wire. Neither reason was compelling enough to justify the added expense and hassle of dealing with household current and possible building code problems. As it happened, I had a wall socket in my laundry room which was 20 feet of stereo cable from my shower's ceiling, and there is where I placed the amp and WiFi hub.



So the total required hardware:

• 1 Airport Express $79
• 1 Jamo 6.52DVCA2 In-Ceiling Speaker $78
• 1 Pyl Pro PCA1 Amplifier $36
• 1 30 foot Cat 6 Ethernet cable $5.40
• 1 Mini Jack to RCA Adaptor $0.65
• 50 feet 16 gauge stereo wire 8.80
• Shipping on cables $8.92
• Total Hardware $216.77

That does tend to add up quickly, doesn’t it? Well, maybe you needed a new 802.11n wireless hub anyway.


In retrospect, I should have gotten 4 conductor in wall stereo cable instead of 2 conductor. The added complexity of dragging two cables had no benefit.


I went to Lowe's and purchased a drywall saw, safety goggles, and a dust mask; all of which made the task of cutting out the speaker mounting hole painless. It is amazing how easily a hand drywall saw cuts through drywall. The hardest part was finding a place to cut the hole where there was plenty of space in the void above the ceiling. I'd have preferred a more symmetrical arrangement with the ceiling light, but the geometry of the joists was such that my options were limited. I used gluestick to temporarily stick the provided paper template so I could very precisely mark out the hole in pencil then started cutting with the saw; very easy. The JAMO speaker easily screws into place with a hidden mount.



And now I have my shower music. Time will tell if it was worth the expense.


[Update: Energy usage. I attached everything to my Kill-A-Watt, and while playing the Airport Express and the amplifier together draw 7 W, while not playing they draw 5 W, and with the amplifier turned off the Airport Express by itself draws 3 W. So, at 5W idle, it costs much less than a dollar a month to power the system. Also, while playing my unibody MacBook draws around 17 W with its screen asleep, so a system which played music 24/7 would cost on the order of $3/month of electricity.]

Mythtv + HDHomerun + SheevaPlug : Connecting the Dots

Marvell just announced a 5 W Linux box with a USB 2.0 port and Gigabit ethernet, the SheevaPlug. This is a full Linux server with a 1.2 GHz processor in a box the size of a large wall wart power supply for a price of $79 US. Presumably any geeky person reading this has a dozen things they could do with such a product, and here is one: MythTV backend.


One of my problems with MythTV has been the old Pentium 4 Dell desktop I use as a backend. The monster draws upwards of 100 W. 24/7. Just to record 5 hours of TV a week and serve out videos.


Well look at what we can build now:

• SheevaPlug 5W ($79)
• HDHomerun 5W ($159) Dual HD TV Tuner
• 1.5TB USB Hard Drive 10 W ($110)
• 20 W for $348

The hard drive cost and the dual tuner are constants when building a MythTV system. I'm not counting the cost of an ethernet switch, as I assume most of us would have an extra port regardless. The major point is using a SheevaPlug for a MythTV backend would be much cheaper even then using a NetBook $250, and would very rapidly be cheaper than even re-using an old desktop $10/month electricity versus $0.50/month for just the SheevaPlug.


And it should be quiet.


On the down side, it would be useless as a frontend, and probably not up to the task of re-encoding videos.

When An App Rejection Improves An iPhone App

[Update: Lullabies is now in the app store. Check it out.]

I recently submitted Lullabies an iPhone App to Apple. They reviewed it for a few days and rejected it. The basic design had been that a user would choose a soothing animation/song and that animation would play to completion, and only at that point the user could choose to replay the song, or go back to pick another. Apple didn't like that. The reviewer wanted a mechanism to go directly back to the root view without waiting. Otherwise I was in violation of interface guidelines.



I did not argue. I gave them what they wanted. Touching the screen brings up a small button which will return to the animation picker.


I had been thinking that if the parent handed a child the iPhone, the child would navigate around like my own children do and not settle into being relaxed. However, it's true that they will probably hit the main button to kill the app if they are inclined, and I don't want the app to be thought of as children only. I find the app relaxing too; my brother has a great voice, and it's calming watching bubbles bounce around. And adults don't need or like boundaries in their iPhone apps. So Apple was right. It improved the app.


The second improvement came from the added time for testing the rejection gave me. Now that it was easier to go back to the root view, I actually tried it and found severe resource management problems. First, I found my animation views were not releasing. Then I was leaking animation objects every time a bubble disappeared. Then I found that animations in the root view were taking a huge amount of time while hidden, to the point where touches became non-responsive. A whole long series of problems when I just wanted to get the app out the door. But, you never get a second chance at a first impression. iPhone apps which are branded as junk rarely get their reputations back. If I put my name on a piece of software, it means I think it is a quality piece of software.


I spent most of my debugging time in the Object Allocations and CPU Sampler Instruments figuring out why my little app was misbehaving. Developers, remember that the Leaks Instrument will not find a Leak if an object is attached to the run loop, as an animation is likely to be, instead look for classes of allocations that keep having net growth over time.


That one little button Apple requested blossomed into a series of improvements, cleanups, and learning experiences. And in the end, I have a much more responsive app, and code which I'll be able to reuse in future projects.


So, thank you anonymous Apple reviewer. You did me a huge favor.

Writing a Lullaby App for the iPhone

[Update: Lullabies is now in the app store. Check it out.]


I have 2 young children, and the familiarity and dexterity they show in using their parent's iPhones continues to amaze me. They can unlock the phone, find the YouTube app, and press on a video to play. And they are only 3 and 2 years old.


I have a brother, James Howes, who is an amazing singer, trying to make a name for himself singing opera in the Midwest. I would love to do something to advance his career.


One night, I came up with the idea of an app to help make babies sleepy, a lullaby app. Restful animations would play while Jim sang something sleep inducing. Originally, a friend of mine was going to do the animations, but he was too busy and I ended up doing the animations using CALayers and Core Animation, which was a first for me.


So here are some ideas about using CALayers on the iPhone. The first thing I did was open up Photoshop Elements and create a 320x480 document. I like Elements because it has simple vectored tools, its Save For Web... function creates excellent PNG files, and most importantly it is a layered editing program. Thus I can mock up my animation before I ever write a line of code to see what parts I need. So for a toy clock, I can combine, a background, a pendulum, a spinning moon dial, a spinning sun, and some foreground artwork. These are all exported from Elements as PNG files. PNG is the proper choice as it has decent compression while still having a transparency, and full color.

To form a toy clock of the kind one might see strapped to a crib.

If I add a layer of shadow—easily created with Element's color to transparent gradient tool—I am able to animate its opacity over the course of the animation ending with a night time scene. I like this gloaming effect better than simply making the whole scene uniformly dim.

Now that I had my parts together, I loaded each into a CALayer as so:

UIImage* moonsImage = [UIImage imageNamed:kMoonsName];
self.moonsLayer = [CALayer layer];
self.moonsLayer.contents = (id)moonsImage.CGImage;
self.moonsLayer.name = kMoonsName;
self.moonsLayer.opaque = NO;
[self addSublayer:moonsLayer];
self.moonsLayer.zPosition = 2;
self.moonsLayer.contentsGravity = kCAGravityResizeAspectFill;
[self.moonsLayer addAnimation:[self spinningAnimation] forKey:@"transform"];

Note, I made use of the zPosition to make sure my parts are drawn in the right order, and that I have a method that creates a CABasicAnimation spinningAnimation. I made a variety of CABasicAnimations to rotate the moon layer, spin the sun and swing the pendulum. You might have noticed that the center of the sun is the center of the moon dial is the center of the clock as a whole is the rotation point of the pendulum. This is not a coincidence; it makes figuring things out a whole lot easier. The pendulum graphic I used extends from the rotation point to the tip of the pendulum, although most of it is transparent.


I also made animations of snow falling, and bubbles bouncing. The hard part was simulating a bubble's iridescence (rainbow effect) in the Core Animation on the iPhone, believe me it would have been easier if Apple provided support for a proper masking layer as they do on the desktop.

It was darn hard getting my brother's audio tracks. Singing lullabies is not part of his normal repertoire—Rossini is more his speed—and he had no easily available recording facilities. The first tracks he sent me sounded like they were sung in an oak closet (better known as my cousin's kitchen). But after a very long time, he delivered the tracks I wanted, and I think they sound pretty good:
Down in the Valley. Note that any imperfections are caused by my amateurish editing skills; Jim is a singing machine.


Thankfully, Apple brought out the AVAudioPlayer class in the 2.2 SDK. It makes playing music much easier than the previous method of messing with AudioQueues. So actually playing the music was falling off a log easy.


So that's that. It was great learning about Core Animation, and I've ended up making good use of the skills in a per hour job this last month. And I hope to make more children apps in the future. I just hope this one makes a little money along the way.

How I Drive Around With My iPhone

If you insert your iPhone's headset into your iPhone, and then plug an iPhone to USB connector into the bottom connector, the phone has a very useful set of behaviors. Regular audio such as music or podcasts will go out the bottom connector—which in my case ends up coming out my car's speakers—while phone conversations will go through the headsets. Also, the click button on the microphone works to pause (single click), answer (single click), hang up (single click) and skip to next track (double click).


Therefore, when I get into the car for my commute home, I plug my headset into the phone, put the right—microphone—ear bud into my ear, and then plug the phone into my car's stereo system. The order this is done is important. Then, as I'm driving around, if someone calls me, I can answer the phone, hang up, and skip tracks all without looking. Be warned, might be illegal in your locality.

A Tech Support Mystery

Last week, my co-worker Gerald came to my cube saying his PowerMac G5 was consistently locking up after starting up and bringing up Entourage. He had come to me as I am the Mac programmer on staff, and therefore considered to know all things Macintosh.

I went down to his cube to find the G5 unresponsive to mouse clicks; locked up just has he had said. Very odd. After a few seconds of futzing around I realized that the machine did respond to right clicks. And a few seconds later, Gerald mentioned in passing that every time he restarted, the optical drive ejected. I immediately knew what the problem was. Can you solve this mystery? Answer below.
















The left mouse button of his Logitech mouse was stuck in the clicked state. Thus the machine was non-responsive to mouse clicks, and as everyone should know, holding down the mouse button while restarting will eject the optical drive of a Mac. I went and got a Mighty Mouse, plugged it in and the machine worked perfectly.

Patience Needed for Switching .mpg Application

My MythTV records over the air broadcasts as .mpg (MPEG) files of several gigabytes each. My preferred mode of viewing them these days is to open up a SMB share on the MythTV box, copy the file over to my MacBook while I'm working and then view it later. Amongst the many annoying things about this process—inefficient SMB transfers, avoiding having Time Machine back up the show, OS X not letting me watch a partially transferred file—a small one is that Quicktime owns the .mpg extension, when it'd be nice if VLC did. But every time I would open a Get Info window on a .mpg file the whole Finder would lockup, apparently generating the preview. And then I'd relaunch the Finder after a minute or so. So I never was able to click the Change All... button.

Turns out that the Finder will eventually, after several minutes, give up with creating a preview, and you can change the Open With application to VLC and then click the Change All... button. So be patient.

Sleep Advice for Geeky Fathers

As a father of young children, I have some advice for my fellow software engineers in similar boats who want time for their side projects. At some point, if you are lucky, your children will be sleeping from their bedtime of say 9:00 PM to maybe 7:00 AM depending on their natural needs. My advice is to work within this framework when it comes to your own sleep schedule.


Every day, come home from work, play with your children till their bedtime, fall asleep as they do and wake up naturally. For me, falling asleep at 9:00 PM will mean waking up in a quiet, empty house at 4:30 AM with 2½ hours of time to work on my software projects and catch up on my TV watching before the children awake. I will spend the rest of the day fully rested, and at my peak performance. Compare with the alternative strategy of staying up after the babies' bedtime which if I "get on a roll" might keep me up till 12:30 AM, with no margin for error. What if the babies wake up at 6:00 AM as they sometimes do? I'll spend the rest of the day under a sleep debt: low performing and grumpy.


Also, my recommended strategy allows you to pay off your sleep debt. If you do this and wake up later than expected the first few days, you had an accumulated sleep debt you needed to pay off before reaching peak efficiency.


I'm basing this advice on this Google Tech Talk which I highly recommend watching:

When Is A Leak Not A Leak

I was sent a bug report on some software I had written a while back wherein it would become less and less responsive over time till it just sort of died. Sounds like a leak.


But when I hooked it up to the Leaks Instrument, I saw no leaks. No red peaks at all. Must not be a leak then.


But one more look. The net objects allocated were going up and up and up. This should not happen, the application should have reached an equilibrium point of net objects allocated, and oscillated around it.


So, I let it run for a while in the Objects Allocated instrument, and then examined the blocks which were being allocated and not deallocated. Turns out I had an object, an audio player, which had a scheduled NSTimer associated with it. When I released the player, it was still being referred to by the NSTimer, so it did not get deallocated. And in this case, I was creating one of these every second or so (probably not a good idea), which meant that not only was the memory leaking, but all those timers were adding overhead to the event loop. No wonder it crawled to a halt. So remember to invalidate unwanted timers.

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.

How I Didn't Get Rich Via my iPhone App

I think we've all seen the stories about some guy in New Zealand making $6K a day for a Choplifter clone, or another fellow making $250K in two months reimagining Tetris. What you don't hear about are the flops. And I have a flop on my hands. My application to monitor over the air digital television signal quality, Signal GH has sold 10 copies. I had had no illusions that it would be a big seller; the target market is small at the intersection of iPhone owners and HDHomerun users; I just assumed there were a few thousand such people and they would all want my app.


Apparently not.


Unlike a lot of apps getting shoveled onto the App Store, Signal is competently coded; performs a useful service, launches quickly, doesn't leak, doesn't crash, and has only a smattering of bugs. Maybe prospective buyers would like to know this, but I have had no reviews so far.


Part of the problem was that Apple mistakenly lists its release date as the day I submitted it to them for testing, instead of the day they actually released it to the public, so I got no time on the front page of the Utilities page. And part is probably too high a price point, maybe $5 is just too much even for niche market apps. Again, I'm flying in the dark here because I've gotten zero feedback.


I also don't know where HDHomerun users hang out. The forums on Silicon Dust seem fairly low volume. Maybe if the HDHomerun were buggier, people would be filling their forums but dang it if the HDHomerun isn't the most reliable gadget on my network. And, I don't want to make commercial announcements on public forums anyway; nobody likes that sort of thing. I'm not a marketing wiz, I am a fairly good Mac coder.


Oh well, I only wasted a couple weeks of spare coding time. I've learned my lessons about targeting larger markets. I learned a thing or two about iPhone development, and hopefully my next post on the subject will be "How I Did Get Rich Via My iPhone App."

UPnP with Cocoa

Needing a license compatible implementation of UPnP I could use to locate MythTV frontends, I made the mistake of using the C++ version of CyberGarage's library. This was a mistake as the C++ version (1.7) is old and filled with bugs and leaks. The proper version to use is the C version (2.2) which is much less buggy and even comes with an Objective C wrapper class.

If you are writing an iPhone app and need to locate a UPnP device, this is probably the way to go.


Oh, and one thing to consider is that if you look through the code, you will see that the library avoids opening up connections with network interfaces that have the IFF_LOOPBACK flag set—for obvious reasons. You might want to also avoid network interfaces with the IFF_POINTOPOINT flag set, as that is as like as not the cell network radio, and you probably don't want to make UPnP inquiries over the cell network.

[Update: Looks like TCM Port Mapper might be the preferred library, but I haven't tried it.

iTunes 8 is still not Cocoa

Earlier in the year, I posted a blog entry about how Apple, obviously, must be getting ready to release a new version of iTunes based upon the Cocoa framework, and not the Carbon framework. While I still believe this to be true, iTunes 8 is not that product.


A quick look through the application's bundle shows all the signs of a product still deeply welded to Carbon.
A quick glance through the Info.plist:

• No Principle Class so no NSApplication at launch
• The HIWindowFlushAtFullRefreshRate flag is set indicating at least a few Carbon windows
• Application requires Carbon environment flag is set

There are a few .nib files in the bundle, but all the ones I looked at were Carbon.

Localized strings are still kept in a resource (.rsrc) file! What in the world.


In fact, there are no obvious signs of any Cocoa use at all.



As someone who's day job involves maintaining a Carbon app that "should" be transitioned to Cocoa, I can sympathize. But it is concerning as Apple wastes development time adding features like Genius to a straight Carbon application. Anybody writing new features will know that their work will have a shelf life of about 9 months; and will have to be reimplemented—at least the GUI parts—in Cocoa. And the sooner a Cocoa iTunes comes out, the faster it will become a mature, bug-free product.

Revamping a Dated Cocoa Application: InCDius 2.5

iPhone development has re-energized my love of programming. My day job requires me to do too much Win32 coding, and that is soul deadening for a Cocoa programmer. The combination of corporate priorities, and the fact I can add features much more quickly and with fewer bugs in Cocoa, leads me to spend a huge fraction of my time in Visual Studio, when I'd rather be in XCode. It's been draining.


I released InCDius 2 back in 2002, and it never got out of beta, although beta 16 was quite stable, and I apparently have a number of loyal (yet put upon) users. It is just an Audio CD database, not a personal media database like the well regarded Delicious Library. It was fast, and pretty darn stable, although a few users have had database corruption issues—please back up to XML people. I knew for years that I should release a new version, but could never quite muster the energy. It embarrassed me having this old, non-Intel application, gradually getting less stable with each OS release application; and I was considering my options for killing it entirely.


But my Remote Remote GH for iPhone application makes heavy use of the SQLite database, so I felt confident I could transition InCDius away from the Berkeley DB database. This transition had been the most daunting of the reasons keeping me from releasing an update.

My first impulse was to refactor the whole application using Core Data, but that would not have added anything but development time; the GUI was wired up quite well; the application was already scriptable. All I needed was a new database backend, and Apple ships OS X 10.5 with SQLite 3 right in /usr/lib. By choosing SQLite, I was no longer responsible for compiling and upgrading my database library; I can rely on it being there and just working. I tried using the QuickLite SQLite wrapper, but it was not capable for the task, as it creates a large number of objects maintaining its internal cache, to the point of locking up my Mac. No, I had to call the SQLite C API directly. As long as I minimize random access into the database, I get good results.

I also wanted this to be a release that could live on its own for a very long time; who knows how long I'll go without finding the time to update it. I wanted code which would last a very long time. This meant not only transitioning to Intel, but compiling for Intel 64-bit, and removing every deprecated API or framework message I could root out. I decided to make the minimum OS X version 10.5 (Leopard), and to transition the codebase to Objective C 2.0, although it isn't quite all there yet. I'll have to work on the garbage collection, but I am using both Objective C 2.0 fast enumeration loops and properties where appropriate.

Forward thinking means removing the past, so out went a few features tied to old APIs. I had been allowing users to import information from Classic Mac OS's CD Player preference file, but that involved using old school Resource Manager calls. Anybody ever going to use this feature again? No. Then out it goes, along with the Resource Manager.

I had 2 separate ways to play Audio CD tracks. One used QuickTime; one used Core Audio. Kept the Core Audio.

NSTableView has a new (to me) way to deal with selections with NSIndexSets, and deprecated the messages I had had been using. Goodbye old messages.

My own Objective C objects were filled with ints, unsigned ints, longs, and even the occasional unsigned. Hello NSInteger, NSUInteger and 64 bit computing.

I had been using a custom version of NSTableView to draw blue stripes. Goodbye custom class, hello check box in Interface Builder and grey stripes.

Obviously, I had been using .nib files for building my GUI. Time to upgrade everything to .xib files.

A user sent me his database (as a .zip archive of XML files) of 15,000 individual disks. Wow, and I had been thinking InCDius was zippy fast and ready for release. Massive performance tuning and the decision to load the database at runtime instead of upon the first search. Much simpler and reliable, and lets the user do something else while everything gets ready.

Take time to remove all the warning messages. You will save yourself a huge amount of hassle in programming, but especially in Cocoa programming if you eliminate all the compile warnings. You want to know right away if the compiler doesn't know if NSView responds to "releese". Do not let warnings build up. Fix them. Fix them all.

A Google Tech Talk by Linus Torvalds inspired me to change the unique identifier key I had been using to lookup disks in the database; he uses SHA1 hashes to avoid corruption in Git, and it seemed to me that a SHA1 hash of the Audio CD's Table of Contents would be as close as I could get to being unique; although there will be rare instances when 2 CDs cannot both be in the database.

So after all this, what do I have? A fast, reliable(?), clean, focused little application, which I can send out into the world; spend the next few months fixing the occasional bug and adding the occasional feature, and which people can use for a good long while.

Signal GH - iPhone App for the HDHomerun

[Update: It's finally in the iTunes App Store.]

I submitted my second iPhone application to the App Store this morning. Signal GH is a utility to monitor the signal quality of over the air television for American and Canadian users of the HDHomerun. I'm charging $4.99 for it, which seems a fair price given what a small market I'm targeting: the intersection of iPhone and OTA HDHomerun users. Anybody who's set a retail price knows how hard it is. And I'm sure there will be a lot of people giving me one star and claiming it should be free, or one star and claiming they didn't understand you needed an HDHomerun. Sorry guys, gotta send my son to day care, the requirements are right in the first sentence of the blurb.


The Silicon Dust engineers did a great job with their libHDHomerun API, anybody wanting to put out a C API should check it out for its use of the language, platform ambivalence, and object like characteristics. Of course, they then released it under LGPL, making me wait the last couple weeks for them to modify the license. But they did, and I promptly submitted.


Now just step back and let the pennies roll in.

Few USB Car Chargers work with iPhone 3G

[Update: an earlier version of this blog entry said that the 2A Griffin PowerJolt was able to charge my iPhone while playing audio and showing the GPS map. Additional testing showed this not to be the case.]

As I spend 4 hours a week driving my car to and from work, I need my podcasts to keep me sane. Before I bought an iPhone 3G last month, I had a very reliable cigarette lighter to FireWire cable hooked up to a tiny dock which I would plug into my reliable iPod Mini. Apple, to save space, removed Firewire charging on the iPhone 3G thus forcing users to go with the inferior USB style charging. In a quest to replace my previous setup, I found out the hard way how inferior USB charging is.


To replace my original micro dock, I purchased an Apple Component AV Cable. This gave me a USB connector for charging and 2 RCA cables to plug into the convenient RCA ports I had previously installed in my Civic. And to think I was mocked for using RCA instead of a mini jack. Of course, this left me with 3 useless component video connectors, but they were easily bundled up.



Now I needed a cigarette to USB adapter, so off to Amazon. I thought the Mace Group USB Charger looked compact.


And was soon happily zipping back and forth between work and home before discovering something: it wasn't actually charging my battery. In the meantime, I had purchased another copy for my wife's car, and the iPhone did not even recognize that has being connected. So back they went to Amazon.


Needing charger for a long day of taking a visitor around town, I picked up a PowerDuo/PowerJolt by Griffin at Circuit City:


That seemed to go alright for a couple days until I left the iPhone displaying a GPS map for half an hour. What's that smell? The smell of the PowerJolt overheating.


OK, might need something more heavy duty. My, this Black & Decker Power to Go cup holder charger looks the part.

Turns out it only delivers 350mA to the USB port. The iPhone won't even notice you are trying to charge it.


How about this Kensington Car Charger for iPhone and iPod rated at 1 Amp? It says right on the box for iPhone (no mention of 3G)


Well it didn't overheat, but it failed my listening to music with the GPS running test, couldn't quite keep up.


Finally, going back to another Griffin PowerJolt from Best Buy, this one larger and with a 2 Amp fuse.


Here we have a winner. [Correction: During a longer test, the iPhone's battery did not build charge while playing audio and displaying the GPS map, but the PowerJolt kept cool and was nearly able to keep up.] Driving around while listening to music and with the GPS on, it was actually able to top off my battery. And this model has the new, don't start smoldering feature.


It turns out that what any given USB port will deliver in terms of power varies widely: one charger might deliver 5 times as much current as another. I would recommend finding a charger with the highest available maximum amperage, something around 2A like the more recent PowerJolts, and avoiding dual port chargers unless they can guarantee a high current to both ports.

[Update: What is strange about this is that according to System Profiler, my iPhone lives on an allocation of 500mA while connected to my MacBook.]

Remote Remote for MythTV for iPhone

I've written a "toy app" for OS X Touch, a version of my Remote Remote GH for MythTV application which acts as a remote control over the wireless network to control a MythTV. It's a toy in the sense I am mainly using it to learn the iPhone SDK, and not to earn money, or even a large user base. I don't expect it will find a large following, I was just learning the ways of the iPhone.


Coding for the iPhone is different. Not so much in the GUI classes or the tools, but in the outlook it requires of the engineer. I was working in a resource starved environment; one in which I needed to take care not to run out of memory, not to use network unless needed, and not to spend a lot of time launching or quitting. An environment, where I had to justify every button on the remote control as space worthy. I leaned heavily on Apple's performance tools, much more than I would on a Mac. And, I refactored constantly. Every time I learned something new, I would change my code to work better and better fit the SDK way.


I also needed to use SQLite extensively, and felt compelled to adapt the QuickLite framework to both Objective-C 2.0 and the iPhone. If Tito Ciuro reads this, please send me an e-mail.


And finally, I'm quite proud of most of the artwork:

It's harder than it looks coming up with simple, thematically consistent, iconic graphics. Thanks to my wife for telling me try again after my original app icon design mashed together a picture of a widescreen TV with a remote drawn in perspective. I went with a simple rendering of navigation buttons, which I liked so much I made the buttons part of the actual GUI.

My Semi-Annual Rant about Compiling MythTV

So, I am testing a little iPhone app to control MythTV, and I decide I should upgrade to the current bleeding edge build. Which is bad enough, as I had Qt 3.3 installed on my Linux box and the bleeding edge is Qt 4 based; requiring figuring out what my PATH, QTDIR, QTMAKE, variables are required, and then ending up with an upgraded database making it hard to go back. And then finding out the the remote control interface is pretty severely broken in a couple places, which I either had to fix or cut back on the features of the app. And then finding out that the mythweb is pretty broken, and that live TV is not improved. Etc.

Bad enough, and then I had to upgrade the Mac frontend to match the new version of the MythTV protocol. As if it it never occurred to the guys at MythTV.org that standards should be flexible enough not to require constant changes. Ever notice that on top of every well formed XML file it says <?xml version="1.0" and that people have gotten along pretty well without changing the definition every 3.5 weeks. After a couple of hours of trying to get the frontend to compile on my MacBook, which has XCode 3.1, and an older version of Qt futzing things up I decided that the build scripts really didn't like llvm, and installed XCode 3.0 on the Mac Mini in the basement. Then it was a couple hours of fixing a few errors in the Mac specific code, and realizing the main configure file had to be made executable.

Then after it finally compiled, it was figuring out why I couldn't turn off pinging the database server (bad mysql.txt permissions), then why the frontend quit right away with the only clue being in the Console: "MythTV requires an updated schema". So the database schema had changed in the last 3 days, causing the frontend to quit without any warning. Classy.

And the playback is absolutely horrible on the Mini for some reason involving TOSLink passthrough or problems with linking in a library—I'm not sure. I really ought to buy another Mini, one which I can run as 100% OS X, and use EyeTV.

Vectored PICT to PDF conversion in your code

You should not be creating any PICT files, but longtime Mac users might have a large number of .pict or .pct files lying around, and some (all?) of the tools Apple provides to open such files and convert them to PDF do a horrid job of it. This applies only to vectored PICTs, as bitmapped PICTS will look bad regardless.


First I refer you to this screen capture of a simple AppleWorks drawing:

You will notice that it looks a little archaic with it's lack of anti-aliasing, but that's what people had in the day.

I copied and pasted this image into TextEdit.app, saved the document as RTFD and then used the "View Contents" item in the Finder contextual menu to get to an actual old fashioned .pict file. This is how hard it is these days to generate a PICT file.


Just to see how not to do this, open the .pict file in OS X Preview.app, zoom in a bit, and you will see that however Preview is rendering PICTs it is doing a pretty poor job of it. I'm guessing it is using QuickTime import to create a bitmapped version.

Tell Preview to save as a PDF and you get this mess:


The basic problem here is that Apple provides an API for rendering a PICT into a Quartz context (and thus into PDF) which preserves the vectored nature of the original and some applications do not use it. If you use this API, your onscreen representation of PICT files will be as good as they can be, and you will be able to export them to comparatively nice PDF files. This does not mean they will look as good as PDFs which had been created from the ground up as such; PICTs lack of support for transparency, Bezier curves, fractional coordinate systems and rotated text make that impossible. But it will look a lot nicer.


QDPictRef LoadPICTFromURL(const CFURLRef& pictFileLocation)
{// warning, I did not actually compile or test this code
QDPictRef result = 0;
CGDataProviderRef dataProvider = CGDataProviderCreateWithURL(pictFileLocation);
result = QDPictCreateWithProvider(dataProvider);
CFRelease(dataProvider);

return result;
}

Look around the header files for the QDPictToCGContext.h header and you will find:

QDPictDrawToCGContext( CGContextRef ctx, CGRect rect, QDPictRef pictRef);


Then you can use the resulting QDPictRef to draw into a Quartz context, and if that CGContextRef was created via a call to CGPDFContextCreate, then you have created as nice a copy of the original PICT as is possible as seen by this screen shot at 200% zoom:

and this PDF result:


Note that rotated text still looks horrible, as the only way to make QuickDraw draw rotated text onscreen was to draw into an offscreen bitmap and then rotate the pixels in the bitmap. It was possible, however, to insert a series of PicComments which inserted rotated text into a PICT. I've checked this out with PICTs created by a separate application, and the Apple PICT to PDF converter honors these comments. I guess AppleWorks just didn't bother to put them in. [Update: Paragraph rewritten to add extra info, and to hide temporary idiocy on my part.]

Also check out the little bump in the arrow heads, probably a glitch that went unnoticed in the non-antialiased original caused by drawing the shaft too long and not quite on center. Otherwise, the new antialiased version looks much nicer. And you can even select and copy the (non-rotated) text right here in the browser.

It's not unusual, but unfortunate that Apple is inconsistent in using its own API. Preview.app obviously does not, nor does the PICT CoverFlow plugin, but TextEdit.app appears to, resulting in the oddity of a PICT in a CoverFlowed RTFd document looking much better than the CoverFlow of the PICT file itself.

Regardless, I recommend that anybody with a large collection of vectored PICTs make PDF copies of them as there may come a version of Mac OS X which will not have any support for PICTs at all. For instance, I doubt you can view PICTs on an iPhone. Warning: see my other posts about how PDFs do not contain the extra data which allows the originating application to recreate the original document. So keep the originals around too.

[Update: I've corresponded with Thorsten Lemke, proprietor of LemkeSoft and creator of the well known Graphics Converter application. He immediately saw the value in incorporating improved Quickdraw picture processing and conversion in his product and version 6.11 and higher (including this morning's beta) will feature it. I envy the nimbleness of independent software vendors. I can't tell you how long my day job company takes getting a minor release out to our customers.]

[Update: here is the source for a simple automator plugin I threw together to make the conversion.

#import "QuickDrawPictureToPDFExporter.h"

QDPictRef LoadPICTFromURL(const CFURLRef pictFileLocation)
{
QDPictRef result = 0;
CGDataProviderRef dataProvider = CGDataProviderCreateWithURL(pictFileLocation);
result = QDPictCreateWithProvider(dataProvider);
CFRelease(dataProvider);
return result;
}

@implementation QuickDrawPictureToPDFExporter

CGContextRef CreatePDFContext(const CGRect mediaRect, CFMutableDataRef theData)
{
CGContextRef result = 0;
if(theData != 0)
{
CGDataConsumerRef theConsumer =CGDataConsumerCreateWithCFData(theData);
if(theConsumer != 0)
{
result = CGPDFContextCreate(theConsumer, &mediaRect, NULL);
CGDataConsumerRelease(theConsumer);
}
}
return result;
}

- (id)runWithInput:(id)input fromAction:(AMAction *)anAction error:(NSDictionary **)errorInfo
{
NSMutableArray* output = [NSMutableArray array];

if (![input isKindOfClass:[NSArray class]])
{
input = [NSArray arrayWithObject:input];
}

NSEnumerator *enumerator = [input objectEnumerator];
NSString* aPath =nil;

while (aPath = [enumerator nextObject])
{
NSURL *inputURL = [NSURL fileURLWithPath:aPath];
QDPictRef aPictRef = LoadPICTFromURL((CFURLRef) inputURL);
BOOL drawn = NO;
CFMutableDataRef theData = 0;
if(aPictRef)
{
CGRect mediaRect = QDPictGetBounds(aPictRef);

theData =CFDataCreateMutable(NULL, 0);
CGContextRef cgContext = CreatePDFContext(mediaRect, theData);
if(cgContext != 0)
{
CGContextBeginPage(cgContext, &mediaRect);
CGContextSaveGState(cgContext);
QDPictDrawToCGContext(cgContext,mediaRect,aPictRef);

CGContextEndPage(cgContext);
CGContextRestoreGState(cgContext);
CGContextFlush(cgContext);
drawn = YES;
CGContextRelease(cgContext);
}
QDPictRelease(aPictRef);
}
else
{
NSString *errorString = NSLocalizedString(@"Picture to PDF could not read the input file as a PICT.",
@"Could not read input file");
*errorInfo = [NSDictionary dictionaryWithObjectsAndKeys: [errorString autorelease],
NSAppleScriptErrorMessage, nil];
}
if(drawn && theData)
{
NSString* outputPath = [[aPath stringByDeletingPathExtension] stringByAppendingPathExtension:@"pdf"];

if (![(NSData*)theData writeToFile:outputPath atomically:YES])
{
NSString *errorString = NSLocalizedString(@"Picture to PDF could not could not create output file.",@"Couldn't write data to file");
*errorInfo = [NSDictionary dictionaryWithObjectsAndKeys: [errorString autorelease], NSAppleScriptErrorMessage, nil];
}
else
{
[output addObject:outputPath];
}
}
else
{
NSString *errorString = NSLocalizedString(@"Picture to PDF could not draw the File.",
@"Could not draw output file");
*errorInfo = [NSDictionary dictionaryWithObjectsAndKeys:
[errorString autorelease], NSAppleScriptErrorMessage, nil];

}
if(theData)
{
CFRelease(theData);
theData = 0;
}
}
return output;
}

@end

]

Keep your Frameworks from Metastasising

Think Class Library, MacApp, PowerPlant. What do these frameworks have in common? They are all on my resume and they are all dead. Qt, Cocoa, AWT(?), Swing, MFC(?), .NET. What do these frameworks have in common? They are not dead, yet. The question mark indicates a framework in the zombie state of not being improved upon, but being used by too many people to be considered dead.

"It just so happens that your friend here is only MOSTLY dead. There's a big difference between mostly dead and all dead. Mostly dead is slightly alive." --Miracle Max in The Princess Bride

And, I am glad that frameworks die. I would rather not live in a world where 23 years later, MacApp was the best we could do. It was a pain to work with and I'm much happier with Cocoa or even Qt. People learned what was wrong with the old frameworks and made better ones. (If only this were true of MFC.) And, baring asteroid collision, people will come up with new frameworks in the future.


And that is the rub. Frameworks get you 2 ways. 1) they usually lock you into writing all your code in a particular language. If the next great application framework uses Python, and all your work is in C++, you're going to be awfully busy. 2) You drink the Kool-Aid, and use Framework classes everywhere. If you are a Qt user, half your methods take QStrings, and when the time comes when you want to switch from Qt to Cocoa, you will be re-factoring for weeks.


The language lockin is tough. I've known for years that C++ is not really a great application language; it may be a decent OS level language, but it is too fragile, too demanding, too static, and too complicated for making reliable desktop applications. But what else are you going to use for cross-platform apps? Maybe .NET will kill C++ as a cross-platform language. I don't know; it'll be a while. Hopefully, an appropriate cross-platform language will rise up to take its place. Which is part of my point, 10 years from now, we will not be using the same language on the same framework to do development. Something better will arise.


Getting back to the point of this entry, you want your code to last longer than any one framework. It's a matter of amortization. The longer your code lasts doing useful work, the higher the payoff for writing it. Over the 16 years I've been programming Macs, I've used 5 frameworks, and 3 of them are dead. I am not predicting the imminent death of Cocoa or Qt, far from it, but die they will, and I should have a backup plan. And here is the other rub, my backup plan 'til now has been to write cross-platform, pure C++ code using a lot of STL and boost, and try to keep the platform specific code from creeping into the general purpose code. But I just said, perhaps prematurely and wistfully, that C++ itself might fall out of favor with framework developers, which both makes cross-platform development more difficult without a Lingua Franca, and negates the hedge against your framework dying.


So I don't have a long term solution, but in the meantime do what has been good advice. Keep your use of frameworks limited to a thin GUI layer on top. Abstract the interfaces between your code and the framework. Abstract, abstract, abstract. To the extent practical, do not propagate framework classes into the meat of your codebase. If people had done this in the past, they could have skipped from MacApp to PowerPlant to Qt with a song in their heart instead of the crushing pain it was for most folks. Do not get locked in without a very good reason.


And know when it is time to scrap your live's work and move to a new language.

...watch the things you gave your life to, broken, And stoop and build 'em up with worn-out tools... --Kipling

Quartz to PDF, versus PS to PDF

I am ankle deep in Postscript code at my day job, so as a refresher I took an afternoon and hand encoded a business card for my wife, who is starting a side business arranging academic tours of China (for the Peking University Department of Philosophy and Religion). Obviously, most people would be better served creating a card in InDesign, or other vectored drawing editor, but this was a learning experience.


Here it is with the contact info scrubbed.



Postscript is not a friendly language, but it was simple enough creating a .ps file in my text editor—BBEdit—and just dragging and dropping the icon from the editor's title bar onto the OS X Preview application. Preview has the convenient feature of auto-magically converting Postscript files to PDF. Of course, compilation errors result in a cryptic failure dialog, but these were enough development tools for an afternoon's project. If I were to do this on a more regular basis, I'd compile a simple app which provided a message callback to the CGPSConverterCreate routine.


Consider how much easier it would be to create this file in Quartz, and how much better the output would look.

• Font handling is hard in Postscript, even if you don't have to embed descriptions of your fonts. Thus my use of standard Postscript fonts Times and Helvetica.
• Kerning is not automatic in Postscript. Yes, you can use kshow to manually set the spacing between pairs of characters. No, I'm not going to do that. Thus, the odd spacing between letters.
• If this file had included characters from non-Roman languages, complications would arise as Postscript only allows 256 characters per font encoding, potentially requiring multiple font definitions per face. None of the free Unicode support in Core Text/Quartz.
• I might have used a little transparency, but there's no such thing in Postscript.
• Postscript is hard to read and maintain. The extra syntax needed to keep the parameter stack organized, distracts the eye away from the actual algorithm being described. Postscript is certainly more compact in the editor, by an order of magnitude, than a series of Quartz API calls but much of that compactness is wasted pushing, popping, dup'ing, and rolling the parameter stack. I mean, just look at it: [Update: changed ATSUI to Core Text]
gsave
basefont [9 0 0 9 0 0] makefont setfont
(Nashua, NH 03061)
dup
stringwidth pop 2 div neg 0 rmoveto
show
grestore

The fact of the matter is that Apple has done a lot of heavy lifting for us either via proprietary extensions to PDF, or taking the extra effort of providing optimized support for font embedding. An afternoon spent trying to keep track of an unruly parameter stack was enough for me to appreciate how much power Quartz gives us, and how easy it is to call upon.

What does it mean when your app launches faster in Debug?

Ummm, maybe you forgot to uncheck "Open using Rosetta" in the release build?


I was enthusiastically awaiting how fast my day job application would launch now that I've eliminated the slowest thing. The debug build launched fast, the release build launched fast under instrumentation, the release build launched really slow from the Finder. What?? Was about to go up to bed, when it occurred to me I had switched on Rosetta for something months ago, and might have just forgotten to turn it off. Yep. Application launches quickly now. Users might even notice when this gets to them in a couple months.


By the way, when you are using Apple's Core Foundation XML Parser, you really really want to use CFTreeGetFirstChild followed by a series of CFTreeGetNextSibling calls to traverse the elements. You really don't want to call CFTreeGetChildAtIndex on anything approaching a large XML document.

iPhone App Ideas: A Target Rich Environment

I was watching a recent episode of Anthony Bourdain's: No Reservations on the Travel Channel this morning, and came up with an idea for an application.

Bourdain described the process in which orders are conveyed through a restaurant: customer tells waiter, waiter writes on order slip, waiter goes to waiter station and inputs order into terminal, order gets directed to the appropriate kitchen personnel. I was struck by how the input terminal involved bringing up a diagram of the appropriate table, and inputting the order for each chair around the circle. This seemed something easily transferable to an iPod Touch style interface.

I'm imagining a situation where the customer tells the waiter, the waiter touches on the table in a map of the restaurant, touches on the seat, is given a series of menu choices corresponding to things on the menu, touches complete, and the order is sent directly to the kitchen. Maybe the customer orders shrimp and the kitchen just ran out of shrimp, the software would show an alert.

In this scenario, the waiter only has to enter the data once, there is less chance of transcription errors, the restaurant does not have to set aside valuable floor space for the waiter station, and status information is more current. Presumably, the people best positioned to make such software is whoever makes the current restaurant terminals, but some enterprising types could get into the business right now while the going is good, by providing an entire Mac/iPod based solution which incorporated the whole system: data entry, accounting, kitchen display screens, etc. If anyone uses this idea, cash is always an appropriate gift.

It would be nice if Apple were to come up with an industrial version of the iPod Touch that was not worth stealing as a media player for specialized situations like this.

The iPhone and the End of Bloatware

You still see tables filling full page ads in computer magazines, a column of checks for the product being advertised, a column of blanks under the competitors. This was the game of the big company, the Microsofts of the world; organizations with large enough staffs to code solutions to any need or perceived need of any customer big or small. Every customer needs 10% of Microsoft Office, but every customer needs a different 10%. Smaller, more nimble companies have made better pure word processors, but they have all been relegated to niche markets, as the vast majority of customers know that somewhere in Office are the exact features they need, plus a bunch of features they might need someday for free. It's just a matter of finding them. And in a world of full keyboards, contextual menus, 24" monitors, gigabytes of RAM, terabytes of storage, multi-cores, and fast CPUs, there's always somewhere to tuck a feature.

Now comes the iPhone/iPod Touch with its 480x320 screen, no keyboard shortcuts, finite memory and demand for near instantaneous launch and quit times. Ponder this small subset of toolbars for Word 2003 on Windows:


and imagine that each icon was twice as big to accomodate the stubby adult forefinger. Imagine making even this small subset of functionality accessible somehow while still showing content. I've a good imagination, but it fails me here.

Anti-bloat features of the iPhone OS:

• Apps must launch quickly (in practice anything less than a second will seem intolerable), and quit as fast or faster
• Apps must be relaunched every time you move back from another app.
• There is a practical limit of 10 or so toolbar type icons per view, and 5 is more reasonable. This leads to a geometric decrease in accessible functionality versus a program on a PC. If you can fit 40 toolbar icons on your computer's monitor, and each opens a dialog with 40 items, and each dialog item invokes a subdialog with 40 features you have 40x40x40-40-40=63,920 accessible features versus 5x5x5-5-5=115 features 3 levels deep on an iPhone (well you could probably fit more than 5 items per view, but you get the idea)
• There are no contextual menus, much less multi-level contextual menu trees
• There are no keyboard shortcuts, eliminating the need for laminated keyboard shortcut hint sheets Scotch taped to the back of the iPhone
• There are gestures, but really, how many unique gestures can you expect a person to master: pinch, shake...?
• There is a finite amount of RAM, and telling the user to "just add more" is not an option
• Lack of both RAM and application interaction are a firewall against the metastasized bloatware which are "Office Suites," which have to at least pretend to work together

No, what we will get are mini-apps. Apps a single competent programmer will bang out and polish in 3 months or less. The functionality which makes up Office could be broken up into scores of such mini-apps: a mini-table creator, a mini-slide presenter,a separate mini-slide editor, a database client, a little drawing app. In fact, even these small apps will probably be too big, and will be streamlined for more specific task oriented, specialized purposes: a blog post word processor, a series of charting modules which each do one type of chart, a specialized Keynote which only has the tools needed to create presentations following a single corporations style—imagine all those exactly the same style presentations you see at Apple events. That would be doable on an app which could only show 5 toolbar icons at once, and which relied upon gestures, animation, templates and transparency to maximize what the user can see and do. And, lots of apps to help with one's location based social networking, whatever that is.

In the iPhone ecosystem, bloatware is non-adaptive. The big have no feature advantage over the small.

The experienced Cocoa programmer does have an advantage, however. I have been reading through the Apple example code, and it is made up of delightful exercises in object oriented minimalism. Actual, full blown apps written in this style will be incredibly light weight for the functionality delivered, with zippy launch times, and responsive interfaces. This seems to be how one masters a framework, and it is especially true of Cocoa, by learning how to do the most with the least code, which is again, the anti-thesis of the bloatware mentality, which seems to only care about churning as much code out as possible.

Re-imagining a Desktop Utility into Cocoa Touch

If anybody's starting up a business based around iPhone development, and need a chief engineer, I'm sure you can find my e-mail address.


Well the momentous day came, and the iPhone SDK is in our hands. I wish I were not so incredibly busy at my day job, or I would take a couple weeks off and learn the ins and outs. But, I've decided I should start small and port a little application I wrote, Remote Remote GH for MythTV, which I'm afraid I have not been properly maintaining, but has the advantage that it would be much more useful on an iPhone than on a laptop, and it only uses Cocoa and various Core Foundation routines. I'm going to go through the exercise here of paring the interface down to size and making it more in touch with the Touch's way of doing things. Then sometime in the next couple months, I'll take the time to actually do it.


Let's look at the original and see how we can get it down to 320x460 and 480x300 (which are about the available sizes once you discount the "status bar" region of the display). Not only do you have a smallish screen, there is inconvenient text entry, and any widget on screen should be at least 44x44 pixels to deal with the stubby fingers of adult humans. On the plus side, there is multi-touch and 3D movement via the accelerometer.

• Disconnect/Connect Button This should probably be done away with entirely, and the app should try to keep a connection up when visible.
• Show Keys Button This brings up a list of keyboard keys which are appropriate for the current state of the MythTV. The idea was for the user to control the MythTV with the same key presses used when sitting in front of the computer running the MythTV frontend. Keyboard input on the iPhone being discouraged, replacement with a series of contextually appropriate button panels is appropriate. (A panel for watching recordings, a panel for navigating, a panel for DVDs, etc.)
• Scrolling Status Console This was a area devoted to telling the user what has happened. This can be condensed into a 2 line status widget at the bottom of each screen.
• Navigation Buttons Live TV, DVD, etc., can be put into a standard navigation bar, to allow the user to jump to a common task, which I will pare to Live TV, Recordings and Video
• Recorded Programs Table This can be moved to its own panel, and condensed, with perhaps a sub-panel which the user can navigate to with more complete information for each recorded program.
• Big Scrub Bar I like the idea of making very long scrub bars to allow for fine control over where in a program the user can jump. This is a good candidate for a control which is always along the long axis regardless of the orientation of the device, and will only be visible in play back mode panels.

As I said, I have very little time on hand, but I was able to make a first step of compiling my network protocol classes, which compiled after a mere 5 code changes—removing #include "Cocoa/Cocoa.h", and replacing call to Carbon's NewPtr(...)/DisposePtr(...) with malloc(...)/free(...).

Then it was just a copy/paste job to make a stripped down version of my original application delegate, which just stuffed replies from the server into a simple UILabel in my main window. Amazingly, this worked on the second try, with a connection forming with the server, followed by periodic requests for status. If anything, the networking code is more solid than in the desktop application.

I'll update this later, as I start to build the GUI, and figure out how best to minimize my power usage (keeping the Wi-Fi unit off for extended periods).

On the Badness of Skins

I refer you to this posting on the product forum for the CoreAVC player application. An application which claims to have extremely efficient H.264 decoding.

Here is the company representative explaining why the Edit menu always comes first , instead of the File menu as Jobs intended it.

CoreUI, our skin layer, is not meant to hardcode things like "File". There are some apps that don't deal with any file and still require text editing. And we can't wild guess where they want the Edit menu. The thing we could do is add a special element in the skin that could place the Edit menu where you want it to be...


Now, I would very much like to see better efficiency in H.264 playback, especially on the 1.6 GHz Core Duo Mac Mini on my wife's desk. That would be a good thing. But here is a cross-platform application whose creators can't be bothered to put together a simple Cocoa shell application for their player, and believe me this would not be a lot of work for a semi-competent Mac guy to throw together. Instead, they've ported their skinning engine—which I'm sure they are quite proud of. The engine is extremely flexible, except in the sense that you can't put together a skin which doesn't make their programmers look clueless.

Let's see. How much time to put together a nice Cocoa application to host your player: X. How much time to port, and debug a "flexible" skinning engine: maybe 4X. So, precious development time which could be spent elsewhere is instead spent on skinning: a misfeature given to the world by WinAmp, and repeated by seemingly every other media player intent on letting skinless iTunes eat their lunch.


You want to know a big reason WinAmp, or MusicMatch (which I worked for) or whatever, couldn't keep up with Apple's iTune team? A big reason was skins, if you are spending 30% of your development time maintaining skins and the skins engine, and you start rejecting new features because they don't fit into the design of the engine, or because you have to add new artwork to 10 separate skins, and you have your best minds trying to figure out an abstract design for docking arbitrary subwindows, and your testing staff spends all day long looking at every permutation of new feature and skin, then it's going to be like you are fighting Apple with your arm tied to your leg, and your leg is bolted to the floor.

And for what? A feature that the vast majority of your user base is at most going to flip through once and forget exists.

BTW, CorePlayer, at the moment, is virtually useless on the Mac, as it lacks AC3 passthrough. You know an actual feature involving playing media. Maybe, if they hadn't spent all that time on their skinning engine, they'd have a product Mac users, like me, would like to buy.