Why ROR?

Rails
1

Can you share your thoughts on Why ROR for the web application
development?

The scaffolding is not effective enough. I think we cannot give high
weightage for this. There are other advantages like active record model,
in built testing framework and migration framework. But, I don’t find
clear answers on Why ROR?
Please provide the straight forward answers.

2

Ayyanar from Aspire Systems wrote:

Can you share your thoughts on Why ROR for the web application
development?

The scaffolding is not effective enough. I think we cannot give high
weightage for this. There are other advantages like active record model,
in built testing framework and migration framework. But, I don’t find
clear answers on Why ROR?
Please provide the straight forward answers.

As I stated in another forum, someone programing in RoR can complete the
same application as three or four other people using another framework
but in half the time. Even providing security measure for my apps has
been a breeze. Also the fact that interaction with the DB is so simple
makes my job a lot easier.

3

Second to Shandy.

RoR is fun to work in and produces great results in a matter of hours.

If one is building a database-driven web application, it’s hard to
beat. Wake up, lay out an app, build it, test it, have lunch. :slight_smile:

As for scaffolding, I haven’t used it since doing Cookbook.

On Feb 12, 8:29 pm, Shandy N. [email protected]

4

On Feb 12, 2008, at 3:50 AM, Ayyanar from Aspire Systems wrote:

Can you share your thoughts on Why ROR for the web application
development?

The scaffolding is not effective enough. I think we cannot give high
weightage for this. There are other advantages like active record
model,
in built testing framework and migration framework. But, I don’t find
clear answers on Why ROR?
Please provide the straight forward answers.

Straight forward answer to Why is that “it depends” – it depends on
where you’re coming from and what problems you’re tring to solve. Why
I chose may be very different than why somone else chose, and
different from why you might choose it.

For people trained on Java, building “small-ish” sites/apps is
inefficient compared to Rails. So many Rails people gush about how
productive it is. Compared to similar frameworks in reflective,
dynamic languages, I would expect Rails tobe about the same (I find
it about the same as my own web framework). So the whole “4x and 10x
faster” business is very relative to your previous experience. It is
quick to develop with when you stick to the core things it was
designed for. When you have to deviate from that path, well, then
it’s about the same as anything else you have to do from scratch.

Rails is batteries included, but some assembly stil required. Rails
does have some nice things “in-the-box” such as testing, migrations,
integration with rake, your basic MVC system all ready to go, and
ActiveRecord. However, there is no built-in tools for user
authenication, multi-language interfaces, and if you’re building lots
of similar apps, Rails isn’t very modular (relatively awkward at
sharing share code between projects). However, there’s quite a few
plugins to fill in some of the blanks.

Rails is well-liked by a lot of today’s programming pop-icons from
the XP/Agile/Pragmatic crowd. This is because Ruby is a lot like
their first love SmallTalk, because Rails sought to embody a lot of
the XP/pragmatic philosophies right from the start, and because the
Ruby and Rails communities are pretty good about teaching good habits
(according to the XP/Pragmatic philosophies). So, if XP/agile and the
Pragmatic approach to things resonates with you, the you’ll find
Rails to be very fluid and at one with The Force.

Ruby. Pretty cool language. Though hampered by arcane, old-school
command names it’s relatively free of syntactic junk which makes for
fairly clear reading. I don’t get too whipped up about the DSL frenzy
that’s going on, but good object and variable naming along with
Ruby’s syntax does seem to make the code brief and readable compared
to other languages. I recently had some code done in 6 languages to
makes available as SDKs, and Ruby is generally very easy on the eyes.

However, Rails is relatively new, so some spit & polish are still
needed in some areas (production deployment is still awkward compared
to other systems), but the good news is that there’s a lot of energy
being put into making Ruby and Rails an equal player on the big stage.

Why should you choose Rails? Well, mostly because it a) does what you
need it to do, b) you appreciate the style and philosophies it
promotes, c) it is supported by a community of like-minded
developers, and d) you can find worthy people to work on projects
with/for you using it. If these things are all yes, then they’re good
reasons for choosing Rails.

–
def gw
writes_at ‘www.railsdev.ws’
end

5

Excellent answer. Can you suggest what kind of application/product ROR
best suits?

6

On Feb 12, 2008, at 9:03 PM, Ayyanar from Aspire Systems wrote:

Excellent answer. Can you suggest what kind of application/product ROR
best suits?

Anything that is web-pagey. Seriously, IMO Rails, and just about any
other thoughtfully designed framework that’s been around a while
regardless of style, is suitable for just about every type of web
site you’ve ever seen. It’s not a matter of being suitable, but
rather being productive. I’ve been involved with very data oriented
sites, brochure sites, and sites in between. I just don’t see a
difference relativeto suitability–it’s all pages and data retrieval.

IOW, purpose shouldn’t be part of the definition, but rather scope of
demand on the network and computation are probably good
considerations for determining if Rails is suitable.

I wouldn’t use Rails as the primary platform to calculate actuary
tables, but I’d use it to show the results.

I wouldn’t use Rails (or any web framework) as the primary UI for
accounting, but I’d use it to search for specfic details from the
accounting records.

I doubt I’d use Rails to create something like eBay (auctions require
some tight threading control I’m not sure Rails would be up to, but I
could be wrong), but I’d probably use Rails to do something like
Expedia (someday that refc will make sense :slight_smile:

Maybe one framework has some tools optimized for certain data
collections or UI experiences over another (Rails was an early player
in boxing Ajax functionality), and you could argue that framework is
“better for X type of sites” because it has some specific tools that
are productive for that, but really, I think you’ll find 3rd-party
solutions (plugins, modules, etc) will balance out what’s available
in total amongst the frameworks that have been around a while. Though
some will definitely be more elegant than others. Is one inelegant
wart tolerable in the light of the other benefits? Only you can
decide which warts are intolerable. (I avoided Ruby due to some
things that really annoyed me, but eventually I just forced myself to
get over it in order to take advantage of what was good about it).

Again, I think it comes down to style, philosophies, upward vs
downward trend in support/growth, and being within the middle 80% of
the bellcurve of mainstream web-type functionality.

–
def gw
writes_at ‘www.railsdev.ws’
end

7

As CTO at a previous startup, I had the chance for a direct comparison
of Ruby and Java. For several reasons, we built a web product in Java
first and released it. Eventually, our reasons for staying Java went
away, and I tried an experiment. My team volunteered to rewrite
everything in Ruby while maintaining the Java site. There were no
changes to the model, and the feature set was the same. In fact, the
Ruby version ended up with a few additional features, but my rule was
a direct port to start with. Some things we found:

  • The Ruby code base was about 2/5 the size of the Java code base.
  • We built it 5x faster. This one isn’t fair though because I had a
    hard rule that no feature changes could be made. The goal was that
    the end-user had no idea anything changed.
  • The dev team was a whole lot happier not dealing with all the extra
    “stuff” you have to deal with in a Java, Hibernate, and Spring app.
  • What a surprise. Ruby executes a whole lot slower than Java.

Since we used Scrum to track projects, it was pretty easy to compare
our velocities. After a couple of sprints, the dev team’s velocity
improved by close to 40%. I expected some gains, but close to 40% was
beyond expectations.

If you have a well-architected web application, I see no reason not to
use Ruby. You may need a few more CPUs to scale well, but that cost is
nothing compared to the development savings. The key is “well-
architected.” You can develop junk in any language or framework.

-Dave

On Feb 13, 2:02 am, Ayyanar from Aspire Systems <rails-mailing-

8

Hi Dave,

Thanks for your input. Just one big question. I believe, you used the
same database used by java in Ruby application, right? Did you face any
difficulties in using the existing database like primary key issue?

9

People say that we can reduce the 30% to 40% of the development cost if
you do the same application in other languages. Is it the fact?

10

On Feb 13, 2008, at 10:12 PM, Ayyanar Aswathaman wrote:

I believe, you used the
same database used by java in Ruby application, right? Did you face
any
difficulties in using the existing database like primary key issue?

I’ve had no issuse with legacy database schemas. I used conventions
quite different than Rails, but have managed to do things just fine
using that same db. Rails has ability to declare your differences.

– gw

11

We had no problems at all using our existing MySQL database. The
conventions used in the Java app were very close to what Ruby expects.
Even it is wasn’t, Rails makes it pretty easy to identify the primary
and foreign keys if necessary. Convention over configuration doesn’t
mean you can’t configure if you need to. That’s one of the beauties
of RoR – keep it simple unless you can’t.

On Feb 14, 1:12 am, Ayyanar Aswathaman <rails-mailing-l…@andreas-

12

Thanks for all your comments