Rails - Dec 2006 - why choose rails?

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 ?

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Truthfully?  Time to market for an application.  If you can build a 
reasonably functional application in 4 months....or a highly functional 
one in 1 month...which would you choose?

JSP = Steeper learning curve and many more issues.

PHP = got no clue man...never done it.

Ruby on Rails = Pretty simple learning curve, decent forums for 
information, mediocre documentation, decent examples books.


-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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...), i think it''s harder the TDD practice with a
web
language, isn''t it ?

Anyway, about the performance? how is better? rails, jsp or php? think 
to a site that maybe will used by a lot of people, can rails handle it? 
or maybe it will be slower than php/jsp (or maybe only php because with 
the jsp we''ve always the jvm)?

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

thanks :)
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?

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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?

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.
> -- 
>  Phlip
>  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!! 

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Phlip wrote:
> 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.)

Yes, sure, i always use SVN to commit every new feature :)
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?

-- 
Posted via http://www.ruby-forum.com/.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

cover wrote:
> Yes, sure, i always use SVN to commit every new feature :)
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...

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 2, 2006, at 3:29 PM, Phlip wrote:
> 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


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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?

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 2, 2006, at 11:20 PM, Phlip wrote:
> 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


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 2, 2006, at 11:18 PM, Faisal N Jawdat wrote:
>
> On Dec 2, 2006, at 11:20 PM, Phlip wrote:
>> 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".
>
http://piston.rubyforge.org/

works wonderfully.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 3, 2006, at 14:18 , Faisal N Jawdat wrote:
> 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".
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




--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

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...

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> 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.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---