Google engineer Cedric Beust argues that Ruby on Rails is not destined for mainstream acceptance. Here are his basic arguments, which he explains further in his own post:

1. Ruby is too hard for most people.
2. Rails is too clever.
3. No credible IDE.
4. Fanaticism of the user base is off-putting.
5. Ecosystem for Ruby Web development frameworks is monopolized by Rails.
6. Rails is not proven to be scalable.
7. Not enough ISPs support it.

I’d say that items 3, 6, and 7 will be fixed in time, assuming that Rails continues to grow as it has. Java was growing in popularity for years before really top notch tools like Eclipse and IDEA were released, and I think that the Ruby tools space is maturing more quickly than that. It will be very interesting to look at the feature set of TextMate in 18 months to two years, for example. If Ruby on Rails continues to grow in popularity, someone will solve the scalability and deployment issues, and ISPs will pick it up. The question is whether other things will keep Ruby on Rails in a niche.

I don’t think Ruby is too hard. Even if it is, the fact is that you can write a solid Ruby on Rails application without taking advantage of any of Ruby’s cleverness. I wrote my first Rails application (a small, simple one) without knowing Ruby at all. Granted I know Java and Perl, so Ruby was very approachable to me, but I didn’t take advantage of any of the most interesting aspects of Ruby. Lots of regular folks have learned enough Perl to get their work done, and Ruby is easier to learn than Perl, in my opinion.

Here’s a real Ruby on Rails story. When I started working on my Ruby on Rails project, I had the services of another developer at my disposal. I could have chosen Java, or PHP, or anything else. The other develoepr knew Java, but wasn’t familiar with any of the MVC frameworks or ORM tools like Struts, Spring, or Hibernate. I realized it would be easier to drop Java and go forward with Ruby on Rails than to get him to stop writing Java apps his way and learn the various frameworks necessary to write Java applications the way I have for the past few years. Yes, there is a lot of cleverness in Rails, but there’s a lot of cleverness in most good frameworks. I’d estimate that 75% of the people who use Hibernate as a persistence layer for their Java applications have no real understanding of how it works, they just know how to map objects to tables and use the Hibernate facilities for managing persistent objects. Rails may be hard to understand, but it’s easy to get started with.

I’m not certain Ruby on Rails will ever find itself on the same plane with J2EE, PHP, ASP.NET, and the other big Web application platforms. There are a lot of intangibles out there that could stymie its progress. But I look at it and see something that really could be a great success. The growth curve is excellent and the Ruby and Ruby on Rails books from the Pragmatic Programmers are top notch. Soon there will be whole shelves of Ruby on Rails books, as well. (An editor pinged me about writing one and I’m a total Ruby on Rails neophyte.) The tools and deployment pictures are both looking better all the time, and the fanatical user base is doing a good job of evangelizing the product.

The jury is still out on Ruby on Rails, obviously, but I’d bet on it being a big success when all is said and done. In the meantime, it’s been a great for my projects, and you can’t ask for more than that.

Update: I misspelled Cedric Beust’s surname, as a commenter points out. My apologies.

The other day someone was explaining to me that the reason Apple laptops don’t have particularly interesting form factors is that Apple’s volume is low enough that a broader spectrum of laptop models would mean that each individual model wouldn’t sell enough to cover the development costs. A small fraction of the PC laptop market is still a pretty big market. A small fraction of the OS X market isn’t so significant.

Perhaps Boot Camp gives Apple the opportunity to branch out into a wider variety of models. I was thinking this morning about Dynamism.com, a company that imports Japanese laptops in form factors that aren’t common in the US market. It’s basically a site for laptop enthusiasts. If people will pay a price premium to buy laptops from overseas that don’t even have US keyboards, surely they’d buy an Apple laptop just to run Windows if the form factor were interesting enough. The additional opportunity to sell to Windows users may create a large enough market for Apple to move into things like subnotebooks, where they wouldn’t have been able to move enough volume to justify developing those kinds of products for the OS X market.

Certainly interoperability with Windows was the main driver for the explosive growth of the iPod. Perhaps the ability to run Windows will do something similar for Apple’s other hardware.

You know, Apple’s announcement of Boot Camp, a tool to make it easy to install Windows XP on Intel-based Macs, was a stroke of strategic genius. Not everyone is happy with it, but that doesn’t matter. None of the unhappy people are going to refuse to buy Macs because they don’t like it. They’re Mac users who will stick with just OS X or Windows users who aren’t going to switch. And there is a significant set of people who will like and who will buy Macs who otherwise wouldn’t. Here’s a short list:

• People who love Apple hardware but want to run Windows. They can just use an iMac or a MacBook Pro as a Windows box.
• People who want to use OS X for work but Windows for games. Dual booting doesn’t make much sense to get work done, but rebooting so you can play PC games is something many people will do.
• People who wanted to switch to the Mac but can’t completely wean themselves from Windows software. Yes, some people need to run Windows apps all the time and will have to wait for virtualization, but for others this is an OK solution. If I use a Mac but have to debug a Visual Basic application once every few weeks, dual booting could be a perfectly acceptable solution.

Those are three examples that immediately come to mind. This project must have been very little work for Apple and will move a significant amount of hardware. Plus it puts them on the front page yet again. Well played.

I mentioned last Monday that I was taking about a week off from my aggregator. By the weekend I had about 1400 unread items, and I finally caught up last night. There were a few feeds that I marked as read, but most feeds I at least skimmed.

What I discovered is that just leaving my aggregator closed for the week is a bad idea. There are several kinds of feeds that I follow. Some of them, I need to keep track of for work. For example, we use wikis for collaboration at work, and following the feeds to see what pages are getting updated is important. It was a bad idea to skip those feeds for the week. There’s also the comment feed for this site. If I don’t follow that feed a lot of comment spam stays around longer than necessary.

Then there’s another category of stuff that it’s helpful to keep up with for professional reasons. Someone had to tell me Rails 1.1 had been released because i wasn’t following the news. Granted I only missed the announcement by like two hours, but still.

Finally, there are feeds that I read strictly for pleasure, or rather because I’m interested in the topics discussed even if they’re not necessarily relevant to my day to day life. You can put all of the political weblogs in that category.

Fortunately, NetNewsWire supports setting specific update schedules on a per-feed or per-folder basis. I’m going to juggle things around so that I have some feeds that are updated hourly, some that are updated once or twice a day, and others that are updated only when I do a manual refresh. Right now I sort of have things organized topically, but I think that organizing by refresh schedule will do a much better job of letting me take control of how much time I spend following feeds. We’ll see how it works out.

Update: the downside of reorganizing your feeds in NetNewsWire is that the interface for moving feeds from one folder to another is truly horrible. It’s basic drag and drop but the way the interface behaves makes it painful when you have a lot of feeds. In general, I find that dragging and dropping items around within a list to be awful when the list is longer than the window.

The developers of Ruby on Rails have come up with yet another small but important innovation in the world of Web applications. Way back in release 0.14, they added the ability to freeze rails, which copies all of the system-wide Ruby libraries you might depend on into a directory in the application so that if the packages on the system get upgraded, your applications won’t break. This makes for fatter applications, but vastly reduces the risk that anyone will break your stuff.

In the Java world, developers have been including JAR files in their web application archives for ages. When I write a Java application, every library other than the ones in the Java class library I use is packaged with the application. Now I can easily do the same thing with Rails applications. Someone needs to add write some scripts to bring this functionality to Perl and PHP. applications. I’d love it if it were this easy to bring along your CPAN or PEAR libraries with your application code.