script/generate controller general

and I get:

uninitialized constant RubiGen

Gross - wtf could have caused that? I pop over to google, and after some digging, I found this post where Kevin D says:

All I had to do was uninstall sproutcore and the related executables (sc-build, sc-gen, sc-server, sproutcore).

Hmm…

sudo gem uninstall sproutcore

Boom - generator works again. I’m not sure why, nor do I care at this point. I’ll play with Sproutcore when it plays nice with the rest of my installed gems. In the meantime, with the attention that Sproutcore is getting after WWDC, I would imagine a lot of folks will encounter the same issue in the coming weeks, so I hope this helps somebody.

Update: Sproutcore pushed out a new patch on 6/18/08 that solves this and a few other issues.

I thought about deleting the other post, but I figure someone else is bound to get the same scare at some point, so I’m just going to update it and link it to here. Thanks goes out to Coda Hale for informing me of this odd behavior.

Over the following days, I was having connectivity issues, mostly with Mail.app in Leopard. (I still have Tiger on a machine too, and did not have those problems on that install) So when I was having a problem with Mail.app, I just popped on over to the webform, composed my emails there, and sent them off. That’s supposed to be the beauty of IMAP, after all, right? It’ll show up in my Sent Mail folder in Mail.app the next time it’s able to connect, so, not THAT big of a deal.

Turns out, it was a bigger deal than I had realized. Gmail likes to autosave a draft for you at some interval, so that you don’t lose a message. Seems reasonable. You can even work on a draft in the webform, and come back to it later in your desktop client, because, after all, that’s the POINT of IMAP. So, where am I going with all of this? Well, there appears to be a bug somewhere in this process, and I’m not sure where or what it is yet. I discovered today that EVERY time the gmail webform saved a draft of an email, that draft was actually being SENT. What’s worse, is Gmail uses AJAX for sending mail, which tends to leave a user somewhat uninformed of what’s going on on the server side of the job, and wondering if the mail they intended to send actually went through or not. I left it alone for about ten minutes the other night, while it was seemingly hanging, and when I came back, it had done nothing, so I clicked the send button a few times to get the damn thing to go. I wound up sending 19 duplicate emails to a guy that I don’t even know. How humiliating!

So, I don’t know if the problem is always on the Gmail side of this, or with Gmail and Mail.app in Leopard syncing up, but flooding people’s inboxes is bad bad bad. It’s even worse when they’re getting flooded with drafts. I deleted my Gmail account from Mail.app in Leopard, and am going to set it up again, to see if it continues to misbehave. It hadn’t connected for over an hour when I decided to just delete it, and I didn’t want to risk flooding the inboxes of any more unsuspecting strangers. I’ll post more when I know more, but in the meantime, if anyone stumbles across this post and is experiencing similar issues, I’d love to hear about them.

UPDATED! If you’re having this problem, fear not - it’s not really a big deal. Check the follow up to this post for an explanation and a solution.

Photography is the same way. You can go someplace where thousands have been before you, and bust out your camera, and take a picture, and no matter WHAT, your picture will NEVER look like another. The sun is different, or the sky is different, or the subject is different (as in moving water, etc). I am probably pointing out the obvious here, but still, it brings me joy to observe it.

I started screwing around with HDR for the first time today, and while HDR is capable of bringing amazing color to images, I found myself most impressed with what I was able to do with a black and white image…

I have a lot to learn, not only about photography, and post production too, but I can’t help but be ELATED with this shot.

applescript docs

So, I’ll start with how to run the thing, and then go into some details about configuring it for your particular setup. You should know though, that the script makes a few assumptions about your development environment:

• You’re on a Mac (duh)
• You’re gonna download the script (get it here)
• You use Quicksilver (if not, get it here, it’s free)
• You use TextMate (if not, get it here, there’s a free trial)
• You have a sane structure to your project directory, and keep them in ~/work (This is easily changed, if you wish)
• You like a terminal for your server, log, and console, and keep them all on the same display/desktop (again, you can change this)

Okay, with all of that out of the way, let’s get on with it. The way this baby works is simple. You invoke Quicksilver (usually ctrl + space) and hit . (the period key) to enter some text. Type out the FULL name of the folder of the app you want to start. Assuming you’re set up with the defaults above, your app called “codeFoo” would live in ~/work/codeFoo, and you would simply type codeFoo in the input field of quicksilver. Next you’ll hit tab to move to the action pane, and type dev or dev_r or something to that effect, to get Quicksilver to look up the script for you. (If you’re not already aware, quicksilver learns the stuff you use and like, and will eventually move that to the top of the list of actions, if it’s not already there. Just use the same string every time to get it.) Once you’ve got the script, hit return, and watch it go! It will fire up three shells for you, start a server, a console, tail the development log, and open your app in TextMate. Productivity bliss, I tell you!

So now that you’re frothing at the mouth to get started using this thing, you need to know how to install it. Again, simple. Just download the script, untar it, and stick it in ~/Library/Application Support/Quicksilver/Actions. If the Actions directory doesn’t exist yet, go ahead and create it now. I’ll wait… Done? Ok, sweet. Just restart Quicksilver (or rescan the catalog, but it seems that doesn’t always work) to pick up the changes, and you’re on your way!

Now, I know you’re anxious to get to work and all, and this script will work with the defaults, but you’ll likely want to do some customization of your own to make it fit your setup just right. To tweak it out, just open it up in the AppleScript Editor, and follow the instructions. You can control the placement of your terminals, change their sizes, change the directory it looks in for your rails apps, etc. If you want, you can even add some arguments to make your terminals different colors, but I didn’t include that in this release. (Just look at the dictionary for termial in the script editor) The default placement of the terminals assumes you are running dual displays, with the secondary to the left, running 1280×1024, and will drop all of your terminals there. If you don’t like that, or you don’t have a secondary display, you should either hit up craigslist, or change this before you use the script. (I haven’t tested it on just a single display to see where the terminals will go with the default settings.)

I had hoped to set this up so that you could navigate directly to the folder you wanted to act on, without having to type in the full name manually, but as of this writing, Quicksilver and AppleScript don’t get down like that, so the only thing we can access is the text you input. Hopefully, one day, in the not so distant future, we’ll have that capability. I’m also looking into what can be done with Spaces (the new, but somewhat sketchy multiple desktop feature in Leopard) via AppleScript, but for now, this stuff will all open on the same “desktop”, and I don’t know how to change it. So, for now, enjoy!