Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

Practical Ruby Gems 101

TimHunter writes "I was skeptical when I first saw the title of David Berube's new book, Practical Ruby Gems, from Apress. Do Ruby programmers really need a book devoted entirely to add-on libraries? Most Ruby programmers already know about the RubyGems package management system, and most already have their set of favorite gems. About a third of the way through the book I grudgingly admitted that Rubyists might be able to use this book. After all, even long-time Ruby programmers are unlikely to know about all the gems covered in this book. So then I had a new question. Would I find something in this book that made me say 'I didn't know you can do that with Ruby!'" Read on for the rest of Tim's review.
Practical Ruby Gems
author David Berube
pages 271
publisher Apress
rating 8
reviewer Tim Hunter
ISBN 1-59059-811-3
summary A survey of useful and interesting Ruby libraries
Ruby is an object-oriented programming language in the same family as Perl and Python. The programming language used by Ruby on Rails, Ruby is very popular for writing web applications but also widely used for general-purpose programming tasks. Ruby is open source with a commercially friendly license, and is available for Linux, Mac OS X, and Microsoft Windows. RubyGems is Ruby's system for managing, delivering, and installing third-party libraries and applications. It is similar to Perl's CPAN or the Python Package Manager.

Libraries distributed by RubyGems are called "gems." RubyForge is the central Ruby software repository and the primary distributor of gems. According to sysadmin Tom Copeland, RubyForge currently hosts about 1400 different gems. Of that number, Berube selected 29 useful and interesting libraries for his survey of "practical" gems. All of the gems described in this book work the same on Linux, OS X, and Windows.

Practical Ruby Gems is divided into three parts. Part 1 describes the RubyGems system itself. This part explains how to install the RubyGems software and then use RubyGems to install and manage individual gems. (RubyGems is not part of Ruby's standard distribution, except in the "one-click installer" for Microsoft Windows.) The section entitled "What is require_gem?" in Chapter 3 demonstrates one of the problems with writing technical documentation for a moving target like RubyGems. Practical Ruby Gems describes RubyGems 0.9.0. After the book went to press the RubyGems team released a new version that replaced the 'require_gem' method with a method called simply 'gem'. Currently all uses of 'require_gem' generate a warning message. (The remedy for this mistake is simple: attach a yellow sticky with the words "s/require_gem/gem/g" to page 20.) This is really a nitpick, though. Generally the text and examples in the book work as well for the new release as they did for 0.9.0.

Part 2 is by far the largest and has a chapter devoted to each of the 29 gems. The chapters in this part share a common structure. After a short introduction to the gem, there is a section entitled "How Does It Work?" which explains the purpose of the gem and how it's used. Frequently this section includes a small example. "How Does It Work?" is followed by a complete example script. Then, "Dissecting the Example" steps through each part of the example, explaining how it works and pointing out important classes and methods. The examples frequently combine two or more gems, such as the example for pdf-writer, which also uses the net-sftp gem, and the example for the mongrel web server gem, which also uses the Camping web micro-framework gem.

The examples — always practical, frequently interesting, at least to a geek like me — are the heart of the book. Berube said that "no one wants to pay to read a chapter that regurgitates [the gem's built-in documentation]....I wanted to write a book that you could take the examples and actually be interested in what they accomplished." For instance, Chapter 6 describes the BlueCloth text-to-HTML conversion gem. The example in this chapter is a script that converts lightly marked-up text to PDF by combining BlueCloth with html2ps and ghostscript. Chapter 12 describes the yahoofinance gem, a library for retrieving stock quotes using the Yahoo! Finance API. The example for this library combines yahoofinance with the fxruby GUI library to produce a rudimentary stock ticker in less than 100 lines of code. (The source code for all of the examples in the book can be downloaded from the Apress web site.)

But not every example is perfect. Several of the examples rely on MySQL, which I found a chore to install. I wish Berube had chosen a simpler data base for these examples. I never did get the Camping example to run successfully. I suspect the problem was caused by some change to a gem introduced after the book went to press.

In Chapter 22 I got my "you can do that with Ruby?" moment. This chapter explains runt, a Ruby library for creating "temporal expressions," objects that describe dates that reoccur, such as "every Thursday" or "the last Thursday of every month." The example combines runt with linguistics, a small gem that extends some of the Ruby core classes with methods that support such things as pluralization and conversion from numbers to words. The result is a program that lists a set of dates expressed as "the 3rd Mondays of 2026." I was impressed by both gems, not only for the functionality they provide but by their natural and elegant interfaces as expressed in the example script. I not only learned about two very practical Ruby gems, but something about Ruby programming itself. This particular example may not strike everybody the way it did me, but I believe that most readers will find an equally pleasant surprise.

Part 3 is a tiny, advanced topics section which describes how to create and distribute your own Ruby gems and how to run a private gem server on a local network.

Practical Ruby Gems is not for the novice. Berube assumes that his reader is familiar with programming in general and Ruby specifically, and is also familiar with the operating system in which Ruby is running. This is an appropriate assumption because Practical Ruby Gems will be most useful to readers who are serious about programming Ruby, such as professionals or serious amateurs, or those would like to become professionals or serious amateurs.

Practical Ruby Gems is available in PDF format from the Apress web site at about half the price of the paper book.

I have been programming Ruby as a hobby for over 5 years. I am the maintainer of RMagick, one of the gems reviewed in this book. Apress gave me a review copy of Practical Ruby Gems, but otherwise I have no connection to the author or publisher.


You can purchase Practical Ruby Gems from amazon.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.

Practical Ruby Gems

Comments Filter:
  • Does anyone here remember books like O'Reilly's "The Whole Internet" (http://www.oreilly.com/catalog/twi2/index.html)?

    With things like blogs and wikis are dead tree versions of these sorts of catalogs really useful or relevant any more?

    The debates here on slashdot rage on about global warming and being "environmentally friendly"... yet how can anyone support a book like this when it could just as easily have been published as a web page?

    I stopped wasting time and money on books like this ages ago. I cannot
    • I find that some books are useful as a way to initially get into a language, simply because most of the online material can be fairly specific and not geared towards getting you acquainted with the subtleties of that language.

      but by the time i've used said book for a few weeks or a month, its generally not as good as a reference piece as something found on the web might be. Its especially easier to find an example of how to do a certain action with a good old net search than it is to thumb through the book
      • Re: (Score:3, Interesting)

        by numbsafari ( 139135 )
        But this book isn't about learning the language. It's a catalog of third-party packages you can use with Ruby.

        A book that documents something that isn't going to change, or develops a concept that requires more than 20 pages of text certainly deserves to be a book.

        But a shopping list belongs in a PDA.
      • I find that with a pdf I will almost allways skip forward to what I need ther n then even if I'm sertain the rest would be intresting to.
    • by AvitarX ( 172628 )
      Either a) you never have to shit
      b) you can use the internet while shitting without someone constantly shaming you with masturbation jokes.

      Aside from shitting, I also find I can read 30 pages or so a night while in bed before going to sleep. Sitting at a computer still leaves me wanting to read in bead or stair at the ceiling for 30 minutes.

      I know many of these books are best used when at a computer ect., but I can still get $50.00 value
    • In certain rare cases, a hardcopy can be vastly more worthwhile than an electronic copy. (Ever try to keep a system running in a shop filled with steel and aluminum dust? Let me tell you this, power supplies + metal dust + grease/oil residue == really interesting arcs if not properly contained in an enclosed office)
      Granted this doesnt really seem to be THAT kind of a case unless theres a large market of Ruby coders working in environments that preclude having a net connection (which would be mindboggling =)
    • Big Fat Books (Score:5, Interesting)

      by kahei ( 466208 ) on Monday June 18, 2007 @04:20PM (#19556183) Homepage

      As someone who just bought a paper copy of the Unicode 5 standard, with annexes and code charts and all, weight 10lb or so, even though it's all downloadable for free, I am really getting a kick out of these replies.

      So why did I buy it? Why not read the PDFs that are thoughtfully provided free by the Unicode Consortium?

      1 -- I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.
      2 -- As a book, the size of the different sections is much more real to me. I know this sounds wierd but with the book I can have insights like 'boy, the addition of Cuneiform bulked out Plane 0 by *this much* that I wouldn't have with PDFs. It helps with situational awareness, I guess.
      3 -- When I want to show it to someone, I go "Hey, look at this bit here in annex 15!" And they look. If I go "Hey, when we get near some wireless access, go to this site and click 'annexes' and then number 15 and it's section 13.7 near the bottom!" they ain't gonna look.
      4 -- Same applies when the 'someone' is me.
      5 -- I see the book, with its myriad post-it notes and bookmarks and marginalia and apprehend it as a whole. This does not happen with a website. With a website I don't even know if I've read it all.
      6 -- etc etc etc ad nauseam.

      Now I don't even like Ruby -- I was a big Ruby fan back in about 1998 and like many other first-generation Ruby fans I learned a harsh lesson about what happens when the whole project is dictated by one xenophobic Japanese guy. Plus as you can deduce from the above I kind of need multilingualization! But if I were still into Ruby this is just what I'd want -- a book I can just pick up off the table in front of the TV, and get an idea, and show the page to someone else, maybe even cite it later. Not a website that changes and that I have to have a computer to read and that requires instructions like 'go to this URL, click on this'. A book! That's why we have them!

      It's what's for breakfast!

      • I'm curious as to your description of Matz (at least I assume that's who you're talking about). I'm pretty new to Ruby but am very interested it's success. Why do you refer to him as a xenophobic Japanese guy and what harsh lesson did you learn?

        I'm not asking to get into an argument or anything just curious as to the history of the language and to understand how and why things happen in its development?
        • Re:Big Fat Books (Score:5, Interesting)

          by kahei ( 466208 ) on Monday June 18, 2007 @05:26PM (#19557057) Homepage

          Well, I didn't really mean 'xenophobic' in the KKK sense so much as in the 'Not Invented Here' sense. I really don't think /. is the place to go into agonizing detail, especially as I am kind of about to eat now. However generally at the time I was thinking of (late 90s) I found there were some disheartening things about Ruby as a project (rather than as a language):

          -- Only a very small core of Japanese people who knew Matz really got to commit anything. Not in that core? No matter how great the value of what you try to commit, you might as well gived up.

          -- Unicode? That's an evil anti-Japanese conspiracy. We must wait until suitable Japanese standards like konjaku mojikyo are mature enough to support. Until then Ruby has built-in support for specific Japanese encodings and the rest of the world doesn't matter. This endlessly-repeated debate partly inspired my page about Japanese attitudes to Unicode [hwacha.net].

          -- Matz used (and still uses AFAIK) Unix only. If it's part of unix (eg fork()) it's in Ruby. If it's not (eg proper threading) it's not in Ruby. Similarly, Matz is used to old-style C with global static vars all over the place, and therefore that's how Ruby is always gonna be. Having been an IT manager in Japan on occasion, I'd say it's a cultural thing that there's no point fighting. Sure, Ruby 2 is right around the corner. Sure.

          -- Documentation is hobbyist-grade. I admit that while writing this post I googled a bit to check if my memories were still valid. I found that there is a project devoted to deducing the Ruby standard by experimenting with the Ruby implementation. If you can't see the problem with that... :)

          Of course back in the late 90s, Ruby 2 was just around the corner and it took a long time for it to become clear that these were systemic, rather than temporary, failings. The current wikipedia page basically sums up everything I just said under 'criticism'. What it fails to mention is that these failings were a conscious decision.

          Disclaimer: I was 100% observer in this process so I'm not a bitter rejected contributor. However, at that time I had high hopes that Ruby might become an industrial-strength language with threading and i18n and a proper spec and so on, and if very slowly and painfully became clear that that would never happen, which was kind of depressing.

          I don't want to bash Ruby. I like ruby. I still write ruby programs. The fact is, though, ruby contains what Matz like to live with, and Matz lives in a relatively old-school world of fork()-ing single-threaded ASCII-piping unix processes with ad-hoc documentation. And any attempt (I didn't make any but I saw plenty made) to change that will be politely and apologetically totally ignored.

          Now I feel a bit dirty for having made my first ever Internet post that is critical of a software project. I would like to say again that I like Ruby and it has it's place and if I were able to use ruby 'industrially' I would want a book such as the one reviewed.

          • by Jonathan ( 5011 )
            Matz used (and still uses AFAIK) Unix only. If it's part of unix (eg fork()) it's in Ruby. If it's not (eg proper threading) it's not in Ruby.

            So, basically you want to make the core of a portable language non-portable? Why *should* the core of Ruby contain non-Unix cruft?

            Documentation is hobbyist-grade. I admit that while writing this post I googled a bit to check if my memories were still valid. I found that there is a project devoted to deducing the Ruby standard by experimenting with the Ruby implementat
          • You are right that most of those issues still do exist. I know Rails was having serious issues dealing with the lack of Unicode and I THINK they came up with a workaround to make it easier to work with non-ASCII characters. I haven't used it much to know whether its a good workaround but it would be nice if it were in the language. I have heard a little about the issues with Japan and Unicode but that article was informative.

            I would totally agree the docs are really bad in some areas. The OpenSSL docs miss
          • Re: (Score:3, Insightful)

            by Kristoph ( 242780 )
            I can only add that given all these issues Ruby has, nevertheless, become hugely popular so I guess someone must be doing something right?

            In the fullness of time, however, if Matz and Co do not meet the needs of the community someone will go off and fork Ruby, or maybe just repackage, document it etc ...

            Is that not the point of open source ... ?

            ]{
          • by pabs ( 1629 )
            I agree with your sentiment, although some of your specific points are dated.

            -- Only a very small core of Japanese people who knew Matz really got to commit anything. Not in that core? No matter how great the value of what you try to commit, you might as well gived up.

            This is no longer true. There are several non-Japanese people with commit access, including Ryan Davis (aka zenspider). There is also a central system for bug reports. More importantly, development decisions are increasingly discussed o

            • by kahei ( 466208 )
              I realize there's no point responding on /. weeks after the original article has left the front page but... thank you for your interesting comments.
      • by suv4x4 ( 956391 )
        I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.

        Oh come on, man! You have a tablet PC, you have a PDF, and you want to read in front of your TV! Think, think!!

        People really got lazy these days.

        jk ;)

        BTW did everybody notice how Ruby's magic worn out lately? The thing was very VERY fast and intuitive to develop basic things in, but kinda hard to deploy and very slow? Funny thing, that.

        That's why I've always said that in IT you're gotta be learning really fast since technolo
      • As someone who just bought a paper copy of the Unicode 5 standard, with annexes and code charts and all, weight 10lb or so, even though it's all downloadable for free, I am really getting a kick out of these replies.

        1 -- I can flip through a book in front of the TV. Not so a PDF. Yes, I have a tablet PC.

        I sit in front of the TV with a magazine, and maybe my DS. You nestle in with a 10lb Unicode book? My friend, you have shot right past "geek" and are solidly in "nerd" territory. Why don't you come b

    • I can see a paper catalog of Ruby add-on libraries being useful, simply because the Ruby web sites are so completely littered with dead projects, projects that have never released code, and so on, not to mention rampant wheel-reinvention.
      • Re: (Score:3, Interesting)

        by numbsafari ( 139135 )
        Consider all the effort that an author puts into compiling such a book as this? Then consider the editor, the typesetter and graphic designer, the pre-press preparation, the printing, marketing and ultimate delivery of a book that is out of date as soon as the contract to even publish it has been signed.

        What if the author simply kept an up-to-date web site with rankings and reviews, removing projects that have gone dead and indicating which projects simply reinvent and which projects actually move the ball
      • Re: (Score:3, Informative)

        by tcopeland ( 32225 )
        > the Ruby web sites are so completely littered with dead
        > projects, projects that have never released code, and
        > so on, not to mention rampant wheel-reinvention.

        That's just the nature of open source. It takes a minute to start an open source project in Ruby or any other language - and neglecting that project take even less time. :-)

        That said, if anyone has a dead project on RubyForge, put in a support request to have it deleted; keep things tidy! And I posted some notes on cleaning up live proje [blogs.com]
    • Some people like reading from a book rather than a computer screen, its easier on the eyes, and sometimes you just want to get away from the screen.

      Though i must admit with the rate that things change i gave up on buying programming books years ago.
  • Installing Ruby on an Apache web server and getting it to work properly. I've seen bits and pieces all over the Ruby Forge wiki and in a ton of Google searches, but nothing that worked.
    • Re: (Score:3, Interesting)

      by CastrTroy ( 595695 )
      Sign up for a hosting service that supports Ruby. While I realize the significance of doing stuff like this yourself, if you really want to just try out a language nothing will stop you quicker than not even being able to get it running. That's why when I look for a web host, I pick one that supports a lot of different technologies, even If I never plan on using them.
    • by f0dder ( 570496 )
      In a similar vein I'd like to see how one gets Ruby to talk to MySQL 5.0.41 on Windows. There's a gem (mysql 2.7.3) for talking to 5.0.27 but I can't find the installer and it doesn't work w/MySQL 5.0.41. The only work around is to use the mysql 2.7.1 gem and stick w/Mysql 4.1.22
      • I don't think I was on MySQL 5 (it was several months ago I did this) but you may want to consider using the mysql-ruby C bindings. I found the pure ruby ones gave me database disconnects all over the place. Yes, there is no slick installer that I know of, and yes, you will probably have to compile it yourself.... but it's an idea. Good luck.
    • Re: (Score:3, Interesting)

      Have you considered using Mongrel instead? It seems to signficantly less wonky than Apache when it comes to running RoR sites.
    • You must be an Apache diehard like myself then--most people I know use lighthttpd. I've actually gotten it to work, if you give me a couple of days I'll post the steps on one of my blogs (http://snappaction.blogspot.com).
    • Yup, someone is already working on it. E.g., the project I'm involved in: http://rubyworks.thoughtworks.com/ [thoughtworks.com] -- Alex Verkhovsky
    • Re: (Score:3, Informative)

      by tcopeland ( 32225 )
      > Installing Ruby on an Apache web server and getting it to work properly.

      The trick here is using Apache 2.2 + mod_proxy + Mongrel. The Mongrel book [awprofessional.com] is well worth the $15, too.
      • The trick here is using Apache 2.2 + mod_proxy + Mongrel. The Mongrel book [awprofessional.com] is well worth the $15, too.

        Yeah, what Tom said - everything else I've tried I've had to declare broken, and I've tried a few (and I've done good battle with all kinds of apache stuff since they forked from NCSA).

        You can also implement mod_proxy in Apache to lighten the load on Mongrel. I have a brief tutorial [bfccomputing.com] for doing this from behind a NAT on my blog, but I still haven't figured out how to get mod_proxy to ign
    • by ari{Dal} ( 68669 )
      Ask and ye shall receive. This is what I used to get ruby up and running on our VMs:

      http://www.howtoforge.com/ruby_on_rails_apache2_fa stcgi_debian [howtoforge.com]

      Not 100% accurate, but any hiccups I ran into were easily solved by installing a few libraries.
    • by lewp ( 95638 )
      If you just want to screw with Ruby, CGI works just fine. Not so much for Rails, though (because Rails is, for all its benefits, "teh hueg").
  • Some books, while useful, are not worth the full purchase price and shelf space. I have bought several books in PDF form this year. PDFs are even better when publishers render the PDF in landscape (horizontal) format - much better for reading on a laptop.

    One advantage of PDF books is that assuming a local search engine like Spotlight or Google Desktop, it is fast and easy to find relevant reference materials.

    That said, I also enjoy my home office bookshelves - satisfying to take a physical book down off the
    • by Hatta ( 162192 ) on Monday June 18, 2007 @05:43PM (#19557237) Journal
      If I'm paying for electronic reading material, PDF is the last thing I want. PDF is for printing; if you need a hard copy just buy the book. What I want from an electronic text is device independence. PDFs are optimized for paper, it's a real bitch to page through them on a screen. I have to keep scrolling, then paging, and scrolling again, and god help me if there are multiple columns per page. HTML on the other hand works great at reflowing the text for whatever device I might be using.
  • Sinve the rubyonrails.com, basecamp.com and other ruby websites all run PHP on their frontend, I was wondering how to scale RUBY. Everytime you talk to RUBY people about scalability, they always point to 43things.com and that seems to be the only one; even so, they require 2-3 times the hardware to so the same job and STILL require PHP in places.
    • by dfg59 ( 697858 )
      The creator of Twitter (as far as I know, one of the most heavily loaded rails apps out there) gave a presentation on scaling at RailsConf this year. The link to the slideshow is below, unfortunately I don't know how much one can get out of it without sound.

      However, sites like http://www.twitter.com/ [twitter.com] and http://www.revolutionhealth.com/ [revolutionhealth.com] are dealing quite well with the scaling issues of Rails. Although it may take a bit more ingenuity, many feel that the substantial productivity boost is worth it. Also, as c
      • Well the productivity boost is gained by the FRAMEWORK (RAILS), not the language. Add a good framework and training to any language and you have better productivity. Still better productivity means nothing if once your web applications starts getting a million hits a day you have to convert all your code to PHP or JAVA to get it to scale. All the productivity is suddenly lost because you have to rewrite all your code.

        And productivity gains at a small to medium size level are MINIMAL to the gains made at
        • Amazon uses it at unspun.amazon.com. It's not the main site but they are using it.

          I also disagree with your statement that Rails is the only reason there is a productivity boost. I've never found a language that feels as natural as Ruby. The standard library seems to anticipate most productivity bottlenecks that you find in other languages and deals with them in an elegant way. Ruby also is incredibly easy to read and understand even if you've never looked at a program before. It's not totally self-document
          • I've never found a language that feels as natural as Ruby. The standard library seems to anticipate most productivity bottlenecks that you find in other languages and deals with them in an elegant way. Ruby also is incredibly easy to read and understand even if you've never looked at a program before. It's not totally self-documenting but sometimes it feels like it is.

            Try Common Lisp. I'm serious; although it's largely useless nowadays (though not because the language has aged; simply because the standar

        • > RAILS makes it easy to develop in but it's achilles heel it's
          > still it's scalability; and it has a problem scaling due
          > to the way it's architectured.

          Nah. We use it on thenewsroom.com [thenewsroom.com]; it's yet another Rails success story [blogs.com].
      • Jason Hoffman's talk at RailsConf [oreillynet.com] also looked at scaling Rails apps. The slides [joyent.com] are available in PDF format.
      • "Although it may take a bit more ingenuity, many feel that the substantial productivity boost is worth it."

        If it takes more ingenuity to get it to work/scale, just how are you getting any substantial productivity boost?
        • Twitter was peaking at something like 12,000 requests per second during the worst of their scaling troubles. Very few sites will ever see that kind of traffic, and keeping up would have been a challenge in any language. Everything is under control now, a testament to both Rails and the Twitter team in my opinion.

          Rails is no speed demon, but getting a product out the door cheaply and quickly is often more important than being able to handle a million hits a day.

        • If it takes more ingenuity to get it to work/scale, just how are you getting any substantial productivity boost?

          This is silly. Getting any application to scale past a certain point is going to require a lot of ingenuity. I guess it depends on where that "certain point" lies.

          Scalability, I think, is one place where Rails' simple architecture helps it. Many (but not all) performance issues can be resolved either through a lot of ingenuity or by throwing more hardware at the problem (or temporarily dedicati

          • After all, you can always just deploy another copy of your app on another box, point it at your database (or database cluster, depending on your needs), and you're good to go.

            With a large site your database is probably the limiting factor; adding more frontends doesn't help. Instead you have to care deeply about what kind of SQL-queries are used, how you can optimize the structure of your database, what data you can cache/pre-fetch, etc... at that point you may come to regret that the whole database inter

    • Ruby web sites run PHP in large part because of the lack of mature Ruby CMS software.

      (That's why I switched to PHP for my web site.)
      • I'm SURE that's why rubyonrails.com, basecamp.com and the other main ruby sites do it... because they have no CHOICE. Because CMS's are so difficult to build. And sarcasm is so hard to craft.
        • Well, whether CMSs are difficult to build or not, last time I checked there weren't any mature ones for Rails. Maybe those web sites decided that reinventing the CMS wheel in Rails wasn't worth it, because developing a CMS wasn't one of their goals.
          • yeah... that's the reason... CMS's are the reason why no big sites are deploying RUBY. CMS's are the reason why PHP is the answer to RUBY's scalability. That must be it. You figured it out!
            • by unDees ( 116113 )
              Who said PHP was the answer to Ruby's scalability?

              I think he (and you, by way of sarcasm) said that PHP is the answer to a different question entirely: "What do you do when there are already tons of good CMSes available for PHP?"

              Nothing to do with scalability.

              FWIW, if I were starting from scratch I'd probably use Radiant, the Ruby CMS. Why bother screwing around with Drupal modules and themes?
              • Who said PHP was the answer to Ruby's scalability?
                Every RUBY site out there who needs it. rubyonrails.com, basecamp.com, 43things.com, etc. They all need and use it and you can't tell me that they all just need a CMS... on the frontpage. Why use RUBY at all?
  • by LinkFree ( 1112259 ) on Monday June 18, 2007 @04:40PM (#19556497)
    "Several of the examples rely on MySQL, which I found a chore to install." For anyone out there who'd like to have MySQL, PHP, and javascript support in Apache should check out Apache Friends (http://www.apachefriends.org/en/index.html [apachefriends.org]) Their xampp project, available for Windows, Linux, sparc, etc. Is easy to install, and once you've done it, it's all ready to use. Full MySQL and PHP support. I also installed their Perl addon, and so far it's all worked flawlessly.
    • I'm sorry, but I just can't let this one go.

      For anyone out there who'd like to have... javascript support in Apache
      Is there really that much demand for Javascript support in Apache?
  • While I'm as annoyed about the Rails crowd running around yelling "RAILS! RAILS! RAILS!" just as much as the next guy and allways have a snappy remark ready for anybody who thinks Rails invented intelligent web programming ... I have to say that you have to give the Rails team credit for introducing professional marketing strategies to OSS projects. Their site was the first OSS site that didn't look like shit from the get-go. They practically invented screencasts as a means of advertising their tool and act
    • Rails is great, but only if your project doesn't butt up against Rails's limitations.

      Rails decided not to be all things to all people, the way J2EE is. Rails is for new applications with one web front end communicating with one and only one database back end (I know, I know, SOAP, but that is often a bad answer for internal applications) and the database schema is brand new (and doesn't use any stored procedures).

      If that is your architecture, Rails should be one of the frameworks up for consideration. If
  • Can they install into $HOME again? The last time I checked (and it was on 0.9.4), they broke the possibility to install somewhere else than to the default /usr/lib hierarchy.

    With some dark magic, you could do it with 0.9.0, but not with 0.9.4. How can a piece of popular on-the-edge software lack so much of common sense functionality?
  • Runt is a great library, I'm surprised it doesn't get more support. I wrote a short how-to for getting Runt up and running with Ruby on Rails: http://suttree.com/2006/08/14/runt-on-ruby-on-rail s/ [suttree.com]
  • I'm surprised that the Hoe gem wasn't mentioned in the review. It's a tool that makes creating, testing, packaging, and publishing RubyGems dead simple.

    http://nubyonrails.com/articles/tutorial-publishin g-rubygems-with-hoe [nubyonrails.com]

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...