h1. Rails 3 h2. 5th year 2004-2009 It has been released for 5 years. It's a milestone in terms of how much we've been through. Why are doing mostly the same thing today as we did 5 years today. Stop fretting about whether you are up-to-date with the latest of the greatest. Mortal wounds was supposed to have taken us down according to Slashdot, reddit and so on. h2. Mortal Wounds h3. It wasn't "enterprise ready" It was an intense struggle in these day "You may have noticed that pretty much everyone in the Ruby Camp are insultatns with many of them being book authors attempting to capitalize on hype" - James McGovern My first reaction was to fight it was usuable for enterprise. Rails today is really not that different from 5 years ago. Nothing has changed since then, but we have a lot of enterprisey people coming in. Some arguments just takes time to sink in. When I started talking about REST in 2006 I knew that a lot of people was gonna say that it wasn't relevant. We shouldn't nescessarily always be in such a rush. Don't be disillusioned early on because people don't get your opinion. h3. Cloning Rails, so it is no longer relevant Sails, Biscuit, Grails, Monorail all tried to take the essense of Rails and make Rails irrelevant. There is this one thing we can boil it down to. Most can't be that, Rails can't. It is all about the unique details and sensibility. Realizing this is who we are, we can play a lot more confident. h3. Switch-backs High-profile switch-back: "7 reasons I switched back to PHP after 2 years on Rails" - Derek Sivers, CD Baby Rails no longer fits my needs. Derek proved that there wasn't really anything in Rails. The Rails community again tried to respond with logical arguments. It's okay that we can live with the fact people can change their minds. We can still be friends even though we chose not to use the same tools h3. The fail whale One of my favorite mortal wounds. In the beginning Rails didn't scale. With Twitter it was all coming together. Here we had a service that people loved so much, that it could be down in what seemd like half of the time, and people didn't care. Twitter is a posterboy for Rails. It has some problems, but we can work through this. The internet debate can be a bit shallow, it doesn't really allow people to react. h3. Array.first, second, ... fifth - and 42th h3. Merb Merb was an incredible alternative to Rails in the community for a long time. It wasn't about just one thing. It was the coming-together streams of things we liked. Emotions can run very hot, but the underline technical differences wasn't really that big h3. We are still here We are convening about the same principles as we did 5 years ago. Just because we are still here, just mean we should relax. But take it easy. h2. The philosophy of Rails 3 What really matters is what makes us who we are. It is the fundemental philosophy we all share that is important. h3. Lockup all the unicorns Rails 3 will not solve everyone's problems. In order not to get trapped in Perl6'ism, we can't get free all the unicorns. h3. No holy cows either The Rails group and I made the mistake of talking about fundemental truths, which led to clashes. We are trying to get away from the notion that anything can't be changed. alias_method_chain An example of what could be a holy cow, the way to do metaprogamming. Nothing is holy. If you wan't to break every Rails app with your idea, it is possible. You arguments has to be overvelmely good, but let's get it on the table. h3. Tasty burgers - have it your way If I walk into Burger King an order a Whopper, no questions is asked. But you can ask to get it without pickles. But if I like pickles, do I have to miss pickles because you don't like it? When I first came to the US, I hated the notion of constructionist meal. Most of the time for most of the people, people just want to eat - they'll take the framework as it is. We can allow people to make their invidividual choices and still be in one community. h2. The progress of Rails 3 No alpha release here at RailsConf, but we do have a ton of code already in the repository. h3. New router Faster. Route by subdomains, user agents, more. Route to other Rack machinery. We are taking a lot of the ideas out of the Merb router. Great features, but it is not that much of a driving difference for me. You should be able to mount multiple applications on the same thing. Goes into the spirit of "have it your way". The Rails routing API haven't changed in a long time: controller :sessions do match 'logout', :via => :delete, :>to => :destroy, :as => :logout match 'login' do get :new, :as => :login ... end end Use of instance_eval. I used to not like that (a holy cow), but now it is accepted for e.g. routing. resources :projects, :controller => :project do resources :attachments resources :participants do put :update_all, :on => :collection end resources :companies do resources :people resources :avatar end end h3. XSS protection Another major holy cow revisited for Rails 3. For a very long time the position has been: Yes that it a realy problem for you to deal with. By default nothing is escaped right now, it would be too heavy to do it automatically. I looked through one of my apps recently, and saw a fair number of places where I forgot to use h(). In Rails 3, everything outputted will be escaped by default. You will have to do this to not get it escaped: <%=raw comment.body %> The Django guys did this, and it worked fine. They still produce fine applications. How do you deal with things you don't want to escaped? The helpers will do this automatically. .html_safe! h3. Javascript goes unobtrusive & agnostic There is been a fairly recent development in javascript libs. Unobtrusive JS means you are not putting explicit JS into the code with onclick and so on. Great idea in the theory, but a horrible idea in practice. I had to maintain an external file with dependency. It is going to hurt me to write code like this. But not anymore. link_to_remote currently uses onclick obtrusive javascript. But in Rails 3 we will adopt the HTML 5 attributes: <%= link_to "Delete", @comment, :method => :delete %> Destroy The same thing goes for remove_form_for. But we will cut the notion of whehter it is remote or not. Just use :remote => true. A post delete will just be A generic Javascript will observe all the links with data-remote. There is nothing protetype or jquery specific about usung data-remote. The confirm could be data-confirm="Are you sure?" h3. More agnosticism - Action ORM, Generators E.g. use form_for on a data_mapper or sql object. We will make the generators more agnostic, e.g. so RSpec can tie in. h3. The great refactoring h4. Abstract Controller + Action Dispatch Shared functionaly for ActionMailers and Controllers h4. Action Relation Underpins active ActiveRecord. h3. Cherry picking from Active Support h3. Callbacks are being sped up h3. The real secret to high productivity The genesis of Rails is about productivity. Is about me working on Basecamp 10 hours per week. What were the elements that made me so productive in these early days? One thing that came down to me - one principle that was really key: Renegotiate requirements. Most developers treat requirments is commandments written in stone. Maybe you shouldn't accept this. The productibity gain was not to just accept requirements as they came down. It is a personality flaw of most progremmers to just accepts this. Example: What is the most delicious chocolate I can get? Belgium chocolate, and I have to go all the way down there, and pay 50 bucks for it. Sometimes I will discover I Twix in my pocket, and can be just as good as the Belgium chocolate. The requirements for fine belgium chocolate is what we often get. Giving them a twix now and then is much more productive. As programmers we want to be the puppy who just catches the stick and bring it back. That's wrong.-- h4. 37s example When building Highrise, we needed a requirements system. We wanted belgium chocolate, but the infinite flexible permission system is too hard. I called Jason and said I wasn't gonna do it. "Sure, whatever" - Stakeholders everywhere. The new solution took me 1,5 days after I spend 2 weeks on the complicated solution. The most powerful tool you have to boost your productivity is to renegotiate requirments. "I don't know how" "It's just too hard" "I'd be bored senseless" We want to be the puppy-hero. Motivation peeks very quickly when you accept a requirement that you don't like. h3. Programmer Sounds like a black box. Something that accepts requirements input and out comes program code. But the black box is not a useful metafor. h3. Partner A much better metaphor h1. Questions h2. What happened to lazy browsers? I don't know. I'm not working on that. I don't know how everything works in Rails, so you shouldn't feel bad about not knowing either. Most of it is just faking as we go along. h2. Who approached who in Merb/Rails merger? It came down to a Cuba-missile crisis in the beginning of December. We were considering nuclear war alternatives. But maybe we should just adopt each other? We went into the technical details and realized that we weren't that different at all. h2. Will Rails 3 be to configurable? No, this is very important to me. The default set in Rails will always kick ass. That's why the notion of "Have it you way" is so powerful. Only people who really care should have to make these choices. h2. One project or more at the same time? Best to work serially, task-switching is very harmful to productivity. h2. Backwards-compatibility? Hugely important. But you always have to be open to the possibility of some new idea. Rails 3 will be as backward-compatible as possible.