Core Mac OS X and Unix Programming 212
| Core Mac OS X and Unix Programming | |
| author | Mark Dalrymple and Aaron Hillegass |
| pages | 541 |
| publisher | Big Nerd Ranch |
| rating | 9 |
| reviewer | Michael McCracken |
| ISBN | 0974078506 |
| summary | A developer's guide to the Unix foundations of Mac OS X, including coverage of recently added technologies. Includes complete source code and online companion material. |
If you've been learning Mac OS X Cocoa programming, you might already know Aaron Hillegass through his excellent book Cocoa Programming for Mac OS X, which was one of the first good introductory books on the topic, and is still one of the best available. Information about this earlier book can be found at bignerdranch.com/Book/. Both Aaron and Mark are instructors at the Big Nerd Ranch, which offers courses in Mac OS X programming. More information about them and the courses can be found at http://www.bignerdranch.com/Company/Who.html. This book is based on the course with the same name at the Big Nerd Ranch. The book's website and a link to order it online can be found at borkware.com/corebook/ . Discussion and further information for both books can be found at cocoadev.com/index.pl?CocoaBooks.
Audience and Writing Style
This book is not an introduction to programming on OS X. It doesn't explicitly cover how to use Apple's Project Builder or Interface Builder, or much of the Cocoa or Carbon APIs, except during discussion of code examples. So if you're entirely new to programming or to using Mac OS X, start with a different book such as Hillegass' earlier Cocoa Programming for Mac OS X to get up to speed with using the development environment. This book will leave you behind at times if you are unfamiliar with using the command line, however, the examples are complete enough to follow along by just typing in what's in the book.Core Mac OS X and Unix Programming does have some very basic material in its first few chapters. They focus on the details of C programming, using the compiler, memory management, and debugging. These chapters will be mostly review for anyone who's developed in C on Unix before, but will be invaluable for programmers who learned to program using Java, for instance. They should also be required reading for programmers who started programming with Objective-C and Cocoa and are still unsure about using "plain" C. If you've ever complained about having to use a C API from CoreFoundation in your nice pure Cocoa application, don't avoid this book -- you need to read it even more.
The book is clearly written and easily understood. The writing is occasionally conversational, in keeping with its history as a course textbook. In the grand history of well-written technical books, it is also occasionally funny. The authors don't try to sell the technologies they discuss, instead giving practical advice that's useful to a programmer who is trying to actually build something. For example, the authors discuss bugs and inconsistencies in the system, clumsy API design and other problems that aren't great ad copy but you will need to know to develop robust applications.
I found this aspect of the book one of the most appealing, that it felt as though I was actually getting down to business. Gems of practical advice that can cut short frustrating problems appear throughout the book, so be sure to read carefully, don't just skim.
Hits
Here I'll discuss a few examples of where I think this book really shines. First, the level of detail of the standard Unix APIs and the development tools is excellent -- I learned many immediately useful things in the first 13 chapters. For example, chapter 8, "Debugging With GDB," was not simply a repeat of the online help, but also contained useful tips about how to use GDB more effectively, from using Objective-C specific features to tracking subtle memory errors. Programmers who had only used Project Builder's interface to GDB will benefit greatly from this chapter.Next, there is pervasive sample code. Each chapter had a complete sample program demonstrating the topic at hand. Much of this code is also available online: see "Online Supplements" below.
Finally, as I mentioned before, the text contains tips and reminders throughout about potential mistakes, tricky problems, and differences between Mac OS X, OS 9, and other Unix flavors. A particularly useful example of this is in chapter 24, "CVS." There is a small but important paragraph that discusses using CVS 1.11 (as used in Sourceforge) with Interface Builder .nib files that can really save some grief. In other chapters, they even include workarounds for system bugs in some of the sample code. This pragmatic approach is really appealing.
Misses
In this section I'll mention a couple potential disappointments. You will have to be willing to learn by just reading code at times. Most of the code examples are not explained line-by-line as is the custom in tutorial books. Comments explain tricky code, and the text covers the areas most relevant to the chapter topic, but for other sections, understanding is up to you. I mentioned this because although I feel the code is clear and a fair trade-off was made to fit in a lot of information, the amount of explanation you like is a matter of personal preference, and so you should know what to expect.Pointers to further reading is another problem. Aside from referring to man pages, there is little attempt to point to good external documentation on any of the more complicated topics. One chapter is not enough to completely cover BSD Sockets, for example, and so a reference to a Unix network programming book would be useful. In fact, every chapter could be improved by a references section, even if it only collected links to Apple online documentation or Unix community websites. With all the practical knowledge in this book, the lack of clues on where to look to answer your own questions was disappointing.
Finally, the cost of the book, at $97.95, is higher than you might expect. I admit that as a student, I would have to think twice about paying this price, although I am sure it would be easily justifiable for professional programmers. I believe that it is worth the price, however, because you would have to buy several other books to cover the same range of topics, and you still wouldn't get the Mac OS X specific information.
Online Supplements
The authors have set up a promising resource for the book at http://borkware.com/corebook/ . The site includes the sample code, errata, reader comments indexed by the chapter and topic they refer to, and a general discussion board. There are already some errors listed, and a few pointers to useful documentation and interesting external discussions on mailing lists. The sample code is not complete at the time of this review, but more is being added. This site looks like it will be a useful addition to the book, especially if many good chapter-indexed comments are added. The site could be kept open as a reading companion while going over a chapter in the book. This site's organization is, in my opinion, much more useful and usable than other books' companion websites, including the site for "Cocoa Progamming," which hid its information from you unless you knew which page number was relevant to your topic.
Conclusion
Core Mac OS X and Unix Programming is a very useful book, and even if you've been developing on Unix systems for years, you can probably learn a few immediately useful things by reading it. I recommend it for any serious Mac OS X programmer who wants to know what to read next after all the tutorials that have come out in the last year or so. I suspect it'll become a canonical reference, and may even be in need of a clever nickname. Congratulations to Mark and Aaron on a job well done.
Michael McCracken is a grad student and Mac OS X developer; he says "I have not attended any Big Nerd Ranch courses, nor have I met either author, although I did see Aaron Hillegass in a crowd once." Update: 07/02 17:36 GMT by T : According to publisher AtlasBooks, bn.com won't actually be carrying this book, but you can get it right now from Atlas. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:Paragraph Intros (Score:5, Insightful)
Unless you have something nice to say, say nothign at all. And unless he made a flagrant error, I suggest just commenting on the book.
Re:Microsoft port (Score:3, Insightful)
Re:C'mon! (Score:2, Insightful)
Re:keychain (Score:4, Insightful)
So how did the keychain suddenly become "unixized"? It's still a part of the Carbon API.
Doeslook unixized to you?
Re:Microsoft port (Score:2, Insightful)
Re:$97.95?! (Score:1, Insightful)
They really should've considered three different books here: the main book that's already available and two other books (the main book split into two volumes). I'd actually buy a volume that's geared toward networking and threading even if I'm paying for unwanted info (I can let it slide to a degree). Instead, I'll likely skim the Rendezvous section without purchasing anything at all, which is a shame but sorry...I'm not *that* charitable.
Maybe I'm using iTunes too much, but I'm a bit tired of paying for unused extras in programming books.
man Pages (Score:3, Insightful)
Re:Microsoft port (Score:2, Insightful)
It would sell more than you think. For companies that want to move the corporate desktop over to GNU/Linux but feel that OpenOffice and the other alternatives aren't fit, it would sell like hotcakes.
Re:Microsoft port (Score:3, Insightful)
Re:Just wondering... (Score:2, Insightful)
It's expensive. Very expensive. With my current budget situation, I had to figure out what else I wasn't going to be buying before I could get it. But cheaper than going to the classes, for which I've gotten several unsolicited glowing recommendations merely for walking around WWDC with a copy of the book.
The authors are great guys, they know what they are talking about and are not stuffy at all. I hung out at their booth a while looking at the book before I bought it and later they both cheerfully signed it for me.
Re:C'mon! (Score:1, Insightful)
Yeah, but you can do the same thing in any decent GUI-based dev environ for Windows or Mac.
I think my point was not so much that you should always use the mouse, but that people who immediately assume that any one developing under a GUI is any less of a skilled programmer are assholes. This whole thread stinks of that. I've seen some pretty shitty programmers who use emacs or vi and I've seen some amazing programmers who use Visual Studio (and vice versa). The tool does not make the man, and anyone who thinks otherwise is full of shit.
Re:Microsoft port (Score:3, Insightful)
Microsoft has an effective monopoly in two areas: operating systems and office software. They are also the only two divisions within Microsoft that are profitable, and support all of their other ventures into PDAs, game consoles, set top boxes, smartphones, and on and on. Office on Linux might not sell to college kid hackers running Linux on their Alienware machines, but Office on Linux would be a powerful incentive for corporate customers to seriously consider rolling out Linux desktops in the enterprise. Therefore, Microsoft will never port Office to Linux.
Re:C'mon! (Score:3, Insightful)
IMO it is more correct to say that you cannot be a competent programmer and not be able to figure out, if needed, how to use a command-line.
I rarely have to worry about using the command-line for programming (though it is there), but when I do have to worry about it (for example -- in Visual C++ 6.0, some compiler and linker options weren't available directly from the UI, one would have to specify them as command-line options to the compiler/linker), I could. Knowing how to use command-lines also allows you to set up nice pre/post build scripts in Visual Studio that can really simplify things (copying DLLs to a shared location after being built, or whatever).
Though I'm generally against the silly minimalist approach many UNIX zealots take with regards to computer use and programming (for example, those who think anyone who uses an IDE is inferior, or whatever), given the choice I'd always prefer to work with programmers who are at least somewhat comfortable using command-lines. Anyone who has no clue in that area has probably not built a serious application. Even on the classic Mac, someone who has created a large application has probably done some scripting in MPW which is a form of command-line.
Re:C'mon! (Score:1, Insightful)
Re:C'mon! (Score:3, Insightful)
Then what do you call those things that ran on Mac OS X and the people who wrote them, if they weren't "programs" and "programmers" respectively? Took me 16 years of shipping commercial software products before I had to use a command line at all, personally.