July 29, 9:44 | Comments (36)

Off to O'Reilly's Open Source Conference

Nothing like the prospect of a grueling 17 hour journey to get you pumped in the morning. Yes, I'm off to Portland for O'Reilly's Open Source Conference. We're looking at an awesome show and I personally can't wait to meet all the fellow rubyists and good people in general.

My tall order of engagements for the show includes a keynote, session, and a three hour tutorial. It's going to be a g-oh good time for Ruby on Rails!

July 20, 16:00 | Comments (14)

Only publishers care about the last 20%

In the second Ruby on Rails podcast, Scott Barron interviews Dave Thomas about a lot of good stuff including how the Beta Book project came to be. And Dave tells how he initial held the typical publisher position: "We can't release something before it's done. Typos and errors will leave a bad impression and people will hate us."

While that may be true for some established branches of technology (can't very well do a less-than-super-polished book on regular expressions today), it's a certainly not for emerging technologies — especially those coming out of the open source communities.

There's a reason we've blasted past 5,000 orders on the Agile Web Development with Rails book in no time at all. While I believe that Rails is (much) better documented than most open source projects, it still belongs to a culture that places code highest and which often leaves documentation to linger or be incomplete.

And even if the documentation is all there, it's spread out across the wiki, the API, the tutorials, the weblogs, the mailing list, and even IRC logs. To get a sane narrative, you have to dig a little. Collect your own mosaic. If you have the time, inclination, and motivation of course.

You can also just choose to pay someone else for all the work. And contrast those scenarios for a moment. Scourge the resources online and put together the puzzle yourself (undoubtedly hours of work). Versus paying an excellent author like Dave Thomas $20-45 to get a "on rails" reading experience where you just turn pages to learn.

How much do you think people care about an off comma or page break if the alternative is doing all the work themselves? Only the publishers and their caring for the craft of creating beautiful books. We, the readers, just want the information faster, so we can get up to speed with less pain.

And we don't necessarily want the bible every time. There are a lot of niche topics that makes for great focused documentation efforts too. That's the mini-book project that Dave is talking about that I've also been pushing on big time.

Of course, once we get started, who says that the current, predominant delivery forms of the documentation are even the way go? I've been pushing ideas in that space to publishers willing to listen as well.

I want to consume better documentation in a variety of forms and quality levels. Hopefully success stories like the AWDR book will encourage more publishers to experiment. It's never been cheaper to do so or more likely to succeed.

July 18, 14:17 | Comments (15)

Anyone using the dynamic alternatives to .NET?

In a post acknowledging that Microsoft is moving too slowly, Robert Scoble wonders whether anyone are actually using the new rise of dynamic alternatives instead of ASP.NET.

I'm glad you asked, Scoble. We're seeing a growing influx of former .NET users coming to Rails. Allow me to sample some of their reactions as to how the two environments compare.

From Christian Romney's analysis, two choice paragraphs:

I disagree that ASP.NET is more productive than RoR. I have been FAR more productive with RoR after just a few months of learning Ruby and a few weeks of using RoR than I am with .NET even though I’ve been coding on the MS platform for 10 years, with half of that time spent almost exclusively working on web applications.

The net result is that I *don't need* an ultra-powerful IDE like VS to develop RoR apps. I do just fine with VIM, thank you. I may not have IntelliSense or Refactoring, but the time saved on DALs alone more than makes up for it, and, honestly, I refactor a lot less in Rails because everything is already in place. If someone told me I had to build a commercial ASP.NET application with VIM I'd tell them to go fly a kite.

From Tim Case's comment on a screencast thread:

10 minutes later, I couldn’t believe what I had just saw, so I started doing the Rails academy tutorials… One hour later, my jaw was on the ground as I stared at my todo application running from MySQL so I started investigating rails further… Two hours later my .NET career was over. It literally happened that afternoon. I no longer had any interest in NHibernate or even seeing Visual Studio ever again.

From Rick Olson's reply on programming hygine:

Going back to ASP.Net development makes me feel dirty. What? I have to update the stored procedure, the model, the DAL, the form, and create a new server control just to add a property???"

See more in praise section on the Rails weblog.

Scoble also highlights that we have 592 links going to rubyonrails.org from Technorati. Don't forget the 518 links going to rubyonrails.com. That's a total of 1110 inbound links (wouldn't it be nice if Technorati made it easier to get one collective list?).

That being said. If you're stuck in .NET for political reasons and not allowed to use Ruby on Rails, you should give MonoRail a look. It's developed by a guy that tasted the sweets of Rails, but was forced to use .NET at work, so he brought a numbers of the ideas over.

July 17, 14:21 | Comments (15)

Patterns and practices, not language

In trying explain the intense pushback that some "enterprise" programmers have been giving Ruby on Rails, I'm entertaining one potential answer: There's confusion of where language ends and patterns and practices begin.

As Java gained traction and became the focus of business, it naturally attracted many of the best brains. While working in Java, they developed and profiliated an impressive array of patterns of practices.

We got the rise of MVC for the server side, an explosion in frameworks, test- and domain-driven development styles, and so much more. And while general ideas, most were explained from within the language that they had been practiced. So you have Java-first examples and implementations all over the place.

Who's to blame someone from thinking that it's all the same? That it's because of, and only in, Java that you would get access to these patterns and practices. And it's certainly havn't been hard to reinforce this belief by picking up one of the popular PHP applications, take it apart, and scoff at how little resemblance it beared to your modern living.

Who's to blame you for thinking that its intrinsic to the languages? Or even worse, that it's intrinsic to the division between dynamic and static languages. That Java equals good patterns and practices and that PHP (and by association, Python, Ruby, etc) equals bad. I think that's the crux of the matter. A misunderstanding well demonstrated in deployment debacle.

So if there's a misunderstanding, let's resolve it now. Ruby on Rails (and many other dynamic languages, frameworks, and applications) are largely built with a relevant subset of the same patterns and used following the same practices as Java!

Sure, there's reinterpretation. And the simplicity afforded in the new context can camouflage the resemblance, but the core ideas (and ideals) are the same.

Hence, I think the attachment many Java programmers have with the language and JVM could very likely be an attachment to the patterns and practices that these technologies are used with instead. And if that's so, it means that we're not so different after all.

If we can get that idea to take hold — that it's not about Java but about MVC, ORM, frameworks, test- and domain-driven development — I think the view on dynamic languages and frameworks in general, and Ruby on Rails in particular, would change dramatically.

July 16, 14:56 | Comments (13)

Growing an open source ecosystem

While open source is a great model at any scale, it gains an almost unstoppable power as it tips, picks up rapid momentum, and establishes a real ecosystem. For open source projects aiming for a lasting impact, the greatest fear should be obscurity. Sourceforge is littered with open source casulties that didn't manage to get the ball rolling.

Thus, mindshare is paramount. Publicity matters. Passion attracts the next great programmer that'll patch the project past the present and into the next smart evolution. Combine passion with relevance and contemporary significance and you truly have a winning mix.

And few things drive relevance and significance as commercial adoption. Passion for the sake of it can only retain most people for so long. To keep the cooking up it's incredibly helpful to be able to eat off the same plate. Commercial adoption does that. It serves as both a retainer and an accelerator. Get better, faster.

Realizing this, I've been trying to help along this chain of events from the early days of Ruby on Rails. It was apparent in my own work life that the projects I needed to get on with business got a lot more attention than the ones that didn't. Rails was forged in the fires of necessity, driven by the commercial interests of 37signals. It owes more than technical finesse to that reality. It owes the drive to get out of obscurity.

Naturally, it has not past me by unnoticed that mixing passion, evangelism, and a drive to fight obscurity is an explosive cocktail. I don't believe that you can ignite high emotion without generating backlash as a residue. But it's worth it.

Because once you realize that an healthy ecosystem has arrived, it's overwhelmingly satisfying. To grow something out of nothing...

• To see 170+ people sign up as "...earning a substantial or full paycheck from working professionally with Ruby on Rails" from 26 different countries.
• To receive close to 1,000 patches in 9 months.
• To have 6-7 books in development by publishers such as O'Reilly and one already out from the Pragmatic Programmers.
• To see 285 people in the #rubyonrails channel on FreeNode one night or 169 messages on a single day on the mailing list.
• To get 87,000+ downloads measured on RubyForge
• To be booked for two keynotes, three sessions, and two tutorials across conferences like OSCON, JAOO, RubyConf, and EuroOSCON over the coming three months.
• To use a bunch of cool, commercial applications such as 43things, ODEO, 43places, and our own 37signals suite of Basecamp, Backpack, and Ta-da List.
• To admire an equally cool set of open-source applications like Typo and Hieraki.
• To witness transformations of hostility to tranquility in high profile developers

In the grand scale of things, we're of course still but a tiny blip on the radar. But considering that its been less than a year since the unveiling of Rails, I think we're doing pretty good. And I don't even want to prophesy what the enumeration of wins will look like a year from now. But I definitely believe that we'll look back at today's excitement and impact and laugh at the humble beginnings.

It's exciting times today and ahead.

July 14, 23:31 | Comments (17)

Letting cooler minds prevail

I'm glad I held my breath for a few hours. Otherwise, I would probably have had to post another picture of a flower tomorrow. See, Patrick Peak wrote this article called Where are the Implications for "No Deploying"? in which the civilized world (Java programmers) are compared to the barbaric horde (Rails programmers).

But I'm already warming up the fumes just introducing and I promised in the title to let cooler minds prevail. First, my coworker Jamis Buck explains the deployment strategy we use at 37signals. The roughly the same approach that the 3,000 people who bought Agile Web Development with Rails already knows about — its recommended as a best practice in the Deployment chapter.

This dispels the insulting assumption that deployment in Rails is done like Patrick imagines the barbaric hordes would:

Developers deploy to a testing or production by manually zipping up the project and copying to the server. (Since there is no Ant to do it for you). Anything I'm missing here?

Heh. "Anything I'm missing here?". Right, cooler minds. Second up, Dave Thomas takes a swing at the Civilization vs Barbaric Hordes approach Patrick adopted for in "trying to understand":

I normally don’t like all these rounds of attack/defend blog posts that seem to crop up. But at the same time, I really don’t like the way that ignorance is used as a weapon. It belittles the discussion, reflects badly on the poster, and alienates communities that have a lot to learn from each other.

BTW, Patrick, did you know that the creator of Ant is working professionally with Rails? Along with lots of other high profile Java programmers. Why would you think that they would suddenly forget the importance of version control and sane deployment practices because they picked up a more agile environment?

Anyway, cooler heads.

UPDATE: More cooling comes from James Duncan Davidson (yes, "the Ant guy") as he explains the deployment strategy used by him and Mike Clark on their current Rails project.

July 13, 22:12 | Comments (15)

Rails is global: Beta book sells to 63 countries!

Open source software has an amazing power to span the world. Before the book has even hit in print, we've shipped the beta PDF to no fewer than 63 countries!

Argentina, Australia, Austria, Belgium, Bosnia and Herzegovina, Botswana, Brazil, Bulgaria, Canada, China, Colombia, Costa, Croatia, Czech Republic, Denmark, Estonia, Faroe Islands, Finland, France, Germany, Greece, Hong Kong, Hungary, Iceland, India, Indonesia, Ireland, Israel, Italy, Japan, Lithuania, Luxembourg, Malaysia, Malta, Mexico, Netherlands, New Zealand, Norway, Pakistan, Panama, Paraguay, Philippines, Poland, Portugal, Romania, Russia, Saudi Arabia, Scotland, Serbia, Singapore, Slovakia, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Thailand, The Netherlands, Ukraine, United Arab Emirates, United Kingdom, United States

That's on a total of almost three thousand beta books sold! And from book stores around the world, we have another two thousand plus books on order. That brings us above 5,000 copies of Agile Web Development with Ruby ordered!

Did I say that the book isn't available in stores before the beginning of August? No wonder it's the most popular book in pre-orders that the Pragmatic Programmers have published yet.

I'm humbled by the intense, overwhelming interest. Once more, thanks so much to everyone that has helped carry the numbers to these heights this fast. I can't wait to hold the print version in my hands come OSCON.

(Yes, I feel every single exclamation mark was essential. Really.)

July 12, 17:23 | Comments (19)

Rails gets its own podcasting show

Considering that Ruby on Rails is powering one of the premier destinations for podcasting with Odeo, it couldn't stand long that we didn't have our own show. Scott Barron is the slick voice at the mic and I'm the first interviewee to appear: Ruby on Rails Podcast.

Yes, the sound could be a whole lot better. And it will be for the next edition. Scott is just coming to terms with the whole thing, recording everything off the iBook built-in mic. We'll be sure to equip him with some proper gear for next week.

The goal is to make this show a weekly occurrence. Scott already has a bunch of interview subjects lined up. Subscribe to the feed and we'll even deliver.

July 12, 13:13 | Comments (21)

Address Book, iSync 2.1 supports Nokia 6630

I bought the fantastic Nokia 6630 back in December under the assumption that Tiger would deliver on interoperability. How sadly disappointed I was when it didn't. But now, finally and out of the blue, Apple has updated iSync to version 2.1 and alongside Address Book now supports my lovely phone. Happy joy, joy.

July 12, 12:17 | Comments (37)

It's boring to scale with Ruby on Rails

I've said it before, but it bears repeating: There's nothing interesting about how Ruby on Rails scales. We've gone the easy route and merely followed what makes Yahoo!, LiveJournal, and other high-profile LAMP stacks scale high and mighty.

Take state out of the application servers and push it to database/memcached/shared network drive (that's the whole Shared Nothing thang). Use load balancers between your tiers, so you have load balancers -> web servers -> load balancers -> app servers -> load balancers -> database/memcached/shared network drive servers. (Past the entry point, load balancers can just be software, like haproxy).

In a setup like that, you can add almost any number of web and app servers without changing a thing.

Scaling the database is the "hard part", but still a solved problem. Once you get beyond what can be easily managed by a decent master-slave setup (and that'll probably take millions and millions of pageviews per day), you start doing partitioning.

Users 1-100K on cluster A, 100K-200K on cluster B, and so on. But again, this is nothing new. LiveJournal scales like that. I hear eBay too. And probably everyone else that has to deal with huge numbers.

So the scaling part is solved. What's left is judging whether the economics of it are sensible to you. And that's really a performance issue, not a scalability one.

If your app server costs $500 per month (like our dual xeons does) and can drive 30 requests/second on Rails and 60 requests/second on Java/PHP/.NET/whatever (these are totally arbitrary numbers pulled out of my...), then you're faced with the cost of $500 for 2.6 million requests/day on the Rails setup and $250 for the same on the other one.

Now. How much is productivity worth to you? Let's just take a $60K/year programmer. That's $5K/month. If you need to handle 5 million requests/day, your programmer needs to be 10% more productive on Rails to make it even. If he's 15% more productive, you're up $250. And this is not even considering the joy and happiness programmers derive from working with more productive tools (nor that people have claimed to be many times more productive).

Of course, the silly math above hinges on the assumption that the whatever stack is twice as fast as Rails. That's a very big if. And totally dependent on the application, the people, and so on. Some have found Rails to be as fast or faster than comparable "best-of-breed J2EE stacks".

The point is that the cost per request is plummeting, but the cost of programming is not. Thus, we have to find ways to trade efficiency in the runtime for efficiency in the "thought time" in order to make the development of applications cheaper. I believed we've long since entered an age where simplicity of development and maintenance is where the real value lies.

This was written as a reply to the What's all the fuss about Ruby On Rails? thread on Joel's forum.

July 08, 15:01 | Comments (54)

New Rails movie with sound and sugar

The original Rails movie left jaws hanging and had developers all over the world stepping through it in slow motion to take it all in. But that was then. Rails 0.5 looks almost primitive from the eyes of a developer working with Rails 0.13. It was high time to rectify both that, the lack of narration, and the notion that Rails is all about Scaffolding.

So allow me to present: The New Rails Movie! It's 50% longer, but shows at least 150% more. And you get my enthusiastic whoops! speak from the Brazilian FISL 6.0 conference where the movie premiered:

Many thanks to Pablo for providing me with the sound from the conference and many thanks to Audacity for making it something you could listen to.

July 07, 17:11 | Comments (26)

Three Rails talks and a workshop at RubyConf '05

The agenda for RubyConf '05 has been revealed and contains no less than three talks on Rails from Lucas Carlson, Nathaniel Talbott, and yours truly. Cherry on top is a Hands-on Rails workshop of sorts after lunch on the last day. It's going to be a Rails bonanza!

But there is more. Oh, there is more. I'm especially looking forward to Jim Weirich's Creating Domain Specific Languages in Ruby and the YARV Progress Report from Koichi SASADA. The whole agenda looks very enticing, actually.

So you should come. Certainly if you're doing or interested in Ruby. Absolutely if you're in, or getting into, Rails. Most of the core group is going to be there as well as plenty more. This RubyConf is the first where Rails will have "come of age" and people will be swapping all those juicy real-life stories.

Thus, I insist on seeing you in San Diego from October 14th through 16th at RubyConf 2005.

P.S.: San Diego is also the home of TextDrive and I hear Jason Hoffman is promising BBQ on the beach. How could you possibly want to miss that?

July 06, 21:29 | Comments (26)

Rails 0.13: 225+ features/fixes in 75 days!

Rumors of our inability to release ever again was surely false. It has happened. A new Rails release for the first time in so long that I had to view the source of my release.rb script again to remember its parameters.

But boy was it worth the wait. We got so much new stuff in here it's not even funny. And the massive influx of new users over the past few months has meant a flood of fixes for every edge case on the planet. We're reaching rapid Maturity on the Scalability with Enterprise goodness scale. Really.

So the big words for this release is Ajax, Migrations, Ajax, Performance, Ajax, Named Routes, and oh, yeah, we got some sweet Ajax in there, too.

It's all backwards compatible too. Upgrading will undoubtful force you to increase the sex-appeal of both your application and your code. Be warned!We got a slightly longer detail on the whole affair up at the Rails weblog.

This of course also means that we're expecting. Yup, that little new one-oh is now slated for laser sharp attention. Just in time for the Rails show they call OSCON. (Yes, delusions of grandeur has been tuned by 37% with this release.)

UPDATE: Our 7th Slashdotting is a reality.

July 01, 10:20 | Comments (26)

The road to harm is paved with good intentions

James Robertson offers a perspective from the Smalltalk camp on the latest meme in Java with Generics Considered Harmful. He charges that its paradoxical to see Java struggle with the immense complexity of generics when the foundation of the language was to dumb things down and make them accessible to the lower levels of the pyramid:

[Joshua Bloch] said that he (and the Java team at Sun) saw the community of developers as a pyramid. The Smalltalkers are up at the peak, and are smart enough to handle all the power they have. He told me (no, I didn't imply this - it was him) - that the Java community was primarily the lower two tiers (imagine 5 in this pyramid) of developers, and simply couldn't handle that kind of power - so Sun had to shield them from it.

I have to concur with James on the depressing implications of such a statement. And most importantly, I don't think it works. Java has become a mace of complexity because of the attempt to shield developers from it. So that screws up the intention to help the lower levels.

But what about the higher levels? How are you going to appeal to that group with a language "dumped down" for the masses? Titles might be one answer. Especially the coveted "architect" label fits well in seeing the hierarchy of programmers as a line of command.

It's a fleeting sensation, though. I believe that's one of the reasons why we're seeing a surge in interest around dynamic languages. The realization that more powerful can lead to less complexity is definitely dawning on a lot of people. And that a lot of the good ideas and patterns can be re-expressed in languages like Ruby for great gain.

When I talk about Ruby on Rails that's often how I bill it. It's the release of good ideas from the captive of complexity. The work, from among others, the top tiers in Suns pyramid put in a context where all tiers of the pyramid can comprehend and forward them.

That's how you can get this funny world where the top tiers of the pyramid are enjoying a life without unnatural restrictions and people just entering the pyramid can love the lack of complexity.