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?"
You'll re-write them entirely and check your new code into whatever source-control system you prefer (SVN, Darcs, etc) before your first day is over.
You seem to be under the impression that the "scaffolds" in Ruby On Rails are all there is. That's not true.
Once you abandon the scaffolds, you can do whatever you want. And it's easy to maintain.
You don't know what you're talking about, in other words.
> 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.
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
Devs are always looking for ways to reduce the amount of time it takes to code something. Admins are always looking for ways to automate their jobs. RoR is nice for devs but makes the admin tasks pretty hard - unless the admin knows his way around the product about as well as the dev does.
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.
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.
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.
"...So I hung back and lurked. For 18 months. Can't beat a good old-fashioned lurking."
The submitter hasn't done the barest of investigation into rails. if he had, he'd know that there's hardly any actual code generation (apart from generating stubs, which is actually useful).
rails apps (of which i've written several) have the smallest codebase i've ever seen for any application, and are therefore eminently maintainable.
ruby itself is a significant contributor to the success of rails due to its concise nature, and phenomenal abilities with regard to modification of instances at runtime.
submitter needs to do some homework.
Once you abandon the scaffolds, you can do whatever you want. And it's easy to maintain.
Very helpful answer. Gee, I can also get rid of RoR and just use Ruby too. So is your answer: RoR - scaffolding is maintainable? Is there other stuff you need to jettison? Any best practices, real world experience? Thought so.
You don't know what you're talking about, in other words.
Well this is *Ask* Slashdot, not *Tell* Slashdot. And not that you know much of anything either judging by your entirely useless commentary.
Automatic code generation sets of alarm bells in my mind;
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.
To stay FAR FAR AWAY from Ruby on Rails here. In fact, they sent us java developers to the Java conference and we were forbidden to go into any of those seminars. Why? Probably because they don't want us picking up any bad habits.
Yes, there's a lot of "automatic" code generation in the demo video(s), but the reality of rails programming isn't anything like that.
There isn't little to none code generated when you use the generate script, mostly it just creates the files, class definition, and maybe a default call to 'scaffold'. That's all there is, so you wouldn't have to "re-generate" anything when a new version comes out. And the "scaffolding" is only good while the site is "under construction", you should have implemented all of the methods the scaffold offers yourself by the time the project is ready.
The only maintenance you'd have to do is when the API changes, and ruby is as vulnerable here as any language.
I think a lot of the "it's not maintainable or scalable" assessments of Rails come from people who have seen its code generation and "scaffolding" features and think that those are the main advantage of Rails. It's true that one can only do so much with the "scaffolding" which is simple and generic. However, the real power of Rails comes not from the scaffoldings but from the framework Rails provides in which to write custom code. I've written two Rails applications and maintained several others. None of them used the scaffolding provided by Rails - they had all hand-written code inside the bare-bones Rails-generated structure. Those applications have proved to be easily maintainable. It's a shame that most of the introductory tutorials/examples/videos for Rails focus on the scaffolding features, because that leads people without much Rails experience to believe that the scaffolding is all there is to Rails and form a (usually poor) opinion based on that.
chown -R us ~you/base
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 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 if interested.
I've been using Rails for several months, and I think it's "automatic code generation" is no big deal, and nothing to worry about. If you're worried about maintainability, it the wrong place to focus.
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 something differently, or more elaborately, than what the scaffolding provides.
So, I think of Rails' scaffolding as "stub" code that happens to include some (very) basic functionality. Like code stubs, they just provide placeholders for you to use to flesh out your own code.
Once the project is underway, it's unlikely you will generate any more code automatically--you don't need to.
It's worth noting that what I've described here is the behavior and usage of code generators that are included as part of Rails. There *are* some cases where people have written code generators that attempt to automatically generate entire subsystems for you in a Rails app--and those generators are the subject of interminable support questions in online forums, and a lot of discussion within the Rails community as to their wisdom. . . which is why no generators like that are included as part of the Rails distribution.
Beyond code generation, I can't say anything definitive about Rails maintainability because it's so new, but my feeling from having worked with my own code, and from having studied the code of others, is that Rails apps should be wonderfully maintainable. After all, the "opinionated" style of Rails leads all Rails apps to be laid out the same way, with the same directory structure, the same application architecture, coding standards, naming standards, etc.
From my experience so far, all these things are likely to make Rails a winner from a maintainability standpoint, as well as in terms of productivity and fun!
In short, yes. I have been working with Ruby on Rails since the beginning of November. I found it to be fast, easy to learn & Maintainable. I am working on an application at work where I have had to make several modifications due to changing requirements. In each case, it was very easy to figure out where in the ROR framework to make the changes and apply them. The results (due to Ruby) were instantaneous and the Users loved the rapid turnaround time. My experience w/Ruby has made me a convert.
Unless they're making a promotional movie on writing a slashdot replacement in 5 minutes
Is that fairly easy to do in RoR or is that not how RoR is meant to be used?
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 that entirely abstracts the functionality from the interface. This is bad for any number of reasons. 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.
That said, if you're interested in Ruby and/or Ruby on Rails looks cool to you, check it out and play around with it. It's also not the only thing that ruby provides to develop applications, even web applications. If you're developing a more serious app, you may look at stuff like PageTemplate for the frontend, ObjectGraph for your ORM, and soap4r for services.
So regardless of your stance on Rails, check out Ruby... there's a lot of cool stuff.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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!
Tapestry is also doing a lot of code generation in Java. You simply write your classes as abstract, create abstract bean members (getters/setters), or other annotated values, and it'll generate the underlying code.
This is great for rapid prototyping and getting your application to a usable point. Then, as you need to, just implement the members as needed. Many times you won't need to set things, because you'll be reading from an underlying object and then doing set's on all the properties, and doing get's to set the underlying object during a save.
It takes some getting use to. The jury is still out for me too.h
It depends what you mean by maintainable. Is it maintainable by the lone cowboy coder (or small group) who writes their own apps? Sure! When you talk about maintainability in a large production environment it's a little different. I've run into issues at work where the Rails apps I've written are hard to maintain because the people who run our server farms aren't familar with the technology and how to support it. (They don't like that I'm running Apache!) So, maintainability in that sense, I'd say RoR is not quite there (but it's getting there real fast).
As for the "automatic code generation" it's not quite that, it's all done behind the scenes (and scaffolding is only part of it). I see how the "alarm bells" can go off because seeing the actual 'code' generated makes a programmer feel all warm and fuzzy inside but really, it's not that big a deal.
I honestly couldn't think of a better way to do something like that than with Rails.
i think you're touching a sensible subject.
with autogeneration can you really maintain your applications and more important, what happens with future versions of RubyOnRails ?
Will thoose autogenerated scripts still be usable ?
Does the ROR developpers have to write migration scripts for your scripts everytime ?
With plateforms like Zope, as soon as structure is not changed the scripts are much more reliables.
----
Gavroche Le Gnou
Flash Xml Multi-User Socket Server
In the meantime, if you want rails-like development but with Python check out TurboGears.
It's been raising quite a storm lately, and for a good reason!
Save your wrists today - switch to Dvorak
I'm interested to hear what the Slashdot community thinks is the best templating system for Ruby on Rails.
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?)
Lose Weight and Feel Great with Isagenix
Forgive me but I've been using rails for over a year and it would seem the parent is posting FUD. You'll have to explain yourself in more detail.
Many of the features it provides are more academic proof-of-concept implementations than well-tested, well-polished ones
Which features are you talking about?
It requires you to do a lot of things manually that could easily be done automatically
Give an example. This should be pretty easy, but I've found I'll often try and automate something and down the road it turns out to be more maintenance than if I were to have just hacked it out.
I have a pretty large ecommerce app and the only raw SQL I have to write are where conditions, which arguably could have been written out in Ruby but that would probably be more work and no gain.
Also, more importantly, it doesn't provide an application layer that entirely abstracts the functionality from the interface.
I'm not sure I know what you are talking about, because my interface is for the most part completely separate from my processing. Interface goes in my views and the processing happens in my controller. Explain this please.
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.
Pretty much tied to MySQL? It comes with connection adapters for both MySQL and PgSQL, and it works fine with both of them. This aught to be a pretty good reason not to trust anything you have said. You have no idea what you're talking about. It doesn't make use of any MySQL-specific features like enums, everything is abstracted down to basic SQL.
If you're developing a more serious app, you may look at stuff like PageTemplate for the frontend, ObjectGraph for your ORM, and soap4r for services.
There hasn't been nearly as much testing and development going on with those projects. I don't know how you could say they are for "more serious apps". You would probably spend at least twice as much time developing an application with one of those.
you should first look at the functionality nightmare that exists. Ever try selecting a table twice in an sql query (aka joining it to itself)? It can't be done. Try a different language, something that isn't a maintenance nightmare and isn't a functionality nightmare. Try python.
The author's concern could be expressed about the maintainability of generated code, whether in Ruby or Otherwise.
//** your code to be put here //** end of your code
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 generate the code that gets the 'skeleton', but from there, it is something you have to maintain yourself. You have to understand what you are generating and maintaining... you might as well think about it as starting our having to maintain someone else's code (which really, it is). As long as you understand the generated code, this is not a problem. one-off code generation is simply a convenience for getting started, it is not a replacement for knowledge.
With build-time code generation, you are ideally automating something that you would have to understand in order to keep up with changes elsewhere in the system. While it might be automating away some drugery, often times you also end up automating away 'layers' that you don't want or need to understand. This is where the maintenance nightmares of generated code come in - you have to hook into stuff you don't understand, often by inserting code in between comments that say something like:
When this is done well, it leads to the dream scenario of getting 'something for nothing' where it is not done well, you create a 'culture of ignorance' that simply guarantees you won't know how to solve the problems you inevitably end up creating.
In my humble conclusion, rails-generated code is VERY maintainable, but you are not off the hook for understanding what has been generated.
Typo: It comes with connection adapters for both PgSQL and Oracle, in addition to MySQL, and a few other databases.
Wow - what a bogus premise: off course Rails based web applications are maintanable. I consider maintenance and modification costs to scale fairly linearly with code size and Rails applications are concise.
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 book for Manning; and on Monday I spent a half day creating the RubyPlanet.net news site. Still, I enjoy Lisp, Python, and Smalltalk and gave web frameworks written in those languages a good evaluation.
I just use a Ruby dispatcher that doesn't require rails, it just loads Ruby apps like php-cgi.
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.
That's not true, self joins are very common and usefull.
Before posting a question like this, how about researching RoR just a little.
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 tutorials to see how they make changes after having "generated" code.
.sigs are for post^Hers.
While working with the corporate software process group at SAIC (I was managing the automated ordnance inspection software department at the time) it became apparent to me that most of the software process is reducable to a human-mediated build/compilation process where the "source" language is the formalism used for specification. Since the highest level language for specification is predication (largely of pre and post conditions of the system's operations) it became apparent that predicate calculus tools -- not necessarily direct execution thereof -- could be very important for automating large portions of the software process.
Since Rails isn't high enough level, its specification language is inadequate and the resulting code generated must be edited directly. But it is a step in the right direction.
Seastead this.
You've obviously never worked with ASP.NET.
You have two hands and one brain, so always code twice as much as you think!
The code generated by Ruby on Rails is intended just to get you started. It also happens to be a completely optional step. You can choose not to use generated code. In my experience so far, the generated code is not adequate for writing real applications, but serves more as a pointer on best practices to use for dividing the work to be done between the model, view and controller.
... so don't complain if you selected the wrong tool for the job. Would you blame dBase for not letting you speak SQL to it?
I didn't like the scaffolding code that was generated and went off to change it, basically, removing a whole generated view/controller, and merging it into another view/controller. After I did that, it seemed to have too much duplicated functionality, and I had a choice between making methods that take classes as additional arguments, and splitting the functionality into similar but separate files. I chose the latter and after refactoring, guess what? I was back to the beginning, which sort of taught me that the default division of labour is a pretty good one.
I don't plan on using the generated code to write the rest of the views and controllers in my project. Why? Just looking at the one class for which I generated a scaffold, gives me a good idea on how I can handle the rest of the code. To believe that Ruby on Rails will write your application for you (which is what you seem to think, as you are complaining about maintaining lots of the generated code) is not correct. No computer will write your code for you properly.
Scaffolding is just to help you get started. You aren't supposed to use it in production. Why don't you also complain that the scripts/console in Rails doesn't print out HTML? After all, because you got a tool to help you look into your domain model, and it shows you what is going on, and let's you type in your own Ruby as well, then why not complain that it doesn't write out the HTML too?
My point is that the point of scaffolding is not to build your application for you
"Rails is not a code generation tool"
Have you really use it?
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.
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 automatically. On the count of SQL, and at the risk of self-promotion, check out Criteria, which lets you write literal Ruby statements that are transformed into SQL, all in a ruby-esque manner.
For the latter count, it is easy (or at least, not very difficult) to implement a system that does implicit object persistence. I have such a system called mephle, which you can see the latest version of in the SVN repository, but it's not documented well enough for general use, and I wouldn't advertise it as such. However, it shows that such a thing is not only possible, but pretty straightforward.
This is just poorly-designed automation, then. There is a clear line for where automation should end and where manual usage should begin. Follow these rules:
If you have a system that follows the above rules, you will find yourself writing much, much less code and focusing almost entirely on the problem at hand. And it's possible to write such a system, especially in ruby---see above.
The fact you have HTML in a separate file from the code is not sufficient for full separation. You should be able to entirely drop the web interface and instead write, say, a GTK or commandline app, without changing any of the backend code.
Then you have not seriously used it with other databases. I recommend you hop on #ruby-lang on irc.freenode.net (I'm there as oGMo as well), and ask around for people's experience with Rails and other databases.
Uh, you have metrics for this where? All of the above modules are much older and more developed than Rails. Rails is the new kid on the block, and it's still got a lot of growing up to do.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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 as it forces you to thing about state and behavior before you write your first GUI title bar. And since the web is XML-centric, makes sense..
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/
I consider Rails to be nothing more than a collection of programming "best practices". I try to use many of the same techniques in my own programs. Indeed, I had a home-brew Perl framework that used some of the same techniques that Rails' Action Pack uses and I considered it my "secret weapon" for rapid development (NOT "prototyping".. just fast coding that doesn't waste time). As others point out, Rails is not about the "scaffolding".. the abstractions are deeper and more general than that.
I've been doing this programming thing a while and I consider it perfectly natural to "write programs that create programs". It's NOT code generation (that's when one program spits out a text file containing another program).. it's just dynamic programming: meta-programming and late binding and lots of run-time decisions. Sure, if you're not experienced, or you're still learning Ruby syntax, you might feel frustrated with an abstract meta-language. You should use the opportunity to learn and dig deeper, in my opinion. So 9-to-5 Java grunts may not enjoy digging deep in Rails, but maybe an old-school Lisp hacker would. Which would you like working at your org, anyway?
Ruby and Rails are great examples of why all that "metaprogramming stuff" is good to have in a language.. even if you don't personally use them, someone can create something cool with them that you can use.
So Rails code is very concise and well-factored, which is good.
BUT.. there is an unfortunate dark side to Rails. The author may be very bright and have great insights in procedural programming, but he simply does not understand data modeling, or it was not taught to him in school, or he chose to ignore it when it was. He thinks the logical model exists only in his code, and advocates a 1960's pre-relational style of application-centric data management. In fact, the Rails theoretical model is nothing more than the old network "model" (navigational queries, universal meaningless object ids, and no high-level declarative abstractions.. the programmer does the work). The Rails community, containing many data management novices eager to avoid having to *think* (this is different than doing less work!), follows right along. Some of the stuff in the Rails mailing lists and blogs is quite silly and flies in the face of data management best practices.
I would like to see an RDBMS that uses Ruby syntax and Ruby attribute types.. it would be a perfect companion to Rails, and would be easy to use and understand. I really get tired of these object-to-SQL mapping anti-patterns. Until then, anyone starting a Rails (or any other app) would be best served by ignoring any data management advice from the Rails community and learning some basic skills FIRST.. so your apps sit on a firm foundation! Rails, being well-factored, thankfully doesn't get in your way if you choose to do this.
So to answer the question.. yes, RoR apps are highly maintainable, provided you 1) understand the Ruby language and the Rails codebase, and 2) properly create your logical model *first*. And if RoR turns out to be the wrong choice at your org, a solid foundation will let you build new apps in a different framework without fear of conflicting with your conceptual model. Yes, having to do #1 and #2 means you have to actually spend some time learning before diving in and developing that critical multi-million dollar e-commerce site.... no framework can be a substitute for knowledge!
The problem that he's referring to in ruby is coincidental naming.
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 there.
Inheritance prevents conicidental naming problems by making the default assumption that two similarly named functions *don't* do the same thing, and can't be used in the same place. You override this assumption by indicating that the class inherits from a certain class (C++) or implements a certain interface (Java).
OO means that objects are typed, and this is enforced by the internal API for accessing them. Static compile-time typing is a kluge to work around a broken type system that does not, indeed cannot, enforce typing at run time. This is a bad imitation of OOP, although it is capable fo running pretty fast (until a bug sneaks around the type assumptions at run time and crashes it). It is a brittle and inflexible, and the baroque superstructure that is C++'s template kluge (for example) is a testament to how badly its type system is flawed at its core. Of course a lot of folks mistake that for a feature: it is in fact a symptom of a fundamental design problem in the language.
Executive summary: Eschew premature typing
Slashdot simplification: C++ suxors!!!
It is a very immature framework, specially when it comes to Enterprise applications.
For example any real enterprise application requires end to end transaction support. Does ActiveRecord handle that? What if the transaction is distributed across systems like mainframe 3270 terminals, couple of web services and some database access? I'm sure doing this in RoR would be much harder and probably take more code than doing it in robust enterprise frameworks like J2EE.
What about LDAP support and single sign on?
I could go on and on... based from the advertising pitch of RoR it seems RoR is just a glamourous framework for managing database tables. I can use any existing DB management tools to do the same with no code as well.
RoR is just hype, using a pretty clever marketing strategy (I'll give it that). The videos were a cool marketing ploy and it sure fooled a lot of people.
So no, in summary RoR is not a replacement for J2EE, it is not an enterprise application development framework. It is a hype bubble waiting to burst.
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.
One thing that disappointed me when I had a look at Ruby was its SQL interface (at least on Windows for SQL server). I find myself writing the same repretitive code in ASP to connect to a server and execute stored procedures. Same thing in Java with JDBC. I did a quick survery of other scripting languages to see if any had features to let me cut down on this copy and paste coding. Ideally I'd love to just call a stored procedure like a method and let the computer sort it out (you know, let the machine do the repetitive part like its supposed to). Ruby was about the best with cutting out the overhead code, but still not ideal. ASP, Python, PHP and Java all looked about the same. The worst part is I did the same check about 6 years ago and somehow accessing a database hasn't changed. This is probably the most common task in web development and its a pain in the ass. And VB style visual controls never worked well for me, I always needed to do something slightly different with the data so I have found it easiest to put the recordset into objects first, then, display it.
So I've decided to stick with Java, I have about half a framework of my own I wrote and if I wrote some code generation it would do the other half. Perhaps there is some great framework out there that I missed that someone will tell me about, but that is part of the problem too, whatever is out there isn't advertised. Easy database access should be in the tutorial for the language if it exists, instead of the usual inefficient ADO-style examples.
Vlissides' generation gap 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.
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 system I used had a sort of patch system, so that when you made changes and regenerated the code, it would re-apply your hand modifications. Still was klunky. But the programming language (**) was bad enough to work in directly, so I didn't mind the klunkiness.
Needing any kind of code generator, be it a GUI layout tool, or what's in RoR is a realization that the programming language itself isn't capable of further abstraction. I guess there is no shame in that, most languages aren't capable of abstraction beyond a fixed level.
There is a solution to this kind of thing, however. If you have a programming system which is sufficiently expressive enough, you can keep coding to higher and higher levels of abstraction. I'm talking about things like higher-order functions and macros. Not C preprocessor macros of course; I mean Common Lisp and Scheme macros.
With a good macro system (which Ruby doesn't have, but can kinda / sorta get by without) you can abstract away even the boilerplate code. But if RoR needs a code generator, then maybe you really need higher levels of abstraction that Ruby can provide.
I suspect, though that the code generator was the first solution. Someone of sufficient cleverness may be able to find a cleaner and more elegant way to do the same thing without the code generator. Ruby is not LISP, but it is pretty good.
(*) I don't mean code generators in the loosest sense of the term, so this doesn't include compilers and such. I mean programs which generate high-level language code. As opposed to C, which is a low-level language / high-level assembler.
(**) Informix 4GL, for the old fogie DBAs out there. Used FourGen's CASE tools.
Sadly, the stupid are shameless.
I have no experience with Ruby or RoR but I am a software engineer like many people here and I would like to stick up for automatic code generation. Modern software is extremely complex and even when excellently designed and implemented by a skilled person or team it is still subject to faults. Automatic code generation, when done properly, is an excellent way to reduce the effort and risk associated with creating certain types of complex systems. A classic example is a parser - hand writing parsers can be done, of course, but they can be notoriously difficult to test and small grammar changes can upset the entire structure of the parser. In this situation, automatic code generation is not only useful, it's also safer and more reliable. If you have to change the grammar, you just reconstruct the parser code.
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.
And to naysayers for implicit typing, it is used all the time under different looks in real heavyweight production code (C++ templates ala STL style, the multitude of runtime aggregate type systems out there, very late bound dispatching, etc, etc). Note that in some cases (like STL), the 'is_suchandsuch' is not necessary, since C++ templates are a compile-time thing so you get compile time type checking and binding.
Can't join a table to itself in SQL? You have to name the table each time, but it's not very difficult and certainly not impossible. Try something like this:
select parent.name from person as parent, person as child
where child.parent_fk = parent.person_pk;
Regards,
Ross
I started my first real Rails project with generated scaffolding, but after a few days there was almost nothing left of it. And I almost wish I had never generated the scaffolding because I had to spend time cleaning up tons of files and method stubs that I was never going to use.
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
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
I [may] disapprove of what you say, but I will defend to the death your right to say it.
now try that in rails.
Why is it named "Ruby on Rails"? Searching provides no answer.
At least it appears to be.
I'm still trying to learn the ropes.
Laugh at my ignorance while I learn Rails - a Real ne
Rails isn't the evil code generation monster that you make it appear to be. It is merely a set of best practices that you either like... or you don't. Our Rails development team really likes them and we're willing to give up a few of our personal preferences for the sanity of working with a framework that allows for easier collaboration.
;-)
The Ruby on Rails framework just sets the tone for you. You can use the scaffolding generator... but we don't in any of our client products. We might use it to just get a quick CRUD view of the existing data we're looking to work with.
It's nothing more than a well thoughtout set of best practices... and people love it.
The *other* guys are still hung up on their own ideas of what is best for their code... but in the end... we just want to get stuff done. Rails makes that a bit quicker to do so.
Ruby+Rails+PostgreSQL+Lighttpd = Enterprie Ruby on Rails!
RRPL4LIFE.
Robby Russell
PLANET ARGON
Robby on Rails
Is it too much trouble to ask you to proof-read stories? The article links commentary is painful on the mind. Between the liberal use of commas, 'of' in place of 'off' to other examples of "what the hell are you trying to write?" how is it that this type of article gets submitted?
A friend of the crew?
So tell me, why would you prefer the first over the second?
The first can be reused when you're searching something other than a SQL database, for example an in-memory array. Also, the first is easier to parameterize since you don't have to manually build SQL query strings.
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
all the examples cited here about why strong typing is a bad thing and the examples cited to prove that dynamic binding appear to be small, single person projects. totally true for single-person productivity when the only person on both sides of an interface contract is yourself. dangerous thinking for much larger projects. remember: right tool, right job.
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.
You don't even say if you USE Ruby, or Ruby on Rails. If not you are just being opinionated without being informed. Either way, your post is useless.
Well said. In the end, Ruby is just a MVC and ORM web framework, along with a little bit of code generation to get you started. That's basically all good, though :)
On that note, it's worth mentioning the Python equivalent of RoR, since the poster mentioned a python background. Django is probably the best place to look for an MVC/ORM (web) framework in Python, if you're interested in trying it.
SELECT replies.parentid parent, replies.postid
FROM posts thread
INNER JOIN posts replies ON replies.parentid=thread.id
WHERE thread.isparent=1
That's a join on itself, right? Who said it's impossible?
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
Look into acts_as_tree.
c ts/Tree/ClassMethods.html
http://api.rubyonrails.com/classes/ActiveRecord/A
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
When people complained that scaffolding opens up trivial exploits, the answer was "you aren't supposed to use it". Its just there to look impressive in the demo videos, and for people who can't add/delete/edit their database through other means (I have no idea who these people are).
For a number of reasons:
Now imagine how easy it would be to build an interactive report builder with the ability to throw the pieces together in this manner. Yes, it's easy. :-)
I could go on, but this should be sufficient.
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
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
Trees are a bitch no matter which language you use. If you can find a tree that satisfies your requirements then you are golden. But most of the time the "tree" modules/javascript/whatever does not satisfy your requirements.
As an example: most javascript based trees require the entire tree structure to be available before the tree is rendered for the client. This may work for you, it has not for me. Most Ajax tree systems (ie they request the children of a node you are expanding rather then having the information up front) only work if the tree is not able to change. If the tree can change then they do not update correctly.
By the way, that is not specifically ruby related, it is related to the "trees" that are available. Ruby will not help you here. nothing will help you here unless you want to do exactly what someone else has already done.
Okay, seriously. A site full of geeks and nobody's cracked this yet? I'm losing faith in you, Slashdot.
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.
Which, of course, kinda defeats the purpose of automatically generating code in the first place.
So, you've asked the Rails developers what their purpose was in using generated code?
The sole reason Rails has generators is to do the tedious bit that gets you started. That's all it's there for, that's all it was ever there for.
The confusion over this is in large part due to the early Rails marketing strategy of making screencast videos instead of readable documents, IMO; everyone latched onto the scaffold thing because it was visual. But scaffolding is really, really ridiculously unimportant.
If you don't pretend to be anyone, are you?
> 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.
> sets of alarm bells
"Sets"? That's like a collective noun or something, right? Is that the correct one for 'alarm bells'? I think not - Google tells me it should be a 'peal of alarm bells'.
or did you mean 'off'?
yeah, sure, anally retentive; so what?
Max.
I've been working on a few RoR projects and we only use the code generators to create unit test stubs for our controllers and models.
:D
We haven't used scaffolds AT ALL in ANY of our RoR projects. So maintenence as far as that is no problem whatsoever.
Maintaining the code doesn't seem to be any more an issue than any other languages. It depends entirely on how you DESIGN your app. Of course, RoR can't design it for you... But if it doesn't scale it would be easier to blame the framework and not your design huh?
>>>"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."
:) I think Ruby is great -- particularly for code generation.
You're right, Ruby is dense, but things could be much worse: it could have been written in Forth, Perl, APL, Smalltalk, LISP, or Postscript. Did you notice that the developers of Ruby brag how Perl coders can just roll right on over to Ruby -- and it shows in the depth and conciseness of each statement and the decorators you put on the variable names based on their context.
For my first Ruby app I was able to write a complicated (for me) cross-indexing application in Ruby rather quickly and found the language much easier to work with than something like Perl, and it felt I was faster coding than if I were using Python. Also, the equivalent Python program would have been much longer. In terms of using it with the internet, can you imagine controlling spaces inside embedded Python in HTML pages!
To a large extent, the code is the documentation. I think you need more practice writing new apps with Ruby. To be fair, it is a more dense language. But the results are so quick. I'm a VB programmer. I hope to work on VB/Linux if Parrot is ever released.
I am going to let you in on a huge secret. Rails is a WEB APPLICATION DEVELOPMENT SUITE. A GTK application is not designed to be run in a web browser, and is not designed to be served up, and used on many machines at once. I am sure that if you wanted to though, you could write an add-on to actionsupport and allow it to be a GTK app using the proper Ruby Librarys
"Love is like a trampoline, first it's like "SWEET!!" then it's like *BLAMM!*"
For biz forms, it is hard to beat the VB approach as far as productivity and simplicity. Some complain about code duplication, but that is only if you don't factor commonalities to shared routines.
Some also complain that VB forms don't scale to user's screens. I never found that a big problem, but some vendors have discovered "stretch zones" that allow widgets to stretch across the zones. Thus, one can have both visual design and stretchiness.
I miss that approach for web stuff. The current generation of web junk is clunky and wordy and anti-visual.
Sure, the language was sometimes awkward, but that can be remedied.
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. So far, no one has mentioned to me or pointed out anything RoR does in Ruby that WebObjects doesn't do already in Java. Meanwhile you loose the advantage of TONS of mature libraries written in Java. Am I missing something? Is there something particularly compelling about Ruby perhaps? I'm not trying to be condescending toward RoR or anything, but all the 'hype' I've read here about RoR was done a decade ago with WO. Plus, WO does a number of things that I haven't heard the RoR camp boasting, like deploying database connected apps over the internet directly to the desktop with WebStart/D2JC.
Anyone care to enlighten me?
There is _ONE_ string class in java, it's java.lang.String. It can be arbitrarily long, it can dynamically grow and shrink. It could have bells on its toes if you really wanted.
A better example might be the existence of java.sql.Date when we already have java.util.Date, or the confusion-causing collection classes like Hashtable vs HashMap, and Vector vs ArrayList (the formers were part of java 1.0, the latters added later and generally preferable).
- jonathan.
Instead of changing the parameter type String from Integer, why not override the method and declare an identically named one that takes the alternate parameter type? Then new code can use the new method, and old code doesn't break.
What's the problem? Maybe you could provide a better example of whatever point you were actually trying to make.
- jonathan.
I'm not saying the other guy's right, but, er, you're revealing your ignorance a bit. ...it's java.lang.String...it can dynamically grow and shrink.
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.
PenguiNet: the (shareware) Windows SSH client
It's always the same story: there is no silver bullet. Once your application will get "serious", you will have to occasionally dig down to the bare metal and debug at a lower level, optimize for performance, etc. And at that point you will need "real" knowledge. My advice: make sure you learn SQL, make sure you understand how the components work. If you're building the next amazon, forget about all that rapid app stuff (unless you're building a site for a friend which will get 2 visitors per day).
I hadn't done this search for a while but just now I re-did it and discovered that the Mercury compiler now has XSB-style tabling. This is an important advance for practical logic programming.
Seastead this.
Different tools for different people; different tools for different jobs.
I could not agree more. But the important distinction here is that the decision of which tool to use is not solely a matter of personal preference. The particulars of the task at hand also come into play.
It remains to be seen what range of applications RoR works best for - at first glance a wide range of webapps looks promising. The range of apps that Java is good for is fairly well known. Many folks are quick to point out java's shortcomings, but few would argue that Java is the best tool for _every_ job, and oftentimes the perceived shortcomings are actually just a misapplication of the tool. If you try to pound a nail in with a screwdriver, do you blame the screwdriver?
The main problem I have with RoR is that the Ruby language is weakly typed. Automated refactoring tools that can rename methods, shuffle variables and methods around different scopes are very handy and very difficult to do in a highly dynamic language like Ruby. This is not to say that those dynamic attributes don't come in handy in some applications, but for maintaining a very large codebase, refactoring tools are a must-have.
Developers who complain about 'I change this name and the compiler complains' must still be using vi or emacs to write code. IDEs like Eclipse or Intellij make this a moot point.
- jonathan.
Yes, indeed you're correct.
But, from a programmer's point of view, if I do:
String x = "foo";
x += "bar";
Semantically, we can say that 'x' dynamically grew to hold a reference to the new string "foobar". Of course behind the scenes different object instances are created and/or shuffled around behind the String reference named 'x'.
The _contents_ of the string is immutable, but semantically those contents can grow/shrink behind the object reference to them.
- jonathan.
The primitive / wrapper hassle is a minor annoyance, at best. And like .NET, there's the "autoboxing" feature in Java 5 that makes this more or less go away, though you may have to understand its own quirks (i.e. you get consistency at the expense of easy predictability).
-Stu
The author may be very bright and have great insights in procedural programming, but he simply does not understand data modeling, or it was not taught to him in school, or he chose to ignore it when it was.
I've been waiting all thread for someone to finally point this out. RoR is one of the most productive things to come out of the web programming community in a while, but its creator and community are doing a lot of damage to a very important discipline.
The Rails community, containing many data management novices eager to avoid having to *think* (this is different than doing less work!), follows right along. Some of the stuff in the Rails mailing lists and blogs is quite silly and flies in the face of data management best practices.
In fact, many people on the blogs are starting to say that there ARE no data management best practices, as data integrity is bunk, and the database shouldn't manage the meaning of the data. They point to the the whole integration database vs. application database distinction, but that ignores the risks you're taking when you create poor data structures for the sake of programmatic simplicity. And then there's the bigger observation that databases have been the most proven way to integrate systems over the past few decades; messaging works too but is much newer and arguably harder to get working properly.
Then again, I'm an SOA advocate in my day job, so arguably this is where things are heading anyway. I'm around a lot of large organizations in recent years, and there are not very many "web + database" projects anymore; they've built them all. Now it's about integrating these silos as services, to improve the quality of data in the enterprise, consistency in experience, flexibility in business process, etc.. Whereas RoR just seems content with creating yet another layer....
-Stu
Scaffolding is not a concept in rails, it is a single, very specific piece of functionality. Its when you use the actual "scaffold" function on your class. I never said the concept of generating code was flawed, I said rails scaffolding is not supposed to be used.
Oh, but it's hype that has made Java into what it is today...
I18N == Intergalacticization
I'm sure this pattern has a name, but I don't know what it is, so we'll try the verbose explanation.
I have one record in a DB. I want people to be able to edit it and I want the results to be helpful if two people edit the same record at the same time - so that the second saver doesn't save over the first one. Does RoR have something to deal with this?
Even constraining our domain to the world of webapps, I disagree that language choice is an "absolutely subjective" decision. If I were building a simple 2-form webapp then Java would be absolute overkill, when PHP or RoR could get the job done 10x as fast.
So in this case, there is some objectivity to it -- Java entails a certain amount of overhead that is just not worth if the situation doesn't demand it. No one would deploy an Oracle parallel server to run a 3-table database that had no transactional requirements.
- jonathan.
We do rapid application development for the web using Catalyst (http://catalyst.perl.org/) - it's fast, it's MVC, and because it's perl we can leverage the whole of CPAN to avoid re-inventing wheels. It's also (with a little CPAN-fu) trivial to deploy on any host that supports FastCGI, and most of our clients already have enough in-house perl knowledge to be confident they wouldn't be sunk if we disappeared tomorrow.
RoR has a great team behind it and an even better hype machine, but Catalyst simply does the job and does it well - and with mod_perl scales comfortably to huge application workloads.
Sure, but it only takes something as simple as...
...to get down to the fact that it's a new object. This difference can crop up pretty easily when working with Strings...
x="foo";
y=x;
y+="bar";
PenguiNet: the (shareware) Windows SSH client