Entries from June 2008 ↓

At RubyConf a bunch of us sat around a few glasses of beer and had a ‘bitch’ session about the state of Ruby Gems, a system we all consider be rather sub-par. At that session Tracy Flynn, friend and colleague of yours truly, said we should do something about it. He suggested we write RubyOpals. Well, Tracy is putting his money where his mouth is, http://github.com/tflynn/rubyopals/tree/master. I can tell you that I for one, can’t wait for Ruby Opals! I’ve already forked the project and started contributing! As soon as the first version is ready for release, I can tell you that Mack, Cachetastic, Genosaurus, etc… will all be the first available as opals.

I highly encourage all of you out there to add this project to your ‘watch’ list on GitHub. And if you have the time, and want to help write something special, I highly encourage you to fork it and start contributing! Time to get out there and start making the Ruby world a much, much, much better place.

I’m sure everyone is wondering why things have been so quiet around the Mack front recently. Well, there are a couple of reasons. One, I’m on vacation in Ireland right now, so my coding time has dropped dramatically. Second, I’m still very much so patiently awaiting the 0.9.2 release of DataMapper, which the next version of Mack needs. Third, there is a lot of Mack work afoot at the moment.

The company I work has seen fit to give me a few more resources to help me make Mack the most kick ass framework out there. I’ve not got 1.5 more bodies diligently working away on Mack, with another body to hopefully be hired in the next full weeks. That will mean, within a few weeks there will be 3.5 full time bodies working on Mack! Awesome!

There are some great things that are going to be in the next build, but mostly it’ll be a nice refactoring. We’re going to splitting a bunch of stuff out of the core of Mack and putting into a mack-more package, similar to the approach Merb and DataMapper have adopted. In mack-more there will be l10n internationalization, RJS support (Prototype AND jQuery), DataMapper 0.9.x support, HAML, Markaby, PDF::Writer support, amongst others. It’ll be nice. Trust me.

We hope to have the next release out within the first or second week of July, of course, this really depends on when the DataMapper release can get out there. Once we get this release out, we can really focus on some extremely kick ass new features. Stay tuned!

Hey everyone, people have asked for it, so here it is, a Wiki for Mack:

http://wiki.mackframework.com/

I’ve placed a few tutorials up there, and it’ll be the defacto place for such information.

I highly encourage everyone to create an account and add to the knowledge base there.

On a different note, it looks like the next version of DataMapper will be out in the next few days. This is great news for Mack developers as the next release of Mack has been held back because it requires stuff in the DataMapper 0.9.2. Once that’s out, the next version of Mack will be right on it’s tail! Keep watching this space.

This is actually a combined post about 0.5.5.3 and 0.5.5.4. They are both small patch releases, but they both address some pretty big problems.

0.5.5.3:

The new version of Passenger (aka mod_rails) now has support for Rack based applications. In their documentation they show how to use a Mack app with Passenger. The documentation is based on the yet to be released Thin adapter. With that said, both of those systems use a piece of Mack that’s no longer there. Because of that I’ve restored the small section of code, to make sure those two systems work with Mack. Which is great news.

On some flavors of Unix when you do a Dir.glob you don’t necessarily get back an ordered list of files. Because of that some people we’re getting uninitialized constant errors. This has also been addressed in 0.5.5.3.

0.5.5.4:

A couple of people have reported issues where they were getting the following error even with the most simple application:

“Rack::Lint::LintError: env missing required key QUERY_STRING”

A Mack supporter by the name of Andre Ludwig stepped up to help me try and figure out the problem. I couldn’t reproduce it on the machines I have access to, I suppose that goes without saying, because I could’ve reproduced it, I would’ve fixed it sooner. Anyway, Andre stepped up with both his time, spending most of his Sunday online with me, but also with his hardware. Andre opened up his server to me so I could go in there directly and play with things until I found the problem.

Sure enough, once I got in there, it didn’t take me too long to figure out what the problem was. It turned out to be a conflict between the latest version of Mongrel (1.1.5) and the latest version of Thin (0.8.1). A simple rewrite of the rake server task and voila! problem solved.

So I would like to say thanks so much to Andre Ludwig for all his time and his hardware. I would also like to thank Saji for originally reporting the problem and for doing some troubleshooting for me as well.

As the community grows I can’t help but be awed by not only how much people are loving what Mack is doing, but also by the communities willingness to get involved and help out. Thanks so much everyone!

Changelog 0.5.5.4:

• Fixed the damn Lint error some people were facing!

The simple, yet extremely powerful, Ruby caching framework, Cachetastic has been upgraded to 1.7.0. The big new feature of this release is the Cachetastic::Cacheable module. Including this module allows any class to become a Cache.

class Person
include Cachetastic::Cacheable
end
Person.set_into_cache(:hi, "Hello There")
Person.get_from_cache(:hi) #=> "Hello There"

Under the covers this creates a Cachetastic::Caches::Base object and proxies requests to it. This is a very simple example and belies the richness of the Cachetastic library. 

http://cachetastic-api.mackframework.com/

Features:

• Flexible configuration. All caches have can either have their own configurations, or they can inherit from a default configuration.
• Easy to use Adapter API. Included adapters include, LocalMemory, Memcache, DRb, File, and more. With the Adapter API being so simple, it’s easy to build your own custom adapter.
• Flexible logging. Each cache can have it’s own loggers, or they can use the default logger.
• JIT caching. Through Ruby’s powerful block structure, you can pass a block to a ‘get’ call and have it run if the results from the get are either ‘nil’ or ‘empty’
• Cachetastic::Cacheable module turns any Object into a cache. It allows for any instance of that Object to cache and uncache itself.
• And much more!