50% and Counting: PHP 7 Takes Off

A year and half ago, we launched support for PHP on Heroku, built from the ground up with modern features designed to give developers a more elegant and productive experience on the platform. Last week, we made PHP 7 available on top of a new, reworked version of our PHP support, and our users are adopting PHP 7’s exciting new features and stellar performance improvements quickly—we’re already seeing PHP 7 being used in the majority of PHP deploys on Heroku.

Under the hood, much of the logic that handles a deploy has changed, but not the fundamental principles upon which our support for PHP applications is designed. We've always been determined to provide a fully standards-based implementation that does not rely on proprietary configuration or magic behavior, and that means building on top of a great foundation of tools.

Composer Rising

Inspired by an explosion of collaboration in Open

php-7

Continue reading “50% and Counting: PHP 7 Takes Off”

PHP – a look back, a look forward

The history of PHP is the history of the web. Long-time developers will remember how PHP changed the universe of web development. PHP brought two key innovations to the table when it first launched. First, it was interpreted, which meant you could edit a file in place, then refresh the page and see the result. This quick feedback loop was why so many started with PHP and is still a cornerstone of what makes the language so useful. Second, it was the first widespread templating language which enabled intermixing of HTML and PHP code. Every other major web language and framework since PHP has followed suit.

Over time, PHP became a cornerstone of the “LAMP stack”. The LAMP stack consisted of Linux, Apache, MySQL, and PHP, and helped to define the world of open source we all take for granted today. The ubiquity of open-source software in web development is near-absolute now, but it was the success of these technologies that redefined an industry.

Of course PHP wasn’t perfect and other languages and their frameworks came along to contend with PHP as the years went by. In fact, Heroku’s founders ran a PHP consultancy called Bitscribe which focused on PHP development before founding Heroku. They eventually moved from PHP on to Ruby on Rails, which led to the creation of Heroku when they discovered that the Rails ecosystem lacked good hosting options.

A Modern PHP

The best way to get someone to do the right thing is to make it the easiest thing to do. That’s why we’ve built Heroku to support and encourage the best practices of modern software development out of the box. We’ve captured a lot of this experience in the Twelve-Factor App Manifesto, and now we’ve also applied it to our new PHP support on the platform. Here’s a look at just of the few of they ways they apply:

The days of live on-server editing along with all the late nights and outages it inevitably leads to are fortunately behind us. Version control is ubiquitous today, and it’s rare to meet a development team not collaborating using a tool like Phabricator or GitHub. Unfortunately, it’s still far too common for system libraries, web servers, and extensions to be mismatched between dev, staging, and production environments. On Heroku, your git integrated deployment pipeline allows you to “git push” to deploy code with confidence whether it’s to your development environment or to production. We’ll use Composer to automatically ensure you get exactly the right version of all your code’s dependencies every time, including configuring either Apache or Nginx, and all your system dependencies.

Although many other languages have grown their own rudimentary native web servers, it’s still most common to pair PHP with a dedicated web server. Apache is the most common choice and very well understood, but Nginx is certainly growing in popularity. We support both, and in order to improve dev-prod parity, we’ve built a composer package that lets you, the developer, choose which one you prefer, receive a sensible configuration out-of-the-box, and further configure them with ease whether you’re running on Heroku, your local machine, or anywhere you please.

Today and Tomorrow

In today's world, PHP developers choose from a huge variety of technology options. These include modern data stores like PostgreSQL, Redis, and MongoDB, front-end frameworks like Angular, and platforms like, of course, Heroku.

In fact, for many modern PHP applications the notion of the LAMP stack seems limiting. Fortunately, PHP developers on Heroku can fearlessly take advantage of just about any technology they can imagine. For example, every PHP app on Heroku includes a free PostgreSQL database with support for a wide variety of powerful features like full-text search, and native JSON types. If Postgres isn’t to your liking our add-on marketplace brings the entire ecosystem to your fingertips. If you’ve got a technology need, you’ll probably find just the add-on you’re looking for.

One piece of future direction we’re incredibly excited about is Hack. Hack brings a whole host of new developments to PHP. Many PHP developers have heard about HHVM, Facebook’s high performance PHP virtual-machine project. Hack is another project from that team, and it includes great new features like an improved collections library, asynchronous method calls, and even the world’s friendliest type-system – all while supporting vanilla PHP code and enabling you to adopt it incrementally as you discover the features you need. And Hack is available for you to try directly on Heroku today with this new PHP support.

We should note though, Hack is quite new, and we encourage you to give it a try, but at this point support for Hack should definitely be considered experimental and we would encourage you to test it thoroughly before putting anything into production.

When you put all these pieces together, it’s inarguable: PHP’s future is bright. Hundreds of thousands of PHP developers ship code every day. From Facebook to Etsy to WordPress: big companies continue to invest in PHP. Between the long-term stewardship of Zend and the new creative energies Facebook’s Hack language have brought to the community, it’s clear that no matter what flavor of PHP you choose there’s an ever more powerful, flexible future… with lots of fast feedback.

Whether you’re engineering high-scale mission-critical systems every day or you’re just making things for yourself and your friends, try the new PHP in public beta on Heroku today.

Happy making, and welcome to Heroku.

Upgrading to the Heroku Toolbelt

Heroku Toolbelt

The original version of the Heroku command-line tool was available as a Ruby gem. This made it easy to install on all platforms with just one command: gem install heroku. While we love this simplicity, it depends on a system install of Rubygems. To get this experience on widely varying development environments, we created the Heroku Toolbelt, a one-click installer for every major platform.

Going forward we will be sunsetting support for the heroku gem in favor of the Toolbelt. If you’re already using the Toolbelt, you’re fine to stop reading now. To verify whether you’re using the gem or Toolbelt, use heroku version:

$ heroku version
heroku-toolbelt/2.32.11 (universal-darwin12.0) ruby/1.9.3 autoupdate

If the output includes heroku-toolbelt, you’re all set.

Advantages of the Toolbelt

The Toolbelt is a self-contained installer that gives you everything you need to use Heroku. Some advantages of the Toolbelt include:

  • The Toolbelt is much faster, shaving several seconds off the startup of each heroku command.

  • The Toolbelt packages its own dependencies and will not conflict with your existing development tools.

  • The Toolbelt automatically keeps itself up to date with the latest available bug fixes, security updates, and new features.

Sunsetting the Gem

Starting today, all users still using the gem will see reminders to upgrade to the Toolbelt. This reminder will appear at most once daily when running a heroku command.

On December 1, 2012, we will stop releasing new updates to the heroku gem.

If you are using the heroku gem in your app to programatically access the Heroku API, we encourage you to migrate your code to the heroku-api gem. Existing versions of the heroku gem will remain on rubygems.org so any code referencing these gems should continue to function as long as the API they reference is available.

We encourage all users to upgrade to the Toolbelt today to take advantage of this new, streamlined CLI experience.

Rails 3.2.0: Faster dev mode & routing, explain queries, tagged logger, store

So we didn’t quite make the December release date as we intended, but hey, why break a good tradition and start hitting release targets now! In any case, your patience has been worldly rewarded young grasshopper: Rails 3.2 is done, baked, tested, and ready to roll!

I’ve been running on 3-2-stable for a few months working on Basecamp Next and it’s been a real treat. The new faster dev mode in particular is a major step up over 3.1.

Do remember that this is the last intended release series that’s going to support Ruby 1.8.7. The master git branch for Rails is now targeting Rails 4.0, which will require Ruby 1.9.3 and above. So now is a great time to start the work on getting your app ready for the current version of Ruby. Let’s not hang around old versions forever and a Sunday like those Python guys :).

There’s a v3.2.0 tag on Github and we of course we still have the 3-2-stable branch as well. You can see all the glorious details of everything that was changed in our CHANGELOG compilation.

For documentation, we have the 3.2 release notes with upgrade instructions, both the API docs and the guides have been generated for 3.2 as well, and there’s a brand new 3.2-compatible version of Agile Web Development with Rails. A smörgåsbord indeed!

Note: If you’re having trouble installing the gems under Ruby 1.8.7, you’ve probably hit a RubyGems bug with YAML that’s been fixed in RubyGems 1.8.15. You can upgrade RubyGems using “gem update—system”.

If you can’t be bothered with the full release notes, here’s a reprint of a few feature highlights from when we did the first release candidate:

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline—how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

Logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
Logger.tagged("BCX") { Logger.info "Stuff" } # Logs "[BCX] Stuff" 
Logger.tagged("BCX") do
  Logger.tagged("Jason") do
    Logger.info "Stuff" # Logs "\[BCX\] \[Jason\] Stuff" 
  end
end

Active Record Store

Key/value stores are great, but it’s not always you want to go the whole honking way just for a little variable-key action. Enter the Active Record Store:

class User < ActiveRecord::Base
  store :settings, accessors: [ :color, :homepage ]
end
u = User.new(color: 'black', homepage: '37signals.com')
u.color                          # Accessor stored attribute
u.settings[:country] = 'Denmark' # Any attribute, even if not specified with an accessor

Rails/master is now 4.0.0.beta

The forthcoming 3.2.x release series will be the last branch of Rails that supports Ruby 1.8.7. There’s a new 3-2-stable branch in git to track the changes we need until 3.2.0 final is release and for managing point releases after that.

So for now you should stop floating on rails/master if your application is not compatible with Ruby 1.9.3. We have updated the version numbers to indicate this backwards incompatibility to be 4.0.0.beta. This doesn’t mean that 4.0 is anywhere close to being released, mind you. We’re simply doing this now because we’re dropping support for Ruby 1.8.7 in rails/master and people should know what’s up.

Major versions of Rails has been on about 2-year release cycle since 1.0 (released in 2005, followed by 2.0 in 2007, followed by 3.0 in 2010) and we intend to continue this pattern. The current internal target for Rails 4.0 is sometime in the Summer of 2012 — but we have blown every major release estimate in the past, so don’t bet your farm on it.

There’s not a lot of details about what we’re going to include in Rails 4.0 yet as the primary purpose for bumping the major version number is to drop Ruby 1.8.7 support. But unlike Rails 3.0, we intend for it to be a much smoother transition. The intention is not for this to be a REWRITE EVERYTHING release in the same way 3.0 was to some extent.

But we’re getting ahead of ourselves. First mission is to get Rails 3.2 out!

Rails 3.2 RC1: Faster dev mode & routing, explain queries, tagged logger, store

Once you’ve boarded the Rails train, you just know that every stop along the way is going to be a good time. This release candidate is no different and we’ve packed it with loving goodies without making upgrading a hassle.

Faster dev mode & routing

The most noticeable new feature is that development mode got a ton and a half faster. Inspired by Active Reload, we now only reload classes from files you’ve actually changed. The difference is dramatic on a larger application.

Route recognition also got a bunch faster thanks to the new Journey engine and we made linking much faster as well (especially apparent when you’re having 100+ links on a single page).

Explain queries

We’ve added a quick and easy way to explain quieries generated by ARel. In the console, you can run something like puts Person.active.limit(5).explain and you’ll get the query ARel produces explained (so you can easily see whether its using the right indexes). There’s even a default threshold in development mode where if a query takes more than half a second to run, it’s automatically explained inline—how about that!

Tagged logger

When you’re running a multi-user, multi-account application, it’s a great help to be able to filter the log by who did what. Enter the TaggedLogging wrapper. It works like this:

Logger = ActiveSupport::TaggedLogging.new(Logger.new(STDOUT))
Logger.tagged("BCX") { Logger.info "Stuff" } # Logs "[BCX] Stuff" 
Logger.tagged("BCX") do
  Logger.tagged("Jason") do
    Logger.info "Stuff" # Logs "\[BCX\] \[Jason\] Stuff" 
  end
end

Active Record Store

Key/value stores are great, but it’s not always you want to go the whole honking way just for a little variable-key action. Enter the Active Record Store:

class User < ActiveRecord::Base
  store :settings, accessors: [ :color, :homepage ]
end
u = User.new(color: 'black', homepage: '37signals.com')
u.color                          # Accessor stored attribute
u.settings[:country] = 'Denmark' # Any attribute, even if not specified with an accessor

These are just a few of the highlights. The full release notes detail every loving change.

Given that this is a release candidate, we’re ever so eager to hear your feedback. We hope it’ll be a quick RC phase, but please do spoil that plan by reporting bugs.

As always, you install a release candidate by doing gem install rails --pre.

Rails now tested on Travis CI

Setting up continuous integration for Rails has been a complicated undertaking in the past.

Rails needs to be tested against different Ruby versions and various modes (such as running test cases in isolation/non-isolation, running ActiveRecord with identitymap enabled/disabled). This made the test suite run for an isanely long time (up to 2 hours on 1.9.2 alone) and required regular maintenance by
the Rails core team.

Over the past weeks the folks at Travis CI have been working hard to provide a better experience to Rails continous integration and today we can happily announce that
Rails is now testing on Travis CI!

Travis CI is doing a great job in providing multi-ruby testing capabilities and it is dead-simple to use. There’s some great potential to this project and it might change the way we see open-source development and testing quite a bit.

So, if you are publishing any kind of open-source code, library or web application, we recommend you have a look at it. And if you have a spare hour once in a while then consider potentially jumping on board to help improve the code base.

Travis CI is using a separate physical worker server (and a quite beefy one!) for running workers dedicated to Rails builds. This server has kindly been sponsored by the great folks over at Enterprise Rails.

[Guest post by Josh Kaladerimis & Sven Fuchs]

Rails 3.1: Release candidate

As I promised at RailsConf, we’re finally good to go on the Rails 3.1: Release Candidate. This is a fantastically exciting release. We have three new star features and an even greater number of just awesome improvements. First the stars:

The Asset Pipeline
The star feature of 3.1 is the asset pipeline powered by Sprockets 2.0. It makes CSS and JavaScript first-class code citizens and enables proper organization, including use in plugins and engines. See my RailsConf keynote for a full tour. This comes with SCSS as the default for stylesheets and CoffeeScript as the default for JavaScript. Much documentation is on the way for this.

HTTP Streaming
This lets the browser download your stylesheet and javascripts while the server is still generating the response. The result is noticeable faster pages. It’s opt-in and does require support from the web server as well, but the popular combo of nginx and unicorn is ready to take advantage of it. There’s a great Railscast on HTTP streaming and the API documentation is strong too.

jQuery is now the default
We’ve made jQuery the default JavaScript framework that ships with Rails, but it’s silly easy to switch back to Prototype if you fancy. It’s all bundled up in the jquery-rails and prototype-rails gems. Just depend on the one you’d like in the Gemfile and it’ll Just Work.

Other good stuff:

  • Reversible migrations: DRY migrations that know how to revert themselves. Cleaner, nicer migrations.
  • Mountable engines: Engines can now have their own routing and helper scope. They can also take advantage of the asset pipeline (more documentation on this soon). Read the story behind mountable engines (even if the asset stuff is now out of date).
  • Identity Map: It’s not enabled by default because of some important caveats that are still to be ironed out, but if you can deal with those, it’s a great way to cut down on the number of queries your app will trigger. Faster is better!
  • Prepared statements: Active Record now uses cached prepared statements, which is a big boost for PostgreSQL in all cases and a boost for MySQL on complex statements.
  • Rack::Cache on by default: This makes it possible to use HTTP caching with conditional get as a replacement for page caching (which we’ll soon factor into a plugin and remove from core).
  • Turn test-output on Ruby 1.9: Much nicer test output courtesy of the Turn gem. It’s on with new applications by default on Ruby 1.9.
  • Force SSL: It’s now easier than ever to keep your app safe with force_ssl. Either per-app or per-controller.
  • Role-based mass-assignment protection: attr_protected now accepts roles, so it’s easier do deal with admin/non-admin splits and more.
  • has_secure_password: Dead-simple BCrypt-based passwords. Now there’s no excuse not to roll your own authentication scheme.
  • Custom serializers: Serialize objects with JSON or whatever else you’d like.

You can also check out the an even longer changelog and get a video overview from Railscast.

If you’re starting a new application, it’s strongly recommended that you do so using Ruby 1.9.2. Rails will continue to support 1.8.x until Rails 4.0, but it’s considered the legacy option. Ruby 1.9.x is where the action is. Get on board and enjoy the massive speed boost.

You can install the Rails 3.1: Release Candidate with gem install rails --pre. Enjoy and report any release candidate issues on Github. We expect to release the final version in a couple of weeks if all goes well.

Rails 3.1 beta 1 released

We’ve taken our first release step towards the final version of Rails 3.1 today with the unveiling of beta 1. This is a release mostly for people who’ve already been following along with the development of Rails 3.1 and want to try a version that’s close to feature complete.

We do not yet have all the documentation ready, so it’s still a bit of a detective job to figure out how it all fits together. Thus, this is not a general release and I wont hold it against you if you’re holding out for a release candidate (coming in the next few weeks).

The tag is 3.1.0.beta1 and you can install using gem install rails --pre. Enjoy!

Using Bundler Groups on Heroku

Bundler groups are commonly used to specify which dependencies of your application are needed in a given environment. You may have something like this in your Gemfile:

 group :test do
   gem "rspec"
 end

Using the "test" group in this case allows you to specify the gems that are needed to test your application.

Since you won’t need these gems in production, you can speed up installation by ignoring the "test" group. Bundler provides this ability through the --without option:

 bundle install --without test

You can currently access this functionality on Heroku by setting the BUNDLE_WITHOUT config var in your application.

Starting today we are going to default BUNDLE_WITHOUT to "development:test" on all new applications.

If necessary, you can change this value for your application by changing the BUNDLE_WITHOUT config var:

 heroku config:add BUNDLE_WITHOUT="foo:bar"

Existing applications will not be affected by this change to the default. If you have an existing application and would like to take advantage of this feature, simply set the BUNDLE_WITHOUT config var to an appropriate value.

We hope that this new default will help to reduce the deploy time of your Heroku applications. Please give it a try and let us know your thoughts!

Rails 3.0.3: Faster Active Record plus fixes

How about some free speed? Well, here you go. Rails 3.0.3 includes a much faster version of Active Record that reclaims the performance lost when we went from Rails 2.3.x to 3.x and then some. Aaron Patterson has done a phenomenal job benchmarking, tweaking, and tuning the ARel engine that underpins Active Record 3 and the result is Teh Snappy.

You can read more about Aaron’s work in his ARel 2.0 write-up. If you dare, you can also have a look at his RubyConf slides that went over the rewrite and speed-up in even greater detail (warning: there are slides of boys kissing!).

In addition to the free speed, we’ve also included a truckload of minor fixes. So everything just works better and faster. What more can you ask for? Oh, that it’s a drop-in replacement for Rails 3.0—there are no API changes. You got it.

See all the changes on Github. Install the latest version using gem install rails. Or bind yourself to the v3.0.3 tag.

Enjoy!

Note: Active Record 3.0.3 is mistakenly reporting its tiny version as 1 instead of 3. This has no impact on anything you do unless you were specifically checking that tiny version. But if it bothers you lots, it’s fixed on the 3-0-stable branch.

charity:water thanks the Rails community

<iframe src=”http://player.vimeo.com/video/15600111?title=0&byline=0&portrait=0&color=0ead00″ frameborder=”0″ height=”225″ width=”400″></iframe>

Thank you, Ruby on Rails community, from Central African Republic.

We raised almost $40,000. Enough for 1,800 people to get clean water. What an amazing achievement. Thanks to everyone who helped get us there, whether your donation was small or large.

Santiago Pastorino joins Rails Core

It’s my pleasure to announce that Santiago Pastorino has joined the Rails Core group. Santiago only started contributing to Rails this year, but has been on fire ever since his first patches were accepted. He’s managed to rack up 380 commits since the beginning of the year.

Santiago is one of the lead developers and co-founder of WyeWorks from Montevideo, Uruguay. He started working full-time with Ruby and Rails in the middle of 2008 after years of Java development. Since early 2010 he is trying to work full-time on OSS and sporadically writes on his company’s blog.

Congratulations!

Appreciate Rails 3 with charity

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.

Rails 3.0: It’s ready!

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

Read more in the new routing guide.

New Action Mailer
Action Mailer was born with a split-personality of half model, half controller. In Rails 3, we’ve made the choice to make it all controller. This means that the feel and functionality will be much closer to Action Controller and in fact they now share a bunch of underlying code. Here’s a taste of what it looks like now:

class Notifier < ActionMailer::Base
  default :from =>
    "Highrise <system@#{APPLICATION_DOMAIN}>" 

  def new_project(digest, project, person)
    @digest, @project, @person = digest, project, person

    attachments['digest.pdf'] = digest.to_pdf
    attachments['logo.jpg']   = File.read(project.logo_path)

    mail(
      :subject => "Your digest for #{project.name}",
      :to => person.email_address_with_name
    ) do |format|
      format.text { render :text => "Something texty" }
      format.html { render :text => "Something <i>texty</i>" }
    end
  end
end

The new Action Mailer is built on top of the new Mail gem as well. Say goodbye to TMail headaches.

Read more in new Action Mailer guide.

Manage dependencies with Bundler
Managing all the dependencies of a Rails application has long been a hassle of patchworks. We had config.gem, Capistrano externals, custom rake setup tasks, and other incomplete solutions.

Bundler cleans all that up and allows you to specify the libraries, frameworks, and plugins that your application depends on. All Rails 3 applications are born with a Gemfile to control it all. See more on the Bundler site.

XSS protection by default
The internet is a scary place and Rails 3 is watching out for you by default. We’ve had CRSF protection with form signing for a while and SQL-injection protection since the beginning, but Rails 3 ups the anté with XSS protection as well (hat tip to Django for convincing us).

See the Railscast on XSS video and the Dive into Rails 3: Cross-site scripting video for more.

Say goodbye to encoding issues
If you browse the Internet with any frequency, you will likely encounter the � character. This problem is extremely pervasive, and is caused by mixing and matching content with different encodings.

In a system like Rails, content comes from the database, your templates, your source files, and from the user. Ruby 1.9 gives us the raw tools to eliminate these problems, and in combination with Rails 3, � should be a thing of the past in Rails applications. Never struggle with corrupted data pasted by a user from Microsoft Word again!

Active Model: Validations, callbacks, etc for all models
We’ve extracted quite a bit of commonly requested Active Record components into the new Active Model framework. This allows an ORM like Mongoid to use Active Record’s validations, callbacks, serialization, and i18n support.

Additionally, in the rewrite of Action Controller, we removed any direct references to Active Record, defining a clean, simple API that ORMs can implement. If you use an API-compliant ORM (like DataMapper, Sequel, or Mongoid), you will be able to use features like form_for, link_to and redirect_to with objects from those ORMs without any additional work.

Official plugin APIs
We also rewrote Railties with the express goal of using the new plugin API for all Rails frameworks like Active Record and Action Mailer. This means that Rails plugins like the ones for DataMapper and RSpec have access to all of the integration as the built-in support for Active Record and Test::Unit.

The new Railtie API makes it possible to modify the built-in generators, add rake tasks, configure default Rails options, and specify code to run as early, or as late as you need. Rails plugins like Devise were able to add much better integration in the Rails 3 version of their plugin. Expect to see a lot more of that in the months ahead.

Rewritten internals
We rewrote the internals of Action Pack and Railties, making them much more flexible and easier to extend. Instead of a single monolithic ActionController::Base, Rails 3 exposes a number of modules, each with defined APIs, that you can mix and match to create special-purpose controllers for your own use. Both Action Mailer in Rails and the Cells project make heavy use of this new functionality.

You can also take a look a this blog post by Yehuda (from last year) to see how the new architecture makes it easy to implement Django-style generic actions in Rails by leveraging Rack and ActionController::Metal.

The Rails generator system is got a revamp as well. Instead of monolithic generators that know about all of the Rails frameworks, each generator calls a series of hooks, such as :test_framework and :orm, that plugins can register handlers for. This means that generating a scaffold when using rSpec, DataMapper and Haml will generate a scaffold customized for those plugins.

Agnosticism with jQuery, rSpec, and Data Mapper
The rewritten internals and the new plugin APIs have brought true agnosticism to Rails 3 for all components of the framework. Prefer DataMapper to Active Record? No problem. Want to use jQuery instead of Prototype? Go ahead. Eager to test with rSpec instead of test/unit? You got it.

It’s never been easier to Have It Your Way™ with Rails 3. And at the same time, we’ve made that happen without making using the excellent default stack any more complicated.

Documentation
Rails 3 has had a long development cycle and while that might have lead to some impatience, it has also given book and tutorial authors a chance to catch up and be ready. There’s a wealth of great Rails 3 documentation available already and more is coming shortly.

The Agile Web Development with Rails 4th Ed book is almost ready and there are plenty more books coming. Check out all the new guides, the new official videos, new Railscasts, and a new tutorial. See the recent recap of documentation sources for more.

Installation
gem install rails --version 3.0.0.

We also have a Rails v3.0.0 tag and a 3-0-stable branch.

Rails 3.0 has been designed to work with Ruby 1.8.7, Ruby 1.9.2, and JRuby 1.5.2+.

Gratitude and next steps
I’m personally incredibly proud of this release. I’ve been working on Rails for more than 7 years and the quality of the framework we have today is just astounding. This is only possible as a community effort and Rails 3 has seen so many incredible developers step up and help make this our best release ever (wink). Many thanks to all of you.

We’ll continue to develop Rails 3.0 with fixes and tweaks via the stable branch and Rails 3.1 is already cooking on master.

UPDATE: We’re raising money for Charity:Water in the name of Rails 3.0. Please donate and help us bring clean water to 5,000 people in the name of the Rails community.

Rails 3.0: Release candidate 2

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!).

Rails 3.0: Release candidate!

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:

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!!!1

1 Just a few weeks before final is out?

Rails 3.0: Beta 4 now, RC in days

RailsConf 2010 is underway and what better occasion to do the final stage of the Rails 3 beta program. We’re very pleased to announce Rails 3 beta 4, which we’ll be hammering on and tuning during RailsConf.

At the end of RailsConf, we’ll be putting out the release candidate. So if you’re at the conference, and even if you’re not, now is the time to give upgrading a chance or even starting a new app. We’re all responsible for making this release solid, please join the fun.

You can install the latest beta with gem install rails --pre

Since we’re so close to release now, it’s also a great pleasure to introduce the new Rails 3 screencast series by Gregg Pollack and EnvyLabs. They’ve done an awesome job putting together six episodes and more are coming. You can also read along in their great Rails 3 slides from the RailsConf tutorial.

I also gave a keynote on Rails 3 this morning at RailsConf, so you can enjoy the slides.

Let’s race to the finish line together.

Rails 3.0: Third beta release

We’re marching towards the release candidates with hurried steps, but along the way we stopped by for another beta. This one spins out a few overdue extractions into plugins (see http://github.com/rails/verification and http://github.com/rails/dynamic_form), fixes a security issue with cookies, crosses a few t’s and dots a few i’s. Upgrading from beta 2 is recommended.

As always, you can install the latest beta with gem install rails --pre.

We’ll see you again soon for the release candidate.

Rails 3.0: Second beta release

It took longer than we thought, but then again, what doesn’t? This is the second beta release of Rails 3.0 and hopefully our last stop before a release candidate. There are still a handful of known regressions (see the list at the end), but we’ve made huge strides since the last release and so have auxiliary tools like Bundler.

You can find all the detailed changes in the the CHANGELOGs for each framework: Action Mailer, Action Pack, Active Record, Active Resource, Active Model, Active Support, Rails.

Please install beta 2 and try it out with new and existing applications. (gem install rails --prerelease after you make sure you’re on Ruby Gems 1.3.6 with gem update --system).

You can use Jeremy McAnally’s excellent rails_upgrade plugin to take a 2.3.x app to 3.0 (and get his update book too). There are already a good number of Rails 3 applications live in the wild.

Thanks a million to everyone who’s been working on this. Rails 3 is a mighty big barn and it’s been a joy seeing the community come together to raise it.

Note that Ruby 1.8.7 p248 and p249 has marshaling bugs that crash both Rails 2.3.x and Rails 3.0.0. Ruby 1.9.1 outright segfaults on Rails 3.0.0, so if you want to use Rails 3 with 1.9.x, jump on 1.9.2 trunk for smooth sailing.

Known regressions: Rails crashes unless configuration.action_controller.session is set, config.thread_safe does not work, Unable to run a RJS partial from an HTML template, Backtrace silencers oftem remove application lines from test failures backtraces, Active Record double escapes error_messages_for