And yet, if things came to a halt more quickly than ever before, they could also restart more quickly than ever before. This is not to say they will, only that the possibility is more than marginal.

Posted via email from Duane’s Quick Posts

I have to say that I’m pleased with the proposal to merge Merb and Rails today. I think this will make the community stronger, among other advantages, at a time when the Ruby web development environment really needs a boost. Part of what made Rails so wonderful at first was the expression of so many developer needs made into reality by a new framework. In terms of technology it’s now an old framework, however, and needs a stem cell booster shot. In my opinion, Merb is just the young tissue to do the trick.

For the record, here are the Merb advantages that made me leave Rails in the first place. If these are merged back into Rails, I will have no qualms whatsoever:

1. AbstractController provides a uniform controller mechanism for controller-like things such as normal Controller classes and the Mailer. This was a wonderful design decision by Yehuda Katz because it means the mailer class benefits from mime types and all of the rendering structure of a controller.
2. Merb’s Router is more flexible than Rails, providing placeholders, deferred decision making, and branching based on all request information (rather than just the url path). Ok, ok, and I have to add, I built the router, but that might not be convincing enough on its own
3. Action Arguments and Action Return Strings are two features that just seem to fit the Ruby way better than what Rails chose to do. Having a “params” hash is occasionally useful, but it obfuscates the method signature. Likewise, being able to return a string to the browser and have it rendered directly is wonderfully simple. Rails should adopt this kind of simplicity.
4. Exception Handling is done in Merb using a single Exception controller. Its actions are simple to configure, which is how you would expect it to be. In addition, exceptions actually lend themselves to use in things like invalid logins and plugins. Rails doesn’t have a good exception handling mechanism and for this reason it failed (in my opinion) to take advantage of Ruby’s excellent exception handling mechanisms.

Hurray for Ruby and a new chance for success on the web!

When you create a fresh Merb app using the merb-gen app [your app name] command-line tool, Merb generates a default app skeleton with a DataMapper object-relation mapper (ORM). While I don’t object to DataMapper, I prefer Sequel for my applications.

So when I started a Merb app using Sequel and Sqlite3, I found an unexpected error:

~ Connecting to the ‘music_store.sqlite’ database on ” using ’sqlite3′ …
/Library/Ruby/Gems/1.8/gems/sequel-2.7.1/lib/sequel_core/database.rb:79:in `adapter_class’: Could not load sqlite3 adapter: (Sequel::Error::AdapterNotFound)
no such file to load — sequel_core/adapters/sqlite3 from /Library/Ruby/Gems/1.8/gems/sequel-2.7.1/lib/sequel_core/database.rb:112:in `connect’

I had all of the correct Ruby gems loaded, so what was the deal? It turns out that in the database.yml file that is generated for DataMapper, there is a line in there that sets the “adapter” to “sqlite3″:

adapter: sqlite3

Unfortunately, Sequel expects the adapter to be set to “sqlite” instead, hence the complaining. Just switch it to adapter: sqlite and you should be good to go.