1
0
Fork 0
mirror of https://github.com/puma/puma.git synced 2022-11-09 13:48:40 -05:00

New documentation.

git-svn-id: svn+ssh://rubyforge.org/var/svn/mongrel/trunk@244 19e92222-5c0b-0410-8929-a290d50e31e9
This commit is contained in:
zedshaw 2006-06-18 04:56:38 +00:00
parent cb6ad54564
commit e5c6b9ad70
2 changed files with 186 additions and 0 deletions

View file

@ -0,0 +1,89 @@
---
title: Adoption
inMenu: true
directoryName: Adoption
ordering: 4
---
h1. Adoption of Mongrel
A collection of people who've adopted Mongrel as their deployment
or development server of choice. If you have a success story, post
it to the "mailing list":http://rubyforge.org/mailman/listinfo/mongrel-users
telling people about it. The site doesn't have to be public, just tell
us how Mongrel made your life easier and what you like about it.
h2. Alison Rowland
"After months of tearing my hair out due to a lack of reliable Rails
deployment solutions, I found Mongrel. Thanks to Mongrel's simplicity
and stability, my hair is growing back. My Rails apps love Mongrel,
too, because it never lets them down."
* "Gallery":http://gallery4222.alisonrowland.com
* "Blog":http://blog.alisonrowland.com
h2. Josh Harvey
We're currently running [our site]:"http://www.rashgash.com" on a Xeon 1300 Blade
server. I'm not even sure exactly what that is, but the getup has been
running without a hitch for over a month now. The site is powered by a
pack of 4 Mongrels (0.3.12.4) with mongrel_cluster 0.1.1 behind Pound
1.8.2. Lighttpd handles the static stuff.
We're only serving 1,000 pages a day at this point, and I haven't done
any brutal load testing, so all I can say is that the system was a cinch
to setup and works beautifully.
h2. "Jason Wong":http://www.jasonwong.org/ ("i5labs":http://www.i5labs.com/)
Jason uses Mongrel and Apache on several sites:
* "Epson Developers":http://www.epsondevelopers.com/
* "Helium Report":http://www.heliumreport.com/
h2. Matt Pelletier ("EastMedia Group, Inc.":http://www.eastmedia.com/)
Matt uses Mongrel on nearly everything including the recent
"VeriSign PIP Project":http://pip.verisignlabs.com/ project.
h2. Ruby On Rails
Dan Peterson and friends managed to convert the whole "RubyOnRails":http://www.rubyonrails.org/
to Apache and Mongrel.
h2. Josh Goebel
His "Pastie":http://pastie.caboo.se/ uses Mongrel and it's a slick little paste site
with a nice IRC integrated bot.
h2. "MarkaBoo":http://www.markaboo.com/
MarkaBoo is a social bookmarking site that started as a prototype
and evolved into an open-source business model experiment. We are releasing the
code under Creative Commons license on Rubyforge and are allowing the community
to drive the features as we approach 1.0. Our only revenue stream is from
Adsense (and sadly it will be a while before it covers expenses). MarkaBoo lets
you treat URLs, files, and content you create uniformly. So you could bookmark
a PDF, a website, and a snippet of code and access them all uniformly. We even
let you bookmark via email and mobile phone.
"MarkaBoo Rubyforge Project":http://markaboo.rubyforge.org/
h3. Honorable Mentions
* Fear of Fish says: "Fear of Fish isn't using it yet, but he will do when his current large project goes live." He likes third person.
* Wilson Bilkovich (Defiler) says: " Can I get on there saying that the web was a hollow lie before Mongrel was released?" No, that quote is full of lies.
h1. Actually Adopting A Mongrel
If you're thinking of getting dog, consider adopting a real Mongrel
instead.
* Rescue a racing dog from "Greyhound Connection":http://www.greyhoundconnection.com/
* Adopt a homeless buddy from "The Humane Society":http://www.hsus.org/
* I judge people by how they treat beings weaker than themselves, and the "SPCA":http://www.aspca.org/site/PageServer are good people.

View file

@ -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.