Mac Developer Journal, Take 2
When I first looked at Mac Developer Journal, I liked the content but not the clunky Zinio reader (which commandeers a top-level spot in my home folder) or restrictive file format. The second issue fixes the most glaring problem: that the layout was designed for printing but could only be printed one page at a time. The first thing I did after downloading the sample of the second issue was to print it to a PDF file. This worked without a hitch, although some of the interactive content printed as solid black boxes. I could now read the issue in Preview.
Alas, all was not well with the PDF file. Not surprisingly for a Quartz-generated PDF, it had no clickable internal links or URLs, and no bookmarks. What is surprising, though, is that the text was not selectable or searchable.
I like to read magazines on paper, but I was unable to print the complete sample issue at high quality. Whether this was because of software problems or my PostScript-emulating GCC printer, I don’t know. When I printed from Zinio Reader, nothing printed after logical page 52 (the first page of the REALbasic article). Author names printed as black boxes. The same thing happened when I tried to print the PDF from Preview, even if I asked it to start printing on page 52. I was finally able to print the issue by asking Acrobat Reader to print the PDF as an image, but that took a long time and reduced the quality. The text wasn’t as sharp, and the code examples no longer had shaded backgrounds.
Page 28 (the last page of the Search Kit article) printed with the body text in a sans-serif font, unlike the rest of the article. This article, by the way, was the one in the sample issue that most interested me. Unfortunately, it ended up being high-level and didn’t seem to provide any information that’s not found in Apple’s own PDF documentation for Search Kit. It also commits the typographical sin of using ligatures in code examples.
On the plus side, some of the articles that aren’t in the sample issue look interesting (the Rich Siegel interview and the two After Hours articles). And the Web site has a video interview with Brent Simmons, in which he has some very nice things to say about SpamSieve (as well as Bare Bones, Omni, and SubEthaEdit).
Overall, I like the content of Mac Developer Journal, but it doesn’t really have the focus that I want. There are marketing-type articles and interviews, which I would read but that aren’t really enough to get me to buy the magazine. There are introductory technical articles. And there are more general-interest “how to” articles that wouldn’t be out of place in Macworld. The writing is definitely a notch better than MacTech. What there are not, it appears, are the develop-style technical articles that should be the core of a Macintosh developer magazine.
For a look at how good a developer magazine can be, consider the platform-agnostic Dr. Dobb’s Journal. It manages to be both broad and deep—see, for example, the tables of contents from the March and April issues—and features columns from Verity Stob and Mike Swaine. I realize that the prices are not directly comparable due to the Mac market’s small size, but at $50/year Mac Developer Journal seems very expensive compared to DDJ ($35/year). The issues are smaller, they’re quarterly rather than monthly, and they’re delivered in Zinio format instead of on paper.
6 Comments RSS · Twitter
I pretty much agree with what you wrote. The main thing that keeps me from getting the second Mac Developer Journal is the fact that it's in Zinio format. The other thing is that the articles, while interesting, lack some depth and can't justify the price.
Michael,
I'd be curious to know what in my article could have made it better for you. I was, in fact, trying to give an intro to the ideas so that the PDF would be easier to digest - and make folks more aware the technology was there and need not be intimidating.
As for the ligatures - sorry, that was way, way out of my control as the author.
-joe (http://rhonabwy.com/mt/)
Hi Joe,
Your concluding paragraph makes it clear that the article was intended to be an introduction, and I think it was a good one. (My only technical complaints are minor: that after extolling the benefits of toll-free bridging you create searchArray the long way, that you imply that "not" queries are supported in Panther, and that analysisDict seems to be leaked.) However, I would have preferred an article that wasn't an introduction. I was already sold on the fact that Search Kit is interesting, and I wasn't intimidated by it. I would have liked to see answers to questions like:
How can I push the Search Kit to the limit, using the current API?
What are the important but non-obvious limitations of Search Kit in Panther?
What's known about extractor plug-ins and Apple's future plans for them?
Under what circumstances would I be better served using an engine like Lucene? What extra flexibility does it offer? How do the speeds compare?
Are there other search engines that I should consider?
I very much agree. It is a very nice article, but more indepth knowledge would be fine. Maybe you should write a second part?
[...] read and enjoyed Dr. Dobb’s from the mid-nineties until a few years ago, when it had become thinner and more [...]
