Ruby On Rails

Ruby On Rails is a framework for developing web applications at a quick but sustainable pace. It has various popular features including an automatic Object-Relational-Mapping class (and a small but complete meta-language for describing table relationships), components, powerful serialization tools, database management, "pretty" URLs without dependance on Apache+mod_rewrite, a framework for publishing web services via a meta-language (no more tedious SOAP templates!), templated and non-templated page generation, automatic generation of unit tests, powerful and intelligent multi-level caching, pre-database entry validation (alongside the in-database validation) and more. Despite this kitchen-sink list, the rails framework is small and relatively lightweight.

I had to edit a PHP application recently, REALLY REALLY simple app. Could have been done with 2 controllers, 2 models, and about 6 Views, probably taking under 100 lines of RubyLanguage. The application... was over 3,500 LOC (the PhpLanguage code only, no HTML), no joke. --RayMorgan? (reposted from the RubyOnRails mailing list w/o permission)

"The above statement seems ignorant of the thousands of lines of Rails code. The writer wrote 100 lines, Rails has many more. Rails ! better than PHP, just different." --BlackHat. See RailsVsPhp

RubyOnRails encourages a TestFirst mentality for web application design, and has numerous tools to make this task easier, including methods for providing "mocks", or mock database objects. It also supports DependencyInjection and development, test and production environments.

Rails has no compile-deploy cycle. Changes to the database or application code are immediately reflected in the web application. This helps encourage developers to keep view logic in the templates/builders and the controller logic in the controller, since there is no difference between the deployment of the templates/builders and the application code. This means that the development cycle of Rails is extremely fast. To help make it even faster, Rails comes pre-configured with a web-servlet that runs on a user port, meaning development can take place anywhere and then be moved to a more robust deployment environment.

The amount of "scaffolding" code required to get applications running is extremely minimal, and uses runtime reflection instead of ahead-of-time code generation, which keeps the code density very high throughout the lifecycle of a project using this framework. To this end, Rails boasts a complete lack of "descriptor" XML files or code annotations -- the framework simply figures it out from the code, and one overrides methods from the framework to change default behaviors.

Ruby On Rails homepage: http://www.rubyonrails.org/

Book: AgileWebDevelopmentWithRails

I recently went through the same decision making process when I was tasked with creating a complete rewrite and redesign of http://yakimaherald.com , for the newspaper I work for. The old site was written in PHP and I already have around 5 years of PHP experience. But I was very attracted to ruby on rails. I made a few smaller client projects with rails and have been very impressed. So after weighing my options I decided to go with ruby on rails. I've already written up the dev process quite thouroughly here :

http://permalink.gmane.org/gmane.comp.lang.ruby.rails/20637

I hope maybe that helps you get a little perspective on the scalabilty and stability of rails. Using ruby I was able to write this app in under 1500LOC in less than 4 months and I am the only developer here. The app gets around 50,000 hits a day right now and the server is not even breaking a sweat. I'm running it on a dual g5 Xserve and it averages out to using around 16% of one cpu right now at the most heavily trafficked time of the day. So I have no doubts about the scalability of ruby and rails. It uses the shared nothing method of scaling. So once I max out the current xserve, I can just add another and it will almost double my capabilities.

-- EzraZygmuntowicz? [reposted from news://comp.lang.ruby]

ruby on rails also allows developers to easily add pre-written code in the form of a plugin. This may be from a small validation or helper method to a whole login system. The "Rails Lodge plugin directory":http://www.railslodge.com has a detailed list on what is currently available.

And once you've warmed up on Rails, switch to SeasideFramework and really start rocking.

Troll aside, SeasideFramework is practically the only serious competition to Rails. And they are extremely close, in terms of features and abilities. Rails is slightly easier to deploy, SeasideFramework has more features. Neither has a huge advantage.

I don't agree. RoR has a built-in O/R mapping layer, which, for all I know is completely lacking in SeasideFramework. This works very tightly with the web publishing layer. This integration is, in my opinion, one of the main drivers of RoR's success. -- Dizan

Many people see the rails movie demos and assume that rails is strictly a CreateRetrieveUpdateDelete screen expedition tool, but this perception is false. The "scaffold" system that many demos use to get CreateRetrieveUpdateDelete screens up so quickly is merely a development tool, and is almost never included in any finished product. Instead, people use ERB (embedded ruby) templates or XML::Builder output. Rails supports nearly any operation that a web application programmer could wish for, and usually supports it better than competitors.

In its domain, RoR works outrageously well. We had a need to build some simple CreateRetrieveUpdateDelete tools for internal use, and the whole team baulked at using any of the mish-mash of bloated, XML infested web technologies (some home-grown) we have around for something so simple. RoR was suggested as one possibility, and after a week or two of desperately trying to find anything else that might do instead, eventually the job was done with it. These days we're hearing things at standup like "we started to task up [story] to do in Ruby, but then we realized that it would be easier to just do it, so we did" and "we started work on [story], but because we were using RoR we accidentally finished it", and "that RoR is like crack, what a hit of instant gratification"

Recently, Rails has been getting a lot of attention by mainstream developer press. While some people have been very critical of the hype surrounding it, many people feel that it is one of the Next Big Things in web development. DaveThomas has called Rails the KillerApp for RubyLanguage. Even Python gurus (including published authors) are migrating to RubyOnRails for web development.

Q:Are there anything about the Rails framework that made it so unique for RubyLanguage? For example, could Rails not achieve similar objectives if the only language available was PythonLanguage? And what stops it from being applied for a MicrosoftWindows based InternetInformationServer?

A: Part of the power of Rails is the programming techniques used to make it. These end up being the interactions that the webapp developer uses, so they're critical to the "feel" of the application. Few languages have the power to compete with Ruby in this area. With lisp-style interned symbols, real meta-programming facilities, dynamic introspection and binding, the unique singleton specializer (who's name is currently hotly debated, I like "eigenclass") and real first-class functions and real closures, Ruby is an extremely rich language to build this sort of framework in, and they leverage it heavily. Check out the magic of ActiveRecord in the tutorials. They implemented a meta-language for inter-table associations, and then they used the dynamic class extension to allow the ActiveRecords? to configure themselves to the current table spec.

Another key aspect of RubyOnRails that is difficult to reproduce for many languages like Java and C++ and C# is the 100% dynamic nature of it. This is why Rails can use RHTML templates without many of the pitfalls of common Java-html templates. There is no compile phase.

People are trying, though. PerlLanguage has Maypole (MaypoleFramework) - which predates Rails, but they want it to compete - and Catalyst (CatalystFramework). Python has Subway (CherryPy? plus new work). Java has Trails (c'mon guys, you need a better name). Quite frankly, none of them are even close to getting the functionality of Rails 0.8, and Rails is approaching 1.0 and has dozens of new features. Rails simply beat everyone to production quality and now grows at an absurdly fast rate. Between the language advantage and head start, my money is on Rails.

Q:Would you have better references than the "introduction resources" listed on the RubyOnRails website? It would be good to have references to review articles from people who do web development, but are not emotionally tied to the RubyLanguage.

A: Most people who get into Rails start talking like hype machines, so finding actual tutorial resources without this tone is hard. But there are a few conversion stories that people like:

A designer who now works on the Rails-based blog "Typo": http://www.encytemedia.com/article/12/azure-template-for-typo ( BrokenLink )
Someone who attended the O'Reilly talk on it: http://radar.oreilly.com/archives/2005/04/on_conferences.html
Even Python developers who are competitors to Rails know, they have a serious adversary. Check out DHH's quote from Jonathan LaCour?: http://www.loudthinking.com/arc/000432.html
The Rails lead developer addresses many valid criticisms of Rails: http://www.loudthinking.com/arc/000408.html
- Sidenote for this one, Rails' inheritance model is changing. They're trying to implement a model more like Hibernate, which is one of the final goals to hit before Rails goes 1.0.

A technorati search for blog links to http://www.rubyonrails.com should reveal some interesting discussions. People convert to Rails all the time.

Rails and Other Languages

What specifically keeps other languages from using the Rails framework? I keep hoping the language-specific-GUI era dies off forever.

Well, when any other language catches up with Ruby, maybe...;-) -- PhlIp

What specificaly does Ruby do for Rails that other languages cannot match? Anybody want to volunteer a code example?

The Ruby ObjectModel is really powerful. Here are some (fictional) RubyOnRails models:

  class Developer < ActiveRecord::Base
   has_and_belongs_to_many :projects
  end
  class Project < ActiveRecord::Base
   has_and_belongs_to_many :categories
  end
  class Category
  end

has_and_belongs_to_many is a class method defined in the parent class, the base class of the ObjectRelationalMapping layer. It extends the classes with instance methods ("Developer#projects" and "Project#categories") that map to associations in database tables, all runtime. Also, ActiveRecord automatically reflects on the schema, making columns available as methods. It does this by overriding Ruby's method_missing instance method of the Object class. While all this might be possible in other languages (possibly with some hacks), this powerful behaviour is quite normal in Ruby. See also RubyLanguage.

But that is basically a DataDictionary and ER model in class form. I've written such tools where one can override what the dictionary supplies for special cases. I haven't tried to use such much for Web apps because there are too few good TableBrowsers for Web stuff.

Hmmmm, GreencoddsTenthRuleOfProgramming? Also, some say that one limitation of PHP is that one can't redefine PHP classes at run-time, which Rails relies on for many addons. Perhaps another kind of structure should be used, such as associative arrays. I also felt that dynamic languages should merge associative arrays and OOP. They are too similar in dynamic languages to bother making distinct syntax.

{I'm curious about your statement, "... dynamic languages should merge associative arrays and OOP. They are too similar in dynamic languages to bother making distinct syntax." Could you expand on that? I'm not sure what you mean.}

MergingMapsAndObjects

Python can compete with code like the above. Here is the same basic example in DjangoProject, and using SQLAlchemy you could build metaclasses to do things like this very easily:

 class Category(models.Model):
    name = models.TextField?(maxlength=50) 
    # ... other fields here and in other models omitted

 class Project(models.Model):
    categories = models.ManyToManyField?(Category)

 class Developer(models.Model):
    projects = models.ManyToManyField?(Project)

Django doesn't dynamically reflect the physical DB schema to add attributes to model instances, but nothing in Python stops that, and you wouldn't want it really in Django, because the model is also used to define additional metadata about fields, such as validation etc, not to mention documentation. Python easily provides the metaprogramming facilities needed for this. (BTW, Django does come with database introspection tools to write the models for you if you've done the DB already, or DB generating tools if you start with Python code, the latter being ideal). I should also point out the Django and Turbogears would currently be considered Python competitors to Rails, not Subway as above. Django in particular is not playing 'catch up' to Ruby, having been developed and used in-house for a few years before being open sourced. -- LukePlant?

First you use simple things like has_many to glue Models together by their intent (_not_ by their SQL statements, though that's also easy). Then, within a few keystrokes, you can download powerful plugins to do extra things.

For example, if you plug in the module acts_as_state, your Model gets a basic ShlaerMellorMethod ObjectLifecycles?-style state table, complete with a transition grid ready for you to populate with events and their callbacks.

A critique of R&R. It basically says that it will not "catch on" for the same reason that Lisp and Smalltalk never did: heavy dependence on esoteric ideas and meta programming:

http://www.beust.com/weblog/archives/000382.html

Perhaps it's a form of LispIsTooPowerful.

Ruby only uses esoteric MetaProgramming for framework construction, enabling very straightforward application-specific code. You don't need the esoteria if you don't want it. For example:

  def self.authenticate(login, pass)
    return find_by_login_and_password(login, sha1(pass))
  end

That should be too simple to require any explanation; it's the same old procedural code we grew up with. Esoteric crap inside ActiveRecord allows normal English statements outside it, so find_by_login_and_password is an automatically generated method with an obvious and bullet-proof interface that self-documents its obvious behavior. All this compares very favorably to old attempts to build CASE tool technology into database query engines.

If that's the case, then it should be relatively easy to port Rails over to other languages, and it is not really tied to Ruby.

Unfortunately not the case, because languages other than Ruby don't provide the same metaprogramming technology required to build up the Rails backend. It'd be easy to port the app-specific code you actually write from RoR to another language, but you can't easily port the Rails framework itself to a less metaprogrammable language. -DavidMcLean?

Then it's at least tied to languages that make meta-programming and high-abstraction relatively easy.

MacOsx already ships with RubyLanguage preinstalled. Mac OS X 1.5 (Leopard) will now also have RubyOnRails preinstalled.

(db) Is there a reliable framework for Perl apart from Catalyst and Maypole? And how about for PHP? PerlFrameworkVsRubyOnRails

Compound Key Difficulty?

Some claim that R&R does not work very smoothly with compound primary keys. Anybody want to comment on this?

There's a plugin that makes it work. But the more database design I do, the more I think that (non-composite) surrogate primary keys are the way to go in general, and that Rails has this one right (pace JoeCelko). --MarnenLaibowKoser

Non-composite surrogate keys, except where absolutely needed, are an abomination. JoeCelko is an idiot.

{{The bottom line is that many shops are stuck with legacy data designs that are not going away any time soon. The tool has to handle goofy database designs decently to be a viable corporate tool. Single surrogate or actual keys make almost any framework easier to use, but it may have some database-side consequences.}}

Funny how I've had a lot of corporate work using something that supposedly isn't a "viable corporate tool", whatever that means. :) But seriously...Rails can handle goofy DB designs if it has to. However, there's a very strong ethos in the Rails community that instead of living with something bad, you make it better. For example, in that situation, I (and, I believe, many other Rails developers) would attempt to refactor the DB schema or introduce a mediation layer. Even if neither of those is possible, other tricks exist, so this is really never an issue in practice. --MarnenLaibowKoser 15 Aug 2013

{{But its competitors are often designed with the assumption of handling goofy DB's reasonably well. If we can assume we can refactor the DB, then comparable competitors may then appear that are even better. A lot of complexity, escape hatches, and "fudging hooks" could be tossed, producing many simpler CRUD frameworks, including DataDictionary-driven CRUD. But the reality is that unless you have Steve Jobs-like persuasion skills, a good many DB's will remain messy.}}

I think you're MovingTheGoalposts? here. Besides, Rails has been around for a good long time, and few comparable competitors of the type you describe have appeared. Anyway, my experience has been that DBs don't have to remain messy, and only do remain messy due to DeveloperApathy? and/or DbasGoneBad -- which are to be avoided in any development environment. I've been doing Rails since 2007, and in that time have worked on everything from solo projects to high-traffic sites run by Fortune 100 companies. I've never had the DB issues you're postulating. Ever. --MarnenLaibowKoser, 21 Aug 2013

{{I don't see MovingTheGoalposts? happening anywhere. People's backgrounds tends to bring them to the same kind of organizations or projects repeatedly. It's roughly akin to type-casting in the acting biz. Maybe RoR tends to be slated for new apps with new DB's. I've worked for a lot of places where the programmers have very little control over the database design, in part because it feeds existing apps and they'd have to be reworked if the DB is changed just to fit Ruby or a specific new app better. That's just how I see it. If my background biases such, it is what is. We all only live one life and see the world through the eyes of that one life. How about we describe a potential institutional issue and then LetTheReaderDecide if that situation is applicable to their own organization or not rather than bicker over the nature of DB political control.}}

CategoryRuby | CategoryFramework