Is Ruby on Rails Maintainable?

kale77in asks: "I've become a big fan of Ruby over the past few months, but I'm not at all sure about Ruby On Rails. Automatic code generation sets of alarm bells in my mind; so that, to RoR's promise of 'Web Development that Doesn't Hurt', I automatically add '...until you have to maintain it'. On the other hand, some writers and coders I respect (like the Pragmatic Programming mob) seem to be fans. I've mainly written generators in Python, to produce PHP/SQL/Java from SQL files, but I've always gone back to well-constructed objects, where extension and overloading offers more precise and maintainable customization than auto-generation allows. So is Rails just a nice RAD tool for disposable, cookie-cutter apps (which have a place, of course)? Is high-level generation just a bad OO substitute? And what has your experience of Rails' maintainability been?"

It's obvious...

[eruanno]

It's quite obvious that the concept of the automatic code generation done in Ruby On Rails was either not completely grasped or completely missed by the author. The whole purpose of the code being generated was to give you a basic structure to take and change until it was what you needed it to be. This is precisely why it is called 'scaffolding', because it gives you the framework to get started with.

As far as the Ruby On Rails framework itself is concerned, it is extremely capable and flexible for handling a great deal of web application projects. Of course there will be specific functionality that Ruby On Rails will not handle very well — there never are perfect solutions.

I wouldn't consider the reviewers objections completely devoid of import, just misguided. You must always be careful about anything you didn't do yourself, but you must exert the same care and attention to the stuff that you do create yourself! Often we put far too much confidence in our own coding skills.

So, in the end, the concept of Ruby On Rails is simply to alleviate the mundane, rote programming that goes into the basics, particularly the structure and minimalistic database interaction, and make it surprisingly simple.

M.T.

Get the basic premise right, first

[blakeyez]

Rails is _not_ a code generation framework. Note the period on that sentence.

Rails may provide the some simple scaffold generation, but that's only there if you _want_ to use it, and it happens to fit the way you'd like a particular part of your app to work. The code produced is concise, easy-to-follow, and thus easy-to-maintain.

For my own applications, I barely ever use scaffolding. It works well for simple admin screens where I just want 'something' that works for now, then will spend some effort on designing it a little better, later.

Rails is as maintainable as you make it. If you're a poor programmer, you're likely to write unmaintainable code, no matter what language or framework you have to help you. Rails helps point you in the right direction, but in the end, it's up to the _developer_ how maintainable his/her code is.

It isn't really code generation

[Anonymous Coward]

Ruby on Rails script/generate generates very little code. If you choose "File, New class" in Eclipse, you get the about the same amount of code, as you would get if you used rails generation features. The only difference is that ruby on rails also generates a test class for the model.

Scaffolding generates a bit more code, but it is never intended to be actually used. It is ment to be slowly replaced, piece by piece, by your own code. So I don't think the disadvantages of code generation really applies here.

So yes, in my experience a ruby on rails project is maintainable.

"favoring convention over configuration"

[leather_helmet]

My limited use of RoR has been favorable - no issues, as of yet, regarding maintainability or spheghetti-O code

It has worked as promised and I have been pleasantly surprised by its functionality
btw, my main use was creating a new database for an intranet application

Try Ruby here! In your browser! Painless!

[5n3ak3rp1mp]

Try Ruby (the language) here [hobix.com]. Integral to understanding much of Rails.

I released my first production Rails app last month. I like it a lot. I have a background in ASP/SQL Server/PHP. Not having to use Microsoft Windows itself is a huge win. But I like the design of the language and the framework and the built-in separation and a thousand little other things. Check out #rubyonrails on irc.freenode.net, great community there too.

Re:Yes, very

[Atlantic Wall]

If you had to use something more than once in Java, why not just write it once and overload the method or the object. That statement that you have to edit the same thing in different places does not make sense if Java is coded correctly.

Wrong Idea

[AntiDragon]

The "Automatic Code Generation" is a slight misnomer. It would be better to think of it as "Semi Automatic Code Generation". (Mental image...hehe).

It's just a part of the system that can *if you so desire* generate basic classes and parts of an MVC system by inspecting your database. It's basic and is designed to give you something to work with while you build the actual application you want.

The real strength of the Rails framework is the various support libraries and the way it gently encourages you to follow specific coding conventions (Hungarian notation fans, run for the hills!). If anything, this not only speeds development but makes maintenance a breeze - Ruby is a very readable language when not abused.

Hmm...that does all sound a bit fan-boyish, doesn't it? Well, I'm a PHP convert to Ruby and I have to say I wish I'd decided to take a look sooner.

Short answer - Rails systems are probably more maintainable than your average ASP/PHP system.

Re:Yes, very

[Bruce Perens]

It's mostly declaration that has to be repeated endlessly, rather than implementation.

Bruce

Rails is more then meets the Eye

[TheUncleD]

Rails provides more then the scaffolding capabilities and simple framework of designing a blog as seen in the video. It provides the structure for fast and organized ruby application development by setting up for the user a foundation of modelling, views and controllers that are easy to use and distinguish. It is not the magic wand to a great web application. The magic wand comes with Ruby programming experience and learning to tie it into Rails application development. You could even go as far as stepping beyond the "narrow view" of what rails is doing and see the bigger picture, understanding that Ruby is supporting all of this webmagic and rails is providing the "rails" as it claims to. One challenge many of the "why is this better than Php?" questioners have difficulty seeing past is the far smaller community rails has, the less clear translation between what php can do and what rails is capable of, and the predefined examples of rails applications in action. Many people leap to using PHP becuase it provides pre-existing code snippets that make the same thing true of many php users, "simple cookie cutter codejobs." Rails offers you a chance at not only using a great framework, but also a great programming language that its built on to make more pragmatic and simpler design tactics to getting your website online and active. Another alternative to rails is Iowa which offers a lighter approach to maintenence, though remains less documented. It can be found here: http://enigo.com/projects/iowa [enigo.com] Whatever you choose to do, look deeper into the situation then the surface of what appears to be "cookie cutter" programming and realize that a powerful tool lies beneath all of this: Ruby.

ORM and MVC in the same framework

[stelmach]

I find it unfortunate that most of the 'newbie' tutorials jump right in to how to generate scaffold code. This code is a bit unmanageable and hard to modify, but I think it has a certain 'WOW' factor associated with it. Once the novelty wears off and you need to develop real applications, you will rarely use the generated scaffold code, and the code you write within the framework will certainly be manageable.

Where I think Rails comes out on top is the fact that it includes a full blown ORM and an MVC implementation under the same, configuration-less framework. No more XML. No more duplicate java beans...More of this on my blog [joestelmach.com] if interested.

Author has it all wrong

[wackysootroom]

Judging by how this article was written you haven't used rails at all, or maybe used it for something extremely trivial. The "automatic code generation" (scaffolding) is only there to help you get started on a project. You can completely bypass it if you want.

I'd be willing to bet that if you used rails for an hour or two, you wouldn't have written this article. In fact, the entire article depends on your assumption that the code *has* to be generated automatically.

So what are you waiting for? Try it and see! [rubyonrails.com]

Re:Here's an AJAX example - how good is RoR for th

[zardo]

I've been using rails for over a year, I think that would be really easy and a testament to how great a language ruby is, in addition to how great a framework rails is. The filesystem classes you will be amazed with, and you don't even have to know javascript to get some pretty amazing AJAX functionality out of your app.

I honestly couldn't think of a better way to do something like that than with Rails.

Re:Eh kindof

[brian_olsen]

"It requires you to do a lot of things manually that could easily be done automatically, and you still write bits of SQL in your code."

Which type of things can be done automatically, you see? Also, what is so bad about writing SQL queries *for complex queries*? I know in my case, I will not be hopping from database system to database system to worry about SQL compatibility issues.

"Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface. This is bad for any number of reasons."

You mean its use of ERb?

"Finally, it's pretty much tied to MySQL, so if you use PgSQL or Oracle (and you should), then you're in for a big headache."

I have no problem using it with PostgreSQL.

Java Interfaces

[bunglebungle]

Java interfaces allow you to declare that something is a Duck, so it must be a duck. However, with Java, I can ensure that anything I think I want to call a duck does indeed fulfill the contract of being a duck. What in Ruby forces you to properly export the collection of methods in Enumerable when you defined is_enumerable to return true? Nothing?

In Ruby, you can write code that assumes a parameter has a method called foo. In the future if I make a new object, I can add a foo method to it and pass it into that code. In Java, all it takes is the oh-so-hard task of creating an interface called, say, CanFoo, that declares a foo method, and typing my parameter to that. For anything I want to pass into that code, I just implement method foo, which I have to do anyway, and add CanFoo to my list of implemented interfaces. Classes don't have to inherit from any particular class, and they can implement as many interfaces as they want. So that was no more work. However, now the compiler helps me to ensure that I properly fulfill the contract of CanFoo. Plus if I want to do anything useful like find things that think they CanFoo, or rename foo to something else, the compiler will know where all of these references are and help me.

I'm not anti-Ruby, but I just plain don't understand arguments like this for the language.

Also, "say it only once" may be somewhat forced by the framework, which is a good principle of a framework, but that transcends languages, so I don't buy that, either.

I'm not arguing that Rails isn't maintainable, just that your reasoning for why it is aren't exclusive to Rails or Ruby.

Re:Eh kindof

[znu]

I've been using Rails for about 7 months, and have done two major projects in it. I completely disagree with your assessment. For starters, it's not at all tied to MySQL. PgSQL support is also very good. My understanding is that Oracle support is not so great at the moment. But I expect that will change. My real point here is that Rails is not inherently tied to any specific database; it's just a matter of what ActiveRecord adaptors happen to be out there right now.

As far as requiring the user to write SQL code, yes, you do have to write fragments of SQL code, sometimes. But SQL is a useful way to describe queries -- that's the whole point. Would using some other query language, that got translated to SQL, be any better? I don't see why it would.

Your comment about Rails not abstracting functionality from interface seems off base as well. Rails adopts a standard MVC architecture, which is pretty much the standard method for abstracting functionality from interface. If you're not getting such abstraction in your Rails apps, you probably just need to think about exactly what should go in the models, what should go in the controllers, and what should go in the views, and rearrange things a bit. Like any other MVC environment, Rails can't prevent you from e.g. putting view-specific code in your model. All it can do is provide a structure that allows you to properly separate these things if you take the time to think about your design properly.

Finally, on the charge that Rails only provides proof-of-concept features, I think you've misunderstood one of the major design principles of Rails. Rails is intended to provide a framework to build on, not a bunch of components you can plug together to get a web app without writing any code. As such, many of its components focus on the core functionality that's really useful, to the exclusion of other stuff. That other stuff might sometimes be nice to have, but it frequently locks you into doing things the way the framework does them, instead of the way that's most appropriate to your app. The Rails approach is a very refreshing change, for me anyway, and I hope the project will continue to maintain this focus.

RoR & Maintainability

[Whatchamacallit]

RoR (Ruby on Rails) is simply a very nice API for doing web apps with Ruby. It will auto-generate some code via what Rails calls Scaffolding. This is meant to get something working extremely quickly and it allows you to enter some data into a table with minimal fuss. The code it generates is quick and dirty and you are supposed to re-write each method as you move forward. That said, it's not a real code generator in the traditional sense. The Wow factor of the videos on rubyonrails.com show off the Scaffolding but that is only a very small part of Rails development.

Ruby itself is very maintainable because the syntax is so very clean. However, it's up to you to document your code with meaningful comments, check it into CVS or Subversion, and implement your own Unit Tests, and include RDOC tags in your comments, etc. All code regardless of language is maintainable if you eliminate the code monkey bad habits. i.e. if you've been coding in PHP and all your code became unmaintable then it's your own fault and not that of PHP. Ruby in my opinion is better organized then PHP and encourages good code standards but ultimately, it's up to the programmer. If you are a neat freak and are very detail oriented and you tend to go back and cleanup, test your code before you check it into your version control system then your code will always be maintainable.

I like the way the RoR ActiveRecord mapping system; maps my classes to database tables and objects to my records. You can programatically create records in the table by creating additional objects. The scaffolding will read an existing database table and generate working classes so you can utilize CRUD functionality. You don't have to use scaffolding but it comes in handy for me even when I throw it out one method at a time and re-write it.

Re:Eh kindof

[Anonymous Coward]

Rails isn't tied to any database. For example, I use a sqlite3 for development. For production, I then move to postgresql (read below about keeping data). You can even create an "in-memory" database if you want to prototype something really simple.

Here is a short prototype:
require 'rubygems'
require 'active_record'

ActiveRecord::Base.establish_co nnection(
  :adapter => "sqlite3",
  :dbfile  => ":memory:"
)

ActiveRecord::Schema.define do
  create_table :users do |t|
    t.column :name, :string
  end

  create_table :posts
    t.column :post_id, :integer
    t.column :title, :string
    t.column :body, :text
  end
end

class User < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::base
  belongs_to :user
end

me = user.create :name => "me"
me.create_in_posts :title => "Blah", :text => "look at all the text I am writing!"

Isn't that neat? I defined my schema in Ruby. Rails will translate this code into SQL statements for any SQL server it supports. Rails also has this neat thing called migrations. You can mess around with your schema, and not effect the data that is already in there. You can even pick up your data and move it to a different SQL database (sqlite3 -> postgresql)

Re:Yes, very

[CableModemSniper]

http://www.rubycentral.com/downloads/dbc.html [rubycentral.com]

Re:Uhm...

[publius_ovidius]

Do you have a beef with compilers and assemblers?

This is a valid question. Quite often when we have a robust low-level language generating high-level language (HLL) code, it's extremely well thought out and tested. However, many are dubious about HLL generating HLL code. I suspect (though I can't prove it) that this is because HLL -> HLL tends to be less widely used and thus is less thoroughly tested and less planned. When done properly -- particularly when covering a restricted and well-defined domain -- it can be extremely powerful. When done improperly, it's a nightmare.

Rails has a large enough user base that most common bugs have been eradicated but from what I've seen, it appears to have a problem that many fourth generation languages suffer from: if your problem fits its domain, it's a piece of cake to solve. When your problem doesn't fit its domain, it can be extremely difficult to solve (anyone who's ever worked with the 4GL Easystrieve Plus can readily testify to this). Most web-based apps, though, are simple enough that folks working with Ruby generally don't seem to have much of a problem with it. However, I've heard horror stories about people trying to use their custom model in lieu of what Rails natively supports -- though I've not had first-hand experience.

Compilers and assemblers tend to be general purpose tools which address a fairly wide problem space. HLL -> HLL tools tend to be special purpose tools and trying to get them to solve problems they aren't optimized for can be trying. In the case of Rails, one thing it excels at (CRUD apps) is a well-known problem space and Rails fits quite nicely.

So I have to say that comparing Rails to compilers or assemblers doesn't quite fit simply due to the differing focus of said tools. However, all of them require that someone trying to work with them understand what they're doing (at least at a high level) and that brings down the maintenance burden quite a bit. Personally, I'm quite impressed with Rails and am happy to see it spread.

generation gap pattern can add maintainability

[zdburke]

Vlissides' generation gap [ibm.com] pattern can help solve a lot of the maintainability issues with code auto-generated from a DB's structure. The idea is that you use some tool to auto-generate stubs from your model, and then you extend (in the formal OO sense) those stubs. When your model changes, you can regenerate your stubs without trying to do some ugly merge between your customized templates and those that reflect the new structure.

Re:It's obvious...

[bryanthompson]

I agree 100%. The scaffolding should be used to get a feel for how quickly developing *anything* on Rails can be. For newbies or J2ee migrants, the short videos on the Locomotive and rubyonrails.com site shows how scaffolding can be built, modified, etc. There's no way I'd put scaffolding into any site that others will see. It's quick, dirty, and easy. Use and extend it, but don't rely on it!

Coming from J2ee-land, Rails has been really easy to pick up, and very easy to maintain--so far. If you visit the #rubyonrails irc.freenode.net, it's very active, and there are a ton of Java guys who want to see what RoR is all about. My biggest problem was figuring out the project structure and then figuring out the standards. Parenthesis, semicolon line endings, and block brackets not being required really turned me off at first. It felt sloppy and just weird.

I think the biggest advantage is that all of the add-ons we were using are included in RoR. Log4j and hibernate, for example, can be hell to set up and maintain. With RoR, the logger is built in, and its migrations are just hibernate-ish enough to get the functionallity I wanted out of it. The pieces you need are there, and they are easy to use. For us OS X guys, Locomotive makes it ridiculously easy to start out also. I don't know about setting up a RoR app in a production environment... From what I've read there looks like a lot of initial configuration, but I had my share of difficulties with Tomcat also.

Since we're still developing the app, I don't know how easy it will be in the future to maintain. I worry about Ruby updates and how they'll interact with old code. WHat happens when deployed in totally different environments? The API is total suck, and there really isn't a ton of information like there is on J2ee. I want to know the best practices and common ways of doing things, but all I find are blogs and random articles that don't really get into detail. The Programming Ruby and Agile Web Development with Rails books are great, but they don't get into these other areas.

Re:Uhm...

[CrazedWalrus]

There are a few. I've never used them, so I can't speak to their quality, but apparently work is being done on exactly what you ask:

Biscuit: http://bennolan.com/biscuit/ [bennolan.com]
Qcodo: http://www.gadgetopia.com/post/4726 [gadgetopia.com]
Cake: http://cakephp.org/ [cakephp.org] ... just to name a few. I just google'd for 'php rails', and got lots of interesting links.

Re:Uhm...

[Marillion]

RoR has explicit and implicit code generation. Model classes which extend ActiveRecord::Base have amazing amounts of implicit, runtime-generated methods which can be replaced with custom logic if that's what you want.

The template generators are explicitly called development-generated blocks of code which are intended to be one-time only and edited by hand thereafter to meet business objectives.

Between the two, I love the former and dislike the later. I usually don't use scaffold built views except for Quick and Dirty lookup table administration. I think the difference between the final view and an empty file is smaller than the scaffold view and the final view.

Re:Uhm...

[Bruce Perens]

Can you alter the templates generated?

Yes. Either completely override the template for a specific method starting from zero with your own code, or get the code generated for that method and then alter it.

How is this article generating all this Ruby-anti-Ruby nonsense when it's a question of Rail implementation?

Because this is in part an instance of the perennial compiled-vs-interpreted argument.

More importantly, why isn't there a PHPoR?

IMO, because the developers capable of doing something like RoR 1) didn't like the PHP language as much as Ruby and 2) felt they could do better than the existing PHP web environment.

Thanks

Bruce

Alternate Frameworks

[hohonuuli]

Rails has been getting a lot of Buzz lately but it's not the only RAD framework out there. Personally, I'm not a fan of Ruby so I'm not so keen to jump on to the 'Ruby Rocks' bandwagon. If you're using python you may want to check out the Python equivalents of 'Ruby on Rails'. Here's a few:

• Django: http://www.djangoproject.com/ [djangoproject.com]
• Turbogears: http://www.turbogears.org/ [turbogears.org]
• Subway: http://subway.python-hosting.com/ [python-hosting.com]

The hard part is writing, not maintaining

[Chief Typist]

I've been using Rails and Ruby for the past few months -- I had no prior experience with either.

The thing that has become clear to me is that the hard part of Rails is learning *how to do it right*

The "automatic code generation" (scaffolding) is helpful for learning *how to do it right* but as you get deeper into the framework, you find yourself coming up against difficult and/or domain specific problems. In all cases I've encountered so far, there are simple solutions to these problems -- the hard part was finding the right way to solve the problem.

You have to take the time to read the documentation, dig through the source code, think about design patterns, and write elegant Ruby code.

Often, this code is only a few lines long. For example, I had an issue with SQL statements including NULL values when I wanted to pick up a default from the table schema. The solution was a single line of code to remove the named attribute from an array in a Model subclass. It took a few hours of research & prototyping to figure out that one line of code.

So as far as maintainability is concerned, I'd say it's pretty good. That one line of code mentioned above is easy to understand for someone doing maintenance. Less is more.

One final observation that I've made regarding Rails and Ruby -- it's a lot like Cocoa and Objective-C (another excellent framework backed by a dynamic language.) When you find yourself writing a lot of code, it's a good sign that you are doing things wrong.

-ch

RoR is maintainable enough -- but...

[oldCoder]

But the programmers API isn't nicely documented in RoR, although there is a web page that claims to do that. For example, to search the RoR API web page you have to use google. Half the time I come up with a blank document. That is, the entry for the function I want is a blank page, and there is no context (no "up" button) so I can't use it as a starting place for more navigation.

The result of the somewhat sloppy documentation is that if I find a function that does something (like by looking at the source) I don't know if it is guaranteed to be there next release. The existing book ("Agile web programming...") is too chatty and not complete and accurate like a reference manual would be.

So I'm somewhat blindly following the examples and when something doesn't work I have to backtrack. Still, all in all, I like it. I need the speed.

And, like a lot of people, I found I had to go back and study Ruby a few times. The existing Ruby docs are great.

But I desperately want a good Rails reference manual.

Re:It's obvious...

[Anonymous Coward]

I agree about the documentation. Everything seems to just boast about their MVC design, without actually telling you how to use it. I searched the 'net for weeks, reading as much as I possibly could, just trying to understand how things work. I had to piece together what I learned from a couple of tutorials and the associated debugging. It took me a couple weeks tinkering to figure it all out.
Turns out that it's dead simple. It's not magic, it's just that most of it's either hidden by default, or in a weird subdirectory. Once you get the hang of it, the directory structure is a godsend. It's so easy, and it's so effective. I'm thinking about writing my own description of Rails once I've finished my current project. It won't be a tutorial, it'll just lay out the basics of how things actually work.
Despite all the empty rhetoric, and lack of descriptive documentation, the IRC community is really helpful, and Rails itself is more than worth the time to learn.

Re:Agreed. And, Python equivalent of RoR

[Beek]

> In the end, Ruby is just a MVC and ORM web framework, along with a little bit of code generation to get you started.

Don't forget about testing... The testing framework is probably the best part of the framework, and not enough people are talking about it.

But int the end, Rails is more than just MVC + ORM + Code Generation + Testing. Rails is greater than the sum of its parts. Having all of those thing in one cohesive framework is much better than cobbling together a stack of tools to do the same thing.

Re:Yes, very

[Anonymous Coward]

What you call duck typing is known in the litterature as structural typing. The alternative, used in languages such as Java and C++ is called name based typing.

Structural typing is more flexible, because, as you say, if it looks like a duck and quacks like a duck, then it is a duck. The counter argument is that allows compatibility between types that are conceptually completely unrelated. An 18 foot tall robot that attacks while looking like a duck and playing scary QUACK sounds is a duck according to this philosophy.

Name based typing, as used in Java and C++ and several other languages, will only allow you to consider something a duck if it inherits the "Duck" type. The is-a relation is always explicit.

And that completes today's lecture on the theory of type systems. You may now flame each other for using structural types instead name based types and vice versa.

Re:Usage of RoR

[ogleslurp]

I used RoR for about a day and wrote a little app then realized that maintenance is a pain and that I would have to manually change all the code anyways to make it behave as I want and that codegen created something I did not want. Then I weighed it against writing sevlets and JSP pages and RoR didn't look so appealing.

I'm certain that this idea will be expressed elsewhere, but please note that the code that rails generates is only a skeleton that you can shape to suit your purposes. But which code generation feature did you use? I am honestly curious, because I can't really line up these comments with any of the code generation features in rails without making some pretty absurd assumptions.

Performance was quite bad too, about 6 times slower than JSP for fetching some data from a database, manipulating it (which is the bulk of the work) and displaying it (given JSP gens compiled into Java and takes advantage of JIT).

Probably you were using the webrick server in development mode. It's not really supposed to be fast, it's supposed to be simple and portable. If you spend some time looking around, you'll find many production configurations that will run as fast as you need them to.

Ruby is a nice language though, but it's not as useful as python.

This is just noise, honestly. Please explain!