Keep your mongrels on a leash

We’re fans of Mac OS X over here, and a number of us have MacBooks or MacBook Pros on which we do our daily development work. And since we’re a Rails shop, we tend to keep around a few Mongrel processes on our local machines running hither and thither with our code. Normally, this would simply mean you keep Terminal.app open and have it running in there.

However, I’ve taken to using Visor as of late, with the modification to make it run transparently in the background (which I’ll get to in my next post). So, since I only have one terminal at any given time, and since (for this app, at least) I have to restart mongrel a lot to effect changes from the lib directory, I’d prefer to not give over my terminal simply for the ease of ctrl-c’ing my mongrel process.

Enter Dogtag, a Dashboard widget I made when I saw the announcement of Apple’s beta release of Dashcode. It runs, and keeps track of, one mongrel process. Give it an environment, a port, and your rails root, then click start. You can restart easily via the restart button. And since it’s nicely multi-instance aware, you can have a few running on different ports and keep track of them all.

It’s not terribly feature-packed, but that’s what dashboard widgets are for. I figure, if I wanted to tweak every setting, I’d make a real Cocoa app to do it. This was about a day’s work and is quite useful to me. I hope someone else finds it useful too.

The correct amount of planning

In a very general sense, there is no “right” amount of planning or organizing you can do prior to starting a project. However, by identifying what “too little” and “too much” are, you can hope to find something that works.

On the “too much” end of the spectrum:

• Speculating about situations that may or may not ever arise far down the road is usually a waste of time. Better to dig in and start creating.

• Drafting a 100 page design document that multiple parties sign off on is usually a waste of time. People are generally thinking of slightly different things when they read about functionality—over the course of a large document these differences add up.

On the “too little” end:

• Don’t just start work on a project without covering at least a few general questions. What’s the goal? How can it be accomplished? What might cause it to fail and how can we avoid those things? How will it make money?

• Avoid “hand waving” issues away. For example, if you don’t have widget X in place yet and the person building widget Y needs X before they can begin, don’t use “X is available” as an assumption in the project timeline. A lot of “hand waving” will lead to a group of people who can all claim to not be responsible for a failed project.