If you use Merb from Git repository, please update your rackup file (rack.rb) or Merb won't be serving your assets.

Read details in Ezra's announcement on Merb mailing list.

As #229 in merb-core shows, people try to set all of configuration options in Merb init file. This caused a hell of a lot of confusion.

Let me explain why it is wrong. As mentioned earlier, Merb boot process has number of stages. Each stage is handled by simple runnable object called bootloader. Bootloaders run in certain order that you can change, but default assumes pid file is dropped before init file is loaded. So if you rely on init file to set port Merb running on, pid file path or other server-related options, defaults will be used instead.

So if you need to specify port, pid file, adapter, daemonization options, clustering options and such, please use command line options instead of init file. Using new -V/--verbose option you can get extra output to see what pid file Merb uses, when it reads process id from it, when it is forking off, where pid file is located, what port Merb uses and so forth.

Hope this resolved number of issues people had with port and pidfile options for a while.

We now have Merb internals page at Merb wiki, and first page there explains bootloaders. Once you got how it works, you get the key knowledge to how Merb plugins are developed, how Merb parts hook into the game and how simple it actually is (thanks Yehuda!).

Explaination is probably very sucky now. It sure will be improved by readers (and author).

Agenda

Stop reading now if Rails is a holy cow for you. You will see not very kind words about l33t rail0rz along the way. But this is actually post about state of Merb and nothing else. If you are not interested in using Merb, move along.

State of Merb.

Time goes by and Merb is moving to one-point-oh on May 29th. Many people keep coming to #merb to ask "Is Merb stable already?" or "What features are missing from Rails?".

It may be helpful to bring you some good news and bad news.

Why Merb is organized like this.

Merb is now 3 subprojects: core, more and plugins. Plugins are kinda not part of Merb but everything that works with Merb and I won't concentrate much on it.

Merb core is supposed to be what every web application today is gonna need, like:

• Web server adapters.
• Rack integration.
• Routing and request dispatch.
• Means of setting up response.
• Recognition of different data formats (MIME types).
• Cookies.
• Session with different storages (DB, cookies, memcache).
• Chunked response messages handling.
• Basic HTTP authentication at hand.

Some basic Ruby the language extensions that are necessary. But they probably gonna move into a tiny separate library that (again, guesses but chances are) will be also shared with DataMapper.

Merb more provides developers with tools that they need for full-blown web applications, not just services:

• Template engines.
• Caching.
• Assets handling.
• Template helpers.
• XML builder support.
• Mailer.
• Parts (subcomponents).
• Generators.

Some other neat things like Django-style action parameters are in -more as well.

What developer expects from 1.0?

Version numbers are bullshit. They do not matter. They reflect nothing. With one exception. 1.0 for most people is like baby birth. Project after 1.0 is ready to use and not incubating any longer.

So once Merb 1.0 goes public, developers who are looking for simple lightweight alternative to Ruby on Rails bloat (but still want use lovely Ruby!) will be shaking their heads: uh, it's 1.0 now, probably it is time to try.

What happens next? We move on to bad news.

Bad news.

Bad news are that subproject that brings all the goodies for most of web developers out there is not Merb core. It is Merb more. If you want to argue go ask your friend how she or he feels about using a framework that provides no mailer, no sweet Haml templates your friend loves, no caching support and XML should be generated by hand.

The are chances every Rails developer (developers who call themselves "Rails developers" are often sensitive like babies) gonna say you "WTF?! How can you live your life without fucking MAILERS?! Should I be reading all those RFCs?! Man, we are here to develop web 2.0 APPLICATIONS, do you think I'd be happy to get down to metal?".

Yeah. Merb more is obviously more important for the masses than Merb core. They may even not realize it. But lets face it: only hackers who already got services oriented architecture years ago will be using just -core. Others will go and cherrypick things from more. And if something is not ready they will be spreading fucking lies like "Merb has nothing my sweet Rails have! I tried it, it is still a playground for them, nothing really works".

You ask why all these are bad news? Take a deep breath. Merb-more is not ready for 1.0 in 3 weeks. It is ready for 1.0 in 2 months (because we want every part of Merb be superpolished but still easy to understand from the inside in opposite to Rails, right?).

Don't panic. I use Merb-more every day, issues are not dramatic, it is useable. But when people are gonna rely on your 1.0, it is pretty important for it to be polished.

Good news.

Good news are that -core is in good shape. 30 open tickets say nothing, some of them are outdated and no serious issues are present.

Merb also has small but proactive community that won't moan and scream like l33t Rail0rz who made a good 100 forks at GitHub to contribute nothing.

Merb community also haven't yet lost momentum of innovation. Merb router, for instance, is a sweet thing to use and still we have cool, useful feature requests for it. Merb parts are yet to be polished but with them it is possible to reuse code without idiotic Engines that add More Magic on top of The Darkest Rails Magic (bootloader and dependencies.rb crap).

Ugly news

Ugly news is that Merb already faces an interesting problems. People want to have a choice in JavaScript library they use, data layer library they use, templating engine they use. Merb gives them it. But it makes Merb pretty much depending on 3rd parties. Recently we had an issue with Sequel plugin that was becase of Sequel 1.5.x changes. Nobody from Sequel community updated Merb plugin, not all Merb developers use Sequel, and plugin became outdated. It is much better than Rails plugins case ("hey dude, does this plugin work with 2.0.2 or just 2.0.1? dude, could you fix my Exception Notifier for Edge? I really want 8 times faster router!") but because plugins have word Merb in their name, people complain to Merb community.

Ugly news will be gone when Sequel and other plugins will be handled by original project community like DataMapper folks how take care of Merb DataMapper plugin.

So should I use Merb?!

If you ask yourself this question, you probably should not yet. Merb really needs people who create their own destiny. It is by hackers for hackers. If you think framework code is something as saint as Saint Patrick and you should never look at it, stay away from Merb as much as you can.

I wanna help!!

So you wanna help. Ok, the moral of the story is to go and give Merb more some love. You use Haml? Go and work on merb-haml. You used to using Memcached? There is merb-cache to hack on.

All of these -more projects are small. You can understand them inside out after 2 evenings spent. You will learn things about your tools that no documentation can provide.

The Rat's nest

If you are seriously looking for a target in -more, go have a look at merb-gen. It is source of so many minor issues. Cleaning Merb LH last week I found out that many reported core problems are actually merb-gen problems. Merb-gen is Merb's Rat's nest.

The Grand Plan

I think I'd try to convince Ezra, Yehuda, Michael, Fabien and other people who make Merb better every day to release -more and -plugins on July 4th and make it "Rails independence day" or even later. Merb-more is what most of developers will be using actively. Also, periodic releases like Ubuntu has would be cool. But 6 months is somewhat long for web space. We need 2 or 3 months.

You still reading? Odd enough. Probably you care about Merb then. Go and give Merb-more some love. Love in form of patches of course.

I've updated idiotic LOC comparison table for several Ruby projects: have a look what is ActionPack today compared to Merb, Rubinius kernel and Datamapper all together.

Rubinius runs Merb.

Step one is to install Sake (system-wide Rake) and DM-dev tasks:

sudo gem install sake sake -i http://datamapper.org/dm-dev.sake

Now have a look: sake -T

Then the same thing for Merb: sake -i http://merbivore.com/merb-dev.sake

To use those tasks you have to cd into directory where you have project directories do, dm-core, dm-more, merb-core, merb-more and merb-plugins.

New DO Pooling module implementation is mostly done.

I may benefit from some good critics though becauseI am not really experienced with threading programming. Grab it from

git://github.com/michaelklishin/do.git

and checkout newpooling branch.

Specs have been reorganized in an ad-hoc manner to use Autotest without extra setups.

I really would love to hear what wrong with it. Thank you.