Archive for December, 2008

latest Merb and Rails 3.0 news

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.



Merb/Rails merge, or Why should merbists be happy?

December 23, 2008, was an important day for the Ruby community. People who used to argue and not get along, have decided to sit down, talk and evaluate their differences. The end result is a strong collaboration of two teams who share the exact same goal.

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:

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

“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.

, , ,


Rails and Merb core team working together on their next release

This is huge!

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


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.

Concretely, nothing changes for merb users. People loving merb should not worry. The way you build merb apps won’t change until merb2.0/Rails3.0. We will still work on your favorite framework and improve it.

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:

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.

, , , ,


Meet the merbists: Jason Seifer

Jason Seifer

Jason Seifer

Today I’m interviewing Jason Seifer known for the funny envyads and the weekly RailsEnvy podcast.

Matt Aimonetti: Hi Jason, could you please introduce yourself and tell us what you do for a living?
Jason Seifer: My name is Jason Seifer and I do mostly web development for a living along with podcasting and screencasting.

Matt Aimonetti: How did you get started with Ruby, what’s your background?
Jason Seifer: As far as my background goes, I have a degree in Psychology from the University of Central Florida. I got started with Ruby by way of learning Rails. I used to do some hacking on perl and php but never anything for full time work until Rails came along. I fell in love with the Ruby language that way.

Matt Aimonetti: You chose to learn and use Merb, could you please let us know why and how that happened?
Jason Seifer: Doing the Rails Envy podcast, I’ve been keeping up with the latest merb news for a while now. Along the way I’ve been extremely impressed by how the merb team handles things, listens to its users, and implements new features. At the same time, I’m pretty lazy when it comes to coding so I wanted to wait until the API was stable and version 1.0ish before jumping in to building merb apps. I have a lot of Rails experience so picking it up wasn’t too hard.

Matt Aimonetti: Do you have some Merb projects available online we can look at? what was your experience so far?
Jason Seifer: I don’t have anything online at the moment but I am working on a couple of things that I hope to release in the coming months. Working with merb is a pleasure most of the time, though it’s pretty easy to get confused with some common rails functions that differ slightly by name (before/before_filter, etc) if you’ve been doing Rails for a while. One thing that’s really nice about working with merb is how compact and easy to understand the framework code is. It’s very easy to jump in and see how something works if you’re having trouble.

Matt Aimonetti: What is your favorite aspect of the Merb framework?
Jason Seifer: As far as features go, I love run_later. It’s pretty nice not to have to run a message queue for decoupling simple things like sending email from the request/response cycle. There are a number of smaller features like that which make merb nice to work with.

My favorite aspect of merb, though, is the stable api. It’s very comforting to know that by upgrading to the next stable point release of the framework that I’m not going to have things that break. This of course doesn’t mean that a stable and comprehensive test suite isn’t important but it is one less worry.

Matt Aimonetti: Could you please mention an aspect of Merb you hope to see being improved in the near future?
Jason Seifer: If you had asked me this question a few weeks ago I would have said documentation, but that itch is being scratched by the merb book. Though not exactly merb, I’d really love to see DataMapper get JRuby compatibility so we can get the full stack on JRuby for deployment. That would be very exciting what with everything going on in JRuby land at the moment.

Matt Aimonetti: Thank you for your time. Anything else you would like to add?

Jason Seifer:
I would encourage people to try merb if they’ve been holding out at all. It’s a great time to get involved and the community is great, too. Also, I’ll be starting a merb podcast soon so stay tuned for that. Thanks very much for talking with me.

, , , ,


meet the merbists: Andy Delcambre

Andy Delcambre

Andy Delcambre

Today, Andy Delcambre is our featured merbist.

Matt Aimonetti: Could you please introduce yourself and tell us what you do for a living.
Andy Delcambre: My name is Andy Delcambre and I work for Engine Yard
( as a Software Engineer. I work primarily on
internal and customer facing projects. These projects are almost
exclusively written in Merb. At Engine Yard we take advantage of many
of the modular aspects of Merb. For example, we use Salesforce for
customer tracking and have a Merb slice which includes the DataMapper
adapters for Salesforce. This gives us the ability to interact with
salesforce from any application for free.

Matt Aimonetti: How did you get started with Ruby, and what’s your general programming background?
Andy Delcambre: I majored in Computer Science at college and had been hearing about
Ruby and Ruby on Rails for a while before I finally dove in. I worked
for the College of Engineering as a Linux Administrator and took the
opportunity to build my first rails application: a tool for managing
our automated deployments. This was a huge learning experience, I had
done web development in raw php before, but this was my first time
using a framework. It was both a bit overwhelming and a breath of
fresh air. When I graduated from University, I decided to pursue Ruby
and Rails as a career path and have yet to look back.

Matt Aimonetti: You chose to contribute to Merb; how and why did that happened?
Andy Delcambre: I was working at Planet Argon (, a small Ruby
on Rails development company and was looking to do some open source
contributions. I had been hearing quite a lot about Merb in the rails
community, especially that it was smaller, lighter and faster. I
decided to look in the bug tracker and see if there was something
small I could tackle and found a bug with the way nil and false
default arguments were handled in merb_action_args. When my patch was
accepted I was fairly hooked. I have been submitting small patches
ever since. I also led the inline documentation team at the Merb
sprint in San Diego during the run up to 1.0

Matt Aimonetti: Do you have any Merb projects available online we can look at? What’s your experience been so far?
Andy Delcambre: All of my merb projects are projects at Engine Yard right now. I
wrote a simple Merb app to manage the content on the Engine Yard
homepage and the blog is based on the Feather blogging engine, written
in Merb. My current projects are not yet publicly available but
should be very cool when they come out.

Matt Aimonetti: What is your favorite aspect of the Merb framework?
Andy Delcambre: I have two answers, first as a someone who works on merb, then as
someone who works with merb.

Ever since that first patch to action_args, I have loved the ease with
which I can jump in and dig under the hood. I have dug down into the
router, the dispatcher, the form helpers, and the mailer, all without
much problem understanding the code.

Second, as a developer of merb applications I think the direction merb
is going with the heavy emphasis on modularity is fantastic. In the
app I am currently working on, we are using four different slices
right now. One of which is an entirely different merb app modified
slightly and mounted within the application. One is a custom
merb-auth strategy that we use internally that makes it much much
easier to maintain consistency for our internal applications. These
would be much much harder to integrate for most other frameworks. It
is so useful to be able to just plug in these small, specific pieces
of functionality.

Matt Aimonetti: What parts of Merb you hope to see improved in the near future?
Andy Delcambre: I am looking forward to the future improvements to the modularity of
merb. I am really ready for the day that you can mount entire merb
apps inside one another. Then, once everything uses merb-auth, I can
imagine mounting a blog and a cms inside the same “app” and have the
users shared across, automatically. How awesome would that be.

Matt Aimonetti: Anything else you would like to add?
Andy Delcambre: I am looking forward to being part of the merb community as this
project just keeps getting better and kicking more butt. Thanks a lot
for including me in this series.

, ,


Meet the merbists: Lori Holden

Lori Holden

Lori Holden

Today, I’m interviewing Lori Holden from Interactive.

I met Lori on IRC a bit before MerbCamp 2008 where she gave a very interesting talk on Sequel.
Matt Aimonetti Hi Lori, could you please introduce yourself and the company you work for?
Lori Holden: Hi Matt, my name is Lori Holden. I originally became interested in software development when I was 10. Since then, I have been a professional developer for over 10 years now and currently work as a Senior Software Engineer for AT&T Interactive.

Matt Aimonetti How did you get started with Ruby, what’s your background?
Lori Holden: Years ago I had been hearing talk about an ‘upcoming’ new language called Ruby. At the time it didn’t have many people in the US working with it, but I really loved how similar to Smalltalk it was.

My core background experience is centered around Ruby, Java, C++, PHP, and Javascript. Outside of that, I consider myself a language geek… and have quite a bit of experience in Python, Smalltalk, OCaml, IO Language, and Perl, along with several others.

Matt Aimonetti You chose to learn, support and use Merb, could you please let us know why and how that happened?
Lori Holden: I was one of the original Rails developers. Since then, I have used Rails off and on… but have found myself growing more and more unsatisfied with it. On top of that, I have also found myself growing out of touch with the core developers over the last couple years, which I am sure doesn’t help things.
Merb is fresh. I find it carries a lot less baggage with it than Rails. Even better, the project is still small and I seem to get along quite well with the the other developers on the project.

Matt Aimonetti You have been contributing to the Merb project and gave a Sequel presentation during MerbCamp 08, what is your motivation?
Lori Holden: Primarily, I just like the developers. Everyone seems to be really passionate about Merb and are willing to push it in some really cool directions. At the same time, Merb still manages to remain slim and with very little bloat.
I really enjoy helping projects push through to release and I was glad to be a part of that for Merb.
Sequel is a really wonderful tool, and I was finding that just not that many people in the Merb community were using it. I had a lot of experience with getting Merb and Sequel to work with each other, and figured I should share my experience with everyone else.

Matt Aimonetti: What is your favorite aspect of the Merb framework?
Lori Holden: This is a really odd one, but my favorite aspect of Merb is that I know it very well inside and out. If I need to browse the source for some feature, I already know where to go and what to look at. I attribute this to how slim the merb-core has remained. I think it is quite easy to work with.

Matt Aimonetti: Could you please mention an aspect of Merb you hope to see be improved in the near future?
Lori Holden: Merb is still immature in some areas. Gem management is one thing that I am finding to be a bit lacking. The support for Sequel could use a bit more improvement… but I suppose that’s something I should work on. And finally, something that I hope Merb always works on: Keep it Small. Keep it Simple. Keep it Core. Bloat should be a plugin away, not an upgrade.

Matt Aimonetti: Thank you for your time. Anything else you would like to add?
Lori Holden: Thank you Matt. I hope you and your wife have a great winter solstice.

, ,


Meet the merbists: Derek Neighbors

Derek Neighbors

Derek Neighbors

Today, I’m starting a new series called meet the the merbists. My goal is to feature various people from our community and ask them a few questions about Ruby, Merb and their projects.

Let’s get started with Derek Neighbors from Integrum.

Matt Aimonetti: Hi Derek, could you please introduce yourself and the company you work for?
Derek Neighbors: I am Derek Neighbors and I work for Integrum Technologies, an agile software company based in Chandler, AZ focused on web solutions using Ruby.

Matt Aimonetti: How did you get started with Ruby, what’s your background?
Derek Neighbors: We were doing custom software development using PHP and Python. We mostly had Python backends with PHP front ends that would communicate via XML-RPC. While this was working, it just didn’t feel productive. We had heard some inklings about this new framework called Ruby on Rails. It was nearing 1.0 and so we decided to do an important but relatively simple e-commerce application in it. We fell in love almost immediately and within 3 months started solely using Ruby for development. The productivity gain just could not be ignored.

Matt Aimonetti: You chose to learn, support and use Merb, could you please let us know why?
Derek Neighbors: We deal with a lot of customers that also have opinions. When we need to work to integrate into their systems, we need the flexibility to do things their way at times. Having to dismantle a framework to do little things can be frustrating. Having a framework with solid engineering practices behind it better allows our developers to help improve or deviate from the framework when necessary. This is something we were struggling with in Ruby on Rails.

Matt Aimonetti: Do you have a public project you wrote using Merb that people can look at?
Derek Neighbors: We have an academic scheduling program we are starting to work on, but have not yet released.

Matt Aimonetti: What is your favorite aspect of the Merb framework?
Derek Neighbors: It reminds me of unix. Lots of small pieces that do their job really well, that when combined make up something pretty spectacular. If you don’t need a piece you can leave it out. If you like emacs (datamapper) instead of vi (active record) then use it. In particular, the concept of Merb Slices is very appealing for code re-use. Something we have struggled with in Ruby on Rails to date. While plug-ins help with re-use there is nothing that would allow the flexibility that say merb-auth enjoys today as a slice.

Matt Aimonetti: Could you please mention an aspect of Merb you hope to see be improved in the near future?
Derek Neighbors: Documentation is pretty high on the list, but also losing some of the “you have to be a ruby hacker to use merb” implications. While it is a hacker’s framework, things like opinionated stacks and talks of Django-like admin interfaces make it sound pretty appealing to the non-hacker audience as well. I am looking forward to Merb not being only for hackers, but still preferred by hackers.

Matt Aimonetti: Thank you for your time. Anything else you would like to add?
Derek Neighbors: I just want to thank Merb-Core for their dedication and passion towards Merb. I think believing in quality and having the determination to make frameworks take it to the next level is what improvement is all about. I thank them for loving Ruby on Rails enough to push the development of both Merb and Ruby on Rails forward by not being okay with “good enough”. People don’t tell open source programmers enough how much they are appreciated. So Merb-Core.. AGAIN, THANK YOU!

, , ,

1 Comment