Meta Bates

I’m now entering the home stretch of writing the Distributed Programming with Ruby book. I’m just a few weeks away, well, technically I’m hours away from finishing the last chapter (Delayed Job) in the official table of contents, however, I’m going to add another chapter and a half. Why? Mostly because I’m a glutton for punishment. That and I want to deliver the best book possible. The extra chapter and a half, not featured in the table of contents below, will be on MapReduce technologies. It’s a really hot topic, and I think it will fit well in the book. What do you think?

Unfortunately, the “Rough Cuts” book on O’Reilly’s Safari site hasn’t been updated in nearly 3 months! I’m not sure why. I keep asking my editor to update it, but it hasn’t happened yet. I’m sure it will soon, especially since the first draft of the entire manuscript will be done in just a few weeks!

UPDATE: Today they updated the “Rough Cuts” with nearly the latest revisions. It’s still missing the chapters on Delayed Job and BackgrounDRb, but it’s closer than it was yesterday.

Anyway, as a public service announcement to you, the readers, I thought I would the table of contents as it stands right now, so you have a better idea of what the book is going to be about. So here it goes:

What do you think? Does it look good? Is this something you’d buy? Let me know. This is your chance to have an influence on a book. If you think something is missing or should be laid out differently, please let me know, it might just make it into the final product.

Ok, enough delaying here, let me get back to writing so I can finish up the Delayed Job chapter.

The other night I submitted a new iPhone application to the Apple Store. The app, which I’ll speak about when, and if it gets approved, uses the new Apple Push Notification service available in iPhone OS 3.0. On the server side I have a Rails application that I am using to send the notifications to Apple. The problem I ran into was how.

Enter the APN on Rails gem. While searching I found one plugin for Rails that mostly worked for me, Sam Soffes’ apple_push_notification plugin. It was a great place to start, but I found that there were things that didn’t suite me. For starters, not having any tests is always a big turn off for me when it comes to any code. I also didn’t like that you didn’t need to save a notification in order to send it. That means you don’t have a record of what was sent and when. I also wanted to have devices stored separately from the notification. Finally, I wanted to be able to easily configure the plugin. Sam’s was using constants that would need to be changed when it hit production.

So, with all that said and done I took Sam’s great work, ripped it apart, and put it back together again, this time in gem form instead of a plugin, and here it is.

There are a few migrations, a few models, and a few Rake tasks, but here is the basic idea of how it works:

To get a better understanding of exactly how it works, and what it does, I highly recommend reading the RDOC.

There are a few things I still would like to add, for example, a controller to do CRUD for devices so iPhones can register with the Rails app. I’d also like to add a task that talks to Apple and finds out which devices are no longer accepting messages so they can be removed.

If you’d like to contribute, please feel free and for the project on GitHub:
http://github.com/markbates/apn_on_rails/tree

Again, a special thanks to Fabien Penso and Sam Soffes for their initial work on this project.

For those of you who have checked out the Rough Cuts version of my book, “Distributed Programming with Ruby”, I thought you would like to get a peek into how the Table of Contents is going to change shortly. For those of you who haven’t seen the old Table of Contents, or are just plain old interested to see what’s going to be in the book, or to see how far along with the book I am, here is the current Table of Contents as of tonight:

As you can see it has evolved quite a bit from what was posted on Rough Cuts just about a month ago. Chances are that it will probably change again, and as it does, I’ll try and keep you all posted. There is talk of adding a large chapter at the end that takes a handful of the technologies I discuss in the book and use them to build a “real world” example application, like a Twitter clone, or something like that. If anyone has any good ideas on what they would like to see for this example, please them my way, I’d love to hear them.

If there are no sections listed below a particular chapter that means that I have either not written it yet, or I’m still too early in that chapter’s development to have properly assigned it actual sections.

The first draft of the book is slated for the end of July. So there is still a lot of work to be done, but it’s still rather exciting. Well, it’s exciting for me at least. Talk to you all soon.

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!