I’ve been using FMDB on a couple projects, and found a bug and made a couple improvements. I submitted the changes to Gus and he included them in the project.

Here’s the proof: http://code.google.com/p/flycode/source/diff?r=30&format=side&path=/trunk/fmdb/CHANGES_AND_TODO_LIST.txt

Actually, it was only about 4 lines of code, so I shouldn’t play it up too much, but I’m extremely proud of myself.

An interesting snippet:

“Q: Carbon isn’t just the UI stuff if I understand things correctly. Maybe I’m confused. Exactly what does Carbon encompass?”

That’s a darn good question (and practically the first question we asked when we were informed of this change in plans).

You would think that what functions make up an API would be pretty cut and dry, but things are rarely that simple. Plus it looks like some of the libraries that people think of a Carbon will actually be available in 64-bit.

(Via Daring Fireball Linked List.)

I really don’t know close to enough to understand the implications of this, but it sounds pretty serious, at least if you want to build 64-bit applications. From the Infinite Loop article:

Although we can still look forward to 64-bit Cocoa applications in Leopard, this development means that third-party developers, especially those with cross-platform products, will be less inclined to support 64-bit computing in their applications. Doing so would require removing all references to Carbon. People in the know tell us that this is is extremely hard—if not impossible—to do: in practice, applications that mostly use Cocoa also call on Carbon for things that can’t be done (easily) with Cocoa.

And for the geekier in the group, here’s a listing of all the files in the Safari directory. DLL hell anyone? Notice there’s a CoreFoundation, CoreGraphics and CFNetwork DLL.

Look at the dialog labeled “General” in this blog post. This is the preferences dialog in Safari for Windows. There are very few clues that it’s a dialog for a Windows application. Really, the only clue is the ‘x’ close button in the upper right corner. Compare this to the other picture which is the preferences dialog for iTunes for Windows. It looks like a standard Windows dialog.

It sure looks like the Safari dialog was built using Interface Builder. The drop downs are Mac drop downs, not Windows.This seems rather unlikely, except that I now know (thanks to Amit Singh) that Interface Builder used to run on Windows, as did OpenStep. Could Apple be reviving this long-dormant functionality?

If I get time, I may try and explore Safari for Windows further and see what I can dig up. I suspect someone with more time and experience will discover any secrets long before I do.

Another (not exclusive) possibility is that Apple hopes that Safari becomes yet another “gateway drug” to get Windows users to switch to the Mac. Making the UI as Mac-like as possible does a few things:

• First, it helps acclimate Windows users to Mac UI conventions.
• Second, it lets Windows users know how much cooler looking Mac apps are.
• Finally, it let’s Windows users know that using software on a Mac isn’t that hard.

I actually have friends who are convinced that they are so acclimated to Windows, they wouldn’t ever be able to be productive on a Mac. To some extent I used to believe this about myself. Not that I couldn’t learn it, but that the learning curve was steep. Of course these days I also have friends who, like me, I wondering why they waited so long to make the switch.

http://trac.macosforge.org/projects/BridgeSupport

New open source project from Apple to provide a language-agnostic foundation for scripting language bridges to Cocoa; already used in PyObjC and RubyCocoa.

http://chopine.be/lrz/diary/2007-05-22_RubyCocoa-0-11-0-is-finally-out.html

Laurent Sansonetti:

After 5 intensive months of development, RubyCocoa 0.11.0 is out. It’s a very big release, as you can see from the release notes. We also feature a completely new website (which is actually a Wiki, easy to maintain for us programmers).

I know you can also write Cocoa apps using Java, but I’ve read that it’s probably a bad idea. I may comment further on this later.

First, I wanted to take into account the fact that I’m a Mac newbie. (I’ll have to tell the story of my switching in another post.) I’m also a Unix newbie. I’ve dabbled with a couple Linux distros, and at one point had managed to turn an old machine into a FreeBSD-based firewall, but I don’t really know any of the Unix tools beyond man and ls -af. A note to other Mac newbies: I cannot recommend David Pogue’s Mac OS X: The Missing Manual highly enough. I still go back to it for keyboard shortcuts or to answer “How do I?” questions.

(Somewhat off topic: One of my primary motivations for purchasing a Mac was to become more comfortable and productive in front of a Bash prompt. I still don’t spend nearly as much time in Terminal as I’d like. I need to find a good Unix for Mac and Unix newbies book.)

Second, I learned pretty quickly that modern Mac programming is done using Objective-C and Cocoa. For a long time I couldn’t remember if Cocoa was the new API and Carbon the old one or if it was the other way around. So I need to learn a new language in addition to an API.

Third, (and I really only recently realized this once I started doing some coding), I need to learn Xcode. From what I can tell, Interface Builder is really the only way to create a Mac GUI for your application. I guess Interface Builder is technically a separate program, but the two seem to go hand in hand.

Okay, enough preface, what did I consider and how did I choose.

Well, as with most things these days, I started with Google. A search for [this page. It was a enough to give me something to work on until I could find something more substantial. I’ll convey my thoughts on the article in another post. Executive summary: It’s a good introduction to Cocoa, Xcode, Interface Builder, and Objective-C, but it’s very, very brief.

My next stop was Amazon. A book search for [Objective C] and then sorting by rating and bestselling helped narrow the search. Note that if you do this, you’ll have to wade through lots on non-Objective-C books that float to the top of the list. Programming in Objective-C by Stephen Kochan emerged as an early favorite. It’s highly rated, a best seller (among Objective-C books at any rate), and the reviews are largely positive. I came really, really close to buying this book.

However, being who I am (see the first paragraph of this post), I decided to do more research. I searched Amazon for [Learning Objective-C], [Cocoa] (that was a bust), [Cocoa programming], [Mac Cocoa Objective-C], [Learning Cocoa Objective-C], [Xcode Objective-C], and a ton of other terms. I also did tons of sorting and resorting and followed what seems like a million “customers also bought” and “customers ultimately bought” links. This brought out a few shortcomings of the Kochan book. First, it doesn’t talk about Cocoa at all. Not a lick. Second, a lot of the reviews had comments like, “This book is great if you’re new to object oriented coding!” Finally, like Cocoa, there was no Xcode. Everything was done via command line tools.

This led me away from my initial choice. First, I know OO coding pretty well. As it says on the about page, I’ve been doing OO coding for a while. Even when I was doing VBScript coding, I was creating classes for encapsulation. In JavaScript, I was creating prototypes for the same reason. I’m not trying to boast here (okay, maybe a little), but I want to convey that I pretty much think in OO these days and I already know the principles like encapsulation, inheritance, and polymorphism. In terms of learning Objective-C, I really just needed a reference or “Rosetta Stone” to translate Objective-C syntax into the Java or C# equivalent and vice-versa.

Second, show me the Cocoa! Learning a new API is much harder than learning a language, at least for me. Most languages, especially C-based languages, are pretty concise and and have a small number of keywords. “Narrow but deep” is a good way to describe a good language. There are a small number of keywords, but lots of power. APIs, especially concerning operating systems, are broad and deep. There’s a ton of power, but there are many, many namespaces, classes, and methods. I don’t know how many times in C# I’ve used lines and lines of code to implement something only to later learn there was a framework call that would do it in a single line of code.

Finally, I knew from the Apple tutorial that I’d need some Xcode advice. I tried poking around the IDE on my own a few times (I used it to code some Java design pattern samples) and couldn’t really get the hang of it on my own. I have a fondness for command line tools and simple editors like emacs, but I know the power of really knowing your IDE from my experience with Visual Studio releases over the years.

So now I new I needed a book that included Objective-C, Cocoa, and Xcode. More searching, sorting, and following links led to Cocoa Programming for Mac OS X by Aaron Hillegass. The ability to read through the preface on Amazon (albeit of an earlier edition) and a review on Slashdot were the final selling points.

I’ll post my thought on each chapter as I go through them, but so far I like it. I have some issues that you’ll hear (err… read) about later, but I can easily recommend it to folks who want to learn to write Mac programs. It’s got a nice introduction to Objective-C and Xcode (and Interface Builder), and covers some important pieces of the Cocoa API.

^*This drives my wife crazy, and who can blame her.

I apologize in advance for future misspellings and any confusion they cause.