Second, my MBP is my development computer. Development computers get the snot kicked out of them. They are constantly in flux. Install the new Ruby; install the new Xcode; install the new iPhone SDK beta and the new Drizzle and CouchDB and LLVM. Update the new MacPorts and Homebrew and OpenPKG. Upgrade my git, hg, and svn. Try Erlang, and Haskel, and Hadoop. Then uninstall and reinstall some or all as needed. Eventually, I cross the beams and it’s time for a fresh start¹.

On the one hand, I crave stability. On the other, I’m pushing constant change. On the one hand, I have simple requirements that can be met with a simple, 1.5 pound portable device. On the other, I’m a power user demanding the biggest, the fastest, the most of everything in a 17” form factor.

I’ve tried various schemes to manage the conflicting requirements of these two modes of interaction with my computer. On occasion, I’ve completely lost my mind and try outlandish solutions such as dual booting or running my personal computer as a VM inside my development computer (hey, at least it was easy to backup). These solutions never worked because I often wanted to jump between both worlds quickly and effortlessly.

Then the iPhone came along. It was nearly perfect, allowing me to separate my personal computing from my development — in a package that was eminently more portable than my 17” MBP. However, the iPhone has certain constraints that require me to maintain a personal computing presence on my laptop. I don’t like writing long emails on my iPhone. Certain web sites are so poorly designed they must be viewed on a full computer². I can’t create content (documents, spreadsheets, presentations, diagrams) on my iPhone. Ultimately, the iPhone is a satellite device.

The iPad promises to be my dedicated personal computer. It promises to email, chat, tweet, browse, write, edit, and watch — all while just working. (And, might I add, from anywhere.) That frees-up my laptop to be a dedicated development platform that I can use and abuse without consequence.

I want an iPad to keep my simple personal computing needs separate from my developer computing needs.

¹ I subscribe to the Ripley school of developer workstation maintenance: nuke the entire site from orbit — it’s the only way to be sure.

² I’m not even talking about Flash — I’m talking about sites that screw up HTML that badly.

My wife doesn’t like the black keyboard, but I pointed out that it matches the black border around the screen. I only performed a little typing on the keyboard, so I can’t report how well it would feel to use for extended coding or writing sessions.

The “trackpad-as-button” was far more intuitive to me than I expected. My reflex is still to press at the bottom of the trackpad where the button is located on my MBP. All of my existing mousing and clicking gestures worked flawlessly, so the migration would seem to be painless for existing Apple laptop users. I then played with clicking and click-dragging the new way, by just pressing my finger down in-place to click. This worked exactly as advertised and feels pretty natural. I believe that I would find it very intuitive if I were using an Apple laptop for the first time and did not have preexisting muscle memory for these operations. The new gestures enabled by the design feel far more ergonomic and comfortable, so I believe I will invest the time to retrain myself when I eventually get one of these laptops.

UPDATE: With the NDA lifted, Brad has generously released the source code for Molecules!

Installing CouchDB

I installed CouchDB from source. This requires the Leopard development tools (Xcode) and MacPorts. I expect all developers to have Xcode installed and most developers to have MacPorts installed, so I won’t detail those steps here.

First, install CouchDB’s dependencies using MacPorts:

sudo port install icu erlang spidermonkey

Download CouchDB and extract it. This is standard configure, make, make install territory here:

./configure
make && sudo make install

Wasn’t that easy?

Creating a couchdb System Account

Find a user number that is available. To see a list of what numbers are already in use, run:

dscl . -list /Users UniqueID | awk '{print $2}' | sort -n

Now find a group number that is available. To see a list of what numbers are already in use, run:

dscl . -list /Groups PrimaryGroupID | awk '{print $2}' | sort -n

On my system, number 103 was available for both a user number and a group number. The rest of this article assumes you are using 103 as well.

The following commands create the group and the user and set the user’s home directory to the CouchDB lib folder.

sudo dseditgroup -o create -i 103 -r "CouchDB Users" couchdb
sudu dscl . -create /Users/couchdb
sudu dscl . -create /Users/couchdb UniqueID 103
sudu dscl . -create /Users/couchdb UserShell /bin/bash
sudu dscl . -create /Users/couchdb RealName "CouchDB Administrator"
sudu dscl . -create /Users/couchdb NFSHomeDirectory \
        /usr/local/var/lib/couchdb
sudu dscl . -create /Users/couchdb PrimaryGroupID 103
sudu dscl . -create /Users/couchdb Password *

Finally, we give the couchdb user ownership of the CouchDB lib and log directories:

sudo chown -R couchdb:couchdb /usr/local/var/<strong>lib</strong>/couchdb
sudo chown -R couchdb:couchdb /usr/local/var/<strong>log</strong>/couchdb

DONE! Now you can launch CouchDB as the couchdb user instead of root.

sudo -u couchdb couchdb

Running as a Service

To control CouchDB using launchctl, I needed to add the appropriate PATH information to CouchDB’s Launch Daemon plist so that gawk is found. Unfortunately, I couldn’t find a solution to edit the plist in-place as a privileged user, so I copied the file to the /var/tmp directory without root privileges so that I could update the copy.

Creating a copy of the plist and opening it for editing is done by:

cp /usr/local/Library/LaunchDaemons/org.apache.couchdb.plist \
        /var/tmp/org.apache.couchdb.plist
open /var/tmp/org.apache.couchdb.plist

In the Property List Editor that opens, follow this steps:

1. Open Root → EnvironmentVariables
2. Click on Add Child
3. Name: PATH
4. Value: /bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/opt/local/bin:/opt/local/sbin
5. File → Save
6. Quit Property List Editor

Then copy the updated plist over the original plist:

sudo cp /var/tmp/org.apache.couchdb.plist \
        /usr/local/Library/LaunchDaemons/org.apache.couchdb.plist 

Now CouchDB can be controlled and monitored by the standard Leopard daemon manager:

sudo launchctl load \
        /usr/local/Library/LaunchDaemons/org.apache.couchdb.plist 

Launch CouchDB on Startup

To automatically launch on start up, run

sudo ln -s /usr/local/Library/LaunchDaemons/org.apache.couchdb.plist \
        /Library/LaunchDaemons/org.apache.couchdb.plist

Congratulations! You have CouchDB running as a system service that will start when you boot your Mac. Let the fun commence.

I’d Like to Thank the Academy…

I’d like to thank the following sites and resources for providing me enough information to piece together the process:

• CouchDB Source Code: README
• SysAdmin’s Chronicles: Creating a System Account in Mac OS X 10.5 Leopard
• evang.eli.st: Installing Postgres 8.2 on Leopard

I particularly recommend the evang.eli.st article, as it explains the dscl command, which may be an unfamiliar account management tool.

I should point out that evang.eli.st also has a complete write-up on how to install CouchDB on OSX. That walk-through is almost a year old, though, and entails editing the Makefile—which doesn’t sit well with me. However, where Leopard departs from standard UNIX behavior, I cease being an aficionado, so his tweaks may be important in ways I haven’t yet discovered.

I suspect the figures are pretty offsetting, leaving any future gain in iPhone revenue as a percentage of total revenue really subject to iPhone sales growth v. other sales growth at Apple… and not the new revenue model which is probably pretty neutral.

I didn’t see a way to leave a comment, so I’ll post my comment here. If the only components to this deal were subsidies and contract revenue, then it would be a nearly complete win for AT&T. But this analysis fails to account for the additional revenue that Apple will gain through the App Store selling applications to iPhone (and iPod Touch) owners.

The service contract revenue lost by the new deal is not offset against increased hardware sales—it is offset against App Store revenues. The more people who own iPhones, the more revenue the App Store can be expected to generate. Apple gave up contract revenue primarily in exchange for permission to run its own store selling software over-the-air directly to the iPhone device. In the traditional mobile marketplace, it is the carrier who sells applications and keeps a generous percentage of the application price. Apple negotiated with AT&T (and, apparently, dozens of other carriers internationally) to allow iPhones to purchase and download applications from Apple’s App Store. To secure this, Apple agreed to no longer take a cut of the iPhone service contracts. Additionally, Apple will allow AT&T to subsidize the iPhone, which is now good for both parties. (This new arrangement is apparently much more pleasing to carriers internationally as well, giving Apple more markets in which to sell its product.)

It’s a win for AT&T because they can attract (or retain) many more customers and they no longer split those contract revenues with Apple. Additionally, I suspect that AT&T even gets a small cut of the 30% Apple keeps for applications sold over-the-air through the App Store to AT&T customers.

Apple wins by dramatically increased hardware sales and the right to sell apps over-the-air to iPhones. And the App Store benefits from networking effects. The more people who own iPhones, the more developers will be attracted to build and sell applications in that marketplace. The more applications there are in that marketplace, the more people will want iPhones. The iPhone’s killer app will no longer be it’s revolutionary interface and ease of use, but rather be the applications that run on it. Finally, Apple wins by attracting huge numbers of new developers to its operating system, libraries, and development tools. John Gruber reports that “two engineers from Apple told me that [interest] wasn’t just for the iPhone — that they were seeing plenty of new-to-Cocoa developers in the Mac-specific sessions and labs, too”.

Everyone benefits.

Outcome: 13 correct, 3 incorrect, and 4 unknowns. So my prediction accuracy is 65%-85%, depending on how the unknowns turn out. Not bad, given that 10% of my predictions were complete guesses.

¹ The original iPhone was 11.6mm thick, according to Apple’s support site and the new iPhone is 12.3mm according to the new iPhone site.

² No discussion of a DashCode for iPhone or HTML+JavaScript+CSS application development solution was stated during the keynote. If it comes to my attention that widget iPhone development is possible, I will toggle my answer’s correctness.

Preamble

To understand my predictions for WWDC 2008, you need to understand where I think Apple is going in the next 24 months. To view the iPhone as a stand-alone product is to miss the point. The point of the iPhone is to create a development ecosystem around Objective-C and Cocoa. This ecosystem will have spill-over benefits for the Mac, since more developers will be familiar with the platform’s development technologies, but the real point is to create a large population of developers already familiar with application development for Apple’s next device: a touch tablet. This is why Apple is suddenly pushing “OSX” instead of “Mac OSX” and “iPhone OS”—Apple wants to impress upon developers that the skills for developing on any OSX device carry over to the other Apple devices as well.

With that out of the way, on to my predictions!

Next-Generation iPhone

3G: Yes

This seems like a given.

GPS: Yes

With all of the concentration on 3G capabilities, discussion about GPS seems to have died down a bit. While GPS technology takes away space and power from other solutions apple could provide in the iPhone’s form factor (such as video conferencing), I think that improved positional capabilities will create many 3rd party developer opportunities.

Faster Processor: No

I think there are so many other bells and whistles going into this revision that Apple will be happy to use a processor with the same speed and power consumption as the current model.

Video Conferencing: No

With 3G network speeds, this becomes possible and it is an intriguing possibility. But supporting (1) video capture, (2) video encoding before sending, (3) bi-directional communication over 3G (or WiFi), (4) video decoding what you’re friend is sending you, and (5) continual screen updates to display the video—all at the same time—will simply kill the battery life.

Thicker (face-to-back): Yes

Since the current iPhone is a 1.0 product, I’m willing to believe that Apple learned a lot during its development and—knowing what they know now—could redesign the current iPhone to be smaller with lower power consumption. Starting from that assumption and adding 3G, GPS, and a larger battery to the mix, I believe that the new iPhone will have to be more voluminous. It can’t get much wider without becoming uncomfortable to hold, and it’s current height seems about right, so I believe that the phone will grow a little thicker.

iPhone mini: Yes

Take the current 8GB iPhone, make it a little smaller, and offer it in a variety of colors for $350. Offer a 4GB model for $250. Pesto! You have a device that may attract the interest of my wife. Since I didn’t understand the point of the iPod mini until I witnessed my wife’s reaction, I’ve come to trust her judgement over mine for products Apple targets at non-technophiles.

Higher pricing: Yes

Components: there are more of them and they are more expensive. With the addition of the iPhone mini at a lower price point, Apple will have a little breathing room on the high end. I expect the 8GB model to retain its current pricing and the addition of a 16GB model for $100 more.

SquirrelFish: Yes

Squirrelfish helps the iPhone in two ways. First, Squirrelfish is fast, provides users with an improved Web browsing experience. Second, it is more efficient—getting the same end result accomplished in fewer clock cycles, so it requires less power to run JavaScript.

iPhone widgets: No

In the latest episode of The Talk Show, Dan and John kick around the idea that iPhone widget applications may make a comeback: applications for the iPhone written entirely in HTML+JavaScript+CSS, facilitated by a DashCode development tool specific to the iPhone. There is a lot of sense to this from the perspective that it would invite everyone skilled in Web design to be an iPhone developer. However, as I stated in my preamble, I believe Apple can use the popularity of the iPhone as a means to push Objective-C and Cocoa, thus building a larger community of developers skilled in the technologies that underlie all of Apple’s “software-expandable” offerings.

Apple Software

OSX 10.6 Will Be Announced: Yes

Steve is quoted (somewhere—sorry, no link) as stating that he wanted to be releasing updates to Leopard on a more frequent schedule than was indicated by the delay between 10.4 and 10.5. Announcing 10.6 at WWDC with it’s release due at MacWorld seems about right to me.

10.6 Named Snow Leopard: Yes

Sure, why not?

10.6 Will Specifically be for Atom Devices: No

This was posited by Josh Bancroft and I think he’s generally right that OSX is being pushed as its own brand to allow for OSX on a new device, but I don’t think it will be announced at WWDC.

OSX 10.6 Will Drop PPC Support: Yes

This completely sucks for PowerMac G5 owners. You’re the losers of an unexpectedly rapid and successful migration to Intel. As a life-long loser myself, I sympathize.

OSX 10.6 Will Drop Carbon Support: Yes

Apple wanted to drop Carbon support long ago, but the old-time Apple developers complained and—probably more importantly—Microsoft and Adobe were unable (and perhaps unwilling) to migrate off their Carbon code bases. Reading the tea leaves, Carbon’s now a goner. Apple used the Intel migration as leverage to push developers toward Cocoa, then Leopard didn’t include support for 64-bit Carbon. If the rumors that 10.6 will be 100% 64-bit are true, that rules out Carbon. Good bye.

New / Improved / Revamped .Mac Services: Yes

Please! I’ve had .Mac service since I purchased my first Mac and it was fine for a while—I didn’t mind the premium price at first because it “just worked” and that’s what I wanted. But each of the last three years I’ve been really close to canceling my membership and Apple would announce something that would make .Mac just barely worthwhile enough to continue holding onto. This year, though, if I’m not blown away, I’m canceling it. Or whatever they will call it.

.Mac Rebranding: Yes

It’s hard to sell something called ”.Mac” to a person whose only Apple product is an iPhone. Explaining that .Mac doesn’t require a Mac must be a nightmare.

Apple Hardware

New Apple Device: No

I believe that 2009 will be the year of the tablet, so no new devices this year.

New MBP Designs: Yes

I’m just guessing here.

New Displays: No

I think that the displays will be revamped when the Mac Pro is redesigned.

Pie-In-The-Sky Prediction

Every good WWDC prognosticator needs to go out on a limb and make an off-the-wall or out-of-left-field prediction.

OSX 10.6 Adds Resolution Independence

Despite the rumors that 10.6 will be focused on stability and performance instead of features, I think that this will be on the short list of enhancements.

Then the iPhone SDK was released. As it happens, I have several itches to scratch on the iPhone. And the iPhone is a fun platform, too—I mean, there’s got to be some way for stodgy business applications to make use of the iPhone’s 3D motion sensors, right?

So this weekend I joined the iPhone developer program, downloaded the iPhone SDK, dusted off my copy of Cocoa Programming for Mac OSX, and got down to business. Since I have a strong object-oriented programming background due to my time with Java and I’m comfortable with weakly typed languages due to my time with PERL and Ruby (I’m thinking of mix-ins), the single chapter on Objective-C was sufficient for me to grasp the major components of the language. I assume when I’m done with the book I’ll be comfortable with Obj-C’s idioms and familiar with Cocoa. However, my advice to people interested in learning Obj-C or Cocoa is to wait for the 3rd Edition of the Hillegass book.

First, there are several places where the page layout is off. For example, between pages 69-70 several paragraphs are lost. But don’t worry, between pages 71-72 you get a whole paragraph repeated! It’s not a huge deal, but it is annoying.

More importantly, the 2nd Edition is written for Xcode 2. Unfortunately, Xcode 3 is very different from Xcode 2, so many of Hillegass’ screenshots and instructions for using Interface Builder aren’t even close to accurate. The “Hello World” application from the first chapter can’t be constructed. I was more than happy to try slogging my way through anyway, attempting to convert the book’s instructions into Xcode 3 operations, but it was all too new to me. Fortunately, Matt Long has an excellent tutorial filled in the gaps sufficiently for me to progress further. However Matt Long’s solution involved writing the necessary Obj-C class by hand, so I had to read Hillegass’ introduction to Obj-C before things clicked.

I’m now a quarter of the way through the book and I’m really enjoying Obj-C and Cocoa. Writing applications for the iPhone is going to be a lot of fun.

Now, I use the iPhone every day and it handles my the majority of personal computing needs. It’s convenient and (generally) a joy to use. I don’t appreciate being sent to my secondary computer for tasks I should be able to accomplish on my primary device. I don’t like opening my MacBookPro to surf the Web. Or to read email, record appointments, update contact information, or even to tweet. In fact, I only look forward to using my MBP for coding, blogging, writing documents, and image manipulation. For my everyday online activities, I far prefer using my iPhone. When I have to use my MBP for an “iPhone activity”, I get irritated.

The irritation has been increasing over the last couple of months. Mostly, my irritation is incited by Web sites that don’t lend themselves to ease of use on the iPhone (for example, my beloved Highrise)—or worse, completely disrespect the fact that I’m on a low-bandwidth EDGE connection (for example, Grub Hub, which I saw advertised on the CTA but had to dismiss because the home page took more than three minutes to load).

With the release of the SDK, the iPhone is graduating to become a full computing platform. It will move beyond email and Web sites². I anticipate that the coming year will see the release of all the applications I need to avoid cracking open my MBP for any of the mundane stuff. Finally, I’ll get to use my iPhone for instant messaging, enjoyable Twittering, Highrise, and WordPress.com administration.

Even if I have to build those applications myself.

¹ Of course, looking back on it, I note that my first mobile phone was purchased “for emergencies”, but very quickly became my primary phone service. Perhaps this is a general pattern for adoption of new technologies.

² To be honest, Web applications have really carried the iPhone farther than I expected. There are some very talented and dedicated people out there who pushed the Web on MobileSafari far beyond what I imagined possible.

Why do I use a Mac? I can’t imagine that I would have these memories of the last two months of Elena’s life if we used anything else. That may not convince you either. But tomorrow is the second anniversary of my little girl’s death and I will have movies to watch and pictures to look at.

I can’t think of a better reason. Amy and I share our condolences and wish your family the best.