I used to send myself every other year. Strangely, I’ve been attending for over 10 years now. Seems odd that it’s been so long. It’s been wild watching the changes in the conference over the years. This year is no different. There’s hardly any “just” MacOS X sessions now – iPhone and iPad (not surprisingly) crowd out the whole schedule. The time to selling out the conference is shorter this year than before, and I rather expect the crowds to be as insane as ever. Fortunately, many of my friends from Seattle Xcoders will be there – even if they love taking digs at each other over sax interface xml parsing code and “unnatural love”.

Best of all, the really big project weighing on my mind for the past month is out – I can go play, hack, drink, laugh with my friends, and not worry about deadlines for a while.

Here’s the details:

Do you love programming for the Mac and iPhone and think Objective-C is the bees’ knees?  Are you sick of your boring 9-5 job and wish you had more interesting problems to solve?  Would you like to join an indie Mac shop in the heart of downtown Everett, Washington?

Flying Meat ( http://flyingmeat.com/ ) is looking for a full time programmer to work on our award winning applications for the Mac, iPhone, and iPad.

The ideal employee has real world experience with Objective-C, programming with Xcode, a friendly attitude when talking to customers, and a penchant for figuring out tough problems.

Location:
- Downtown Everett, WA.

Responsibilities:
- Programming (fixing bugs, adding new features, etc) on our existing applications, and help bringing about new ones for the Mac, iPhone, and iPad.
- Assisting with 2nd level support.

Requirements:
- Experience with Objective-C and Xcode.
- Experience with Subversion or similar version control systems.
- Ability to work with at least a couple of scripting languages, such as Python, JavaScript, Ruby, Bash, Lua, JSTalk, etc.
- Experience shipping an iPhone, iPad, or Mac application.
- Highly professional, with the ability to multitask and deliver solid work on tight schedules.
- A sense of humor and an easy to get along with personality.

Experience that will help you stand out:
- Ability to work comfortably with Mac OS X graphic APIs such as Core Image and Quartz.
- Familiarity with network protocols.
- Ability to zip around in Terminal.app while blindfolded.
- You know the Mac HIG inside and out.

Benefits:
- Paid vacation.
- Profit sharing.
- Relaxed working environment.
- Retirement plan.

How to Apply:
Please send resume in plain text to gus@flyingmeat.com .  Make sure to point to projects you’ve worked on, and we would also love to see code you’ve written!

The only problem, in my opinion, with GitHub is having to use git! I find it darned confusing, and I’m pretty confident and effective with source control tools. Not that I don’t appreciate it’s power, I’m just not in favor of that particular level of complexity/ease-of-use tradeoff.

Anyway, while I’m not great with it, I can figure it out. And since I did, I wrote it up. The example is available for the GitHub project letters if you’re interested. It should be really easy to translate into any other project on GitHub, and has the basics for collaborating, including getting code from anyone’s fork of the project and pull it into your own.

http://github.com/ccgus/letters/blob/master/README-CONTRIB.markdown

Hope it’s useful… I’ll be doing another one of these at some point for BitBucket and mercurial…

I’ll definitely have to check this one out this coming week on the commute into work.

I’ve been impatiently awaiting this day for a while. I promised Gus I wouldn’t talk about features or the code or whatever while it was in beta, but now it’s out! The handy little feature that Gus posted (Command-Shift-6) a little while back has been my virtual life saver while making screen shots for classes. The new feature (my favorite, clearly) not only makes a snapshot but brings ALL the windows on your system in as layers in an Acorn document.

You can navigate down a great little hierarchy to find the one you can, select and copy the layer, and then paste directly into Keynote. Getting “just the right” shot is a hell of lot easier now: no trimming or dealing with that shadow effect (a real PITA for screenshots), you don’t have to worry about what background you have on your desktop, and even the windows of a given application are nicely sorted out into their own layers. You can merge them back together, or just grab the specific window you need (Hello Interface Builder!).

If you’re doing anything with screenshots on the Macintosh – get this program now! The minor cost will get paid back time on the first project you do with it.

The bullet points really define it well. Just go read Rand’s post. Heh – and his blog, if you don’t already.

A new version of class-dump is now available. You can download it from the links on the class-dump project page. It is built for Mac OS X 10.5 or later.

Version 3.3 adds support for Snow Leopard, improves property handling, improves structure/union handling, fixes a bunch of bugs (including two crashers), and no doubt adds some new bugs.

(Via Steve Nygard’s Weblog.)

While the MyBus.org site has been responding fine for the past few weeks, we’ve now seen multiple times over the past year when their site has been down and/or unresponsive to the point of breaking the Seattle Bus application. Hopefully this will fully resolve it. A future point update may allow users to choose between real-time trackers, but that hasn’t been coded in yet and I hope won’t be necessary.

I’ll post an update when it’s past review and is available for purchase again on the iTunes AppStore.

I apologize for the trouble and annoyances.

If you have the application already, it’s worth noting that the application does work periodically. Unfortunately, the data feed is just so inconsistent as to be nearly useless.

UPDATE:

I have a new parser functioning correctly with by MyBus.org and King County’s Metro Tracker site. The update should be uploaded to the AppStore shortly. I’ll post when I get the new version uploaded, and when it’s available.

I must say, it’s incredibly embarrassing that the King County site doesn’t even emit well formed HTML. The new parser is an interesting screen-scrape accumulation of regular expressions to pull out the relevant data. At least they’re posting it online…

Two reasons finally swayed me to OmniFocus:

1. Right now, out of the box, it syncs between multiple Macs and the iPhone. (Things doesn’t – although that’s coming in the future)
2. I know some of the Omni guys and I think they do some darn nice stuff – I feel good about supporting folks who’s office is just within a couple of miles of my house.

Diving in headfirst, I got both the desktop and iphone versions of the app. Getting started with OmniFocus is, well, heady. There’s a lot in there, and a fair bit to learn. I was jones’n for the simpler “just tag the thing” structure of things for a bit, but I’m coming into sync with the OmniFocus way and getting some goodness from it. Since it caused me some gnashing of teeth to start, I thought I’d share what I’ve learned.

The two primary ways of looking at your work in OmniFocus is by project and by context. They’re orthogonal – so a given task can have a context and a project, and those don’t need to be related. The context setup flipped my trigger a couple of times, trying to get the sense of what they hell it was for. I’m not even sure that I’ve nailed it – but in my world, “context” in the OmniFocus set up is a description of the limiter to where you need to be or who you need to be working with to get something done. I’ve stripped out the default contexts and drained it down to “Office”, “Home”, “Online”, and a list of my team members.

The “Office” vs “Home” is really the differentiator for me. I’m online damn near all the time – but I kept that in the pile to keep it separate from contexts where I might be out somewhere and needing to get something done (like picking up groceries, in the classic setup of the app).

The “people as context” is my stab at dealing with follow-ups and tasks associated with the awesome team that I’m managing. The whole reason I decided to dive into GTD in a serious way was so that I had a handle on the sheer information volume load that was flowing through and around me – an order of magnitude greater than when I was just knocking stuff down by myself and mostly on my own recognizance. I’ve just started with the people as context setup – but so far it looks to be working OK. The question that I haven’t answered, and lies before me is do I want to track tasks that I’ve delegated to folks within my team in my OmniFocus task list. I may try it – but I fear that’s a slippery slope. I’m thinking that I’ll only really want to aim that towards when I need a follow-up or information back to do something else.

Projects are the other big deal in OmniFocus. I’ve got a ton of projects. I’ve also got them cascading down with folders (took a while to sync into that setup) and I’m using default contexts with those folders. So for something related to, oh, say one of those “Enterprise Software” systems I was tirading about yesterday – I make sure I have a pre-set context to “Office”. Any tasks I create under that project from there automatically get the “Office” context, which saves my fingers a few typings.

I also work between Mac and (sob) Windows. Nothin’ doin – it’s just the state of the world that I need to interact with both worlds constantly. I’ve also migrated my half-assed attempt at GTD with Outlook’s task manager (couldn’t keep a damn thing organized with that setup) fully into OmniFocus. So the trick is dealing with emails that come in from Outlook, asking for me to do something. I’ve taken advantage of the nifty Mail.app rules integration to enable me to forward email to a different inbox and that gets ingested into the world of OmniFocus. Works really well too – I just leave Mail running on the laptop and stuff gets crammed into my OmniFocus inbox for me to categorize and deal with at my next round of that (currently I’m doing that at the end of the day, cleaning up as it were).

I haven’t yet jumped in to reviewing my tasks and projects, but I’ve set up a repeating “to do” item (tickler, in GTD parlance) with OmniFocus to remind me to do just that. I also haven’t looked at the Calendar sync – at some point I may dive into that, but I haven’t so far.

Finally, Perspectives are the key to making OmniFocus really sing. You can set up one (or several) views into your world based on due dates, contexts, projects, etc. You can save a window’s view as a “Perspective” – and I’m making aggressive use of that setup. My only gripe there is that perspectives aren’t shared with the OmniFocus database – I had to set them up on each machine I was working with.

Finally – the iPhone app:

So far, it’s mostly a way for me to ingest tasks while I’m in a meeting. I can tap the task in there, and I feel a lot more confident that I won’t loose track of it. I generally just shove things into my Inbox from there, and at the end of the day I review all the stuff I need to get done, tasking it out further if needed and categorizing it from there. I tried to set up the location based context mappings, which seemed kinda nifty, but I ran into something unhappy there, and I’m working with Omni’s tech support to get that nailed down and straightened out. Not sure why – but it’s not ever returning a location to the application.

The sync, my key value and reason for choosing OmniFocus, is working great though. The end result is paying a bit more for the setup (desktop & iphone application), and I wish it would sync a bit faster than it does, but it DOES the sync and everything is being kept up to date.

As a final note to anyone reading this far – if you’re going to invest in the software to do GTD and you choose to do it with OmniFocus, take the time to watch the videos that they provide and spend a weekend getting used to the software. Also – like writing software – don’t be afraid to trash what you’ve done and rejigger the thing based on what you’ve learned to make it better for yourself.

I knew about OpenStreetMap from OSCON last year (or maybe even the year before) – but I had no idea that someone had put together this library. The terms of service for Google Maps are actually somewhat restrictive, Microsoft is quite a bit better, but this really tops them all. The mapping is also incredibly good. The united states have been pretty lucky that the information is technically “free”, even if finding it in published forms that is useful can be tricky. Other countries are FAR less open. The UK, for example has incredible ordinance survey maps, but they aren’t considered “public information” there.

Anyway, if you’re considering a mapping component to your iphone application consider checking this out.

Rands In Repose: FriendDA:

The lesson of the Holy Shit is that when you stumble upon a truly revolutionary idea, you have the ability to recognize it. There are lots of people who, when they first saw a web page, thought, ‘I can order pizza on the phone with a live person. Why would I do it on the computer via, what’d you call it? A browser? Also, why is that text blinking?’

You didn’t see pizza. You didn’t even see the blinking text. In fact, you saw nothing in particular; you just had a gut feeling. There was no logic or strategy behind the gut feeling, it was a sense of deep potential. Your amorphous thought was, ‘I can’t think of anything I won’t be able to do on the web.’

A Holy Shit is the instant of instinctually recognizing massive potential.

He goes on to talk about FriendDA, which is something that has been implicitly used among a lot of tech geeks that I know for a number of years. The concept has been incredibly prevalent among iPhone developers even prior to the notification that Apple was rescinding that too-fucking-long-lasting NDA. Thursday nights at Luau, after Xcoders, there’s bound to be all sorts of talk. It shouldn’t be a surprise that iPhone’s get whipped out and running sample code passed around. “Yeah? How’d you do that…” comes up frequently thereafter and the conversation takes another left turn and riffs on some technical content for a while until the next round of beer shows up and shuts people up again for a bit.

The interesting lesson to be learned is that the images used in the UITabBarItem properties aren’t used with all their colors – they’re basically a mask. The image that’s displayed in the user interface is based on what’s set to transparent or not, obscuring any additional detail you might think you’re adding. That’s actually a bit of a relief – I was worried about matching the colors properly. Took me by surprise when my images were solid square blocks though. I’ve since used Acorn to generate up some PNG files with transparent sections to make my UITabBarItem masks, and that appears to be working quite well.

By the way, make your mask about 30 x 30 pixels. Making it smaller just looks funny…

… or how [UITableView reloadData] kicked my butt

The SeattleBus application includes a database with 1018 stops in it. Those were all the stops that I had with geolocation data and to which the MyBus web service responded with stop information. I started with 1211 data points, but just around 15% of the bus stops didn’t return any data.

One of the views in SeattleBus is a list of all the stops – and that’s where I felt the pain. In fact, it wasn’t until after 1.0 shipped that I realized exactly where the pain was coming from. It isn’t interesting caching or slow lookups from SQLite – it was from invoking UITableView reloadData where the data had 1000+ elements. Loading 100 or even 300 was a pretty reasonable delay. You’d notice it, but it wasn’t too bad. 1000 just pushed it over the edge to a good few seconds. Not to mention the UI component of trying to scroll through 1000 items on the iPhone. Man, that’s just painful. It screamed for (and I implemented) a search mechanism to make it a more useful view.

At WWDC this year, they warned us that reloadData was expensive. Ooooh yeah. One of the suggestions that I heard for resolving that was to load a subset of the data (say 100 rows, which isn’t too bad of a wait) and then using the method UITableView insertRowsAtIndexPaths:withRowAnimation: to inject additional rows using a background thread of when the user gets to where they need them. When I’d do a search and get back anywhere from 8 to 100 items (typical search in my tests), the reload was nicely fast. It was when I cancelled the search and reloaded the original view that everything went to hell. After reseting my model objects like a good programmer, I’d invoke [UITableView reloadData] like I was used to doing on a desktop Mac’s NSTableView. Then (on the device – the simulator was plenty fast), I’d wait.

Kris Markel came up with an interesting solution when cobbling together a search example for me (now That’s a beta tester!). Instead of preloading the data he was loading it in from the database in the UITableView data source method tableView:cellForRowAtIndexPath:. Ahhhh, right. I didn’t follow that path exactly (although I was darned tempted to), but instead implemented caching so that once I did that particular load, I didn’t have to re-do it again and again. I’ve got the application set to blow that cache away on a low memory warning, but it’s made a lot difference.

The next step there will be to load a subset up front and then populate that cache in the background with NSOperation or something equally interesting for a background thread. There’s no reason the user should have to wait through the 2.7 seconds of loading time for the whole kit.

Pretty much a one-liner typo “looks right” until you realize it isn’t bug. I’ve got it fixed in version 1.1.1 – in fact, that’s pretty much the only thing in version 1.1.1. I fixed the bug and uploaded it to the App Store to put it into review.

If you haven’t upgraded from 1.0.2 or earlier to version 1.1, then consider waiting for this update to clear. If the timing is the same, it’ll be available roughly October 8th. I’m afraid I don’t have any control over how fast it moves through the App Store approval process, so hopefully sooner and not later.

It’s one of the sides of the App Store/sales channel setup that I really wish I could change. If I was delivering this application myself, then that update would be out right now and damage limited to the few folks who upgraded in the past 8 or so hours that the broken update was available. At this point, I’ll have to guess a large number of folks will get the 1.1 update/upgrade before I can get out a properly fixed version. I’ve got a good sense of how many customers I have – so I’ll keep track. I hope it’s a low number, but I fear it won’t be.

I missed something in my testing, because when I upgraded my copy of Seattle Bus to version 1.1 (now available in the AppStore), my favorites were all switched around to stops I didn’t recognize. Damnit.

It’s easy enough to reset, but I’m very annoyed that I missed that bug. I expect a lot of you will be too.

I updated the description in the AppStore so that folks upgrading will at least have a chance of knowing about the breakage before it hits them. Since I don’t have any other means (aside from this blog) of contacting my customers directly, that’s all I could think of doing. Well, and writing this entry.

I think it’s still very worth updating for the other features. This update also happens to have an updated bus stop database associated with it, and it’s the code that “upgrades” your database with the new information that’s obviously flawed. I even explicitly tested that functionality, but clearly I missed something too.

My apologies to all of you for breaking your favorites!

I’ve been a listener of Scotty’s podcasts since they’ve started, but I’d never considered being on one before. John Chaffee of Busy Mac Software has been on a few and suggested that I might be a good candidate for this one. Since it was about developer groups, and I’ve been running one for the past 3 years here in Seattle… yeah, ok – I’ll give it a go.

The whole process was fun, I got to meet a few folks I’d never run into previously, and chat with a few that I had met previously.

I just hope I don’t sound like a raving lunatic or mumbling fool.

As it turns out, the date parsing for what I’m trying to do is a tricky little bugger, and looking at the timestamps that resulted at 11:55pm for 3rd & Union downtown showed me a few glaring flaws.

I’ve fixed most of them – the remaining pain point I’m hoping to verify later tonight. It seems that if a bus is scheduled to arrive at 11:55pm, and the current time is 12:01am – the system thinks you’re waiting for the bus that following night at that time, and you get a wait time of something like 1440 minutes.

It also appears that the web system from transit has a slight flaw with their own time display. They display 12 midnight at 12:00pm. I don’t know about you guys, but I always thought that was noon, not midnight. Ah well – another special case in an already messy bit of code, because parsing time from simple strings is frankly just rather fraught with difficult situations.

So with any luck I have this nailed down and ready to go… I’m going to check tonight, and then I’ll be getting it uploaded to the site. Even if I haven’t quite got the bugs all nailed down, I suspect I’ll get it uploaded to the site. I think this bug has been around since day one, so waiting a little more for the fix is better than holding up the other good stuff I want to get into your hands.

Update: As of 7pm PST, September 16th – version 1.1 has been uploaded to Apple and is pending review. There remains a known issue with date parsing and determining “wait times” when you’re looking them up just after midnight. I’m continuing to work on that, and will release an update – but I didn’t want to hold up the other features for that bug.

Pretty damn much on the money.

Ended up playing about 12 hours yesterday…