I finally have a iTunes Music Store account and I just bought my first album (the soundtrack for Motorcycle Diaries)! All you need is a buddy in the US (hey, Jason!) and the willingness to lie about your address. Check and check.
Then your buddy to go to the iTMS page on Apple.com and pick Send Gift Certificates (lower right corner). It works kinda like PayPal we you'll then get a certificate email with the code for redeeming the amount. Click, click and you're in!
So it's official. Instiki and Rails are now iTMS-ware. Like the software? Send me a gift certificate to iTMS on email@example.com. (I'm just kidding. Rails and Instiki is free software—unless you're gonna do it? :)).
Ruby on Rails is stirring up the waters in the Java world. Matt Raible, the man behind AppFuse (kickstarting J2EE development), has been "thinking about Rails ever since I wrote a post about it".
The thoughts must have lead to some frustration with his current environment, though. Here's his description of why doing a CRUD on a single database table would flunk any productivity test:
...if I did it right now in AppFuse's current state, it'd be a disaster... To CRUD a database table using AppFuse you have to create 11 new files and modify 5 existing files. 16 files. What a beotch, huh? If I made a video of this - it'd be 20 minutes long!
While this might make AppFuse look silly, it's really more of a symptom of the patterns we have in J2EE and how we're supposed to architect our apps. 3 tiers, test-driven, loosely-coupled and internationalized.
Compare this to the Rails approach:
class Post < ActiveRecord::Base
# All attributes are given accessors
# through column introspection
class WeblogController < ActionController::Base
# The controller now has actions for all
# CRUD operations and uses introspection
# to select the input fields and columns
I'd be depressed too if my environment forced me to go through a 20 minute setup phase (and that's for an expert, I'm sure creating and updating 16 files could easily take longer for people less skilled than Matt).
Naturally, this has spawned interest in remedying the situation for Java. Enter Trails by Chris Nelson:
The Trails framework is a domain driven development framework inspired by others that have gone before it such as Rails and Naked Objects. Its goal is to make developing database-driven web applications in Java radically easier, faster, and more fun. The basic approach is to eliminate as many of the steps as we can.
While I laud the aspirations for easing the pain that is J2EE, I'd advice treating the disease rather than the symptoms. Which is of course while I keep stressing the use of Ruby on Rails instead of just Rails. Rails cannot happen in a language like Java. Approximations will try, though.
So I would recommend trying the real thing before settling with an approximation. This realization came to both Python on Rails, Rails.NET, and Active Record in Tcl.
But if you're stuck with J2EE as a fear-driven technology choice made by higher powers, I most certainly recommend checking out Trails. Chris is picking the best infrastructure J2EE has to offer and will attempt to make it fit like Rails. That's a great starting point and a good vision. Best of luck!
Hi Matt. Thanks for the kind words. I'm honored. I'd just like to correct one misconception about Rails.
When you write "something like Rails would never fly in Java because it appears to be tightly coupled to the database" that's not really true. Active Record (the ORM part of Rails) has a database abstraction layer embedded called Abstract Adapter, which all the specific adapters are implementing transparently.
Hence, your Rails application is not tightly coupled to a specific database, but rather to the Abstract Adapter interface. Since concrete adapters are just ~100 lines of code, it's pretty easy to implement your own adapter if the current offering isn't sufficient.
The PostgreSQL and SQLite adapters were implemented one the same day by one person (Luke Holden). There's a Microsoft SQL Server adapter just around the corner (by Joey Gibson) and I've heard of people working on Oracle and DB2 adapters too.
So the only tightly coupling going on is if you write database-specific SQL. On that account, I'm actually very sympathetic to Jeremy Zawodny's Database Abstraction Layers Must Die!. Chasing database abstraction without a specific business case asking for it is just something You're Not Gonna Need and it's certainly not doing The Simplest Thing Possible.
The disappointment in undeniable. Despite the rumors, despite the articles from mainstream press, despite the competition from Microsoft. Despite it all, Apple have chosen to route around Denmark and not launch the iTunes Music Store here. At least not for the foreseeable future.
Country manager for Apple Denmark, Kenneth Nielsen, says:
The countries we have chosen all have one thing in common: They're Euro countries. There won't be coming any more shops for the time being — besides Canada later in the year.
I don't know who to blame more: The people who voted against the Euro in Denmark or Apple for screwing us out of a special solution, like Great Britain got.
This is a dark, dark day for Danish Apple fans. To tease, to veil in mystery, and then not to deliver is cruel and unusual punishment to loyal subjects.
Lars Pind has just announced that Collaboraid has signed a big deal with a large NGO to develop their intranet using Ruby on Rails.
What's especially exciting about this deal is how fast Collaboraid have been able to adopt Ruby on Rails and secured a commercial contract using it. This shoots a big hole in the whole notion that off-mainstream languages are great barriers to entry for development firms. Here's what Lars' has to say about that:
Learning Ruby was quite easy - we were able to get started just by looking at the existing code, and the Ruby book by the Pragmatic Programmers is excellent. Rails has been similarly easy to learn, what with plenty of support from the Rails community on #rubyonrails, good introduction materials on the site, and a visit by David.
It's wonderful to see development firms like Collaboraid trumph fear-driven technology choices and work with forward-thinking organizations to get working software into the hands of users faster.
Marten was the guy behind the short burst of Rails.NET activity. Since then, I've convinced him to convert to Ruby on Rails, get a Mac, and now he has even bought TextMate in anticipation of receiving said Mac (before Christmas).
So it seems that my Jedi mind tricks are quite operational. Muhaha. No, seriously. Welcome to a better world, Marten. You're going to love it here (as if you didn't already).
Neil Weber seems to think that the world of tomorrow will be one where we shop for finished components, sprinkle them with business-specific attributes, and off we go with a done system in no time at all. This future has had industry-wide fascination since the beginning of time. I believe it is a false hope.
At RubyConf '04, Brad Cox (co-designer of Objective-C) blamed the apparent stand-still of the software industry on the lack of a viable commercial platform for components. If only it was easy to resell your Bill of Materials class, we could design it once and for all and merely "reuse".
In all humbleness, I think this is yet another software mirage. Software is not like hardware, high-level components can't be reduced to interchangeable IC's. Software is a collection of design decisions and where that cut should be made, which decisions we should bother with and which we shouldn't, is ever fluctuating.
The components dream is in many ways similar to the aspirations of model-driven architecture. Programming is a soon to be lost art of craftmanship, move over for industrialization!
Only it never really works out that way, does it? 4GL's and CASE tools have had their rise and fall. The point is that when you already know what you're going to build, such as a Bills of Materials system, then it's likely that you can just buy a finished system and alter it slightly. It's obvious that once you drastically reduce the problem space, pre-made applications are more likely to be a Good Enough fit.
But to think that we can reduce the problem space for information systems in general, to make it fit our existing components, is where I spot the disconnect. When I think back on the systems I've done, I can't come up with many good candidates for classes I could have carried all the way through and merely configured.
At least not on the business level. Rails is a great example of how infrastructure, that which is below our domain models, can and should be standardized. But design decisions can not follow this road.
Of course, I'm merely replaying my version of what many of the great thinkers in software had done long ago. The solution is not to embody repeating business problems in components, but to look for patterns. Gather, synthesize, and describe the forces, challenges, and good solutions that other people have come up with.
This sums up my vision for Rails as well. The border at which new functionality is accepted or rejected lies at the brink of the business domain. I don't believe that user management, access control, discussion boards, or Bill of Materials classes make for good component candidates.
I fully recognize that this might very well just be a limitation of my intellect and that wiser men truly has found the holy grail of software. But just label me skeptical on this one.
David A. Black has just finished converting not one but two of the stable Ruby community sites to Rails. The Ruby FAQ is a searchable archive of questions and answers on all things Ruby. It was originally written in Iowa by Dave Thomas long, long ago, but due to lack of maintenance it was in bad shape and ripe for a rewrite. Enter Rails.
The RCRchive is a database for Ruby Change Requests. That is if you'd like something to change in the Ruby language, you write an RCR and the community comments. If enough people like it, Matz will have a look and a final word on whether it will go in or not. This system is now also powered by Rails.
If that wasn't enough for Mr. Black, he has also started developing the Aside application that he presented thoughts (PDF) on at RubyConf '03 in Rails. I believe it's scheduled for a demo at Seton Hall University — where David is an Associate Professor of Communication — later this month.
To top it of, RubyGarden has a new article online called Reflections on Rails where David gives his opinion on developing with Rails. Here's a taste:
It’s actually very similar, in its domain, to the feeling many get from Ruby itself. For me, it also represents a kind of enforced de-spaghettification that can only be for the good. Yes, one can write spaghetti code in a Rails controller. But the organization of one’s project itself will militate against it.
Oh yearh, David hadn't touched Rails — or any web-framework for that matter — before RubyConf '04 (which he organized with Chad Fowler and others). So all of this Rails activity has happened within the last three weeks or so. Now I'm the one impressed.
I think more customers are choosing technology out of fear than good is and many developers are doing a shoddy job standing up to those fears. Customers fear that a world of risk and hurt will come unless they choose "a standard", like Java, C#, or PHP, and by silently bowing in agreement, developers are selling the customer short.
In the advent of highly agile and open source frameworks such as Ruby on Rails (and there are many others), it has never been easier or safer to "experiment" with new technology. Unlike the days of old, it no longer requires an engagement with a vendor and a blind bet on his treasury box of magic tricks. Vendor has turned community and the treasure box has turned transparent.
From the feedback I'm getting, most developers have a pretty good grip on how Rails is going to help them within a few hours. After about a day they're usually pretty convinced. And after a week, all I have talked to are turning out working software at high velocity.
With the barrier for examination so incredible low, there's simple no excuse to instinctively reach for the bow as the first response to fear. As much as it delights me to read Matt Raible write about his enthusiasm with Rails:
After watching the video this morning, it's enough to make me want to become a Ruby developer and use Rails to develop my next webapp.
I'm am equally disappointed by his defeat by default when he his mind wanders on to the possibility of actually using this stuff:
Then again, Ruby probably doesn't pay the bills nearly as well.
So maybe that's just Matt, right? Wrong. This depressing pessimism is pervasive. David Crow chimes in with enthusiasm:
Matt Raible points me to the Ruby on Rails quick setup video. Damn, that is impressive! After spending all weekend fighting with data objects and PHP, I need to spend more time with Ruby and Ruby on Rails.
And then follows the "self-evident truth" of Matt with an immediate dismissal for commercial viability:
Matt's got it right it might not pay the bills, but it looks like I can learn something.
As much as I commend both guys for their interest, kind words, and real enthusiasm, I'm frustrated beyond belief by their lack of energy to fight inertia. How can there ever be a better tomorrow if you're not even willing to contemplate fighting for your enthusiasms of today?
If I do anything of significance with Rails, I hope more than else that it's broadening the horizon of customers by inspiring developers to acquire the will to push for their beliefs and enthusiasms.
Customers are sold short when we as developers accept fear-driven technology choices.
As earlier mentioned, the fine chaps at Combustion Labs invited me to come to Vancouver for a week to introduce their team of PHP programmers to Ruby on Rails.
Now considering that all three companies I've done Ruby on Rails consulting for has either already switched or anticipates to switch to the platform, I feel that the pressure is on to keep the winning streak going.
And I wonder when the bag of tricks is going to run out, so it won't be possible to dazzle guys like Lars Pind of Collaboraid who noted this after I visited:
Watching David demonstrated to me directly, visually, personally, a very productive way of working that broke with a number of traditions we've held for years...
So to ease my mind, I'm planning to think of stuff I'd like to do on whatever little spare time I might have. Do you have any good suggestions?
I'm flying in on Sunday and going out on Saturday. (Going out as in flying to San Francisco for Building of Basecamp III — do consider signing up if you're in the area, there's still a few seats left).
Dave Thomas has been touring his Ruby talk ever since his first stop at Amazon. For his on-the-spot programming, he has been using TextMate about which he notes: "...this editor just works for these presentations". Mighty flattering. But Dave has even more up his sleeve.
For the Ruby tutorials, he has been using Rails to implement his Amazon application example. I'm not sure how many times he has run the presentation, but something about the feedback he's getting must be pretty convincing:
It’s generating some buzz—I think Rails may well be the framework to break Ruby into the mainstream.
I couldn't ask for higher praise or a greater vision for Rails.
It's been fifty days since our last confession, so it's no wonder that this outpouring is by far the biggest yet in Rails history. It's absolutely packed with goodies ranging from a whole new framework for sending email to the smallest new alias for an existing method. In total we're just shy of 100 additions, changes, tweaks, and fixes.
This is also the release with the highest number of contributors. I've counted at least 23 different people with patches in Rails 0.8 — and there are many, many more responsible for suggestions and bug reports. This is truely turning into a community movement and I'm extremely pleased to be the steward for it.
Read more about the changes:
Get it all from the Rails website, talk it up on #rubyonrails (FreeNet). Or even easier, just do "gem install rails" (or "gem update" if you're already running on Gem Rails) — you'll automatically install all the newest versions of the required dependencies.
Despite my obvious OS X/*nix bias, Rails works great on Windows. It's really easy to install as well thanks in large parts to the One-click Ruby Installer by Andy Hunt and Curt Hibbs. And to prove just how easy it is, Tobias Luetke has created three movies showing you every step of the way:
- Lesson 1: Setting up Ruby, RubyGems, and getting Rails loaded
- Lesson 2: XAMPP installation and database integration.
- Lesson 3: Making the jump from WEBrick to Apache.
Inspired to follow Tobi and interested in demonstrating some other part of Rails in a movie? Please do have a look at Rails Academy.
Sean is yet another Java programmer burning the midnight oil with Ruby on Rails. Among many kind words, he offers a simple example on how to beat the dreaded 1+1 problem that a naive ORM will kill performance on any iterations with.
However, that doesn't solve the 1+1/iteration problem because this will face the same issue. But the solution is much simpler and elegant. I modify the Account class to:
class Account < ActiveRecord::Base
'select a.*, o.first_name, o.last_name ' +
'from account a and owner o ' +
'where a.owner_id = o.owner_id'
Welcome on board, Sean. I hope the productivity gains you've experience will allow that midnight oil to be replaced with a day-time engagement.
P.S.: There's an expanded discussion of this piggy-back technique on the Active Record wiki.
I've always wanted to do this. So now I'm doing it. Quoting myself:
The first official update to TextMate has emerged from the trials of nine betas before it. Before talking about what’s in it, we’d like to thank all the early adopters that have made it possible for us to iterate at this insane speed. Your time and money are incredibly appreciated and your trust and belief in the product has made all the difference in the world. We’re honored to serve you with this update.
Yes, TextMate 1.0.1 is out. Read all about or skip right to the download.
Matthew Langham has a hilarious post on podcasting. Or, so I hope it's intended. It's really short, so I'll reprint:
Podcasting...who needs it? I'm sorry but I just don't get it. I mean isn't it just an easier way of downloading audio files to your MP3 player? So? Where's the beef? Just because everyone can now become a broadcaster - doesn't mean everyone will want to listen to you - does it. Bah humbug.
If it's not a good joke, I pity Langham for his inability to appreciate the obvious contradiction in denouncing podcasting from a weblog. Replace podcasting with weblogging and "easier way to download MP3" with "easier way to post to the web". Weblogs were never about having the largest audience, Podcasting won't be either, and I doubt the video theme following that will be.
RubyGems is one of the best things that have emerged while I've been Rubying. It's the equivalent of CPAN + apt-get as a repository for Ruby libraries and applications. It has been gaining speed fast and currently holds 111 distinct gems, which is about 10% of the number that age-old Ruby Application Archive has in store — impressive and fast take up!
Even more impressively, though, is the uptake among users. Chad has just announced that more than 5,000 copies of RubyGems have been downloaded and more than 20,000 gems have been retrieved! I'm incredibly proud to see that Rails is responsible for at least 1/4 of all gems downloaded.
I can't wait until RubyGems is part of the standard library. Now that the release of Ruby 1.8.2 seems to be taking longer than first anticipated, it would be fantastic if RubyGems made it in before release. Are you listening, Matz :)?
While we await inclusion in the standard library, let's make the world of gems even more exciting. I for one would bless anyone that would make these libraries available as gems: FastCGI, MySQL/Ruby, Posgres/Ruby. Those three are currently the only non-gem libraries I have installed.
Jason does a great job describing some of the models we're currently contemplating in response to the growing interest in a hosted version of Basecamp. It gives a good deal of insight into how serious we take the whole No Human Scaling aspect of Basecamp.
We don't want to grow a company of 25 people around Basecamp even if that looks like a very possible road forward. Instead, we're sticking to our design of constraints and are thinking about how to leverage those best.
I particularly like the ideas of auctioning off just a handful of installable versions. We have quite a few large and very interesting companies on the notification list for an installable version. Just how much could a program like Basecamp be worth to have inside the firewall?
At the other end, I'm attracted to solution for dealing with upgrade cycles: Don't do them. Sell a v1.0 with all the bugs and inefficiencies that it might very well have. And then give people another chance at v2.0 — but no in-betweens. I wonder if it would work, though. Even with everyone as consenting adults. Would having the source available and being able to do internal improvements help assure people of the viability?
Business models for open source
While we're contemplating what to do in the commercial world of Basecamp, I'm at the same time seeing a number of opportunities arise for Rails. Just recently, I signed on to help Combustion Labs in Vancouver explore Ruby on Rails for a week.
That's the traditional open-source service model. Give away source and software, sell services. But there are many new models popping up. One of them is doing hosting, which of course is exactly what I announced earlier today.
Partner with a hosting company and make sure that they Just Work with your software. A lot of the pain in open sourcing is getting the stuff up and running. If you can pay something reasonable to have that all taken care and support the project, then what's to think about?
On top of that, there's of course taken either commercial sponsorships for feature improvements (I was talking to a guy at RubyConf about adding integrated Web Services support to Rails on that model) or raise funds directly from the community. A few of the guys from #rubyonrails talked about how they'd like to raise funds to allow me a month off to improve the documentation.
It's a brave new world for funding of great software and ideas outside of the traditional channels.
TextDrive is an incredible cool hosting firm founded to support open source developers and projects by letting the users buy top-notch hosting straight from the source. They’re already home to Dean Allen of TextPattern, Rickard Andersson of PunBB Noel Jackson of Photostack and Matt Mullenweg of WordPress
On top of being in excellent company, Ruby on Rails is exceptionally well-supported on TextDrive. You’ll always have the latest version available as GEMs, you can keep your code under Subversion (and show it off with Trac), and have your choice of PostgreSQL or MySQL for the database.
Equally important: By being hosted on TextDrive, you’re supporting Ruby on Rails development with 50% of the profits from your plan. It won’t take many people before that turns into a very meaningful contribution that will allow Rails to go above and beyond. Be among the early adopters and you’ll be able to tell your grand children that you helped Rails reach world domination :)
Read more: TextDrive Hosting with Ruby on Rails
P.S.: These guys already hosts MacroMates.com, RubyonRails.org, and will soon do Instiki as well. They know their stuff.
Jason Fried attended Web 2.0 this week and while the enthusiasm for the next major version of the web was great, some things sounded an awfully lot like we were just rebooting the cycle:
But, I’ve gotta say, it felt a lot like 1999 again. Tons of VCs floating around. Tons of talk about Round A and Round B funding. The word “millions” was overhead in more conversations than was comfortable. Too many smiles and not enough skepticism.
Amen. What's so freaking special about Web 2.0 is that you don't need to let the organizational scaling get ahead of the business. All this newfound computing power, cheap bandwidth, and powerful technology are enablers for postponing the growth of heads:
So, my advice to these new companies with their new products and fresh-faced enthusiasm… Keep it small. Start small and stay small. Borrow from yourself before you borrow from someone else. You can have an impact with just a few people. You can build great products with a small team. You can do it on your own. You can.
Let's party like it's 2004.
We've been pretty tight-lipped about the numbers on Basecamp, but we're now going to push two of them because we just couldn't stay quiet any more. So here's the official addition to the Basecamp website:
Used by tens of thousands of people in over 40 countries!
From individuals managing their home improvement projects, to professors managing their classrooms, to small and big businesses managing their client and internal projects, everyone is using Basecamp to keep their projects and ideas organized.
We're extremely proud to have gotten this far with a team of what amounts to about two and a half full timers. What's even more amazing is that we've been able to scale without adding a single person. That was one of the goals from day one: Build a product that doesn't require organizational scaling.
If you want to know how we did it, you really should consider attending the third Building of Basecamp. It's on November 9th in San Francisco. We're teaming up with Adaptive Path who are going to talk about Building Blogger the day before.
For the last workshop, people gave us a 4.76 out of 5 rating on whether they thought it was money and time well spent.
Some of the praise from attendees went:
Presenting in front of a tough crowd of mostly C/C++ and Java guys, I'm told by my robot spies that Dave Thomas did very well at Amazon. So congratulations on that!
When you're used to dealing with 32 million customers, I guess you do develop somewhat of a thick skin towards claims from new technology, so that skepticism certainly did put Ruby on the spot a few times. But once Dave drew in the examples with the Amazon domain, the crowd was somewhat more easily swayed.
Erik Benson snapped this shot using his camera phone of Dave going on about Active Record:
If there's anyone in the Amazon camp that were enticed by that last section on Rails, don't hesitate to drop me a line.
UPDATE: Erik Benson has posted a first-person report on the presentation.
We've just launched a major update to Basecamp that introduces responsibility assignment for todo items and new responsibility screens for both todos and milestones. This was an interesting feature introduction.
At first glance, I thought it conflicted with one of our dear mantras that Project Management is Communication. I saw this initiative pulling us towards the Control and away from Communication. As in managers would use the new overview screens to assign blame (you still haven't done X, Y, and Z) and spread general mischief.
But as we talked more about the feature, I realized how that fear of misuse was dwarfed by the communication potential. First of all, we made it so that every employee could see what any other employee had on their plate — not just the administrators (who are often managers).
Using it as such, it's a great tool to enable employee-to-employee collaboration. You have an idea of whether now is a good time to disturb or talk about that feature you've been working on (because Pam is working on something similar). Or if Paul has a light load, you can arrange for a swap on some items.
At the same time, it's a really useful tool to communicate upwards that "there's just not enough hours in the day". If your todo list is already full, it's pretty hard as a manager to be oblivious to that fact and assign an even heavier load with your head in the sand. Same goes for the milestones: "If we need to get this done by Friday, maybe I shouldn't also be in charge of sending out 100 envelopes".
So despite the potentials for misuse, I'm generally pretty happy about how this turned out. Especially the new todo list where you can see everything that you need to do across all projects.
The Amazonians in Seattle are in for a special treat this Friday. Dave Thomas will be presenting a two-hour show covering Ruby with examples of how the Amazon domain could be modeled herein. Dave Thomas needs no introduction, but just for good manners, he's the one of the Pragmatic Programmers and author of the just-released Programming in Ruby, 2nd edition.
What particularly excites me about this talk is that Dave will be including a tutorial on Active Record and a full-blown example of a small web-application developed in Rails.
I just had a look at the slides and I must say I'm really impressed how quickly Dave has internalized the Rails approach. The Amazonians are surely in the hands of a master.
And as if that wasn't enough, Dave is most likely going to be presenting using TextMate as his editor. I can't begin to tell you how cool it feels to have one of your all-time technical role models present using not one but two projects I've had a hand in.
Best of luck on Friday, Dave.
It feels incredibly good to release TextMate after all the anticipation that has built up around it. I've been so lucky as to have this be my third experience of the kind. First Basecamp, then Rails, and now TextMate.
Undoubtedly, all this hype will lead to a few disappointed faces. No, TextMate won't make you breakfast in bed. Or complete your over-due project for you. But it will hopefully enhance your productivity, and most importantly, your enjoyment in working with a graphical editor on OS X.
So I won't keep you here with a long story. We got one of those on the TextMate blog. Now go on, download TextMate.
Instiki has just exceeded 5,000 downloads! And what better way to celebrate that than highlight how Mena of Six Apart fame organizes her own notes:
I have recently found that I enjoy using Instiki to keep notes. I don't like using wikis for collaboration. We keep one internally and I'm at a lost when it comes to finding data quickly. I'm a chronological, categorical sort of person. However, I've been able to use Instiki for collaboration with the person I know best -- myself.
What an honor. I'm thrilled to see how Instiki just keeps on growing even as I'm shamelessly neglecting it for other pastimes. I'll get back to it, though. Instiki has at least 10x the user base in it.
The generosity of the Pragmatic Programmers shined once again at RubyConf as the first 50 attendees was bestowed a copy of the new Programming Ruby book (PickAxe II among friends). Considering the enormous impact of the first edition, people were school-girl giddy about getting their hands on this much anticipated tome.
I didn't have much time to look at it during the actual conference, but on the flight home I gave it a good thorough look. And "holy wow", to borrow an expression. I had high expectations, but Dave Thomas and company has really blown those away.
First of all, the book is huge: 800 pages in total. It contains a great introduction to the language itself, to good techniques such as unit testing and duck typing, over tutorials to RDoc and RubyGems. On top of that is a complete reference to all the 900 methods included in the 48 built-in classes. And of top of that is a fantastic overview of the about 100 classes in the standard library.
Mind you, both the reference and the standard library is original work done mostly by Dave Thomas. This is not just a lame reprint of an already existing standard library documentation done by others (which seems to be really in-vogue for PHP books to republish php.net).
And all the material from the first edition has been tweaked, rewritten, and expanded to account for time and the new major version. As an example of it's greatness, I gained at least ten new important insights about that language and libraries in the few hours I spent flipping through. And I live and breathe Ruby for hours and hours each day.
In short: You need this book! Whether you're a Ruby veteran, neophyte, or just puzzled observer of all this Ruby raving. This is it. This is the book you want. I'd also really recommend that you get the Book + PDF combination. You the dead-tree version to lean back to read the longer chapters and use the PDF while programming Ruby at the screen.
So let me just finish off with:
(...or I'll be terribly disappointed with you)
The Robot Co-op has hired Borges-developer Eric Hodel to work with Ruby on Rails for their upcoming product. Congratulations to both Eric and all the guys at the co-op. It's wonderful to see more companies get on the Ruby train and especially when they're hiring within the community as well.
Best of luck to all of you. I'm sure I'll be talking more to you shortly, Eric.
We're on the last day of RubyConf, but what a wonderful weekend it has been. It's been so great to finally meet everyone and put a voice, face, and handshake on so many of the names from the Ruby community.
The presentations has been great and I've especially enjoyed listening to Rich Killmer (Alph), Jim Weirich (Rake/RubyGems), and Nathaniel Tallbott (test/unit). And I'm still looking forward to Jamis Buck's presentation on Copland.
My own presentation also went fairly well. I started out a bit slow, but think I made a good comeback with the "Mantras" and "It's not just about the code" sections. Hopefully video and audio will be available shortly.
Of course, I've also had plenty of chances to talk about Rails. The reception to that here has been awesome. I've had a chance to sit down with Jim Freeze and just a little bit with David A. Black and help them get started.
Oh, yearh. And the reception to TextMate has been overwhelming as well. There's a ton of Apple users in the crowd and even the VIM'ers have been taking it in. I can't wait until we have the chance to release it publicly ever-so-shortly.