Tonx Coffee

My relationship with coffee has evolved over the years. Most blog readers probably associate me with carrying a big-ass vacuum thermos of coffee into work and drinking it over the course of a day. And almost never washing out my coffee mug. If that's your impression it might astonish you to hear that many days now I only have a single cup (not mug, single cup) of coffee and at most I have two cups in a day. For a while I had a Senseo (there was a post about that back on Pic-A-Day when I ran that) and nowadays I use plain old French press which just generates a cup or so. I ultimately bought a larger French press that can make three cups at once for when I have guests who want coffee but now I just make one cup, then drink one cup. Simple.

Reasons? Well the reasons are legion. I'm more caffeine sensitive now. I suspect that's a mix of drinking less coffee and getting older but it's tough to separate the two there. If you know me as that "drinking a pot from a thermos" guy you also know me as a the guy who pops Tums all days. Guess what? Less black coffee means less stomach acid. Science! Also as I wrote on the defunct photo-blog I got weirdly OCD about "if I brew a pot of coffee I drink the whole thing". Switching to the Senseo meant I brewed coffee one cup at at time so drinking the "whole thing" was no longer a deal, but it also meant I was drinking mediocre coffee. Switching to the French press meant I could make good coffee and still only make one cup at a time.

OK, swell. Now I just need coffee beans. For a while I was trekking up to Orchard Valley Coffee to buy beans but that's a whole drive and crosses the 17 traffic and can be icky at the wrong time of day. Then for quite a long time I went to the local coffee shop (Lime Tree Espresso) that sources beans from Barefoot Coffee. This was a Good System™. Problem is that the local store is pretty much a one–man shop and sometimes he is just closed unexpectedly. About three weeks ago I went one day and found out he had started closing Tuesdays at noon. I went Wednesday at 2 PM and he was just "out until 2:30". At which point I had to go buy Cthulhu–knows–how–old Peet's beans from the Safeway. Enough. It's 2012, can't I just buy good coffee beans from Amazon and have somebody ship them to my hermetically sealed house of Board Games 'n Code Development™?

Well I didn't actually check on Amazon but the answer is yes! You can get 12 ounces of quality fresh-roasted beans shipped to you every two weeks from Tonx. But don't use that link use my pyramid scheme link a bit later. It will save you $10!

I just got my second shipment from Tonx this week and opened it up today. I have to say, I'm really pleased. 12 ounces/2 weeks is at least really close to my coffee bean consumption and I like the coffee just fine. It's within a buck or so of what I was paying at the local shop and I don't have to drive out and there and hope he's open.

So there you are. If you like quality coffee I'd recommend checking out Tonx. If you want to give it a try use this link. You get $10 off your first month and I think if three people use that link I get a free T-shirt. Or something like that. Anyway it's good coffee. Check it out.

Road Trip is Available!

Hooray! Road Trip is available in the App Store now for iPhone, iPod Touch, and iPad.

I don't know that I've ever really written down the story behind Road Trip so now is as good a time as any. Set the wayback machine to August 2008! Apple had just updated what was still known as iPhone OS into version 2.0 with the App Store allowing third party development. I had picked up an iPhone in March but had found at the time that iPhone development was limited. Apple considered it a beta and getting the keys that let you put an application on the hardware was at their discretion and I wasn't invited to the party. So around July or so I had acquired the necessary certificates and was trying to figure out what my "Hello World" learner app would be.

By this point the Big Honkin' Road Trip (BHRT) was well established. A group of friends from my Kesmai days would gather somewhere and we'd travel around hanging out and visiting various local HOOTERS. Usually we tried to find a state where there on the order of three – six restaurants and visit them all, thus completing the HOOTERS of (state) tour. Our process for handling this was a little complex. Sometimes there would be a car rental, sometimes we'd have somebody's vehicle(s). There would be hotel rooms, there would be gas costs, there would be bar/food tabs. As different people paid for different items we'd constantly be passing back and forth cash as we tried to pay for things evenly. Mind you, sometimes we'd have six people on the trip with one or two others showing up for one stop or another. Plus there was drinking. We'd have somebody staying sober to drive, but that wasn't always the person tracking the cash. There were always these crummy morning reconciliation sessions where we'd dig up receipts and try to reconstruct who owed whom what. The previous BHRT I had used an OmniOutliner document to track every receipt and all of the outstanding debts. It worked but it was still a pain.

For some reason while Karin and I were at PAX in August it hit me: I could put an app on my iPhone to do all of this. At this point I had one week to write the app. This was the first version of Road Trip. I worked on it at PAX a bit, and wrote the vast bulk of it on my flight from California to Dulles to start BHRT2K8. It wasn't quite ready that night and I have some humorous memories of frantically debugging the math in Tony's car on Saturday morning because we needed the app to work before I started drinking. We all agreed that after I had been drinking I wasn't allowed to tweak our key financial instrument – this was really a refinement of an old MAMBA Kings rule where we could code after drinking at Fridays After Five (a little civic party that would happen in the summer that was a couple of blocks from our offices) but we never committed code until a sober review. (Indeed, you can see my key observation about that debugging session in a post on this blog.)

The UI for that version of Road Trip was hideous. It had this tabbed interface with no graphics, the first version couldn't handle splitting things non-evenly, there was some terribly confusing debt/payment nomenclature that was overly complex, and it was ugly as sin. But it worked. You could tell it "Oh Tony paid for a hotel room that Tim and Tony are splitting" and it would tell you how much each person owed each other. The core idea was offsetting debts: if I owed Tony $90 for a hotel room and I picked up a lunch tab so Tony owed me $45 then I'd still owe Tony $45. Now if there's a third person in that mix the numbers got more complicated but the app didn't care. It would tell you who owed the most money and they picked up the next tab. That would likely change the "Deadbeat" and we'd rinse and repeat. On the last stop of the trip we'd settle up and that would be the only time cash would have to change hands. We usually didn't have anyone owe more than $50 or so.

We used that version of Road Trip for several BHRT's and it slowly got more features, but was still ugly as hell and complicated. I was busy doing other paying work so Road Trip never got a through work over and I was never convinced there was much market for the application. Our trip to PAX East last year wasn't technically a BHRT but we did use Road Trip for settling debts.

OK, so last year my paying work stopped and I didn't have a great lead for something new. I decided to do iOS work and at that point why not dust off Road Trip and ship it? Maybe it won't be a big hit, but it's mostly done right?

Well, no. iPad had happened between 2.0 and 4.x and it really ought to be a Universal app. And the UI was just awful. And it really should have a map view, and maybe something about photos? Really the only thing that salvageable was the core math crunching. So the ugly Road Trip became Road Trip Classic and I started a new project, using iOS 5.0 (then in beta) and embarked on learning storyboards, the new iPad UI elements, and generally modernizing it.

And here we are way too many months later! I like the new UI and it even has some pretty textures evoking the key conceits of the app: money and roads. Maybe somebody will find this app useful, and at the very least we'll have an easy–to–use version for the next BHRT …

If you (or somebody you know) would find the app useful please check it out!

Bring me your comments, yearning to be free!

In the comments thread over on the X-Com post Tony mentioned that there was an annoying CAPTCHA that you had to pass in order to post a comment. I don't see that because I have an account on the site so I'm not considered an anonymous commenter. I can't find a setting to turn off the CAPTCHA but I can have up to 250 accounts on my current plan. I can make accounts that let you login and post comments without hassling about who you are. Tony beta–tested this and it seems to work well. However, what I can't provide on my current plan is a form where you sign up for an account. So. We don't' see a ton of traffic on this blog and I suspect I can keep up with requests for accounts. If you'd like to post a comment drop me a line and I'll get you squared away. If you don't have an email address for me there's a form in the sidebar on the right that you can use to contact me.

I should note that I'm not doing anything to remove the old "anonymous" comment system, so if you're posting a one-off comment and would prefer to use that go ahead. It just turns out that if you're likely to make multiple comments over time that it's a bit friendlier to get an account here and avoid the rigamarole. It's a new option, not a replacement of the old system.

Obtaining your iOS Device Unique Device ID (UDID)

So you've got a friend who has written an iOS app and he or she wants you to beta test it. (Hint: if you're reading this, I'm that friend!) What do you need to do?

You need to provide that friend with your iOS device's "Unique Device ID" or UDID. Your friend can then generate a certificate that tells your device that it is allowed to run the beta app. You can drop this certificate and the app itself on iTunes and iTunes can then install the app on your device. All well and good but UDID's are long numerical strings and are a pain to find and type in anywhere. Apple provides an interface for getting them but it works a bit unusually and I thought it was worth writing some notes.

Here's an image of the Apple instructions. Everything you need to know is here but you have to read it carefully.

So here are step-by-step instructions:

1. Launch iTunes.

2. If you have Wi-Fi Sync enabled your device should already be in the sidebar. If you don't have Wi-Fi Sync turned on then you'll need to connect the device with a cable.

3. Select the device in the sidebar and make sure you have the Summary Tab displayed. You'll probably see the Serial Number displayed.

4. Click the Serial Number itself (or the text label that says "Serial Number") and it will toggle to displaying Identifier (UDID): and the actual UDID string.

5. OK, this is the weird part. Even though you have no text selected if you hit Ctrl-C right now iTunes will copy the UDID onto the clipboard. You can't select the text in any way (since a click will change the display back to Serial Number) but trust me, this should work.

6. Paste the UDID from the clipboard into an email and send it to your developer friend. He or she will thank you!

MKMapView is a Naughty Minx

OK, that was nasty to find. I've been plagued on and off by a crash bug that I only seem to see on the iPad and it's never been very reproducible. Today I was putting textures in the background of the iPad screens and found a reproducible crash. Hooray! Except as soon as I put a breakpoint in the crash would go away so there's some sort of race condition/multithreading going on. Mumble grumble.

The breakpoint was everyone's friend EXC_BAD_ACCESS. Of course this means the bad code wasn't anywhere near the actual crash. (And as an aside, surprising to me because I use ARC and therefore I don't write the retain and release code. So there's probably an ARC bug in here as well. Later I'll try to make a test app and submit a Radar.)

How did I find it? That in and of itself is a convoluted story and maybe worth relaying. I turned on NSZombieEnabled (in Xcode 4 you go to the Edit Scheme window and there's a checkbox in the Run/Diagnostics panel for Enable Zombie Objects) and discovered it was my TripMapViewController class receiving a respondsToSelector: message after it had been deallocated (and after the view wasn't onscreen anymore). This is a bit of a red herring because I use respondsToSelector: a fair amount so I scrubbed through all of my code and verified that I wasn't the culprit.

OK, I have to admit that stumped me for a moment. So it would appear that some other system thread is calling respondsToSelector with a pointer that it snuck past ARC. I did something hacky just to confirm the situation: I stashed a copy of the TripMapViewController in a static pointer, which should mean ARC no longer released the object. That worked and the crash stopped. Now what? After that I realized my object was still around and that I could overload respondsToSelector: and at least see the damn callstack. Turns out this controller gets a lot of respondsToSelector: messages; enough that you can't just stick a breakpoint in there. I did some more clunky things so that I could turn on a breakpoint after viewWillDisappear had been called. Sure enough, this big pile o' hacks worked for me: I could see the callstack of a bogus call. Problem is that it was all system stuff, with several calls just labeled "MKLongHash". If you Google MKLongHash you only get one hit which turns out to be a Stack Overflow thread about ARC and messages to zombie MKMapViews. Oh really?

---

Sure enough that's it. If you set the delegate of a MKMapView to a controller it is possible that ARC will incorrectly release the controller while some MKMap thing is still messing about. The solution provided in the article is to explicitly set and clear the delegate on viewWillAppear/viewWillDisappear. This worked for me. Maybe the next person who Googles for MKLongHash will find this helpful :-)