Re: Deploying Ruby on Rails Applications (was: Re: Can't update feeds?)

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

> 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 Locomotive).

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

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

HAHAHAHAHAHAHAHAHAHAHA!

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

Not.

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

Chet
~~~
... 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.