diff options
Diffstat (limited to 'site/src/not_mongrel.page')
| -rw-r--r-- | site/src/not_mongrel.page | 97 |
1 files changed, 0 insertions, 97 deletions
diff --git a/site/src/not_mongrel.page b/site/src/not_mongrel.page deleted file mode 100644 index b7ff121..0000000 --- a/site/src/not_mongrel.page +++ /dev/null @@ -1,97 +0,0 @@ ---- -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. |