One of the members, Patrick Cassell, runs an Apple news and commentary blog at iTechCrossroads.  He did a brief interview, and posted it online.

I wasn’t quite expecting a verbatim interview, so like I guess like that’s how I actually speak and stuff.  But there were some interesting questions.

Here’s part 1, and part 2.

TL;DR: I can batch show and hide UIViews really easily now. Easier than setting up a bunch of outlets, fiddling with tags, making dummy views, or groveling through the view hierarchy.

I bet it’s Cocoa 101 nowadays, but they were new to me, pretty much seeing the reference when dragging a connection to header files (which I never do) and promptly forgetting about them. I might have seen reference to them in a WWDC sessions or something. But finally now I had a real use. Yay! For a lot of this stuff I need to actually use it for Something Real before it sticks in my brain. I can learn stuff by doing, but I’m lousy at memorization. Just look at my history grades during high school. On second thought, please don’t.

RideBuddy™ is one of the new apps coming from Cycling Fusion. Amongst a ton of other stuff, RideBuddy lets you track workout time in various heart zones – ranges of heart rates that have different benefits and consequences to the body. We like the Sally Edwards Heart Zones® system, which is a five-zone system based on certain physiological markers. I won’t get into specifics here, you can join the Cycling Fusion Winter Training in January and get the full details.

Five zones are kind of a lot for a beginner or just a casual rider to wrap their mind around, so Sally created Zoning™, a friendlier three-zone system and a color-coded heart rate monitor. It’s only three zones, but it’s based on the same physiological markers as the five-zone system. You can get a lot of health and training benefit by using the three zone system, and can graduate to the five-zone system when you feel up to it.

My stuff needs to support both. So, I have a number of screens like this one:

Something that’ll support three zones or five zones. Internally I can support from one to five zones. The code that adjusts the layouts based on the zone system in-use hides everything zone-related, then populates and enables stuff zone-by-zone until it runs out of zones. In the above screenie I have four objects per zone: two static labels and two text fields. zone zone zone.

To simplify that work, I have five IBOutletCollection(UIView)s — one for each zone. I walk through all of them to Hide All The Things, then walk the zones enabling a particular collection and populating items until I run out of zones. If I don’t hit a collection, it stays hidden.

Understandably, this is so much nicer than setting up an IBOutlet for each label and text field and making the connections. Or setting a tag on the items. Or groveling through the view hierarchy showing and hiding things. Or having a dummy UIView just to be a container. Just add the outlet collection and make connections in IB.

Markus Möller on Twitter “uses them for animating / moving groups of views. Better than putting them all in a container view. Less hierarchy.” which is another excellent use.

I had a great time when I spoke at CocoaConf this last August in Columbus, OH. It was in my back yard and was a no-brainer to go to. I had a huge amount of fun, learned a lot from the other speakers, and had a fun panel discussion. Plus Dave Klein’s family is a lot of fun. Be sure to hang out with Solomon if he’s there.

I’m not sure what my gesture over there is from. Maybe from the virtual sock puppet portion of “Performance Tuning.”

CocoaConf will be in Raleigh NC, December 2th and 3th. You can browse the full schedule to see if stuff is interesting to you. There’s a registration page if you want to go. I can’t make it because I’ll be playing a concert that weekend, otherwise I’d probably head down.  (December is always nuts for me.)

There’s a $50 discount for CocoaHeads folk. The coupon code is a secret to the non-COCOAHEAD individuals out there, but smart folks should be able to figure it out.

I’ve been to a bunch of SteveNotes.  The RDF was real.  I always recommended WWDC (and MacWorld) newtimers  to do at least one SteveNote.  Now we can just reminisce.

The thing that’s really impressed me about Post-NeXT Apple is the quality of people attracted to, and kept by, the company.  I have friends inside of the The Fruit, all of whom are amazingly awesome.  Curtis. Zach. Evan. Ben. Bill. Clark. Chris. Dave. John.  And any others I’ve forgotten.  It’s a true testament to the leadership that such talent has been assembled.

I never met the man.  I did pass within 30 feet of him on the Google campus a couple of years before.  I was helping move 200 pounds of homebrew for a tech talk, and saw someone sitting under a tree chatting with someone else.  I asked my companion “is that…”  ”yes it is”  ”whoa”.  And we went on our merry way.

I’m gonna head over to folklore.org and read some stories now.

My first App got accepted into the AppStore yesterday – Cycling Fusion’s Class Builder™. Woot! Amazingly enough, it went through the approval process without a peep. There’s screen shots and tutorial videos (some still in the making – didn’t expect AppStore approval so quickly) at the link. And it’s at the AppStore.

Class Builder is a tool for Indoor Cycling (a.k.a. “Spinning®”) instructors to lead better classes. Rather than juggling an ipod, sheets of paper or 3×5 cards, and a stopwatch; instructors can plug their Device into the club sound system, run the class, and have cues pop up at the proper time during the class. They can also configure pre-class and post-class music for ambience before and afterwards. If the club has a projector, the instructor can plug their Device into the projector and show everyone the ride profile, along with additional information like current cadence / power / HeartZone®. A slideshow of photos can be shown during the pre-class time to help set the mood.

Despite “Class” in the name, this has nothing to do with programming.

Folks have asked me what I’ve been up to in the year-and-change since I left Google to work with Cycling Fusion. This is it, and the usual billion other things that go on when you work at a startup (along with the major update to AMOSXP)

The code is pretty much all mine, end-to-end. 13,000 non-comment / non-whitespace / non-brace LoC, 84 classes, 32 html files, and 677 .pngs. Not huge, but respectable. It was my first time really to work on something small enough that could be coded by a single programmer – usually I work on behind-the-scenes stuff that nobody else wants to touch. App design was by me and Gene Nacey, the fearless leader of Cycling Fusion. Graphic design by Emanuel Rufino and me. Luckily I now have the Photoshop skills to convert between an inspired artist and the user interface, to tone things down or amp them up as needed to fit the demands of the UI.

Class Builder is a part of the overall Cycling Fusion strategy for bringing the worlds of Indoor and Outdoor cycling together. We’re revolutionizing Indoor Cycling as we now know it through curriculum and certification, targeted training programs, web-based tools, mobile device apps, licensable music and an online video training library. Our big coming-out party is in the fall. If you’re into that kind of stuff, come on down to the ICI Pro Conference in October and check us out.

This book is a massive overhaul of the second edition.  I dropped a number of chapters (I’m pretty sure folks know about version control systems these days), and a number were added (DTrace and GCD anyone?), with pretty much everything edited and improved (bye-bye Shark :-(  Hello Instruments :-) ), covering stuff through 10.6 / iOS 4.  Students taking my class at the ranch get to be guinea pigs a sneak peek of the Lion-related material.  It had already been over five years since the second edition, so we decided to go ahead and ship it, and then do a thorough job on the Lion / iOS5 / iCloud stuff in a later edition.  Hopefully not so much later this time.

Speaking of Editing, Susan and Chris Loper from Intelligent English edited the book and maintained the DocBook-based pipeline of tools.  The second edition did not have an editor, and it shows.  Chris wrangled the tools, and thanks to Susan’s work I’m quite proud of the third edition, the quality of the writing, and the quality of the index (another second edition sore spot).

These things make great Labor Day gifts.  Be sure to order several for the children.  I’ll have a couple with me at CocoaHeads/Pittsburgh this week to give away.

Edit2: Gaige Paulsen pointed out that it’s already available in the iBooks / Kindle stores.  You can snarf the free sample and check out the table of contents.

Edit1: Folks have asked what’s new (skimming down the ToC – I’ve been living inside this thing, and teaching out of it for five years now…)

• ObjC 2.0 stuff, properties, etc
• Blocks
• 64-Bit computing
• getopt_long
• lib/otool
• Garbage Collection
• Debugging techniques
• DTrace
• Overhaul of Performance Tuning
• Instruments
• NSFileManager got a complete overhaul
• IPv6, overhaul of the code
• CFHost
• FSEvents
• Operations
• GCD

For folks in/near the DC area, iOSDevCampDC is happening that same weekend. I wish I could be split in two, because they’ve got some good speakers as well.

Every now and then I come across a software tool that Gets It. A tool that does everything right. A tool that is a joy to use. VoodooPad is one. MarsEdit is another. Scrivener is the latest to enter the pantheon of My Favorite Apps.  The last three big chunks of new stuff for AMOSXP(3), (GCD, using Instruments, and a re-write and major updating of NSFileManager) were organized and written in Scrivener, and then later converted to DocBook for inclusion in the book. In all, about 18,000 words worth of work.

Scrivener is a non-linear text editing environment. Rather than having, say, a chapter of a book in one single Word or Pages document, you can have each section or sub-section of that chapter in an entity. You can organize these entities in an outline, and Scrivener will automatically flow the text as if it were a larger document. Each entity can be as long or as short as it needs to be.

For example, this is the “binder”, the outline view, for the new GCD chapter:

It has all of the sections of the chapter. If I’m wanting to edit the text for Dispatch Groups, I can select it in the Binder and focus in only on that text. If I wanted to make sure that the text flows into and out of that section, I can multi-select Time, Dispatch Groups, and Semaphores, and see those three sections of text in one editing panel, with subtle separators between the sections. If I decide that I really should talk about queues before terminology, I can just drag the entity and rearrange things. This feature alone, to me, is worth the low price of admission ($45).  Doing major surgery like that in a single document is fraught with peril.  With Scrivener, it’s drag and drop.  Don’t like it?  Undo it.

In addition to seeing the text, and a standard wordprocesor-style outline view (which I don’t use), there’s a cool corkboard mode. I originally thought it was silly and gratuitous, but I eventually found it to be a nice (and fun) way to play with the organization of the document. The corkboard mode also shows metadata, such as a high-level description of the section, its draft status, and other things:

You can see that most of the chapters are First Draft, meaning that I’ve gurgitated out the text, did an editing pass, and it’s ready to make the one-way trip to DocBookland for markup, professional editing, and indexing. A couple are “In Progress”, meaning they’re being worked on but not ready to see the light of day. I can tell at a glance what shape the chapter is in. You can rearrange the document here too. Clicking and dragging the note cards is reflected in the outline view, and hence in your overall body of text.

One of the cool things is the text contents of the note cards. The title of the card matches the title in the Binder view. Simple enough. But you can also have a description, independent from the actual contents of the section. Scrivener gives you a lot of opportunity for out-of-band data. With traditional word processing environments, pretty much everything that’s in the document is part of the flow of text, except maybe things like reviewer’s comments. Scrivener has lots of opportunities for attaching meaningful metadata to sections: add tags, arbitrary keywords, arbitrary long notes and descriptions. Fiction writers can tag scenes with characters, themes, locations, smells, etc. Later on they can do searches to see all the scenes a particular character is in, or what sections concentrate on badger foreshadowing.  I didn’t use much metadata stuff, mainly the note card descriptions and the status.

In addition to the “Draft” area, which has all the text of your document in the little entity files, you can have any number of non-publishing hierarchies of stuff. I do most of my research in VoodooPad – it’s where all the raw information goes as I read technical docs, research on the web, and write test apps. Then I bring it over piecemeal into Scrivener as I suss out how things should be organized, and figure out what needs to be included and what can be left on the floor. Here’s the research part for Instruments:

Each of the texty-looking icons is the equivalent of a text file. You can have whatever text you want there, formatted how you want, embedded images, etc. Kind of like Keynote, these text docs aren’t the leaves of the tree. They’re also the internal nodes. The “Different Kinds of Instruments” text doc actually has three child documents too, each with their own text. I can select “Different Kinds of Templates”, and see its text, along with the children’s text in-line (if I want). There are also images, in this case screenshots, that are part of the “document” hierarchy. As I was writing the chapter, I’d be migrating important information from Voodoo Pad, arranging and rearranging entities so the order of presentation made sense. I wrote a fair amount of the chapter’s prose here. As I took screen shots, I added them as child nodes to the text they would appear in. This way they’d carried along as I rearranged chapters. It’s a very powerful, yet easy to use system.

One odd thing about Scrivener is that it is actually fun to write in. No other text editor feels as responsive as Scriv’s. It’s hard to describe, but typing just feels better than in other apps. The obligatory full-screen mode is nice when you have to concentrate to Get Things Done.  Also, I am a huge fan of the “typewriter” mode. This centers the line being edited in the window. I can have a tall window so I can get lots of context, but when I’m actually typing and editing, the text is in the sweet-spot of my eyeglasses.

Indie developers would should take a good look at Scrivener’s website.  I spent a long time reading the materials, and looking at the demo movies.  They’re all very targeted.  ”Here is a cool feature, here’s how it fits in with the rest of the product and here is how you would use it.”  After awhile, I got a very good sense of the how the product worked, and what particular features would make my life easier.  I had zero problems getting Real Work done immediately after download.

So, if you’re into any kind of long-form writing, whether it be novels for NaNoWriMo or technical books, or even the occasional complicated blog post, I recommend you check out Scrivener. It does so much Right that it is a joy to use.

I stumbled across this little tutorial I wrote back in the mists of time, probably around 1996 or 1997.  And it was based on a tutorial I wrote at Visix, probably in 1993 during one of our Optimization Parties.  It describes how to read the output of gprof, a profiling tool available on most unix systems.  It’s even still there on Mac OS X.  So you kids with your fancy Shark and Instruments, here’s what some of your elders used.

gprof is not a GNU tool, even though it has the leading “g”.  That “g” probably stands for “call Graph” profiler. You’ll need to check your system’s documentation (e.g. man gprof) for exact instructions on getting gprof to work, but usually it just involves compiling and linking with -pg, running your program, and doing gprof gmon.out > oopack.

Here’s a 300K sample of output from gprof on the Dec Alpha if you want to take a look at it. This particular report is from a run of AOLServer 2.2.1 which involved fetching index.html 53,623 times.  The links that follow go to anchors in that 300K sample.  What was I wanting to profile?  I wanted a gut check to make sure that life in the server was sane, and if there were any obvious bottlenecks that maybe I could address if I had the time.  The test was to fetch index.html over and over again. In this case, around 53,000 times

There’s 4 parts to gprof output:

• Built-in documentation: Short form of everything here, and more.
• Call-graph: Each function, who called it, whom it called, and how many times said calling happened.
• Flat profile How many times each function got called, the total times involved, sorted by time consumed.
• Index: Cross-reference of function names and gprof identification numbers numbers.

I go to the flat profile section when I first start looking at gprof output. The big time consumers are usually pretty obvious. You’ll notice that each function has a [number] after it. You can search on that number throughout the file to see who called that function and what functions that function calls. Emacs incremental search is really nice for bouncing around the file like this.

Here you can see that DString is a big time gobbler:

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 17.7       3.72     3.72 13786208     0.00     0.00  Ns_DStringNAppend [8]
  6.1       5.00     1.28   107276     0.01     0.03  MakePath [10]
  2.9       5.60     0.60  1555972     0.00     0.00  Ns_DStringFree [35]
  2.7       6.18     0.58  1555965     0.00     0.00  Ns_DStringInit [36]
  2.3       6.67     0.49  1507858     0.00     0.00  ns_realloc [40]

Out of 21.05 seconds of total clock time, Ns_DStringNAppend consumed about 4 seconds, or about 18% of the time in and of itself. It was called 13 million times.

MakePath consumed one and a half seconds itself, and its children consumed three and a half seconds. At least one individual call to this consumed 0.01, and at least one individual call took a total of 0.03 seconds in MakePath and its children.

Handy tip – the function numbers in brackets are approximately sorted by time consumption, so a function with a [low number] will generally be more interesting than one with a [high number].

Now that you know that Ns_DStringNAppend is called a bunch of times, this could be a useful target for optimization, I’d look at its entry in the call graph section.

Before doing that, just for illustration, take a look at AllocateCa [33] since it has all of the interesting pieces of the call graph in a more compact size:

                0.04        0.18   53622/160866      Ns_CacheNewEntry [62]
                0.04        0.18   53622/160866      Ns_CacheDoStat [58]
                0.04        0.18   53622/160866      Ns_CacheLockURL [64]
[33]     3.0    0.11        0.53  160866         AllocateCa [33]
                0.16        0.17  160866/321890      Ns_DStringVarAppend [30]
                0.06        0.00  160866/1555972     Ns_DStringFree [35]
                0.06        0.00  160866/1555965     Ns_DStringInit [36]
                0.04        0.00  160866/1341534     Ns_LockMutex [43]
                0.03        0.00  160866/1341534     Ns_UnlockMutex [53]

The entries above AllocateCa [33] are the functions that call AllocateCa. The entries below that are the functions that AllocateCa calls. There are two numbers separated by a slash: the first number is the number of calls that the function has made, while the second number is the total number of invocations of that function.

In other words, for 160866/321890 Ns_DStringVarAppend [30], AllocateCa called Ns_DStringVarAppend 160866 times. Across all of AOLServer, Ns_DStringVarAppend was called 321890 times.

Similarly, for 53622/160866 Ns_CacheNewEntry [62], means that Ns_CacheNewEntry called AllocateCa 53622 times, and AllocateCa was called 160866 times total.

So, just by looking at this snippet, you know that the three Ns_Cache functions each call AllocateCa about once per serving of index.html, and that AllocateCa makes a single call to Ns_DStringVarAppend, Ns_DStringFree, etc… each time. What’s also interesting to note is that someone is calling Ns_DStringFree more than Ns_DStringInit. This may be (or may not) be a bug in AOLServer. You can go see Ns_DStringInit and Ns_DStringFree yourself and track down who the culprit is.

The floating “3.0″ on the left is the percent of total time that the function consumed. The two columns of numbers are the amount of time (in seconds) that the function consumed itself (AllocateCa took 0.11 seconds of time total to run its own code) and the amount of time in the function’s children (0.53 seconds were spent in its children)

Getting back to real analysis of DStringNAppend, you can see that MakePath made 50% of the Ns_DStringNAppend calls. Since you know that there were 53623 fetches of index.html, that means that for each page, MakePath was called twice, and for each call to MakePath, Ns_DStringNAppend was called 64 times.

If one call to MakePath could be elided (since it’s getting called twice), or if fewer than 64 Ns_DStringNAppends could be done per call, we could see a performance boost.

Just browsing the gprof output can be an illuminating exercise. If you have a gut feeling that a particular function is a hot spot (say, Ns_LockMutex [43]), you can see the call graph for that function, see if it’s consuming lots of time, or if it’s being called a whole bunch.  Here it was called 1,341,534 times, or about 25 times per page serve. Maybe that’s high.  Maybe that’s right.  Sometimes a suspected culprit isn’t there, or you find a surprising time waster.

Because this sample gprof output was done on a Dec Alpha system, there was some suckage involved, such as no explicit time recorded for system calls. So we don’t know if, for example, select() blocked for a long time on each call.