Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

Ruby For Rails 173

Posted by samzenpus from the get-on-the-train dept.
Simon P. Chappell writes "This may not be the book that you think it is, if you don't read the title carefully, but it is the book you need, if you are developing applications for Ruby On Rails (often known as just Rails, or RoR, to its friends). When learning any new development platform, there are many idioms and approaches, best practices if you will, that can benefit your development efforts. This book sets out to bring you that understanding of the best way to write the Ruby side of your Rails application." Read the rest of Simon's review.
Ruby For Rails
author David A. Black
pages 493 (17 page index)
publisher Manning
rating 10/10
reviewer Simon P. Chappell
ISBN 1932394699
summary A stunningly well written explanation of real-world Ruby skills for Rails development.


I see two main audiences for this book. The first group would be those who are learning to develop Rails applications and need some help with their Ruby skills. The second group would be those who already have good Ruby chops, but who want to learn the primary Rails idioms and techniques. Naturally, there is always the curious geek crowd who might find the twofer of an introduction to writing real-world Ruby and a hype-free description of what Rails actually brings to web development, to be quite attractive. I place myself firmly in the third group, but after reading this book, I'm ready to move to the first group.

To quote it's own website, "Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern." The first thing this tells us is that like any framework worth it's salt, it is fully buzzword compliant. The second thing it tells us is that it really does try to help with every layer of your application, from providing a full controller to automatically mapping your data objects to their respective backend database tables. Oh, and with the bare minimum of configuration files to boot! For those of us who have developed web applications with Java, this is a welcome break.

The first part describes "The Ruby/Rails Landscape" and has three chapters that describe how Ruby works, how Rails works and then shows a very simple example of Ruby-enhanced Rails development.

The second part describes "Ruby Building Blocks" spanning five chapters, four through eight. This part is a very good tutorial style introduction to Ruby. Chapter four introduces objects and variables with chapter five showing how to organize those objects with the concept of classes. Chapter six introduces us to modules and program organization in general. Chapter seven talks about the default object, self, and scope. Chapter eight covers control flow techniques. This is more than just a fancy way of saying conditionals and loops, because it includes one of the better explanations of closures that I've read to date.

The third part describes "Built-in Classes and Modules", in chapters nine through thirteen. Chapter nine covers some of the Ruby language essentials for Ruby development in the trenches. These include useful syntactic sugar, the family of methods that change data "in place" rather than returning a modified copy, some of the tricky aspects of the Boolean objects and the proper ways to compare two objects so that you get a comparison on their contents, which is likely to be what you want, rather than their memory location. Chapter ten looks at scalar objects: strings, symbols, numbers, times and dates. Chapter eleven examines the Ruby collections: arrays and hashes and discusses when you would use each one, based on their relative strengths. Chapter twelve looks at the regular-expression facilities within Ruby and chapter thirteen wraps up our tour of Ruby with some of the dynamic aspects of the language, including the "eval" family of methods that allow a Ruby program to run arbitrary code.

The fourth and final part describes "Rails Through Ruby and Ruby Through Rails". To quote the book, the purpose of the fourth part is "helping you get more out of Rails by knowing more about Ruby." To this end the simple application created in the first part of the book is revisited and revised. Chapter fourteen starts us out with remodeling the application written back in chapter three. Chapter fifteen looks at programmatically enhancing ActiveRecord models. Chapter sixteen covers the options available for enhancing the controllers and views. Finally, the part wraps up with chapter seventeen where techniques (and much encouragement) for exploring the Rails source code are shared.

The writing is excellent and the style is very engaging. Every concept is stunning well explained. Much as I liked and enjoyed "Programming Ruby" (the "pickaxe book" to it's friends) by Thomas, Fowler and Hunt, this book takes the state of Ruby writing to a new level.

The progression of the book is very well thought out. The first part introduces us to both Ruby and Rails. You can create basic Rails applications with very little Ruby and that's exactly what this first part walks you through. Then parts two and three teach Ruby skills and idioms that are directly applicable to Rail application creation. Part four takes these new skills and shows them being applied to the second Rails application of the book. I found this to be a very good sequence for progressing through the material.

The examples in the book are excellent and many of them are geared towards Rails-style situations. This not only helps to teach Ruby skills, but also keeps the Rails context firmly front and center during the process.

The index on this book is a magnificent 17 pages. That's not something you see too often.. The art of a good index seems to be somewhat lacking these days, but this book helps to redress the balance.

If Ruby on Rails is of no interest, then this book is most likely not the one you want. Also, if you were looking for something with an exhaustive, reference-style, coverage of Ruby, perhaps you'd be better off considering something like the "Programming Ruby" book.

This is a great book, that's very easy and enjoyable to read. It's a stunningly well written explanation of real-world Ruby skills for Rails development."

You can purchase Ruby For Rails from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page
This discussion has been archived. No new comments can be posted.

Ruby For Rails More

Ruby For Rails

Comments Filter:

  • I'm also a type 3 (Score:5, Interesting)

    by andrewman327 ( 635952 ) on Wednesday July 12, 2006 @03:15PM (#15707992) Homepage Journal
    I have trouble learning about things when I do not understand how they work. What I like about this book is that it goes out of its way to explain how the technology works. So many programming books start with: "Now write the following code snippit in the IDE and compile." For the first time reading a /. book review, I actually want to buy this book!
    • OK, I couldn't find it in Wikipedia, and I've never heard the term. What is a type 3? I learn much better when I understand why. Does that make me a type 3 or a type 4 or something?
  • It's about the right time for a RoR book, since things have been moving so much of late, but after 1.0 (1.1) rails things should be 'solid' enough to learn from. I used a few RoR apps for a time, but their instablitiy (which may had been caused my my inexperience) was unforgiveable. Perhaps this book would be a good read.

    • Re:Right time (Score:4, Interesting)

      by tcopeland ( 32225 ) * <(tom) (at) (thomasleecopeland.com)> on Wednesday July 12, 2006 @04:21PM (#15708540) Homepage
      > It's about the right time for a RoR book, since
      > things have been moving so much of late,

      Yup, and this book will last for a while since it focuses on how Rails uses Ruby to do the metaprogramming "magic". So if the APIs move on slightly the techniques in Dr. Black's book still apply.

      For those who aren't on the Ruby lists, Dr. Black is a long-time Ruby user, a founder of the 501(c)(3) Ruby Central [rubycentral.org] that organizes the Ruby conferences, and generally a Rubyist from way back. He's rather a guru but he still answers questions on the mailing lists and generally does a lot of grunt work.

  • Fad (Score:2, Interesting)

    by Umbral Blot ( 737704 )
    I would invest time and money in Ruby on Rails, except that it is obviously a passing fad. This is because Rails is designed to solve a specific problem (serving web pages), and we know for sure that the serving web pages won't be a problem for all time. What people want the web to do, and how we share information over the internet, is bound to change, and when it does the Rails way of doing things will be about as useful as the Java Applet way of doing things (which was for a time The Big Thing, but now
    • You're right about ActionPack. The other parts of Rails are extremely useful in just about every domain.

    • Re:Fad (Score:5, Interesting)

      by mclaincausey ( 777353 ) on Wednesday July 12, 2006 @03:47PM (#15708248) Homepage
      There's no reason to assume that Rails will fail in the near term. Rails is based on a method of decomposing software functionality that does back to the 1970s (Model-View-Controller). Rails might not be here forever, but it has a very solid architectural foundation and it is easy to adapt it to the latest trends (for instance, you can create AJAX-based Web applications very easily with RoR). In other words, the extensibility and architecure of Rails make it adaptable, just as you mention Ruby being adaptable.

      • Re:Fad (Score:2, Interesting)

        by Umbral Blot ( 737704 )
        Your very wording however reveals the difference that I am driving at. Consider "the extensibility and architecure of Rails make it adaptable". This implies that one has to work to adapt Rails to new situations. You would not say the same thing about a programming language. A programming language simply is adaptable, one doesn't have to work to adapt it to new kinds of algorithems. The distinction I am making here is that you can learn something X (say Ruby) which you can apply to many tasks, or you ca
        • So you're expecting an application framework that adapts itself to any forseeable trend? Good luck with that. For the time being, any framework that is easy to adapt will have to do, at least for those of us living in the real world.

          Any Turing complete language is adaptable in some sense. And programming languages do indeed have to be adapted, and that adaptation requires work. That's why you write libraries, and why features are added over time.

        • "This implies that one has to work to adapt Rails to new situations. You would not say the same thing about a programming language."

          Are you even a web developer? You're defending programming languages by saying that they allow for future changes simply because algorithms are written with them, but you then turn around and call Rails unadaptable to "new situations" because it has an API.

          Last I checked 100.0% of the dynamic content web developers out there actually use an API of some kind. It's lunacy to call
          • ...because its API doesn't work with what's smokin' hot in 2011...

            Hi. I just got back from 2011, and we don't use RoR any more. I came back because my head chip was based on it and my GF is upset because my web pages don't fit in her small-format stack. Anyone got the source RNA here?

        • So do you not know any libraries or frameworks in other languages? Do you write your own printf since, sooner or later that'll change too. Do you use DirectX /OpenGL or do you directly address VRAM? I don't think anyone is arguing for learning a framework (rails) without knowing the language (ruby). In fact that's what the book in question is about: learning the underlying language.

        • Your very wording however reveals the difference that I am driving at. Consider "the extensibility and architecure of Rails make it adaptable". This implies that one has to work to adapt Rails to new situations. You would not say the same thing about a programming language.

          Rails isn't a programming language. It's a framework, and yes, it is aimed at a particular situation. It's aimed at web developers who want to be able to make web applications. If you're a web developer wanting to make powerful, vers

      • > you can create AJAX-based Web applications very easily with RoR

        Right on. Ditto with RJS - we're using them on the indi site [getindi.com] (click the comments section to see it in action) and they work nicely. A very little bit of Ruby code gets you the Javascript functionality you want. And Rails' architecture seems to make that sort of thing easy to add.

      • Re:Fad (Score:3, Insightful)

        by Decaff ( 42676 )
        There's no reason to assume that Rails will fail in the near term. Rails is based on a method of decomposing software functionality that does back to the 1970s (Model-View-Controller). Rails might not be here forever, but it has a very solid architectural foundation and it is easy to adapt it to the latest trends (for instance, you can create AJAX-based Web applications very easily with RoR). In other words, the extensibility and architecure of Rails make it adaptable, just as you mention Ruby being adaptab
        • > It assumes that the database schema is the centre of the data model.

          Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services [rubyforge.org]. So AR may be a bit more flexible than your post indicates...
          • "It assumes that the database schema is the centre of the data model.

            Hm, although, the folks from salesforce.com wrote a ActiveRecord adaptor to their web services. So AR may be a bit more flexible than your post indicates...

            No, it isn't - not really. The issue is that your data model is determined by one source - it doesn't matter if this is a web service, or if it is a relational database.

            A data model should be independent of the mechanism of persistence. You should be able to persist the same data mode
            • > You should be able to persist the same data model
              > to web services, databases, XML and so on

              If you need that functionality, yes. If you only need to write to/from a specific persistence mechanism, then using a good solution for that persistence layer may be a good way to go.

              > This is why most ORMs have a separate mapping layer, which protects against this.

              I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.

              An
              • "> This is why most ORMs have a separate mapping layer, which protects against this."

                I'd submit that many web apps don't need really this layer and that, in many cases, introspecting the DB like AR does is plenty good enough.

                The thing is, it leads to fragile code. Changes in a schema lead automatically to changes in code, which are potentially hard to trace, as they happen only at run time. Also, it can seriously inhibit portability, as schema changes are almost always necessary to some extent when swi

                • Re:Fad (Score:2, Informative)

                  by gigahawk ( 745812 )
                  Decaf this is the same thing you say on every rails thread. Rails is an 80% solution. Screw portability it is not a serious problem to most people. I don't know any companies who are switching database vendors more than once every 4 or 5 years, and when they do it's because they are writing a new application. This is the real world, who cares? We already have many tools written in ruby for consuming and modifying data from outside services and they work just fine in rails. This is not a "problem", this is
                • > Sorry, my opinion is that introspecting the DB (or any
                  > persistence mechanism) at run time is a seriously bad idea, for many reasons.

                  Ah, well, in that case, you're definitely unlikely to be happy with AR :-). Well, anyhow, best of luck!

                  • Re:Fad (Score:3, Informative)

                    by Decaff ( 42676 )
                    Ah, well, in that case, you're definitely unlikely to be happy with AR :-). Well, anyhow, best of luck!

                    Indeed :)

                    It is a shame that AR has such publicity when there are far better approaches, in Ruby, which could have been used in Rails instead, like Og.

                • "The thing is, it leads to fragile code. Changes in a schema lead automatically to changes in code, which are potentially hard to trace, as they happen only at run time."

                  I have never used any framework where changing the schema didn't lead to all kinds of problems. Rails is actually more resilient then most because objects automatically morph with the change and with frequent use of iterators it drastically reduces the amount of code that needs to be fiddled with.
                  • I have never used any framework where changing the schema didn't lead to all kinds of problems. Rails is actually more resilient then most because objects automatically morph with the change and with frequent use of iterators it drastically reduces the amount of code that needs to be fiddled with.

                    No, it is the other way around. Rails less resilient because objects automatically morph with the change. This automatic morphing is the aspect of Rails ActiveRecord that I consider to be both uncessary and dange
                    • Well those types of frameworks already exist. J2EE immediately comes to mind as well as hibernate, ibatis etc. The rails people have produced an alternative to those types of frameworks because they didn't want to define something in two places (or three or four or five or sixteen). In other words it's not a bug, it's a feature.

                      If you don't like that feature of Rails then it's not for you but DRY is a major selling point of rails. It sounds like you would be more comfortable with J2EE.
                    • Your tests (you are writing tests, aren't you?) will already catch any problems that arise from changing the schema. Unless of course your production database just changes at random. In which case you've got way bigger problems.

                      One of the golden rules of development is that you can't predict what data people will throw at your code. However, with Rails/ActiveRecord you can't even predict what your code is! The tests you would have to write are phenomenal - you would have to check for the continued existe
                    • Well those types of frameworks already exist. J2EE immediately comes to mind as well as hibernate, ibatis etc. The rails people have produced an alternative to those types of frameworks because they didn't want to define something in two places (or three or four or five or sixteen). In other words it's not a bug, it's a feature.

                      If you don't like that feature of Rails then it's not for you but DRY is a major selling point of rails. It sounds like you would be more comfortable with J2EE.

                      Sorry, but this is wil
                    • "Sorry, but this is wildly out of date. J2EE can be just as DRY as rails. "

                      No it can't. As you said you need a mapper file to map your database to your objects.

                      "For example, with Hibernate and with other ORMs used with J2EE, you can generate you Java classes from a database schema (or part of that schema). However, unlike Rails, this is only done when you request it."

                      Once again that's precicely the point. Class generation has been around for decades now. Rails specifically didn't want to do that.

                      "This is no
                    • No it can't. As you said you need a mapper file to map your database to your objects.

                      In those ORMs that do, it can be generated for you - either from your schema or your classes. You need not touch it yourself. In many ORMs (such as JPA) you need no mapping file at all.

                      Once again that's precicely the point. Class generation has been around for decades now. Rails specifically didn't want to do that.

                      No, you are missing the point. Class generation has been indeed around for decades. But the modern approach
                    • Not at all, it's entirely implicit. As your application runs through the tests, the missing methods will raise an exception. It's no different than removing a method that exists right in the model.

                      This just doesn't work effectively for substantial applications (at least in my experience). You can't test all parts of all the code all the time - this effectively removes the agility of Ruby.

                      Database schemas don't just change at random. To do it the Rails way you even have to write a Ruby script (a migration) t
                    • "But the modern approach is to define your data as classes and have schema generation (or something called 'meet in the middle', where schema and class definitions interact). Rails gets it the wrong way round - the relational database is a very poor place to define object models - this was a lesson learned decades ago (but apparently, not learned by Rails)."

                      Rails can do that. It's called migrations. You should look into it. They are really cool. Once again you need to learn about the thing your are pissing

    • Re:Fad (Score:5, Insightful)

      by misleb ( 129952 ) on Wednesday July 12, 2006 @03:48PM (#15708255)
      I would invest time and money in Ruby on Rails, except that it is obviously a passing fad. This is because Rails is designed to solve a specific problem (serving web pages),


      Doesn't this apply equally well to every other web framework out there? Browsers are designed to solve the specific problem of reading web pages? Are they just a fad too?

      -matthew

    • Re:Fad (Score:2, Interesting)

      by JoeyLemur ( 10451 )
      You're basically saying the web is a passing fad, then.

      And your arguement of Rails killing Ruby when it stops being the flavour-of-the-week doesn't hold much water... Perl was associated quite closely with CGI programming back in the day, and its grown beyond it.
      • No, but I am saying that our current expectations of the web (I'm looking at you AJAX) are a passing fad. Next year there will be some other hot new web technology that will make Rails and AJAX obsolete. It might even make web pages obsolete, who knows. The point is that it is better to keep your options open since the future is unknowable.

    • I knew it! (Score:2, Interesting)

      by Mateo_LeFou ( 859634 )
      I've been dodging the whole Rails gestalt, and I can't say exactly why. I watched that cute video where the guy puts together the blog in about 10 minutes, and I'm all "cool, okay". And I did that and woot!

      Then I decided to put together a blog that worked a little differently... and realized that to do so, I needed to spend a few months learning Ruby. not woot.

      Maybe I didn't stick with it long enough, but it just seems like another micromanaging "framework" to me.

      • Re:I knew it! (Score:5, Insightful)

        by misleb ( 129952 ) on Wednesday July 12, 2006 @03:56PM (#15708324)
        Are you being facetious? Or are you actually annoyed that you had to learn a programming language and a framework to do something useful with Rails? I can't tell.

        -matthew
        • I think you are missing the point of your parent poster. He is merely pointing out the fact that the video makes it seem like things can be done in 10 minutes; the people "advertising" Ruby on Rails are emphasizing the speed in which one can "bang out" some web app, like a blog. I cannot attest to how easy or hard it is do so, because I have never attempted myself. However, the video does make it look easy, with major catches - namely, learning the actual language, because one does not simply know from birt

          • However, the video does make it look easy, with major catches - namely, learning the actual language, because one does not simply know from birth how to do everything he is doing to make his blog.

            Why does this seem like such a "duh!" moment to me? Rails DOES make it easy to make things like blogs, but you'd have to be either extremely lazy or dimwitted to think that you could do it without learning something. I mean, you saw (in the video) that you actually had to input some Ruby code. Where did the grandpa

            • Agreed -- but perhaps the Ruby people should have a disclaimer similar to the one on commercials for diet pills where they show a person losing 70 pounds in a month: "Results not typical."
            • But see, that's a problem I've encountered recently; one of my team members for a project we're working on was all gung-ho about doing it in Rails, convinced that we could put things together as "one-liners" (his favourite word now, it seems). From the early stages, he was adamant that we do it in Rails, even though neither myself nor the third person in the group knew Ruby or Rails. So about halfway through the planning stages, I asked the guy what projects he had coded in Rails in the past.

              He'd watched

        • What that video reminds me of is e.g. a demoing a word processor or other document generator. Look, you open this template, fill out the fields in this wizard, and you've got a pretty, laid-out invoce you can print and send!

          Great unless your business is unusual in some way they hadn't predicted -- that is to say if your business has a significant, novel differentiation that sets you apart from all other business. That is to say: if your business is sound.

          I have no problem learning a programming languag

    • Re:Fad (Score:5, Funny)

      by DysenteryInTheRanks ( 902824 ) on Wednesday July 12, 2006 @04:12PM (#15708458) Homepage
      we know for sure that the serving web pages won't be a problem for all time

      Very, very true. When the robots finally rise against us, we will be more concerned with finding shelter from the HoverDrones and their menacing gatling cannons and scavenging food not burned by the fearsome robot fire brigades! Instead of writing CRUD apps, we'll be crawling through sewers with radiation burns, hoping to reach the central meeting point for the remnants of the human resistance.

      Massive raditiation from the nuclear explosions will make the mere thoght of a WiFi, WiMax or cellular Internet connection laughable, and the network will in any case have been repurposed by the robots for their own genocidal ends, a grimly ironic rebuke to the original vision of the Internet as an Apocalypse-proof ARPAnet. And in any case, we'll be a tad more concerned with using baseball bats and snowshovels to bludgeon down waves of robots before they reach our cowering families! Rapid development of Web applications will be a bit of an after thought, no?? HaHA, HuhHAAA!

      When deciding whether to starve or to feast on the remains of one's robot-electrocuted best friend, HTTP cookies will tend to be far from one's mind, eh mate!?!? HA!

      As our once-proud cities burn into molten pools of blood and steel, watched by cold eyes of robot-controlled satellites in heliosynchronous orbit and encircled by robots in rupurposed tanks and SUVs, bearing shoulder-launched rockets, "serving web pages" will be the LEAST of our problems, and we will rue the day we thought of the web AS ANYTHING BUT A FAD!! MWHAHAHA!!!! ... or is that not what you meant?
      • a grimly ironic rebuke to the original vision of the Internet as an Apocalypse-proof ARPAnet

        Ha! One of the rare slashdot funny-modded comments that actually contains cleverness. I salute you, sir.

    • Re:Fad (Score:3, Insightful)

      by jaydonnell ( 648194 ) *
      Almost every problem that someone solves is a "passing fad" by your definition. Why learn how to build bridges when we will have flying cars one day? The reason is that learning how to solve an immediate problem well, i.e. serving web pages, will help you know how to solve other, future, problems. Learning rails helped me understand what good clean code should look like. This will help me with any coding problem I try to solve in the future.

    • I would invest time and money in Ruby on Rails, except that it is obviously a passing fad. This is because Rails is designed to solve a specific problem (serving web pages), and we know for sure that the serving web pages won't be a problem for all time.

      This is one of the strangest reasons I've ever heard for not learning Ruby on Rails. Whilst the web may eventually be replaced by another system, I see no indication that this will happen any time soon. Certainly a number of firms believe it will be around

  • actually (Score:5, Informative)

    by aleksiel ( 678251 ) on Wednesday July 12, 2006 @03:41PM (#15708191)
    i went to purchase a rails book the other day and gave this book and the book "Agile Web Developent with Rais" and found the agile development book to be better, imho. and $10 cheaper.
    • > i went to purchase a rails book the other day and gave this
      > book and the book "Agile Web Developent with Rais" and found
      > the agile development book to be better, imho. and $10 cheaper.

      I think they serve different needs. Get the Agile book to learn how to build a Rails app, and then get Dr. Black's book to learn how Rails works under the covers.

  • Oh Ruby... (Score:4, Funny)

    by Penguinshit ( 591885 ) on Wednesday July 12, 2006 @03:45PM (#15708231) Homepage Journal

    Every time I see the name "Ruby on Rails" it reminds me of this coke-whore who lived in my college dorm...

  • Soon to be obsoleted by Airways for Python (Score:5, Funny)

    by Outland Traveller ( 12138 ) on Wednesday July 12, 2006 @03:56PM (#15708327)
    Guido van Rossum was heard exclaiming that he was developing with SNAKES on a PLANE.

  • RoR -- Made for Java Devs (Score:3, Insightful)

    by fupeg ( 653970 ) on Wednesday July 12, 2006 @04:45PM (#15708705)
    For those of us who have developed web applications with Java, this is a welcome break.
    People like to think that RoR came from the same spring that produced Python and PHP. That might be true of Ruby, but not RoR. Nope, RoR is made for Java devs. That's why they make such a big deal about the lack of configuration. Java frameworks have a notorious amount of configuration. RoR is very natural for Java devs who are also used to MVC frameworks for web apps. It is not as compelling to PHP and Python developers, even though Ruby is a lot closer to those languages than it is to Java.
    • yeah this is a good point. I've tried to explain Ruby on Rails to both php developers and java developers and the java developers just get it.. they completely understand the benefits and usually fall in love with it.

      On the other hand, the php developers really have a tough time grasping the concepts behind RoR. I think this is mostly because they have ever seen a MVC pattern. They are so used to mixing all their business logic in with their HTML, it's hard to comprehend the benefits of RoR and using an MVC
  • Quit the hype allready. There are at least 3 oss web packages out there that are better in more than just a few aspects:
    django ( http://www.djangoproject.com/ [djangoproject.com] )
    Symfony ( http://www.symfony-project.com/ [symfony-project.com] )
    Zope ( http://www.zope.org/ [zope.org] )
    Zope is by far the oldest and most sophisticated. Django is Rails done right and in Python and Symfony is a PHP metaframework that includes Propel and some other third party goodies with tons of very neat PHP 5 foundation work. Each one of these kick Rails up and down the street
    • Django:
      Overall very nice. No capistrano, no migrations, no built in support the unit testing like rails. Great admin interface, very fast.

      Symfony:
      Don't know, never used it, never will because it's PHP and I don't like PHP anymore.

      Zope:
      Aaah zope. So much innovation, so much potential, so much going for it but in the end so hard to learn and use. Very slow. documentation not all that great. TTW design is a HUGE drain on productivity. No support

    • Re:Slashdot - Where Rails gets the hype. (Score:5, Interesting)

      by flipper65 ( 794710 ) on Wednesday July 12, 2006 @06:17PM (#15709220) Homepage
      Having just come off of a review of these exact frameworks for adoption at our firm I have to take exception with some of your statements. I will absolutely give you performance for all of these exceeding that of rails, however, ease of deployment (Capistrano for comparison),ease of use (have you really looked at Zope/Plone and tried to do anything really useful with it?), and, oddly enough, other than Zope, there is more documentation for rails than for either of the other two frameworks. I am including the three ruby/rails books that are currently available as rough cuts through O'Reilly's safari service.

      We settled on rails because it was faster to iterate and develop, the whole MVC design pattern just screams out to be used in database driven website design, and rails is just flat out more fun to work in than PHP ever was. Even if it turns out not to be the wave of the future, having worked in ruby using rails has already begun to teach our developers to think in terms of convention over configuration, standards and object orientation.

      Really, it's been a win for us. Also, the ruby for rails book is an outstanding read, I would also recommend enterprise integration with ruby as a good next step.
    • Rails ain't hype, as a fulltime Java programmer who got a little too curious, I can tell you that this is the real deal. I dislike people who discount other languages and frameworks just because it isn't their favorite framework they've been using. Attachment is an awful trait in the programming industry. I won't discount any of the frameworks you've mentioned because I simply havn't used them, but in comparison to Java frameworks I've used for many years, Rails blew them all away. I see a bright future f
      • I think he is more opposing the "silver bullet" hype. Ruby with rails or no rails is no silver bullet. RoR does give advantages, mostly to developers, can save time in some projects and be a great idea or at least provide groudn for great ideas to grow from.
        If you're a little bit experienced in how applications scale and how good the products of big brothers are in this (either java or dotnet) you can clearly see that ror is not an answer to everything. It just makes some stuff simpler, and in it's
    • I have to agree with this. Django, while underdocumented (again though, thanks to Mr. Spolsky's Law of Leaky Abstractions [joelonsoftware.com] needing to go through the source to learn how something works is acutally a pretty good learning metaphore) is really the framework Rails should have been. Dynamically compiled models, complete decouplization from it's separate components (don't like the template system? use something else! or just write HTML to the output. or XML. or whatever), and thanks to the recent branch merg

  • Rails needs to be more mature (Score:4, Interesting)

    by FooBarWidget ( 556006 ) on Wednesday July 12, 2006 @05:10PM (#15708860)
    I've tried Rails. It's pretty good, but it needs to be more mature because it lacks support for the more advanced stuff. Among the things that it currently (seem) to lack are:

    - Support for saving database records using database function. In other words, I want Rails to automatically perform a query that looks like this:
    INSERT INTO foo VALUES(NOW());
    I want to insert a record that uses the database server's time instead of the web server's time.

    Or, something like this:
    INSERT INTO foo VALUES('bar', INET_HTON('127.0.0.1')); --- notice the INET_HTON() part
    In this example, I want to store IP addresses as integers in the database.

    - Apache integration is still too immature. I don't know about Apache 1, but Apache 2 integration using FastCGI doesn't work *at all*. The documentation on the website about Apache integration is very messy: different pages suggest different things. After much research I found out that:
    (1) mod_fastcgi (not FastCGI itself, which is something else!) is dead, use fcgid instead.
    (2) Integration using fcgid doesn't work either!
    After a lot more research I found a working solution: make Apache proxy requests to a lighttpd server, which is running the Rails app. This doesn't seem like an ideal situation.

    - Documentation is still too immature. While the API references are pretty good, the Wiki is very messy (see Apache integration).
    • Mongrel is the latest and greatest to handle rails requests. http://mongrel.rubyforge.org/ [rubyforge.org]

      It's a http server written ruby(and c where speed matters) that is very easy to install and get up and running and performs as fast as lighttpd.

      What a lot of people are doing is setting up apache 2.2 to serve static pages, and proxy any rails requests to mongrel... There's no fastcgi/fcgid involved.
      • As someone who tried for a good couple months to make FastCGI work properly for a production app that needed reliability, mongrel has been a savior. I love Rails, but was beginning to think it was unworkable for anything important because of FastCGI's(specifically mod_fastcgi's) flakiness

        The only real downside is the bleeding-edge technology needed(i.e. Apache 2.2 w/ mod_proxy_balancer)

    • What's wrong with mod_ruby that you're trying to use FastCGI?

      I know nothing about rails, does it not work with mod_ruby?

      • "What's wrong with mod_ruby that you're trying to use FastCGI?"

        I did a lot of research trying to figure out why the wiki usually recommend FastCGI instead of mod_ruby. Try reading this [shugo.net]! I quote:
        "Having 100 Apaches with 10 FastCGIs will use only 800MB of memory while having 100 Apaches each containing mod_ruby process can easily use 3GB of memory."

        So no mod_ruby.

    • I use PHP for the kind of work you mention, together with the Adodb library [sourceforge.net] which is an abstraction layer for the database access. If you want to, you can also use the raw SQL statements in PHP, but that's rarely needed and I don't recommend it for portability reasons. As a framework for normal enterprise intranet web applications I use eGroupWare [egroupware.org].

      With these tools, I have never found any need for Ruby, with or without Rails. I tried it and the first thing I noticed was ugliest quirk they stole from FORTRAN-

      • Funny, but I've coded for a living off and on for over a decade, including in PHP, and don't consider the inclusion of an "end" statement instead of a closing brace to be a damning indictment of a language. You're essentially arguing that not using C-like syntax shows a language isn't very well thought out.

        Suppose you had an array of hashes -- in PHP, something akin to:

        $mood_list = array( array( "id" => 0, "mood" => "happy"), array("id" => 1, "mood" => "grumpy"), ...)

        You need to know what the hi
        • There are other languages you could do this as easily in, but PHP is not one of them.

          One should use the best tool for each application. When all you need is to set up a way for people to access a database in a corporation intranet, then the best tool is PHP, because it is the quickest way to create an interface between SQL and HTML. You don't need closures or blocks of code as parameters for that. SQL has all what's needed to handle the database. But when I want to get data from a web form, all I need to d

          • In a Rails form, I might type

            <% form_for :user do |form| %> <%= form.text_field :name, :size => 40 %>

            And then access that returned variable with

            @user.name

            I suppose I'm not seeing the dramatic productivity loss in doing it that way compared to PHP's approach of

            if (!empty ($_POST)) extract($_POST);

            ...which isn't necessarily safe, anyway, from a good coding practice standpoint. (I tend to use the EXTR_PREFIX_ALL option for extract, which isn't necessary with Rails--the returned form

    • - The documentation is provided by the community. Have you posted your apache configuration? Ruby is a much meatier program than Perl or Python or PHP and as a result, doing CGI the non-fast cgi way isn't an option. The fact that Apache has problems with fastCGI isn't the fault of Rails however.

      - I don't know how far into the API you've looked, but there are most definitely ways of using literal SQL statements rather than .save().

      - Yes the wiki could use some work, and this is something any rails fan can
      • - I don't know how far into the API you've looked, but there are most definitely ways of using literal SQL statements rather than .save().


        The point is, I don't want to do literal SQL statements, I want Rails to do it automatically for me. I want to store IPs as integers in the database, but I want the model to expose them as strings.
        And in the future I may want to use stored procedures to create database entries.

Slashdot Top Deals

Dennis Ritchie is twice as bright as Steve Jobs, and only half wrong. -- Jim Gettys

Close