Slashdot Mirror
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?"
> Automatic code generation sets of alarm bells in my mind
Do you have a beef with compilers and assemblers?
Sheesh, evil *and* a jerk. -- Jade
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.
"Support Bacteria - Its the only culture some people have" - Circa 1985
Bruce
* Duck typing: If it looks like a duck and sounds like a duck, it's a duck! Object types don't matter to the users of Ruby objects. What matters is that the object responds to a particular collection of methods. This is something like virtual functions, but does not require inheritance from any class or virtual class although inheritance from a Ruby module (sort of an abstract base class) is often the best way to implement those methods. So, a Ruby object might export a collection of methods called Enumerable and would respond positively to an is_enumerable? method to identify that those services are available.
Bruce Perens.
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.
Rails has created quite a buzz in the Web 2.0 community, which means a lot of people jump straight into Rails without any prior knowledge of Ruby; and then when they find they can't get very far they blame that on Rails.
It's like hacking the Linux Kernel without ever having programmed in C. You're bound to think it sucks because you won't have a clue what's going on.
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.
I've been doing almost pure OO programming for the past 8 years (using mostly C++ and Java), but recently took up Python (for python-twisted and pyWxWindows) and Ruby on Rails (for server-side development), and I can tell you that it is much simpler, easier to debug, and quicker to get done than taking the time to create massive class hierarchies whose inheritance structures and interfaces only exist to satisfy type-safety requirements.
Don't get me wrong. I like writing class hierarchies as much as the next guy. I've spent years doing it. But when I compare what I can get done in 30 minutes in, say, Python, to what I can't get done in 3 hours in C++, the advantages start to become very clear.
Try Ruby (the language) here. 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.
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 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.
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.
This space unintentionally left unblank.
As others have noted, what Rails generates for you are stubs. Even if the stubs are full-featured enough to let you add, edit, view, and delete objects, they're still stubs. It's just that RoR is succinct enough that generating 150 lines of code (including action views and layouts) is all that's necessary to provide all of that functionality in a very basic way.
l -from-scaffolding
But, two links for your consumption.
My article on the topic of what I call Scaffold Withdrawal
http://www.slash7.com/articles/2005/12/07/the-fal
Structure generation vs code generation (from the Rails' creator's blog)
http://www.loudthinking.com/arc/2005_10.html
It's true that "Ask Slashdot" is vehicle for enlightenment, but I didn't think it was a vehicle for the basest laziness. I don't understand why someone would go Ask Slashdot instead of looking at a couple F/OSS Rails app packages and deciding for himself whether or not they look "maintainable."
If the submitter did, he'd find that it's clear that maintaining Rails apps is no problem. You don't have to know much about a given app to even do serious "maintenance" on it. As long as the programmer hasn't tried really hard to break all the benefits Rails brings to the table (regular file structure, MVC separation, clean models, helper classes, etc), then you'll already know a lot about how the app is structured before you even unzip it.
---- My Design, Code, Ruby on Rails blog: http://www.slash7.com/
Ruby is not statically typed, which means that if you have a very large program and you change an API in that program you have to go and find all the instances of calls to that API in your program yourself, either through running automated tests or seeing the broken calls in the debug log of your application. Compiled langauges on the other hand such as Java,C,C++,C# have static calling conventions which means that when you break an api the compiler will point out all the broken calls to you and not let you run your program till you fix them all. This tends to make statically typed languages more maintainable. If you need to break out of static calling conventions you can in Java at least using introspection and bytecode enhancement but this is usually only done in well defined scenarios inside of application frameworks instead of for every class like in Ruby.
RoR is pushing this whole codegen thing too much (I personally think codegen is the work of mediocre developers who have ego issues, but that's just me). 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. Ruby is a nice scripting language but I didn't like the architecture of rails. Just not for me. 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). Ruby is a nice language though, but it's not as useful as python. So I struggle to find a place where I can use it, maybe it can be nice as a simple embedded script language (similar to Lua).
If asked what I would use to develop a server side app, I would have to look at volume and complexity then go in the order: C/C++ > servlets > JSP/PHP > RoR (from highest volumen/complexity to lowest). For high volume/complexity C/C++ is still the best efficient way to go but not for all, requires more work from the developers and not for average/weak developers. Servlets are a good next step if performance is not extremely important. JSP/PHP is a good way to run a site that doesn't have complex computation or one that is static content based (news, blog, forum, and such). RoR I would use for maybe some prototyping or to build a quick and dirty app to provide a simple view of the database (but even then I would probably lean to PHP). YMMV.
Unfortunately, that's exactly what most Visual C++ programmers mean by code generation. The "wizard" generates a huge chunk of boilerplate code that the developer never understands. He would prefer not to even look at it, but occasionally has to make some minor tweak.
When I use code generation, I generally write the generator too. As you say, there are two choices: you either generate the code once and then maintain it completely manually (i.e. it's just the scaffolding), or you maintain the generator and the input to the generator but never touch the output of the generator.
Tools like Borland C++ Builder and Rational Rose try to give you the best of both worlds with the "round trip" code generation/reverse engineering. While they do have some advantages, in my opinion they aren't overly successful at it.
Graham
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.
I18N == Intergalacticization
I hope that the number of highly-modded responses which have had the chance to clarify what code generation is in Rails, and what its purposes are within the development cycle, will allay some of the FUD. When I began learning Rails I was under no impression that code would be generated beyond the scaffold, and that the scaffold was only there to get some meaningful database interaction happening right away. This tutorial which I began learning Rails from explained it clearly:
Of course, these actions and views are very plain--not the sort of thing you'd want users to see (unless they are total geeks). The good news is that we can leave the scaffolding in place and slowly, one at a time, provide our own versions of the actions and views. Each time you create one of the actions or views it will override the scaffold's version. When you're done, simply remove the scaffold statement from the controller.
The way I imagine the misinformation formed is from certain people hearing the sentiment of "faster development in Rails" and jumping to the conclusion that there must be some sort of cheat involved. Watching the video demos probably fueled this, as the demos are showing Rails off, and the scaffolding is a selling point.