I'm currently working with Groovy and Grails. While Groovy is pretty straight-forward since it's basically Java, I can't say I grok Grails. I read that Groovy is to Grails as Ruby is to Ruby on Rails, but what does that mean?
To address your confusion with the metaphor (though it has been answered in other words under your question):
Groovy is to Grails as Ruby is to Ruby on Rails, but what does that mean?
Grails was a web framework built on/with the Groovy programming language to do the same thing for Groovy that Rails (a web framework for Ruby) does for Ruby.
What does it mean to be "on rails"?
The answer to this comes down to the essence of these web frameworks.
These web frameworks (Grails & Rails) are built on the premise of "convention over configuration", which means that using common conventions to develop web applications can lead to higher productivity and more maintainable applications (this is a gross generalization). And by defining a convention and sticking to that you will find that your applications are easy to generate and quick to get up and running.
This is what it means to me to be "on rails", just like a train. When a new train route is developed there is no worry about reinventing the way the train will get from one place to another, it's been solved by a single convention for decades: rails. Just as the tracks on a train route constrain its path from two locations, convention-based web frameworks use conventions to the flexibility of application developers so that they can concentrate on what the essential business problem of their application.
One key benefit of a convention for a web framework is that the web framework can now make assumptions on how certain layers of the application hook together. In Rails, one can usually assume that if one's database table has a plural name, the ActiveRecord class mapped to that table will have the corresponding singular name. Consequently, Rails code generators can consume the data-mapping information to generate data access code such as dynamic finders, migrations, lazy-loaded association traversals, etc. This data access code in a configuration-based framework is laborious to code by hand.
Several people have mentioned the technicalities of what makes Rails/Grails what they are. Several people have also mentioned "convention over configuration" as being the "rails" in Rails/Grails. This is getting closer to the truth. But this is just one characteristic of the broader philisophy of Rails, which is the concept of opinionated software.
Opinionated software can't be described in only technical terms; it's a philosophy; an ethos; an attitude. Like it or hate it, that is what's at the heart of Rails.
Here's an exceprt from a 2005 interview with David Heinemeier Hansson, creator of Rails:
Rails is opinionated software. It eschews placing the old ideals of software in a primary position. One of those ideals is flexibility—the notion that we should try to accommodate as many approaches as possible, that we shouldn't pass judgement on one form of development over another. Well, Rails does, and I believe that's why it works.
With Rails, you trade flexibility at the infrastructure level to gain flexibility at the application level. If you are happy to work along the golden path that I've embedded in Rails, you gain an immense reward in terms of productivity that allows you to do more, sooner, and better at the application level.
There is also a later interview that further explores the subject.
So being 'on rails' is a metaphor for being 'opinionated', which is why it is named as it is. That and the fact that "Ruby on Rails" is alliteratve, which any journalist or writer will tell you, is a sure-fire way of hooking people's attention.
I think a framework that strives to be "rails-like" refers to several things:
model-level: an AR-patterned ORM (rather than datamapper), migrations or some automated schema and model-layer management, handling foreign keys in the application (not in database schema, and also not using stored procedures or pure DBMS logic)
TDD encouraged: automatically generated skeletons for unit-tests,
naming conventions connecting database table names and model names, controller and view actions and HTML templates
streamlined route recognition and route generation scheme
emphasis on REST architecture
integration with ajax libs: RJS, prototype and scriptaculous
Rails is a framework for developing web applications with a database back-end. I think the name originally was a play on words. A train can take you somewhere really fast, but only where the rails go.
Being on rails means you can't control where you are going. It means, you can only go where the rails have been laid. Any attempt to go where the people who laid the rails didn't anticipate you to go will lead to frustration.
It's an automotive expression. When a car handles exceptionally well, it's said to "corner like driving on rails" (i.e. it gives you excellent control).
I don't know if that's where the rails people got that name, but that's how I interpreted it.
Really short and simple answer: Convention over Configuration.
As said above, Rails and Grails provide conventions for web application development -- naming your pieces a certain way and putting them in the right places get your application working by default with no extra configuration. When you want to deviate from the convention, you can configure your way there.
I disagree with the other comments of "on rails is a philosophy about convention over configuration" and so on.
While rails does adhere to those philosophies, "Ruby on Rails" is the name of a web framework. Nothing more, nothing less. It's not referring to any specific "on-railsness" about it, it's just a brand name in the same way that McDonald's is a brand name.
If someone else writes another framework and calls it "Python on Rails" then there'll be another brand name. If not, "XYZ on rails" just means people are being confused.
Ruby and Groovy are languages.
Ruby on Rails is a ground-breaking webapp framework. See excellent answers on opinionated software above.
As a matter of history, a working title for a Groovy webapp framework was Groovy on Rails. However the RoR community objected. The team chose Grails instead.
It's a metaphor, and I'm almost said that needs explaining. Anyway, it's an extremely good metaphor for what Ruby on Rails does. It makes it extremely easy to do (go to) the common stuff, i. e. testing, validation, deployment, MVC.
Related
Most generic CoffeeScript/Backbone.js examples use attribute names like someFlag, however Rails prefers/requires some_flag.
Is anyone aware of discussion on the topic or a style guide that takes this into consideration?
I follow the convention of the server technology for my Backbone models.
For example, in my Rails applications, I set attributes using underscore names like some_value, and in my .NET applications I set attributes using capitalized names like SomeValue.
This makes it easier to integrate everything on the back-end. It's a minor inconvenience to remember to do this in the client side code, but once I'm deep in to a project, it becomes habit for that project.
The ease of the back-end integration is well worth the minor effort to use the convention that the server wants, in my opinion.
"There are only two hard things in Computer Science: cache invalidation and naming things."
-- Phil Karlton
http://martinfowler.com/bliki/TwoHardThings.html
Most of the time, whenever I hit a website that looks "bubbly" in nature, and all prettified in those pastel-like colors, I think to myself, "This was probably done with Rails." And, lo and behold, after some digging into the site's information pages I discover this is actually true. So, I pose the question, not knowing much about Rails but enough about Django to understand how the database stuff works:
Does RoR have any display-specific qualities that affect how a web page looks? Or do all RoR devs naturally use the same Adobe tools to make everything look so ubiquitous?
Ruby on Rails is a server side technology, so it doesn't lend any specific quality to the user visible design. That said, it is a "trendy" technology so people who are likely to write their back-end code with RoR are likely to choose a particular "Web 2.0" style for their views.
As a Ruby on Rails developer, I can tell you that most Ruby on Rails developers are passionate about their work and we pay a lot of attention to details when building websites as much backend as front end. Its not just a trend, its a way of thinking and working.
No, it hasn't any display-specific qualities.
The theory is that RoR makes that backend stuff easier, so more time can, and apparently is, spent on the front end stuff.
Its all done with Mirrors. And CSS. :)
Rails is a very popular Web framework, it's just be coincidence that all the ones you've looked at have been rails apps.
What kind of sites have you been looking at to draw this hypothesis?
that's a funny question with a funny description :) ... bubbly!
As a madman, I develop with RoR, it's kind of rule in our area. We learn madness from the beginning, as a result of http://railsforzombies.org...
May wise men follow a wise path!
Short Answer: NO
However...
As a Rails developer I can say that due to the Agile nature of Rails and the speed in which you can develop web applications with Rails I do find myself having more time freed up on a project to spend polishing the user interface. I believe this may be a reason you often see more polished looking Rails sites.
So in my mind I believe your choice of framework can have a direct correlation to the end product that is produced!
Rails does add some stuff to the front end. Like to every html form, it will add a hidden input element authenticity_token.
You can also tell because rails URLs and form actions will never end with suffixes like .aspx or .php or .html or .jsp, and they won't usually append ?query=book&encoding=utf8 like you see on google. And they won't usually have superlong crufties like you see on amazon (eg http://www.amazon.com/Agile-Web-Development-Rails-Ruby/dp/1934356549/ref=sr_1_1?ie=UTF8&qid=1297922135&sr=8-1). Instead Rails prefers simple routing URLs. If amazon were written in rails, you might instead expect amazon.com/books/Agile-Web-Development-Rails-Ruby
So there are ways to spot a Rails app. I expect other web frameworks, especially the ones that emulate rails, would duplicate some or all of these features, so this isn't a sure-fire method, but it helps.
Some ruby gems like jekyll, toto and webby offer out of the box blog-type integration into your ruby app. Another way of developing a rich web blog-type application is to build and model the application yourself using pure ruby and rails practices. (e.g creating an Article and User model). The first offers out of the box features the 2nd option offers more customization and control.
In people's experience on Stack Overflow, which would be the best route and what would people consider when making the decision to use a gem out of the box versus going alone?
All of the gems you mentioned take static, markdown/textile/etc files and turn them into HTML websites. They take different approaches to it, with jekyll spitting out the finished website for hosting, toto doing the converting and routing on request, and webby doing the same as jekyll mostly.
If you're using Rails, it's important to note that none of these will integrate into your application well. They're built to more-or-less operate on their own.
Generally speaking, if a gem has the functionality you need, use it. They are not equivalent to plugins you find for Wordpress and Drupal where they are typically low-quality, buggy, poorly documented, etc. More often than not, gems simply add a couple modules that you can integrate into your application how you like.
On the other hand, a basic blog is pretty quick and simple in Rails, especially considering you've got a handy walkthrough guide straight from the Rails documentation on how to do it.
If you're new to Rails and want tight integration with your app, it's probably best to bake your own blog features.
This will take some time to do, but its worth it to learn how things really work.
If you're more seasoned, just look at the gem's API and documentation and decide if it does what you want it to do and if you're comfortable with how to integrate it. If so, it'll save you time.
One other consideration: who will be using the blog? Is it for internal use, and programmers will be the ones updating it? If that's the case, then you can make it very easy by not worrying about a lot of aesthetic polish in the back-end. Conversely, if you're making an app that includes a blogging component for the general public you might want it to feel more polished. In this case a gem might save you a lot of time.
It depends on your application.
I've been learning the Ruby web framework Sinatra lately, and I'm finding it great to use. Most of the articles and blogs I have read about it seem to assume that it is good only for small websites, or 'tiny' web-apps. Is this true? Can a complete web application be built in Sinatra, or is Ruby on Rails the way to go?
You could, in theory, build an entire web application using Sinatra, and it would offer you more precision control than Ruby on Rails would.
That said, it also removes all of the nice features ruby on rails gives you, such as the Model-View-Controller architecture.
If you're looking to build a web application with database interaction, I strongly advise you use Ruby on Rails.
If you're looking to build a very simple API or something that just takes some data and throws it up onto Twitter or something, go ahead and use Sinatra.
There is no reason that it couldn't be used to build an enterprise website. It's fast and intuitive. Two key things in building a larger web application. While it does lack many of the features of Rails, I am yet to run into a road block.
I personally like the slim nature of Sinatra. It embraces routing instead of making it a headache.
I usually find myself wrestling with Rails, whereas I configure Sinatra to my liking.
As for database interaction, mongo_mapper + Sinatra works very well.
I have been spending some time creating what I called a framework.
It was aimed at the creation of quiz likes games. It was supposed to have two players syncronized and present them a question to solve, etc.
I would like it to be fully customizable so I tried to develop components that can be put in or out of the pages. In the end the elements became slim ruby methods to add a whole bunch of Javascript and CSS to the pages.
Still the Javascript needs to connect to Ruby so methods supporting it are created but they will only be present when the component is present. Some components depend on one another making everything overly complex.
And after this attempt I wonder, is there is not a better and easier way to make a framework aimed to one kind of application on RoR? Or is the concept flawed or RoR in some way flawed?
Ruby on Rails is a framework on its own accord and is "opinionated software". This means that the writers of Rails looked at what would make most sense for creating a web application to them. Many people support the original developers views and so use Rails for their projects as well.
I think your concept of creating a quiz is a good one, but first you need to understand the rails stack. Depending on what you need exactly, you can create either an engine, plugin or whatever.
What I have seen a lot is that you specify what you need in your controller. (How you do that is up to you). All that information is stored in a class variable and transferred to the view where you can render everything you need with some helpers. The hard part is making it all generic enough to be reusable.
But, maybe Rails isn't the right tool for you. Maybe you need something more lightweight like Merb or even Sinatra.
There is no 'flaw' in Rails. Rails is not the 10**1000-in-one tool Java is. It's a framework that tries to do one way very good in a particular way. I think Rails can be the right tool for you, but you need to be skilled enough to wield the tool :)