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

Scott Likens damm at livid.dk
Wed Jul 16 20:12:49 EDT 2008

On Jul 16, 2008, at 3:47 PM, Chet Farmer wrote:

>> We are comparing an Apple to a Pear, LAMP is not the same as LAMR  
>> or a Ruby on Rails install.  Please stop comparing it, you are  
>> doing nothing useful by doing that.
> Are you really saying you can't compare a Ruby app with a LAMP app?  
> That's ridiculous. How else can someone decide between Typo and MT  
> and WP and etc?
> No, you're just wrong. It makes PERFECT sense to compare the  
> experience of setting up and using Application X with that of using  
> Application Y if both X and Y are competitors in the same market  
> (i.e., blogging software).

As I said above, you are doing nothing useful in this argument.  Stop  
it.  If you care that much passionately, then run Wordpress.  The  
argument is self defeating, because you are comparing apples to  
pears.  You can try this argument on a Django list and see how far you  

>> What is mongrel? Let's see here if this quote satisfy's you.
>> "Mongrel is a small library that provides a very fast HTTP 1.1  
>> server for Ruby web applications. It is not particular to any  
>> framework, and is intended to be just enough to get a web  
>> application running behind a more complete and robust web server.
>> What makes Mongrel so fast is the careful use of an Ragel extension  
>> to provide fast, accurate HTTP 1.1 protocol parsing. This makes the  
>> server scream without too many portability issues.
>> See mongrel.rubyforge.org for more information. "
>> A bit technical, but Mongrel is a Web Server.  Like Apache, or  
>> nginx or lighttpd.  Except that all it cares about and knows about  
>> is the application in which it is running.  Technically you can run  
>> it on port 80 (if you run it as root) and remove the whole extra  
>> web server from the equation.  Mongrel is for Ruby what mod_php is  
>> for Rails (bad analogy).  It does all the dirty work and forwards  
>> the end product to Apache and then to the end-user.  You can  
>> compare it to Tomcat or Jetty I guess, however that's not here nor  
>> there.
> Why on earth would you need to run a second web server? That seems  
> like a really bad idea, frankly, hence my annoyance that the most  
> obvious question (which boils down to "WTF?", essentially)  isn't  
> addressed.

Then I suggest you to take that torch up with the Mongrel Mailing list  
and ask them.

>> Frédéric has pretty much gone into the other problems you addressed.
>> However, the best method of updating/upgrading typo depends on the  
>> backend.
>> Let's say you use SQLite3
>> 1) backup your databases in db/ to a separate location
>> 2) unarchive the new version of typo in a separate directory (for  
>> staging or testing purposes).
>> 3) copy the backed up databases (do not move them, we want to keep  
>> a pristine copy still somewhere) to db/
>> 4) verify you are using the proper environment (e.g. PRODUCTION /  
>> DEVELOPMENT ...) and then run rake db:migrate
> What does rake do in this context?


To Quote from http://wiki.rubyonrails.org/rails/pages/UnderstandingMigrations

"ActiveRecordMigration allows you to use Ruby to define changes to  
your database schema, making it possible to use a version control  
system to keep things synchronized with the actual code.
This has many uses, including:

     * Teams of developers – if one person makes a schema change, the  
other developers just need to update, and run “rake db:migrate”.
     * Production servers – run “rake db:migrate” when you roll out a  
new release to bring the database up to date as well.
     * Multiple machines – if you develop on both a desktop and a  
laptop, or in more than one location, migrations can help you keep  
them all synchronized."

In essence, your database has a 'version' number in it, and if someone  
adds a new model, or changes a model a migration is also made.  So  
that you can run 'rake db:migrate' to ensure your database is "up to  
date" and able to do what the new version intends to do.

>> 5) start typo on a different port then the original typo is running  
>> on.
>> 6) Browse to the site by ip:port and verify if everything worked as  
>> planned, and if it did not discuss how it did not work properly,  
>> and if it did work how it can work easier.
>> Of course you'll have to reinstall your plugins and themes.
> !!!!
> To put it mildly, that's a bit bizarre and very unfriendly to the  
> user.

With the exception of plugins and themes, I find the upgrade process  
very relaxing and totally capable.  Very straight forward, and easy to  
do.  You can stage an upgrade painlessly and if there's a problem you  
have not affected your actual blog in any way what so ever.

>> I believe as a standard practice
> Maybe for Typo. Not for anything else I use.

Remind me not to hire you as a Systems Administrator.  You should  
ALWAYS make a backup, upgrade in a an test environment and verify  
everything  happened properly before you roll out the new version.   
Now I realize that isn't as "Cowboy" as say Wordpress, where you just  
slap in the new version and it might upgrade your database and off you  
go.  But when things FAIL and they always do (see Murphy's Law) it's  
better to have a backup on hand, and be able to recover from it.  Then  
fall flat on your ass and then resort to emailing someone saying "WTF  

Not to mention that is part of the Sarbanes-Oxley Compliance Matrix (http://www.crcdataprotection.com/solutions/sox_compliance.asp 

It's always a good idea to have a backup handy, and there is a  
wonderful list of things you have to do "to be Fully Sox- 
Compliant" ... I only mention this because some of these should be a  
daily business practice for some people.  It would make their life  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/typo-list/attachments/20080716/dc25e462/attachment-0001.html>

More information about the Typo-list mailing list