Meta Bates

I’ve always been a big proponent of Ruby 1.9, I make no bones about it. My question is why wouldn’t you be? It’s faster, more powerful, easier to use, and makes things a lot clearer and cleaner than 1.8. So why then are pretty much all of us still running our applications on 1.8.x? Great question, and as far as I can tell there is really only 1 answer.

That answer? Because no one else is. It’s stupid really, but it’s the truth. We’re all afraid to run our applications in 1.9 because we don’t know many other people that are. Because of that it makes it hard for you to make your application work with 1.9 because all those gems and libraries  you use aren’t 1.9 compatible, so you’re forced to keep running your app on 1.8. And so the cycle continues.

Enter Rails 3.0. Here is a major upgrade to the most prominent web framework in the Ruby community, and I would argue the reason that most of us got into Ruby in the first place. This upgrade will force us all to make some pretty severe changes to our applications to make them fully compatible.  The changes in ActiveRecord alone are so sweeping and massive that we, as a community, are going to have to put some serious time into upgrade our applications. Yet, despite this, we are all going to do it.

Why are we all going to upgrade to Rails 3.0? Because it  looks cool and sexy, and we want those great new features and all those performance enhancements to make our applications run faster. Which leads me back to Ruby 1.9.

In Rails 3.0 they are dropping support for Ruby 1.8.6 and below in favor of Ruby >1.8.7 and >1.9.1. I propose that Rails 3.0 becomes Ruby 1.9 compatible only. Think about it. What a perfect opportunity for us all. We are all going to have to upgrade the libraries and gems we maintain to support Rails 3.0 and we are going to be upgrading our applications to Rails 3.0, so why not go full steam into Ruby 1.9?

There is no better time than now to push forward into the future as a whole community. Let’s put Ruby 1.8 behind and reap the benefits of what Ruby 1.9 has to offer. What do you say? Can we do it? I think we can.

After more than two years powering production level applications I found that Cachetastic was starting to get a bit long in the tooth. I felt that there was a lot I could to make Cachetastic an even better library than it already was. I thought that I had added a bunch of cruft to the framework that people were just not using and maintaining it all seemed like a bit of a pointless chore.

So what was I unhappy about?

Configuration:

I was pretty unhappy with the way configuration was being done. I liked using Configatron to power the configuration, but I didn’t like the way I implemented the way I was using Configatron. For example, to set up one of the default settings, like the expiry time, you would configure it like such:

configatron.cachetastic_default_options.expiry_time = 30.minutes

Now you would configure that same option like this:

configatron.cachetastic.defaults.expiry_time = 30.minutes

That’s a little savings, but it really hits when you want to configure a particular cache. Let’s say we a cache called My::Super::AwesomeCache, to configure it in past versions of Cachetastic we would do this:

configatron.my_super_awesome_cache_options.expiry_time = 15.minutes

Now in Cachetastic 3.0.0 we configure like this:

configatron.cachetastic.my.super.awesome_cache.expire_time = 15.minutes.

As you can see all configuration now happens under the cachetastic namespace in Configatron. Then it’s a matter of using a Configatron namespace for each of your modules. I find it a lot easier to manage.

Another change in configuration is that in previous versions if you wanted to override one default configuration value for a particular cache,  you had to override them all. Now, you can just override the one value  you want, and the rest will be nicely inherited from the defaults.

Speed

Cachetastic has always been a very fast library, but I knew that more could be squeezed from that stone. With Cachetastic 3.0.0 you now get a hefty 25% improvement in the Memcached adapter and a whopping 99% in the LocalMemory adapter! Those are pretty awesome numbers. These numbers were easy to achieve when I stepped back and examined what it was I really wanted to do, and picked the most straightforward path to that goal.

Bloat

After more than two years Cachetastic was starting to suffer from a severe case of bloat. For example, I’ve never used the DRb adapter, have you? So why is it there? The same goes for the HtmlFile adapter. I wrote that because at my last job the operations team weren’t savvy  enough to be able to get Apache to talk to Memcached, so they wanted to serve HTML files, hence the rather awful adapter. Both of those adapters are now history.

There also used to be support for Rails Session Caching. Considering that most people are now using the Cookie store for sessions, there really is no need for this cache. It could also be argued that it should not have been bundled with Cachetastic at all. I would agree with those arguments. Cachetastic is, and should always be, a standalone caching framework, that can be plugged into Rails or any plain old Ruby project that needs caching support.

Also purged is automatic support for mixing in the Cachetastic::Cacheable module into ActiveRecord. If you want this functionality, it is very easy to include in your application. I don’t want to force it on anyone, so that is gone now.

Finally there are a handful of smaller features that I’m sure no one will miss that I’ve yanked out in the name of performance, reliability, and ease of maintenance.

Nice and Clean

When I realized what I really wanted, and what I didn’t want, it became clear that what was needed was a fresh code base. With that said, I hit delete (well, not really) and started over again. The code is now smooth, so much easier to read, and fast. In previous versions even my eyes went a bit crossed when I tried to figure out exactly what was going on. There where quite a few levels of indirection, and things just weren’t place where they probably should’ve been. That has all been fixed.

With a nice, clean code base comes a brand new set of tests. The tests are now extremely comprehensive, and while 2.x was very well tested, I know that 3.0.0, is tested to the hilt.

Because 3.0.0 is a brand new code base, I should probably stress the fact that is NOT backward compatible. So please be advised.

Installation:

$ sudo gem install cachetastic

Conclusion

I really hope everyone likes this brand new version of Cachetastic. I’m very happy with it, and I think if you give it a chance, you will be too.

If you’d like to have a peek at the RDoc, it can be found at:
http://cachetastic-api.mackframework.com/

Hey there folks, sorry for the long wait for this release, but it’s here. It’s been a long November for yours truly. I’ve had to find a new job. I’ve had pneumonia. We, at least in America, have celebrated Thanksgiving. And, of course, who can forget RubyConf 2008?

So with that said, what’s in 0.8.2? Honestly, not a whole lot. There are a couple of bug fixes, a button_to_remote (think submit_to_remote in Rails) helper, and deferred routes. More on deferred routes in a moment, as it’s actually a pretty cool feature that only Mack and Merb share. And finally there is bundled gems.

Bundled Gems

What do I mean I say ‘bundled gems’? Well, because of the rather large number of gems that get installed with Mack, and because of some gem version dependency issues, Mack is now bundling it’s third party dependency gems inside itself. For example, mack-facets used to rely on the gems ‘facets’ and ‘english’. Those gems are now bundled inside the mack-facets gem and now longer need to be downloaded and installed by end users. This should make installing Mack super easy. It should also make dealing with having multiple versions of Mack installed on your system easier to deal with and maintain.

Deferred? Routes

So what are deferred routes? Ezra wrote a really great write up back in April. The idea is simple, with newer web servers such as Thin and Ebb, you can tell them to spawn a new thread to handle particular requests, such as long running processes like file uploads. This can really help speed things up as server can process regular requests using an event machine model, which is very fast, but can be really slow and block the server for longer processes. Now those processes can spawn into their own threads and not block the server.

In Mack 0.8.2 you can mark your routes with a deferred? => true option which will trigger this behavior. It’s much more advanced than the similar feature that can be found in Merb, which requires a separate configuration for your deferred actions, and the urls have to be ‘hard coded’. Mack let’s you use all the dynamic power of your routes, like you would want to. It’s just another option on the route itself. For a great tutorial on using deferred routes, check out the following page on www.mackery.com:

http://www.mackery.com/routing/deferred_routes

Upgraded Dependencies

A few gems have been upgraded as part of this release, the big ones include DataMapper to 0.9.7, ActiveRecord to 2.2.2, and Haml to 2.0.4.

Changelog:

• [#237] Fixed render :rjs throws errors
• [#236] Upgraded to ActiveRecord 2.2.2
• [#235] Upgraded to DataMapper 0.9.7
• [#230] Upgraded to facets 2.4.5
• [#229] Upgraded to english 0.3.1
• [#227] Removed WEBrick logging
• [#226] Bundled gems.
• [#225] Removed dependency on Thin
• [#223] Fixed mackery console fails
• [#148] Added button_to_remote helper method.
• [#16] Added deferred? routes.
• gem: active_record 2.2.2
• gem: data_mapper 0.9.7
• gem: addressable 2.0.0
• gem: facets 2.4.5
• gem: english 0.3.1
• gem: rspec 1.1.11
• gem: haml 2.0.4

Well, it’s finally here, Mack 0.6.0! This release has taken a long time, but I feel that it’s definitely worth it. This has to be the best release of Mack to date. During this release the Mack dev team grew by 100%, Darsono Sutedja, previously a contributor to Mack, is now a full time Mack core team developer! Darsono has done an absolutely great job on this release, thanks Darsono. With that out of the way, let’s jump straight to the good stuff, shall we?

DataMapper 0.9.2 Support

At long last Mack supports DataMapper 0.9.2. Because previous versions of Mack used DataMapper 0.3.2, there is some upgrade work that you’ll need to do, but trust me, it’s worth it. DataMapper 0.9.2 is a gigantic leap forward from 0.3.2. If you have problems installing the data_mapper gem, make sure that you don’t have gems.datamapper.org in your source path for rubygems. You can remove it with the following command:

gem source -r http://gems.datamapper.org 

RSpec Testing Support

RSpec is now the default testing framework for new Mack applications. This innovative testing framework makes it fun, and simple, to do behavior driven development. If you haven’t yet played with RSpec, I would highly recommend it. I wasn’t a big fan of ’spec’ testing prior to meeting Adam French, of DataMapper fame, and he turned me on to the joys of rspec. I think you’ll like it too, if you give it a chance.

mack-more

There is now a mack-more package. This will house all the optional gems available to the Mack framework. This include things like HAML and Markaby support, localization, etc… Use what you want, ignore the rest. This will help keep the core code clean, light, and of course, fast.

Localization/l10n Support

Darsono did a great job with the mack-localization gem. There is now optional support for internationalization in Mack applications. Check out the gem, it’s definitely worth it if you need to support multiple languages for your web application.

Much, much more!

Of course, there’s a lot more Mack than the stuff I just mentioned, there’s tons of bug fixes, some code clean up, some API changes, transactional testing support, the ability to catch specific errors in routes and have them diverted to a controller/action for handling.

There is a great wiki entry on upgrading your existing Mack project to 0.6.0 here. I highly recommend reading it whether or not you have an existing Mack application.

With this release the Mack team is also fully embracing Lighthouse. If you find bugs, or have suggestions please visit http://lighthouse.mackframework.com and log them there. You’ll also find the list of features that will eventually be added to Mack.

Changelog:

• INCOMPATIBILITY NOTICE: Moved Mack::Configuration.root to Mack.root
• INCOMPATIBILITY NOTICE: Moved Mack::Configuration.env to Mack.env
• INCOMPATIBILITY NOTICE: Mack::Configuration.* path methods no longer exist. Use mack-paths instead.
• INCOMPATIBILITY NOTICE: Dropped mack_ruby_core_extensions in favor or mack-facets
• INCOMPATIBILITY NOTICE: Mack::Controller::Base is now Mack::Controller (and it’s now a module)
• INCOMPATIBILITY NOTICE: Haml renderer is now part of mack-more.
• INCOMPATIBILITY NOTICE: Markaby renderer is now part of mack-more.
• INCOMPATIBILITY NOTICE: Changed request param’s accessor routine, from params(key) to params[key]
• INCOMPATIBILITY NOTICE: Test::Unit::TestCase is no longer the default testing framework, RSpec is. If you wish to use Test::Unit::TestCase add the following config parameter to your config/app_config/default.yml file:
    mack::testing_framework: test_case
• INCOMPATIBILITY NOTICE: ENV["_mack_env"] and ENV["_mack_root"] are no longer supported, please use ENV["MACK_ENV"] and ENV["MACK_ROOT"], or just Mack.env and Mack.root
• INCOMPATIBILITY NOTICE: MACK_DEFAULT_LOGGER constant is no longer available. Please use Mack.logger instead.
• INCOMPATIBILITY NOTICE: The ApplicationHelper module is now deprecated. Please move view level helpers into Mack::ViewHelpers::* and controller helpers into Mack::ControllerHelpers::<controller_name>
• thin.ru and thin.yml are no longer needed, you may delete them.
• RSpec assertions are now automatically added.
• Added a Mack::Testing::Response class to make testing of responses easier.
• moved test_extensions to testing and added the module Testing to the files in it.
• Added a dependency on mack-more
• Added a set of Rake tasks to update existing Mack applications.
• [#30] Added Mack::Logging::Filter to filter out unwanted parameters from the logs.
• In routing you can now define a route that will catch an Exception from another controller.
• ORM will not be initialized if the app never specify which ORM to use.
• All Mack unit tests are now written using rspec-1.1.4.
• mack command now takes an optional -t flag to determine which testing framework to use–value could be test_case or rspec [default]
• new setting added to app_config: testing_framework
• gem: cachetastic 1.7.2
• gem: application_configuration 1.5.0
• gem: erubis 2.6.2
• gem: genosaurus 1.2.1
• gem: thin 0.8.2
• gem: rspec 1.1.4

So a lot has been made in the last few days about my decision to drop ActiveRecord’s native support in Mack. People have asked why can’t I keep what I already have in regards to support for ActiveRecord, and why can’t I support Sequel. So, I’ve decided to compromise.

In the next version of Mack, which should be out in the next day or two, I’ve broken out support for ActiveRecord and DataMapper into their own gems, http://github.com/markbates/mack-orm/tree/master. That means you’ll be able to still use ActiveRecord, if you want. The default ORM, however, will be DataMapper. That’s what you’ll get out of the box with Mack.

Now, keeping with my original post, I’ll be actively maintaining the mack-data_mapper gem, and when I can I’ll make similar changes to the mack-active_record, but I’m not promising anything. Now the good thing here is that since the repos for these gems are on GitHub, anyone can contribute changes/additions to them. I’ve even put a stub in there for Sequel support, that’s definitely something someone else will have to support.

This also has a nice advantage in keeping the Mack core clean and simple. Hopefully this will all lead to faster development time turn around for Mack.

It’s also worth noting that when I talk about ‘native’ support, all I mean is some Rake tasks and some generators. There’s nothing stopping anyone from using ANY ORM with Mack. You could even create your own, if you really wanted to.

Here’s to hoping this makes everyone happy!