Hi!
Pittsburgh Cocoaheads tonight will feature Sean McCune talking about Git, the groovy distributed revision control system thingie.
7:30 on the CMU campus.
Cheers,
++md
Hi!
Pittsburgh Cocoaheads tonight will feature Sean McCune talking about Git, the groovy distributed revision control system thingie.
7:30 on the CMU campus.
Cheers,
++md
James Summers has posted a very thoughtful review of Learn Objective-C on the Mac.
Next CoocaHeads/Pittsburgh is Thursday July 3, 2008, 7:30 at Newell Simon Hall 3001 on the CMU campus. No set agenda, but we’ll have the usual snacks and geeky discourse.
P.S. I’m on twitter as “borkware”, still working on revisions to AMOSXP, plus doing some work on LoC.
In case folks might have missed it : Launchd: One Program to Rule Them All Tech Talk @ Google, with Dave Zarzycki, the launchd dude.
Hello Everyone,
Two friends of mine who are excellent musicians (Trumpet and Trombone) are moving to Philly this summer, and they’re looking for good community music groups (band and/or orchestra). They don’t know anyone in Philly. *I* don’t know anyone in Philly would know what groups are good in the region. If anyone has suggestions, leave a comment or drop me a line at markd@borkware.com. Thanks!

Hello everyone,
The next Pittsburgh CocoaHeads will be April 24, 7:30 pm at Newell Simon Hall, room 3000. Unless someone wants to talk about something else, I’ll babble incoherently about Unit Testing and Code Coverage, plus a peek at the Google Mac Playground and CoverStory.
We’ve got a google group / mailing list at http://groups.google.com/group/cocoaheads-pittsburgh. Please join if you’re in the area.
The Time Capsule I ordered a while ago has arrived. Woot! Remote Backup Nirvana is coming my way!
So far, it’s been working out “eh”. It took a couple of tries to get it onto my WDS network, and I’ve gone through a number of scram-the-backups-and-redo-from-scratch getting things set up. Here are a couple of first impressions.
stated on every backup. I’d need to backup a few megs, which would take two minutes, and then it would sit at “Backed up 10Megs of 10Megs” for 5-10 minutes, all of which was looking at mail messages. It turns out I had a lot (over 65,000) of “deleted” messages that weren’t in the trash, weren’t in any mailbox, but showed up if you command-L while viewing the inbox. Control-clicking on the mailbox and choosing “Erase deleted messages” did nothing. I had to select each Inbox (I have 3) and choose “Erase Deleted Messages in Selected Mailbox” from the menu (or use command-K) Once I did this, a backup (including an email check) is about two minutes from “Backup now” til it completes.

And mdutil -i off /Volumes/blah doesn’t turn it off either. Even a reboot didn’t help. Sigh.
Hopefully once some of these annoyances are worked out I think Time Capsule will work out a lot better in backing up my, and the wife’s, MacBooks. Before this we had an “rsync to a DL-DVD-sized dmg on a Mac mini” setup, and hoped it didn’t fill up the disk image, plus waiting for a DL disk to burn, and hope it didn’t fail part-way through with media errors.
Just in case you’re reading Learn Objective-C on the Macintosh, and you’re wanting to make a “Foundation Command-Line Utility” project in the might (or might not) be new Xcode which might (or might not) be associated with the latest iPhone excitement, you’ll probably want to look under “Command Line Utility” on the sidebar, and choose “Foundation Tool” from the project picker. They may (or may not) have moved it from previous Xcode versions. Or not. You didn’t hear it from me,
I usually don’t like to Pimp my own Warez, but Sir Daniel Punkass pointed out to me that Learn Objective-C on the Macintosh is quite applicable to iPhone development, especially for folks who don’t already know Objective-C. Sometimes I’m a bit clueless.
LoC is an introductory book, but assumes you know C (it’s officially the follow-on to Learn C On the Macintosh). It covers a lot of the basic stuff you need in Cloud-Cocoa Land - especially memory management, which we go over a lot in the latter half of the book, since memory management is the place that many Cocoa programmers have problems.
We tried to make it as non-boring as possible, so I think even experienced programmers can get something out of it. From a twitter in response to Mr. Punkass, Diego wrote “started on the book and it’s very good. straight to the point and doesn’t linger on topics. which i like. thanks for the tip” (Thanks Diego!)
On the down-side, it doesn’t cover the properties syntax, or the new fast enumeration syntax, but once you have the basics of the language under your belt, you should be able to pick those up quickly.
Want to learn more about OpenGL ES? http://www.khronos.org/opengles/ has some information. The OpenGL ES 1.1 specs would probably be of the most interest.
At the last CocoaHeads/Pittsburgh meeting, we chatted about setting up a mailing list, and maybe using a Google Group. I’ve gone ahead and set one up:
http://groups.google.com/group/cocoaheads-pittsburgh.
Wheeeee!
Apple’s released some new/updated documents. The Threading Programming Guide looks particularly interesting, especially if my LNC episode inspired you to not run away screaming.

Wonder if a signed integer value and a sanity check for <= 0 would have caught this case? (Mail.app on Leopard. BTW. Anyone know how to get Mail.app on Leopard to delete messages without moving them to the trash? command-delete moves to the trash, and doing a “Cut” takes a freakishly long amount of time.) Radar 5353034.
For folks in the Western PA area, the next CocoaHeads/Pittsburgh will be thursday, February 7. I’ll be talking about NSOperation.
I had the pleasure of recording another Late Night Cocoa podcast over at the Mac Developer Network. This time I blabbled about concurrent programming, including some chatting about NSOperation.
If you know something about Cocoa programming, I’d like to encourage you to do a LNC podcast. Scotty is a pleasure to work with.
I’ve been using Pages for writing new AMOSXP chapters, and for the most part, it’s a pleasant experience. I’ve just about got the NSOperation chapter put to bed, and was making a PDF to send off to the first round of reviewers, when I noticed the generated PDF output was beyond horrible. Here’s what it looked like on-screen:

and here’s what the resulting PDF looked like:

Hideous, isn’t it?
Turns out that Pages is honoring the “Turn off text smoothing for font sizes x and smaller” when generating the PDF, and using bitmaps for the smaller font sizes. I have that set to “12 and smaller” because anti-aliasing plus my eye correction conspire to make things difficult to read. Why Pages is using this setting for PDFs is beyond my comprehension (and I hope it’s just a bug - VoodooPad does the RightThing. Filed Radar 5698417). You’d think that PDFs are being made for someone else’s consumption, and so wouldn’t carry along personal preferences like this.
My cow-orker, Mike Morton, gave me a little bit of advice over a year ago that’s proven to be incredibly useful: “In your -dealloc, release objects in the same order they’re listed in the @interface“. This makes it really easy to double-check your work and make sure you’re releasing everything you need to. It also makes maintenance easier: skim down your -dealloc and compare to your @interface before you land your code.
It’s Macworld 2008 time. I had Google Booth Bunny duty on tuesday. When I wasn’t working the booth, I wandered around the show floor with a camera, with the obligatory web gallery.
My friend and cow-orker Greg Miller has a piece published at MacTech: Exploring Leopard With DTrace.
DTrace is cool. DTrace is awesome. Go read this.
Apple provides downloads for OS X version for developers with seed keys. That’s cool.
Apple’s webservers cut off long downloads after twelve hours. When it takes twelve hours and fourteen minutes to download something, that’s not cool. I don’t want to think how many multigigabytes I downloaded before figuring out that twelve-hour cutoff.
Jonathan Wight said on IRC one day, “dude, use Speed Download“. I did. It works. I watched the progress meter at 12 hours. download speed went to zero as expected. A couple of seconds later it cranked back up Fourteen minutes later I had a finished download. That’s cool.
One thing that made me happy, and was greeted with applause at WWDC, was the news that ZeroLink is gone in Leopard. The linker is now fast enough to make ZeroLink unnecessary.
So what was so bad about ZeroLink? The first problem wasn’t actually ZeroLink’s fault - it was Apple making ZeroLink on by default for new Xcode projects. A common refrain heard from new Mac programmers was “I made a Cool Little Cocoa App, sent it to a friend it won’t work for him. What’s wrong?” ZeroLink.
ZeroLink performed its magic by demand-loading object files, and those object files weren’t included in the application bundle until several Xcode revisions later. So sending an App to a friend (or a reviewer, or a cow-orker) would mean sending them a broken app. Then the programmer would ask for help on a mailing list or IRC, get told to turn of ZeroLink, and then rebuild and re-send. In fact, the Feenode #macdev FAQ has a special section just for ZeroLink.
This was embarrassing and demoralizing, especially for someone new to the platform. New, small projects didn’t benefit from ZeroLink anyway, and you have to have a pretty large program before the time savings is noticeable. Someone with a project that big will have someone intimate with Xcode who would know about ZeroLink, so need to have it on by default.
The second problem was that ZeroLink introduced instability, with its frequent refrain being “I’m getting weird crashes”, which are fixed after turning off zero link. I got paid for a full day’s consulting tracking down a strange C++ operator new overload. The daily smoke test built and ran great, but development versions crashed and burned in weird places. We finally tracked the main difference between the developer builds and the automated builds: ZeroLink. Turned it off, rebuilt, and life was happy ever after. This particular app (which was freaking huge) was broken down into lots of frameworks, so link time wasn’t that much longer than with ZeroLink. (Because of this framework breakdown, I was able to pull some command-line tricks to prevent unnecessary recompilation of other parts of the system, and greatly reduced my turnaround time on a TiBook500 vs the G5-weilding full-timers, but that’s a story for another day.)
Good bye ZeroLink.
Chris Hanson and Scott Stevenson are organizing NSCoder Night in the Silicon Valley, a weekly event where Cocoa geeks can hang out for coding and mayhem at a coffee shop or a pub. It sounds like it’ll be a huge amount of fun.
For folks in the Pittsburgh area, Jeff Hunter is organizing DevHouse Pittsburgh thursday the 8th. It’s similar to NSCoder and SuperHappyDevHouse, but in the pittsburgh area. Some of the local CocoaHeads will be there.

After about a year off, Pittsburgh Cocoaheads is going to be starting up again. Second thursday of the month, 7:30 - 9:30 PM, on the CMU campus (Newell-Simon Hall. Room 3000 or 3001. There will be signs pointing the way)
And for folks who don’t know about CocoaHeads, it’s an international Mac Programmer’s group. Pretty much an excuse for Mac programmers to congregate and geek out. Right now we have 20ish chapters in seven countries, two hemispheres, and four continents. Check out CocoaHeads.org for a chapter near you. If there is no local chapter, or if your local chapter hasn’t met in awhile, feel free to drop us a line and become an organizer.
CocoaHeads started in Pittsburgh several years ago when AgentM and I decided to start a Mac programmer’s group because there was nothing in the area. He came up with the name and the logo, and did a lot of evangelizing in the early days. I’m glad AgentM picked the name : I would have come up with something horrible like “Western Pennsylvania Mac Programmer’s Geeking Out And Food Eating Society”, which doesn’t quite have the groovy ring of “CocoaHeads”