Meta Bates

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 everyone, it certainly has been awhile, a month by my count. I have been diligently working on a book for Addison-Wesley called, “Distributed Programming with Ruby”, so having the time to blog went from a luxury to almost non-existent. But here’s another little post to keep your RSS feeds happy.

I’ve started working on porting the mack-distributed package to the non-Mack world. This new project, and I use the term new loosely for the time being, is tentatively called Distribunaut. The project on GitHub can be found here: http://github.com/markbates/distribunaut/tree/master. It’s pretty rough right now. I’ve ported over the distributed objects section of mack-distributed, but not the views and routes.

You can install the gem like such:

$ gem sources -a http://gems.github.com
$ sudo gem install markbates-distribunaut

To use Distribunaut we first need to start a Rinda::RingServer. Distribunaut comes with a binary to help make this easier:

$ distribunaut_ring_server start

Once we’ve done that we can create an object we would like to share:

When we run that we can access it like such:

That would result in the following being printed out by our ‘client’ code:

On our ’server’ side we would see something like this:

This is, clearly, a very simple example, but it shows you how easy it is to use Distribunaut. We haven’t done any real configuration, and things just magically work!

Over the next couple of months I’ll be extending and rebuilding this library to make it even more powerful and easy to use. I’m going to add fault tolerance, selection algorithms, and whole lot more. The API you see in these examples will most likely remain unchanged, but I’m planning on pretty big under the cover changes.There will be a very in-depth look into all of this in the book, obviously. (Shameless plug, I know.)

If anybody out there wants to contribute to this project, I’d love the help. Any sort of feedback is welcome.

Thanks to the cold and snowy New England winter this year, I’ve been able to devote quite a bit of time to getting Mack to run on Ruby 1.9, so with that said, here’s the 0.8.3 release of Mack, featuring… TADA… Ruby 1.9!! Of course there are a few other features and improvements in this release. Here’s a quick run down:

Ruby 1.9

The big one. Mack runs very well on Ruby 1.9, unfortunately I can’t say the same thing about some other frameworks. I’ve had some run ins with DataMapper on 1.9, but I’m sure those will be ironed out shortly.

A few weeks ago I announced I was working on getting Ruby 1.9 support for all my gems and libraries. I started out with Configatron, then upgraded Cachetastic and Genosaurus. Now Mack is 1.9 compatible. When I made the announcement the guys at RailsEnvy picked up on it and said that I made a call to arms to the community to pick up 1.9 support. Now granted, I didn’t actually say those words, but I think the intent was there, so I’m going to now officially say those words. This is a ‘call to arms’ to the Ruby community to upgrade their gems, plugins, libraries, frameworks, etc… to work on Ruby 1.9. I’ve done it, and I can tell you, it’s not that tough. Just use multiruby, and you’re off and running.

ActiveSupport In, Facets Out

What with the world getting smaller these days, well, at least the world of Ruby web frameworks. A lot of great work is going into refactoring ActiveSupport and making it faster, better, and smaller. Because of that and the fact that every time a new release of Facets comes out it breaks a whole lot of stuff, I’ve decided to use ActiveSupport as the basis of the mack-facets gem. So basically mack-facets is just ActiveSupport with a few more enhancements.

JavaScript Effects

Thanks to the tireless efforts of Gerardo Pis-Lopez, mack-javascript, has been upgraded to add helpers methods for effects for both Prototype/Scriptaculous and jQuery. Thank you to Gerardo for the much needed upgraded to mack-javascript.

Upgrades

Mack has been upgraded to use Rack 0.9.1, DataMapper 0.9.9, and a few other smaller gems.

Changelog:

• [#243] Upgraded to Rack 0.9.1
• [#242] Upgraded to DataMapper 0.9.9
• [#241] Removed dependency on Facets
• [#239] Add do_sqlite3 to gems.rb
• [#166] Effects for mack-javascript
• [#133] Added Form Builders
• [#22] Ruby 1.9 Support
• gem: rack 0.9.1
• gem: rspec 1.1.12
• gem: configatron 2.2.2
• gem: cachetastic 2.1.2
• gem: data_mapper 0.9.9
• gem: addressable 2.0.1
• gem: extlib 0.9.9

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

I know with each release I say how excited I am by this release, but that’s usually because with each release there’s some great new feature that makes me either proud to have developed it, or to proud to be associated with it. Mack 0.8.1 is definitely no exception.

Before I get into what has to be my favorite feature since the distributed features of 0.7.0, and quite possibly my favorite feature in Mack today, let’s talk about a few of the other features in this release.

More Routing Enhancements

There are a few great new features in the routing system in this release. The first off is a real crowd favorite, Nested Resources. Just like Rails you can now nest resources in Mack.

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

In Mack 0.8.0 we introduced the ability to put host information in the routes file. This would be used to match the host when matching a route as well as building the url for that route when using the url helpers. This made dealing with subdomains very easier. Well, to really give everyone that subdomain fu everybody loves, we’ve added the ability to put embedded parameters in the host parameter in routes. It’s pretty dang cool, let me tell you. Checkout these examples:

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

Pagination API

There is now a pagination API that’s part of the mack-orm API. The first implementation of this in the mack-data_mapper package. At its heart it’s extremely easily to implement for new ORMs, one method, and using it is just as easy. There will be a write up on using the API in the forth coming days.

Jabber Support

The mack-notifier package can now send notifications using the Jabber protocol.

!!Portlets!!

Portlets are what components in Rails should’ve been and they’re what slices in Merb should be. Portlets are a way off packaging a full Mack application into a Ruby Gem so they can easily be shared and used in other Mack applications. As you’re about to see, this simple page is all the information you need to know about developing, testing, packaging, and using Portlets.

Portlets encapsulate a whole Mack application, from controllers to views to models to configuration settings to your images, stylesheets and javascripts. This makes it possible to develop extremely rich applications and share them with other Mack applications.

http://www.mackery.com/portlets/developing
http://www.mackery.com/portlets/testing
http://www.mackery.com/portlets/packaging
http://www.mackery.com/portlets/using

Bug Fixes and Minor Feature Updates

As always there are great bug fixes and feature updates. Below is the changelog that outlines those improvements.

Changelog:

• [#217] Fixed rake mack:dump:routes throws errors
• [#216] Added ability to turn off view caching in distributed app
• [#215] Asset path lookup flow update
• [#213] Fixed the params method should be case insensitive
• [#211] Added a pagination API to mack-data_mapper
• [#210] Added a pagination API to mack-orm
• [#209] inline form built by link_to should include authenticity token
• [#208] Added support for DataMapper repository context per request
• [#207] Fixed session cookie not being deleted properly
• [#206] Portlet now have access to its base_path
• [#205] Fixed testing of nested parameters and file uploads breaks
• [#204] Resource routes can now take options when being defined.
• [#203] Updated distributed: view_cache to include Mack::ViewHelpers instead of Mack::ViewHelpers::LinkHelpers
• [#200] INCOMPATIBILITY NOTICE: mack-notifier configatron namespaces have changed from *_settings to * (e.g. smtp_settings to smtp)
• [#198] Added Embedded parameters in ‘host’ for Routes
• [#196] Extlib 0.9.8 support
• [#195] DataMapper 0.9.6 support
• [#193] Portlet Support
• [#192] mack-localization now supports portlet
• [#191] Asset-Packager support for Portlet
• [#143] Nested resources in Routes
• [#134] Form elements are now ‘errorfied’.
• [#131] Date/Time select boxes can now be easily re-arranged.
• [#78] Jabber support
• gem: configatron 2.1.5
• gem: extlib 0.9.8