I'm a guy who lives in San Francisco, Ruby developer. I've been a Ruby developer for about 6 years. I got into it just about when Rails was first publicly announced. It had a lot of hype, I checked it out and I liked what I saw. I was a PHP developer before that and I was glad I got out of that.
2. You work at Engine Yard right now. Why don't you talk about that?
Back when Merb came out as an alternative to Rails, I was interested, because I hit a lot of the specific problems that Merb was trying to solve. I checked it out and I started using it, started contributing back, I got more and more involved in the contribution side, ended up on the core team there writing pretty large chunks. Since Engine Yard was our sponsor in development they saw me and asked if I wanted to work for them and that's how it happened.
3. You were involved in the Rails 3 refactoring. That was a big task, wasn't it?
Yes, it was. We've been at it for about 14 months now, I think, maybe a bit less, more like 12, 12-14 and we're getting really close to release. I'm pretty excited about that. We released one Beta, the second one is coming if it hasn't already been out. I've been online the past couple of days, so the release should be coming out soon.
4. Are there any big changes in the Rails 3?
There are actually quite a significant amount of changes, but most of those are in terms of implementation. We were quite careful about the API that most people use. We only changed it slightly and there was a lot of consideration put into whether or not we would break something. The vast majority of changes are in terms of the configuration of the Rails application so everything in config in the root level. Besides that, a lot of the internals change, there is a lot of refactoring that happened pretty much everywhere.
When I started out, the first thing we tackled was ActionPacks, specifically ActionController. Then we touched ActionView to do a lot of cleaning up in there and refactoring to make it easier for plug-in developers, specifically since Rails has been out for about 6 years now and we have a better idea of what people will want to do with it. We refactored Railties a lot, but we changed the way you would configure an application slightly like we specifically made an Application class.
We cleaned up the initializers, we removed all the ones that were not necessary, we added a way for plug-in authors to hook into the initialization system. We added Bundler which is a way for you to manage your dependencies. There has been a lot of other work that lots of people were working on, ActiveRecord was cleaned up and the query generation stuff was removed and replaced by Arel, which is a relational algebra library.
We added ActiveModel, which it's actually twofold - one is an interface that defines how ActionPack expects to interact with the model because all the view helpers, like respond_with and all those helpers assume it would take a model. Previously it had to be ActiveRecord like an instance of the ActiveRecord class. Now, anybody like the DataMapper or the Sequel guys can implement that interface and Rails will just go along happily in all the view helpers and just output everything that's needed.
5. What was the influence of Merb on Rails 3?
Merb started with a Gist or was it a Pastie back then that Ezra put together. It was about a hundred and some lines, it was a light Ruby framework that sat next to our Rails application and handled file uploads, because back then Rails was intolerantly bad with file uploading. It grew from there and it became a replacement for ActionPack. Specifically when I used Merb I kept my ActiveRecord models with it because I still liked ActiveRecord. It was targeted around trying to build a modular framework, trying to build a light framework. A framework that gave you the Rails experience but when you needed to change something or to tweak something it didn't get in the way. It was trying to define public APIs that plug-in developers could use. It was built with the really light core and all the extra features were built-in modules, kind of like plug-ins into Merb. The Merb community proved that you could get that Rails experience with the modularity and that's when all the Rails developers said "Why don't we just work together on something? We can get the best of both worlds and move forward with the next version of Rails". It made sense to everybody so that's how it happened.
6. Rails 3 is now much more modular than previously. How small can you make Rails 3?
I think Yahuda tweeted this, basically Rails is a kit to make Rails. You can get as small as you want. You start with Rack and everything on top of that is middleware or really light layers. Rails 3 is a lot more modular than Merb ever was, which is great. It's not just Merb and Rails, it's a completely new thing that's much improved. For example, controllers now you have different actions in them and you can get a Rack app for a specific controller action. You don't need to use anything and all the sessions, cookies, basic error handling, basically everything, the router also is just middleware. You could, just for example if you like the Rails router, you can only use that. There is ActionDispatch inside of ActionPack, which is a collection of all these middleware and everything that's Rack related. You don't have to use ActiveRecord with ActiveModel, which is an API that defines that interface that Rails has. With models you can use anything else - you can use DataMapper, Sequel, custom, build ones, whatever. You can get it as small or as big as you like.
Right now Rails Metal is the base class of ActionController::Base. The way we broke it up is that you have AbstractController, which is a whole other thing, all AbstractController does is handling dispatch into a specific action. Then we have ActionController::Metal, which inherits from ActionController::Base and all it does is add the Rack element to action dispatching. If you want to use Metal right now, you just make a class inherit from Metal, define your action and that's all you have. Then, you just hook it up to the router and you don't have access to rendering callbacks, anything. It's basically 2 method calls on top of just Rack and it lets you write really light Rack apps in one class with the action dispatching features.
If you're new, basically you would start exactly the same place you would with Rails 2. you check out whatever tutorial, you'd install the Rails gem, you would do 'rails my_app', you would generate all the scaffolding for you, not controller scaffolding, just the Rails application scaffolding. You would then generate controller, it would look exactly the same. On that respect, nothing has changed.
9. You mentioned the work on Arel. What is that?
Arel is object oriented implementation of relational algebra that was done by Nick Kallen who works at Twitter right now, he also did NamedScope in ActiveRecord. What it really is, it's a way for you to build your relations, which are kind of like the queries in SQL in a really nice API and then you just tell ActiveRecord "Give me the records for this query" and it would then say "Ask Arel, here is the relation I built for you, now please give me the rows back." Arel will then generate the SQL for it in a really much better way than it used to do as it has the full tree that is the query that you want to build. It would build a SQL, execute it, get you back the records so all ActiveRecord will do right now is ask for rows to Arel, get them back and instantiate the models for you. It's a much better way to generate SQL and the main thing about Arel is that it's the relational model not SQL. You can take anything that's relational data and write an Arel engine for it and Arel will be able to handle that, write queries for that.
10. You mentioned some example backends for Arel.
Specifically what I was playing around with since I work at Engine Yard, our main product is built on Amazon's EC2 infrastructure. EC2 has a REST interface to handle everything and it really is relational data because you have AMIs which are the operating systems. The AMIs have many instances that are your running servers, the instances have many volumes that are mounted to it. All these relationships are just relational algebra. I started playing around with implementing an Arel engine that takes the query that I want and converts it to a bunch of API calls and returns that data. Eventually, ActiveRecord should not see any difference between that and SQL. We're not quite there yet, because it's a large refactoring work that's not 100% done, but that's my goal in 3.1, to work on cleaning up the interface between ActiveRecord and Arel. I'd like to add, if you are just using plain Arel, which also has it's own API, you can do that right now.
11. I think you worked on Bundler. What is Bundler about?
Bundler is something that Yehuda and I worked a lot on. It started with a little bunch of Thor tasks that were in Merb and were meant to manage the dependencies that your application has. It's basically dependency management. Before, what you did was install your gem files directly to Ruby gems and then you just required them, there's no main way to do that. Then Rails, in 2.2 or 2.3 (I don't remember the specific version they added it), had a way in your config files that you config.gem to find your dependencies in an Rake task, but all that did was loop through the gems and install them. What Bundler does is it takes the entire gem sets and it resolves the full dependency graph then. Doing that, avoids the gem activation problem that's been plaguing Ruby ever since gems became popular. Also, it gives you a bunch of commands that manage locking your dependency graph to a specific version. Generally, it just tries to make dependencies sane. That's why, whenever you deploy, it'll reproducibly deploy every time.