[typo] Deploying Ruby on Rails Applications (was: Re: Can't update feeds?)
damm at livid.dk
Wed Jul 16 07:04:19 EDT 2008
Which portion of the documentation needs to be revised? FastCGI?
Mongrel? I suppose someone can whip up some instructions on how to
make the config.ru for Passenger if need be. Typo is imo extremely
easy to deploy and get up in running in under 5 minutes. If your
having a problem deploying typo please elaborate and tell us what the
problem is with you deploying Typo so we can help you deploy it? I
can read over old e-mails however that does not always constitute the
current situation. Specifics are excellent, like are you using Apache
2.0? 2.2? 1.3? How are you attempting to deploy it via FastCGI?
As far as Phusion Passenger (http://www.modrails.com/) it's actually
if you look at their site they even have tested Typo with it (http://www.modrails.com/documentation.html
Ideally, one would like to use Swiftiply (Mongrel with some added
performance), but that's not here nor there.
In typo 4.1.1 (I won't reference a recent version because I don't have
one installed currently) there is typo/installer and inside there is
examples for apache13 apache20 (which works for 22) and lighttpd
(fastcgi). For the most part you should just have to Copy & Paste,
modify the small things and go.
But I will leave the question open here,
How can we help you deploy Typo? be as specific as possible.
On Jul 15, 2008, at 11:24 PM, Chet Farmer wrote:
> Look. I like Typo. I'm still trying to use it. But mails like this
> just tick me off. They provide no help to speak of while insisting
> there is no problem.
> Also, proofreading is a good idea.
> On Jul 15, 2008, at 10:22 PM, Scott Likens wrote:
>> To whomever it may concern,
> I reckon that would be me, among others.
>> I notice the common thread here. How to deploy typo?
> Why do you think that is?
> The choices are:
> a) Typo IS hard to deploy; or
> b) Typo isn't hard to deploy, but is poorly documented; or
> c) Typo isn't hard to deploy, and is well documented, but the
> documentation is hard to find; or
> d) The people posting this question are all idiots.
> Hint: It isn't (d), and (a), (b), and (c) are functionally identical.
>> There is many ways to deploy typo, the most common is
>> 1) FastCGI. (It's also the most murky confusing documentation imo,
>> I don't blame this on typo, I blame this on FastCGI Documentation
>> and the people who wrote it).
>> 2) Mongrel/Webrick
>> 3) Phusion Passenger (aka mod_rails?)
>> Now, there's no real difference with Mongrel/Webrick if you run
>> nginx or Apache or lighttpd. It works, it's well documented and
>> takes the most amount of memory (actually all of them really take
>> the same amount of memory, you just don't see the ruby process
>> hanging around using up 140megs of memory).
> Um, no. It is NOT well documented, or, if it is, those documents are
> not easy to find. They're not complete at Typosphere, and they're
> not apparent anywhere else I looked. I saw rote, by-the-numbers list
> dox, but nothing that explained why I was doing what it said to do,
> or what the rationale was behind Mongrel vs. mod_ruby, or anything
> an admin will want to know when making the choices that are part of
> an installation. If those docs exist and I somehow missed them, I
> will GLEEFULLY accept pointers.
>> Phusion Passenger... Excellent option, if you have a cheap
>> Dreamhost.com account that is going to be your easiest option,
>> documentation is decent and it's much easier to deploy.
> First I've heard of it. Maybe it's a great choice; I have no idea. I
> wish I'd known about it when I first started playing with Typo.
>> So there you have it, 3 basic methods to deploy your blog.
> You say this as though your post constitutes instructions. This is
> not the case.
>> If your coding Ruby on Rails chances are this is nothing new to
>> you, and you have no problem with it. But those who have come from
>> the "PHP Boat" (as we'll call it, a/k/a wordpress, etc) they just
>> untar files into a directory edit a few files, loadup their web
>> browser and bam. It works.
> Yup. Nice, too. This is, above perhaps all else, why a "bad"
> language (PHP) has earned such a dominant market position.
>> This is because the company behind PHP has spent a great deal of
>> time and money at making PHP the dominant language.
> Er, and PHP itself, or mod_php, or whatever, pretty much Just Works
> without installing half a dozen more components, proxies, etc. This
> ease of use took effort, it's true, but it also provides nontrivial
>> It doesn't make it better, or worse or anything. (It scales
>> horribly also for those of you who are talking about scaling).
> Actually, "easy to deploy" DOES earn an app significant points with
> pretty much any administrator I know. I consider that "better."
>> Let's say you grab a Perl based blog, what's your common problem?
>> Well mod_perl, perl with ithreads enabled. Yeah you can use it as
>> a cgi script and have it exec perl on each page/function. But
>> again, we'll go with it does not scale well. We have Python and
>> django, I know have not touched any of the django software really
>> so I won't go there.
> Do you have a point here?
>> So let's bust out some simple myths,
>> Rails is hard to deploy, FALSE. In fact Ruby on Rails Applications
>> are quite easy to deploy provided your hosting company gives you an
>> environment where it can deploy sanely.
> Is this a synonym for "provided your hoster does it for you?"
> Because I've installed Rails on several different *nixes over the
> years, and have *never* found it to be simple to get running in a
> production environment (i.e., ignoring quickie dev stacks like
>> This is something that DHH has commented on a few times; there is
>> no way to make the pain of deploying a Ruby on Rails app on a "bad/
>> cheap hosting server" go away. Is that the fault of Ruby on Rails?
>> or the company you chose to host with? I'll let you decide on that
> If "application stack A" installs quickly and cleanly, and
> "application stack DHH" doesn't, do I care? I'll let you decide on
> that one.
> Shared hosting does not equal bad hosting. It's totally appropriate
> for probably 85-95% of the blogs that exist. Being essentially
> incompatible with shared hosting environments is a bad move for
> Rails, and DHH saying otherwise doesn't make it so. Being hard to
> get running in a hosted environment makes Ruby on Rails less
> appealing, and therefore hurts Typo.
>> Rails does not scale, FALSE.
> I wager "scaling" matters to virtually zero Typo installations. It's
> too unfinished to support a high traffic blog.
> As for Rails itself, I don't care. It's not on my professional radar
> for several reasons. It might be someday.
>> Look at Twitter
>> and other Ruby on Rails based web apps. Anyone who tells you that
>> Ruby on Rails is not enterprise ready, lied to you. Ask for your
>> money back and tell them to get the heck out of your office.
> I smell a fanboy.
>> My single point of this post is that there is great documentation
>> (for the most part) on how to deploy Typo, or any other Rails app.
> Too bad you didn't see fit to provide links to any of it here.
>> I will freely admit that the last decent version of typo in my
>> personal opinion was typo 4.1.1. That whole Rails 2.0 version
>> really jaded me, and now Rails 2.1 is out. Makes me more jaded,
>> and is making me walk away from Rails as a viable option.
> Wow. Just wow. Now we get to the Typo portion of your post, and you
> tell me the current revision isn't as good as 4.1.1. This is really
>> I think the best thing I can say out of this, is if your having a
>> problem deploying Typo (or anything else) please file a bug, write
>> an email, give as much detail as you can. The more detail the
>> better, so the developers of typo can find and squash the bugs.
> This list is so low traffic as to be mistaken for dead. There's not
> much in terms of Typo discussion anywhere else I can find (the name
> collision with Typo3 doesn't help; I don't know whose fault that is).
>> Remember, if you don't raise your voice, you don't say this is
>> broken; you have failed the community. Just as much as you have
>> failed the community if you fix what is broken, without reporting
>> it and giving a patch so it can be addressed. Not everyone is a
>> developer, not everyone can program ruby on rails. But Frédéric
>> cannot fix a bug he is not aware of, nor can Piers.
> I don't anyone is likely, ever, to accuse me of suffering in
> silence. I've been clear from the get-go that, while I find Typo
> overly complex to install, I *got past that part* and that my main
> problems now are functionality and bugs with the system.
> Frederic has, of late, responded fairly quickly to some of my
> messages -- but Typo itself is still essentially broken on some
> serious points (editor support and feed updates come to mind).
> That's frustrating, and it's frustration that piles on top of the
> leftover annoyances associated with Typo's installation problems.
> I want to use Typo. I really do. I'm not a naive noob. But it's not
> perfect, and neither is Rails.
> ... the early dawn cracks out a carpet of diamond
> Across a cash crop car lot filled with twilight Coupe Devilles,
> Leaving the town in the keeping
> Of the one who is sweeping
> Up the ghosts of Saturday night...
> Tom Waits.
> Typo-list mailing list
> Typo-list at rubyforge.org
More information about the Typo-list