On 7/3/07, whiterabbit [email protected] wrote:
5.Allows you to deploy database changes within the code, so the other
1.Have a lot of rules about the database fields. Even though you can
overload it, if do It, you have to change the code in many places to
make it work. For example I normally use a Database graphic designer
that works perfect with Mysql standard tables and the id standard is
different from the ID standar name used by Rails. Does not support
standard table design, for example the tables shouldn’t have plural
names. It’s a long discussion between OO purist and DBAs. Also I found
many samples of the developer that showed not Normalized Tables
(duplicated fields) in order to make it work quicker I bet.
If you follow the conventions then yes everything is pretty easy. You
can
vary from the conventions but takes extra configuration. Pluralization
is
one of the things you can turn off if you don’t want to use it. It is
best
to choose your field names wisely up front since they will be used
through
out (there is no extra aliasing/mapping layer). You can normalize or
denormalize depending on your needs, Rails accommodates things nicely.
I
have not seen any db framework that does things as elegantly and easily
as
Rails and ActiveRecord.
Once you learn to use migrations you might just give up your db
designer, it
is very simple, cross platform, allows things to be upgraded and
downgraded
over time and is very easy to source control. You can easily go to any
version of the db with a simple command.
- It feels heavy, not so quick. I think is because it adds lots of
layers in order to make transparent the database use and some other
stuff.
It is a full stack framework so most everything you need is there,
making it
heavier for some things, but for any decent size app you’ll end up using
much of what is there over time. It has been plenty fast for my
applications, but there is also a variety of caching mechanisms to allow
it
to scale up greatly.
3.It is not easy to use an html editor like Dreamweaver. I normally
use Dreamweaver templates and Smarty, that allows you to design in GUI
without interfere in the code.
There is a plugin for Rails which I started called MasterView which
allows
you to work more in the fashion you mentioned. You can take a pure HTML
prototype, sprinkle in some tag attributes to make it live and continue
to
round-trip WYSIWYG edit the templates throughout the life cycle of the
project. It also leverages all the power of Rails layout, partials, and
helpers without giving up WYSIWYG editing.
Check out this video to see it in action:
http://masterview.org/media/html-to-live/screencast.html
This open source project is hosted on Rubyforge and the main website is
here
http://masterview.org/
4.If you change the database configuration, you need to restart the
server. I do not know how it works in a shared server.
In development mode, you would not have to restart the server, the db
config
is re-loaded on each request, but in production mode it is cached on
startup. Usually these sort of changes are done as a unit, you make
changes
to your tests, create migrations for your db, change your views and then
you
would want to deploy these things as a unit, rolling back if anything
failed
or tests didn’t work. Capistrano makes this whole process dead simple
and
can be done consistently across an array of servers.
Also it is fairly easy to trigger a graceful reload of the app using
mongrel
or fast cgi. With mongrel you can signal the apps to restart after they
finish what they are doing, so you can do this without taking site
offline
if you want to do a quick update.
5.The best editor is for Mac. The Windows´ one is based on Eclipse,
but as far as the test I made with the last version, not all the code-
complete options were implemented, which force you to remember many
things of the rails syntax and make it error-prone.
Many do like the Mac, but there are tons of Linux and Windows users as
well.
I prefer emacs myself, but Eclipse/RadRails is also a very popular (and
cross platform) choice. Tons of work is being done in the IDE
department,
most every vendor is working on their own versions. Code completion is
one
of the hot topics that many are working on and are in various stages of
development. However Rails is pretty straight forward and simple once
you
get into it, you really don’t need that code completion stuff as much as
you
do in other environments and frameworks. I wouldn’t develop Java without
a
fancy IDE helping me, but with Ruby and Rails I just don’t need it.
6.The debugger is not as user friendly as the PHP debugger (with Zend)
or Java debugger are. It remembers me the first version of gdb I used
for debugging c in Unix.
There are various ways to debug an app, I have even run my Rails app in
several of the IDE’s to have full debugging support in GUI environment,
but
you just don’t usually need this very often. The combination of things
being
simpler in Rails along with having good test suites to catch things at
unit
level, you just don’t end up needing debugging as much. It is there in
various forms if you need it, but you just don’t need it is often in my
experience.
7.I think is easier to find a PHP or Java servlet host provider.
I’d agree that it might be easier to find PHP provider (most any hosting
company provides that), but there are plenty of options out there (and
you
only need one at a time 
If you are wanting to write something that
should work in absolutely at every hosting company then PHP/Mysql is
your
best option, but personally I would think long and hard about that
requirement before I would give up the power and productivity of Rails.
Someone else mentioned that the convention of things helps when you
bring
others into the project, and I would whole heartedly agree. If you bring
additional developers into an existing PHP project or even a Java
project,
it may be quite a while for them to figure out where things are at and
to
become comfortable, but with Rails, most any good Rails developer can
sit
down with a project that followed the normal conventions and be
instantly at
home and ready to contribute. And the nice thing is that most of these
conventions do really make our lives simpler and easier if we follow
them
not only in terms of dealing with Rails, but even in terms of code
layout
and structure.
Hope that helps some! I would suggest that at some point you give Rails
a
try for a project, if not this one then another project. I think you’ll
be
happy you did. There is a reason Rails is the fastest growing web
application framework, and that wouldn’t be the case if there weren’t
significant advantages, because PHP, Java, and .Net were already
entrenched
in the market but now are being displaced rapidly.
Blessings,
Jeff
–
Jeff B., MasterView core team
Inspired Horizons Ruby on Rails Training and Consultancy
http://inspiredhorizons.com/