Rails - Apr 2005 - Installing Ruby+Rails+MySQL/Ruby on a shared webhosting?

Hi!

Is this possible?
My webhosting (Linux, http://www.gauldong.net/phpinfo.php) actually
had a 1.8.0 Ruby, but it won''t be updated for some time, so my choice
would be to "install everything from scratch". Actually
that''s what I
did for PHP 5. I had to recompile (with little modification) PHP 5 and
run it as CGI with cgi-force-redirect to avoid attacks (I don''t want
to have #!''s on my PHP scripts, so I actually had to use the PHP
executable itself, how dangerous!)

I first tried to use Ruby CVS but it didn''t work. I''ll try to
see how
far I get with Ruby 1.8.2.
Note that everything (Ruby, Rails, Rubygems, etc.) is installed in my
own home directory (using --prefix option in most setup/build tasks).

What I currently don''t like is putting #! stuff in all my scripts...
Is there a way to avoid this, but still secure? The primary reason is
because I will develop the app using Windows then upload/synchronize
it to the Linux server. #! generally is tied to a specific server
configuration, even more if I use a local ruby installation.

What I''m afraid in developing with Ruby is stonewall bricks that
happens because Ruby [libraries] currently don''t support something.
For example, gd image library is nicely bundled with PHP. Ruby has
rmagick which doesn''t compile on my Windows configuration. PHP has
SimpleXML which makes reading/writing XML files [very] easy. And ruby
has (?). And that''s just for a start...

BTW I can''t modify any server (httpd.conf) configuration, all I have
access is .htaccess files. Any help/thoughts is greatly appreciated,
even more if someone is having the similar situation as mine...

-- 
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center

On 04/04/2005, at 3:47 AM, Hendy Irawan wrote:
> What I currently don''t like is putting #! stuff in all my
scripts...
> Is there a way to avoid this, but still secure? The primary reason is
> because I will develop the app using Windows then upload/synchronize
> it to the Linux server. #! generally is tied to a specific server
> configuration, even more if I use a local ruby installation.
Developing on a different platform than your target is less than ideal, 
and will only make your life harder (especially if you''re having to 
manage the packages on both platforms yourself).

I highly recommend trying out a linux distro for Rails development (all 
you need is emacs, firefox and a few terminals) or, of course, just buy 
a Mac  =)

- tim lucas

> On 04/04/2005, at 3:47 AM, Hendy Irawan wrote:
> > What I currently don''t like is putting #! stuff in all my
scripts...
> > Is there a way to avoid this, but still secure? The primary reason is
> > because I will develop the app using Windows then upload/synchronize
> > it to the Linux server. #! generally is tied to a specific server
> > configuration, even more if I use a local ruby installation.
> 
> Developing on a different platform than your target is less than ideal,
> and will only make your life harder (especially if you''re having
to
> manage the packages on both platforms yourself).
> 
> I highly recommend trying out a linux distro for Rails development (all
> you need is emacs, firefox and a few terminals) or, of course, just buy
> a Mac  =)
I develop in windows just fine.  Webrick works great for testing.  I
just check my files into subversion, export them on my host, copy over
some host-specific config/environment files, and restart my lighttpd
process.  The only time I have to mess with the shebang line is in the
dispatch.fcgi file, but I keep a copy of that on the host.

I can''t offer any advice on installing all that stuff on a shared
webhost.  It seems like it''d be easier to set this up on a host that
supports rails out of the box.

Even though my setup seems to work fine, my next laptop will most
likely be a mac :)

-- 
rick
http://techno-weenie.net

Tim Lucas wrote:
> On 04/04/2005, at 3:47 AM, Hendy Irawan wrote:
>
>> What I currently don''t like is putting #! stuff in all my
scripts...
>> Is there a way to avoid this, but still secure? The primary reason is
>> because I will develop the app using Windows then upload/synchronize
>> it to the Linux server. #! generally is tied to a specific server
>> configuration, even more if I use a local ruby installation.
>
>
> Developing on a different platform than your target is less than 
> ideal, and will only make your life harder (especially if you''re 
> having to manage the packages on both platforms yourself).
>
> I highly recommend trying out a linux distro for Rails development 
> (all you need is emacs, firefox and a few terminals) or, of course, 
> just buy a Mac  =)
>
> - tim lucas
>
Well tonight I experienced this first hand, as I uploaded my application 
to my "production" site which runs linux (I''m not live yet)
for the
first time. I develop on windows. Maybe when macs support PokerStars 
I''ll switch :)

Getting it running on my prod site was a bit of work, but due to the 
excellent error tracing provided it only took a few minutes to solve by 
myself. I certainly don''t think moving to a Linux development 
environment is easier than what I had to go through (I''ve run linux for
8 years, sometimes as my only OS although now its just in a VM that I 
find I rarely need to start up).  I had done a simple test on my site 
just using rails to generate a test app and have it connect to my 
PostgreSQL database, but had done all my real development locally in 
windows xp. I sort of figured I''d just ftp my rails directory up and it
would all work. I don''t have any webserver yet I just run WEBrick and 
with a proxied port mapping so its dead simple. On my hosting site 
(theinternetco.net) the shared Rails installation isn''t using gems. I 
found I needed to replace my environment.rb and dispatch.rb with ones 
generated on my actual site, since the dependencies are coded different 
if you don''t use gems. I also copied an online generate scripts/* into 
my app''s directory which solved some issue - I think just in the server
script but possibly others.

I don''t know that any of these issues are linux/windows or just
gems/not
gems but either way they were easy to fix. Overall the process was 
pretty painless and from now on I''ll just be uploading my app directory
or public subdirectories so I doubt I''ll even have to remember this. My
advice is develop in the platform that you are comfortable and 
productive on.

On 3-apr-05, at 19:47, Hendy Irawan wrote:
>
> What I''m afraid in developing with Ruby is stonewall bricks that
> happens because Ruby [libraries] currently don''t support
something.
> For example, gd image library is nicely bundled with PHP. Ruby has
> rmagick which doesn''t compile on my Windows configuration. PHP has
> SimpleXML which makes reading/writing XML files [very] easy. And ruby
> has (?). And that''s just for a start...
>
Ruby has REXML, which essentially gives you all what SimpleXML does in 
PHP (but without XSL). And it is native Ruby so it does not depend on 
libxml2.
It also has a GD module (it''s old and not maintained but it works), and
RMagick for Windows whouls be available as binary.

BTW, I think you will be able to run Rails on your host (if you can 
compile/install things yourself), but if I was you I would kindly ask 
the host to install FCGI for you. Otherwise Rails will just be too slow 
(even for 1 client).
--
Julian "Julik" Tarkhanov

On Apr 4, 2005 9:21 PM, Julian ''Julik'' Tarkhanov
<listbox-RY+snkucC20@public.gmane.org> wrote:
> It also has a GD module (it''s old and not maintained but it
works), and
> RMagick for Windows whouls be available as binary.
If Ruby is so wonderful why isn''t everyone maintaining their
"jobs"?
(even that it doesn''t give you any money, uh uh)
> BTW, I think you will be able to run Rails on your host (if you can
> compile/install things yourself), but if I was you I would kindly ask
> the host to install FCGI for you. Otherwise Rails will just be too slow
> (even for 1 client).
Yeah, that''s one wall I would have a hard time on. Reflecting the
entire database and all other startup stuff? Damn. Why doesn''t it
cache something or else... relying on FastCGI support for acceptable
performance is not something good for a framework (IMHO), no matter
what programming language you use to implement it...

-- 
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center

Hendy,

On 4.4.2005, at 17:36, Hendy Irawan wrote:
> On Apr 4, 2005 9:21 PM, Julian ''Julik'' Tarkhanov
<listbox-RY+snkucC20@public.gmane.org>
> wrote:
>> It also has a GD module (it''s old and not maintained but it
works),
>> and
>> RMagick for Windows whouls be available as binary.
> If Ruby is so wonderful why isn''t everyone maintaining their
"jobs"?
> (even that it doesn''t give you any money, uh uh)
>
>> BTW, I think you will be able to run Rails on your host (if you can
>> compile/install things yourself), but if I was you I would kindly ask
>> the host to install FCGI for you. Otherwise Rails will just be too 
>> slow
>> (even for 1 client).
> Yeah, that''s one wall I would have a hard time on. Reflecting the
> entire database and all other startup stuff? Damn. Why doesn''t it
> cache something or else... relying on FastCGI support for acceptable
> performance is not something good for a framework (IMHO), no matter
> what programming language you use to implement it...
You wont get good performance on plain CGI no matter what language you 
use. Period. That doesn''t mean a Rails app would be unusable on CGI, 
actually one of my sites was running on it a few weeks before I got it 
under lighttpd/fastcgi today. Needless to say, the speed improvement 
was noticeable but that really hasn''t got anything to do with ruby or 
rails, it''s just the nature of CGI.

You''re free to propose enhancements and provide patches to implement 
them. If you don''t know about some specific features, by all means ask.
There''s a lot of people willing to help but your tone is getting pretty
negative. I would suggest getting more familiar with a technology 
before starting to rant about its (imagined) shortcomings.  That said, 
Rails does support caching 
(http://rails.rubyonrails.com/classes/ActionController/Caching.html) 
and does not really depend on FastCGI (you can use mod_ruby or some of 
FastCGI alternatives), it''s just the most reliable, proven and easiest 
way to get Rails working really fast.

//jarkko

--
Jarkko Laine
http://jlaine.net
http://odesign.fi


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 4-apr-05, at 16:36, Hendy Irawan wrote:
> On Apr 4, 2005 9:21 PM, Julian ''Julik'' Tarkhanov
<listbox-RY+snkucC20@public.gmane.org>
> wrote:
>> It also has a GD module (it''s old and not maintained but it
works),
>> and
>> RMagick for Windows whouls be available as binary.
> If Ruby is so wonderful why isn''t everyone maintaining their
"jobs"?
> (even that it doesn''t give you any money, uh uh)
>
>> BTW, I think you will be able to run Rails on your host (if you can
>> compile/install things yourself), but if I was you I would kindly ask
>> the host to install FCGI for you. Otherwise Rails will just be too 
>> slow
>> (even for 1 client).
> Yeah, that''s one wall I would have a hard time on. Reflecting the
> entire database and all other startup stuff? Damn. Why doesn''t it
> cache something or else... relying on FastCGI support for acceptable
> performance is not something good for a framework (IMHO), no matter
> what programming language you use to implement it...
Moot point. Thousands of people run MovableType on plain CGI, and it 
also does a boatload of reflection and OR mapping. And it is painfully 
slow. And it runs much faster under mod_perl.

Relying on FastCGI is absolutely OK  even for PHP - for instance:
http://phplens.com/phpeverywhere/fastcgi-php

More than that - (I imagine) if you would use something like Rails 
under mod_php it would be much slower for the end-user (because all 
this reflection would have to be performed at request time).

Remember - "Rails is bad" and "My hosting/clients/whatever
don''t let me
run it" are two different things. Don''t mix.
--
Julian "Julik" Tarkhanov

For Julian, Jarkko, and everybody in rails list, I apologize if my
tone was getting rather negative about Rails/Ruby, I never meant it
that way. Ruby is an excellent language and Rails is the perfect
companion for web development.

On Apr 4, 2005 10:34 PM, Julian ''Julik'' Tarkhanov
<listbox-RY+snkucC20@public.gmane.org> wrote:
> Relying on FastCGI is absolutely OK  even for PHP - for instance:
> http://phplens.com/phpeverywhere/fastcgi-php
I wish I could... it''s not as if I didn''t want it.
> Remember - "Rails is bad" and "My hosting/clients/whatever
don''t let me
> run it" are two different things. Don''t mix.
I never said "Rails is bad". Rails is wonderful. It''s a
lightweight,
capable, easy-to-use framework that''s suited for most web application
projects. It''s just that the "you need to use FastCGI if not
it''s slow
even for 1 client" thingy that intimidated me.

While it''s true that CGI is [much] slower than FastCGI or other
alternatives like mod_*, I don''t want that to mean "don''t
use CGI
because it''s bad and slow". What I''d like would be to
tune the
application so that it''s acceptable even as a normal CGI, although
it''d be 100x faster under FastCGI.

My current PHP-based website (http://www.gauldong.net/) gets 120.000
hits per day, giving up 200 MB bandwidth daily, which is roughly 1.5
hits per second. Not that busy. Page generation is somewhere between
200 ms to 1000 ms, not very bad (duh!) considering the things it has
to do especially on the front page. The site is running a self-built
PHP 5.0.4, under pure CGI, and (guess what) no accelerators
(eAccelerator, the only accelerator for PHP 5 doesn''t support PHP in
CGI).

I use a custom framework which is a bit modular, which is both good
and bad as even simple things like the smiley processor and HTML
filter is kept out in a separate module and each has its own
(surprise!) XML information file. Imagine parsing all those numerous
XML files on every request! So it''s only natural that I implement
caching on that part and most of other parts...

Is there a guide on Rails on how to configure it so it''ll get maximum
performance under CGI? (caching, etc.)

(BTW, I read somewhere that changing the database schema required
restarting the webserver under which Rails is run, if not Rails won''t
recognize the new schema... is this true? If it is, it''s a bit weird
that doing so doesn''t require restarting the database server...)

-- 
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center

On Apr 5, 2005 3:45 PM, David Morton
<mortonda-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org>
wrote:
> Also, it is possible to control caching, whether per page, action, or
> fragment, and RoR steps aside *very* quickly when a page is cached.
How nice! :-D

Is it also possible to "cache Rails"? The caching which has been
described seemed to cache the output of the page, writes that to a
static HTML file, then serve that instead of processing the request
for the next N seconds/minutes?

What I expected was more like a framework caching functionality.... so
for example in the case of database reflection, it''d cache the
reflection''s result and use that for the subsequent requests, but
still processes requests normally (the caching is only to speed up
Rails startup after the first time). Is this available?

Note that I haven''t done anything else beyond "gem install
rails" and
reading the first pages of Programming Ruby. Ruby and Rails look very
interesting (as I have discovered many things they can do wonders to
that couldn''t be achieved--or can be achieved with much difficulty--
in other platforms) but I also want to discover its limitations and of
course, solutions to these limitations...

-- 
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center

On Apr 5, 2005 5:39 PM, David Morton
<mortonda-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org> wrote:
> | What I expected was more like a framework caching functionality.... so
> | for example in the case of database reflection, it''d cache the
> | reflection''s result and use that for the subsequent requests,
but
> | still processes requests normally (the caching is only to speed up
> | Rails startup after the first time). Is this available?
> 
> Oh yes. :)  look into fcgi and lighttpd.  I''m not sure about
caching the
> reflection... It might. Is that a difference between development and
> production environments?
Well actually that''s the whole problem came from. If only I can use
FastCGI (and other speedier alternatives than pure CGI) then I would
have used it. If my webhoster already provided me with a recent
Ruby+rubygems+rails+some things I didn''t even know I wanted then I
wouldn''t even have started this thread.

My development environment is anything I can dream of except that this
has to be Windows XP, not a Linux box or something. I''ve set up my PHP
web site in such a way that uploading the site is just a matter of
zipping it, uploading the zip, then unzipping the package in the
remote shell. Everything works, I don''t even have to
search-and-replace for some (sorry, no pun intended) stinking #!
stuff. I don''t have to even upload my database since the MDB library
I''m using does the rough work of updating the database schemas, etc.
I''m considering rsync to replace this method since it looks like a
much better alternative.

Anyways, I''m still questioning whether this kind of development cycle
(Win dev with Linux prod that has ruby and everything in my own home
directory) can also be applied [smoothly] with a Rails-based web app.
> | in other platforms) but I also want to discover its limitations and of
> | course, solutions to these limitations...
> I''m finding fewer and fewer limitations. ;)
This is the most serious limitation IMHO: DB API. True, PDO is even
only available in the upcoming PHP 5.1, but at least PHP already had
PEAR DB, MDB, adodb, Creole, not too mention other not-so-famous (like
Horde''s?) DB API''s but still actively maintained.

PHP also lacks "decent" PCRE support. The new Unicode character
classes that''s already in PCRE is not yet in the PHP distribution.
Does current Ruby''s regex implementation already support this?

-- 
Hendy Irawan - http://dev.gauldong.net - GaulDong Developer Center

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hendy Irawan wrote:

| Yeah, that''s one wall I would have a hard time on. Reflecting the
| entire database and all other startup stuff? Damn. Why doesn''t it
| cache something or else... relying on FastCGI support for acceptable
| performance is not something good for a framework (IMHO), no matter
| what programming language you use to implement it...

Actually, the reflection seems to have little negative impact on
performance, and in fact it seems to be faster than parsing XML schema
and stuff that other framewroks do.

The reason for needing fastcgi has to do simply with the time it takes
to compile all the framework code.  Imagine if J2EE had to compile the
entire framework for every request!   This is simply the same problem
that mod_perl solves with perl, and Application Servers for Java: keep
the framework in memory rather than reloading it on every request.

Also, it is possible to control caching, whether per page, action, or
fragment, and RoR steps aside *very* quickly when a page is cached.

If you haven''t read it already, look at the recent weblog article:
http://weblog.rubyonrails.com/archives/2005/04/04/justingehtland-is-back-with-numbers-to-back-it-up/

- --
David Morton
Maia Mailguard server side anti-spam/anti-virus solution:
http://www.maiamailguard.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUlATSIxC85HZHLMRApAoAJ0UHNho1lsKOndgdxbvgAhbbKvZkQCfVvQ2
SZe/bEuFoU2fzeyWQPcJelw=QFfp
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hendy Irawan wrote:
| On Apr 5, 2005 3:45 PM, David Morton
<mortonda-0/IDydmJJnNeoWH0uzbU5w@public.gmane.org> wrote:
|>Also, it is possible to control caching, whether per page, action, or
|>fragment, and RoR steps aside *very* quickly when a page is cached.
| How nice! :-D
|
| Is it also possible to "cache Rails"? The caching which has been
| described seemed to cache the output of the page, writes that to a
| static HTML file, then serve that instead of processing the request
| for the next N seconds/minutes?

This is very configurable - and sweepers can be set to flush the cache
however often you need.  As I read it, it may be possible to have
everything cached like this, but then sweep the cache as soon as a
change is made... (I haven''t tried this yet)


| What I expected was more like a framework caching functionality.... so
| for example in the case of database reflection, it''d cache the
| reflection''s result and use that for the subsequent requests, but
| still processes requests normally (the caching is only to speed up
| Rails startup after the first time). Is this available?

Oh yes. :)  look into fcgi and lighttpd.  I''m not sure about caching
the
reflection... It might. Is that a difference between development and
production environments?


| Note that I haven''t done anything else beyond "gem install
rails" and
| reading the first pages of Programming Ruby. Ruby and Rails look very
| interesting (as I have discovered many things they can do wonders to
| that couldn''t be achieved--or can be achieved with much difficulty--
| in other platforms) but I also want to discover its limitations and of
| course, solutions to these limitations...

I''m finding fewer and fewer limitations. ;)


- --
David Morton
Maia Mailguard server side anti-spam/anti-virus solution:
http://www.maiamailguard.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCUmrpSIxC85HZHLMRAgtUAJ0VPGiuguCTIYuRL+k0IBNcTByxFQCeIeGa
iHVtmFl8xEojodCRKU7sfZY=MSvT
-----END PGP SIGNATURE-----