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 ?
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
Redirecting... ← NOT a blog!!!
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.
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)?
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
Redirecting... ← NOT a blog!!!
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!!
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?
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?
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
Redirecting... ← NOT a blog!!!
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
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
Redirecting... ← NOT a blog!!!
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?
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
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
Redirecting... ← NOT a blog!!!
On Dec 2, 2006, at 11:18 PM, Faisal N Jawdat wrote:
this). you’re bringing plugins into your vendor/plugin directory,
svn externals:
update them (as installed in vendor/plugin), but not something that
automatically does it every time i “svn up”.
works wonderfully.
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
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 G.
grzm seespotcode net
Faisal N Jawdat wrote:
svn externals:
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
Redirecting... ← NOT a blog!!!
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 A.s book on Plugins. It explains
how to install plugins if your project is already in Subversion.