A Tale of Two Rubies
I came across two postings by veteran programmers tonight. Both detailed their experiences using Ruby On Rails.
The first, a systems architect, described his successful efforts to replace a PHP application with a new one developed in Ruby On Rails.
The PHP application was exhibiting signs of code bloat and just did not have a good architecture. To bring this out, he mentions how the PHP version was 50,000 lines of code - and the Ruby ON Rails version, which does most of the same things, is only 5,000 lines of code.
All kinds of performance issues are examined. The author shows the multi-server architecture that has been used at a couple phases, using some beautifully-drawn diagrams he did in OmniGraffle (a well-known drawing application for the Mac).
The adventures of scaling, Stage 1:
The other article on Ruby On Rails was a rant by Joel - as in Joel On Software. Joel was not so happy a camper.
The main thing he complained about was the way the database development process works in Ruby On Rails, and how he managed to run afoul of what he wanted when he used the defaults.
For instance, he wanted smarter generated code to be created by looking at his foreign key declarations. He wanted validation code generated that would ensure invalid data would get caught by the application instead of the database.
He also complained that the official programming documentation that comes with Ruby and/or the official sites on the web is somewhat lacking.
I can vouch for that. Some things about the Ruby and Ruby On Rails documentation is very good. Yet there are huge holes in it too.
I think the good documentation is out there. It exists - and you can often find really good stuff like tutorials and examples out there somewhere.
The problem is, you have to hunt. That is kind of an issue, since you are generally in a hurry to learn how something works as quickly as possible. That is because learning time comes out of your coding time.
The so-called Pic-axe book on Ruby is excellent. It does a good nob of covering the language.
It touches upon the great classes in the library too. It falls short of providing examples that comprehensively show each major purpose of each class in use, however.
Doing that, would probably take a book set of several volumes, each one the size of this standard book about Ruby programming.
However, somebody should do it. Either writing the books, or else putting them online.
Ruby On Rails is kind of the same deal. You can read the documentation that comes with it. To really understand it though, one of the things you will probably have to do is buy the pragmatic programmer book on Ruby On Rails.
Plus, reading sample applications, watching screencast demos of it in use, and writing your own applications is pretty much mandatory for picking up Ruby On Rails, or Ruby for that matter.
I have to say that the Python standard library documentation - reference and tutorials - are far more mature and comprehensive than Ruby's documentation.
On the flip side, Python's standard library's growth spurt was in the 1990s. Ruby's took place after the 1990s. So, Python has had longer to document their modules than Ruby has. Ruby's standard library is way more up to date too.
Things that are relevant today - object-oriented XML processing, RSS feed generation/parsing, and tons of other recently important things you are more likely to find built-into Ruby than Python.
Similarly, Joel is in self-described rant was comparing Ruby On Rails to other tools. It failed in his expectation because it did not match what he learned when using those tools.
Probably a fair outcome, considering if it simply did what they did well, people would just use those existing tools and libraries! Ruby On Rails is trying to carve out its own niche.
Unlike a lot of languages/frameworks, it is very object-oriented. Also, it adheres to a set of design principles that other languages do not even have. So it is clear up front that it is not going to be similar to them.
Apparently, from looking over the first article, you can really wring some amazing performance out of Ruby On Rails. But to do that, you have got to pay your dues first and learn its ways and play but its rules. Even if that is a hard task, it is still an important task!
The first, a systems architect, described his successful efforts to replace a PHP application with a new one developed in Ruby On Rails.
The PHP application was exhibiting signs of code bloat and just did not have a good architecture. To bring this out, he mentions how the PHP version was 50,000 lines of code - and the Ruby ON Rails version, which does most of the same things, is only 5,000 lines of code.
All kinds of performance issues are examined. The author shows the multi-server architecture that has been used at a couple phases, using some beautifully-drawn diagrams he did in OmniGraffle (a well-known drawing application for the Mac).
The adventures of scaling, Stage 1:
While a couple of high-traffic sites are being powered by Rails and while the Rails book has a handful of instructions to scale your application, it was apparent for us that you%u2019re on your on at a certain point. This series of articles is meant to serve more as a case study as opposed to a generic %u201CHow To Scale Your Rails Application%u201D piece of writing, which may or may not be possible to write. I%u2019m outlining what we did to improve our applications%u2019 performance, your mileage may obviously vary.
The other article on Ruby On Rails was a rant by Joel - as in Joel On Software. Joel was not so happy a camper.
The main thing he complained about was the way the database development process works in Ruby On Rails, and how he managed to run afoul of what he wanted when he used the defaults.
For instance, he wanted smarter generated code to be created by looking at his foreign key declarations. He wanted validation code generated that would ensure invalid data would get caught by the application instead of the database.
He also complained that the official programming documentation that comes with Ruby and/or the official sites on the web is somewhat lacking.
I can vouch for that. Some things about the Ruby and Ruby On Rails documentation is very good. Yet there are huge holes in it too.
I think the good documentation is out there. It exists - and you can often find really good stuff like tutorials and examples out there somewhere.
The problem is, you have to hunt. That is kind of an issue, since you are generally in a hurry to learn how something works as quickly as possible. That is because learning time comes out of your coding time.
The so-called Pic-axe book on Ruby is excellent. It does a good nob of covering the language.
It touches upon the great classes in the library too. It falls short of providing examples that comprehensively show each major purpose of each class in use, however.
Doing that, would probably take a book set of several volumes, each one the size of this standard book about Ruby programming.
However, somebody should do it. Either writing the books, or else putting them online.
Ruby On Rails is kind of the same deal. You can read the documentation that comes with it. To really understand it though, one of the things you will probably have to do is buy the pragmatic programmer book on Ruby On Rails.
Plus, reading sample applications, watching screencast demos of it in use, and writing your own applications is pretty much mandatory for picking up Ruby On Rails, or Ruby for that matter.
I have to say that the Python standard library documentation - reference and tutorials - are far more mature and comprehensive than Ruby's documentation.
On the flip side, Python's standard library's growth spurt was in the 1990s. Ruby's took place after the 1990s. So, Python has had longer to document their modules than Ruby has. Ruby's standard library is way more up to date too.
Things that are relevant today - object-oriented XML processing, RSS feed generation/parsing, and tons of other recently important things you are more likely to find built-into Ruby than Python.
Similarly, Joel is in self-described rant was comparing Ruby On Rails to other tools. It failed in his expectation because it did not match what he learned when using those tools.
Probably a fair outcome, considering if it simply did what they did well, people would just use those existing tools and libraries! Ruby On Rails is trying to carve out its own niche.
Unlike a lot of languages/frameworks, it is very object-oriented. Also, it adheres to a set of design principles that other languages do not even have. So it is clear up front that it is not going to be similar to them.
Apparently, from looking over the first article, you can really wring some amazing performance out of Ruby On Rails. But to do that, you have got to pay your dues first and learn its ways and play but its rules. Even if that is a hard task, it is still an important task!
Technorati tags: rubyonrails, optimizing, performance, architecting, designing, programming, database, web
posted by John Collins | 6:16 PM
0 Comments:
Post a Comment
<< Home