Tag: doh

Mea Culpa… again.

Posted on by david

I’ve been using Super Duper! for, like, ever (and therein lies the root of my problem.)

I’ve been using SD! to backup my laptop to an external LaCie drive every night. I’ve been doing this since said laptop was an Aluminum G4. I’ve been doing this since the default partition scheme was “Apple Partition Map”. I’ve been doing this since before I got my MacBook Pro…

I’m sure you can see where this is going.

I took my MBP in for repair yesterday (finally got fed up with the thermal shutdown problem it’s always had). No problem I thought – the warm and fuzzy feeling that having a recent SD! backup gives you in full effect. I’ll just boot the new Mac Mini (Core 2 Duo) I bought for the living room off my backup and keep working until the MBP is back.

Uh, no.

Of course the Mac Mini wouldn’t boot from the backup drive (remember that old partition scheme?) OK, time to clone it to another drive… 3 hrs later and 96% of the way through the clone the destination drive dies. OK, try again, different drive, 2 1/2 hours later, the clone is complete (Yay!) but the clone is un-bootable (Boo!).

So, I re-installed Leopard on the destination drive and started to migrate from the backup… Estimated time to completion? ~5 hrs (at which point I gave up).

In case your are keeping track, that equates to an entire day wasted.

2 hrs later while shopping at the mall (and just around the corner from the Apple Store) my cell phone rings. It’s the Apple Store technician, my MBP is ready (Hooray for Pro Care!)

Lesson learned? Always. Test. Your. Backups. Warm and fuzzy feelings don’t actually mean your are safe. Trust, but verify.

D’oh!

Posted on by david

After installing Leopard on my MBP I noticed that Mail wouldn’t allow me to do “Entire Message” searches. The “Entire Message” button was greyed out.

I tried rebuilding all of my mailboxes in Mail and forcing an index by calling:

    mdimport ~/Library/Mail

Neither helped.

It turns out the MBP’s boot drive had somehow been added to the Spotlight Privacy list…

D’oh!

D2W: Wildcards beware!

Posted on by david

Don’t you just hate it when you outsmart yourself (and make your self feel stupid in the process)?

In Direct To Web it is possible to have wildcards in the rules and these are often used to automatically determine pageConfiguration values. For instance you might have a set of rules that look like this:

50 pageConfiguration like *Applicant* --> entity = "Applicant"
50 pageConfiguration like *Contact* --> entity = "Contact"
50 pageConfiguration like *Division* --> entity = "Division"

And another set of rules that looks like this:

50 pageConfiguration like Edit* --> task = "edit"
50 pageConfiguration like Inspect* --> task = "inspect"
50 pageConfiguration like List* --> task = "list"

So far so good. You get some nice pageConfigurations that kinda configure themselves wrapping your common tasks and model objects (ie: pageConfiguration EditApplicant -> task = ‘edit’ and entity = ‘Applicant’). But…

Add one more rule:

50 pageConfiguration like EditRelationship* --> task = "editRelationship"

And things get icky, now there is a conflict between Edit* or EditRelationship* so the rule engine goes with the first match… but not always, once in a blue moon it will do what you wanted it to do. Just enough to keep you thinking there’s something broken in your templates or EOModel. It can’t be the rules… “‘Cause, heck it worked a minute ago!”

I knew about this! I did! I ran into it with compound names in my EOs (ie: Contact, BigContact) but that didn’t stop me from wasting a ton of time on it anyway.

Oh, the fix is easy. Just take the second rule and give it a higher precedence:

55 pageConfiguration like EditRelationship* --> task = "editRelationship"

It’s the beating your head against a wall of your own making that is hard.