Yehuda Katz is a member of the Ember.js, Ruby on Rails and jQuery Core Teams; his 9-to-5 home is at the startup he founded, Tilde Inc.. There he works on Skylight, the smart profiler for Rails, and does Ember.js consulting. He is best known for his open source work, which also includes Thor and Handlebars. He travels the world doing open source evangelism and web standards work.

Dispatch from the Front Lines

Hey all,

It’s been a very busy few days, but I’m glad to say that the work on the Rails/Merb merge is going quite smoothly. Some things that have already happened:

  • DHH has posted an outline of our plans to bring display/provides into Rails: http://tinyurl.com/providesinrails. The new API resolves some lingering issues I personally had with the provides/display version, and is still undergoing a bit of change.
  • Michael Klishin (antares) has begun work to merge Extlib into ActiveSupport. There are already some obvious incompatibilities, so we will be doing both cleanup on the differences and selecting the fastest implementations. He has also begun porting LazyArray, the underpinnings of the DataMapper “kicker” technique, to ActiveSupport. I should note that Michael was instrumental in merging Merb and DataMapper’s extensions into Extlib in the first place, so this should work out quite well.
  • As DHH mentioned in his post, some work is also being done to work out a better API for the Merb router. While our API works fine, we’re working together on an even better API for Rails3. One of the great things about working with the Rails team is being able to work with very talented API designers on some hard problems. To be clear, we will still support both Rails2’s API and Merb1’s API, because the Merb router, which is serving as the base for this work, decouples the code generation part from the DSL (so any DSL can be used to generate the structures that the router than converts into its compiled matching method).
  • We have started discussing some other issues that could potentially break back-compat in Rails (like Merb’s BlockAwareEnhancer for helpers that take blocks), and I’m happy to report that the conversations have been very productive. Being able to revisit issues that both groups addressed suboptimally in the past with a larger group is proving to be quite enlightening.
  • I have personally begun work to unify the code in Rails that does content negotiation to always go through a single path. You can follow along at http://github.com/wycats/rails/commits/content_negotiation. I will be rebasing this remote branch against current rails master frequently (to keep it in sync with rails head) so you may need to reclone from time to time.

On the Merb front, we will be releasing 1.0.7 this weekend. Expect the first transitional release (Merb 1.1) in the next month or two. It will probably involve porting over basic configuration to Rails’ style (Merb’s Kernel#* style is pretty icky) and probably starting to create a shim for some of the more obvious differences (before/before_filter comes to mind). It’ll be the first of several releases specifically designed to help you make the transition in an incremental way.

Happy holidays folks!

8 Responses to “Dispatch from the Front Lines”

This is heartening. The hardest part of merging two codebases – and two cultures – is the endowment effect. We did X this way, we’re sure we did it this way for a good reason. We worked hard, it’s already done and it finally works, and we’re certainly not going to revisit that whole discussion just to work with your code.

You’re taking the opposite approach: We did X this way. We were never thrilled about it, but it had the best set of trade-offs at the time. Do you have a better way to do X? Does the merge eliminate the need for some of those trade-offs? What do your fresh eyes see in X?

That’s a teaching moment for the rest of us.

Looking good :)

David hasn’t permitted comments, so at least here:
1) congratz to provides/display, BUT
2) that’s pretty bad idea to have respond_to block when it can be done more rubyish and more faster and logic through case content_type as is in Merb.

@botanicus you will still be able to use case content_type as in Merb. This is a replacement for display, and will not require the creation of any new blocks.

Я так понимаю, в последнем абзаце как раз вся соль и изложена ;)

Leave a Reply

Archives

Categories

Meta