Ask HN: Ruby on Rails why the hype?

Do you have a specific example of something you feel Rails doesn't do? Maybe that way somebody can tell you where in the rails ecosystem that falls.

  def self.ocr(file)

     result = system("my_ocr_prog", file.path)

     return result

  end

The "computationally interesting" stuff shouldn't be handled by your web framework. That's not its job. What Rails does well is let you get a baseline-nice web application with many common features up and running without much fuss.

Business Tier?

Why ROR? Speedy development, fun programming language, easy to build, test, iterate, repeat etc. Easy to migrate DB's, lots of scaffolding to reduce amount of code you need to write. Tons of great plugins written for the stack, very active community, some incredibly talented developers work on the stack.

ROR is perfectly suited for building out a great web app, quickly. And yes, it does scale ;)

Rails MVC blurs the distinction between a "pure" business tier and a db access layer.

The intention behind the design of ActiveRecord is that the db access logic is done automagically and you can make AR models your domain model.

The recent trend of adding various finders, etc. to AR models blurs the conceptual clarity a bit. Some plugins also blur this clarity.

Generally you should be able to use AR models as business objects, just be aware that there might be a few other behaviors added on that aren't strictly part of the business rules. This might irritate some people.

You are certainly free to write your business logic as separate classes as you see fit. Rails doesn't tell you not to. It just offers a convention that is often very reasonable for most peoples' needs.

It's the magic. The fact that rails extends data types and adds implied functions to your models without you having to tell it to. The fact that lines like:

cookies[:remember_token] = { :value => user.id, :expires => 20.years.from_now.utc }

Do exactly what you think they will, without having to define everything. That's the "magic" behind rails. It let's you focus on the application rather than the framework.

MVC and the N-Tier systems some similarities, but differ in their implementation. I came from a 3-Tier background where everything was simply divided, DB, Business, Output. Most of the time, the 3-Tier acts like MVC because you're accessing DB From the Business Layer then Showing it on the View.

Where they differ, and this is from my experience (feel free to correct me) is that in MVC, the Views have an attachment to the Controllers. Basically a view can only have one controller. Views can have multiple partial views, but ultimately belong to one controller. In the n-tier system, the view can be abstracted to the point where it does not care what is going to be shown.

Once you wrap your head around MVC, it is hard to go back, especially for Web products.

ROR also takes care of a lot of your db schema and logic, so you can focus on programming, not writing CRUD statements.

All of the code samples in the "models" that I've seen seem to be straight to database type code

I think the problem is that you're looking at "code samples", which tend to be the simplest possible examples. One of the nice things about RoR is that a model class can be as short as two lines:

    class MyModel < ActiveRecord::Base
    end

and everything else happens by "magic". Our system has a few classes like that. OTOH, we also have model classes with thousands of lines of complicated business logic. But, showing those to someone trying to learn RoR would just overwhelm them.

The hype is that it was finally a framework that does not build on leaky abstractions like "business layers". The downside is that it sometimes adds a few others...

By the way: the Rails hype was 3 years ago. Now, its just one implementation of the same concept like all others.

Makes it quick and easy to create working web applications without having to worry about all the extra necessities. Yes, you should learn about databases, working with SQL, html requests, routing, etc in depth, but Rails handles it for you so you don't have to waste the time setting up the cookie cutter parts and can get right to prototyping.

RoR has a lot of advantages for rapid development and prototyping early on. I think over the course of the development cycle, the advantages even out with other frameworks. In other words, for the first 10% of your development, you'll get much more accomplished than if you decided to use pure Ruby (or even Django or Symfony).

However, this "magic" comes at a price, and at some point you will hit a wall, and if you're a very attentive programmer, you'll have been paying attention to what the magic has been accomplishing without you behind the scenes, and you'll be able to figure out a way around it without scrapping your code base. If you haven't done that, then you're going to pull your hair out in frustration.

To be honest, I'm not a huge fan of rails or other magic frameworks for anything other than prototyping, but ymmv, I definitely understand why people like it.

Rails is based around the idea that the simple cases don't need a lot of explanation to the computer. So, let's say that you have an Article model.

  class Article < ActiveRecord::Base
  end

There's no need to do things like 1) tell it which database table to use; 2) tell it the setters and getters you want. Those can be inferred. Well, it's called Article so it'll use the articles table and we're going to want a setter and getter for each column.

Now, that can be overridden. You can call set_table_name to explicitly tell it to use a table, you can add additional methods, you can override the default setters and getters, etc. That's the idea behind Rails. You need a programming language to describe the decisions you're making that affect how your application works, but for a lot of things you're doing the same thing over and over and there's no reason to keep doing the same thing over and over.

Let's say that you wanted to (by default) order the articles by their creation date:

  class Article < ActiveRecord::Base
    default_scope :order => "created_at DESC"
  end

You've now defined some business logic so that when you call Article.all, you get them in that order. On the models, you can define any amount of logic you want by creating instance or class methods. In fact, all of those fancy keywords are just mix-ins - method calls that add methods to your class.

This is why it looks like Rails is lacking a bit of business. When you call belongs_to :apple, the belongs_to method gets executed as the class is interpreted and that belongs_to method is something like:

  def belongs_to(associated)
    define_method associated do
      associated.to_s.camelize.constantize.find(send("#{associated}_id"))
    end

    define_method "#{associated}=" do |val|
      send("#{associated}_id=", val.id)
    end
  end

Now, it's more complicated than that (since belongs_to adds some additional features), but that's the basic premise. You have this foreign key association and, most often, it's a simple association where you want to define a setter and a getter for that association. So, the belongs_to method takes the name and pops out two methods based on that name. The first is the getter and it makes the name you input into a camel-case and gets the constant with that name. It calls the find method on that constant and inputs the foreign key value to the find method. Likewise, the setter (setters in Ruby are methods that end with the equals sign) and sets the "name underscore id" attribute on the model to the id of the associated object.

But you could just as easily define the methods yourself in the Article class rather than using the helper mix-in. Likewise, if you have business logic that doesn't fit in with what's already made, you can define any methods you want on your model classes.

The same goes for controllers. Controllers can be pretty small. If you're just trying to get the latest 10 articles, there isn't a lot you have to do - you need to fetch them from the database and store them in a variable. This is another one of those areas where Rails doesn't ask you for things it can assume. Instance variables (which start with the "@" symbol) get passed to the template, local variables (which have no prefix) don't go to the template. The template that gets rendered is the one named "controller/action". Of course, you can override that and call render :template => "xyz/abc" if you like.

I'm sorry if this seems a little all over the place, but I'm not sure what kind of business logic you're looking to implement. If you give me an example, I can provide some insight. However, from what you've said, it looks like you've just seen the basics of what models can do - and that's because a lot of the intro code is "let's build a blog" where there isn't a ton of business logic. But you can make any methods (class or instance) you like to do things to your data. Rails creates the basic cases for you - because the ...

It's fast, good for prototyping and it's built in testing frameworks are better than nearly any other framework I have used. Especially native to the framework.

There are a number of things I don't like about rails, and it's more important that in most languages to do lots of unit testing because of the extremely dynamic capabilities of ruby. You'll be happy when you do gem updates

Redmine's models do all sorts of computationally interesting things[1]. What does business tier mean?

[1] http://github.com/edavis10/redmine/tree/master/app/models/