顯示包含「comparison」標籤的文章。顯示所有文章
顯示包含「comparison」標籤的文章。顯示所有文章

星期四, 6月 07, 2007

I'm Ruby on Rails, I'm Java

I really love this video from railsenvy.com. The idea is come from Get a Mac TV Ads by Apple.com

Some interesting comparison between PHP, Rails and Java

During the International PHP Conference 2006, Tim Bray, who - among many other things - co-edited the XML 1.0 and XML namespace definitions, gave a keynote about "How to combine PHP technology with Java based on Enterprise Systems". During his keynote, he presented some very interesting comparison between the popular development "frameworks" PHP, Ruby on Rails (RoR, Rails) and Java


  • Scaling : Load balancing, Shared-nothing, CPU , DBMS, File I/O, Observability
  • Development Speed : Compilation step, Deployment step, Code Size, Configuration process
  • Development Tools : IDE, Templating, How many tools, O/R Mapping, Performance, Documentation
  • Maintainability : MVC, OO, Readability, Language count, Code size
It seems Java can't get a upper hand from the eyes of Sun people.

Download the presentation file

Why I love RoR?

I agree most of those from analysis and comparison. In fact, I just want to point out that there are several good IDE are coming out e.g. Aptana IDE (RadRails has integrated into Aptana)

Pros

  • An MVC framework for Ruby helps separate presentation from business logic
  • Unit tests are built right in.
  • Don’t repeat yourself (DRY) principle makes for less painful development
  • Agile no compile development
  • Convention over configuration and meta-programming does away with all the configuration you have in a Java framework like Struts.
  • Active Record Object Relational Mapper needs very little mapping configuration.
  • Heavy Ajax Support, Prototype and Scriptaculous helpers are in Rails
  • Built in XML Web Services
  • The Ruby language is pretty easy to learn. Everything is an object. Its clean and easy to read.
  • Easy model validations
  • Very quick to develop applications from the ground up when you have control over the database schema
  • Share nothing architecture. Session data is stored on disk or in the database so it could be shared amongst many nodes
  • Ruby is dynamically typed, which allows for easier development in my opinion since one can just check to see if an object has a method instead of worrying about what kind of type it actually is.
  • Classes are never closed so you can easily add methods to any class, even other apis. This allows active record to dynamically create method names for each database columns at run time. There is no need to update a mapping schema when you add a column to the database, the method is “magically” there.
  • Closures allow for dynamic behavior that would take much more code in Java.
  • It protects developers from common mistakes. It follows best practices which should be adhered too in new development. Also, since it scales by process you don’t have to worry about developers trying to create threads in the application container which could bring down the container.
  • Mongrel Server gives a Rails application its own container and speeds production requests greatly.
  • Ruby has been around for some time, first developed in 1993. Ruby is a language in itself was was not created to be web specific.
Cons
  • Limited legacy schema support. You pay in added code for someone else using composite primary keys in the database schema. Not a show stopper, but you lose the quick development features of the ActiveRecord database model each time you have to account for this.
  • Freely available api documentation is seriously lacking. Books are fairly decent but they are having a hard time keeping up with the rapidly evolving framework. It makes it hard to know about deprecated practices.
  • If you cannot follow the best practices for some reason you are forced to solve the issues by hand.
  • Generated Scaffold code is pretty useless when working with a database that doesn’t follow the rails specs. You have to customize a great deal, then again the word is that we are not supposed to be using scaffolds for real development, which was one of the main selling points of rails.
  • Scaling by process can eat a lot of memory on the server. Memory is cheap though.
  • No built in internationalization support.
  • No plan to include better legacy database support.
  • SQL Server(all versions) support is very lacking and has the same problems just as PHP. I would not use it for production against SQL Server.
  • Rails is a fairly new framework compared to PHP and Java, so there are not as many developers, but many are eager to learn.
  • Limited IDE environments. Textmate is the best but it only runs on a Mac.

星期一, 4月 23, 2007

Ruby vs. Java