Planet Ruby

Matz Ruby World Keynote

2010-09-06T05:41:00+00:00

The following is my real time transcription of the translation of Matz’s speech at Ruby World 2010. I was typing as fast as I could while he spoke, and I probably made some mistakes. I might have left out some words or sentences. If anything doesn’t make sense, assume it’s my fault and not Matsumoto-san’s. Anyway, I enjoyed Matz’s keynote and thought other English speakers might like a chance to see what he said.

I’m Matsumoto

I Started Ruby in 1993 at NaCL:http://www.netlab.jp/. When I joined the company after graduating from college, I didn’t have much to do at the time. I was not fired fortunately. But I had plenty of time so I started to work on Ruby as a side project.

So at the time, there was ONE user of Ruby. Then I started to develop Ruby with some other friends.

In 1995, Ruby was released and distributed over the internet for general use. At the time, people on usenet got interested in Ruby and gave me some feedback. Also we used a mailing list to distribute information on Ruby.

So within days, about 200 people got involved. So in 1995, the number of people who knew something about Ruby was about 200.

Even after that, Ruby was known to a relatively limited number of people.

Then in 1999, I published a book called Object Oriented Scripting with Ruby. This was the first book on Ruby. It’s only natural. Who else is going to write a book on Ruby, right??

At the time, this sold pretty well. Cumulatively, we sold almost 20,000 copies. I’m sure I’m allowed to discuss this number. Probably it’s only 17,000 in real numbers. This was in Japanese, so Ruby was known to the whole nation. So in 1999, Ruby was known to a lot more people. More engineers and programmers knew about the language.

I started to hear from many people that they knew about Ruby.

In year 2000, a book in English was published. Many people in the world came to know about Ruby.

Then in 2004, Ruby on Rails was released. Of course, most people know about this Web application framework. Ruby on Rails is very productive compared to competing frameworks in other languages. There was an active discussion on the comparison of performance. It was welcomed by many people. We estimate that the number of users grew to 100,000 people in 2004.

In 2008, US-based Gartner released a survey. In the report, Gartner estimated that the total number of Ruby users reached 1,000,000. This was a huge number as you can see.

In the same report, the reporter predicted that in five years (2013) the total number of users would be 4,000,000. Ruby is open source. You don’t have to pay anything to use it. You just download it. It is therefore very difficult to know how many people are using it. I created Ruby myself and I don’t know how many people are using it, so I’m not sure how Gartner reached their conclusion. But anyway, 4,000,000 people are predicted to be using Ruby in 2013.

So in 20 years, this project which started with one person may have increased from 1 to 4,000,000 users. This is beyond the normal growth rate of a technology.

This period of Ruby’s popularity was due to the popularity of Ruby on Rails.

There is a ccompany called Tiobe Software which is a software company in the US. Their Tiobe Index rates the popularity of programming languages using Google, Yahoo, Microsoft, and other search engines to rate the popularity of languages on the internet. Back in 2009, according to Tiobe index, Ruby was ranked #10. And in 2008, it was ranked #9.

In this year, 2010, it was demoted to #12.

You may have a concern about the future of Ruby, but if you drill down deeper, you will see: objective-c is getting more popular, driven by iPad, iPod, etc. development. Objective-C is required. So it jumped form 42 to 11. And Go by Google was released in April of last year. So where it didn’t exist previously it jumped up to #15.

As you can see, Ruby represents 2.221% of programming language references according to Tiobe. That’s good.

So don’t have a concern about this.

But this marks a very interesting symptom. The end of the ruby “bubble”. When I joined the company, the bubble economy was still there. Then it collapsed and caused a lot of trouble. A “bubble” is not sustainable. Bubbles are therefore undesirable.

There are many comedians and musicians named as “one-hit wonders”. I don’t want Ruby to become that.

The life expectancy of a programming language is pretty long. Fortran was created in the 1950s. I want Ruby to be like this. That’s why this presentation is called “Sustainable Ruby”. The question is how to maintain Ruby’s high level of quality and the high level of quality of the people.

So in order to implement “sustainable ruby”, we must first discuss the benefit of Ruby. Benefit is very important for Ruby to be sustainable.

Benefit #1: Productivity. One of the reasons that Ruby is quite popular is that its productivity is quite high. An embodiment of this is Ruby on Rails. When Rails was released, it was often cited that people would say that Rails had 10x productivity over java. Ruby developers didn’t really believe this, but a specific developer in the US wrote an article saying that he felt that HIS productivity over Java when switching to Rails was 10x. In 2005 and 2006, this one sentence caused a lot of arguments and discussion.

After several years of discussion and usage of Ruby on Rails, it may not be 10x but there are many cases where you can enjoy the productivity of Ruby on Rails over Java.

Also, another example of how Rails is productive is that it can take only 15 minutes to develop a web application. In 2004 at a Brazilian conference, David Heinemeier Hansson demonstrated web application development using Ruby on Rails. Without any preparation, no design, no database, he started to create a blog application. You could create articles, list them, etc. He created this application in 15 minutes. In 2004, creating an application in 15 minutes it was astonishing. It was great marketing to do that.

I’m a software engineer and I’m not very interested in marketing. But that video was a huge contributor to making Ruby on Rails popular. Ruby itself didn’t have any marketing, but Ruby on Rails promoted Ruby as well.

Was the Rails framework the sole reason behind the productivity boost when using it? I don’t think so. Ruby itself also makes the productivity possible.

Post-Rails frameworks. Merb Sinatra Ramaze Rails 3

Merb was emerging as a post-Rails framework, but it was quite unique in open software. Merb and Rails jointly created a new framework in the form of Rails 3. Also, Rails 3 is inheriting some of the Merb characteristics. Totally new framework by combining/merging different frameworks.

So far I’ve been talking about the benefits that Ruby can provide in order to make Ruby sustainable.

The second element is the Potential the language can demonstrate. Now we have the technology and the technology is convenient and we can create some benefits. But we need to have potential in the Language for people to make investment.

Around Ruby we have much new technology. Ruby on Rails, for example, introduced innovations in Web development. It wasn’t the first web framework. Not even the first Web framework in Ruby. There were already a lot of web application frameworks in Ruby when Rails was released. But under the circumstances, Ruby on Rails implemented new ideas that triggered productivity enhancements in Ruby AND other languages (python, etc.). So Ruby on Rails had a huge impact on the web application development arena.

Whenever a new technology is created, the surrounding areas also enjoy the benefits of this technology. Not all new technologies will be successful, but some of them will really boost the entire IT industry.

We do see some of that trend in the industry. To support the new technology we need to have smart engineers (hackers). The smart engineers usually come to the interesting technology. Whenever there’s new technology that’s created, it invites the smart engineers who then create new technology. This is a positive cycle. Ruby is one of these positive cycle enforcers.

Benefit, Potential, and….

Passion

The author of The Passionate Programmer, Chad Fowler, is here. I feel embarrassed to say something about him before his keynote. But I have to say this. He is right to emphasize passion. Many people are passionate about ruby. Engineer passion is very important. Passion is key.

In the US there is a conference called RubyConf:http://rubyconf.org. The first one was held in Tampa Florida. There were only 34 attendees at the first conference. Right now we have more than 500 people attending. If the venue could handle it we could probably fit 700 or 1000. They actually limit the number of attendees. They sell out every year. This year RubyConf will be held in Matsue’s sister city, New Orleans. It will be the 10th. It is the longest running Ruby conference on the globe.

Euruko. Poland, Barcelona, Berlin, Prague. On the last day, Euruko always invites speakers to bid on where Euruko should be. Speakers make their case and the location of the next Euruko is voted on.

Two weeks ago we had RubyKaigi. It was held in Tsukuba City. Not in Tokyo. I graduated from Tsukuba univeristy. It made me feel like i was going home. We had about 700 people at RubyKaigi this year. RubyConf will have 500 (ed: actually 600 to 650). The biggest conference is held in Japan.

As you can see here in this venue as well Ruby World has so many people from so many countries. I would say that the IT industry is japan is becoming truly internationalized. We have a disadvantage in Matsue because it’s so remote, but the passion of the Rubyists makes it possible.

We also have regional Ruby conferences in India, China, Brazil, all over the US, etc. They also have another conference called RailsConf:http://railsconf.org, which is operated by a professional event management company (ed: and Ruby Central). They had 1800 people. So that really boosts Ruby.

Startup passion. I’m going to talk about US companies, but there are many venture companies in Silicon valley who are very interested in Ruby. More than 60% of VCs use Ruby to provide the system. Among the famous ones known to Japan includes Twitter. As a startup, they implemented everything using Ruby from bottom to top. Currently they have 100s of millions of users. Much of the RUby has been replaced but if you access twitter you can still see twitter driving the system.

As of last year another acronym was introduced “ARC”. Agile, Ruby/Rails, Cloud. I’ve heard that VCs ask startups who aren’t using Ruby, “Why not?” Investors are pressuring startups to use Ruby. “It’s faster, so if you can shorten your release by one month why not use Ruby?”, they say.

A few years ago when startups were getting started, they wanted to attract smart engineers, so they used Ruby to attract them.

Executives’ passion: Productivity is the key. It’s not just the engineers who are passionate about Ruby. Productivity is one of the biggest factors for businesses. Executives started to realize the importance of using a productive language. Productive languages drive profit. Some executives are finding hope in Ruby.

Differentiation can be found by using Ruby. The japanese IT industry is characterized by conservatism, so many may be reluctant to use Ruby. But by making the decision to use Ruby, they may differentiate themselves. There is also the possibility to change the entire industrial structure by switching to Ruby and other open source technologies, driving more SMBs.

In Japan, major IT companies receive contracts and subcontract to others. But with Ruby and smart engineers, these can be driven to small businesses which can innovate. This drives hope.

Motivation drives Hope

for Food for Money These are very pragmatic

for Good Cause But some people might make a bigger attempt to change the world.

Many people are finding hope in Ruby. Many found potential in Ruby.

Not all have succeeded. Some are extremely successful. Some are not. What made the difference?

In some cases, the benefit was not enough. Or people couldn’t see the potential. But the biggest factor was PASSION! How passionate or decisive they were made the difference.

Lots of people love Ruby. Pictured here (ed: he shows a picture in his slide) are the smiling faces of the staff of the RubyKaigi. This is not organized by professionals. 700 turnout is already beyond its technical limits. But when we ran the survey, most people were satisfied by the conference. It’s miraculous considering the tough circumstances. But these people are passionate.

Many people are surrounding ruby. Hacker,s engineers, executives. They LOVE Ruby.

Of course I love Ruby myself. It’s my child. Every day I am expanding my affection for Ruby. There are so many people out there that love Ruby. As a Japanese, I’m reluctant to say “love”. Actually one guy said “I love you”. I am poor at English. I was very embarrassed :) For Japanese, it’s difficult to express love in a direct fashion. Of course that guy didn’t mean “love”. He just loved Ruby. Like a strong kinship.

Many people love Ruby. Let me give you some examples:

NaCl. When i started at NaCl, Inoue-san he actually picked me up and allowed me to work on this. Back in 1995, there was no way to know if Ruby would be used by anyone. But the president, Mr. Inoue-san had the faith and the vision to hire me and let me work on Ruby. He gave me plenty of time to work on Ruby. It’s all possible because of him.

In 2006, the Matsue mayor actually visited our lab. We would like to use Ruby to revive the city. I had to reply, “Are you out of your mind?” Can you believe this person would try to revive our city using Ruby? Many people living in many places outside of Matsue, so I said maybe it’s difficult but someone from the city told me the Mayor was very serious about this. The mayor himself actually expressed his desire to use Ruby. So as a local government, Matsue city is committed to promote Ruby, which is very very exceptional on examination. How much contribution we’re making to the city really is unknown.

This is Mr. Mizoguchi the Shimane governor. I don’t know how to show my appreciation to him. I’d like to take this opportunity to thank him again. There are many other local governments who are interested in using Ruby to revive their city. But the question is how passionate are the top management or the governor or mayor? Even if the promoters work hard, unless top management is passionate about the promotion it’s not going to work.

One exceptional case is the governor of Fukuoka. A rival of Shimane :). For some reason he really loves Ruby. I’m living her and he’s in Fukuoka. There’s no relation. But Fukuoka is committed to using Ruby and they have organized the Fukuoka award and they have the Ruby Business Commons headquarters.

Here is a noodle called Ruby on Matsue Ramen. The maker of this Ramen sent me an email. The maker of this has no connection to Ruby, but he has a local businesses and wants to promote Ruby. He offered to include the Ruby logo on this noodle to contribute to sales. It’s remarkable. This person volunteered to make Ruby Ramen for us without us asking.

And thanks to all the efforts of all these people, Ruby is exciting right now.

I have been engaged in Ruby for 17 years and i think it’s making sense for me to be passionate about Ruby. But many others are passionate about Ruby. I don’t understand why, but Ruby is loved. Love is driving Ruby.

With the support of so many people, we are able to hold this Ruby World conference for the next two days. And I hope that for these days we can fully discuss the benefits of Ruby so that it will be helpful to what you do. 17 years ago I was the only one person who used Ruby. But over 17 years, people who are using Ruby (more than 1,000,000 people) in university Research, implemented in IT industry, etc.

Some of the things Ruby users are discussing are quite inspiring. Without this conference we can’t attract all of these great people to Matsue people. We should take advantage of this opportunity.

Ruby is supported by passion. And by love.

One more thing: The Ruby Association which I chair provides Ruby programmer certification. We have this announcement today that we have created a new “Gold” certification for Ruby programmers. This requires a higher level of skill. If you go to the Ruby Association home page, there is a press announcement which explains what you need to do to be qualified as Ruby “Gold” certified.

Thank you.

Ruby on Rails 2.3.9 Released

2010-09-04T21:56:07+00:00

We’ve released Ruby on Rails 2.3.9 (gem and git tag) to extend the 2.3.8 bridge a few steps closer to Rails 3 and Ruby 1.9. If your app runs on Rails 2.3.9 without deprecation warnings, you’re looking good for an upgrade to Rails 3.

Deprecations

Changes i18n named-interpolation syntax from the deprecated Hello {{name}} to the 1.9-native Hello %{name}.
Replaces Kernel#returning with Object#tap which is native to Ruby 1.8.7.
Renames Array#random_element to Array#sample which is native to Ruby 1.9.
Renames config.load_paths and .load_once_paths to the more accurate config.autoload_paths and .autoload_once_paths.

Along with these deprecations come a broad array of bugfixes and minor tweaks. Read the commit log for the full story.

Onward to 3.1!

Appreciate Rails 3 with charity

2010-08-31T15:39:38+00:00

Rails 3.0 is a gift from all of us who’ve worked on it to anyone who wants to build something. If you like our gift, please show it by donating to the Rails 3.0 release charity: Charity:Water. We’ve started a campaign to raise $100,000 in the name of Rails 3.0, which will give 5,000 people access to clean water if we make it.

Charity:Water is a fantastic charity (and not just because they run on Rails!). You’d make everyone working on Rails proud by helping us reach our lofty goal.

Donations can be made at http://mycharitywater.org/rails3.

My Reading List on 8/31/2010

2010-08-31T10:24:16+00:00

Thanks to Prentice Hall and Addison-Weseley giving me three new books, my reading list has bulked back up. Here's what I'm working through at the moment: The Freebies UNIX and Linux System Administration Handbook (4th Edition) — I'm really excited about this one, I've loved the first three editions, and this looks like a really solid revamping of a classic in the Sys Admin field. The D

in which the lessons of ZZ Top are applied to the marketplace

2010-08-30T18:23:38+00:00

I've been thinking a lot about ZZ Top recently. This isn't something I generally do as a rule, but it was prompted by re-reading a blog post by the inimitable Giles Bowkett ostensibly about the song I'm Bad; I'm Nationwide. Go ahead and cue that up in the background while you read this post; it's vaguely relevant.

"Bad" in this sense of course is the good kind of bad, like the Michael Jackson song. It seems to be mostly about attitude. Giles makes the point that generally being bad is not correlated with being nationwide.

"I'm Bad, I'm Nationwide" is a ZZ Top song. Hopefully you can figure out what it's about, but just in case, the singer's point is that he is bad, and he is nationwide. [...]

It's good to be bad. It's good to be nationwide. It's even better to be worldwide. How can we apply the lessons of ZZ Top in the workplace?

Obviously if you walk into your boss' office, jump on his or her desk, pull down your pants, and perform toilet functions all over the place, that would be bad. But it would not be nationwide, and it would not encourage becoming nationwide. In fact, it would not really be bad, it would just be stupid. But this silly example highlights a deeper paradox: that which is bad is usually local, and that which is nationwide is usually good.

Giles goes on to talk about how the bad/nationwide balancing act applies to a career in software development, which is interesting, but I've been thinking about it in terms of projects instead. Take the familiar realm of editors. There are a few of them that are nationwide just by virtue of having survived and built up a following over the course of several decades. And they're also often bad when flame wars erupt over them, as is fairly common.

So Emacs and vi have somehow achieved the intersection of bad and nationwide, which as Giles posits is tricky to pull off. Simply being bad doesn't work in the long-term, and while quiet competence sometimes does, it's worth noting that in many cases attention helps a project improve in concrete ways—especially projects whose users are developers. This is pretty key for things like languages, libraries, and build tools.

The problem I'm faced with here is that being bad is also often correlated with being inflammatory. The easiest way to get attention in the software world is to pick a fight. You see this all the time on sites like Reddit; when people smell blood they upvote, which is why stuff like Aleph vs Node.js: the smackdown makes it to the front page despite being a superficial comparison.

The thing you have to remember about picking fights with another project or language just for the sake of it is that often the attention fallout is more evenly distributed than is intended. When someone goes out of their way to pick a fight, they usually aren't much good at hiding the fact that they've got an investment in one side. Impartial readers can usually pick up on this pretty easily, and they're likely to spot holes in the argument or write it off it as a piece of cheerleading. In cases of particularly unfair partisanship, they may even begin to sympathize with the target under attack.

The closest I've come to this sort of bad/nationwide is this post I made on Twitter a few months back:

Q: What's the difference between Ant and Maven? A: The creator of Ant has apologized.

This turned out to be just the right mix of nasty and clever to really take off; hundreds and hundreds of people passed it on, and over the next few days searches for my name came up with just pages and pages of this over and over again. At the time of this writing it's still on the second page of results in a search for my name.

I've got to admit, as the author of a build system that competes with Maven, this felt kind of good. The problem is it's totally a cheap shot—everyone involved with build tools ends up in a position of needing to apologize to their users given enough time. James Duncan Davidson has expressed his regrets over the use of XML in ant, Dave Thomas is less than proud of how RDoc has turned out, and I'm pretty sure the only reason the guy responsible for the tabs/spaces distinction in Makefiles hasn't apologized is that he fled to Tijuana for facial reconstructive surgery. Anyway, Leiningen will eventually be in the same position if it's not already.

So we're still left with this question of whether you can be bad and nationwide without also being a jerk. I think it's doable, but you just don't see it much because picking fights is so much easier. One example that comes readily to mind is _why the lucky stiff. He qualified not just by his off-kilter visual style but by his aversion to what he scoffed at as "best practices".

Perhaps this is why I have trouble swallowing unit testing or extreme programming or other best practices as the law. I guess there’s a place for these tricks (the work place,) but they do not speak to the pure form of hacking for hacking’s sake, which I so ardently defend! Unit testing, in particular, is designed to reel in spontaneous hacking. It is like framing a picture before it has been painted. Hacking, at heart, will continue to be something of spontaneous order, something of anarchy, and the landscape of hacking is something which comes from human action but is not of human design.

― This Hack was not Properly Planned

This may not sound particularly controversial, but in the context of the test-driven-fanatic Ruby community it was a pretty weighty heresy. But he was all about exploring the fringe, and some excellent ideas came of it. It caught peoples' eyes and drew them in, so much so that when he disappeared, the communities surrounding his projects picked up the orphaned bits and carried them forward.

Bad... and nationwide.

This is way more productive than us-vs-them fights that normally accompany attempts to be bad and nationwide. So what does this mean for you and me? Most people can't draw like _why, but injecting your own particular brand of crazy into your projects may be a slick hack you can pull to sidestep the negativity.

Here's an example: the new task in Leiningen spits out a blank Clojure project skeleton. At the time I saw a few too many "foojure"-type names popping up for new projects, and when I saw one called "Couverjure" I said enough is enough. Now the new task will refuse to generate projects named after *jure puns. Arbitrary? You bet. Ridiculous? Perhaps. But harmless and easy to work around. And don't forget controversial:

The point is: don't take yourself too seriously. Hack the good hack and leave an easter egg or two around for the adventurous. Then you too can be bad... and nationwide.

Rails 3.0: It's ready!

2010-08-30T18:13:51+00:00

Rails 3.0 has been underway for a good two years, so it’s with immense pleasure that we can declare it’s finally here. We’ve brought the work of more than 1,600 contributors together to make everything better, faster, cleaner, and more beautiful.

This third generation of Rails has seen thousands of commits, so picking what to highlight was always going to be tough and incomplete. But here’s a choice selection of major changes for Rails 3:

New Active Record query engine
Active Record has adopted the ARel query engine to make scopes and queries more consistent and composable. This makes it much easier to build complex queries over several iterations. We also delay the actual execution of the query until it’s needed. Here’s a simple example:

users = User.where(:name => "david").limit(20)
users = users.where("age > 29")

# SELECT * FROM users 
# WHERE name = "david" AND age > 29 
# ORDER BY name
# LIMIT 20
users.order(:name).each { |user| puts user.name }

Read more in new Active Record guide and watch the Dive into Rails 3: ARel video.

New router for Action Controller
When we switched to a REST-based approach for controllers in Rails 2, we patched on the syntax to the existing router while we were waiting to see if the experiment panned out.

It did and for Rails 3 we’ve gone back and revamped the syntax completely to favor the REST style with less noise and more flexibility:

resources :people do
  resource :avatar

  collection do
    get :winners, :losers
  end
end

# /sd34fgh/rooms
scope ':token', :token => /\w{5,5}/ do
  resources :rooms
end

# /descriptions
# /pl/descriptions
# /en/descriptions
scope '(:locale)', :locale => /en|pl/ do
  resources :descriptions
  root :to => 'projects#index'
end

JRuby at JavaZone 2010

2010-08-30T17:12:07+00:00

I’m pleased to be able to return to Oslo for JavaZone 2010. Whether you’re checking out JRuby for the first time or a veteran JRuby user, I’ll have something for you! And if I don’t, I encourage you to come badger me after the talk is finished.

JRuby: Now With More J!

Additionally, if you’re interested in meeting up for some JRuby discussion next week in Oslo, do drop me a note at the address in the upper right.

Deploying, Monitoring and Troubleshooting Rails on JRuby

2010-08-30T17:06:52+00:00

I am pleased that my Engine Yard webinar on JRuby and deployment is available for general viewing. While the JRuby deployment story is still evolving and maturing, and the 60 minute time frame is too short to cover the issues in depth, I hope you’ll find the content at least gives you some ideas or directions to look.

As always, feel free to contact me with any questions!

Deploying, Monitoring and Troubleshooting Rails on the JVM with JRuby from Engine Yard on Vimeo.

Rails Has Great Documentation

2010-08-30T13:20:00+00:00

To this day I still hear people complain that Rails has poor documentation. From where I’m sitting this seems far from the truth. Let me lay out the evidence piece by piece:

RailsTutorial.org

To learn Rails from scratch Michael Hartl recently finished his book Ruby on Rails Tutorial: Learn Rails by Example. The book teaches Rails 3 from the ground up and it’s available for FREE online. If you’d rather have a PDF or a book you can grab that as well (and he’s even working on some screencasts).

The source for the finalized book will be pushed to GitHub and released under a Creative Commons License shortly after Rails 3 is done. If you’d like to help translate the book to your language of choice, feel free to contact Michael and he’ll get in touch when it’s time to make it happen.

Rails Guides

If you’re not a Rails newbie don’t forget about the Rails Guides, which have been updated for Rails 3.

Rails API Docs

There are two main websites I use to do API lookups. The first is Rails Searchable API Doc, which has online and offline searchable documentation. The second is APIdock which is online only, but has the ability to comment and easily compare different versions of documentation.

Rails 3 Free Screencasts

If you’re more of a visual learner (like me) then there are plenty of free screencasts to teach you about Rails 3. About 2 months ago I produced the Rails 3 Screencasts, which will get you started.

Ryan Bates has also produced an incredible amount of Rails 3 screencasts over on Railscasts.com. Ryan has been producing Railscasts for over 3 1/2 years, isn’t that crazy?

There’s also a few good free screencasts over on Teach me to Code by Charles Max Wood.

Keeping on the Edge

If you find yourself wondering how to keep up with all of the newest features / libraries for Rails 3, both the Ruby5 Podcast and the Ruby Show are going strong. Don’t listen to audio? It doesn’t matter, just subscribe to the Ruby5 RSS feed and get links with descriptions to all the newest libraries, tutorials, and more. You might also want to checkout Peter Cooper’s new Ruby Weekly, a Ruby email newsletter

Need to upgrade a big app to Rails 3?

Jeremy McAnally’s Rails 3 Upgrade Handbook PDF is just $12. There’s also a few paid screencasts for the upgrade over on Thinkcode.tv and BDDCasts.

Need a Book?

There’s a bunch of books that will be coming out after the release, most of which you can start reading now. The Rails 3 Way by Obie Fernandez, Rails 3 In Action by Ryan Bigg and Yehuda Katz, Beginning Rails by Cloves Carneiro Jr and Rida Al Barazi, and of course the Agile Web Development with Rails:fourth edition by Sam Ruby, Dave Thomas, and David Heinemeier Hansson.

In conclusion

No more complaining about lack of good documentation! Seriously. If you want even more Rails 3 content, check out the blog post by Kevin Faustino on 34 Ruby on Rails 3 resources to get you started.

Ruby|Web Interview with Pat Maddox

2010-08-25T13:12:50+00:00

Ok, if I'm going to post about GoGaRuCo today, I should also spend some time on Ruby|Web, the latest regional conference from Mike Moore (@blowmage) and friends — truth in advertising, I'm a volunteer on the board for Ruby|Web, so I might be a bit biased. Just so my biases don't show too much, I asked Pat Maddox(@patmaddox) to answer a few questions for me. Of course, he's a speaker at Ruby|Web

GoGaRuCo 2010: mini-interview with Ilya Grigorik

2010-08-25T09:31:08+00:00

Ilya Grigorik (@igrigorik) is another GoGaRuCo speaker who's kindly agreed to sit down and work through a short interview with me. Hopefully this gives you taste of what you'll be missing if you're not going to the Bay Area's regional Ruby conference. Machine Learning and Ruby don't leap to mind as a common pairing. Why is machine learning important to Rubyists? Ilya I don't think the topic of

Rails 3.0: Release candidate 2

2010-08-24T03:07:34+00:00

The release candidate process is progressing as planned. This second candidate has very few changes over the first, which means that unless any blockers are discovered with this release, we’re targeting the final release of Rails 3.0 for this week(!!!).

So please do help us weed out any blockers. Especially in our two new main dependencies: Bundler and ARel. They’ve both progressed into release candidacy for their 1.0 releases and will be sharing the same 1.0-final release date as Rails 3.0.

You can see a complete list of all the dotted t’s and crossed i’s on the new fabulous Github comparo view of RC1 and RC2.

As always, you install this latest version with: gem install rails --pre

Also note that Rails 3.0 now has it’s own stable branch. The master branch is now reserved for Rails 3.1 development. (That’s right, we’re already going there and it’s going to be M-A-G-I-C-A-L!).

GoGaRuCo 2010: mini-interview with Josh Susser

2010-08-19T08:33:57+00:00

GoGaRuCo is just around the corner (Sep 17-18), and it looks like it's going to be a great conference again this year. I wanted to touch base with Josh Susser (@joshsusser) again to see what was going to set this year apart. He was kind enough to answer a few questions. If you live in the Bay Area and haven't already decided to hit GoGaRuCo, what are you waiting for? This is your second time

My Thoughts on Oracle v Google

2010-08-18T16:52:58+00:00

As you've probably heard by now, Oracle has decided to file suit against Google, claiming multiple counts of infringement against Java or JVM patents and copyrights they acquired when they assimilated Sun Microsystems this past year. Since I'm unlikely to keep my mouth shut about even trivial matters, something this big obviously requires at least a couple thousand words.

Who Am I?

Any post of this nature really requires an author to identify where they stand, so their unavoidable biases can be taken with the appropriate dosage of salt. Rather than having you dig through my past and learn who and what I am, I'll just lay it out here.

I am a Java developer. I've been a Java developer since 1996 or so, when I got my first University job writing stupid little applets in this new-fangled web language. That job expanded into a web development position, also using Java, and culminated with me joining a few senior developers for a 6-month shared development gig with IBM's then-nascent Pacific Development Center in Vancouver, BC. Since then I've had a string of Java-related jobs...some as a trenches developer, some as a lead, some as "architect", but all of them heavily wrapped up in this thing called Java. And I can't say that I've ever been particularly annoyed with Java as a language or a platform. Perhaps I haven't spent enough time on other runtimes, or perhaps I've got tunnel-vision after being a Java developer for so many years. But I'd like to think that I've become "seasoned" enough as a developer to realize no platform is perfect, and the manifold benefits of the JVM and the Java platform vastly outweigh the troublesome aspects.

I am an open-source developer. In the late 90s, I worked in earnest on my first open-source project: the LiteStep desktop replacement for Windows. At the time, the LiteStep project was a loosely-confederated glob of C code and amateur C hackers. Being a Windows user at the time, I was looking to improve my situation...specifically, I had worked for years on a small application called Hack-It that exposed aspects of the win32 API normally unavailable through standard Windows UI elements, and I was interested in taking that further. LiteStep was not my creation. It had many developers before me and many after, but my small contribution to the project was an almost complete rewrite in amateur-friendly C++ and a decoupling of the core LiteStep "kernel" from the various plugin mechanisms. I was also interviewed for a Wired article on the then-new domain of "skinning" computers, desktops, applications, and so on, though none of my quotes made it into the article. After LiteStep, I fell back into mostly anonymous corporate software development, all still using Java and many open-source technologies, but not much of a visible presence in the OSS world. Then, in 2004 while working as the lead "Java EE Architect" for a multi-million-dollar US government contract, I found JRuby.

I am a JRuby developer. Since 2004 (or really since late 2005, when I started helping out in earnest) I've been partially responsible for turning JRuby from an interesting novelty project into one of the top Ruby implementations. We've become well known as one of the best-performing – if not the best-performing – Ruby implementations, even faced with increasing competition from the young upstarts. We're also increasingly popular (and perhaps the easiest path) for bringing Ruby and its many paradigm-shifting libraries and frameworks (like Rails) to Java and JVM users around the world – without them having to change platforms or leave any of their legacy code behind. Part of my interest in JRuby has been to bring Ruby to the JVM, plain and simple. I like Ruby, I like the Ruby community, and on most days I like the cockiness and enthusiasm of those community members toward trying crazy new things. But another large part of my interest in JRuby is more sinister: I want to prove to naysayers what a great platform the JVM actually is, and perhaps make them think twice about knee-jerk biases they've carried and cultivated for so many years.

You'll notice I refer to JRuby not as "it" or "she" or "he", but as "we". "We've become well known...We're also increasingly popular..." That's not an accident. There's now over five years of my efforts in JRuby, and I consider it to be as much a part of me as I am a part of it. And so because of that, I have a much deeper, emotional investment in the platform upon which JRuby rests.

I am a Java developer. I am an open-source developer. I am a JRuby developer and a Ruby fan.

I am not a lawyer.

The Facts, According to Me

These are the facts as I see them. You're free to disagree with my interpretation of the world, and I encourage you to do so in the comments, on other forums, over email, or to my face (but buy me a beer first).

On Java

The Java platform is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. And by big, I mean it's everywhere.

There are three mainstream JVMs people know about: JRockit (WebLogic's first and then Oracle's after it acquired them), Hotspot (Which came to Sun through an acquisition and eventually became OpenJDK), and J9 (IBM's own JVM, fully-licensed and with all its shots). Upon those three JVMs lives a gigantic world. If you want the details, there's numerous studies and reports about the use of Java in all manner of business, from the hippest new startups (Twitter recently switched much of their stack to the JVM) to the oldest of the old financial concerns. It's the favored choice for government server applications, the strongest not-quite-completely-Free managed runtime for open-source libraries and applications, and now with Android it's rapidly becoming one of the strongest (if not the strongest) mobile OS platform (even though Android isn't *really* Java, as I'll get into later). You may love or hate Java, but I guarantee it's part of your life in some way or another.

There are a few open-source implementations of Java. The most well-known is OpenJDK, the Hotspot JVM that Sun relicensed under the GPL and set Free into the world. There's also Apache Harmony, whose class libraries form part of Dalvik's (Android's VM) Java-compatibility layer. There's GNU Classpath, a GPL-based implementation of the Java class libraries used for the ahead-of-time Java compiler GCJ. There's JamVM, which leverages Classpath to provide a very light, very minimal, (and very simple) JVM implementation. And there's others of varying qualities and relevance like IKVM (Java for .NET), VMKit (a Java compiler atop LLVM), and so on. OpenJDK is certainly the big daddy, though, and its release as GPL guarantees we'll at least have a solid Java 6 implementation forever.

Java is not an entirely open platform, what with the now-obvious encumbrances of patents and copyrights (not to mention draconian policies toward Java's various specifications, which are often very slow to evolve due to the JCP quagmire). That's not a great state of affairs, and if nothing else you have to recognize that folks at Sun at least tried to release the platform from its shackles by chasing OpenJDK. But the process of "freeing" Java has been pretty rocky; OpenJDK itself took years to gain acceptance from OSS purists, and the choice of the GPL has meant that folks afeared of the GPL's "viral" side still had to look for other options (which is a large part of why Apache Harmony was used as part of the basis for Android). Perhaps the biggest nail in the coffin is that Sun's Java test kit, the gold standard of whether an implementation is "compliant" or not, has never been released in open-source form, ultimately binding the hands of developers who wished to build a fully-compatible open-source Java.

Java is not an entirely closed platform, either. OpenJDK was a huge step in the direction of Freeing Java, and the Java community in general has a very strong OSS ethos. There's no piece of Java software that isn't at least partially based on open-source componenents, and most Java library, framework, or application developers either initially or eventually open-source some or all of their works. Open-source development and the Java platform go hand-in-hand, and without that relationship the platform would not be where it is today. Contrast that to other popular environments like Microsoft's .NET – which has been admirably Freed through open standards, but which has not yet become synonymous with or popular for OSS development – or Apple's various platforms – which aren't based on open-standards *or* open-source, but which have managed to become many OSS developers' environment of choice...for writing or consuming non-Apple open-source software. Among the corporation-controlled runtimes, the Java platform has more OSS in its blood than all others combined...many times more.

Java is not perfect, but it's pretty darn good. Every platform has its warts. The Java platform represents a decade and a half of tradeoffs, and it's impossible in that amount of time to make everyone happy all the time. One of the big contentious items is the addition in Java 5 of parametric polymorphism as a compile-time trick without also adding VM-level support for reifying per-type specializations as .NET can do. But ask most Java developers if they'd rather have nothing at all, and you'll get mixed responses. The sad, crippled version of generics in Java 5 doesn't do everything static-typing purists want, nor does it really extend to runtime at all (making reflective introspection almost impossible), but they do provide some nice surface-level sugar for Java developers. The same can be said of many Java "features" and tradeoffs. JavaEE became an abortively complicated jumble of mistakes (tradeoffs that went bad), but even upstarts that arguably made better decisions initially have themselves graduated into chaos (I believe the Spring framework has now grown even larger than the largest Java EE conglomerate, and Microsoft's periodically reboots their blessed-framework-of-the-week, resulting in an even more disruptive environment than a slow-moving, bulky standard like JavaEE). Designing good software is hard. Designing good *big* software is exponentially harder. Designing good *big* software that pleases everyone is impossible.

Why People Hate Java

Java is second only to Microsoft's platforms for being both wildly successful and almost universally hated by the self-sure software elite. The reasons for this are manifold and complex.

First of all, back in the 90s Java started getting shoved down everyone's throat. Developers were increasingly told to investigate this new platform, since their managers and long-disconnected tech leads kept hearing how great it was from Sun Microsystems, then a big deal in server applications and hardware. So developers that were happily using other environments (many of which exist to this day) often found themselves forced to suck it up and become Java developers. Making matters worse, Java itself was designed to be a fairly limited language...or at least limited in how easily a developer could paint themselves into a corner. Many features those reluctant developers had become used to in other environments were explicitly rejected for Java on the grounds that they added too much complexity, too much confusion, and too little value to trenches developers. So people that were happily doing Perl or C++ or Smalltalk or what have you were suddenly forced into a little J-shaped box and forced to write all those same applications upon Java and the JVM at a time when both were still poorly-suited to those domains. Those folks have had a white-hot hate for anything relating to Java ever since, and many will stop at nothing to see the entire platform ejected into space.

Second, as mentioned quickly above, Java in the 90s was simply not that great a platform. It had most of the current warts (classpath issues, VM limitations, poor system-level integration, a very limited language) on top of the fact that it was slow (optimizing JVMs didn't come around until the 2000s), marketed for highly-visible, highly-fickle application domains like desktop and browser-based applications (everyone's cursed a Java app or applet at some point in their life), and still largely driven and controlled by a single company (at a time when many developers were trying to get out from under Microsoft's thumb). It wasn't until Java 1.2 that we started to get a large and diverse update to Java's core libraries. Java 1.3 was the first release to ship Hotspot, which started to get the performance monkey off our backs. Java 1.5 brought the first major changes to the Java language, all designed to aid developers in expressing what they meant in standard ways (like using type-safe enums instead of static final ints, or generics for compiler-level assurances of collection homogeneity). And Java 6, the last major version, made great strides in improving startup time, overall performance, and manageability of JVM processes. Java 7, should it ever ship, will bring new changes to the Java language like support for closures and other syntactic sugar, better system-level integration features as found in NIO.2, and the feather in the cap: VM-level support for function objects and non-standard invocation sequences via Method Handles and InvokeDynamic. But unless you've been a Java developer for the past decade, all you remember is the roaring 90s and the pain Java caused you as a developer or a user.

Third, the Java language and environment has stagnated. Given years of declining fortunes at Sun Microsystems, disagreement among JCP members about the direction the platform should go, and a year of uncertainty triggered by Sun's collapse and rescue at the hands of Oracle, it's surprising anything's managed to get done at all. Java 7 is now many years overdue; they were talking about it when I joined Sun in 2006, and hoped to have preview releases within a year. For both technical and political reasons, it's taken a long time to bring the platform to the next level, and as a result many of the truly excellent improvements have remained on the shelf (much to my dismay...we really could use them in JRuby). For fast-moving technology hipsters, that's as good as dying on the vine; you need to shift paradigms on a regular schedule or you're yesterday's news.

Update: At least one commenter also pointed out that it took a long time for Java to be "everywhere", and even today most users still need to download and install it at least once on any newly-installed OS. Notable exceptions include Mac OS X, which ships a cracker-jack Java 6 based on Hotspot, and some flavors of Linux that come with some sort of Java installed out of the box. But this was definitely a very real problem; developers were being pushed to write apps and applets in Java, and users were forced to download a multi-megabyte installer just to run them...at a time when downloading multi-megabyte software was often a very painful ordeal. That would put a bad taste in anyone's mouth.

It's because of these and similar reasons that folks like Google finally said "enough is enough," and opted to start doing their own things. On the JRuby project, we've routinely hacked around the limitations of the JVM, be they related to its piss-poor process management APIs, its cumbersome support for binding native libraries, or its stubborn reluctance to become the world's greatest dynamic language VM. I've thought on numerous occasions how awesome it would be to spin off a company that took OpenJDK and made it "right" for the kinds of development people want to do today (and I'd love to be a part of that company), but such ventures are both expensive and light on profitability. Nobody pays for platforms or runtimes...they pay for services around those platforms or runtimes, services which are often anathema to the developers of those platforms and runtimes. So it required someone "bigger" to make that happen...someone who could write off the costs of the platform by funding it in creative new ways. Someone with a massive existing investment in Java. Someone with deep pockets and an army of the best developers in the business who love nothing more than a challenge. Someone like Google.

Why Android?

(Note that a lot of this is based on what information I've managed to glean from various conversations. Clarifications or corrections are welcome.)

There's an incredibly successful mobile Java platform out there. One that boasts millions of devices from almost all the major manufacturers, in form factors ranging from crappy mid-00s clamshells to high-end smartphones. A platform with hundreds or thousands of games and applications and freely-available development tools. That platform is Java ME.

Java ME started out as an effort to bring Java back to its original roots: as a language and environment for writing embedded applications. The baseline ME profiles are pretty bare; I did some CLDC development years ago and had to implement my own buffered streams and various data structures just to get by. Even the biggest profiles are still fairly restricted, and I don't believe any of them have ever graduated beyond Java 1.3-level featuresets. So Sun did a great job of getting Java ME on devices, back when people cared about Sun...and then they let mobile Java stagnate to a terrible degree while they spent all resources trying to get people to use Java EE and trying to get Java EE to suck less. So while resources were getting poured into EE, people started to form the same opinions of mobile Java they had formed about desktop and server Java years earlier.

At the same time, Java ME was one of the few Java-related technologies that brought in money. You see, in order for handset manufacturers to ship (and boast about) Java ME support, they had to license the technology from Sun. It wasn't a huge cash cow, but it was a cow nonetheless. Java ME actually made money for Sun. So in true Sun form, they loused it up terribly.

Fast forward to a few years ago. Google, recognizing that mobile devices finally were becoming the next great technology market, decided that leaving the mobile world in the hands of proprietary platforms was a bad idea. Java ME seemed like it could be an answer, but Sun was starting to get desperate for both revenue and relevance...and they'd started to back a completely new horse-that-would-be-cow called JavaFX, which they hoped to pimp as the next great development environment for in-browser and on-device apps alike. They weren't interested in making Java ME be what Google wanted it to be.

Google decided to take the hard route: they'd fund development of a new platform, building it entirely from open-source components, and leveraging two of the best platform technologies available: Linux, for the kernel, and Java, for the runtime environment. However there was a problem with Java: it was encumbered by all sorts of patents and copyrights and specifications and restrictions. Hell, even OpenJDK itself, the most complete and competitive OSS implementation of Java, could not be customized and shipped in binary-only form by hardware manufacturers and service providers due to it being GPL. So the answer was to build a new VM, use unencumbered versions of the core Java class libraries, and basically remake the world in a new, copyright and patent-free image. Android was born.

There's many parts to Android, several of which I'm not really qualified to talk about. But the application environment that runs atop the Dalvik VM needs some explanation.

First, there's the VM. Dalvik is *not* a JVM. It doesn't run JVM bytecode, and you can't ship JVM bytecode expecting it to work on Dalvik. You must recompile it to Dalvik's own bytecode using one of the provided translation tools. This is similar to how IKVM gets Java code to run on .NET: you're not actually running a JVM, you're transforming your code into a different form so it will run on someone else's VM. So it bears repeating, lest anyone get confused: Dalvik is not a JVM...it just plays one on TV.

Second, there's the core Java class libraries. Android supports a rough (but large) subset of the Java 1.5 class libraries. That subset is large enough that projects as complicated as JRuby can basically run unmodified on Android, with very few restrictions (a notable one is the fact that since we can't generate JVM bytecode, we can't reoptimize Ruby code at runtime right now). In order to do this without licensing Sun's class libraries (as most other mainstream Java runtimes like JRockit and J9 do), Google opted to go with the not-quite-complete-but-pretty-close Apache Harmony class libraries, which had for years been developed independent of Sun or OpenJDK but never really tested against the Java compatibility kits (and there's a long and storied history behind this situation).

So by building their own non-JVM VM and using translated versions of non-Sun, non-encumbered class libraries, Google hoped to avoid (or at least blunt) the possibility that their "unofficial", "unlicensed" mobile Java platform might face a legal test. In short, they hoped to build the open mobile Java platform developers wanted without the legal and financial encumbrances of Java ME.

At first, they seemed to be on a gravy train with biscuit wheels.

Splitting Up the Pie

Sun Microsystems was not amused. A little over a year ago, when several Sun developers started to take an eager interest in Android, we were all told to back off. It wasn't yet clear whether Android stood on solid legal ground, and Sun execs didn't want egg on their face if a bunch of their own employees turned out to be supporting a platform they'd eventually have to attack. Furthermore, it was an embarrassment to see Android drawing in the same developers Sun really, really wanted to look at JavaFX or PersonalJava or whatever the latest attempt to bring developers back might be. Android actually *was* a great platform that supported existing Java developers and libraries incredibly well (without actually being a Java environment), and for the first time there was a serious contender to "standard" Java that Sun had absolutely no control over.

To make matters worse, handset manufacturers started to sign on in droves to this new non-Java ME platform, which meant all that technology licensing revenue was reaching a dead end. Nobody (including me) wanted to do Java ME development anymore. Everyone wanted to do Android development.

Now we must say one thing to Sun's credit: they didn't do what Oracle is now attempting to do. As James Gosling blogged recently, patent litigation just wasn't in Sun's blood...even if there might have been legal ground to file suit. So while we Sun employees were still quietly discouraged from looking at or talking about Android, the rest of the world took Sun's silence as carte blanche to stuff Android into everything from phones to TVs, and mobile app developers started to think there might be hope for a real competitor to Apple's iPhone. Things might have proceeded in this way indefinitely, with Android continuing to grab market share (it recently passed iPhone in raw numbers with no slowing in sight) and mindshare (Android is far more approachable than almost any other mobile development environment, especially if you're one of the millions of developers who know Java.)

And then it all started to go wrong.

The Mantle of Java Passes to Oracle

If for nothing else, Jonathan Schwartz will be remembered as the man who broke open the Sun piñata, simultaneously releasing more open-source software than any company in history and killing Sun in the process. Either Jonathan had no "step 2" or the inertia of a company built on closed-source products was too great to overcome. In either case, by spring of 2009 Sun was hemorrhaging. Many reports claim that Jonathan had started shopping Sun around to possible buyers as early as 2008, but it wasn't until 2009 that the first candidates started lining up. Initially, it was IBM, hoping to gobble up its former competitor along with the IP, patents, and copyrights they carried. That deal ultimately went south when Sun refused to consider any deal that IBM wouldn't promise to carry to completion, even in the face of regulatory roadblocks sure to come up. Many of us breathed a sigh of relief; if there's any Java company even more firmly stuck in the old world than Sun, it's IBM...and we weren't looking forward to dealing with that.

Once that deal fell through, folks like me became resigned to the fact that Sun was nearing the end of its independent life. Years of platform negligence, management incompetence, and resting on laurels had dug a hole far too deep for anyone to climb out of. Would it be Cisco, who had recently started building up an interesting new portfolio of application server hardware and virtualization software? What about VMWare, who had recently gobbled up Springsource and seemed to be making all the right moves toward a large-scale virtualized "everything cloud." Or perhaps Oracle, a long-time partner to Sun, whose software was either Java-based or widely deployed on Sun hardware and operating systems. Dear god, please don't let it be Oracle.

Don't get me wrong...Oracle's a highly successful company. They've managed to turn almost every acquisition into gold while coaxing profitability out of just about every one of their divisions. But Oracle's not a developer-oriented company (like Sun)...it's a profit-oriented company (unlike Sun, sadly), and you need to either feed the bottom line or feed others in the company that do. So when it turned out that Oracle would gobble up Sun, many of us OSS folks started to get a little nervous.

You see, many of us at Sun had been actively trying to change the perception of the platform from that of a corporate, enterprisey, closed world to that of a great VM with a great OSS ecosystem and an open-source reference implementation. Folks like Jonathan believed that by freeing Java we'd free the platform, and both the platform and the developer community would be better for it. We were half right...the OpenJDK genie is out of the bottle, and there's basically no way to put it back now (and for that, the world owes Sun a great debt). But only part of the platform was Freed...the patents and copyrights surrounding Hotspot and Java itself remained in place, carefully tucked away in the vault of a company that just didn't mount patent or copyright-driven legal attacks.

Oracle, now in control of those patents and copyrights, obviously has different plans.

The Suit

So now, after spending 4000 words of your time, we come to the meat of the article: the actual Oracle v Google suit. The full text is provided various places online, though the Software Patents Wiki has probably the best collection of related facts (though the wiki-driven discussions of the actual patents are woefully inaccurate).

The suit largely comes down to a patent-infringement battle. Oracle claims that by developing and distributing Android, Google is in violation of seven patents. There's also an amorphous copyright claim without much backing information ("Google probably stole something copyrighted so we'll list a bunch of stuff commonly stolen in that way"), so we'll skip that one today.

Before looking at the actual patents involved, I want to make one thing absolutely clear: Oracle has not already won this suit. Even after a couple days of analysis, nobody has any idea whether they *can* win such a suit, given that Google seems to have taken great pains to avoid legal entanglements when designing Android. So everybody needs to take a deep breath and let things progress as they should, and either trust that things will go the right direction or start doing your damndest to make sure they go the right direction.

With that said, let's take a peek at the patents, one by one. And as always, the "facts" here are based on my reading of the patents and my understanding of the related systems.

Protection Domains To Provide Security In A Computer System (6,125,447) and Controlling Access To A Resource (6,192,476)

The first two patents describe the Java Security Policy system, for controlling access to resources. One of the least-interesting but most-important aspects of the Java platform is its approach to security. Code under a specific classloader or thread can be forced to comply with a specific security policy by installing a security manager. These permissions control just about every aspect of the code's interaction with the JVM and with the host operating system: loading new code, reflectively accessing existing classes, accessing system-level resources like devices and filesystems, and so on. It's even easy for you to build up security policies of your own by checking for custom-named permissions and only granting them when appropriate. It's a pretty good system, and one of the reasons Java has a much stronger security track record than other runtimes that don't have pervasive security in mind from the beginning.

In order to host applications written for the Java platform, and to sandbox them in a compatible way, Android necessarily had to support the same security mechanisms. The problem here is the same problem that plagues many patents: what boils down to a fairly simple and obvious way to solve a problem (associate pieces of code with sets of permissions, don't let that code do anything outside those permissions) becomes so far-reaching that almost any reasonable *implementation* of that idea would violate these patents. In this case the '447 and '476 patents do describe mechanisms for implementing Java security policies, but even that simple implementation is very vague and would be hard to avoid with even a clean-room implementation.

Now I do not know exactly how Android implements security policies, but it's probably pretty close to what's described in these patents...since just about every implementation of security policies would be pretty close to what's described.

Method And Apparatus For Preprocessing And Packaging Class Files (5,966,702)

This is basically the patent governing the "Pack200" compression format provided as part of the JDK and used to better-compress class file archives.

Update: Alex Blewitt has posted a discussion of the Pack200 specification. He says this patent isn't nearly as comprehensive, but that it may touch upon how Pack200 works. His post is a more complete treatment of the details of the class file format and how Pack200 improves compression ratios for class archives. It also occurs to me now that this patent could be related to mobile/embedded Java too, where better compression would obviously have an enormous savings.

Java class files are filled with redundant data. For example, every class that contains code that calls PrintStream.println (as in System.out.println) contains the same "constant pool" entry identifying that method by name, a la "java/io/PrintStream.println:(Ljava/lang/String;)V". Every field lookup, class reference, literal string, or method invocation will have some sort of entry in the constant pool. Pack200 takes advantage of this fact by compressing all class files as a single unit, batching duplicate data into one place so that the actual unique class data boils down to just the unique class, method, and code structure.

The reason for having a separate compression format is because "zip" files, which includes Java's "jar" files, are notoriously bad at compressing many small files with redundant data. Because one of the features of the "zip" format is that you can easily pull a single file out, compressing all files together as a single unit prevents introducing any interdependencies between those files or a global table. This is a large part of why compression formats like "tar.gz" do a better job of compressing many small files: tar turns many files into one file, and gzip or bzip2 compress that one large file as a single unit (conversely, this is why you can't easily get a single file out of a tarball).

On Android, this is accomplished in a similar way by the "dex" tool, which in the process of translating JVM bytecode into Dalvik bytecode also localizes all duplicate class data in a single place. The general technique is standard data compression theory, so presumably the novelty lies in applying decades-old compression theory specifically to Java classfile structure.

If I've lost you at this point, we can summarize it this way: part of Oracle's suit lies in a patent for a better compression mechanism for archives containing many class files that takes advantage of redundant data in those files.

Are you laughing yet?

System And Method For Dynamic Preloading Of Classes Through Memory Space Cloning Of A Master Runtime System Process (7,426,720)

I'm not sure this patent ever saw the light of day in a mainstream JVM implementation. It describes a mechanism by which a master parent process could pre-load and pre-initialize code for a managed system, and then new processes that need to boot quickly would basically be memory-copied (plus copy-on-write friendly) "forks" of that master process, with the master maintaining overall control of those child processes through some sort of IPC.

Ignore for the moment the obvious prior art of "fork" itself as applied to pre-initializing application state for many children. Anyone who's ever used fork to initialize a heavy process or runtime to avoid the cost of reinitializing children has either violated this patent (if done since 2003) or has a compelling case for prior art (if done before 2003).

It's likely that this patent was formulated as an answer to the poor semantics of running many applications under the same JVM. Java servlets and later Java EE made it possible to consider deploying all of your company's applications in a single process, isolated by classloaders and security policies. What they never really addressed was the fact that code isn't the only thing you're sharing in this model; you're also sharing memory space, CPU time, and process resources like file descriptors. No amount of Java classloader or security trickery could make this a seamless multiapp environment, and so work like this patent hoped to find a lightweight way for all those child applications to actually live as their own processes.

On Android, this manifests in the fact that each application runs independently, and they (like most operating systems) fork off from either the kernel process or some master process.

In this case, Oracle's banking on being able to litigate with a patent for a very common application of "fork".

Method And Apparatus For Resolving Data References In Generated Code (RE38,104)

This patent, invented by James Gosling himself, basically describes a mechanism by which symbolic data references in code (e.g. Java field references) can be resolved dynamically at runtime into actual direct memory accesses, eliminating the symbolic lookup overhead. It's part of standard JIT optimization techniques, and there's a lot of references in this patent many great JIT patents and papers of the past.

Here there may actually be merit, or as much merit as can be found in a software patent to begin with. The patent itself is tiny, as most of these patents are. The techniques seem obvious to me, but perhaps they're obvious because this patent helped make them standard. I'm not qualified to judge. What I can say is that I can't imagine a VM in existence that doesn't violate the spirit – if not the letter – of this patent as well. All systems with symbolic references will seek to eliminate the symbolic references in favor of direct access. The novelty of this patent may be in doing that translation on the fly...not even at a decidedly coarse-grained per-method level, but by rewriting code while the method is actually executing.

I would guess that this is a patent filed during the development of Java's earlier JIT technologies, before systems like Hotspot came along to do a much better large-scale, cross-method job of optimization. It doesn't seem like it would be hard to debunk the novelty of the patent, or at least show prior art that makes it irrelevant.

Update: I actually found a reference in the article Dalvik Optimization and Verification with dexopt to the technique described here (about 3/4 down the page, under "Optimization"):

"The Dalvik optimizer does the following: ... For instance field get/put, replace the field index with a byte offset. ..."

But Dalvik still does this only once, before running the code (actually, at install time); not *while* running the code as described in the patent.
Interpreting Functions Utilizing A Hybrid Of Virtual And Native Machine Instructions (6,910,205)

This patent, invented by Lars Bak of V8 fame, describes a mechanism for building a "mixed mode" VM that can execute interpreted code and compiled (presumably optimized) code in the same VM process, and flip between the two over time to produce better-optimized compiled code. This describes the basic underpinnings of VMs like Hotspot, which alternate between interpreting virtual machine code and executing real machine code even within the same thread of execution (and sometimes, even branching from virtual code to real code and back within the same method body). Any other VMs that are mixed mode would probably violate this patent, so its impact could reach much farther than Android. (In a sense, even JRuby might violate this patent, though our two mixed modes are both virtual instruction sets.)

Now you might think the other mainstream JVMs would violate this patent, but they don't. Neither JRockit nor J9 have interpreters; they both go immediately to native code with various tiers of instrumentation to do the runtime profile data gathering. They iterative regenerate native code with successively more and better optimizations. Lars most recent VM, the V8 Javascript VM at the heart of Chrome, also goes straight to native code.

Now here's where it gets weird: Up until Froyo (Android 2.2) Dalvik did a once-only compilation to native code before anything started executing, which means by definition that it was not mixed-mode. And even in Froyo, I believe it still does its initial execution in native code form with instrumentation to allow subsequent compiles to do a better job. Dalvik does not have an interpreter, Dalvik does not interpret Dalvik bytecode.

Perhaps someone can explain how this patent even applies to Dalvik or Android?

Update: A couple commenters correct me here: Dalvik actually was 100% interpreted before Froyo, and is now a standard mixed-mode environment post-Froyo. So if this suit had been filed a year ago this patent might not have been applicable, but it probably is now.

Method And System for Performing Static Initialization (6,061,520)

Sigh. This patent appears to revolve completely around a mechanism by which the static initialization of arrays could be "play executed" in a preloader and then rewritten to do static initialization in one shot, or at least more efficiently than running dozens of class initializers that just construct arrays and populate them. Of all the patents, this is probably the narrowest, and the mechanism described are again not very unusual, but there's probably a good chance that the "dex" tool does something along these lines to tidy up static initializers in Android applications.

Given the "preloader" aspect of this patent, I'd surmise that it was formulated in part to simplify static initialization of code on embedded devices or in applet environments (because on servers...the boot time of static initialization is probably of little concern). Because of the much more limited nature of embedded environments (especially in 1998, when this patent was filed) it would be very beneficial to turn programmatic data initialization into a simple copy operation or a specialized virtual machine instruction. And this may be why it could apply to Android; it's another sort of embedded Java, with a preloader (either dex or the dexopt tool that jit-compiles your app on the device) and resource limitations that would warrant optimizing static initialization.

So, Does the Suit Have Merit?

I'll again reiterate that I'm not a lawyer. I'm just a Java developer with a logical mind and a penchant for debunking myths about the Java platform.

The collection of patents specified by the suit seems pretty laughable to me. If I were Google, I wouldn't be particularly worried about showing prior art for the patents in question or demonstrating how Android/Dalvik don't actually violate them. Some, like the "mixed mode" patent, don't actually seem to apply at all. It feels very much like a bunch of Sun engineers got together in a room with a bunch of lawyers and started digging for patents that Google might have violated without actually knowing much about Android or Dalvik to begin with.

But does the suit have merit? It depends if you consider baseless or over-general patents to have merit. The most substantial patent listed here is the "mixed mode" patent, and unless I'm wrong that one doesn't apply. The others are all variations on prior art, usually specialized for a Java runtime environment (and therefore with some question as to whether they can apply to a non-Java runtime environment that happens to have a translator from Java code). Having read through the suit and scanned the patents, I have to say I'm not particularly worried. But then again, I don't know what sort of magic David Boies and company might be able to pull off.

What Might Happen?

In the unlikely event of a total victory by Oracle, there's probably a lot of possible outcomes. I don't see the "death of Java" among them. There's also the possibility that Google could win a convincing victory. What might happen in each case?

The Nuclear Option

The worst case scenario would be that Android is completely destroyed, all Android handsets are confiscated by the Oracle mafia and burned in the city square, and all hope for a Free and Open Java are forever laid to rest. Long live Mono.

To understand why this won't happen we need to explore Oracle's possible motives.

As I mentioned above, Java ME actually did bring licensing revenue to Sun. There's a lot of handset manufacturers, millions of handsets, and every one put a couple cents (or a couple bucks?) in Sun's pocket. In the heady high times of Java ME, it was the only managed mobile runtime in town, with sound and graphics and standard UI elements. It wasn't always pretty, but it worked well and it was really easy to write for.

Now with Android rapidly becoming the preferred mobile and embedded Java, it's become apparent that there's no future for Java ME - or at least no future in the expanding "smart" consumer electronics business. Java ME lives on in Blackberries, some other low-end phones, in most Blu-Ray devices (BD-J is a standard for writing Java apps that run on Blu-Ray systems, utilizing one of the richer class libraries available for Java ME), and in some sub-micro devices like Ajile's AJ-200 Java-based multimedia CPU. If you want Java on a phone or in your TV, Android is taking that world by storm. That means Java ME licensing revenue is rapidly drying up.

So why wouldn't Oracle want to take a bite of the rapidly-growing Android pie? Would they turn down a portion of that revenue and instead completely destroy a very popular and successful mobile Java, or would they just strongarm a few bucks out of Google and Android handset manufacturers? Remember we're talking about a profit-driven company here. Java ME is never going to come back to smartphones, that much is certain and I don't think even Oracle could argue it. There's no profit in filing this suit just to kill Android, since it would just mean competing mobile platforms like Windows Phone, RIM, Symbian, or iOS would just canibalize their younger brother. Instead of getting a slice of the fastest-growing segment of Java developers, you'd kill off the entire segment and force those developers to non-Java, non-Oracle-friendly platforms.

Oracle may be big and evil, but they're not stupid.

Google Licensing Deal

A more likely outcome might be that Google would be forced to license the patents or pay royalties on Android revenue. I honestly believe this is the goal of this lawsuit; Oracle wants to get their foot into the door of the smartphone world, and they know they can't innovate enough to make up for the collapse of Java ME. So they're hoping that by sabre-rattling a few patents, Google will be forced (or scared) into sharing the harvest.

Given the contents of the suit and the patents, I think this one is pretty unlikely too. Much of Android and Dalvik's designs are specifically crafted to avoid Java entanglements, and I think it's unlikely if this suit goes to trial that Oracle's lawyers would be able to make a convincing argument that the patents were both novel and that they were violated by Google. But let's not put anything past either the lawyers or the US federal court system, eh?

Nothing At All

There's a good chance that either Oracle or the court will realize quickly that the case has no merit, and drop all charges. I'm obviously hoping for this one, but it's likely to take the longest of all. First, the court would need to gather all facts in the case, which could take months (especially given the highly technical nature of some of the compaints). Then there's the rebuttals of those facts, sorting out the wheat from the chaff, deciding there's not enough there to proceed, and either Oracle backs out or the court tosses the case. In the latter case, there's the possibility of appeals, and things could start to get very expensive.

Total Collapse of Software Patents

This is probably the one of the highest-profile cases involving software patents in recent years. The other would be Apple's recent suit against HTC for design elements of the iPhone. Several other bloggers and analysts have called out the possibility that this could lead to the death of software patents in general. I think that's a bit optimistic, but both Google *and* Oracle have come down officially against patents in the past (though perhaps Oracle's had a change of heart since acquiring Sun's portfolio).

As much as I'd like to see it happen, software patents probably won't be dead in the next year or two. But this might be a nail in the coffin.

What Does This Mean for Java?

Now we come to the biggest question of all: how does this suit affect the Java world, regardless of outcome?

Well it's obviously not great to have two Java heavyweights bickering like schoolchildren, and it would be positively devastating if Android were obliterated because of this. But I think the real damage will be in how the developer community perceives Java, rather than in any lasting impact on the platform itself.

Let's return to some of our facts. First off, nothing in this suit would apply to any of the three mainstream JVMs that 99% of the world's Java runs on. Hotspot and JRockit are both owned by Oracle, and J9 is subject to the Java specification's patent grant for compliant implementations. The lesson here is that Android is the first Java-like environment since Microsoft's J++ to attempt to unilaterally subset or superset the platform (with the difference in Android's case being that it doesn't claim to be a Java environment, and it may not actually need the patent grant). Other Java implementations that "follow the Rules" are in the clear, and so 99% of the world's use of Java is in the clear. Sorry, Java haters...this isn't your moment.

This certainly does some damage to the notion of open-source Java implementations, but only those that are not (or can not be) compliant with the specification. As the Apache Harmony folks know all too well, it's really hard to build a clean-room implementation of Java and expect to get the "spec compliance patent grant" if you don't actually have the tools necessary to show spec compliance. Tossing the code over to Sun to run compliance testing is a nonstarter; the actual test kit is enormous and requires a huge time investment to set up and run (and Sun/Oracle have better things to do with their time than help out a competing OSS Java implementation). If the test kit had been open-sourced before Sun foundered, there would be no problem; everyone that wanted to make an open-source java would just aim for 100% compliance with the spec and all would be well. As it stands, independently implemented (i.e. non-OpenJDK) open-source Java is a really hard thing to create, especially if you have to clean-room implement all the class libraries yourself. Android has neatly dodged this issue by letting Android just be what it is: a subset of a Java-like platform that doesn't actually run Java bytecode and doesn't use any code from OpenJDK.

How will it affect Android if this case drags on? It could certainly hurt Android's adoption by hardware manufacturers, but they're already getting such an oustanding deal on the platform that they might not even care. Android is the first platform that has the potential to unify all hardware profiles, freeing manufacturers from the drudgery of building their own OSes or licensing OSes from someone else. Hell, HTC rose from zero to Hero largely because of their backing of Android and shipping of Android devices. Are they going to back off from that platform now just because Oracle's throwing lawyerbombs at Google? Probably not.

What Does This Mean For You?

If you're a non-Android Java developer...don't lose sleep over this. The details are going to take months to play out, and regardless of the outcome you're probably not going to be affected. Be happy, do great things, and keep making the Java platform a better place.

If you're an Android developer...don't lose sleep over this. Even if things go the way of the "Nuclear Option", you've still got a lot of time to build and sell apps and improve yourself as a developer. For a bit of novelty, start considering what a migration path might look like and turn that into a nice Android-agnostic application layer, something that's largely lacking in the current Android APIs. Or explore Android development in languages like JRuby, which are based on off-platform ecosystems that will survive regardless of Android's fate. Whatever you do, don't panic and run for the hills, and don't tell your friends to panic.

If you're mad as hell about this...I sympathize. I'm personally going to do whatever I can to keep people informed and keep pushing Android, including but not limited to writing 8000-word essays with my moderately-educated analysis of the "facts". I welcome your help in that fight, and I think it's a damn good time for people that want an open Java and an open mobile platform to show their quality by standing up and letting the world know we're here.

"All that is necessary for the triumph of evil is for good men to do nothing."

Do something, and we'll get through this together.

Footnote: Java Copyrights

I'd love for someone versed in copyright law to provide a brief analysis of how the Java copyrights described (vaguely) in the lawsuit might play out in Android. Java is certainly not ignored as a concept in Android docs, tools, and libraries, but it's unclear to me whether those copyrights amount to something enforceable when it comes to Android or Dalvik.

Update: "Crazy" Bob Lee emailed me to clear up a few facts. First off, Android and OpenJDK first came out around roughly the same time, so there was never really time to consider using OpenJDK's GPL'ed class libraries in Android. Bob also claims that Dalvik's design decisions were all technical and not made to circumvent IP, but it seems impossible to me that IP, patent, and licensing issues didn't have *some* influence on those decisions. He goes on to say that Android relies on process separation to sandbox applications, rather than leveraging Java security policies (or similar mechanisms (which Bob insists are badly designed anyway, and I might agree). Finally, he believes that in the worst case scenario, Dalvik would probably only require minor modifications to address the complaints in this suit. The "nuclear option" is, according to Bob, out of the realm of possibility.

Thanks for the clarifications, Bob!

Book review - Web Operations

2010-08-17T13:55:01+00:00

I just finished reading a great book - Web Operations by John Allspaw and Jesse Robbins. This isn't a book of code samples; it's a book to make you think more about system administration in the large, infrastructure as code, and other big picture items for the web systems that we deal with today. Some notes:

Chapters 6 and 11 talk about the difference between monitoring and metrics and the need for both. I've always done the monitoring part - mostly on the system level, though, gathering load average and disk usage and such. What I haven't done enough of is monitoring on the app level - e.g., if 100 users have signed up in the last day, alert me. These sorts of things are very doable, but they require effort. For metrics, doing those on the application level is very informative - how many users signed up today? How many tickets were opened in the past week? These chapters talk about using Ganglia for that... sounds like a great tool, and would be an improvement over the low-ceremony daily summary emails. At least those are a start, though; better than nothing. Gathering those metrics can lead to interesting discussions around trends and forecasting - if we did get 100 users in a day, what would that mean for our system? How would that change our hardware breakdown? And there are business-level questions too - are those users coming back, or are they creating accounts and never logging in again?
Chapter 7 is a reprint of the excellent "How Complex Systems Fail" essay by Dr Richard Cook. Well worth reading and re-reading.
Chapter 10 is a good discussion of dev/ops collaboration - or, sadly and more often, the conflict between the two. It's a tragedy and a waste when dev folks and ops folks don't get along. The ops guys have so much to teach the devs - they spend all day dealing with and are experts in stuff that devs usually touch once every 3 months (network configs, DNS, SMTP, backup/restore). And vice versa, of course - my impression is that there are a lot of ops shops that aren't using SCM for their scripts and don't have server builds automated. Tools like Puppet can help to bridge this gap... generally, both dev and ops need to be considerate of each other's responsibilities and needs. Lots to learn here.
Chapter 12 had a fun discussion of the lure of DB clustering. I won't spoil it for you, but it really rang true for me.
One thing I liked about the whole book was the general assumption that you do want failover and redundancy and are willing to work for that. That is to say, that you actually care about the app you are working on, the people you are working with, and the customers you are serving! I don't quite know how to put my finger on it... but there's sort of an underlying thoughtfulness about it all. There's a feeling that I don't want to blame others for the system going down, rather, I want to build in sufficient checks and balances so that when a server goes down the system continues to tick along without anyone having to make the 2 AM drive to the colo. It reminds me of the Cassandra project fellows saying that if a DB node goes offline in the middle of the night they can say "meh" and let it go until the next day. Good stuff.

Obviously, I heartily recommend this book. If you've done much devops at all you'll find yourself enjoying (and sympathizing with the folks suffering through) the anecdotes, and you'll come away from this book a list of things to do to lower the stress level around running your web app. Enjoy!

Why Whyday

2010-08-16T17:00:15+00:00

This next Thursday is Whyday. Celebrate with some outragous coding.

What are you doing for Whyday?

This next Thursday is designated as Whyday, a day set aside to commemorate all the many wacky contributions of Why the Lucky Stiff to the Ruby community. How do you celebrate WhyDay? The WhyDay web page suggests:

See how far you can push some weird corner of Ruby (or some other language).
Choose a tight constraint (for example, 4 kilobytes of source code) and see what you can do with it.
Try that wild idea you’ve been sitting on because it’s too crazy.
You can work to maintain some of the software Why left us (although Why is more about creating beautiful new things than polishing old things).
On the other hand, Why is passionate about teaching programming to children. So improvements to Hackety Hack would be welcome.
Or take direct action along those lines, and teach Ruby to a child.

As for me, I have several ideas:

Play with the HTML5 canvas, maybe writing a Ruby DSL for easily generating diagrams in Ruby.
Play with some Grit (a Ruby/Git library) and see if I can categorize git commits into a swimlane structure.
Combine the two ideas into program that generates a graphical swimlane representation (using an HTML5 canvas) of a git project history (similar to the hand drawn swimlanes in Vincent Driessen’s Article).

Those are just my ideas. And I reserve the right to change my mind at a moments notice.

So, what are you doing for whyday?

Rails and PostgreSQL job at Paperless Post

2010-08-10T17:17:00+00:00

Another Rails and PostgreSQL job, this time at Paperless Post (via the Github jobs board). Looks like they have a few more open positions. And you'd work with Aaron Quint, who's their CTO. Good times!

Rails and PostgreSQL job at elevenlearning.com

2010-08-06T13:33:00+00:00

Saw this ad for a Rails and PostgreSQL job at Eleven Learning. The company name is a "Spinal Tap" reference... well played.

PGCon 2010 talk on Rails and PostgreSQL

2010-08-03T21:04:00+00:00

A while back I posted a link to a talk by Gleb Arshinov that he gave at the SF PUG. This talk was on "PostgreSQL for high performance Rails apps", and was full of fine suggestions from their experiences with their Rails apps.

Gleb is back again, this time on May 21 2010 at PGCon where he and Alexander Dymo talked about PostgreSQL as a secret weapon for Rails apps. Some of the same ground is covered (use SQL DDL vs ActiveRecord create_table, etc), but there's lots of new information too. Here are some notes:

1:10 They're using PostgreSQL 8.4, nginx, and mongrel

4:00-6:00 Talks about dropping down into SQL via ActiveRecord

6:30 Use include to eliminate N+1 queries.

7:30 Watch for things like acts_as_tree that reintroduce lots of queries in exchange for the improvement in abstraction.

9:00 One query, 12 joins - complicated, but query time goes from 8 seconds to 60 ms.

14:00-17:00 A technique for recording SQL queries; this helps ensure you're not running unexpected queries

19:00 Suggests use straight SQL for DDL rather than the ActiveRecord DSL

20:00 Use constraints, FKs, etc to preserve data integrity - "anything you don't have a constraint on will get corrupted"

23:00 Don't use CASCADE since app won't know about the deletions

28:00 Keep a log of times for the most frequent user requests. Alex suggests using integration tests for this; code is at 29:10 and 29:30.

32:30 A technique for loading data with ActiveRecord's select option with PostgreSQL arrays to save on object creation. Questions from the audience about normalization vs efficiency.

38:50 Role/user/privilege checking can be slow; shows a technique for using PostgreSQL's bool_or and GROUP BY to get the data in one fell swoop. Query time went from 2+ seconds to 64 ms.

42:00 Do analytics in the database. Saw speed improve from 90s to 5s and saved tons of RAM.

44:40 Some excellent new PostgreSQL features that are either here now or are on the way (replication, windowing functions)

46:30 Demonstrates a problem with PostgreSQL's LIMIT and OFFSET when used with subselects. Some discussion of pagination with the audience. Here's an excellent discussion of pagination alternatives written by Justin French.

50:30 How to force PostgreSQL to use a subselect vs a join; the example goes from 605ms to 325 ms.

52:20 Be careful with generate_series. Apparently these functions cannot generate hints for the planner.

55:30 General props to PostgreSQL community.

59:40 Need to test queries both in cold state and hot state; they saw 14x speed difference.

1:01:40 Tune PostgreSQL - shared_buffers, work_mem, autovacuum, etc. Rely on community knowledge for initial configuration.

Lots of good stuff there, enjoy!

Rails 3.0: Release candidate!

2010-07-26T21:46:07+00:00

High off Baltimore Pandemic and Yellow Tops, I believe we promised a release candidate shortly after RailsConf. As things usually go in open source, we gorged ourselves on fixes and improvements instead. But all to your benefit. We’ve had 842 commits by 125 authors since the release of the last beta!

Now it’s time to just say good is good enough, otherwise we could keep on with this forever. So please welcome the Rails 3 release candidate! You install, as always, with gem install rails --pre.

Most of the fixes have been of minor significance, but we did manage to dramatically speed up Rails 3 development and startup speed for larger applications (Basecamp went from insufferable to about 2.3 levels of enjoyment).

Speed is now pretty good across the board except for part of Arel that Active Record now depends on. We’ll be making sure we get performance of Active Record back to at least 2.3 levels before release.

A few more highlights:

Support for the MySQL2 gem, which will take care of MySQL encoding issues on Ruby 1.9.2.
Shallow routes are back.
Fixed the autoload issues
Made the rails command work even when you’re in a subdirectory
Dealt with a variety of web encoding issues

Indulge yourself in the delights of all the glorious details from the commit logs or checkout the slightly less pedantic summaries in the CHANGELOGs.

This release candidate of Rails 3 also concides with the release candidate of Bundler 1.0. Huge strides were made with Bundler and it should both be much faster and have most of the edge cases sawed off.

I’ve said “we’re almost there” so many times that I’m almost exhausted. But really, guys, WE’RE ALMOST THERE!!!¹

¹ Just a few weeks before final is out?