Abusive When Harried

I've determined that approximately 75-80% of all technical questions can be accurately answered with the response, "Because you are a dumbass."

Examples:

  • Q: Why isn't my computer working?
    A: Because you are a dumbass.
  • Q: Why did my computer freeze?
    A: Because you are a dumbass.
  • Q: Why can't I log in to the server (x)?
    A: Because you are a dumbass.
  • Q: Why can't my browser read the website (x)?
    A: Because you are a dumbass.
  • Q: Why can't I get online?
    A: Because you are a dumbass.
  • Q: Why can't I find my file (x)?
    A: Because you are a dumbass.
  • Q: Why is this piece of technology (x) so slow?
    A: Because you are an unbelievable dumbass.

Seriously folks, computers have become exceptionally reliable and predictable. If something's not working, well, frankly, it's probably your fault.

Now leave me alone. I have work to do.

Idiot.

Notes on Google Desktop

Google Desktop, the Google-made search utility for your computer, is finally out for the Mac. I've been playing around with it, putting it through its paces, and comparing it to Spotlight. Here's what I've found so far:

  1. Google Desktop is much, much faster at searching than Spotlight. Spotlight took nearly a full minute to search the term "test" on my computer (that's measured from the time I hit return in the search bar to the time the pinwheel stopped spinning). Google Desktop was nearly instantaneous at returning results. I found both sets of results about equally useful — or useless, depending on your perspective.


    Spotlight Search Results: Slow and Useless
    (click image for larger view)

  2. Google Desktop also returned fewer results than Spotlight. I'm not quite sure why this is so. My guess is that Google Desktop searches metadata and/or file contents differently than Spotlight. But who knows? I've often wondered how Spotlight determines what results get returned, and how relevancy is determined. It's mysteries like that that make these things perhaps less useful than they could be. I know how to optimize my web site for Google's internet search engine, at least to some extent, because how Google searches the web is not completely opaque to me. I do not know, however, how best to save my local data to optimize it for searching via Spotlight or Google Desktop. So my results tend to vary. The nice thing about Google Desktop, though, is that I at least don't have to wait 50 seconds to see my useless results returned. I get them instantly. Yee-haw.

    Google Desktop Search Results: Fast and Useless
    (click image for larger view)

  3. Spotlight stores its index files on a per drive basis, which is smart: index your drive on one machine, it's indexed everywhere. Spotlight's index files are also really small. Google Desktop, on the other hand, creates much bigger index files than Spotlight, and those index files are all stored on the root drive (in /Library/Google/Google\ Desktop/Index/). This is bad for two reasons. On the location side of things, if you move, say, a firewire drive to another computer with Google Desktop, that computer will have to re-index the drive, and that index will always be out of sync with the ones on other systems, causing Google Desktop to constantly index external drives. On the size end of the equation, since the Google Desktop index is entirely on the root drive and can get quite large, it is quite possible, given a large quantity of data and a relatively small root partition — like, say, on my system — for Google Desktop's index files to completely fill your hard drive and lock up your system. Yes. This did happen to me. Thank you for asking.
  4. Google Desktop also shows you other useful information right in the list of search results, which is nice. Info like the file path and a preview of the document's contents appear right there in the search window.

In terms of functionality, though, I like Google Desktop about as much as I like Spotlight, which is to say, not all that much. Mainly because I just don't get very useful results. There are some interesting features that Google Desktop offers in terms of Gmail integration that I've yet to try. These might add some appeal to the program. But as far as searching my local system goes, thus far even Google has yet to make a desktop application that rivals its internet search engine. Seems strange that searching local files is a harder nut to crack than searching the internet. But I guess it is after all.

UPDATE:
First off, I meant to mention that the initial indexing for Google Desktop took a very long time. I'm not sure how much because I ran it on my work machine and let it go all weekend long. Judging by the size of the index when I left the machine versus the final size, I'd guestimate it took roughly 24 hours. Very rough estimate. And bear in mind that I have probably around 1.5 to 2 terabytes of data.

Today I find that Google Desktop is hogging my CPU. I get a big performance hit whenever I'm doing large file writes to disk, which is understandable though hardly forgivable. Times like these the processor can hit near 120%. So, for instance, a file copy involving many files will cause my Quad G5 to bog down noticeably.


Google Desktop: Processor Hog
(click image for larger view)

In addition, since Google Desktop is apparently pretty damn slow about indexing, said file copy will cause Google Desktop to start indexing again, which makes its processor usage hover between about 50% and 90%. Google Desktop's indexing process is both slow — far slower than file copies — and processor intensive — to the point of making other apps run noticeably slower. I'm uninstalling it now. I have work to do.

That was fun while it lasted.

Google Gone Deaf?

So the other day I was searching the term "Risso's dolphins" on Google. Something I'd read had referenced them, and I was curious what they looked like. So I type "Risso's dolphins" into that ever-familiar Google search field, and this is what I get back:


Google Search: Do I Stutter?
(click image for larger view)

Uh, yeah. I did mean "Risso's dolphins." That's why I typed, "Risso's dolphins."

Seriously, Google, you're losin' it, man. Maybe you should see a doctor.

Scripts Part 7: Contextual Menus with Automator

Recently, for some odd reason, there has been a spate of solutions to the problem of creating new files in the Finder via a contextual menu. One involves a contextual menu plugin called NuFile. Another involves installing Big Cats Scripts and linking it to an Applescript. But honestly — and I'm surprised someone else didn't think of this first — when faced with simple contextual menu tasks, these days my first thought is to look to Automator.

And by golly, that's just what I did. Here are a few Automator workflows that do, more or less what the afore-linked methods do. To me, the advantage of the Automator approach is that you don't need to install anything. It's all baked in. Which means you don't ever need to update anything either. Nice. Simple. And, yeah, kind of the whole point of Automator.

So here you go. Maybe someone will find this useful, if for nothing other than as an exercise in creating contextual menu functionality with Automator. Or skinning a cat multiple ways. Or something. To use this, download the .zip file, unzip it and place it in:

~/Library/Workflows/Applications/Finder

NewTextFile Workflow

It should become active immediately.

Also, here are a couple variants. One will create a text file, and then open it in TextWrangler (if you have TextWrangler, and if you don't, go get it now); the other creates a Word document, and opens it in Word. I'm far to lazy to completely duplicate the functionality of NuFile. But if you examine these workflows, you can at least see now how that would be possible (in fact, fairly easy) to accomplish.

NewTextFile Workflow Variants

I actually think it would be great if Apple made it drop dead simple to create true contextual menus for the Finder. Fortunately, Automator gets us pretty close.

Oh, yeah, and since this is technically script writing, and since I haven't posted to that series in some time, we're gonna go ahead and call this a Script Sharing post. Deal with it.

Right. Good night.

UPDATE: Revised March 31, 2007, 3:00 PM

Stephan Cleaves has added yet another implementation of this idea. He's using a combination of Automator and AppleScript. I certainly think his implementation is better than mine in a few ways. Certainly more full-featured. It will prompt for a file name, for instance, and takes pains not to overwrite a preexisting file with the same name. Nice. But we're taking very different approaches to the same idea (his version places a file in the front-most Finder window, my version places it in the right-clicked folder), and he was confused by my approach. After speaking to him via comments on his blog, I realized that some clarification as to how my workflow is actually constructed might be in order.

Basically, my workflow takes the folder selected in the Finder as input and assigns that input to the variable "$@". That variable and the for loop in my workflow are automatically generated by Automator when you select “as arguments” from the “Pass input:” field in the “Do Shell Script” action. It’s how you get the context (the selected folder) passed to the script. Apparently Automator takes “$@” as the variable for “the folder you just selected” whenever there’s no input from a previous action. This was something I learned while fiddling around with all of this, and it's really my favorite part. The coolest thing for me here, really, was figuring out how to pass the context — i.e. the right-clicked folder — to an Automator "Do Shell Script" action. This opens up worlds of potential.

Finally, as I said, the for loop in the action is auto-generated by Automator. The workflow will work almost as well with the simple script:

touch “$@/NewText.txt”

Using the for loop, however, allows you to create a new text file in multiple folders by selecting said folders and running the workflow.

It's really kind of amazing how many ways there are to do this. Wow. Fun stuff.