Rails 3.0 – LIVE, released!

Or: How to NOT kill a brand.

WTF: a Play Station 3! What is this article about? Something I hope will NOT see in the near future.

Sometimes it is difficult a great brand to stay on top. And if that brand is an Open Source one…

Open Source philosophy is sometimes dangerous. Some people out there believe Open Source means “truly software democracy at work”, if you don’t like it, choose another one, or do it for yourself. Well; it is OK thinking that way if you have no serious business attached to an Open Source technology. Did someone asked how many production projects are running Rails 2.2.2? Or even Rails 2.0? Or Merb 1.0.5? Or even Merb 1.0? Why so many releases? Why so close?

Look at this Merb – Rails, so called “merge”. In between the lines we can Read: Rails “eats” Merb. But that is not necessary a bad thing. I think we are just on a high level of WTFs per hour on this subject. BTW, the best “merge” definition I have got is: “To blend gradually into something else”.

I’m a newbie here, I’m focusing on Rails, just because a newbie need to focus on something, but I have made a fast incursion on Merb at RubyLearning (beta course), and I need to say: I like what I have seen there. The only drawback was it wasn’t working fine on Windows, but I think they have fixed this on a later version, so…

Now back to the point: I don’t care if they call it Merb or Rails, but it is fair to keep the bigger market share brand, so, we can say the brand Rails “eats” the brand “Merb”. May be it is time to find a new real OPEN SOURCE logo (that is for DHH) and improve the brand into something like “Rails 3.0 – LIVE”, to celebrate that.

But the same COULD NOT be applied to the teams, they MUST be merged. That is what I really care about.

The way they will move from now on, will make history (or not). They have established the brand: “Rails 3.0” it is, but which is the strategy?

I think they must have a common focusing point on Rails 3.0, two in fact:

• Convince Merb users that they can upgrade to Rails 3.0 and their project will remain almost the same, and they will not need to “rely on Mack, Waves, Sinatra and others to fill in the gap”.

• Convince Rails users that the new options and technologies available will not necessary change their projects a bit, will not introduce new bugs and if they want Rails will remain as opinionated as it is now.

There must be a mission: “No pain, plenty of gain” for both current brands users.

I have read that “Merb will keep on living and be supported for a very long time. (we will keep on fixing major bugs even after rails 3.0/merb 2.0)”.

To be honest, I think it is a bad idea. It means the newcomers on the Rails core are still attached with their old brand, and if that is the point, they will be a team inside a team, not a merged team with a common objective.

So people from the Rails core: the older ones and the newcomers, PLEASE, THIMK.

The users, THE CUSTOMERS, don’t need two brands for so long IF the remaining one gives the options they need, so, keep in mind the two focusing point mentioned above and MOVE ON.

A real and complete team merge MUST be done when Rails 3.0 get released.

And Merb support MUST be ended with Rails 3.1 or Rails 3.2 at least.

Or, you can remember the classic: “How to kill your brand”. Coincidentally or not, they were talking about version 3 at that time too.

I hope there will be a time in the future we can say: we believe they two become one.

Merb is DEAD

Well, I don’t think so, in fact I think Merb is now immortalized, just because it twist a fundamental concept on Rails World, which is: “Rails is an opinionated Framework”.

You can see all sort of reasons, why people adopt Merb or Ramaze instead of Rails and use other alternatives on the full stack like Rack and Thin, all over the place.

Since Rails could now dress all Merb good features, reasons to start developing a “new” framework against Rails, will start to diminish from now on.

Here are the basics on Rails 3.0 prototype on the table:

"Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty (“rails myapp --core” and “rails myapp --flat”)."

"Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over."

"Rails will always have a default answer to every question within the stack. But you will have the option of your choice on: TESTING, ORM, TEMPLATING, AJAX. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives."

"Too many plugins break when Rails is updated. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades."

"The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 (May 4 to 7) in Las Vegas."

On the other hand, there are some side effects over the earlier adopters of Merb: speeches, keynotes, courses and books and even applications, are now on the spot. What to do?

Rails’ official blog announcement.
Rails’ official site announcement.
Yehuda’s blog announcement.
Ezra’s blog announcement.
Matt Aimonetti's blog announcement.
Carl Lerche’s blog announcement.
Lori Holden's reply.
EngineYard’s blog announcement.

Well, that is it.

Marry Christmas!

Test on color code

This is a test on posting colorized code here on Blogger:

def creditcard?(type = nil)
number = self.to_s.gsub(/[^\d]/, "")
return false unless number.length >= 13

if type
    return false unless creditcard_type == type
end

sum = 0
for i in 0..number.length
    weight = number[-1*(i+2), 1].to_i * (2 - (i%2))
    sum += (weight < 10) ? weight : weight - 9
end

return true if number[-1,1].to_i == (10 - sum%10)%10
return false
end

After that I have edited the post to check the consequences...

And then edited another time to fix it... Very fast.

And here is the source: A Brent Sowers' article.