diff options
Diffstat (limited to 'site/src/not_mongrel.page')
-rw-r--r-- | site/src/not_mongrel.page | 97 |
1 files changed, 97 insertions, 0 deletions
diff --git a/site/src/not_mongrel.page b/site/src/not_mongrel.page new file mode 100644 index 0000000..b7ff121 --- /dev/null +++ b/site/src/not_mongrel.page @@ -0,0 +1,97 @@ +--- +title: Not Mongrel +inMenu: true +directoryName: Not Mongrel +--- + +h1. What Mongrel Isn't + +h2. Or, Write Your Own Damn Web Server + +Every once in a while I get someone who sends me an e-mail a lot like this: + + "Hey Zed! I got this great idea for Mongrel. All you have to do is + completely change the internal processing, add 200 more methods to the HTTP + parser, make it run on Solaris ZFS with AIX backends, serve Bittorrent over + Ethernet, and have it save Korean orphans while eating a Mango in the back + seat of an El Camino driven by twenty midget clowns. If you do that I'll be + rich! Uh, we'll be rich!" + +Mongrel is an HTTP server for Ruby applications. It does the bare minimum necessary to +serve a Ruby application. That's it. No more, no less. I fight off features all the +time until they're absolutely needed, and usually if someone needs it they can write +their own special GemPlugin and serve it up without even talking to me. Mongrel is +great that way and I love when people extend it for their own uses. + +Notice I said "I love it when people extend it for their own uses." I didn't say +any of the following: + +* "I love doing other people's dirty work so that they can make millions off the sweat on my back." +* "I am your whore, so sure I'll get right to writing that Bittorrent client." +* "I would love to be your corporate tool since I'm all about getting screwed." +* "Wow that idea is so brilliant I think I'll sign an NDA right away so you can take all my rights and all my work." + +If you have a feature that you think would be great for Mongrel, then go for it, but you +implement it first. I can give you advice, give you help, encouragement, meet you for +coffee at conferences and I'll even take reasonable patches if you find bugs and do come up +with nice little ideas. + +But don't send me monster patches that make your application work better and expect +it to get put into the Mongrel core within the hour. This is called "code fisting". + +h2. Code Fisting + +I worked with this guy once who walked into my office one day to tell me that +he had started reorganizing the code base for the product. Problem was he +started this completely useless reorganization two days before a big +deployment, checked it into the CVS repository without telling anyone, didn't +get it working at all, and then had to go on vacation that same day. He was in +my office to *tell* me to clean up his mess since his changes completely broke +the build. He did all of this without telling anyone or asking first. + +This is "code fisting", where you shove large amounts of code at people where +it isn't wanted. When you do this all you're doing is pissing off the people +you work with and costing your employer money. In an open source project it +can get you kicked out, ridiculed in public, and jeopardize your reputation. + +I find that people who do this seem to not understand the #1 rule about working +with others on a software project: + + "Whenever you do something make sure it causes the least amount of suffering + for others." + +Change is important and the project needs it to improve, but if you go +thrusting your nasty designs on other people in surprise Ninja moves then +you're not following the rule. + +So how do you reduce the suffering that comes from big changes? + +h2. Code Lube + +Code lube is the answer to *necessary* code fisting. Code lube is a +combination of communication, coordination, and gently applying your changes +slowly over time until they're in sync with the rest of the world. You have to +baby step the other participants and if they aren't receptive, then put your +stuff into a patch or a branch and come back to it later. + +This includes changes that aren't related to code. Deployments need to be +heavily coordinated. Moving servers, changing database schemas, installing new +versions of tools, and changing important documentation all require talking +with people. + + +h2. Contributing To Mongrel + +Hook everyone up with a bit of code lube. Talk with people on the project, +contribute something small and useful first. Don't just change all the +STDERR usage to $stderr so that you can get a nice printout for your unit +tests (especially when there's already a simpler existing way). Talk with +people first and see if they're receptive. + +If they're not receptive, take the Mongrel code and do it yourself. You never +know, maybe we're all stupid and you're brilliant. Since Mongrel is open source +and you've apparently got the free time, then grab the code and try out your +idea. If it turns out to be a great one *then* talk with people to get it +implemented. + +Otherwise, have fun with the project. |