Style, power and portability: HP dv5
- Related Stories
-
Ajax gives software a fresh look
October 4, 2005 -
From Web page to Web platform
August 16, 2005 -
Grassroots computing languages hit the big time
May 13, 2005
(continued from previous page)
called stored procedures, is very much an asset and an example of how contrarian thinking can be innovative.
"We took a pretty radical stand: Stored procedures and all things that make your database clever are evil," Hansson said. "If you tell a lot of IT shops that, they'll be majorly offended, because that's just the way they do things."
With future enhancements, he intends to take the idea of simplicity beyond writing code to different areas of the development lifecycle. One idea is to include tools to easily deploy Web applications onto clusters.
Hansson thinks that the current interest in Ruby on Rails is the "tip of the iceberg." And like others, analyst Monson-Haefel agrees that Ruby on Rails has a good future.
As an open-source project leader, Hansson has the right traits: He's willing to take contributions from others, he knows the product well, and he's constantly promoting it, Monson-Haefel said. "This is exactly how things like Linux got started," he added.
Despite the interest in Ruby on Rails, Hansson never had any intention of setting the Web development world on fire. The project grew out of practical necessity, a philosophy he intends to maintain in the Ruby on Rails open-source project.
In 2003, Hansson was working as a consultant for 37signals, a company that sells hosted project management and personal organizer applications.
During that development project, he discovered Ruby , a scripting language developed in Japan in the 1990s. To speed up his own work, he developed templates to complement that basic Ruby language.
About halfway through a project, he decided his templates could be packaged as a framework that could be used for all manner of Web development. In July 2004, he released Ruby on Rails and began actively promoting it.
Now a principal at 37signals, Hansson has no plans to commit his efforts full-time to Ruby on Rails. Remaining at 37signals as a programmer will ensure that the project continues to be practical, he said.
"If there is one thing that will kill Rails, it's to put people on it who are no longer in touch," said Hansson, adding that he has recruited like-minded, practical people to work on the open-source project.
The decision to start an open-source project was a business, rather than a personal, decision. By getting outside contributors, his employer can improve Ruby on Rails faster.
"Open source is a better business model for developing infrastructure code," Hansson said. "There are a handful of companies that have any business selling infrastructure software. It's really laughable for other entities to try."
See more CNET content tagged:
Ruby on Rails,
Web development,
BEA Systems Inc.,
programming model,
PHP
I have years of experience with Java/Struts/J2EE, PHP, and many other languages/frameworks, and have set up and benchmarked RoR applications recently. I used to be more enthusiastic about RoR, but when I tested it in August (I realize it was/is still beta) it had *major* performance problems. I understand both the tarpit of J2EE development and the amateur-hour nature of most PHP projects. Ruby is a beautiful, vastly more appealing language than either Java or PHP.
I greatly admire the goals of RoR and congratulate DHH both on his marketing skills and on pointing out that the J2EE emperor, particularly Struts, wears no clothes! But before we get too caught up in the hype, let's be real.
RoR *IS NOT* "five to 10 times faster than comparable Java frameworks". Not even close if you are talking performance. In fact, it is more like 30-40 times *SLOWER* than raw JSP with pooled JDBC connections, even after the virtually mandatory optimization of a persistent FastCGI interpreter.
Where RoR shines is on *productivity*. And I agree that a 5-10 fold increase in productivity is profoundly more important than a 5-10 fold increase in application speed. Usually the bottleneck in web apps is either the network or the database anyway, so maximizing execution speed is largely a waste of time beyond a certain level.
There are alternatives to RoR while it matures; Catalyst is a similar framework for Perl with much better performance and pluggable MVC components. ColdFusion is an ugly language and framework compared to RoR, but it has a lot of built-in functionality and very good performance since it is compiled into Java bytecode. Finally, there is ASP or ASP.NET with embedded Perl.
One of the key productivity benefits of Ruby over Java is the fact that it is a dynamic language, like Perl, Python, and even PHP. I am a Sun Certified Java 2 programmer, yet I feel Java and Microsoft's Java clone (C#), have virtually no place in web app development. Dynamic languages are the key! They are not necessarily "easier" than Java, but they let you get more done with less code. RoR is a nice, coherent framework with a beautiful dynamic language (Ruby), but until its performance issues are resolved I will be using Perl-based frameworks or ColdFusion.
That said, on data entry areas, I need faster response, as in faster then the data entry people can type, and I have achieved instant response using AJAX.
My hope is that RoR will eventually include the following as it matures:
1. The ability to compile generated scripts into actual computer code to make them run faster.
2. The ability to use other scripting languages
3. A huge library of buttons, code, components and grids that a developer can use in web applications
Yes, I know what I have typed sounds like the features present in Microsoft.Net, that is exactly the point: A highly productive and easy to install/configure/generate framework with rapid execution, multiple supported programming languages and a huge library of web-based classes and gui objects would be a great godsend to programmers.
You don't need RoR for AJAX, and I have found it easy to do AJAX-type development with Zope, but you could also do it easily with PHP/ASP or others. You just need Dojo or Prototype/Scriptaculous for a common library. (in fact you dont even need those, they just make things easier)
I guess the thing I don't like about RoR, is that it's too simple. What if I *want* to build something out of a stored procedure? I also, don't want to be forced to name my columns the way RoR wants them. I know RoR can be extended to include other, more complex operations, so it will be a good fit for some, no doubt.
Completely my preference, but I like Zope, which is why I do Zajax, now. :)
I've found that a Content Management System can be an incredible productivity booster for the web based application development cycle. A CMS allows for non-technical individuals to update and maintain general site content, freeing up developers and designers to focus on new features and functionality. Plone offers an out of the box CMS system complete with Acceess Control Layer, workflow, presentation logic and a ton of other nifty features (even *gasp* "AJAX" support).
I think PHP has their equivalent with Joomla, but I don't see a similar framework in the RoR stack as of yet.
I have heard filemaker make promises for quite some time.. oh, well.. I will go study for my MCSA exams... let the gods drink their wine... lol
Edition software is a "complex monstrosity" that's hard to learn,
he said."
While I agree with the statement about Java, (speaking as a
former Java Programmer), I think it is a bit incorrect to say that
all PHP applications are difficult to maintain.
You could say that Ruby applications are hard to maintain, but
Ruby on Rails applications are better. In much the same way you
could say PHP applications are hard to maintain, but PHP
applications written in WASP, for example, ( http://
wasp.sourceforge.net ) are better.
"The trick", said Hansson, is to "slaughter the holy cows"
Well, dont kill all the holy cows. I understand in what context he is using holy cows, but i thought it was funny since I run http://www.holycow.org
databases. Any busy application that depends on a database will
live or die based on how it uses the database. Perhaps RoR is
targeting smaller applications, but in my experience, people want
to be productive AND they want the power to scale. Does RoR seek
to become the Microsoft Access of web frameworks? If so, great,
but I haven't seen too many developers getting six-figure salaries
making Access databases.