Nobody learns if nothing is brok3n

So who is Jamie Hardt anyhow?

I'm a sound designer and sound editor based in Los Angeles, California -- you can see my credits either on my website, soundepartment.com, or by searching for me in the IMDb.

I write software mainly just to scratch a particular itch I might have at a particular time. I wrote a cuesheet formatter called "Agent Orange" -- so named for its ability to kill tress -- a kind of program that turns CSV data into a sort of Gantt chart for audio playlists, because there were no good products on the market and I wanted to make sure any future products met a certain minimum standard of quality. It's also implemented in Ruby, and is distributed with a little Cocoa GUI to help people use it.

I'm completely self-taught as a developer; I never took any programming classes in school, and I only really got my start when I installed the Developer Tools CD from Mac OS X 10.3. My continuing education comes from K&R (the ANSI C version), developer.apple.com, cocoadev.com, and the Pickaxe Book. I had always done little projects in Filemaker, but as I was asked to build more and more complex databases, and I found myself using more and more complex processes in my work, I was frustrated with its limitations and started looking for something else.

How have you found that your workflow has changed since moving away from FileMaker?

Not really, it just makes the things I do easier; I don't have to tech support Filemaker databases anymore! I like being able to solve a problem for someone and doing it FINALLY, without having to come back and fix things for them, and leaving them happy, and Filemaker was kinda failing at that.

Filemaker is fine for applications you're doing yourself, but applications you do for another people is a different matter.

Are there any things that you miss from developing with FileMaker that you do not get with Ruby or Cocoa?

The speed of turning a simple project around, I guess, but I hesitate to call making a Filemaker database "developing."

What made you want to start working on calllog2ical?

I came to my iPhone from a Treo 650, and while my Treo was really beginning to wear on my patience, I really liked being able to download my call log from it at the end of the year, for tax purposes. There was a nice little shareware app on the Mac that would extract your Treo's call log and spit it out as CSV.

Apple, being who the are, made a very good phone but forgot to give us a way to extract a phone log. I'm a freelancer and do a lot of contract work, and I like to keep track of who I talk to on my phone and when so I can, as stated, properly document my cell phone as a business expense.

So I wrote the script to accomplish this task with the iPhone (I haven't written the iCal-to-spreadsheet script yet, but I don't think it'll take more than an hour or two). I was originally going to write a program that exports the call log to a text file, but there's a problem. When you clear the call log in Phone.app, the calls disappear from the database, and your iPhone will regularly expire old calls off the end of your call log. Thus, reading the call log at any one moment will not give you the call log for a long period (like a year).

What you need to do is have a program that you run regularly to extract phone calls from the backup and move into a database of some sort, that intelligently inserts only new events and won't drop events if they don't happen to appear in the call log today. The iCal Calendar Store just happened to be in the right place at the right time for me; I could've made up a little sqlite database to store the calls in, but the iCal database is suited specifically for this kind of time-dependent data, and the kind of presentation you get, on a calendar and in your agenda, is pretty appealing.

It's major weakness is that you have to run it regularly to move the calls across to iCal, and you might lose calls if you don't run the script as often as you clear your call log. You could go a long ways to fixing this by (for instance) detecting when an iTunes sync occurs, which I'm sure is possible by observing the iPhone backup files, though I haven't investigated this in depth. Another way to fix this is to write a script that runs on your *phone itself*, and backs up old calls every day before they get sweeped, but I personally am avoiding hacking my iPhone until Apple supports it.

Do you typically find that Apple leaves some things out that you need like with calllog2ical (or things like Perian or Growl)?

I think they accomplish everything they set out to do.

Is there anything you'd change about the iPhone (besides call logging), if you were given the chance?

Mostly calendar stuff, like showing which calendar an event is from and OTA subscribing to calendars (er syncing). Laptop tethering for the EDGE service would be nice too.

It's really an excellent phone for someone like me, that does most of his work on contract or freelance, and is responsible for keeping his own agenda and contacts. I think Phone.app and MobileSafari.app are the best programs of their kind on any phone.

Why Ruby over another language, such as Python?

In my process of getting frustrated with Filemaker, I went looking on the internet and found Ruby on Rails (it must have been at version 0.5 at the time or something like that). I was really inspired by some of the cool features in the Ruby language, went out and bought the Pickaxe Book to get a better handle on it. After dealing with Objective-C, I appreciated that Ruby has a very similar underlying mentality, and since I taught myself programming in ObjC I just found it more amenable to the way I like to work. Ruby gave me my first experience with things like lambdas and continuations and anonymous functions, and it has a way of doing these in a way that made me actually understand them for the first time.

I've played with Python as well, but I got the impression it's object-oriented features are kindof a bolt-on, and I have a serious psychological issue with syntactic whitespace (particularly tabs).

Did you need to go out and buy a book based on the fact that the documentation was lacking, or was there another reason?

Documentation of what? Ruby? I just like buying books, you can read the Pickaxe book on the web after all, I just liked having something on paper I could browse at leisure. I think documentation of the Ruby language itself is quite sufficient.

The Rails documentation has always been a little on the sketchy side, but this is a symptom of the fact that it's always getting new stuff put in it and the people who are on the edge of its development seem to get bored with doing things one way for too long :) The API docs are OK, but when you're trying to do something specific, Rails has this problem in that there may be five ways to do some things, and the Rails devs have been in love with each of them at one time or another and have done a blog entry about how their agile practice du jour is wicked cool. It can be difficult to find information on a particular rails mechanism without also getting advocacy for it.

Another related thing: When it comes to answering "How to do X?" type questions in Rails, you generally go thru the wiki or blog entries and see what other people did, and Rails makes awesome example code (I dare say one of its design objectives is to make code that reads well). Of course, on a language level, they get this kind of readability by hideously overloading and aliasing methods and functions, so a lot of the foundation Rails methods, like, say, ActiveRecord::Base::find(), just takes an anonymous hash for an argument, and this hash can contain string keys to values, symbol keys to values, or no hash at all, maybe a string, maybe an array of strings, maybe it need not be an array, merely an object that mixes in Enumerable. The method may take a proc as an argument, or it may yield values to a block (and the arity of the block might be 1 or 2 or none or any combination of those).

That ends my rant, but despite this, I really like the idea behind Rails, and it taught me a lot about programming, and maybe what not to do too ;)

Do you feel the documentation out there is now up to par?

see ibid.

How do you feel about things like RubyGems?

Without it using OSS libraries in Ruby would be inconvenient to say the least; it's a great way to distribute OSS libraries of code. I wouldn't use half the open-source software I do without tools like RubyGems and darwinports. My only gripe is that often my end users don't have them, so *I* have to resolve their dependencies for them.

Why did you choose to go with the GPL?

I was putting it up and the GPL v2 was the first one that came to mind? I honestly don't pay TOO much attention to these debates, but I tend to lean towards the GPL for anything that isn't published for strictly educational purposes.

I like the idea that the code is out in the open, and I wouldn't want someone to sell some kind of "Pro" version for 29.95 when all they did was slap a dialogue box on it. I also think the GPL strongly favors end-users by giving them the right to examine and extend the software they have.

Honestly it was really more of a whim than anything, I could just as well have made it BSD, and since Ruby is an interpreted-only language (for now), it's not really practical for people to add to the script without the changes being visible to all.

Why is calllog2ical important?

I suppose, aside from the fact that I can now do my taxes again, it shows how quickly you can write a little "mashup"-style script using the Cocoa Scripting bridge and your language of choice.

I also suppose, if you didn't value your privacy at all, you could publish your iCal to your website or whatever, and get some kind of twitter-style life-stream. That's not my thing, but some people might like it. Then there's variations on this, like employers keeping tabs on employees, etc.

What are your thoughts on the scripting bridges new to 10.5? (if you haven't messed with them, we can skip this one)

calllog2ical wouldn't have been coded in an hour without the scripting bridge; it's excellent for prototyping an application. For commercial software developers I don't think it's all that important, but for people who want to do a little hack every now and then it's excellent.

I'm curious what Apple's real "Development Roadmap" is for the scripting bridge. Will a RubyCocoa application I build today run in 10.6 without modification? Exactly how serious do they take the Scripting Bridge as a "platform" for development, particularly given that it's really not acceptable for commercial software?

Pies or Cakes?

French silk pie, please.