Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Programming IT Technology

Part 2 of Ruby on Rails Tutorial Online 187

An anonymous reader writes "Curt Hibbs has released Part 2 of his tutorial Rolling with Ruby on Rails to the O'Reilly ONLamp site. The first part was published in January. Topics covered are database transactions, callbacks, unit testing and caching." From the article: "In Rolling with Ruby on Rails, I barely scratched the surface of what you can do with Ruby on Rails. I didn't talk about data validation or database transactions, and I did not mention callbacks, unit testing, or caching. There was hardly a mention of the many helpers that Rails includes to make your life easier. I can't really do justice to all of these topics in the space of this article, but I will go into details on some of them and present a brief overview of the rest, with links to more detailed information."
This discussion has been archived. No new comments can be posted.

Part 2 of Ruby on Rails Tutorial Online

Comments Filter:
  • by grayrest ( 468197 ) on Friday March 04, 2005 @09:36AM (#11843850) Homepage

    It's rough, but it's coming along.
    • by jellomizer ( 103300 ) * on Friday March 04, 2005 @09:41AM (#11843892)
      It is always good to have two closly competing languages. Ruby and Python are so close in design it helps keep both on their toes. Some people consider Python and Perl to be competive but the language syntax is much more different, and often lead to more of a holy war debate on what is better. While I don't find this type of argument for Python vs. Ruby But I could just be looking in the wrong spots.
      • Python and Perl not only differ in syntax, but also aim at completely different niches.
        You're not really supposed to write big programs in Perl -- Perl is better suited for short tasks, anything that includes heavy string parsing and/or sysadmin chores.

        [evil Perl zealot hat on] Python, on the other hand, serves as a poor excuse for a "real" language aimed for apps longer than several screenfuls of code -- but, it loses because of [XXXXX]. It's also likely to give you Cobol fingers.

        In the above, [XXXXX] s
        • Cobol fingers? If you've ever coded in a team you will be indenting anyway, python just means you can type most of the language using the normal keys, rather than twisting your fingers round to reach the edge of the keyboard at every turn. (Seriously, how do you type all that punctuation? I suppose the extreme conciseness of perl means there's less typing overall which maybe makes up for it, but still....)
    • by Colonel Panic ( 15235 ) on Friday March 04, 2005 @10:25AM (#11844239)
      Wouldn't that be PoR?

      Seriously, though, I really think that Ruby the language is part of what makes RoR so great. I'm not sure you can do a lot of the same stuff in Python as you can with Ruby. Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python. But as they say, imiation is the sincerest form of flattery...
      • by Colonel Panic ( 15235 ) on Friday March 04, 2005 @10:30AM (#11844291)
        That should be 'immolation is the sincerest form of flattery'.
      • by Simon ( 815 ) <{simon} {at} {}> on Friday March 04, 2005 @11:05AM (#11844603) Homepage
        Being able to define natural looking domain-specific languages using Ruby's code blocks seems like something that would be very difficult in Python.

        Do you any examples of this in action? I mean a non-trivial example showing a Ruby block based solution for a problem that is clearly better than the more tradional (messy?) solution.

        Impress me. :-)


        • Haven't done any ruby in a while, so I don't have any code handy, but blocks are great for things like GUI callbacks. You can put the code right where it would logically fit, and you don't end up with a 1001 quitButtonOnClick() type functions cluttering your namespace.
        • by Paradox ( 13555 ) on Friday March 04, 2005 @01:34PM (#11846082) Homepage Journal
          I can't impress you, sorry. But I can say that Ruby blocks are a powerful tool that are very flexible and useful. Ruby iterators are the showcase of this tool, and they're something you use every day in ruby. For example:
          ary = [1,2,3,4,5] # Example Array
          ary.each do |val| # Begin a block
          puts val.to_s + " was here!"
          Blocks can be used inline as above, or turned into true closure-bearing functors like so:
          my_block = lambda { |x| puts x.to_s was here }
          ary = [1,2,3,4,5]
          ary.each &my_block
          You can write higher order functions that accept lexical blocks trivially. For example:
          def my_hof( &block )
          yield # Calls the associated block within scope
 #Calls the associated block as a function
          Also, ruby's blocks are used to do neat things like ensure things happen at the end of an operation. File I/O is the classic example. Check out how Ruby's library ensures your file closes:
 "somefile.txt", "w" ) do |handle|
          handle.puts "This is text in the file."
          end # File is ensured to be closed now
          This is just a small sample of what Ruby's standard lib does with blocks. They're really quite useful. They're like Lisp's lambdas but with a cleaner syntax when used inline.
      • It isn't just Ruby's blocks that make Rails so great. It's the fact that it's possible for Ruby Classes to reopen themselves and dynamically define, alias, and remove methods from themselves.

        When you see a block of code like this in Rails:

        class Person < ActiveRecord::Base
        has_many :addresses
        has_and_belongs_to_many :friends, :class_name => "Person"

        What it does is take the schema for the People table, parse it, and actually re-open the Person class at runtime and adds the methods to support th

    • There is Catalyst []
    • Similar ideas worth taking a look at for python: []

      BSD Licence, also based on MVC style design.
  • What is this? (Score:3, Insightful)

    by Lovesquid ( 840251 ) on Friday March 04, 2005 @09:42AM (#11843903)
    Hmmm... nowhere in the summary does it tell what "Ruby on Rails" is, or why I should care about it, and with the server getting hammered, I can't RTFA to find out. How about including a 1-sentence summary of what the topic of any story IS before posting it, for those of us who don't already know everything there is to know about everything.
    • I must have gotten in just ahead of the quote from Part I:

      Ruby on Rails, the super productive new way to develop web applications

      OK, that's helpful. Continuing...

      Ruby is a pure object-oriented programming language with a super clean syntax that makes programming elegant and fun...

      Rails is a open source Ruby framework for developing database-backed web applications. What's special about that? There are dozens of frameworks out there and most of them have been around much longer than Rails. Why sh

      • I've never used Ruby myself, but judging from the text you quoted, RoR people seem to have a weak spot for superlatives and exclamation marks... Let's just hope their coding is more "super" than their writing.
    • You can always use Google. Ever heard of that tool? If not, check out Ruby on Rails Site [].
    • It's a collection of Java Best Practices rewritten in a 'cool' geeky language. Nothing new....
      • Re:What is this? (Score:5, Insightful)

        by JamesOfTheDesert ( 188356 ) on Friday March 04, 2005 @10:46AM (#11844435) Journal
        It's a collection of Java Best Practices rewritten in a 'cool' geeky language. Nothing new....

        Quite true. For example, Java Best Practice #1 is to avoid using long, detailed XML files for configuration, and instead use the programming languge itself, which is dynamically loaded and interpreted when needed.

        Another Java Best Practice is to let the framework write the tedious boilerplate code for you. For example, in Struts, you just run

        % struts myAppName
        and you're halfway done writing your Web application.

        Here's one more Java Best Practice: Avoid expensive , complex application server software, and do rapid development using the Web server that is built into the standard library. Then deploy to the Web server of choice with no code changes or quirky vendor-specific API hacks.

        • Re:What is this? (Score:4, Insightful)

          by coldtone ( 98189 ) on Friday March 04, 2005 @12:07PM (#11845226)
          Halfway done?! You must be kidding!

          Being a java web developer, and using struts to build 3 different applications I have to say that enough is enough.

          Struts is a very simple web framework, which will do several things for you.
          Dramatically increase the size of your app.
          Limit the functionality of your app.
          Makes the code hard to read and follow. Just about everything runs though the struts config file.

          The only benefit I see with struts is that is provides some clean definitions for code. (A place for display, a place for validation, a place for the work to be done) And gives you some tags to help with internationalization. (Just help mind you, if you need to have a totally different layout for a different language then, well you're screwed.)

          I would only use struts again if I was writing an application that was to be localized and translated, and was working on a large team. Otherwise a well written set of JSP's will get the job done faster and will be easier to read.
    • Well, don't feel too bad. Even if you'd already read the previous article, you still wouldn't have a clue what this is:

      "In Rolling with Ruby on Rails, I barely scratched the surface of what you can do with Ruby on Rails"

    • Normally, "editors" would do something like this. Does Slashdot have "editors"?
    • Wow! You don't have time to read the article, but you have time to post a bitchy whiny comment.

  • Ruby is great (Score:1, Informative)

    too bad there isn't the big fellowship right now (besides japan, where it is bigger than python, whatever that means ;) i think its the most clean and powerful oo-scriptings language available.
  • by elh_inny ( 557966 ) on Friday March 04, 2005 @09:44AM (#11843916) Homepage Journal
    Has anyone actually done some interesting stuff that now works in a productive environment?
    • Last time when Pt1 of the the article came out, in the discussions on /. some sites were pointed out (seemed like decent sites too).

      I've been meaning to get around to add RoR to my apache (XAMPP) setup to try it out. Most of what I do at work is ASP/ASP.Net and I've been looking for something else (not to fully replace them, but perhaps as a complement). I'm not big on php, but it has it's uses and followers (I use it on some small websities with cheap hosting). J2EE isn't my definition of fun (although it
      • From what I had seen, RoR seemed pretty promising (and it keeps getting better they say), but I'll have to dig deeper to see it's full power. The only problem I can see now is finding some decent hosting for that, preferably cheap (RoR *with postgresql* to make things worse).

        Check out
    • by elmartinos ( 228710 ) on Friday March 04, 2005 @09:56AM (#11844026) Homepage
      Shure! Even though Ruby on Rails is really very young, there are a few commercial sites that use it already. Here are a few links: Although, the first 3 links are somewhat related.
    • Basecamp( tens of thousands of users, designed by the creator of RoR 43Things( thousands of users, now working with TadaList( an online todo list app with thousands of users Snowdevil( an online store that is powered by rails. It was deployed very rapidly using rails. If you can get through to the onlamp article there is a more complete listing of real world RoR applications at the end.
  • Sounds exciting... (Score:4, Interesting)

    by szlevente ( 705483 ) on Friday March 04, 2005 @09:45AM (#11843926)
    "A Rails web application can run under virtually any web server"
    Now that really made me curious. Is that really true, tried, and tested? If so, we need another bunch of tutorials about how to use Rails under Tomcat, Apache, etc. There is no way this framework will replace existing Java frameworks, but using it for prototyping is promising.
    • by zimba-tm ( 598761 )
      Some answers for those who are lazy

      == ROR runs and was tested under :
      Apache + CGI
      Apache + FCGI
      Apache + mod_ruby
      Lighttpd + FCGI
      WebRick (ruby server)

      OS : Linux / Window / OSX / *BSD

      == Real-life examples :
    • In this case, I guess "virtually any webserver" means either apache, lighttpd or WebRick. I couldn't find anything IIS related (not that I spent hours looking either).

      DB wise, it supports MySQL, PostgreSQL, SQLite, MS SQL Server, IBM DB2 and Oracle.
    • by rubycodez ( 864176 ) on Friday March 04, 2005 @10:24AM (#11844237)
      No way this framework will replace existing java frameworks

      There is actually a chance it may become a mainstream way of building an enterprise framework. There is a very cool new bytecode Ruby virtual machine and just-in-time compiler (YARV), and the next generation of Ruby, Ruby 2, will support native OS threading. Unlike Java, the source for Ruby is and will be completely open & transparent. Ruby can run on platforms where java can't, like BeOS and MS-DOS.
    • Yeah, it does run under most basic webservers. Not too long ago, Rails needed apache's mod_rewrite to get the pretty URLs. But the addition of Rails Routes fixed that mostly.

      Your web server can run Rails if it does the following:

      1. Can invoke CGI somehow (duh)
      2. Can forward URLs like http://somesite/somename/blah/blah/blah to http://somesite/somename/dispatch.cgi?/blah/blah/b lah

      This is an awful lot of them, and Ruby runs on just about every platform used for web serving, so yeah. Rails could work most a

  • by teidou ( 651247 ) <tait@fit[ ]com ['is.' in gap]> on Friday March 04, 2005 @09:48AM (#11843956) Homepage
    To explain Ruby on Rails, I could say it is a highly integrated model-view-controller type web application framework. That would be like saying a Ferrari is a 4 wheeled internal combustion vehicle: true, but misses the point.

    For more info, see An good alternative tutorial is at [].

    There are even better introductory materials coming. Dave Thomas (of Pragmatic Programmers) is working on a Rails book, chapters are being reviewed presently.

    Rails is powerful an flexible. More importnatly, it's a lot of fun. If you are a programmer who want to enjoy web-based application development, please do take a look at Rails.
    • by pamri ( 251945 ) on Friday March 04, 2005 @10:27AM (#11844259) Homepage
      Another great resource is the Ruby on rails weblog [] which has links to more tutorials, job postings about rails, updates, etc., There's also an updated video [] tutorial on building a weblog.
    • > To explain Ruby on Rails, I could say it is a highly integrated model-view-controller type web application framework.

      Rails is not really MVC -- The Controller part at any rate, the bane of every struts programmer, is entirely invisible in Rails. I suppose not having to deal with it yourself doesn't make it go away ... but really, nearly ANY application can be broken down into MVC parts or otherwise viewed through some MVC lens. The term was never all that meaningful (it only made sense when the cont
      • At any rate, you tend to define look and behavior in the same file in Rails,

        Excuse me? Uhh, the look is defined by the templates, and the controllers just do the setup and actions. Rails has a very clear separation of view and controller.

        You define look in the templates and behavior in the controller. Sometimes, the behavior is just loading a group of database items into a class variable for display. Sometimes, it's more complex, involving things like redirection and database manipulation.

        But you'd

    • ... is a version of the tutorial that's not on PDF. Since the tutorial was authored on OpenOffice, it would have been just as easy to provide a web version.

      And how about a good tutorial on Ruby itself? Most of us have no idea what this language is about.

  • by WWWWolf ( 2428 ) <> on Friday March 04, 2005 @09:49AM (#11843968) Homepage

    When the part one was published, I had severe problems getting Rails to work in Debian. There was a lot of really odd tools that needed to be installed and all that. Rails web page had tons of Ruby packages that I was pretty sure I didn't need...

    But one thing has changed since then: Rails is now in Debian unstable []!

    • Actually, rails/any ruby library/app/whatever is quite easy to install if it is available on ruby gems and you have installed ruby gems. ruby gems [] is sort of like apt for ruby. Once you install gems, to install rails, all you have to do is, gem install rails and gem uninstall rails to uninstall rails. Although you are unlikely to need it. :-D
    • by Tobias Luetke ( 707936 ) on Friday March 04, 2005 @10:52AM (#11844477)

      Please don't make this sound like an rails or ruby issue. Debian really blew it on packaging ruby. Most of the system related problems which come up in #rubyonrails are related to debian linux installations.

      How did they come up with the brilliant idea to split the standard library into 34 different packages? I just can't see how something moronic like this can even get started considering that a standard library is all about raising the status quo of the language by providing some shoulders to stand on so people can reach for higher goals.

      Keep in mind that ruby has no dependencies at all. All dependencies are optional and the libraries using them (tk,x11, readline) fail gracefully with exceptions when the parts are not installed. Not so if the entire library is missing, this will cause a runtime exception with cryptic error message which rails will never be able to handle. Also ruby is tiny the entire package is 3mb!

      I heard they are talking about improving the situation by adding a "virtual package" for ruby which contains all 34 seperate packages

      Future in Debian terminology is traditionally not soon and thats a fix feeble fix considering all they need to do is to put all 3mb of ruby in one package

      Anyways the point is fairly moot now since debian doesn't have ruby 1.8.2 anyways which is required for the latest rails

      Luckily its easy to install ruby by hand. And I heard gentoo and freebsd install pretty easily too...

      • Debian does the same thing to Perl, except there are substantially more than 34 packages. I'm not sure what the point is, as Perl has its own package management via the CPAN module. I wish Debian would let Perl do its own package management, like Gentoo does.

        The entire Ruby system isn't 3MB, either, if you're calling those 34 packages the system. The log4r package alone is 1.1MB, libqt-ruby is another 1.3MB, and libxmlparser-ruby is 0.8MB.

        And Debian does have Ruby 1.8.2, I run Debian unstable and I've bee

        • And Debian does have Ruby 1.8.2, I run Debian unstable and I've been using 1.8.2 for a while now.

          Try telling that to my web host. They (sanely) use Debian Stable on their servers. Debian Stable only includes Ruby 1.6.7. Why should they use Debian Unstable on production servers?
          • So that they can offer a more competitive selection of web applications, and attract more customers. Duh.

            Of course, they may not realize that. Similarly, it seems to be tough to find a web host that offers ordinary people J2EE...
        • With Perl, at least, there's a good reason: Perl is required by the base system, and it is important to keep the base small. IIRC, the way they do it with Perl now is the way the parent was saying would happen soon (erm, eventually :-p) with Ruby: there is a minimal package for the base system, but if you install the package called "perl", it will install much more.
    • $ cat /var/lib/apt/lists/ _ sarge_main_binary-i386_Packages | grep-dctrl -n --field=Package ruby --show=Size

      Summing the output, yeilds 31806976 bytes or 30 MB.

      $ aptitude show rails
      Package: rails ...
      Depends: ruby (> 1.8), ruby ( 0.10.7),
      libyaml-ruby (> 1.8.2), rdoc (> 1.8.2), libtest-unit-ruby (> 1.8.2),
      libdrb-ruby1.8, libsoap-ruby1.8, libxmlrpc-ruby (> 1.8)
      Recommends: libwebrick-ruby1.8, irb (> 1.8)
      Suggests: libapache-mod-ruby
      • on-rails-on-debian.php has a good tutorial which shows an alternate server for a acouple debs and from which you can just copy and paste the horrensously long atp-get command. Sadly, I get a 'permission denied' error chenever I try to run 'rails foo'. So maybe the tutorial wasn't that great after all.
  • ROR rocks! (Score:5, Interesting)

    by Pfhreakaz0id ( 82141 ) on Friday March 04, 2005 @10:12AM (#11844132)
    As a guy who has written db-driven web apps in ASP, ( alittle), perl CGI, plain JSP/Servlet and j2ee app server with EJB's (both with and without a persistence framerwork/Object-relational bridge), I can tell you ROR is my favorite. I've only been using it for two weeks on a part-time project. It's ... beautiful. I can't think of any way to describe it. It. Just. Works.

    And ruby is a really nice scripting language. You should check it out.
    • Re:ROR rocks! (Score:3, Interesting)

      by pepicek ( 710120 )
      The best way to describe ruby and rails for me it's that you are writting programs for you to understand them, not for computer. It's really changing the way you think when you are programing. You have time to focus on bussiness problem rather than computer's. Even if you have Mac OSX and really love it :-).
    • Re:ROR rocks! (Score:1, Interesting)

      by Anonymous Coward
      Hi, I'd like to learn some new stuff. I've decided that Ruby is my new project. I'm coming from the point-of-view that I haven't really programmed at all in a long time (not since I took some classes in school, other than programming some excel macros in vba). Any suggestions where I should start with Ruby. Initially I've been taking the random approach; I've got Ruby (and Tcl) installed, and I'm just looking at tutorials and adding text boxes, and stuff like that. Any suggested easy first projects that re
      • Dan: hmmm, I'd find an itch to scratch. You can start by install rails and go thru the "todo list" tutorial web site. That's what I did. Maybe that will fire some ideas. Want to write a blog? write your own little blog site. It would be pretty trivial to do in rails.... I dunno.
  • by Ridgelift ( 228977 ) on Friday March 04, 2005 @10:47AM (#11844451)
    Dave Thomas' new book "Agile Web Development With Rails" [] is due out in July. It's really, really good so far (I'm one of the lucky ones who is helping review it). My perspective is a person who knows very little about databases, web application development and no previous knowledge of Ruby, the language that Rails is built on.

    One of the big problems with Ruby on Rails [] is that it [] is [] well [] documented [], but a lot of it is API's and reference documentation. Dave's new book has an excellent tutorial which is the best thing I've seen written so far about RoR for newbies, and promises to go into the depth and detail similar to his Pickaxe [] book.

    If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released. I'm finally getting over the hump with RoR and I now see what all the fervour is about.

    (Oh, don't ask me to post or send copies of his drafts, 'cause I ain't gonna!)
    • One concern that I have about this is: How long has this book been in the works? Rails has gone through leaps and bounds and fairly huge changes( sometimes on a week-to-week basis) even in the few months I've been working with it. Will the book be up-to-date when it comes out?
      • One concern that I have about this is: How long has this book been in the works? Rails has gone through leaps and bounds and fairly huge changes( sometimes on a week-to-week basis) even in the few months I've been working with it. Will the book be up-to-date when it comes out?

        It's current up to 0.10, the latest version. David Heinemeier Hansson, the author of Rails, is also on the review team and seems to be good friends with Dave Thomas. So I think it's fair to say the book will be faily up to date, bu
    • If you've previously looked at RoR and were disillusioned because you just weren't "getting it " or didn't want to slug through the technical documentation, I encourage you to keep an open mind and wait until Dave's book is released.

      Ah; sounds like this is getting closer to Struts land: Great tool, but to really understand it you need to buy a book.

      Or no?

  • by MarkWatson ( 189759 ) on Friday March 04, 2005 @10:51AM (#11844470) Homepage
    I have worked through the RoR tutorial and re-implemented a simple admin web app that I originally wrote for a customer using JSPs and Tomcat. I must say that what took me 4 hours to write using JSPs and JDBC took about 30 minutes using RoR.

    A big advantage that Ruby and Python have over Java is that they are dynamic languages that makes it not too difficult to write a database wrapper class that dynamically looks at database/tables meta data and generates access methods on the fly. Java Tails (using XDoclet market tags) can't really compete.

    I really love the full J2EE stack for developing large scalable web applications but I am now looking at alternatives for creating smaller systems much more quickly.

    BTW, I really like RoR's templating scheme: much like JSPs in syntax (JSP non-XML syntax, that is) but do to Ruby's much terser notation for enumerating collections, the the templates tend to look a little cleaner.

    For Python, I really like the light weight CherryPy web application framework. I plan on checking out Python Subway also when I have some time.

  • by MSBob ( 307239 ) on Friday March 04, 2005 @11:20AM (#11844738)
    The Rails is such a great showcase of Ruby it really got me interested in the langauge itself. In particular looking at their Object Relational mapping tool it's very impressive how easy it is express your mappings with very little effort. Have a look at this example [] and compare it to a typical set of java classes with Hibernate tags. Then in case of Hibernate you have the extra build steps with Ant to generate the hbm files and so on. Don't get me wrong I like Hibernate and use it every day but Hibernate must operate within Java's syntactic limitations. With Ruby there is so much more flexibility that helps Rails achieve much more simplicity and expresiveness.
  • A few years back I created a dynamic MySQL backed website in PHP. When I first started learning Ruby, I converted this site to Ruby (ala eRuby and mod_ruby). I easily cut my code in half, *plus* it became a whole lot easier to read (and I was a ruby-newbie!). I am now migrating the site to use Rails, which, from what I can tell so far, is cutting that code down in half *again*.

    If Rails had been around when I first started the site, I would have saved hours upon hours of development time. Rails is an am
  • by badboy_tw2002 ( 524611 ) on Friday March 04, 2005 @12:50PM (#11845645)
    I don't normally write cheerleading testimonials, but its also rare I find something this cool that I want to gush about it.

    The first tutorial (I saw it right here on Slashdot!) got me curious about RoR. I went home and installed it that night. A couple weeks later (total of maybe 10 hours invested) I had completely converted my community website over to rails (from a servlets site), and am launching it fairly soon. The funny thing is, the actual code to drive this thing is really small. No boring, repetative database code, automatic validation, lots of helpful classes (authentication is downloading a new package and running a make script). Things in the tutorial make it look like you're limited to standard naming conventions, but I assure you that you can override everything if you've got an existing database that doesn't match the RoR naming scheme.

    I've found the community very helpful. Hosting is a bit limited now, but I'm getting a account soon to get my new site up and running.

    This is definately worth an install and the 20 minutes it takes to do the tutorial, check it out!
  • by sean23007 ( 143364 ) on Friday March 04, 2005 @01:56PM (#11846306) Homepage Journal
    I considered using Ruby on Rails for a large project I was doing, and found that though it was extremely easy to get started and do simple applications, it fails on more complicated databases. It does everything for you automatically, and you can easily write functions in Ruby that do the work of the database, but this is best only when the database isn't doing a whole lot itself except for holding data.

    My database is in PostgreSQL, and uses a lot of dynamically named tables and schemas, as well as many trigger functions written in pl/pgsql. In order to get RoR to work, I found that I was going to have to edit the framework itself extensively, and would still be hampered by the slowness of Rails, which I found to be unforgivable.

    I ended up having to design my own framework in Python, which can handle the most complicated databases without any more trouble than the simplest. The construction of the pages now takes a little more time than it did in Rails, but pages that used to take over a second to load are now instantaneous.

    That said, I translated a small web app from Rails to my own framework, and the translation took less time than it did to write it in Rails in the first place and ran a lot faster, but that's because the design was done in Rails. I'd say that Rails is really good for prototyping small applications and getting them working really quickly, and then translating them to another framework for production becomes quite simple.

    For non-trivial web applications, Rails has the problem of being optimized for ease of use, not for complete control. Note that I'm not trolling, or saying Rails has no use. Just that I found that it wasn't sufficiently capable for what I was trying to do with it.
    • The part of Rails that deals with the database and does the ORM is called ActiveRecord. You don't have to use AR with the other components of Rails.

      Also, AR has gone through some extensive changes in the last release, it may better suit your purposes now.

      Keep in mind that it's still a fairly new framework. It will only get better!
      • I don't mean to say that Rails has no uses. It definitely seemed to be wonderful for a certain subset of applications. However, the amount of work it would have taken to rewrite ActiveRecord such that it would be compatible with my database was roughly equivalent to the amount of work it would take to completely implement my own solution. I simply decided to do the latter. Perhaps I should have written an AR replacement that would have been enough for my database, because that certainly would have advanced

The Shuttle is now going five times the sound of speed. -- Dan Rather, first landing of Columbia