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 folks, I know it’s been awhile, so I thought I would give you all a very quick update as to how the book is going. It’s going really well. I’m about 100 pages into it, and it’s shaping up very nicely. Addison-Wesley is preparing to put it into their “Rough Cuts” program so you can all get your dirty little hands on what I’ve written so far as early as a few weeks from now, or so I’m told.

While I don’t want to give too much away about the contents, everybody loves a good surprise, let me say that part one of the book will be the most comprehensive guide to DRb and Rinda that you’ll find anywhere. Including the source code!!

I’m working hard on part two of the book which focuses on third party tools, frameworks, and libraries. It’s quite a fun part of the book to write as there are a great deal of choices out there, including my own Distribunaut. (PS. I released a new version of it on GitHub a week or so ago.) Writing about different libraries is quite fun as I get to really delve into the source code and see the good and bad ways people like to write code. Plus some of the libraries have really great features, or really turn things on their head.

When the book is available as a “Rough Cut”, I’ll certainly keep you all informed. In the mean time keep watching this space and have a great weekend!

It is with a sad and heavy heart that this evening I announce that I will no longer be developing the Mack Framework. The project, started a year ago, and has been source of great pride, joy, and at times frustation. Of all the projects I have ever worked on, this one was definitely closest to my heart.

The decision to stop working on Mack was something I did not take lightly. If I had my druthers, and plenty of free time and a source of funding, I most certainly would continue on working on it. However, reality has a different way of plenty out.

When I first started developing Mack the company I was working for at the time was frustrated with the pains and shortcomings of Rails. It was the right platform for the company when we started, however, two years in a start up is a life time and the company took many twists and turns, that lead us to the path of seeking an alternative platform to Rails. At the time Merb was not a serious contender, and there was little else out there that was looking to satisfy the needs we had. Enter Mack. I spent nearly 10 months developing Mack for that company. We rolled out several Mack applications. It worked really well for what we wanted it to do.

Again, however, reality came into play. The company was forced to lay off nearly 50% of its staff, and I was one of them. I quickly took a position as the Director of Engineering for another startup in Boston. This shop, too, is a Rails shop. The difference between the two companies is that for the company I work for now Rails is the right solution. This means that I am spending my days working with Rails, and not developing Mack.

At night and on the weekends I like to spend time with my wife and my son. I play in a band, www.thebluewires.com, and I am working on a book for Addison-Wesley entitled, “Distributed Programming with Ruby”. I’m a busy man, and Mack is a big project. You can’t successfully write a web framework part time. Especially when that part time is really more like part-part time. You need to be able to put dedicated full time resources onto a project of that scale, and I just don’t have the time to do it.

Would I love to see the project continue? Certainly. If there is someone out there who wants to take it on, please let me know. I would love to see it grow. There is so much I wanted to do with it. So many great ideas.

Now, for the good news, I am planning to port a bunch of the Mack functionality over to the Rails 3 platform. The obvious one being the mack-distributed package which is a key differentiator between Mack and the other Ruby frameworks. Another package I think worthy of migration is mack-notifier, which provides, in my opinion, a really nice clean API for doing notifications, whether they be email, Jabber, SMS, etc… I also really like the mack-data_factory package. It provides an ORM agnostic way to do great data factories for testing. Finally there are some routing improvements that I think Rails could really benefit from, as well as a few other bits and bobs here and there.

I wish to thank everyone who has supported this project over the year. A few key people I think that deserve a special call out are: Darsono Sutedja (the second biggest contributed to Mack), Gerardo Pis-Lopez (the third biggest contributor), and Greg Arsenault (my previous boss who fought for me to develop Mack). If there was such a thing as the Mack Core Team, those guys would be it. I would also like to thank people like Peter Cooper, Gregg Pollack, Adam French, Dan Kubb, and everyone else who either opened a Lighthouse ticket, submitted a patch, wrote a blog entry about Mack, or who was just there for support and guidance over the past year.

I am going to keep www.mackframework.com around as a forum for my other projects, such as Cachetastic and Configatron, and the other projects I have brewing. Expect some cool new projects out of me in 2009, include some iPhone projects that I’m excited about undertaking. I will be releasing the last version of Mack by the end of the month. It will essentially be a few bug fixes, an upgrade of DataMapper, and Sass support.

To summarize, thank you everyone. I appreciate your support and I look forward to contributing to the community in new and exciting ways.

Thank you.

Happy New Year everyone!

With the help of the absolutely amazing multiruby library and an edge version of rspec from GitHub, the latest version of Configatron now supports JRuby 1.1.6 and Ruby 1.9.1rc1. There are no other functional changes to the library, so it’s a full drop in replacement for vesion 2.1.6.

I highly encourage everyone to checkout multiruby and start upgrading their libraries so we can all move to 1.9 quicker, which means more speed and more power. Once we’re all in 1.9 land we can really make use of some of the amazing features it provides.

Anyway, I’ll be working on upgrading all my libraries and applications to work on 1.8 and 1.9, and hopefully JRuby, over the next couple of months. So be on the look out for a new versions of Cachetastic, Genosaurus [update: Genosaurus already works with 1.9 and JRuby. Hoorah!], and, of course, Mack.

For all those of you who have missed it, today it was announced that Merb will be discontinued and merged into Rails 3 sometime by the end of next year:

http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3

What does this mean for Mack and other alternate frameworks? Well a lot, and nothing, all at the same time. I personally, am not pro the merge. Merb was the biggest the alternative to Rails out there. This has been a problem for us smaller frameworks in that it was hard to get a fold hold into the alternative to Rails marketshare that Merb had a hold on. So with Merb going away, why aren’t happy that Mack has the opportunity to become the big alternative to Rails?

Well, the answer to that question is simple. Innovation and competition. With Merb becoming as big as it was becoming it was forcing Rails to become a better framework. It also made the other alternative frameworks, such as Mack, to be better frameworks as well. Mack has always strived to be a great hybrid of all the frameworks out there. It has strived to provide the best of all those worlds. If all those worlds merge together, what space is left for something like Mack? Mack, and others, could end up being no different than Rarb (Rails + Merb), and then where is the innovation?

If this was the two biggest cable companies or banks merging the government would be screaming monoply. While I’m not saying that, I do feel that this certainly will have an impact on innovation, an impact that only a good healthy competition can bring. Now, please don’t get me wrong, I think Rarb will definitely be innovative. It should be as both Rails and Merb independently have done some amazing things, and I hope that they continue to do so.

So what does the future hold for Mack with this news? Business as usual. Mack will continue to try and be innovative. It will try to make your life a little easier as a developer, and make developing portals and distributed applications easy and fun. Hopefully, Mack will fill the void that will be left by Merb and more people will pick it up as a mature web framework. Hopefully, that will do what Merb once did, force Rails (or rather Rarb), to be more innovative. Hopefully, it will become the alternative that will create another web framework to be innovate to knock it down, and so on…

How do you feel? Are you happy? Are you sad? Are you indifferent? I’d love to hear what you think.