Musings of a Programmer

I’ve seen a lot of people complaining about how bad 2009 was on Twitter and Facebook, and pretty much everywhere else. And while there were definitely some down moments, I’d have to say that for my money, 2009 was one of the best years I’ve had. So maybe your 2009 was horrible. I’m not trying to dispute that. I’m just going to politely ignore it, and go about my day.

First and foremost, our first child, Logan, was born this year. I can’t begin to put into words how awesome fatherhood has been. Watching this little person grow from barely being able to move, to already being able to walk a little in just about eleven months is incredible. Not to mention the personality he’s already got.

Then there was my business that I finally got off the ground, even if only a little. It’s still not much more than a hobby, but it’s paying my server costs. I’m currently working on version 2.0 of Logbook, and hope to get it out the door before school starts up again at the end of January. But we’ll see what my work schedule has to say about that.

And then there’s my actual day job. You know, the one that pays the bills. While 2008 saw me finally land a full time programming gig, it was Perl, and not really my first choice. But at least it wasn’t UNIX admin work anymore.

Well, November of this year, I found my perfect job. I’m working for a small startup in Boston. And while I’m working primarily on iPhone software, which I LOVE, I also get to do some Mac software. I’m working with a great group of people, and am really looking forward to 2010, and the stuff we have coming down the line.

So there you have it, my 20,000 foot view of 2009. And let me just say, I’m really looking forward to 2010 as well.

So, after my post back in March about Core Data being available for iPhone 3.0, I was asked if my enthusiasm for Core Data on in Cocoa Touch was misplaced, or at least premature. Well, now that I’ve converted the storage back end of Logbook from FMDB, which is a thin Objective-C wrapper on SQLite, to Core Data, I can safely say that Core Data is just as fast, and in some cases marginally faster.

And this time I actually have some data to back that statement up. Before I did the conversion, I added some simple timing checks to the code, and recored the times for loading table view cells using FMDB, and using Core Data.

If you look at the chart below, you can see that on average, Core Data is actually a little bit faster than FMDB, but not enough to alone make it worth the work of converting. The real win comes from the amount of code that you can just toss away after this is done.

Now, one of the questions I’ve had asked, is what about the agregate functions that SQLite, and therefore FMDB, allows you to use? The answer is tricks using NSPredicate, NSFetchRequests, and the agregate functions provided by Key/Value coding. These three features of Cocoa combined more ore less give you the same power of SQLite’s built in functions, and may even use those features of SQLite under the hood.

I am extremely happy to see this finally be allowed. I was ecstatic when Apple announced in app purchases back in March. But then immediately crashed when we were told that “free apps remain free”, and there would be no in app purchases for free apps.

Now that developers can use in app purchases to have upgrades from free apps, we’ve moved one step closer to the way most indie software is developed. We still can’t do time limited demos, but we can have feature limited free versions.

OK, so I’ve had this thought for a while, and it’s not going away. That thought is that we need a CocoaHeads chapter somewhere in central CT. I’ve enjoyed going up to Boston for their meetings, but it’s just too far to make it every month. So while I’d like to keep going up to Boston once in a while, since they’re a great group of people, I’d probably end up running the CT chapter sometime other than the typical second Thursday.

So, the general idea is start a CocoaHeads chapter somewhere in CT, preferably somewhere near Hartford or Tolland. On the other hand, location and time would depend on who’s interested, and where we can find some place to meet. So, if anyone’s interested, drop me a line (craversp@gmail.com), and we’ll see if we can’t figure something out.

I should have posted this yesterday, but the price change took forever to show up in the App Store.

Anyway, I just wanted to announce that Logbook, my fuel and maintenance tracker for the iPhone and iPod Touch is on sale to celebrate the one year aniversary of the App Store. It’ll be $0.99 until sometime tomorrow when I remember to change the price back. So go get it, while it’s cheap.

Well, Apple just finished up their iPhone 3.0 event, and let me say, they answered my prayers and then some.

First off, they added Core Data (at least it was on one of the slides). As is evident from most of my previous posts, I spent a lot of time looking for a good ORM layer for the iPhone. I finally settled on FMDB, a thin wrapper around the SQLite API. It’s solid, but I wasn’t looking forward to using it instead of Core Data on one of my projects that was going to have both Mac and iPhone versions. Now, I don’t have to worry about that. Of course now I also need to consider picking up a copy of Marcus Zarra’s Core Data book, so I can really get down and dirty with it.

Now I would have been plenty excited had Core Data been the only thing they announced for developers today. Instead, they also announced a Maps API. And while it makes you provide your own map tiles, that’s not going to be a problem for me. I had plans all along to use my own tiles.

There were also a bunch of other developer centric announcements today, but those were the big ones for me. Mac <-> iPhone syncing for apps would have been nice, but I can live without that. And who knows, they may still announce it. Here’s hoping. On the other hand, I can’t expect Apple to do all of the heavy lifting for me.

Now begins the wait for the iPhone developer’s portal to reopen, so that I can grab me a copy of the new SDK, and get to work.

While heading over to the UK for a developers conference is way out of my budget right now, anyone who is looking for a good Mac developer conference should go check this out.  It’s been put together by Scotty, from the Mac Developer Network, and he’s done one hell of  a job. He’s lined up a great group of speakers, all of whom are giving talks that I wish I could attend. Go check it out!

Earlier today, there was a post over at Macworld asking for opinions about which Mac was the best one ever. This then sparked a few Twitter memes talking about favorite Macs, first Macs, and the same for computers in general. This got me thinking about my nearly life long relationship with various different computers.

The first ever computer I used was a TRS-80 Color Computer 3 that was bought for my family by my grandparents. I was about 8, and I spent an unhealthy amount of time typing in BASIC programs out of a book. I was amazed at what I could make this machine hooked up to a TV do. I eventually got to the point where I learned how to modify the programs I was working with, to make them do what I wanted, and not just what the author intended. I even learned how to use the attached cassette tape deck to save what I had done so it wasn’t lost as soon as I hit the power button.

After that, it was mostly whatever time I could get on the TRS-80 Model III’s, Apple IIe’s, and IIgs’s at school, as we didn’t get another computer at home until my freshman year in high school.

In my freshman year, it was a Mac LC II. I loved it. 68030 processor, running at a blazing 16 MHz, 4 MB of RAM, and a 80 MB hard drive. From a programming side of things, I never did much more than tinker a little with a demo copy of Metroworks. I did learn to tinker with the hardware some though, and that was fun as hell.

After that, I went through my “PC phase”. I had a ThinkPad while I was in college, and built a handful of PCs after that.

Finally, about 4 years ago, I got back into Macs. I picked up a nice, new 12″ 1.33 GHz iBook. I started playing with Xcode and Interface Builder, and that was it. I was hooked on Macs again. And slowly, I started getting rid of what was left of my PCs. And now, I sit here typing this on my nice, 7 month old white MacBook, watching TV on my PowerPC Mini (which is due for an upgrade), and my wife is still getting a lot of work done on that 4 year old iBook.

After about two months of trying out different object-relational-mappers for use in iPhone software, I came to the conclusion that they were all either too complex for what I needed (OmniDataObjects), or to immature (all the rest). I may give OmniDataObjects one last look for my next project, as it will have both a Mac and iPhone side, but for Logbook, I finally decided that FMDB was my best bet.

Now, FMDB is by no means a ORM. In fact, it’s not much more than a thin Objective-C wrapper around the SQLite libraries. So that means that you’re doing all your own saving and restoring out of the database. But with that limitation, comes some incredible power if you are comfortable working with SQL.

There are a lot of places where I just load up objects out of the database, just because I need to use all or most of the data they contain. But in others, where I only need one piece of information, or just a count of how many objects there are, I let the database do it’s thing. And from my experience, the SQLite team isn’t exagerating when they say they’ve optimized for speed where ever they can. Add to that the fact that, in places where I needed a total or average to display, I could just call a single line of SQL, instead of walking an array or other data structure, and there are some serious performance increases.

I orginally disregarded FMDB in my search, because I was stuck in the “why would I want to muck around with SQL” mindset. Once I got into it though, I remembered just how powerful working at that level with your data can be. Yes, some things are more difficult then they would be with an ORM, but really, not that much. I’ve actually come to appreciate FMDB enough that I may end up using it instead of CoreData on any project I have that will be on both the Mac and the iPhone.

In my last post, I started my search for a good object-relational mapper that I could use in my iPhone applications, since Core Data is not available on that platform. I had found FMDB, and ActiveRecord, but hadn’t started really using either, or stopped looking around for options. I have since discovered OmniDataObjects, which quite honestly is probably the most full featured, but least documented, ORM layer for SQLite. ODO also seems to have quite a few dependencies on other Omni frameworks. Not a huge deal, but I was looking for something as simple as possible. What I finally settled on was SQLite Persistent Objects.

I had actually started out working with ActiveRecord. I have done some Ruby on Rails work before, and the Objective-C version of ActiveRecord was close enough that I decided to give it a try. So I went through the process of creating my database, and initializing all the tables I would use. After that, it should have been a matter of defining my model classes as subclasses of ARBase, adding in their relationships, and then adding the SQLite connection call somewhere that will get called early in the application launch. And for the most part, it worked fine. Where I ran into trouble was with relationships between classes with multi-word names. I dug around for a little while the afternoon I found this bug, and it seemed to be some combination of the code that translated between the pluralized and singular forms of words (AR uses singularized class names, and pluralized table names), and the code that translated between camel case class names, and underscore separated class names. While it’s true that ActiveRecord is an open source project, I finally decided that if I could find a better working solution, my time would be better spent working on my own software, instead of fixing someone else’s libraries I was trying to use. Were I not trying to run a Mac software business on the side while witting Perl all day, I probably would have made a different decision, because there is definitely promise in ActiveRecord.

This is about when I started working with SQLite Persistent Objects. The pure simplicity of this library has floored me. There is no need to prepopulate a database with tables, or to even create the SQLite file at all. Just create subclasses of SQLitePersistentObject, and as long as all of it’s properties are either a base type (int, float, char, etc), another subclass of SQLitePersistentObject, or support NSCoding, that is all you have to do. The one thing that took me a bit to get used to is that unlike ActiveRecord, there doesn’t seem to be any easy way to have a “belongs to” relationship. This is because all “relationships” are handled as properties of the class, not as methods. “Has many” style relationships are typically NSArrays or NSDictionaries (or their mutable counterparts), and “has one” would just be a single sublcass of SQLitePersistentObject. Not thinking, I initially tried to setup a “belongs to” relationship by including the parent object as a property of the child, but that led to a nice infinite loop when I tried saving either the parent or the child. Obvious once I thought about it, but I had to try. Other than that one hiccup, I have been quite impressed with SQLite Persistent Objects, althouh I have not yet had the chance to do any real performance testing, as I am still waiting on my iPhone developer program application to be approved.

So, for my money, SQLite Persistent Objects is the current leader for a iPhone stand in for Core Data. ActiveRecord doesn’t seem to be there just yet, and while I’m sure OmniDataObjects is probably a great framework, I was able to get up and running with SQLite Persistent Objects much quicker.