Musings of a Programmer

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.

Not too long ago, I saw it mentioned in a blog post somewhere that the iPhone doesn’t support Core Data. That kind of makes sense, I’d imagine that Core Data is a little heavy, what with all that “magic” it gives you. Unfortunately, it forced me to start looking for alternative data store Frameworks, since I have more than one idea that I’d like to eventually put out for the iPhone/iPod Touch. While I haven’t looked too deeply at any of them (I’m still only about one third of the way through the Hillegas book, August has been busy), I’m looking right now at two fairly different front ends to SQLite. There are several others out there that I’ve seen, and probably dozens more that I haven’t. These two just seem to be the most actively developed and used.

The first one I found was Gus Muellers’s FMDB. It’s apparently used in both the Mac and iPhone versions of NetNewsWire, and I’d imagine at least a few of FlyingMeat’s applications. That means that it’s been out there for a while, and that it’s been used heavily. Which to me says, that if it’s used properly, it should be fairly fast and stable. I’ve dug around in the examples, and a little bit in the code for the Framework, and for the most part like what I see. It’s a pretty low level Objective-C wrapper around the SQLite C libraries. Which means that the trade off for the speed and stability is that you get to write a lot of SQL statements that will give you back Objective-C objects. This is a little bit of a pain, but I’ve worked with SQL before, and I’m fairly comfortable with it.

The other project I found was ActiveRecord for Objective-C. As the name would imply, it’s an Objective-C version of the ActiveRecord that is used by Ruby on Rails. Right there, I was interested, since I spent the better part of a year playing with Rails. My only concern is performance. Search the web for ActiveRecord, or Rails in general, and there are lots of complaints (valid or not) about performance. Now, I haven’t actually written anything using this new Framework, but I have dug around in the code for it some. The Objective-C Framework seems to use a lot of Cocoa’s Key-Value coding and some hard-coded methods, where-as the Ruby version uses mostly Ruby’s meta-programming magic. And from everything I’ve seen and read, the meta-programming magic is what tends to slow down Ruby’s ActiveRecord. This may or may not be the case anymore, as I haven’t been involved in Rails programming for around a year (think Rails 1.2).

So, I think I’ll play around with ActiveRecord first, and as long as the performance level is there, I’ll probably use that, if only because I’d rather not have to muck around at the SQL level unless I have to.

While I’ve only seriously been working on learning the Cocoa frameworks for a month or two now, I’ve been poking at it since I first got back into Macs about three and a half years ago. So while I may not be intimately familiar with the Cocoa frameworks, I’ve had a fairly good grasp of Objective C syntax for a while now. Which means that even though I’m a newbie, I do have an apprecieation of some of the new features of Objective C 2.0.  So here are some quick thoughts, in no particular order.

Properties

I love them. I may have gotten started on BASIC way back when I was in elementry school, and finally gotten serious about programming with C early on in college, but I spent way too much time with Java for school work after that. And one of the things that Java taught me to hate was writing all those getters and setters. I always thought it was insane that I had to spend dozens of lines of code per class just setting up data access methods. Then I got into Ruby about two years ago, and it had these wonderful attr_accessor, attr_reader, and attr_writer shortcuts that did all that mundane work for you. All of a sudden, dozens of lines of code turned into one line for most instance variables. After that, I started wishing that every language I worked with had that kind of feature. Sure it wasn’t huge, but it was a nice thing to have. Then, I managed to get myself into one of the Leopard Tech Talks up near Boston, back in Januaray 2007, the single event that I credit with really putting me on the track I’m on now. And what was one of the big new things they were talking about? Objective C 2.0. And what was one of those great new features? Damn right. Properties. They may not be a game changing feature, but they make my life as a developer just that much eaiser. Which leads me into

Fast Enumeration

I had planned on writing a lot here to, but then I realized that fast enumeration was just another one of my good friends from dynamic languages like Ruby and PERL, that while I could live without them, were very nice to have.

Dot Syntax

This, for me, is a very “so what” addition to Objective C. I suppose it may be handy for the C++ and Java coders out there who may be intimated by all the brackets everywhere. But for me, I find it just as easy, and more consistent to write [someObject stringValue] than to write someObject.stringValue.

Garbage Collection

The jury is still out for me on garbage collection. While memory management may be a pain, I’ve had it hammered into me since I was a freshman in college. And really, from what little I’ve played with it, I found the reference counting model of Objective C to be one of the easiest memory management methods I’ve used. On the other hand, no having to worry at all about memory management at all was one of the things I really liked about Java, which was the first garbage collected language I really got into.

I am quickly learning that blogs and podcasts can be a developer’s best friend. Especially when your development platform of choice has the great community around it that the Mac development community has. I’m only a few chapters into the Hillegass book, but I’ve been following a bunch of developer blogs, and a few podcasts. As a result, I’m more excited about coding than I’ve been in a long time. Not to mention some of the great tools I’ve discovered. Everything from tips on using the Apple supplied debugging tools, to third party applications like Git.

The other thing that podcasts are great for, is just hearing how other people do things. Hearing how different people combine different tools. Sometimes with very different results. The other thing that developer centric blogs and podcasts are good for is hearing about the various problems and road blocks that you may eventually run into yourself.

Now, I’m not typically a fan of “link blogs”, but I feel that this one time, it’s necessary:

Some of my favorite Cocoa/Mac development specific blogs:
Cocoa Blogs - Articles
Cocoa Is My Girlfriend
Cocoa Nut
Cocoa Samurai
dannygreg.com
Fraser Speirs
Gus’s blog, adventures in Flying Meat.
inessential.com
Michael Tsai’s Weblog
Mike Lee
Red Sweater Blog
stuffonfire.com
Theobroma Cacao

I also listen to “Late Night Cocoa”, “Mac Developer Roundtable”, and “MacSB” over at The Mac Developer Network. Scotty puts on one hell of a podcast. In addition to those, I’ve recently started listening to Core Intuition with Daniel Jalkut and Manton Reece, and I highly recommend it.

Lastly, I would recommend expanding your circle of what you read and listen to beyond blogs and podcasts specific to your niche. On top of giving you the chance to see how other development platforms work, you may even pick up a few new tricks you wouldn’t normally have.

I’ve moved this blog to a new domain name. The old domain will redirect here until July 28, when it expires. The RSS feed for articles should not need to be changed, as I am running that through feed burner.

Here are some more things I’ve noticed after a few more weeks with Git:

Many of the articles I’ve seen comparing the various different distributed versioning systems tend to complain that Git is overly complex. And while that may be, I don’t think it’s to the point where you can’t just pick it up and start using it. Back in May, when I first started using Git on a regular basis, I had only ever used Subversion, and I was productively using Git within an hour or two. Granted, I wasn’t using anywhere near all of the features, but at least I was back to where I had been with Subversion. On top of that, every now and then, I’ll pick up a new feature of Git, that either Subversion didn’t have, or I didn’t know about. Who knows, maybe this air of complexity is left over from the days of Cogito.

One of these new tricks I’ve picked up was stash. Git’s stash option gives you a way to put aside changes that you are working on, without committing or rolling back. This comes in handy when something you’re working on isn’t ready to be committed yet, but you need to make a quick change in something else. An example would be if you are working on a new feature, and all of the sudden realize that a small bug needs to be fixed in your test environment. Just ‘git stash’ to save your changes, and roll back your working environment to your current HEAD. Then fix the bug, commit the fixes and roll them out to test. After that, you just ‘git stash apply’ to re-apply your saved changes. And while I haven’t played with it much, another nice feature of stash is that git will save multiple stashes, and allows you to add comments to them so that you can more easily keep track of which is which.