Slashdot Mirror
Ajax On Rails
mu-sly writes "Ajax and Rails - probably two of the biggest buzzwords in web development at the moment. In this article over at ONLamp, Curt Hibbs introduces the incredibly powerful Ajax support that is part of the Ruby on Rails web application framework. It's a great read, and serves as a gentle introduction to the cool stuff you can accomplish with ease using the Ajax features of Rails."
Every time I see material surrounding Ruby on Rails, I'm further convinced that it could be the web application programming foundation that starts to displace PHP as developers start to look at the transition from PHP 4 to PHP 5. Getting an increased install base for ruby on rails, as is the case with php (a fairly difficult task, admittedly) would definitely help no end in increasing the framework's popularity, at least amongst those programming smaller web applications.
Business Voyeur
b) Microsoft's own technology being used by Google to loosen Redmond's deathgrip on the market?
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Of course Rails isnt the only completely F/OSS web application framework; Rails is best when you want to put relational data online: It's edge is it's simplicity.
On the other hand remember Zope - If you can get your head around Aqusition, the ZODB and Product Deveopment then Zope is a super-fast development platform.
Ajax grew from one of those hated, non-standard Microsoft features.
Help me take back Slashdot. When did 'News for Nerds' become 'FUD and Conspiracy Theories for Extremist Nutjobs'?
You should probably read this paper on scripting
The moral is, no matter how complex a system build on Ruby will get, it will always be more simple to use than a system build on Java, just because Java carries the characteristics of a systems programming language while Ruby carries the characteristics of a scripting programming language.
Scripting is not a holy grail. The only fundamentall advantage of scripting is name-based polymorphism (i.e. dynamic dispatch), it allows you to skip extracting common interfaces in your object model. As the software grows this advantage soon becomes negligible, and may even turn to disadvantage, because you'll have to find and isolate general interfaces manually.
I am sick of seeing this excuse. You can't run around the internet screaming how rails is the greatest thing since the wheel, and how it renders java obsolete because its 100x faster to work with, and then say "its not done" when people actually try to use it. If you are ready to hype something and tell everyone how great it is, then you need to be ready to accept criticism too. If we can't compare it yet because it isn't finished, then stop running around telling us how great it is and how we should all be using it.
A web application framework that includes a web application program generator
No, Rails generates many methods "on the fly", but it doesn't generate any program for you. You still have to write the program. However, there are many cases where if you don't write your own code for something, Rails will supply a "default". When you get started writing your app, do you really need to waste time writing code to "display the template"? No, rails does it for you and chooses the template with the same name as the action. However if you need it to do something different, which is common, you simply have to add the one line of code to render the template. This saves a lot of time!
Think of it this way: when you log into a Unix shell, you need to "ls" some files, "cp" some files, etc. Luckily, most Unix shells have those commands available, already written for you. Does that mean you can't write your own? No. Does that mean you can't customize what they do? No, they have lots of flags. Do you often need to write your own? No, usually the existing functions are good enough.
That's what Rails is: a domain-specific language for writing web apps. Of course you can throw all that out the window and write *any code you want*, Ruby is a general programming language, but it's kinda silly to waste your time like that.
a database
what database?
Rails doesn't "include" the Ruby language! And the web server is part of the Ruby library, not Rails!
The program generator accepts a description of database tables and generates generic Ruby code (web pages) to do CRUD (create, read, update, delete) maintenance of each table.
Man, you are really lost. ActiveRecord (a PART of Rails, you can use your own model classes) queries the DB to find methods *if you haven't defined them*. It also makes time-saving assumptions like, the name of the table is derived from the name of your class. Most people of course, use the defaults.
With very little initial effort one can create a (very) basic web application.
Delete "initial". Delete "(very) basic". Replace "create" with "create and maintain".
Same weaknesses as most one-way program generators:
Rails is not a code generator. Do you understand? No .rb files are created. It's all done dynamically, on the fly, with well-factored libraries. You can rewrite or replace any part of it.
Once a site is generated, modifying the generated code slows things to a near-halt since
Man, when you're in a hole, stop digging. All you have to do to "modify" the "generated code" is write a method that overrides the default. If you're an OO programmer you already understand the concept. (And no, it's not hard to do. If your table has a "first_name" column, and you want to override Rails' generated method, name your method "first_name". The original value is in a hash called "@attributes". It ain't rocket science).
There is no round-trip capability (i.e., if you hand-coded changes to a web app, regenerating the app in RoR will wipe out those changes.
You seriously need to take 10 minutes to look at Rails so you can realize how ridiculous this is.
Both RoR and AJAX are being pitched to communities not particularly skilled in development.
If this community doesn't include folks like you, count me in.
I've been coding since before the web, for nearly 20 years. I've done "real" MVC. Rails is a collection of all the good ideas people have been using for years, all in one pac
You don't understand one of the most important necessary preconditions for a larger web app in corporations - someone to approve it.
J2EE and ASP.NET have rich organizations that they can loan you to take key decision makers (CFOs) out to lunch to help approve expensive J2EE projects.
Compared to the Oracle sales guy flying my previous CFO out to some golf conference to pitch their J2EE-based framework, Rails has NOTHING..
I speak from experience - We had the case of One Oracle Salesguy against EVERY SINGLE internally developer telling this CFO that the Oracle framework sucked and that even Oracle was moving to Tomcat. Guess who won.
That feature - the lunch&conference&golf budget - and that feature alone is enough to make J2EE and ASP.NET win most corporate environments.
ActiveRecord is a *design pattern*. It dictates, to a certain extent, the shape of the database it supports. In reality, using it well is often a relatively good way to get a flexible/good schema from scratch with less db knowledge. It's not completely braindead, but a reasonably aware developer can do much better with the active record limitations than with a blank slate IMHO.
Rails itself could be put on top of any persistence layer. Instiki uses Madeliene instead of AR and it works fine. It just comes, out of box, with AR installed and that is the most natural. If you write your own ORM, it can work with rails. People have had success working with legacy schemas by frontending them with postgres views that behave more in the way that AR expects.
In any case, rails is more suited to new projects with new databases at this time. AR doesn't propose nonstandard database design in principle, it just dictates certain facts (mostly naming conventions for columns/tables) which can often be overridden. The most obvious one is that rails expects non-join tables to have an INT(11) PRIMARY KEY AUTO_INCREMENT field. Not being a DBA, I don't know what database design patterns are out there. Being a performance and efficiency conscious developer, I don't see how AR's patterns could get you into a performance or maintainability muddle by using them on a new project.
So much for the "tune for performance later" crap. When will programmers learn that doesn't actually work? You need a good design that includes tuning for performance early on.
Algorithmic and architectural optimization is best accomplished after you fully understand the problem domain, and low-level code optimization is best done only after you've optimized the big stuff. Most of the time, you don't go in knowing exactly what you're doing, so you can't make big gains without refactoring a ton. In fact, the more you design up front, the more work it is to go back and change things around. This is one reason why iterative development methodologies are gaining in popularity.
Our example, Ruby, is currently a 1.x release. A feature-complete 1.x release, as far as I'm concerned. Now, Ruby 2's VM is planned to be JIT and generally faster. But, I guess it won't because apparantly refactoring "doesn't actually work". Just the other day I was writing some new code that ran faster, but it actually didn't because, see, I had written slower code to begin with, which makes all succeeding versions work at exactly the same speed. Yeah.
-/ILP/-
So much for make it work, make it right, make it fast
No, the fundamental advantage of dynamic languages is programmer productivity. You can accomplish a goal in a dynamic language like Scheme, Smalltalk, Python, or Ruby in 100 lines that would require 500 or more lines of Java. That's also an advantage when you have to modify the code--there's less of it and it's faster and easier to read as a result. It's also much simpler and faster to create unit tests in dynamic languages, leading to more and faster testing of projects. These advantages grow with the size of the project.
The other advantage of dynamic languages is flexibility. While Java has limited support for features like reflection and generics, dynamic languages have offered much more powerful and easy to use versions of these features for years. Java is also missing other dynamic features like closures and metaprogramming. Groovy's feature list is an inverted list of many of the limitations in Java's dynamic capabilities.
Java's main contribution to programming languages isn't any new feature. It doesn't have any significant new features, and most of its main features like object orientation, byte-compilation/VM and primitive concurrency were in other languages like Simula and Pascal in the 1960s or 1970s. Java's primary contribution is that it was well marketed and that its limited dynamic features have inspired a large number of programmers to want more of the flexibility that languages like Scheme and Smalltalk offered decades ago.