xpchelper reply message validation: code signature invalid
The code signature is not valid: The operation couldn’t be completed. 
(OSStatus error -67061.)

I was able to track the bug down to an issue with the code-signing feature built into the Mac development tools. At best, code-signing allows users to confidently download applications knowing that the program they download matches what the developer published (i.e., no viruses or hacks were inserted into the program before you downloaded it).

Unfortunately, code-signing appears to be broken (at least in some cases) on OS X 10.7.5 (the latest update to Lion). The problem can be fixed on the developer's end by turning off time-stamping when code-signing the application. What a strange bug in OS X. I guess I'll add an extra code-signing step to my application deployment checklist to work around this bug.

For future reference, code-signing after an archive is accomplished using the terminal:

export CODESIGN_ALLOCATE="/Applications/Xcode.app/Contents/Developer/usr/bin/codesign_allocate"

codesign -fs 'Developer ID Application' --prefix 'com.yourcompany' --preserve-metadata=i,e,res,req --timestamp=none YourApp.app/

On OS X 10.8.2, here's the specific error message I encountered when trying to write an SQLite file to a user-specified location:

coreData: error: (21) I/O error for database

There are a supposedly a number of ways to work around this, including turning off the journaling feature of SQLite. I tested this fix for a bit but couldn't generate an SQLite file in this manner.

After thinking for a bit, I came up with another work-around. Because I'm exporting data from my app (and not using the SQLite store as a normal data file that will be continually read from and written to), I simply generate the SQLite data file inside my applicaiton's Sandbox folders and then copy the file to location specified by the user. I don't love this solution, because it's got an extra point of failure, but I don't see another solution to this problem that's less of a hack.

I probably should have thought of this solution a bit more quickly, but I'll chalk this up to another hour or two trying to work around problems in Apple's Sandbox.

But now that I'm working on making Planbook a modern, 64-bit app, I need a new solution. While there appears to be active ConnectionKit development, it hasn't become a fully 64-bit framework and the documentation is basically non-existent. Getting it to work would require either continuing to distribute Planbook as a 32-bit app (not ideal) or mucking through the ConnectionKit code to generate and use a 64-bit version of the framework. After 2 days of working with ConnectionKit, I made some progress, but it didn't seem likely to yield a viable solution.

Fortunately, I discovered Apple's relatively simple FTP client sample code. It's iOS focused, but the core networking code is all CFNetwork based and can easily be used with Mac OS. After a couple more hours of work, I've got FTP integrated back into Planbook with no outside dependencies.

I use a Netgear Dual Band Wireless N router (the WNDR3700 v2, to be exact). I've also flashed the firmware and am running DD-WRT on the router for extra configurability. It was easy to install, following the provided directions. I noticed that my iMac was connecting to the router at a max of 54mbps, far slower than the 300mbps the router should provide.

Based on a random forum article, I suspected that our connection issues might have something to do with the encryption algorithms we use for the WiFi networks our router manages. It was a quick fix to adjust the router to use AES, rather than TKIP, to encrypt our signal. I'm not sure why DD-WRT defaults to TKIP, but making the change instantly boosted my iMac to a 300 mbps connection, and increased my speedtest results results by 50% (up and down). Comcast is giving us a pretty good connection for our $30/month.

Previously we'd get an even 20 up and down.

Smoke from the 70,000+ acre Whitewater Baldy Complex Fire has filtered into Albuquerque, making for a nice sunrise and poor air quality.

I decided to purchase the Mac App Store version of Coda, mainly because that's the only way to get iCloud support. Since I've spent the better part of the last three months re-writing Planbook for Lion's Application Sandbox, I was surprised to see that Coda 2 doesn't implement the Mac App Sandbox.

I get why- Coda is deeply integrated with the file system and other low-level components of Mac OS and sandboxing would make this integration difficult or even impossible.

The problem is that Apple has stated that only bug fix updates (and not feature updates) will be allowed to non-sandboxed apps after June 1st.

If you have an existing app on the Mac App Store that is not sandboxed, you may still submit bug fix updates after June 1.

-Apple, in an email to developers on 5/18/12

This is why I'm working so hard to develop a sandboxed version of Planbook (rather than implementing cool new features). I want to be sure I can deliver future feature updates to my Mac App Store customers.

So, Coda 2, released one week before the sandboxing requirements are implemented, may only receive bug fix updates (as opposed to new features). I'm sure this release date isn't coincidental.

Hopefully Panic has enough sway with Apple to get their Coda 2 feature updates approved. And, I hope that I'm not going to miss out on the great stuff they're going to implement in 2.1 and beyond because I used the Mac App Store to make my purchase and Apple sticks to their rules regarding the sandbox and updates.

It almost makes me wish I had purchased the direct copy instead and given up iCloud support. Panic, being upstanding members of the Mac community will, I imagine, find a way to give direct copies to Mac App Store purchasers should feature updates be impossible through the Store.

The Mac App Store has been great for developers like me, but this kind of ambiguity is really stressful, especially now that such a large portion of Mac software sales go through the App Store.

As seen from south Albuquerque, NM, USA- May 20th, 2012. Taken with a handheld pair of solar glasses as a filter.

Lea County, in Southeast New Mexico, will soon be home to a 17 square mile ghost city designed to let businesses, the government and universities test ideas and devices in a safe, sequestered environment.

[Y]ou've heard of NIMBY (Not In My Backyard). We have never confronted that in New Mexico.

From About.com (I'm not linking to the actual content):

Actually, this method starts with diluted sulfuric acid, which you boil to make concentrated sulfuric acid. This is the safest and easiest method of making sulfuric acid at home.

[materials needed follows]

car battery acid

glass container

outdoor source of heat, like a grill

When I was teaching, I can't imagine suggesting to anyone that they should concentrate sulfuric acid in a glass container on the barbeque. Beyond the inherent dangers of sulfuric acid listed above, heating glass over an open flame carries a risk of breakage. Sulfuric acid, if spilled on your grill, is going to react with the iron the grill is made of to produce hydrogen gas (which you probably don't need near an open flame). Compare the About.com tutorial to how Canada's occupational safety administration suggests working with sulfuric acid

From eHow.com (again, no link):

Pour the sulfuric acid solution into the one liter Pyrex bowl and heat the bowl to 100 degrees Celsius with the stove/hot plate.

and

For example, to make a sulfuric acid solution 1/10th of its original concentration, add 900 mL of distilled water to 100 mL of original acid solution.

First, eHow is suggesting that you concentrate sulfuric acid over the stove. I've actually seen someone place a pyrex bowl directly onto a stove burner. It took a few minutes for it to shatter. Even though the desired temperature of the sulfuric acid is 100℃ (incredibly dangerous at home on its own), the stove burner is much, much hotter than that and can easily destroy a pyrex bowl. Fortunately the bowl I witnessed only contained water- imagine spilling sulfuric acid all over your stove, into the burners and oven, onto the floor and most importantly, all over the home-chemist standing nearby.

Secondly, eHow violates one of the first rules that chemistry teachers teach their students- never add water to acid. Always slowly add acid to water (here's why).

eHow and About.com don't understand how to safely work with chemicals and they don't understand basic principles of chemistry. Their quest for pageviews by providing "how-tos" on every subject imaginable has led them down a path that could injure people who follow their directions. They should take these pages down.

(via Adrian Dingle )

Here's what I did:

1.  I installed all the Canon software on my Mac.  I popped the CD into the drive and ran the Setup application.  It took a while to install and required me to connect the camera to the computer via USB so it could download the appropriate software.

2.  I took a few test shots with the camera.  After taking the test shots, I pressed the physical playback button at the bottom right of the back panel to view my pictures.

Viewing an image on the camera

3.  There's a wifi icon on the playback screen (top left).  Tapping this brings you to a semi-crude display letting you select a device that you want to transfer pictures too.  All I care about is transferring back to my computer so I figure the computer icon is the one I want.

Selecting a device that will accept pictures

4.  I tapped the computer icon and was asked to select an device.  I assume this means a computer, but there aren't any shown because I haven't setup the camera yet.

Selecting a device (there are none as I haven't set up the camera)

5.  I tapped 'Add a Device' and was magically brought to a screen enabling me to connect the camera to my wifi network.  I selected the network and entered the password.  I was online in a few seconds.

Selecting a WiFi Network

6.  Once I was online, I was brought back to the 'Select a Device' screen where my iMac now automatically appeared as a device available for selection (this is the computer that has the Canon software installed).

That's my iMac (running the Canon software).

7.  I tapped 'Jeff's iMac' and the Canon software opened on the computer and let me import pictures via WiFi. Pictures transferred at a rate of roughly 3 seconds per picture.  

Canon software running on my iMac and importing pictures.Now, anytime I want to send pictures from the camera to the computer, I go to the playback screen, tap the WiFi button and the import software opens on my Mac. The Canon software does have a preference to automatically start importing pictures when it launches, but inexplicably it still requires me to acknowledge a dialog on the Mac before the images start transferring.  So, I still have to go to the computer to initiate the transfer.  Hopefully this gets fixed.

Technical details:  I'm using an iMac (i7) running Mac OS 10.7.3.  My router is a Netgear WNDR3700 v2 running DD-WRT (17201).  The iMac has a static IP address assigned by the router and is connected wirelessly.

I'll post some comparison shots between my iPhone 4S and the Canon ELPH 320 HS tomorrow.  I'm just glad the WiFi link seems to be up and running.