As if the world hadn’t changed enough for the families of three souls lost to senseless violence at the hands of a madman in Cupertino yesterday, we’ve also lost a visionary who was willing to continue risking his successes to change our world for the better.

My condolences to the families of Mark Muñoz, 59; John Vallejos, 51; Manuel Guadalupe Piñon, 48; and Steven P. Jobs, 56 and to their friends and co-workers.

Steve drove the personal computer industry. The IBM PC wouldn’t have been designed as it was, nor been the success that it was, had it not been for Steve’s insistence on raising the bar on the Apple II’s case, documentation and packaging beyond the aesthetic sensibilities of the technophile typically purchasing microcomputers at that time.

Windows would not have existed were it not for Bill Gates’ realization that Steve correctly viewed the GUI as the catalyst to broadening the PC’s appeal to regular people who had no interest in becoming computer literate. And of course, the Macintosh is still around and Microsoft is still copying its aesthetics and features.

Mobile computing is just the latest incarnation of PC devices, and Apple is solidly dominating them with the iPhone and iPad. What his vision is for cloud computing is still a mystery, but he’s made it plain it’s important enough to invest a considerable sum.

No floppy drives either!

Steve’s made even companies outside the computer industry sit up and take notice. Remember when brightly colored plastic goods were all the rage after the introduction of the original iMac? And of course, the recording and motion picture industries have had to contend with Steve’s ambitions, as well as benefited from Apple’s software for creative professionals.

Now, I’m no Apple fanboy. I think the essence of The Macintosh Way at Apple was effectively killed when Steve returned as iCEO with his NeXT lieutenants. And no one can deny that Steve didn’t originate the ideas nor implement them. But it’s doubtful anyone else could’ve pulled off what he did. It’s pretty evident no one else would because, even with the examples he’s set, no other big computer company has. He understood how the technologies he was around could be utilized by people, not just engineers; he had the organization to achieve it; and he was willing to spend the resources, time and reputation to bring his vision to reality.

I had played with a Macintosh at a dealer’s once or twice but saw little value in it. It did doodles, but not real tasks. The machine that blew my mind was the Commodore Amiga. It too, had a mouse-driven GUI, but its hardware blew the doors off any other on the market. I even got a job as a Macintosh programmer on the basis of the software I developed for the Amiga. I cockily boasted of the machine’s superiority, of the inferior Mac’s usefulness only for trivial “home’ applications, and my new bosses said they might consider porting their software based on what I showed them. But it wasn’t long after, as I programmed the Mac during the day, and my Amiga at night, that I began to see the genius embodied in the Mac. It was just so much more professional in the look and feel of its UI and, sad as it was for me to acknowledge, its hardware (the case and peripherals). More elegant, refined. Even more artistic. The technological superiority of the Amiga paled to the human element reflected in the Mac. I understood that. And it wasn’t the fact there were windows, menus and an interface in which everything was actually a picture. Those were already available for most platforms of the mid-80s. It was how the total experience was shaped, how the necessary elements complemented each other and supported that experience. Without the strength of Steve Jobs’ vision and conviction, we wouldn’t have had that.

There’s no doubt that his resignation yesterday signifies an unhappy prognosis in his battle with cancer. Men with his abilities and drive don’t stop creating voluntarily. Even into their 70s and 80s, they continue to imagine wonderful gadgets and objects and do the work they enjoy. My neighbor Tom, in his 70s, crafts beautiful wooden boxes with compartments and sliding wooden locks using manual and powered wood-working tools that intimidate me. He told me he too, has terminal cancer. But he just keeps working, and smiles the most welcoming smile because he’s still doing what he loves. They all do. Until their bodies just aren’t strong enough to keep up with their hearts. It’s tragic to lose men in their 70s when there’s so much we have to learn from them.

It’s more than doubly so when they’re as young as Steve Jobs.

Update: I forgot to mention that I got help from the great folks at NSCoder Nights in San Francisco when mucking about the installer and Xcode files. Particularly helpful were Bruce Spath and Dan Grover. Thanks again, guys!

Here’s how you can install the iPhone SDK for 2.2.1 on a Mac running at least MOX 10.5.5:

1. Ensure you have at least 6 gigs of disk space available. If you have tried to install the iPhone SDK on the target volume before, it may state an upgrade will be performed instead of an install. Sadly, the only solution I currently have for this situation is to uninstall Xcode using /Library/Developer/3.1/uninstall-devtools.
2. Download the SDK disk image.
3. Mount the image by double-clicking it.
4. Copy the mounted volume to a hard drive.
5. Navigate to iPhone SDK.mpkg/Contents/iPhoneSDK.dist in the copied folder and replace line 340 which should be
start_selected = "isIntel() && hasRightOS() && agreedToSLA()"

with
start_selected = "true"

6. Run the installer, selecting either the default location /Developer or another directory name if you’re looking to preserve your current Xcode installation.
7. After a successful installation, navigate from the installation directory (default of /Developer) to /Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone Simulator Architectures.xcspec, and make the following two changes.

First, replace

{ Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: i386)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = ( i386 );
ArchitectureSetting = "ARCHS_STANDARD_32_BIT";
},


with

{
Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: i386)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = (
i386,
);
ArchitectureSetting = "ARCHS_OLD_STANDARD_32_BIT";
},
{
Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: ppc)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = (
ppc,
);
ArchitectureSetting = "ARCHS_STANDARD_32_BIT";
},


then, replace

{ Type = Architecture;
Identifier = i386;
Name = "Intel";
Description = "32-bit Intel";
PerArchBuildSettingName = "Intel";
ByteOrder = little;
ListInEnum = NO;
SortNumber = 105;
},


with

{
Type = Architecture;
Identifier = i386;
Name = Intel;
Description = "32-bit Intel";
"PerArchBuildSettingName" = Intel;
ByteOrder = little;
ListInEnum = NO;
SortNumber = 105;
},
{
Type = Architecture;
Identifier = ppc;
Name = "Minimal (32-bit PowerPC only)";
Description = "32-bit PowerPC ";
"PerArchBuildSettingName" = PowerPC;
ByteOrder = big;
ListInEnum = No;
SortNumber = 201;
},
{
Type = Architecture;
Identifier = ppc7400;
Name = "PowerPC G4";
Description = "32-bit PowerPC for G4 processor";
ByteOrder = big;
ListInEnum = NO;
SortNumber = 202;
},
{
Type = Architecture;
Identifier = ppc970;
Name = "PowerPC G5 32-bit";
Description = "32-bit PowerPC for G5 processor";
ByteOrder = big;
ListInEnum = NO;
SortNumber = 203;
},


Now go ahead and start Xcode and when you select the “File > New Project…” menu item, you should see a darling iPhone category for projects. Also, run the iPhone simulator in /(Xcode install path)/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\\ Simulator.app, it’s really mind-blowing to run it on your desktop, especially one Apple tells you isn’t able to run their iPhone SDK.

By the way, if you don’t feel like going through these steps yourself I’ve put together iPhoneSDKonqueror, an app which will handle these steps for you in a mostly automated manner. You should buy it. It’s only USD$5 and if you appreciate the ability to use your PowerPC Mac to write apps for the iPhone, it’s the right gesture to make to me.

While making the changes to Mori’s code for 1.7, I encountered some oddities in test results, and it turned out there was a bug which I had introduced in an earlier release. While it doesn’t appear to endanger data in Mori notebooks, it might not return all the results you expect in a search, or in entry summaries.

In addition, it has what I hope are a couple of performance improvements, continued improvements to Italian localization, and a work-around for Leopard’s insistence to treat non-Apple Spotlight metadata files as third-class citizens.

Normally when Spotlight discovers a file has been created or changed, it will ask the responsible program to figure out what’s inside, and feed it back to Spotlight. But one of the drawbacks to Spotlight’s design is it lacks the ability to define containers, or documents which contain logically distinct elements such as the chapters of a book, pictures in a photo album, or entries from a Mori notebook; and which can nest other containers as well. Treating a document as a single entity, Spotlight will open a document at the beginning (or maybe the place where the cursor was the last time it was open), even if what you’re looking for is somewhere near the end.

Because it doesn’t understand that a file can have distinct elements, the development teams for other Apple software (e.g., iPhoto, Safari, Stickies, etc.) came up with a scheme to trick Spotlight by creating new files with the data for those elements. So that’s how Jesse coded Mori’s behavior: duplicate the data for that logically distinct element in its own file. A separate copy of each element’s data in its own file. One extra file per element. That means the space taken up by your data is easily half again more than if Apple just added a container definition for Spotlight metadata (once for the notebook, another for the entry metadata file, and the third copy in Spotlight’s database).

But that isn’t all. While we’d like to keep all those extra files inside a notebook bundle (a directory which Finder treats as a file), because Spotlight treats a document as a single element it won’t look for those files inside the bundle. So Mori creates those files in the metadata cache folder (in your Library/Caches/Metadata folder), along with the metadata files from some of Apple’s programs. If you open the metadata folder and look at these files, you’ll see they have numbers to help Mori figure out which entry contains that data. But when you do a search using the Spotlight menu, and when you select menu item ‘Show All’ and the results are displayed in the Finder, you won’t see the numbers; you’ll see the titles for the entries they represent.

Leopard however, isn’t so democratic; which is why users where complaining about the entries when Leopard was released. First off, it ignores any non-Apple metadata files in the cache folder unless you set your Spotlight preferences to use those files. Secondly, it will ignore the title info embedded in the entry metadata file and just display the file’s actual title, meaning the number. How’s that for Apple undermining the work of third-party developers?

So the workaround I came up with is to add the entry’s title (or Untitled, if it has none) at the beginning of the filename, so you at least have an idea which entry matches your search terms.

(Thanks for wasting about a whole month total of my development time on that alone, Apple. I feel the love.)

I am, of course, more than happy to eat crow should I be proven to be completely mistaken or speaking from out-dated information. It’s easily worth it in order to improve the user experience.

Regardless of the rationale for the design decisions, enjoy, and thank you for being part of the community and continuing to support Mori!

Wow. A lot of folks already have lists of what they don’t like about the MBA. So do I.

• It isn’t a tablet.

  The tablet interface opens up a whole new range of apps (just look at what changes the touchscreen interface has brought to the mobile market.) I could be so much more productive with a tablet. I promise.

• Lack of replaceable battery.

  Will I be able to get to an outlet in five hours? Would I have been able to find a spare battery in three years’ time when the charge goes down to 2?

• 1.6GHz CPU?

  Are you kidding me? Weren’t we looking forward to the 3GHz PowerPC G5 more than four years ago?

• FireWire!

  Why has Apple abandoned the IEEE1394 spec it created?

• Gigabit Ethernet

  In fact, any ethernet at all! Something, at least, which has better performance than WiFi!

Others complained about the hard drive capacity being only 80GB, and the solid-state drive (SSD) being so expensive. I don’t care. As a laptop, it wouldn’t be where I do the bulk of my work or computing. It would only be for away-from-the-desk computing.

When I saw the announcement, and the pics, I knew it was a computer for lightweights. It isn’t meant for power users. It isn’t meant for programmers. It’s meant for folks whose computing needs just aren’t driven by applications which demand horsepower.

Joe Goh, the developer behind Phone Journal, replied, “Definitely not just trendy. Lots of people I know won’t carry a portable computer otherwise. Its going to be a hit with ladies”, which proves my point exactly. If you haven’t already needed to carry around a laptop, particularly one like the less expensive and more powerful MacBook, why would you start with this model?

So, although I saw that the userbase for the Mac was going to explode through the MBA, as a user, it just wasn’t my type of machine.

But as I was reading Wil Shipley’s take on it, the notoriously name-dropping blogger and lead developer of Delicious Library, and how he was going to buy one for himself, I realized there was something special about that solid-state drive.

This is a picture of a 256K Dynamic RAM memory card for an S-100 computer. It’s the sort of thing we used back in the late 1970s. Typical of gadget freaks, it was more power than the CPU could directly handle, so the excess had to be put to use somehow: RAMDisk.

Back in those days, microcomputers generally used floppy drives: storage devices that stored information on portable media that resembled CD-Rs *inside* its jewelry case; except the floppies stored up to 800KB, looked dark brown because they were actually coated with rust, and were 5.25″-8″ in size! These things were large, and slow. Things were better if you could afford the $3,000 for a 5MB hard drive because they were faster and stored a tad more info, but the majority of us users were stuck with the less-expensive, and slower, floppy drive.

Ah, but that extra RAM came in handy here. Once you loaded in some RAMDisk software onto your micro, your RAMDisk would give you performance that blew away even those speedy hard drives. Instead of putting up with the slow grinding-grinding of the floppy drive while you were working, the RAMDisk would buffer the data the first time it was read from the floppy, then blast it into application memory whenever it was needed. You would wonder just how well it worked when you didn’t hear the drives spinning and grinding as before, but when the results came up, you knew it worked fabulously.

And it wouldn’t take long for the results to appear. Performance was thousands times better. You wouldn’t have to go to lunch when you ran the assembler anymore. It was now fast enough to give you just enough time to grab some coffee. It was that fast.

The MBA’s optional SSD will give you that level of performance boost. While hard drives were a couple order of magnitudes faster than floppies, they were still orders of magnitude slower than RAM. While hard drives have improved in performance, so has RAM. Just as adding more RAM to your computer will give a bigger performance increase than adding a faster processor, substituting that power-draining, mechanical hard drive completely with a solid-state device will give a phenomenal performance gain.

While you might complain about 64GB being miniscule(!), the real caveat is that these flash devices that make up the SSD have a limited lifetime. 300K to 400K writes. That’s not a paltry amount, but it is still something to keep in mind.

So now that I think about it, the MBA has one significant advantage for one particular power-user niche: the developer. It doesn’t have the raw CPU horsepower we crave. It doesn’t have the ability to do gigabit ethernet connections to our networks. It doesn’t have separate communication busses for main and video memory. It doesn’t even have a tablet interface. But it does have a honkin’ 64GB drive with no moving parts.

I guess when I get enough money, I’ll have to plunk down for an MBA after all. After they come out with a Rev. B. Hopefully, they’ll have a 128GB SSD option by then!

Well, it looks like the latest toolbar fix has finally stuck. There were actually a few, very subtle interrelated items, and some procedural issues that cascaded into others. Code was shifted around hither and yon, resulting in elimination of two of a main class’ instance variables and simplification of logic in several methods.

Speaking of which, I’d really love to try out Xcode3′s new refactoring tools, but that would mean

1. spending more time in Leopard, which freezes on me,
2. and spending more time in Xcode3, whose text editing I already loathe.

I will need to investigate how well refactoring works in TextMate (which I already own and use from time to time when bumping against some other Xcode2 limitation.)

The pressure cooker development level of the past couple of weeks really put the development process here through the wringer. Some things held up. Some things fell apart. So more ‘behind the scenes’ development is going to take place here to minimize the interference caused by the mismatch between what needs to be done and what the tools require me to do next.

Some observations of the release’s development:
1. The primary, agile-based, processes were abandoned in the panic over the continued toolbar problems and Leopard incompatibilities.
   There was no established process for handling emergencies, so the chaotic edit-compile-test behavior resurfaced. This is not to be repeated.

   Corrective Measures: A plan of action for dealing with emergencies must be established. Exercises and drills prepared and performed so the proper outcome occurs next time.

2. Users seemed to be unaware, or unconvinced, of my plans for Leopard.
   Although I had made statements regarding the planned support for Leopard, it was only in response to questioning by users. I had failed to provide information ahead of time and prominently.

   Corrective Measures: While users refer to the forum when there are questions or they have some issue to resolve, they refer to the blog constantly. It’s best to have already disclosed plans so users have time to assimilate needed info and prepare accordingly. Blog. Blog. Blog. Forum posting: link to blog. Then blog.

3. Unit testing got skipped.
   It was unavoidable given the current process because tests didn’t cover the critical issue being developed: the user interface (i.e., toolbar items and empty windows).

   Corrective Measures: Mock objects are inadequate to sufficiently test the UI. For all my blustering that the UI is testable, it’s clearly time I seek or develop the necessary tools and put them to use.

4. Subversion is a win, but it’s an ugly win.
   Being able to restore files, or the project, of a particular beta or release build, or of a particular date and time, is great. Being able to make wholesale changes to the project, then abandoning them, or keeping them along a separate branch to continue experiments at a later date without juggling project directories here and there, is great. Being able to merge or contrast multiple working project directories from separate environments (Tiger, Leopard, laptop, and the v1.6.3 release) quickly and easily, is great.

   Nibs saved as a smattering of files in the repository: not so great. Confusing subversion with its own metadata when copying/adding directories: not so great. Performing an add/delete when moving or copying directories and files instead of adding “move” or “copy” semantics to the system: not so great. Poor integration mechanism for multiple offline revisions: not so great.

   SCM is great. I’ve used CVS for years. I’ve even set up another project or two using Subversion before I bought Mori and Clockwork from Jesse. But I don’t see where it’s an obviously better package than CVS, but perhaps that’s because I’ve learned to work around CVS’ shortcomings. (Reviewing the feature list at http://subversion.tigris.org, the only practical feature I see that means anything to someone actually using Subversion is command-level manipulation of directories, although the handling of renames is poor. Hrmm. And svn+ssh access to the repository, with Xcode integration even!)

   Corrective Measures: For the time being, the messiness of the metadata in copies and moves will have to remain unsettled. As long as the structure ends up correct, and it doesn’t take long to get it to that state, it remains tolerable in the face of bigger issues. A procedure must be established to handle the circumstance where developers are offline and must “commit” in some manner which is transferrable to the repository when they are back online.

5. Debugging is severely inadequate for professional-grade development.
   Can you tell Apple’s team has a severe case of he-man, mouse-haters club insecurities? (Either that, or they’re operating in crunch mode so much, they don’t have time to develop the appropriate tools. Nah!) The debugging facilities they provide for developers operate primarily through the use of environment variables, console output and functions and output which require gdb to access.

   ZeroLink didn’t work well and was abandoned; Fix and Continue is still problematic; and the vaunted debug libraries (to help you catch errors in the parameters passed to the AppKit and Foundation libraries) hasn’t worked right since 10.4.3.

   My own debugging facilities are rudimentary and lacking in depth. More of the failures in the field should be communicated back to me (remember Safari’s ‘bug’ button?). The crash reporting mechanism should work when the crash occurs, not the next time Mori runs. Also, exceptions are logged to the console, but otherwise go unnoticed by Mori and the user.

   Corrective Measures: Extend the runtime monitoring and browsing tools. Rewrite the crash reporting mechanism to activate when the application terminates. Add an exception handler which sends reports back. Develop proper high-level debugging tools for Objective-C, the UI, CoreData and Bindings. Coding takes place at a higher level. Debugging should be at least at that same level. -fobjc-gc exists for a reason. Take advantage of it!

6. The build process is inconsistent, confused and unstable.
   The various plugins’ build settings aren’t consistent. Extraneous resources (images, sounds, etc.) are stored in the nibs. At times the build directory must be purged for a functioning executable to be built.

   Corrective Measures: A Build Settings Table has already been prepared and Mori and its plugins have had their settings documented. The settings for the Blocks plugins has yet to be documented. The effect of some settings has to be determined, which can then be propagated to the targets as appropriate. The project file should be purged of duplicated actions, unnecessary references, etc.

7. Debugging Mori when it’s used for normal work results in too much human activity thrashing.
   Because the debug and test versions use the same preferences/file settings, the release version used for normal work had to be exited to avert data corruption in the notebooks.

   Corrective Measures: This issue was resolved with the Oneill branch. However, that uses a separate target to achieve its distinction. Some means of specifying a special bundle id for the debug and test builds must be developed to accomplish a similar effect, perhaps through preprocessing the Info.plist.

8. Checklists are great
   Being able to state that processes are being followed, builds are complete, and updates were released correctly, is great.

   Corrective Measures: Checklists are great, but scripted procedures are better. Automate as much of every process as possible.

9. To-Do lists, Getting Things Done (GTD), or whatever Time Management activity that is put into practice definitely helps.
   I’ve got the audio book. Mori’s got the plugin. I’ve got Taskpaper, too. I’ve got a Handspring Visor Edge and its Palm Desktop software. Something, anything, that helps track tasks that need to be done so nothing falls between the cracks is a plus. They are effective at keeping things moving forward, but I’m not efficient at it and a lot of discipline and effort must be used to keep moving things forward.
   Corrective Measure: I used TaskPaper to handle the tracking during this hectic period. I’ve got a blog entry in preparation, but basically, I found it a great way to get into the GTD system due to its simple interface. I must continue developing my understanding of this system to manage my activities, and see about getting the various software/devices integrated better.

Next Batch of Changes

I’ve already begun work on v1.6.8: Improved checking and repair functionality for notebooks. Correct Italian localization, thanks to Mario Pettenghi. The code for the Blocks framework will be tweaked so it compiles without triggering warnings (e.g., unused parameters, missing prototype, etc.). Additional unit testing for the UI, and refactoring of UI code.

These improvements to the code will set up the continuation of progress for v1.7, which should then be ready during the holidays. At least that’s the current goal.

Even after releasing two updates to the same app in as many days, there are still unresolved, critical issues that have to be corrected. I’m attempting to get the toolbar items and empty windows bugs fixed in Tiger, and solve some of the more blatant of the Leopard issues.

Speaking of which, I hate Leopard. It froze while I was away from my machine. Don’t just put lipstick on a pig and tell me it’s a healthier beast. Get a healthier beast.

Stacks? Pretty. (At least the grid layout. The arc toss is a hurler.) I can’t navigate through nested folders with it though. Less functional. Would I rather have prettier than less functional? Definitely not in this case.

So I rebooted into Tiger and answered some emails. I’m going to see if Thunderbird (yes, I don’t use Mail.app for real email) will allow me to link to its database in the Library (~/Library/Thunderbird) or whether it’s yet another example of me wanting to be so unconventional that I can’t get tools to do what I want.

Then I’ll head back into Leopard and add some more unit tests and debugging and hopefully get a stable update into users’ hands by morning. I’m hoping the debug suffix works better for me in Leopard than Tiger’s did.

So it turns out the announcements were not as spectacular as we had hoped for. A lot of the keynote was in fact a repeat of last year’s. What was new was the disclosure that EA and id were developing new games for the Mac, Safari was going to be available on the Windows platform, and that XHTML/AJAX was the API for the iPhone.

Very underwhelming. Very un-spectacular. And very significant.

Gaming for Mac gives less cause for users to run Windows on Mac hardware.

Safari for Windows gives more reason for web developers to support the lowly Mac user, who could otherwise be ignored.

And XHTML/AJAX, or Web2.0, means that the iPhone has no significant programming hurdle for users. You could write up a simple iPhone app using Safari on your Mac or PC, and download it to your iPhone when it’s ready. You could even tweak other apps to your liking. Perhaps Apple will be motivated to release DashCode for Windows as well. But it just goes to show that scripting has already won.

It will also inhibit the adoption of Microsoft’s PopFly!, Silverlight, Adobe’s AIR, and other proprietary “solutions” to ubiquitous, networked apps.

It also means the iPhone has no significant programming differentiator from any other platform. Thus, whatever apps you write for the iPhone will operate with minor modification on the Nokia N90, which also has an embedded WebKit.

And, finally, it means my plans are not only safe, but will carry more weight than I thought.

There was an alpha released last week, and an announcement due this week. However, due to some minor distraction, the news will be postponed for a week and we’ll just release a beta or two instead. Hopefully, that will be sufficient to adjust for any unexpected “secret features”.

Neither, it appears, do New Media folks.

Here’s one who does, though. (This lesson may also apply to developers tied too closely to the Mac platform.)