Weekly Edition
Return to the Press pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks)
IBM developerWorks looks
at Ruby on Rails from a Java perspective. "Ruby on Rails seems
to be a lightning rod for controversy. At the heart of most of the
controversy lies amazing productivity claims. Crossing Borders author Bruce
Tate has come to understand that Rails isn't a better hammer; it's a
different kind of tool. This article explores the compromises and design
decisions that went into making Rails so productive within its niche. Then
it looks at Rails-inspired ideas that should get more attention within the
Java community."
(Log in to post comments)
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 16, 2006 21:45 UTC (Mon) by ajross (subscriber, #4563) [Link] Maybe I can troll an explanation from someone: what's the deal with rails? I've never done any significant Ruby work, but I've read tutorials here and there. They all look cool (albeit mildly inscrutable) at the beginning, as the database schema appears "magically" from the data used to describe the page. But then the tutorial starts adding features, and as that happens the magic starts disappearing. The queries become fancier and need to be done in SQL, the magic code generators start being replaced with more conventional "PHP-like" template code in the pages, etc... The end result doesn't look, to my eyes, any different from a PHP or Mason application. Add to that the fact that Rails engine requires (I think) that it be the web server and won't run as an Apache module and it starts to seem kinda awkward. What gives? This seems to me like another situation where a cool toy has "optimized" the wrong part of the problem (initial site setup) and complicated the hard parts (long term maintenance and code evolution).
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 16, 2006 22:42 UTC (Mon) by k8to (subscriber, #15413) [Link] Without real rails experience, I'm going to guess.
Often, a tool that makes the simple cases magically simple is still worth it, because a good chunk of your web application consists of simple cases, while some portion is the fiddly bits you care about. Making the unimportant parts automatic can be a huge win, even if it doesn't seem impressive.
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 16, 2006 23:07 UTC (Mon) by gravious (guest, #7662) [Link] I am only just starting down the ruby road but let me tell you what I have learnt thus far.
As the article explains (and as the tutorials on the Rails site show) there is quite a bit of magic because rails infers the field names and table names from the names you give stuff in the ruby code - as they say "convention over configuration". And that's nice. I mean id generally is your primary key, is it not?
You are wrong about the web server requirement. Rails ships with a default web server to get you going quickly Webrick (written in Ruby) but it requires just a one line change to tell it to use Apache or (to name an up and coming candidate) Mongrel.
PHP is cool. I love it - Ruby on Rails is new. You are right to be sceptical as to it's long term maintainability, I guess we'll find out in the long term :) From what I can see Rails seems to have hit a sweet spot - it is probably inadvisable to call it a toy. Also the fact that prototype.js seems to have grown out of Rails is kudos enough in some ways give the evilness of Javascript.
{okay I confess - any language that turns literals into full blown objects, has inspired a poignant guide to itself, that has come from Japan, and has spawned the most left-field database driven web application framework out there is going to get my attention... live and let live huh, there's room for us all :) }
to.each { |there| there.own }
Anthony
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 17, 2006 8:40 UTC (Tue) by tomsi (subscriber, #2306) [Link] The deal with rails is to speed up development of certain a type of applications: those applications are web based and needs a database.
It contains a nice object/database wrapper called ActiveRecord, it uses to MVC pattern to make sure that your model and display stays separate, and it uses templates for presentation.
It has a "convention over configuration" philosophy. By shunning configruation files and forcing a specific way of creating database tables and field names, you get an application that is more self-documenting and easier to maintain (as there is only one way of doing things).
If this fits with your way of working and the problem you are trying to solve, it is great. And quick.
It is definitely worth a try.
Tom.
Rails will run as a CGI or FastCGI apache module. Posted Oct 17, 2006 11:41 UTC (Tue) by hummassa (subscriber, #307) [Link] and the real deal is: starting is easy. with PHP or Mason, starting iskind of difficult, putting more things is more difficult. With ruby, starting is easy, putting more things becomes more difficult. That's it.
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 18, 2006 17:35 UTC (Wed) by rfunk (subscriber, #4054) [Link] Part of it is that Ruby is a much saner and more powerful language thanPHP. Part of it is that Rails encourages good web programming practices, while PHP seems to encourage bad practices at every turn. Part of it is that Rails makes the mundane tasks easy, letting you concentrate on the interesting and unusual parts. For small things our web dev shop still uses PHP, but all our large projects are now being done with Rails. We're still learning, but after working in Ruby/Rails for a while PHP is just too painful to deal with. Oh yeah, and we're currently deploying them on virtual hosts with Apache 1.3 and fastcgi. Eventually we'll probably replace the fastcgi part with Mongrel. Deployment is the biggest difficulty with Rails right now, though there are other issues that are symptomatic of a young project.
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 20, 2006 1:55 UTC (Fri) by kbob (subscriber, #1770) [Link] One more opinion...
Ruby is just another scripting language. It's cleaner than Perl5 or TCL, and grottier than Python. Not especially great and not particularly broken. Ruby on Rails would have worked just as well if it had been called Perl on Poles or Pythons on a Plane. (-:
Rails has two main technical strengths: a surprisingly clean, well-thought-out architecture, and aggressive use of defaults and conventions to keep you from having to write boilerplate code.
Rails also has better marketing than any other web framework, and was lucky enough to be in the right place at the right time. A bunch of Java refugees found it and noticed that it sucks a lot less than the EJB stack.
Last year, I gave a Rails talk at the local LUG, and I presented a CD librarian sample app. It was about 15 lines of code, but it was fully functional. I dropped in a ~100 line CSS file and it was fully functional *and* attractive. (Well, geeky-attractive. I'm no designer.)
When a tutorial starts adding features, it may be more about showing more of Rails than because that stuff is needed. I haven't had to drop into raw SQL yet, though it's nice to know I can.
Rails comes with its own minimal webserver which is great for development, but it also plugs into Apache and other web servers. It can even be configured as a CGI script which is nearly universal.
Rails is not perfect by any means. ActiveRecord (the database abstraction) gets flaky when you combine advanced features. The page templates are just as easy to abuse as PHP. (Rails discourages putting application logic in the templates, but bad programmers are incorrigible.)
IMHO, Rails is a good framework. It's not the Second Coming, and it's not snake oil.
Crossing borders: What's the secret sauce in Ruby on Rails? (developerWorks) Posted Oct 19, 2006 9:55 UTC (Thu) by Jaffa (subscriber, #4327) [Link] Grails is an interesting Java-based version of Rails using Groovy as the language rather than Ruby. Although it's not yet as mature as Rails it has some interesting advantages:
Groovy as a language is fairly mature and a nice hybrid of a "pure" dynamic language and Java syntax.
Javafied Ruby-On-Rails Posted Oct 30, 2006 1:19 UTC (Mon) by ldo (subscriber, #40946) [Link] > Code defines database rather than vice-versa Ack, please, no. I thought if there was one lesson we'd learnt in the last half-century of programming, it's that data structures are easier to understand than code structures. As Fred Brooks said about thirty years ago: "Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowcharts; they'll be obvious." (For "flowcharts" substitute "code"; back then flowcharts were commonly considered to be somehow easier to understand than actual code, which was nonsense.)
Java vs the rest Posted Oct 30, 2006 1:34 UTC (Mon) by ldo (subscriber, #40946) [Link] One easy-to-overlook aspect of the previous article, in particular, is that it does mention aspects of Rails that depend heavily on dynamic features of modern scripting languages (like Ruby and Python), that an older language like Java simply doesn't support. Things like being able to execute code during the definition of a class.
|
|||||||||||