why choose rails?

cover wrote:

why i should choose rails instead of php or jsp ? (no flame, it's only a
curiosity...i wan't learn a web language, but i've to choose one). When
use rails, jsp or php ?

To write a web program, you must often write lots of code in several languages, running in several layers. To get anything done, for example, you must add a variable in SQL to your database, then add it again to your business layer, then add it again to your HTML. And nowadays you might add it _again_, to your Ajax!

Classical web frameworks are often "smart HTML", where you template your HTML and put logic inside <% %> tags, or similar. But the problem arises _what_ logic to put there. You don't want SQL statements, but that's usually the easiest thing to write. A web framework should make the easiest statements also the most logically correct ones.

Rails simplifies this using a powerful principle:

   Rails shortens the distance between any two points

If you need a variable in your SQL and your HTML, you just add it in those two places. Rails takes care of...

- migrating the database to the new schema
- upgrade the live data in that database (!)
- add the variable to all your data objects
- copy the variable from database into the
                   objects without _any_ SQL
- transport the variable into the HTML layer

So when you make a change, you typically tweak only a few locations, and this makes you feel like the distance between those layers is very short.

If you don't configure Rails, it will try to guess, and it will often guess correctly. All data tables should have a key called 'id', for example. You shouldn't want to use any other key name, but if you want to (or if you want _no_ key), you can still configure Rails to support this. And because Rails shortens the distances between two points, Rails itself can almost always express things once and only once. You don't need to write similar code in many different places just to get anything done. Classical web frameworks still often require that.

Oh, and Rails fully supports something called "Test Driven Development", which is a system to make most bugs disappear without any debugging. That's common in standalone applications these days, but extremely rare in web applications. Rails makes it easy the same way it makes good application designs easy:

- present the variable to the test cases for testing
- provide sample data in the variable for tests

This is just the tip of the ice-berg. These features make Rails extremely rapid to work with. The hardest of Rails development is often easier than the easiest of classical web development.

cover wrote:

Hi, thanks for your post... i know the test driven development (i
usually use it with other rules of the Xp process), is there some books
(or site) that explain the TDD with rails (like the book "TDD by
example", maybe...),

Read the thread "TDD killing my joy of Rails". It starts with "I've been working through the book /Beginning Ruby on Rails E-Commerce/ which is very heavy on Test Driven Development."

i think it's harder the TDD practice with a web
language, isn't it ?

Rails has the single biggest benefit over Brand X there - it was invented by TDD. Hence most tests simply extend a rich testing framework. You don't need to start from scratch.

cover wrote:

i've just bought that book, and....it's really good (obviously i havn't
read all of it, but some, random, pages)... but now i've another
question, i've seen that they use a lot of extra plugin, do you usually
use it or do you make by yourself all things?

Part of your Rails adventure will always be adding plugins. Add a
bunch to start (while they still mix-and-match well), and then
occassionally add more.

My current list:

acts_as_authenticated/ arts/ assert_select/ form_test_helper/
helper_test/ visualizemodels/

The Rails maintainers are correct not to add every one of those to the
core. Some you might want to do a different way, some are unstable and
experimental, and some not everyone should want.

cover wrote:

uhm...ok, but, for example,if you have to choose between develop the
entire search engine and ferret, what do you prefer? or globalize, or
other examples...
when do you choose to use a plugin and when to develop it by yourself?

You can audition a plugin and if you don't like it take it out.

Everything in Rails-land assumes you are using a version controller. (And Subversion would be nice, too..!

(Using a version controller is a Best Practice in all of software engineering. No program anywhere, over a few dozen lines, should be without one.)

So submit your version, audition the plugin, see if you like it, and if you don't then take it out. I suspect SVN lets you bulk-revert everything back to a checkpoint.

cover wrote:

...i've seen that they use a lot of extra plugin, do you usually
use it or do you make by yourself all things?

Another note: The best plugins are small, and enable you to do things. The most invasive plugin in my list was the authentication jigger. Nobody wants to rewrite that!

Don't think of plugins the way certain big flabby web frameworks use them - as complete sets of working pages that you drop in. Think of them as powerful tools to help you then write the features.

cover wrote:

Yes, sure, i always use SVN to commit every new feature :slight_smile:

Some folks who read this mailing list are graduating up from web programming...

The next week i'll setup the machine for the continuous integration with
rails, do you suggest me something about this? i've seen that there is
CIA and continuous builder, do you use it?
another utility i think i'll setup is the rcover, for the code
coverage...and, do you know maybe something like checkstyle (java) for
rails?

Continuous integration is for when you have more than one programmer. I just check things out on another server and test them every once in a while. So I haven't learned what the CI plugins do...

You can audition a plugin and if you don't like it take it out.

[...]

(Using a version controller is a Best Practice in all of software
engineering. No program anywhere, over a few dozen lines, should be without
one.)

That said, I've found svn to be a rather painful way of getting plugins. Specifically, if I need to update the plugin it's a bit of a mess. If I use externals then I get the updates for free, but if I want more manual control on what updates I do and do not accept I get to suffer again. Has anyone found a decent way of handling this, or should I look into writing something.

-faisal

Faisal N Jawdat wrote:

That said, I've found svn to be a rather painful way of getting
plugins.

These might be two different topics. I introduced SVN because I was introducing the concept of auditioning a plugin, then reverting your own code if you don't like it. The same as any other incremental testing cycle.

You might be discussing other people putting their plugins into SVN, so the plugin system can install from those repositories.

What's wrong with that?

Specifically, if I need to update the plugin it's a bit of
a mess. If I use externals then I get the updates for free, but if I
want more manual control on what updates I do and do not accept I get
to suffer again. Has anyone found a decent way of handling this, or
should I look into writing something.

I don't get it. What's externals?

You might be discussing other people putting their plugins into SVN, so the
plugin system can install from those repositories.

What's wrong with that?

they aren't the same problem (which is why i changed the subject line), but they are related (which is what got me thinking about this). you're bringing plugins into your vendor/plugin directory, and you're keeping that directory (along with the whole app) version controlled, so how do you update the plugins if there's an update (e.g. changes made to acts_as_authenticated to work with rails 1.2, with the start_form_tag and end_form_tag deprecations).

as i understand it, there are two ways to handle this: manually, or via externals. neither is particularly ideal.

I don't get it. What's externals?

svn externals:

http://svnbook.red-bean.com/en/1.0/ch07s03.html

externals have the advantage that you always get to track the latest version of the plugin. they have the disadvantage that you don't get a say in the matter. when you do things manually, the advantages and disadvantages are flipped.

i think what i'd really like is a plugin manager that i can run to find out if there are new versions of plugins, and automatically update them (as installed in vendor/plugin), but not something that automatically does it every time i "svn up".

-faisal

http://piston.rubyforge.org/

works wonderfully.

You can specify which revision you pull using svn:externals. For example, if I don't want to track Rails tip, but rather some arbitrary revision (say, 5553), I can use "rails -r5553 http://dev.rubyonrails.org/svn/rails/trunk". When I decide I want to try out a later version, I can either specify a new version explicitly or even remove the -rNNNN and again track Rails tip. It's worked well for me. Works fine for plugins, or any other code you're pulling using svn:externals.

Michael Glaesemann
grzm seespotcode net

Faisal N Jawdat wrote:

svn externals:

http://svnbook.red-bean.com/en/1.0/ch07s03.html

externals have the advantage that you always get to track the latest
version of the plugin. they have the disadvantage that you don't get
a say in the matter. when you do things manually, the advantages and
disadvantages are flipped.

So that's what that freaking thing is. Somebody caught a case of featuritis, huh?

And it does indeed confuse the two issues of installing plugins and versioning our _own_ source...

So that's what that freaking thing is. Somebody caught a case of featuritis,
huh?

And it does indeed confuse the two issues of installing plugins and
versioning our _own_ source...

It is not featuritis. Installing plugins and versioning are
inter-related. Check out Subversion Primer for Rails Projects :
http://blog.teksol.info/articles/2006/03/09/subversion-primer-for-rails-projects

Another good resource is the James Adams book on Plugins. It explains
how to install plugins if your project is already in Subversion.