Here are the facts:
All there of us have had Programmming Ruby, Agile Ruby on Rails books for a
few weeks or more. After trying to create simple applications we dropped a
proposal to do an intranet in Rails and created it in WebGUI instead. I hate
Perl but Rails was taking too much time.
> http://www.hiveminds.co.uk/node/3094
A bit of FUD in there about Rails:
> Rails also has many drawbacks in that it removes almost all of the
portability
> of Ruby"
How so? Ruby runs everywhere so Rails pretty much can too.
Rails on my PC has differences from what is in my web host and so the
application will not run without me tweaking it. We deployed a test app to
Dreamhost, Bluehost and HostPC. Of the three Bluehost worked without
problems but still required some changes. The other instances just did not
run.
Deploying a Rails application is complicated, time consuming task and just
not
> something that you will want to do on a repetative basis
Here is your deployment tool:
http://wiki.rubyonrails.com/rails/pages/Capistrano
We used switchtower.
Rails also is a lot of work if you just want to do a single webpage
application
> that contains everything.
Everything like what? I have found everything I need up to now. I've
even ripped out portions of my own code when I would find there is a
Ruby gem that provides what I need.
A simple single page guestbook is what we are testing. Rails was just too
much for something so simple.
Web hosting companies are also a large factor in using Rails. To do Rails
> properly you need to have ssh knowledge and be prepared to do some
> command line manipulation of files. The needs of Rails makes a shared
> hosting environment difficult to set up and administrate.
There are many hosting companies that are embracing Rails with open
arms. Here are your current options:
http://wiki.rubyonrails.com/rails/pages/RailsWebHosts
I use OCSSolutions.com. They have a nice setup, very smart folks
working there and very responsive service.
The problem is that they all hosters seem to have unseen differences that
clog the process. Each of the three we tried seem to have different versions
and packages of Ruby running. Apache was a problem. We run Apache 2 which
did not seem to be a problem a first but when things stopped working
everyone started pointing to the Apache servers first. Rails was just not
generic enough for us.
As far as using SSH, I'm not sure why you wouldn't want that. Clear
text FTP passwords are bad and most GUI FTP clients support SFTP at
this point.
SSH seemed to be needed to troubleshoot. Each time we contacted a support
desk we were asked to telnet into the server and do configuration changes.
One of the biggest Rails drawback for me and the reason that I decided to
go with
> eRuby is the that Rails was taking up all my time with Rails problems
and
> troubleshooting. I was learning a lot about using Rails but not much of
the
> Ruby programming language.
You might want to pick up a copy of Ruby for Rails:
http://www.manning.com/black/
To effectively use a framework you should probably know the language
it's built with, that's gonna be true for any web framework, not just
Rails.
Exactly our point. Since the end result should be a Ruby teaching
situation we found that Rails got in the way. Also students would need
two books (budgets you know) rather than one 
Also I truly dislike that acronym FUD. It is thrown about too often when
people are giving their experiences, outlook and opinion. None or us fear
Rails, are uncertain about its purpose nor doubt that its capabilities. We
just decided based on our own conferencing and experimentation not to go
with Rails this time and we gave our reasons why.
···
On 7/26/06, Greg Donald <gdonald@gmail.com> wrote:
On 7/26/06, tesla <tesla.nicoli@gmail.com> wrote:
--
Greg Donald
http://destiney.com/
