Learning T'ai Chi

I took a T'ai Chi workshop this weekend, presented by Robert Goodwin. Mr. Goodwin is one of the founders of the St. Louis T'ai Chi Chuan Association. The Association is affiliated with Mr. Benjamin Lo (no link), the senior student of Professor Cheng Man-Ch'ing. This lineage is important.

I once again find myself in the position of being both happy and sad. I am very glad that I took the workshop. I am tremendously grateful to Mr. Goodwin for taking the time to come and teach us. I learned many lessons, and the most important (as I understand things) are lessons I would never have learned (or learned much later) if Mr. Goodwin had not come to teach us.

Yet I am sad to see how little of T'ai Chi I have grasped. I have learned a great deal over the years, and I have no qualms about my intentions. But T'ai Chi is such an onion, there are always new layers to it. Each new insight that I gain shows me that there are three more yet to be learned. It sometimes makes me feel my dedication and perseverance are lacking. When I give myself the luxury of an excuse, I mutter something about two working spouses in a multi-child family. But the truth is that I feel like a 'slacker'.

But I will forgive myself and move on, striving to do better in my T'ai Chi practice and in my understanding of the principles of T'ai Chi. Since so much of learning in T'ai Chi is about being honest with yourself, this is another chance to accept how much more there is to learn and strive for it.

Thank you, Mr. Goodwin. The workshops were fantastic.

I'm a "Week"

I'm a software "guy". And by some definitions that makes me a "geek". And when it comes to cool, inventive and creative things, I really am a software geek. But lately I've become a woodworking geek. Sadly, the term "woodworking geek" suffers from a plethora of problems, not the least of which includes a sort of cognitive dissonance. So I've decided that I'm a "week" (woodworking geek). Is that word horribly overloaded? Yes. Will inventing a term that duplicates one of the most common words in the modern English language doom the term to failure? Without a doubt.

Sigh. I guess I'll abandon my delusions of grandeur and revert to "aspiring wood craftsman" (but "week" is much simpler and catchier... :-) )

Humanity

One of the great tragedies of our existence is the way in which man's baser instincts run roughshod over his transcendent ideals. Greed, aggression, and cruelty can undo, in moments, the painstaking efforts of millenia. Are we so fundamentally flawed that we are destined to ignoble oblivion?

Middle Age

I've been feeling lately like I'm middle-aged. It's not something I could explain it in any clear way, beyond the obvious things (like having a couple of kids, a job that I need to pay the bills, thinking about whether I'm saving enough for retirement, etc.). Besides, you can have those things and not feel middle-aged.

Then, tonight, it hit me: you're middle-aged when you read the vast majority of things because you need to read it, not because you want to read it.

Take Supercapitalism by Robert Reich. I'm not far into it (partly because I strongly suspect I'm not going to be joyful about what I learn), but if it's anywhere close to as good as The Work of Nations then it's going to be amazingly good. Now it's true that this sort of material does hold some interest for me. But not enough to represent something like 25% of the books I've read in the last year that weren't directly for my job (or reading to my kids).

So it's not the affair with the 'other woman' (haven't had one), nor the sleek sports car (don't own one) that defines middle age. It's when you spend practically all your time reading things you need to read and very little time reading things you'd like to read.

I wonder what's coming from Delta

Well, Delta Machinery has had a countdown clock on their website for more than a month now:


I think they are going to announce a new line of tools at the big AWFS woodworking show in Las Vegas. I hope it's something cool and not just an excuse to introduce a lower-quality line of tools made in China.

Looks like I'll find out tomorrow.

Bathtub Reading Table

I recently completed my latest woodworking project. It's a bathtub reading table made of mahogany.



I designed it to be just wide enough between the outside supports to allow felt pads on the inside edges. This prevents the table and tub from being scratched, and provides a nice smooth surface for sliding the table back and forth.

Learning Cocoa: Which Frameworks to Learn?

I've been wondering which frameworks on Mac OS X I should learn. It's hard to know the answer to this, since different applications will need different frameworks. But it occurred to me that examining the frameworks that Apple uses in their own applications might be a good start.

Not too surprisingly, you can determine the shared libraries used by an application. So I whipped up a little shell script to go through a set of applications and print every framework used and the number of different applications that use it. The applications are:

• Address Book
• Automator
• Backup
• Calculator
• Chess
• DVD Player
• Dashboard
• Dictionary
• Font Book
• GarageBand
• Image Capture
• Mail
• Photo Booth
• Preview
• QuickTime Player
• Safar
• System Preferences
• TextEdit
• iCal
• iChat
• iDVD
• iMovie HD
• iPhoto
• iSync
• iTunes
• iWeb
• Keynote
• Pages

There are more than 100 frameworks used by these applications! Wow. This little experiment reveals some unsurprising things: learn Cocoa. But it also suggests that there are at least portions of Carbon that are required reading (the Carbon framework is the second highest used). There are some odd things near the top, like iMovieSupport.framework and some things that are obviously important but I don't know what they contain (like CoreServices.framework).

If we arbitrarily remove all the frameworks used only once, we still have 71 frameworks. If we remove those used 2 times or less, we still have 61. If we remove all that are used less than 10 times, we end up with 18 frameworks:

100 - Cocoa.framework
93 - Carbon.framework
50 - QuickTime.framework
48 - CoreServices.framework
35 - Foundation.framework
33 - OpenGL.framework
33 - CoreFoundation.framework
30 - iMovieSupport.framework
27 - AppKit.framework
24 - ApplicationServices.framework
24 - AppleAppSupport.framework
21 - IOKit.framework
17 - SystemConfiguration.framework
16 - QuartzCore.framework
13 - Security.framework
13 - AddressBook.framework
11 - QTKit.framework
10 - BDControl.framework

This is much better than 100, but still too large. I guess I need to figure out what is in these libraries and go from there. Until I can do that, I have plenty to do just learning Cocoa fundamentals and the development tools.

Learning Cocoa: Peeling the Currency Converter Onion

Well, after quite a bit of reading and trying to puzzle out how to use Interface Builder to work on applications using Cocoa Bindings, I've concluded that I don't understand well enough. This is rather surprising to me, since I have more than twenty years of development experience with more than fifteen years of object-oriented and GUI programming experience. But whether I'm in the early stages of dementia or Apple's documentation leaves something to be desired, I clearly have to take a different approach :-). So, I've gone back to the Currency Converter tutorial to try to make a few things gel.

I know that Xcode 3.0 and a brand spanking new version of Interface Builder are due out with Leopard sometime this spring (of 2007), but I'm trying to learn as much as I can before then. After the new Xcode and Interface Builder come out, I may revisit this subject to weigh in on the dementia versus documentation debate.

I should point out that this article is not meant to be a slam of Xcode & Interface Builder. I don't have enough knowledge to know if it's my ignorance that is the issue, if Xcode & Interface Builder need improvements, or (probably most likely) some mix of the two. So, this is as much notes to myself for future reference as anything else, posted somewhere that others might find it helpful.

So, time to get started. Happily, the tutorial is pretty up-to-date:

You'd better be up to date

[Note: This is a discussion of the tutorial and in no way takes the place of the tutorial. You probably need to have worked through the tutorial or work on it in in parallel.]

We are going to create a simple currency converter, to understand how Cocoa implements the MVC (Model/View/Controller) design pattern. The application itself is trivial:


The GUI for the Currency Converter Tutorial Application

After running the Xcode application and creating a "Cocoa Application" project, we see this:


The Main Xcode Window

We are instructed to open the NIB file, named MainMenu.nib, which is the file that contains the user interface. The user interface is edited using Interface Builder, Apple's sort-of WYSIWYG GUI builder. If we double-click on MainMenu.nib, Interface Builder is launched. The tutorial walks us through a number of user interface tasks like renaming menus and menu items, titling the window, creating user interface elements, etc. All of these are simply until we get to creating some bindings.

Even the first binding action, setting up the tab order of the text items is reasonably straightforward. We control-drag from the starting field to the next field. This brings up the object inspectors Connections tab where we choose nextKeyView.


Specifying Tab Order of Text Fields
The strange part, at least to me, is how we specify the first text field to receive focus. In the object window of the NIB, we see this:


There's the item named "First Responder" staring us in the face. But we don't touch it. Instead, we control-drag from the main window to the first text field to recieve keyboard input and choose initialFirstResponder:


Setting the Main Window's "initial responder"

This is non-obvious step number one.

Next, you have to remember you need a custom controller and how to create one. I had no problem with this when I went through the tutorial because it gave me the steps. But when I went to write my own application, I forgot that you have to switch to the Classes tab of the NIB window, select the class you want to sub-class (NSObject in this case), and hit ente r. As it turns out, you can also use the contextual menu to create the sub-class:


Regardless of whether you use the menu (remembering it exists) or hit enter, this is only obvious with practice, giving us non-obvious step number two.

For a complete newbie like myself, knowing what to sub-class is non-obvious, leading to non-obvious step number three. The tutorial tells us to sub-class NSObject, so we do so, naming the new class ConverterController.


Creating the ConverterController class

The tutorial now goes on to talk about outlets. When they are first brought up, their purpose and the reason for giving them a unique name is not obvious. After reading through this again, it now seems clear that outlets are really just object references. They are marked in the code with the IOOutlet macro, a null macro apparently there solely to let Interface builder find them in the code. But things get more confusing quickly. The next section telegraphs the murkiness to come. The first sentence in the "Target/Action in Interface Builder" section says:

"You can view (and complete) target/action connections in the Connections pane in the Interface Builder inspector. This pane is easy to use, but the relation of target and action in it might not be apparent."

After introducing the new term "target/action connections", in the very next sentence they define a target as the outlet of a cell that sends an action message. What the heck is a cell and what is an action message? The next few paragraphs weren't particularly helpful in explaining this.

After some additional reading and head-scratching, I think it's much simpler than they made it. UI components like buttons have their own object references ("outlets") that refer to things, and they use those references to invoke methods ("actions") on the object they refer to. It's a stinkin' object reference used to invoke a method. I honestly still have no idea what a "cell" is, but I'm betting it has to do with some abstract pattern of the UI components of the Cocoa GUI frameworks that I really don't need to know about at this point. There is one subtle bit of information buried in here: "actions" follow a naming pattern (again, to let Interface Builder find them). I wish they'd just told us that from the outset.

So now I think I finally get it: start your control-drag from the object that will do the invoking and stop on the thing to be invoked. So if your button needs to invoke the controller because it was clicked, drag from the button to the controller. If your controller needs to alter the model object, drag from the controller to the model object.

Along the way, another non-obvious thing showed up: when you view the instances tab of the NIB window, you don't see the outlets and actions of that instances class. For example, the attributes tab of the inspector is empty:


Inspector Display when Examining Instances

Then, when you switch to the Classes tab and have ConverterController selected, you see the outlets and actions:


Inspector Display when Examining Classes

Don't get me wrong: this is good contextual behavior by the Inspector. But for a newbie it was a revelation when I first noticed that flipping to the Classes tab (where the ConverterController class was already selected) showed the outlets and actions I'd defined a few minutes ago and lost track of. I think a lot of this is due to trying to absorb all the new terms in the first place, leaving me dazed and confused...

The next several pages of the tutorial are reasonably straightforward, describing how to add required methods and providing the code for those methods. There's a fair bit of Objective-C, but nothing shocking to someone who understands OO.

After some housekeeping and doing a build, I was able to run my application. And of course it didn't work.
Prior to taking the time to write this down, I would have been at a loss at this point. But by forcing myself to (mostly?) sort out the whole "outlet"/"action"/"connection" business, I had enough information that I quickly figured out I'd somehow deleted the connection from my ConverterController to my Converter. Once I reconnected them, the application started working.

Getting zero feedback when I clicked and the text window for the run produce is a real issue. I understand the need to not flood a console with messages in a real application. And I realize a production GUI application may have nowhere to send messages. But Xcode has a window with text output for the session when you run the application:


The Run Log Window of Xcode

It only seems natural, especially when running the debug version, to print some error messages indicating where my problem manifested. I hope someone can tell me a simple way to turn on what should have been on by default.

Learning Cocoa: Links

I'm starting to spend more time trying to learn the Cocoa development frameworks. For those not familiar with it, Cocoa is a set of software development frameworks based around the Objective-C programming language. There are a number of different frameworks within Cocoa, including GUIs, networking (and IO in general), graphics & imaging, distributed computing, etc.

The most obvious site for learning about Cocoa is the Apple developer website. But, with the help of some friends who are also trying to learn Cocoa, I'm starting to find other good resources on the web for learning Cocoa. Since Cocoa is not as well-known as Java, C++, or Ruby, it's like discovering a whole new world on the web. Here are a few links I'm finding useful:

Cocoa Dev Central - a sort of almanac of Cocoa-related material
Cocoa Blogs - a website listing blogs of people discussing Cocoa (I still need to drill down on this one)
CocoaLab - has a PDF trying to help non-programmers learn how to program Cocoa.
CocoaHeads - "CocoaHeads is a group devoted to discussion of Apple Computer's Cocoa Framework for programming on MacOS X." A sort of clearinghouse for Cocoa Develoer Groups. There's one in St. Louis, so maybe I'll try attending.
IndieHIG - a project to create Human Interface Guidelines (HIG) that are up-to-date with the current Mac OS X look and feel. They feel Apple's guidelines are out-of-date, though the HIG guide on the apple site seems pretty up-to-date to me.
Karelia Software's Cocoa Open Source - "A random collection of useful bits of Cocoa, as found in Watson and in other sundry Karelia applications and testbeds. Feel free to adapt these for use in your Cocoa applications."
Theocacao - a website/blog by Scott Stevenson discussing Cocoa and related topics.

There are even a couple of podcasts on the subject:

Cocoa Radio
Late Night Cocoa

Some of these I found myself, while some of these came from Brian Coyner or David Giovaninni (thanks, guys!).

Searching: Wikipedia as a Primary Source

It's amazing to me how much good material there is on Wikipedia these days. It's getting to the point where I'm about to switch from doing a Google search as my first step in research to doing a Wikipedia search. This obviously doesn't work for very dynamic or overly specific things, like a recent news story (Google News) or some very detailed aspect of a software package. But for terms, or relatively well-known subjects, it is a wealth of information.

For example, it's entry on the Objective-C programming language is quite good. It's explanation of networking terms, for example, is surprisingly good.

It may be time to switch the default search engine for my Safari search field...