Migration/upgrades

Migrating a Rails App from a version to the other is very much like playing the lottery, you are almost sure you will lose. To be more correct, you know things will break, you just don’t know what, when and how. The Rails team seems to think that everybody is always running on the cutting edge version and don’t consider people who prefer to stay a few version behind for stability reasons. What’s worse is that plugins/gems might or might not compatible with the version you are updating to, but you will only know that by trying yourself and letting others try and report potential issues.

This is for me, by far, the biggest issue with Rails and something that should have been fixed a long time ago. If you’re using the WordPress blog engine, you know how easy and safe it is to upgrade the engine or the plugins. Granted WordPress isn’t a web dev framework, but it gives you an idea of what kind of experience we should be striving for.

Stability vs playground zone

New features are cool and they help make the platform more appealing to new comers. They also help shape the future of a framework. But from my perspective, that shouldn’t come to the cost of stability. Rails 3′s new asset pipeline is a good example of a half-baked solution shoved in a release at the last minute and creating a nightmare for a lot of us trying to upgrade. I know, I know, you can turn off the asset pipeline and it got better since it was first released. But shouldn’t that be the other way around? Shouldn’t fun new ideas risking the stability of an app or making migration harder, be off by default and turned on only by people wanting to experiment? When your framework is young, it’s normal that you move fast and sometimes break, but once it matures, these things shouldn’t happen.

Public/private/plugin APIs

This is more of a recommendation than anything else. When you write a framework in a very dynamic language like Ruby, people will “monkey patch” your code to inject features. Sometimes it is due to software design challenges, sometimes it’s because people don’t know better. However,  by not explicitly specifying what APIs are private (they can change at anytime, don’t touch), what APIs are public (stable, will be slowly deprecated when they need to be changed) and which ones are for plugin devs only (APIs meant for instrumentation, extension etc..), you are making migration to newer versions much harder. You see, if you have a small, clean public API, then it’s easy to see what could break, warn developers and avoid migration nightmares. However, you need to start doing that early on in your project, otherwise you will end up like Rails where all code can potentially change anytime.

Rails/Merb merge was a mistake

This is my personal opinion and well, feel free to disagree, nobody will ever be able to know to for sure. Without explaining what happened behind closed doors and the various personal motivations, looking at the end result, I agree with the group of people thinking that the merge didn’t turn up to be a good thing. For me, Rails 3 isn’t significantly better than Rails 2 and it took forever to be released. You still can’t really run a mini Rails stack like promised. I did hear that Strobe (company who was hiring Carl Lerche, Yehuda Katz and contracted Jose Valim) used to have an ActionPack based, mini stack but it was never released and apparently only Rails core members really knew what was going on there. Performance in vanilla Rails 3 are only now getting close to what you had with Rails 2 (and therefore far from the perf you were getting with Merb). Thread-safety is still OFF by default meaning that by default your app uses a giant lock only allowing a process to handle 1 request at a time. For me, the flexibility and performance focus of Merb were mainly lost in the merge with Rails. (Granted, some important things such as ActiveModel, cleaner internals and others have made their way into Rails 3)

But what’s worse than everything listed so far is that the lack of competition and the internal rewrites made Rails lose its headstart.  Rails is very much HTML/view focused, its primarily strength is to make server side views trivial and it does an amazing job at that. But let’s be honest, that’s not the future for web dev. The future is more and more logic pushed to run on the client side (in JS) and the server side being used as an API serving data for the view layer. I’m sorry but adding support for CoffeeScript doesn’t really do much to making Rails evolve ahead of what it currently is. Don’t get me wrong, I’m a big fan of CoffeeScript, that said I still find that Rails is far from being optimized to developer web APIs in Rails. You can certainly do it, but you are basically using a tool that wasn’t designed to write APIs and you pay the overhead for that. If there is one thing I wish Rails will get better at is to make writing pure web APIs better (thankfully there is Sinatra). But at the end of the day, I think that two projects with different philosophies and different approaches are really hard to merge, especially in the open source world. I wouldn’t go as far as saying like others that Rails lost its sexiness to node.js because of the wasted time, but I do think that things would have been better for all if that didn’t happen. However, I also have to admit that I’m not sure how much of a big deal that is. I prefer to leave the past behind, learn from my own mistake and move on.

Technical debts

Here I’d like to stop to give a huge props to Aaron “@tenderlove” Patterson, the man who’s actively working to reduce the technical debts in the Rails code base. This is a really hard job and definitely not a very glamorous one. He’s been working on various parts of Rails including its router and its ORM (ActiveRecord). Technical debts are unfortunately normal in most project, but sometimes they are overwhelming to the point that nobody dares touching the code base to clean it up. This is a hard problem, especially when projects move fast like Rails did. But looking back, I think that you want to start tackling technical debts on the side as you move on so you avoid getting to the point that you need a hero to come up and clean the piled errors made in the past. But don’t pause your entire project to clean things up otherwise you will lose market, momentum and excitement. I feel that this is also very much true for any legacy project you might pick up as a developer.

Keep the cost of entry level low

Getting started with Rails used to be easier. This can obviously argued since it’s very subjective, but from my perspective I think we forgot where we come from and we involuntary expect new comers to come with unrealistic knowledge. Sure, Rails does much more than it used to do, but it’s also much harder to get started. I’m not going to argue how harder  it is now or why we got there. Let’s just keep in mind that it is a critical thing that should always be re-evaluated. Sure, it’s harder when you have an open source project, but it’s also up to the leadership to show that they care and to encourage and mentor volunteers to  focus on this important part of a project.

Documentation

Rails documentation isn’t bad, but it’s far from being great. Documentation certainly isn’t one of the Ruby’s community strength, especially compared with the Python community, but what saddens me is to see the state of the official documentation which, should, in theory be the reference. Note that the Rails guides are usually well written and provide value, but they too often seem too light and not useful when you try to do something not totally basic (for instance use an ActiveModel compliant object). That’s probably why most people don’t refer to them or don’t spend too much time there. I’m not trying to blame anyone there. I think that the people who contributed theses guides did an amazing job, but if you want to build a strong and easy to access community, great documentation is key. Look at the Django documentation as a good example. That said, I also need to acknowledge the amazing job done by many community members such as Ryan Bates and Michael Hartl consistently providing high value external documentation via the railscasts and the intro to Rails tutorial available for free.

In conclusion, I think that there is a lot to learn from Rails, lots of great things as well as lots of things you would want to avoid. We can certainly argue on Hacker News or via comments about whether or not I’m right about Rails failures, my point will still be that the mentioned issues should be avoided in any projects, Rails here is just an example. Many of these issues are currently being addressed by the Rails team but wouldn’t it be great if new projects learn from older ones and avoid making the same mistakes? So what other mistakes do you think I forgot to mention and that one should be very careful of avoiding?

Updates:

1. Rails 4 had an API centric app generator but it was quickly reverted and will live as gem until it’s mature enough.
2. Rails 4 improved the ActiveModel API to be simpler to get started with. See this blog post for more info.

One of the many things I like with Couch is that it handles attachments and can replicate them as well as serve them for you using the Erlang based builtin webserver. (you can load balance your dbs and do some other really cool stuff)

Let’s take a use case. Let’s imagine that you have a web app with logged in users. Every user can have their own avatar.

No big deal, you get the user to upload his/her avatar to your app and add it to the user document in the database. To serve it from the database, you just need to create a proxy in nginx/apache and redirect the virtual avatar url to the protected DB making sure the request is a GET request.

Add to that a caching solution like varnish or memcached module for nginx and all your db goodies get cached and served by the cache (server/client) until they get modified.

Now, the problem is when you want to serve authorized attachments. Let’s imagine that we want to let our users upload private files, files that should be accessible only by the owner or users designated by the owner.

In this case, a simple nginx rewrite wouldn’t work. We need to authorize attachment requests. Here is a cool way of doing that using nginx and merb’s router. (Expect Rails3 router to do the same).

Let’s start by setting up nginx and create a proxy for couchdb:

Now that this is done, we are going to use Merb’s awesome router to handle the incoming requests. The cool part of this is that we won’t be dispatching requests so, going through the router is almost free. (check on the Merb router benchmarks for more info). Let’s edit our router and set a special route for our assets.

We are using a deferred route which gets executed instead of dispatching the request.

If the attachment route is being matched then we are checking what environment we are currently running in. If we are in production or staging environment then we are sending back a rack response to the webserver. The response is just a forward to the proper couchdb document behind the proxy. Of course, before allowing that to happen, we could authenticate the logged in user, log the request and do a couple of other things. You have full access to your models from the router, so authenticating a session isn’t a big deal. You could even create temporarily urls like AWS s3 does.

If we are not in production or staging mode, then just redirect the request to couch since we assume you have access to the local db. This way, your asset urls will be working in production and dev. In real life, you’ll want to apply the authorization before choosing how to deliver the document/attachment tho as you want it work the same way in development and production.

It was encouraging to see so many people excited about what’s being ported over from Merb and the new options available to people who are currently limited by the existing stack. For those interested in pushing Rails further and doing stuff out of the norm, here are my slides. Arthur Zapparoli from Brazilian Rails squad recorded most of the talk and told me he will upload the video ASAP. You can also read Yehuda Katz’ blog which covers what he talked about.

It was really great to meet a lot of new people as well as people I only knew via IRC/IM/twitter.

It was a great honor to finally meet Dan Kubb (DataMapper), Ninh Hernandez-Búi & Hongli McLovin Lai (Phusion), Peter Cooper (RubyInside), Raimonds Simanovskis (Oracle adapter for AR), Arun Gupta (Sun/Glassfish),  Jeremy Hinegardner (crate), Michael Maxilien (IBM), Dana Jones (railsbridge), Zach Zolton & Geoff Buesing (CouchRest) and of course the Brazilian crew (lots of awesome .br guys came this year, I’m looking forward to RailsSummit) and last but not least, the French speaking crew (I’m glad to see Ruby is picking up back home). (I know I’m forgetting people… sorry about that)

It was also really nice to talk with some experts like Dave Astels, Aslak Hellesøy, Rich Kilmer, David Chelimsky, Ryan Brown, Derek Neighbors etc.. to get their feedback on various projects I’m working on.

Leaving Vegas, I feel like the Rails community is expanding quickly (it was the first RailsConf for 1/4 to 1/5 of the attendees) and that the community is organizing itself to welcome a new audience (better documentation, great initiatives like railsbridge.org, willingness to help), as well as trying to be more available to the ‘Enterprise’ world.

These feelings were enforced during our Rails Activism BOF and after talking with 3rd party developers and sponsors really trying to solve problems that newcomers to Rails are now facing. This is an exciting time.

Merb::Config[:max_memory] has been fixed and now polls for memory usage every 30s instead of 0.25s. (memory is set in KB)

This new version also uses DataMapper.repository instead of Kernel#repository (DM and Vlad related bug fix)

We are still on schedule for Merb 1.1 which is planned for early April. (If you install Merb from our edge server, the latest version should already be Ruby 1.9 compatible)

Key items on the agenda were:

• Ruby 1.9
• Mountable apps
• migration path to Rails3

After spending some time arguing back and forth, we decided that few things had to happen before we could migrate the current slices to pure mountable apps. Freezing the releases while waiting to get that done doesn’t seem like a good idea.

Therefore, here is the plan for Merb 1.1:

• Ruby 1.9 full compatibility (with the very appreciated help from Maiha and Genki (preview of their work there)). Because Merb depends on different gems, we also need to work with 3rd party developers to make sure Merb’s dependencies are Ruby 1.9 compatible

• Merb helpers (fixes, enhancement and missing helpers)

• Make Merb controllers, rack endpoints. This is a fully transparent change for the framework users. By making this switch, we offer more flexibility to the router (you can mount a sinatra app for instance) and we adopt the same approach as Rails 2.3 making the transition to 3 much easier and facilitating the implementation of mountable apps. Again, this is an internal change and you won’t have to change anything in your application.

• Router optimization, Carl has been working on few tricks/optimizations for the router that will be available in 1.1

• Namespacing. If we want to make every single application, a potential mountable app, we need to namespace our applications. This is something we already do with slices, but currently generated applications are not namespaced. We are planning on doing that for 1.1 (backward compatible) to make mountable apps easier.

• ActiveORM. ActiveORM is an ORM abstraction layer developed by Lori Holden (AT&T interactive) which helps with helpers and other parts of your code accessing your ORM directly. For instance, the errors_for method need to be implemented differently depending on the underlying ORM. ActiveORM offers mapping for the 3 major Ruby ORMs: ActiveRecord, DataMapper and Sequel but let you hook to it if you want to extend ActiveORM to support your own ORM.

There is plenty to do but we decided to still try to have an expected release date: around the end of March. As always in the OSS world, this is something we hope for, not a promise

What about Merb 1.2?

1.2 will focus on mountable apps and we hope to get started on a separate branch before we release 1.1. However, mountable apps are hard to spec and we need a better feedback from the community. Tell us what you like with slices and what you don’t like. Let us know how you would like the new mountable apps to work. Be as precise as possible. (you can leave a comment here or on the mailing list)

However, today is a special Monday. It’s the first Monday of the year and I have a special announcement!

During the Rails/Merb merge announcement, it was mentioned that I will be joining the soon to be created “Evangelism team”.

A few people asked me what being a “Rails Evangelist” means. To reassure my parents and close friends, no, I didn’t join a new cult worshiping locomotives. However, I still think that public transportation should be improved, especially in this time of crisis (but that’s a different topic).

A technical evangelist, is usually someone who knows and uses a specific technology and thinks others should look into it. This is something I’ve been doing for Merb while being part of the core team. I initiated and helped organizing MerbCamp, re-did the wiki, started working on the merb-book, spent time looking for and listening to users, spent time with third party developers and people pushing Merb to a new level (YellowPages, Wikimedia and many others).

This interaction with the end users and the third party developers is something the entire Merb team valued a great deal and I always felt it was something the community really appreciated.

As part of the merge, it was agreed that we would push things further and have a team within the Rails team to take care of “communication”. Rails is a bigger project than Merb and communication between the dev team and the users isn’t always something easy to do.

That’s why we have formed a separate team that will help communicate and support the community better. We now even have an official page on the Rails website itself

The Rails Activists

The A-Team just got announced on the Rails blog.

Instead of being called “evangelists”, we are going to be called “activists”. I think part of the argument was that the E-Team doesn’t sound as good as the A-Team.

We started with team of 4. You might not know them yet but they all are brilliant people and I’m really glad to be working with them.

Gregg Pollack, from Rails Envy. You might remember Gregg from the Rails vs * commercials or from the Rails Envy podcasts. I’ve known Gregg for a little while and he’s someone you can rely on and always full of energy/new ideas.

Ryan Bates, mainly known for his Railscasts. I only met Ryan once in person, but I’ve always been impressed by his work (don’t tell anyone, but I secretly dreamt of having something like Railscasts but for Merb )

Mike Gunderloy. I actually did not know Mike but I have read and enjoyed his blog and have seen his work on the Rails guides. Mike is an experienced writer and developer. He joked the other day saying that he started programming before any member of the Rails team was even born. Mike is a great addition to the team and I’m looking forward to learning from his experience.

Gregg and Ryan also covered the event, you might want to check their blog posts (Gregg’s and Mike’s)

So what are we going to do?

Pretty simple. We’ve boiled it down to 2 sentences:

The mission of the Rails Activists is to empower and support the worldwide network of Ruby on Rails users. We do this by publicizing Rails, making adoption easier, and enhancing developer support.

if you prefer a few more details, here are some of the tasks we are going to work on:

• Public Relations with media of all sizes
• Ombudsman work to ensure good user-to-user support
• Community Leadership at events and conferences
• Media Organization to help create good promotional opportunities
• Website maintenance
• Documentation efforts
• Developer support

Do we need help?

Absolutely! The idea is not that we are going to do all the work. The concept of this new team is to help organize the community. We are going to build a Rails Network, a network of people involved in local Rails “evangelism”/activism, people contributing and/or translating documentation, third part developers etc…

First thing would be to join the mailing list and share your suggestions, comments, concerns, etc., with us.

Secondly, we have already set up some forums to hear your feedback.

To start off, we are asking people to let us know what they would like to see happening in the Rails3 timeframe.
We have other forums for more general feedback, but we need to work with deadlines so we can prioritize accordingly. Using the Rails3 milestone should help us focus on a short/medium term deadline. Long term and not specific suggestions are welcome in the other forums.

Finally, contact us. You can find multiple ways to do so on the activism team web page.

• Foy Savas, author or the “merb way” wrote a very well written post on “Rails monoculture”
• Pat Eyler, wrote an article asking if Rails and Merb would be better together.
• Ben Aldred, tell people to stop worrying and start loving Rails 3.
• fotonauts.com a Rails and Merb Photo website developed by an ex-apple team, was featured in TechCrunch. Fotonauts is the perfect example of an app that will bain a lot from the merge.
• Yehuda has been blogging a lot about every single step and even though most people are enjoying a well deserved break, you can read the details of the work started on the merge.

Basically, the work started, we are getting familiar with the rails code base and are optimizing things slowly but surely with a focus on testing JRuby. The Merb router is being optimized and ported over to Rails 3.0. Rails and Merb developers will be able to stick to their DSL (so we stay backward compatible). Merb bootloader is also being ported over without breaking the backward compatibility. Finally, ActiveSupport is being broken down in more manageable/independant chunks so people will be able to pick only what they want to use. A “mini” version is also on the work.

• Merb 1.0.7 got released yesterday with a bunch of bug fixes.
• merb_sequel 1.0 should be released sometime this week and i’m planning on adding rails i18n syntax support to merb_babel.

Overall, the news was very well received, just look at the tweets out there and the comments on Yehuda’s and Rails’ blogs.

Interestingly enough, the Rails community really embraced this decision and just got totally excited about the perspective of merging merb’s philosophy and expertise into Rails. If you re-read David’s blog post you can see that it’s a real homage to Merb.

The rest of the internet sounds pretty happy about the news, here are few posts:

• arstechnica.com
• internetnews

Even Zed the entertainer thought it was a good thing:

“I honestly didn’t think that would ever happen. I just assumed that Merb
would eventually wipe out Rails by being the better framework, or they’d
wipe each other out soon.

So, congrats are in order. You guys are finally grown-ups and now have
the chance to make something better.”

Some merbists like Jade Meskill really understood what we are trying to do while some other ones got really mad at us.

I think a pattern emerged from the negative reactions:

• Why merge when we are about to win?!
• What does Merb win by being merged into Rails?
• Why not merge Rails into Merb?
• You are killing innovation by killing the competition
• You screwed us over and now I have to go “back” to Rails
• Rails 3.0 won’t even be as good as Merb 1.x
• The Rails team won’t let you do what you have to do to merge Merb into Rails
• DHH is a jerk

Let me quote Yehuda:  “Calm yourselves ”.

Why merge when we are about to win?!

This is probably the most rational argument. This is also something the Merb core team considered for a little bit.
Merb is gaining huge momentum and the target audience was very reactive to what we did.
People such as Yellow Pages, Wikipedia and even Adobe started using or looking seriously at Merb because of its focus on modularity and performance.
We started building an elite community and we were pretty proud of that.

But take a moment to think about it. Our goal has never been to hurt or compete with Rails. Our goals were to get modularity, performance and a strong API. If the Rails team really wants that, and will work on it, why should we work against each other?
It’s not about winning or losing. It’s all about the long term plan of your framework, about the people involved and the community behind it. We had to take ourselves out of the equation and consider what would be good for the Ruby community.

What does Merb win by being merged into Rails?

People seem to easily find things we might lose but have a hard time finding things we are gaining.
Looking at it on the very short term, this is probably correct. The merb team will have to learn how to work with the Rails team.
We need to understand the reasons behind every single aspect of the code and find ways of merging things nicely.
On top of that, we still need to work on merb as promised. (see Wycats’ post)

However, in the long term we get all the benefits of Rails:
- stability
- community
- traction
- experience
- don’t have to always justify why use Merb instead of Rails

But more importantly, we extend our team.

Most people using a framework might not realize what it is to work on a big Open Source project.
When you work on an OSS project, people come and go, and that’s why you usually have a core team of people you can rely on.
Merb has a lot of contributors but a small core team of 5 people (Yehuda, Carl, Daniel, Michael and myself).
Managing a project, such as merb, requires a tremendous amount of time and patience. Rails has the same problem with its core team of 6 people. People have lives, business, projects etc…

Joining two teams of experts in developing web frameworks in Ruby is like if in the next Soccer World Cup, the French and Italian teams would go on the fields at the same time to beat other teams. 22 players on 1 side, training and learning together. American readers, please imagine the Giants and the Colts facing the Green Bay Packers (I was told I don’t like the Packers).

Long term, you will get better quality and more frequent releases. We also have different world views and backgrounds which means we will learn a lot from each other, again that means better code for you guys

Why not merge Rails into Merb?

That’s actually a good question. We discussed maybe using merb-core as a base for Rails 3.0
The truth is that Merb 2.0 would probably be as big as Rails but more modular.
So we have the choice to keep on building on top of Merb 2.0 or deconstruct Rails.
As the Russians say: ‘ломать — не строить’, it’s always easier to take things apart

Rails already has a test suite, it has already been tested on the wild for a while and its internals are known to many developers. Taking apart the code to make it faster, cleaner and more modular is arguably easier than reinventing the wheel. At the end of the day it doesn’t really matter from which end you start as long as you end up with the same result.

Some people even asked to come up with a new name for the merged project. Meails, Mr Ails, Reverb, Reab were suggested. While I thought it was a joke, some people were really serious. Can you imagine if during the recent bailout, banks changed names every time they were purchased by another bank? People would be super confused and would not even know where to send their mortgage payments.
On top of that, Rails has a huge user base compared to Merb and has an immense brand recognition in the world at large, it would be foolish to throw that away.

Let’s not be chauvinistic and see what’s best for all.

You are killing innovation by killing the competition

Again, a good point but my question to you is: Should we stay in the competition just for the sake of it?

Rails clearly told us: we want what you have and we would love you to work with us. So the options were:

• tell them to go to hell and let them try to redo what we already did and know how to do.
• accept to work with them and make Rails a better framework.

Option 1 would keep the competition alive, but now you have 2 groups of people trying to do the same thing and being better at different aspects. The community gets confused and communication breaks.

Option 2: we lose the Merb vs Rails competition, but we double the amount of people working on Rails and therefore increase the change to make it better faster.

We went for option 2 and we know there is already some competition out there and there will be more coming up soon. I don’t think it’s realistic to expect us not to merge because we want to keep the competition going.

You screwed us over and now I have to go “back” to Rails

Yehuda will blog about some more detailed examples as we are making progress, but you need to stop thinking that Merb will just be absorbed into Rails.
If Rails just wanted to add some “Merb flavor” to Rails, they would have just taken whatever they needed and would not be interested in a merge.
See Rails 3.0 as a new generation of Rails, whatever we promised you for merb 2.0 plus all the goodies from Rails. Rails users will still have their default stack and all choices will be made for them (like in the current Merb stack). The difference for standard Rails user will be better performance, a static API and an option to go off the “golden path”.
Merbists won’t lose the stuff they like in Merb, stacks, full support for DataMapper, Sequel and other ORMS, jQuery or other JS library, opt-in solution using just rails-core, better core isolation, built-in RSpec and webrat support, slices, merb-cache, merb-auth and all the other key plugins that will be ported over.

To be able to achieve all of that, we will have to make some infrastructure and code modifications.

Rails internals should end up:

* way less magical (even Merb uses some magic, but we’ll make sure to keep it to a minimum)
* returning shorter and cleaner stack traces
* cleaner (required for the new API)
* better isolated (required to increase the modularity)
* alias_method_chain won’t be available at the public API level (we probably still will need some chaining mechanism internally, but that’s a different story)

So, no, you don’t have to go “back” to Rails. In fact, imagine you could do exactly what Rails does but with the performance and modular architecture of Merb. That’s what you will get with Rails 3.0.

Rails 3.0 won’t even be as good as Merb 1.x

I think I mainly replied to this question in my previous answer.
There is no reason why Rails 3.0 won’t be better than Merb 1.x.  Actually, I believe our API will actually be even better. With the help of David, the existing Rails core team, and the Rails community, we will be able to define an awesome API that will change the way ruby web development will be done.
The merb API is great but we already know some of its limitations and we don’t have as many plugin developers to work with. Working with plugin developers is something I’m personally excited about. As a Rails developer I have been really frustrated when using 3rd party plugins and trying to develop my own.
Having a well tested, developed against, public API will make all the Rails 3.0 plugins so much better. And because Merb plugins already use an API, we will be able to port all the plugins over, so it will be at least as good as 1.x
Also, we are going to work on real app benchmark tests to make sure the performance gain is at least as good as what we have with Merb.

Migration will be easy and well documented. We are not giving up on the Merb book and it will be very useful to explain the Merb way to new comers wanting an idea of the new stuff in Rails 3.0. It will also be the best source of information to migrate your app to Rails 3.0.

Talking about migration, we promised to give you a sane migration path when it will be time to migrate.
Again, don’t freak out because we are changing the name, the spirit of Merb will keep on living.

The Rails team won’t let you do what you have to do to merge Merb into Rails

In all honestly, I was worried about that. I was wondering if all of that was not an evil scam planned by DHH to kill Merb as it was getting a good momentum. I like conspiracy theories and it sounded pretty good.
To my surprised, after a few private conversations with David, I realized that he was genuinely interested in making Rails better for people and fulfill the needs of people who need more flexibility.
Just re-read his blog post http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3. After what he said, how can he back up and just keep Rails the way it is? And why in the world would he want that to happen?
It’s a team effort and we have already spent hours and hours discussing some details. I can promise you that the Rails team is very excited about the new stuff that’s coming up. But don’t forget that it’s a merge and we are reconsidering some of the stuff we did in Merb to better re-implement them in Rails 3.0.
So far, I haven’t seen any of the Rails core team member tell us, no you can’t do that because that’s not the way it’s done in Rails or because we just don’t like it.

DHH is a jerk

Recently, in an interview I gave to rubylearning.com http://rubylearning.com/blog/2008/12/18/matt-aimonetti-why-on-earth-would-you-ignore-merb/ I mentioned that a big difference between Merb and Rails was the way we were dealing with the user base.
I quoted David from an Interview he gave to InfoQ http://www.infoq.com/interviews/David-Hansson back in 2006.

As part of the merging evaluation process we literally spent hours talking back and forth. I had a seriously hard time believing that Rails and David honestly wanted to change their world views. How can you go from saying what you said in 2006 to adopting what Merb is pushing for: letting the framework bend to make what each developer wants if he doesn’t want to follow the “golden path”?

Interestingly enough, David recently addressed this point on his blog. http://www.loudthinking.com/posts/36-work-on-what-you-use-and-share-the-rest

“I wanted to take a few minutes to address some concerns of the last 4%. The people who feel like this might not be such a good idea. And in particular, the people who feel like it might not be such a good idea because of various things that I’ve said or done over the years.”

First thing first, David addresses the minority of people worried about his image and what it means for them.
So, David actually cares about hard core merbists and he wants them to join the fun. I personally see this as something very encouraging!

A recurring theme we hear a lot is that Rails becomes whatever DHH/37signals needs/wants. If DHH needs something new, it will make it to Rails, if he doesn’t need it, it won’t.

David has a very simple and almost shocking response: DHH != Rails

David is really happy with Rails. Rails satisfies his needs but he knows that some people out there need/want something more/different.

“I personally use all of those default choices, so do many other Rails programmers. The vanilla ride is a great one and it’ll remain a great one. But that doesn’t mean it has to be the only one. There are lots of reasons why someone might want to use Data Mapper or Sequel instead of Active Record. I won’t think of them any less because they do. In fact, I believe Rails should have open arms to such alternatives.”

So, you can still think whatever you want about David. What’s important is that Rails is more than David. It’s an entire team of people with different needs and different views.

DHH isn’t a dictator and based on concrete examples such as the “respond_to vs provides” discussion, I can reassure you that David has been very receptive to arguments and never tried to force any decision because he thought it was better.

While people still try to find some drama in a hypothetical war between Rails and merb …

The Rails team and the Merb team announced today that they will work together on a joined version of the 2 frameworks. This is so exciting! Nobody believed it could ever happen (I personally, seriously had my doubt).

Yehuda had a great post laying out the plan and explaining things in details. Check out David’s post explaining why he wants us to work together and his vision of a better Ruby world.

I have to say that I have been impressed by the Rails core team and especially David (DHH).

I’ve known David for few years now and we had long (sometimes heated) discussions on topics like i18n/l10n for Rails. David is known to be a very opinionated person. But if you come up with the right arguments, he can be convinced and when that happens, he is willing to move forward and shake things up.

This merge is a concrete example that David and the rest of the Rails team care about Rails and the Ruby community more than we usually give them credit for. As a unified team, we are going to change the way web development in Ruby is done!

But what does it mean for you?

I put together a FAQ video which, I hope will answer your questions.

Matt Aimonetti: message to all merbists

Transcript:

Hi, I’m Matt Aimonetti from the merb core team and as you might have heard, a big announcement was made earlier today.
I did this video to hopefully answer the questions you might have.

Q: So what’s the big news?

• merb and Rails team will work together on the next version of their frameworks
• merb 2.0 and Rails 3.0 share the same common endpoint
• we realized we now have the same objectives and agreed on all the key principles.
• merb will provide Rails with agnosticism, modularity, improved performance and a public API.
• The end product will be called Rails 3.0 but what real matters is that it’s a huge gain for the entire community.

Q: What??? I thought there was a war going on between Rails and merb, what happened?

• There was no war between Rails and merb
• We created merb because Rails was not fitting us
• We wanted better performance, more choices/ more modularity and a Public API.
• The Rails team now embraces these concepts and want Rails to follow them, so why not work together?

Q: Wait, does that mean that merb is dead?

• Absolutely not!
• merb development won’t stop, we are going to keep on releasing updates until Rails 3.0
• clear migration path, and upgrading to Rails 3.0 will be as trivial as upgrading from Rails 2.x to Rails 3.0

Q: What does the timeline look like?

We just started getting together to discuss the technical details. We are shooting for a release at RailsConf 2009. However it’s hard to estimate this kind of thing so, again, that’s just an estimate

Q: I just started a merb project, so what now?

I’m sure you had valid reasons to use merb, you needed modularity, performance and a solid API.
Keep on using Merb, we won’t let you down. The good news is that the next version of merb (Rails 3.0) will be even awesomer!

Q: What about my client who was looking at using merb for his new project?

If your client is going to be using merb for valid reasons (and not just because it’s not Rails) they should still use merb, but with the full understanding that they will end up using Rails in 6 months or so. Again, Rails 3.0 will have what pushed you to use merb.

Q: I’ve been involved with the merb-book, what will happen with this project?

• Rails 3.0 won’t get released right away
• still need awesome documentation
• if we look at Rails 3.0 as merb 2.0, we can easily imagine how the current work can be extended to the new version
• Rails team will also include an evangelism team which I will be part of, so will be able to focus more on projects like the book

Q: I’ve been working on a merb plugin, what should I do?

Keep working on it! We’ll assist you with the migration process and the new solid API.

Q: What if I still have questions?

Come talk with me, or any member of the new team. We’ll be open to hear your questions, worries, frustrations.
merb always valued its developers and we will continue to do so but on a bigger scale.

Lori Holden worked on merb_sequel and we should release a 1.0 release of the plugin in a few days.

I’m sure this news comes as a shock for many of you, but try to not see Rails 3.0 as the way Rails is right now. Imagine a version of Rails with true modularity and agnosticism (sequel, DM and AR will still be supported) and the same type of performance as what you get with merb. In other words, the Rails world is about to discover the power of merb!

Here is what Yehuda explicitly says in his blog post:

• Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. [...]
• We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins.[..]
• As of Rails 3, Rails will have a defined public API with a test suite for that API. [..]
• Rails will still ship with the “stack” version as the default (just as merb does since 1.0), but the goal is to make it easy to do with Rails what people do with merb today.
• Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. [..]
• Rails will continue their recent embrace of Rack, which [..] will improve the state of modular, sharable logic between applications.
• In general, we will take a look at features in merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

Personal perspective

I’m personally really excited about this opportunity. I had a hard time believing that we could work together but I was proved wrong. We have many challenges in front of us, but watching the two teams working together is very reassuring.

I’m also glad to see that we will have a Rails Evangelism team that I will be part of. I strongly believe that one of the many reasons why merb has been so successful is because we work and listen to our community. We have put a tremendous amount of energy into trying to understand what you guys need and what you like and dislike. In return, we have seen many people working hard on the wiki and the merb-book.

Can you imagine doing that with almost 4 Million Rails developers?

I’m also looking forward to working with a team and reaching to even more people.

Other news related to the merge:

• The RubyOnRails website will keep a trace of this historical moment: http://rubyonrails.org/merb
• The merb training scheduled for Jan 19-21, in partnership with Integrum, will still take place, and if you want to get a head start and learn about the things that will make Rails 3.0 totally kick ass, I’d suggest you join us.

If you have any questions, or if you want me to publicly answer questions on your blog please contact me. I’ll do my best to get back to everyone.