Well, I wasn’t able to get the transfer complete due to a finicky module. So I’ll continue working on the current fixes for Mori and cutover preparations, and hopefully tonight’s attempt will be successful.

A few weeks back I remarked that there were two surprises I wanted to spring on you. Unfortunately, the recent chaos postponed the work involved, but I’ve been able to continue them now that things have settled down.

One is an upgrade of the site. The website software is seriously out of date. I’ve noticed that searches no longer return search info for new content. Also, it’s currently on an account which doesn’t handle quite so much bandwidth…nor disk space. So tonight I’ll be taking the site down while I transfer the data to the other site. I’ve got the updated software on the new server, and I’ve practiced transferring the info. Here’s hoping that it goes through in the shortest possible time and without unexpected challenges.

The other is a long-standing surprise that I’ll be able to announce after the site has extra capacity.

I had wanted to get these both out of the way so I could participate in the IronCoder contest for Mac developers, which was stretched out to a whole week! A whole week, and I still wasn’t able to participate! Oh well. I’ll still attempt to publish what would’ve been my entry in a week’s time. Of course, that means I’ll have to do my development in Leopard, using Xcode3.

Perhaps I should take a month to finish it.

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.

Since it appears that the users still experiencing the “empty window” or missing notes problem are running Leopard and have some strange mixture of preferences (particularly “Enable check spelling as you type in new windows”), I should be able to get some update out today to Tiger users at least.

I received word a short while ago from users experiencing this specific symptom, and byakkie, who thankfully took the time to experiment with all the preferences to help pin down the most likely causes, regarding the results of running an experimental build to deal with the big remaining issues. With those results, and knowing it’s Leopard-specific (those more stringent parameter requirements!) I’ll reboot into Leopard in a moment and get down to exorcising that gremlin. If it’s like the other Leopard problems encountered it should be relatively easy to find the problem, and hopefully not-too-difficult to engineer a solution.

While I had awaited word, I worked on streamlining and pruning certain aspects of the build process and decided to tackle the recurring error message on my console:

*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (WebView)

which is always cause for concern for developers when things go wrong that you didn’t even realize were going on! “WebView?! Since when is there a WebView in an outliner?”

So I tackled it and discovered it is part of Blocks’ software update service, which checks for new versions of Mori and displays the release notes when found. Once I linked the WebKit framework into the Blocks software update plug-in, the release notes window popped up to announce a new version! Then it had a redirect issue I had to fix (because www.apokalypsesoftware.com redirects to apokalypsesoftware.com). Then I discovered the links in the release notes weren’t pointing to the correct location. And so on.

This all leads me to one conclusion: you folks are hard-core Mori users! Do you Fred Flintstone your way to work? Do you eat stale bread? Do you really love Mori’s features so much that you’ve been willing to put up with the broken stuff for so long? (And just what Mori features are you particularly fond of? I’d like to intensify that experience for you!) It’s just a more pleasant experience when the software does things for you like it should. Wow!

Well, while I am half-joking, I am truly impressed and grateful that you’ve been willing to endure some inconvenient obstacles just for the productivity that you gain with Mori. Thank you so much! I plan to continue fixing these annoyances as features are added, so that you find there’s more that can be done by Mori and less roadblocks it puts in your way.

Anyway, now on to Leopard and that fix!

Unfortunately, one of the fixes I thought I made didn’t carry over from one of the work directories (four at last count) I used to develop for the various MOX versions.

Or I was completely delirious at the time and never made the fix at all.

Whatever the cause, 1.6.6 still shows empty windows as a result of the toolbar problem. You can see when Mori gets confused by checking your console logs. You’ll see an entry like

2007-11-20 11:58:08.592 Mori[8503] *** -[NSCFArray objectAtIndex:]: index (0) beyond bounds (0)

Here’s the cause, and one of three possible paths you can take to get around this while you wait for the, hopefully finally fixed at last, v1.6.7 update: In order to improve your user experience (are you feeling it?), I wanted to move your old toolbar preferences settings to the new internal naming system. So it performs a check to see if the two settings are different, erasing the current one and copying over the new one if they are. However, if your previous toolbar had more items than the current one does, it will come up short during the compare and thus cause a Cocoa exception.

Mea culpa. Mea fixa isa cominga uppa.

In the meantime, here are three ways to get your notebooks back all shiny and fresh.
1. Add a bunch of extra items to your toolbar. Probably at the very beginning where they’re easier to get to and remove.
2. Rename your preferences file (com.apokalypsesoftware.Mori.plist in your Preferences folder) until such time as Mori 1.6.7 is released and things have settled down. Or, if it doesn’t particularly bother you to personalize your toolbar again you could just delete that file.
3. Just open all those important notebooks. Close them. Re-open those notebooks. All your data now appears because Mori has updated the toolbar info. (Or you can just do this for those notebooks you need for the moment. The fix will be released shortly…once I check a few things here first!)

4. My apologies again to those who were alarmed at opening an empty notebook.

I just shipped the latest Release Candidate (Mori 1.6.6alpha89) to the beta testers, and I feel pretty certain it’s fine.

I’m about to do some final checks in Leopard (10.5.1) and may even install 10.5 again to double-check there while I await word from the testers.

I’m going to add a special dialog thanking the beta testers for their bravery and helpful comments and pointers. Not only have they helped to nail the big “empty windows” and Leopard freezing/crashing bugs, but their insights and explanations have revealed some things that I wasn’t aware of in Mori’s functionality! It should take maybe two or three days of coding and testing to add to Mori.

But it’ll have to wait as I know a lot of folks have been patiently enduring the problems in hope of a quick and stable release. So let me just thank them here for their fantastic service to me and Mori’s user community:

Bob Embry
Michael Koch
Rolf Schmolling
Joe Wicentowski

For their patient vigil and endurance, I am grateful.

It looks like the showstoppers which were part of 1.6.4, 1.6.5 (and even 1.6.3 counting the toolbar) have been dealt with. The latest build even seems to function normally in Leopard.

Thus, now that Leopard 10.5.1 has been released, and my Leopard install was for testing purposes anyway and not as my primary development environment, I’m going to install it and test the 1.6.6 build against it as well to make sure it still works. That is, after a stopover in Tigerland just to make sure that nothing in Leopard loused up my main volume.

The problems in Leopard appear to result, not from changes in the architecture of the Cocoa classes, but in how stringent the standards for values passed to them are, and how they deal with values which are unacceptable (invalid parameters and exception handling). Sure, code should only pass correct data all the time, but sometimes our expectations are off. Sometimes we get incorrect data ourselves (Garbage In Garbage Out), and sometimes, bad things happen in the real world in which computers operate.

Tiger used to be somewhat more non-chalant about this issues. It would ignore all but the most egregious problems, unless the programmer or the user asked otherwise. Leopard seems to be more restrictive and demanding of Mac developers and the code they write. Again, not bad by any means, except for the unexpected and the change in behavior for things that used to work before.

So, with more testing and better debugging (so why can’t I get “debug” suffix to work?!), we’ll hopefully see this occur less often in Mori’s code.

Now…back to that checklist.

Ever since I decided to treat my blog more like Twitter, and just write micro-events rather than an entire epistle, writing either has come to a virtual standstill. (Except of course for the firestorm that has been Mori v1.6.4, v.1.6.5, and v.1.6.6 which is now undergoing 3rd party testing and I’m still trying to squash that “freezes while writing in Leopard” bug.)

Option-clicking the ‘Run’ icon in Xcode3 causes Mori to execute, then gdb starts up and attaches to Mori’s process, then Mori quits. Huh?

As if that weren’t enough, everytime gdb starts up, it spews out a lot of warnings about object files it can’t find. Like so,

warning: Could not find object file “/BinaryCache/Libsystem/Libsystem-111~176/Root/usr/local/lib/system/libc_debug.a(errno.o)” - no debug information available for “/SourceCache/Libc/Libc-498/sys/errno.c”.

warning: Could not find object file “/usr/local/lib/system/libcommonCrypto_debug.a(md2_dgst.o)” - no debug information available for “/SourceCache/CommonCrypto/CommonCrypto-32207/Source/Digest/md2_dgst.c”.

warning: Could not find object file “/usr/local/lib/system/libcommonCrypto_debug.a(md4_dgst.o)” - no debug information available for “/SourceCache/CommonCrypto/CommonCrypto-32207/Source/Digest/md4_dgst.c”.

warning: Could not find object file “/usr/local/lib/system/libcommonCrypto_debug.a(md5_dgst.o)” - no debug information available for “/SourceCache/CommonCrypto/CommonCrypto-32207/Source/Digest/md5_dgst.c”.

warning: Could not find object file “/usr/local/lib/system/libinfo_debug.a(gethnamaddr.o)” - no debug information available for “gethnamaddr.c”.

warning: Could not find object file “/var/tmp/Libm/Libm-287.1~6/Libm.build/Libm_debug.a.build/Objects-normal/ppc/scalb.o” - no debug information available for “/SourceCache/Libm/Libm-287.1/Source/PowerPC/scalb.c”.

What kind of railroad are we running here?

Anyway, at this point I’m planning on changing the file format after v1.7 ships. It’s just making it too tough to do some fixes. Mori still won’t require Leopard for some time yet, but I have to make my job, and putting out updates, somewhat simpler.

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.

Mori v1.6.4 has just been released, and the week that just ended leads into yet another.

The Leopard “lockup” bug where the note’s text doesn’t update (even though the user can continue entering text) has been corrected. The remaining issue I am aware of on Leopard is the faulty highlighting of misspelled words. I’ll be doing development in Leopard in hopes the improved development tools will help catch/correct bugs present in Tiger and any other Leopard-related issues manifest themselves.

The other things in this release I’ll mention here are there are bugfixes like the toolbar icons bugfix (For real, this time. I hope.) and some features targetted for Oneill has been folded into this release.

The biggest feature, which was one of those secret features I was reserving, is internationalization is now present in Mori. Sure, you could write and edit text in whatever language is supported by Tiger, but now Mori itself will be able to give you its UI in the language of your choice. As long as that choice is Spanish. Unfortunately, it’s the only localization that was finished and checked to make this cut. Because Drupal’s Project modules doesn’t allow nested comments (I think), I’ll be posting the text for the files to the forum with a separate topic for each individual localization needed. This way, native speakers in each language can correct and comment on each file separately.

I had more I was going to say, but in between the time I started that paragraph and now I had discovered 1.6.4 still had toolbar issues; written a newer, updated version; released it as 1.6.5; took a quick nap; and posted an article in the forum regarding the nature of the toolbar problems and the mechanics of the current system. Now to add a “delete old settings” to the mix and find the Leopard incompatibilities so I can ship 1.6.6.

Then I hope I can get back to doing a couple of other urgent new things.