Is Ruby on Rails Maintainable? 348
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?"
Uhm... (Score:4, Insightful)
Do you have a beef with compilers and assemblers?
Re:Uhm... (Score:5, Insightful)
Re:Uhm... (Score:5, Insightful)
Bruce
Re:Uhm... (Score:4, Interesting)
I concede that "scaffolding" is used by EVERY PROGRAMMER. That's the idea behind code reuse. "I'll adapt my authentication I made for a BB system to use as auth for an entire website." "I'll use my pretty table CSS from last year for displaying this data."
Can you alter the templates generated? If I have coding standards implemented, I have serious doubts the default RoR scaffold templates specifically adhere to mine. If I can't alter these templates, the answer to the article is no. If I can alter these templates (I assume it's possible), the answer to the article is yes.
How is this article generating all this Ruby-anti-Ruby nonsense when it's a question of Rail implementation? More importantly, why isn't there a PHPoR?
Re:Uhm... (Score:3, Informative)
Biscuit: http://bennolan.com/biscuit/ [bennolan.com]
Qcodo: http://www.gadgetopia.com/post/4726 [gadgetopia.com]
Cake: http://cakephp.org/ [cakephp.org]
Re:Uhm... (Score:3, Interesting)
Re:Uhm... (Score:4, Informative)
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... (Score:3, Informative)
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)
Re:Uhm... (Score:2, Funny)
No, but interpreters have always slowed me down.
Re:Uhm... (Score:5, Insightful)
If you're writing the original app using a code generator and making all subsequent modifications to the software by modifying the product of the generator, you've sort of missed the point.
Re:Uhm... (Score:3, Insightful)
Code generation methodology (Score:4, Insightful)
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.
Re:Uhm... (Score:5, Informative)
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.
It's obvious... (Score:5, Informative)
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.
Re:It's obvious... (Score:5, Interesting)
Ruby on Rails is great. At the very least, everybody should try it. It's no silver bullet, but it is a huge improvement over most everything else out there.
Using Rails is a bit like using a Mac: you always run into these little helpful features that make you think it was created just for you.
Re:It's obvious... (Score:5, Informative)
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:It's obvious... (Score:5, Insightful)
Here's how I'd look at the problem. I'm not a developer, but I'm decent with Java, C++, Python, and Perl. If I look at some random Java project, I can pretty much grok what it's saying and make the changes I need. The same is true for many languages I'm not really familiar with, like Lua and php (I've been updating a WoW mod that was dropped by its creator).
Now, mind you I might just be upset because I looked at RoR and didn't instantly understand everything. But I was generally put off by the amount of things that were being invoked as if by magic, and I'm even less of a magician than I am a developer. At least with some Java project I've got all the code in that directory, and I know which parts of the standard API and which 3rd party modules are being imported. I looked at some of the stack traces that I got and I was totally bewildered.
One thing that could alleviate this is good documentation. The majority of RoR docs I've found are written by people who either have no intention to truly impart knowledge or don't have the competence, and are directed at non-programmers. They're consummately infuriating. I would much rather hear the ugly truth (I read Programming Perl and Python in a Nutshell for leisure sometimes) than be treated like a child. This pretty much means I have to read the API specs, which ain't no walk in the park.
What this boils down to is if I were in a management situation, I wouldn't know how to hire or deal with a Ruby dev. First off, I couldn't just get somebody I thought had good character, work ethic, an excellent track record and a portable skill set, I'd have to hire a Ruby on Rails Developer. I mean, there are some times when you really want an expert in the field, but those people are hard to come by. Then if I hired him I'd be like, "Hey John, what's this function over here do?" and he'd be stirring a black pot in a pointy hat while cackling, "Double, double, boil and trouble / Fire burn and cauldron bubble!"
Yes, very (Score:5, Interesting)
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.
Re:Yes, very (Score:2, Informative)
Re:Yes, very (Score:3, Informative)
Bruce
Re:Yes, very (Score:2)
Re:Yes, very (Score:5, Insightful)
It's called not doing stupid stuff. Now, I don't know much about Ruby, but in Objective-C, these things are called Protocols, and in Java, they're called Interfaces, but the rule is that if you implement a given protocol, then you must conform to a given contract. Can a developer deviate from that contract? Yes. Are they fucking retards if they do? Absolutely! If you want to prevent that, your only option is to work with a language like Eiffel which incorporates design-by-contract at the language level... of course, even that isn't foolproof.
Re:Yes, very (Score:2)
Thanks
Bruce
Re:Yes, very (Score:2, Informative)
Re:Yes, very (Score:3, Insightful)
Coincidental naming (Score:3, Interesting)
I implement a function with a name "join" without knowing what the rest of the world uses it for. (e.g. my "join" joins a chatroom, but the standard use of "join" is to concatenate all of the objects in an array together into a string.) Suddenly my object looks like a duck, and quacks like a duck, but doesn't act like a duck. Ruby thinks it can be used in the same context that everything else uses it in, but semantically it can't be used ther
final void superClassMethod() {} //WO > RoR? (Score:3, Insightful)
Well, if you make a method final in Java, the compiler generates an error when you try to compile an overridden subclass method. That's one way to take care of the problem :-) Perhaps Ruby has something similar...?
RoR, codegen.. from what I gather, there's nothing there that wasn't done years ago. It's called WebObjects. [apple.com] So far, no one has mentioned to me or pointed out anything RoR does
Re:Yes, very (Score:3, Interesting)
Eivind.
Re:Yes, very (Score:5, Insightful)
Re:Yes, very (Score:5, Funny)
Re:Yes, very (Score:2)
Or you could just be incredibly elitist about it and shame bad coders into never publishing stupid crap for other people to see or maintain...
Jasin NataelDoesn't work. (Score:4, Funny)
Sadly, the stupid are shameless.
Re:Yes, very (Score:3, Funny)
No, the key is to have a superficial language feature that has no impact on development time but keeps people away.
Tons of parentheses seems to work well. Using indentation to delimit is another approach that's still in its infancy.
Re:Yes, very (Score:4, Insightful)
Ruby's lack of typing does make it incredibly flexible, but it has significant disadvantages to, namely that a whole class of programming errors which should be found at compile time, go totally unnoticed until the program tries to execute that code path and finds that it has an object of the wrong type.
Don't get me wrong, I program Java at work and hate it, and I program Ruby for play and love it. But I still think we can do significantly better.
Languages like O'Caml, manage to get the best of both worlds. For example, you can write a method in O'Caml which takes a object as it's parameter and uses a "compare" method on that object. Elsewhere in your program you try to call this method with an object that doesn't have a compare method. Not only will O'Caml detect this error at compile time, it can do so without forcing the programmer write type declarations everywhere.
Sadly O'Caml isn't the answer either, it doesn't have a remotely decent web application framework. But I think that combining strong typing with type inference is the way to go for rapid prototyping environments.
Re:Yes, very (Score:3, Interesting)
Only if the object's type is explicit at some point in the function call tree at compile time, I suppose. I can think of dynamic scenaroios where this would not be knowable at compile time.
Static checking as you describe would involve propogating type information from the called function up through its callers while that call sequence is being checked. While nobody doe
Re:Yes, very (Score:2)
I honestly don't know if it's something that could be considered remotely decent (I don't do web apps and thus have no first-hand experience with it, or well, anything else in the genre), but have you looked at AS/Xcaml [asxcaml.org]?
Re:Yes, very (Score:3, Insightful)
I disagree with this. I recently had to debug some RDoc code to create a custom generator. RDoc a big chunk of mostly uncommented Ruby code. Trying to debug and understand it was somewhat reminiscent of trying to debug Perl. Ruby gives a programmer the same expressiveness that allows them to write highly cryptic sh
Re:Yes, very (Score:2)
Thanks
Bruce
Re:Yes, very (Score:3, Insightful)
Java Interfaces (Score:2, Informative)
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 i
Re:Java Interfaces (Score:2)
Bruce
Re:Java Interfaces (Score:2)
Don't take this as an objection to type-checking, I agree that it can be useful.
So, say I do want to add a new method to Enumerable. I add it to one object, and I make use of it in one place. And the system doesn't complain, and I can add
Re:Java Interfaces (Score:2)
(Not meant to rag on Java - I love the whole strong typing object orientation and understand the design choices against multiple inheritance
Re:Java Interfaces (Score:2, Interesting)
How? If I have an interface with a method "quack" that is supposed to print a message from a string you pass it, and I write a class implementing it that calculates the factorial of 1,023,342 instead, you can call it, and it will compile and even run, but still violate the contract of being a duck
Re:Java Interfaces (Score:3, Interesting)
I call BS. Just because a Java class implements an interface, does not mean it implements what is expected of the interface. If your compare method returns a -1
Re:Yes, very (Score:3, Interesting)
Hibernate, Struts, Spring, and so on add facilities to Java that bring it more in the direction of Rails. There's a famous example of a Java programmer who set out to show that he could write concise code in Java on a par with RoR. He attempted to duplicate an existing RoR program. He sent the result to the RoR creator, claiming success. It's three times the size of the equivalent RoR code. So, I'm still waiting to see someone mak
Get the basic premise right, first (Score:5, Informative)
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.
Gem up on Ruby First! (Score:5, Insightful)
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.
Re:Gem up on Ruby First! (Score:3)
Myself, I'm in that situation. I've never done any coding professionally except to support my own work as network admin. Having started in Perl, every problem I come across I try to solve in perl (even when a simpler shell script would suffice).
Now that I'm giving rails a try, I find myself frustrated because I realize I know nothing of ruby. So next step (for me) is to put aside rails and learn some ruby. Rails will come afterwards.
If you want rapid application developement, I'
Re:Gem up on Ruby First! (Score:2)
It isn't really code generation (Score:5, Informative)
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" (Score:2, Informative)
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
This is your typical dev-versus-admin mentality. (Score:3, Insightful)
Now add the additional idea of a custom-designed project that the dev put together - and didn't document (because devs never document, right?). Chaos ensues.
Bad OO Substitute? (Score:5, Insightful)
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.
Re:Bad OO Substitute? (Score:5, Insightful)
Thanks
Bruce
Re:Bad OO Substitute? (Score:4, Insightful)
Re:you reveal your ignorance with your poor exampl (Score:3, Interesting)
No it can't, it's immutable. Strings can only create new objects which have grown or shrunk. Admittedly, the optimised implementation uses the same backing array for the new String, but it's still a new String. A StringBuffer (which in my books is another string class) can dynamically grow and shrink. In 5.0/1.5 there's now also StringBuilder.
Re:Bad OO Substitute? (Score:4, Interesting)
In practice, strong typing and the lack of Ruby-style dynamism allows compilers and runtimes to make optimizations they otherwise couldn't. Those matter, a lot, try looking at the memory usage or execution speed of your average Ruby program sometime! Worse, it's an unfixable problem, at least without modifying the language itself quite heavily.
I think the way we're going to go with language design, as an industry, is more like Boo [codehaus.org] - a language which on the surface looks like Python and has many of the clarity and programmer efficiency features that make Python so much fun to use, but under the hood is actually a traditional strong/static typed language. In Boo, type inference is used to let you drop many of the redundant type declarations that normally clutter up Java/C#/C++ style code, and a smart compiler plugin system is used to let you add new features to the language easily. This is traded off against the ability to do things like add/remove methods at runtime which are hard to implement in a time/space efficient manner.
Re:Bad OO Substitute? (Score:2)
Re:Bad OO Substitute? (Score:2)
I totally agree that a lot of coding done in static-typed languages is simply wasted, since it serves no other purpose then to make the compiler happy, however on the other side I love compile-time checks, far to many times I had some piece of Python, Ruby or some other dynamic typed language which ended up just being a *HUGE* pain to
Try Ruby here! In your browser! Painless! (Score:5, Informative)
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.
Wrong Idea (Score:3, Informative)
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.
Scaffolding is exactly what it says it is. (Score:3, Insightful)
You're reading too much into it. Just like when you're building a house; you put the Scaffolding up to give you something to work from. When you're done building your project, the Scaffolding is gone.
We've been told... (Score:3, Funny)
Re:We've been told... (Score:2)
Re:We've been told... (Score:2)
I think it is more likely they didn't want to foment a general revolt amongst their Java devs. It kinda sucks to learn you can do the same things in 1/3 the time or less by changing languages.
But perhaps you meant this all along and I didn't pick up on your subtle humor.
Code Generation - Negative Image (Score:2, Insightful)
Re:Code Generation - Negative Image (Score:2)
Rails is more then meets the Eye (Score:4, Informative)
ORM and MVC in the same framework (Score:2, Informative)
Where I think Rails comes out on top is the fact that it includes a full blown ORM and an MVC i
Code Generation in Rails is No Big Deal (Score:2, Insightful)
The only time code gets generated for you automatically is at the very beginning of a project to create "scaffolding". That scaffolding is great, because it lets you get something up and running very quickly, but in my experience, it NEVER survives in the body of the project for long--you always want to do
Nobody even uses the scaffolding anymore (Score:3, Funny)
Eh kindof (Score:2, Interesting)
Rails is OK. It's a great way to get into the language and attract users, and for that I appreciate its existance.
That said, as a fairly long-time user of Ruby myself, I wouldn't use it. Many of the features it provides are more academic proof-of-concept implementations than well-tested, well-polished ones. 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. Also, more importantly, it doesn't provide an application layer
Re:Eh kindof (Score:3, Informative)
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. Th
Re:Eh kindof (Score:5, Informative)
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.
Re:Eh kindof -- Idiot (Score:2)
Criminy, that's a hard post to read. Use blockquote instead of bold! ;-) Anyway:
Rails requires you do a lot of stuff like do manual updates on objects, write literal SQL strings in your code, and other similar little things that could, with some creative ruby, be done
Author has it all wrong (Score:3, Informative)
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]
TurboGears (Score:3, Interesting)
It's been raising quite a storm lately, and for a good reason!
Template System for RoR (Score:2)
I'm a PHP / Smarty developer and have really liked it.
I know there are some great templating systems out there, like Canny (very closely based on Smarty but not made for Rails).
Ideally I'm looking for something that works seamlessly with Rails and is close to Smarty in concept and functionality. Canny for Rails would be perfect. (Or has someone found a way to use Canny with Rails?)
Re:Template System for RoR (Score:2)
I'm still trying to wrap my head around Ruby and Rails, and was investigating templating engines to try and decide whether it was worth the time to continue learning Ruby and Rails. I've been doing PHP and Smarty so long that I'm very used to them, so changing isn't
Maintainability of Code Generation (Score:2)
To talk about this intelligently, lets split it into 2 kinds of generation: the 'one-off' code generation that occurs once, in order to get something up and running, which is then maintained on its own, and the 'generate every time you build' mentality of things like XDoclet (to mention one of many). Both have their pros and cons.
With one-off code generation, (which is what Rails is), you gene
I use Ruby on Rails and Java (Score:2)
After heavy experimenting with Common Lisp, Python, and Smalltalk based frameworks I have decided to base my consulting business on just Ruby on Rails and a subset of the Java J2EE stack. I am a little prejudiced on language choice since I have written 5 Java books and I am working right now on a Ruby boo
How about a little research first (Score:2)
RoR generates complete, readable code for you when you ask it to (the scaffold), but once you've done that, you're typically going to go modify that yourself. It's relatively simple, logical code. And it's a one time deal. You will typically intentionally go modify that scaffold code, unless you're doing something really simple.
Besides, if you wanted to know how maintainable RoR code was, you could have followed any of the many
If you think Ruby on Rails is scary... (Score:3, Funny)
RoR & Maintainability (Score:3, Informative)
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.
RoR HLL maintainance nightmare (Score:2, Insightful)
Yes, if poorly written and
Yes, when applications get very, very complex--which is a given. And they will get very complex, just wait 2 yrs.
Consider the great development tools of RoR such that you end up with a Microsoft environment/paradigm--great for RAD, not so great for critical systems that need to be up 24/7, 100%.
I'd still go with XML Schema-based code generation, much more stable
Structure generation vs code generation (Score:4, Insightful)
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 [loudthinking.com]
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.
Static vs Dynamically Typed maintainability (Score:5, Insightful)
SQL (Score:2)
generation gap pattern can add maintainability (Score:2, Informative)
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.
Automatic Code Generators (Score:2)
I've believed for the last few years that automatic code generators (*) are a bad idea.
I haven't spent too much time looking at RoR, except for reading some introductory docs. But when I ran across the code generation bit, that set off alarm bells.
I've used automatic code generation systems a few times. It was always inconvenient. There were always instances where you wanted to do something the code generator couldn't do by itself, so you had to drop into the programming language itself. One syst
Automatic Code Generation sets off alarm bells? (Score:4, Interesting)
A compiler is a form of automatic code generation - you don't compile your source by hand, usually, you let the compiler do it. The compiler becomes a cornerstone of your industry and is trusted perhaps far beyond what it really deserves. But the important thing is that it is hopefully consistent and can compile to a lower form much more accurately and faster than you or I or anyone can. You can make large scale higher-level changes without worrying too much about the effects of these at the lower level.
Unfortunately all generalisations fail when you talk about specifics and the implications of this don't need stating, but I think it's unwise to say 'automatic code generation sets off alarm bells' when it is more accurate to think 'writing it manually should set off alarm bells' for many implementations.
Generated Code? (Score:3, Interesting)
I do, however, use the basic "scripts/generate " scripts. They save me a minute or two of creating files and directories and class definitons. Handy, I suppose, but I am not sure if this is considered "generated code." The only "code" that Rails really generates for me is HTML and SQL (Tag Helpers and ActiveRecord) which is pretty nice, actually. The less HTML and SQL i have to write and more I can focus on the actual code, the better.
Re: code generation replacing OO model:
I have no idea what the OP is talking about. RoR is pure OO.
Probably the only thing that I find a little frustrating about RoR is the shear volumn of files involved in a project. Navigating through them gets gradually more time consuming.
-matthew
The hard part is writing, not maintaining (Score:4, Informative)
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... (Score:5, Informative)
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.
Common Misconception (Score:4, Insightful)
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 [onlamp.com] 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.
Re:Here's an AJAX example - how good is RoR for th (Score:2, Informative)
I honestly couldn't think of a better way to do something like that than with Rails.
Re:Before worrying about a maintenance nightmare.. (Score:2)
Re:Perhaps (Score:2)
Wow, it's a fault of the technology that the people who run your server farms aren't well trained for the job they're being asked to do? Nice logic there.
Usage of RoR (Score:5, Interesting)
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.