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.

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

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

Although not as sexy a release as 0.7.0, there are some very important bug fixes and some cool new little features in this release. Rack has been upgraded to v0.4.0. DataMapper to 0.9.5. Facets to 2.4.4, and a few other gems as well.

There is now a much nicer session store API that will allow developers to build their own session stores. There’s also a couple of new session stores that ship with 0.7.1. There’s a DataMapper session store, and a cookie session store, which is now the default session store. The previous Cachetastic based session store can be used by requiring the mack-caching gem in gems.rb and putting the following setting in your app_config/*.yml file:

mack::session_store: cachetastic

There is now built-in support to help prevent cross-site scripting attacks on forms. Some view helper methods have nice updates such as :disable_with and :confirm, and asset hosts.

And a whole host of other little improvements across the board. Enjoy!

Changelog:

• [#153] Emails with just a single ‘part’ are now being sent correctly.
• [#147] Added :confirm to button helpers.
• [#146] [Diogo Almeida] Added :disable_with to submit_button form helper.
• [#145] Added rake generate:<generator_name>:desc task to ‘describe’ a Genosaurus generator
• [#144] INCOMPATIBILITY NOTICE: rake server is no more. Please use mackery server instead.
• [#142] INCOMPATIBILITY NOTICE: rake console is no more. Please use mackery console instead.
• [#140] Added Mack::BootLoader
• [#139] Added ability to change the pattern for test files
• [#137] Added subdomains method on request.
• [#130] Added ability to ‘reload’ the console
• [#129] DataMapper 0.9.5 support
• [#128] Updated json_pure to 1.1.3 and removed ruby-debug dependency
• [#127] Moved mack-paths into core
• [#126] XSS Prevention
• [#125] Cookie store is now the default session store, not cachetastic
• [#124] Opened up the session store API
• [#122] Added DataMapper session store.
• [#121] Cookie session store support.
• [#120] Added PassengerGenerator to generate the necessary files to run Mack with Passenger Phusion (mod_rails)
• [#118] Mack/mack-more can be loaded from vendor/framework/mack and vendor/framework/mack-more
• [#117] Added rake task: mack:freeze:edge
• [#107] Updated to Rack 0.4.0
• [#95] Removed deprecated model_* methods
• [#94] Removed deprecated submit_tag
• [#40] Added Mack::Utils::ContentLengthHandler so response will now have ‘Content-Length’ in its header.
• [#21] Asset Hosts
• gem: rack 0.4.0
• gem: json_pure 1.1.3
• gem: data_mapper 0.9.5
• gem: genosaurus 1.2.4
• gem: ezcrypto 0.7
• gem: facets 2.4.4

 

 

Page Caching

There is now a mack-caching gem which gives you easy to use page caching when you require it. To use page caching first you need to add it to your gems.rb file like such:

gem.add "mack-caching", :libs => "mack-caching"

That will require the gem and give your app access to the page caching libraries. Next you to turn on page caching in your application. In the appropriate config/*.yml file add the following:

use_page_caching: true

Now, you just need to tell your controllers which actions they should cache:

class FooController
  include Mack::Controller
  cache_pages  nly => [:index, :show]
end

If you give the cache_pages no optional parameters then it will cache all the actions for that controller. Alternatively, you could give it an :except parameter to list the actions you don’t want cached. 

Notifiers (aka Mailers)

Mack now has a mack-notifier gem that will be the repository for all ‘notification’ systems, the first of which is email. The Mack::Notifier API is simple and easy to use and will allow developers to plugin in different notification systems under the cover without having to change their application code. 

A notifier can look as simple as:

class WelcomeEmail
  include Mack::Notifier
end

With that you can then write the following bit of code:

we = WelcomeEmail.new
we.to = "foo@example.com"
we.from = "bar@example.com"
we.subject = "Hello World"
we.body(:text) = "My plain text body"
we.body(:html) = "My html body"
we.attach(Mack::Notifier::Attachment.new("/path/to/my/file")) 
we.deliver

Obviously there’s a lot more to the API, including a validations module, but that’s a subject for another post. 

JavaScript (aka RJS)

The mack-javascript gem now gives you Rails-like RJS support for Mack. The default library to use with mack-javascript is jQuery, but there is prototype support available as well. 

Data Factory

Creating faux data for testing can be a real nightmare. Fixtures can be difficult to maintain and trying to create your own faux data can be a chore. That’s where the mack-data_factory gem comes in.

For each model that you want to produce, you will need to define a factory class.  

Let’s say that I have 2 models: Item and User, and Item belongs to user.  So the factories will look like the following:

class ItemFactory
  include Mack::Data::Factory
  field :title, "MyItem"
  field  wner_id, {:user => 'id'}
end

class UserFactory
  include Mack::Data::Factory
  field :username, "planters", :length => 25, :content => :alpha
  field :password, "roastedPeanuts", :immutable => true
end

So, the 2 classes above defined the factory for item and user.  As you can see, each factory will need to explicitly list all the fields that it will populate, and for each field, you can define rules on how the content is generated.

Supported content types: 

• :alpha –> alphabets.  rules: [:length, :min_length, :max_length]
• :alphanumeric –> alphabets and number.  rules: same as :alpha
• :numeric –> numbers [optional, because if the field's default value is number, its content type will automatically set to numeric)
• :email --> generate random email address
• :username --> generate random username
• :domain --> generate random domain name
• :firstname --> generate first name
• :lastname --> generate last name
• :name --> generate full name
• :city --> generate city name
• :streetname --> generate street name
• :state --> generate state.  rules: [:country --> :us or :uk, :abbr --> true if you want a abbreviated state name (us only)]
• :zipcode –> generate zipcode. rules: [:country --> :us or :uk]
• :phone –> generate phone number
• :company –> generate company name.  rules: [:include_bs --> include sales tag line]
  example:  field, “”, :content => :company, :include_bs => true could generate something like:
  Fadel-Larkin monetize cross-media experiences

Changelog:

• [#60] Fixed Mack executable problem
• [#59] Fixed gems:* tasks
• [#57] Moved most files under to lib/mack
• [#56] mack-more: Added Mack::Utils::RegistryMap
• [#55] mack-more: mack-facets: Mack::Utils::Registry is now Mack::Utils::RegistryList
• [#54] Added DataMapper 0.9.3 support
• [#52] mack-more: mack-[orm] should require mack-[orm].rb using its full path.
• [#51] Application generator should generate orm support in the right place
• [#50] Mack will now have 2 environment files: mack_core and mack_app.  Mack.rb will load both files, but it gives other module chance to load just the core files and not the application’s files.
• [#49] Making sure the orm tasks is available when orm_support is removed from the app_config
• [#49] mack-active_record:  mack-active_record.rb will require mack-active_record_tasks.rb
• [#49] mack-data_mapper:  mack-data_mapper.rb will require mack-data_mapper_tasks.rb
• [#49] Updated warning message if orm is defined in app_config (i.e. user only needs to require mack-[orm_name], instead of both that and mack-[orm_name]_tasks).
• [#48] rake generator:list now displays the correct names for the generator tasks.
• [#47] rake gems:* tasks now work, and no longer require mack_ruby_core_extensions
• [#46] Calling .to_param on nil now raises a NoMethodError exception.
• [#45] rake stats task now works with Test::Unit::TestCase
• [#44] Mack::Runner has now been extended to allow for greater extension flexibility.
• [#43] Added a Mack::Utils::Registry class to allow for easy creation of registries.
• [#42] Sessions can now be turned off globally using the app_config.mack.use_sessions switch.
• [#41] Deprecate orm_support.rb
• [#38] There is now a registry of Controllers that are in the system.
• [#36] Renamed the initialize method in the Mack::Controller module to configure_controller. This gives
•   control of the initialize method back to the class.
• [#34] Mack::l10n now raises exception with a fully qualified name.
• [#33] mack-active_record now requires ActiveRecord 2.0.2 explicitly, not >=2.0.2
• [#31] Added support for ruby-debug.
• [#26] Log Coloring for console output.
• [#24] Added mack-notifier support.
• [#18] Added Page caching.
• [#14] Data Factory
• [#7] Added support for Extlib::Hook in a few places.
• [#6] RJS support
• Added a rake tmp:clear task.
• gem: application_configuration 1.5.1
• gem: ruby-debug 0.10.0
• gem: data_mapper 0.9.3

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

In addition to the great new features, a lot of bugs have been worked out, and more of the API has solidified further. Because of some of these changes I’ve posted an upgrade guide from 0.5.x to 0.6.0. This guide can be found on the wiki. 

This guide is meant to make upgrading as quickly and as a painless possible. There are a couple of big changes, but they should be fairly simple to make.

I’m very happy with this release, it’s been long toiled over, and it shows. It’s very stable, fast, and fun. I think everyone is really going to like it. 

As more info about the release becomes available, I’ll keep everyone posted.

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!

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.

Why is this you might ask? Why aren’t I going to get Mack support for DataMapper 0.9.1 out there, if it already works. Great questions. The answer is simply this, migrations. I’ve spent most of the weekend hanging out with a great guy by the name of Adam French. Adam is one of the core developer’s of DataMapper. As a matter of fact, I just left Adam after we spent a couple of hours in the hotel bar writing a gem called, dm-voyeur, to allow for ‘observing’ of DataMapper::Resource objects.

Anyway, as I’ve been hanging out with Adam I’ve been trying to upgrade the Mack migration generator script to build the new style format for DataMapper 0.9.1. What I found though, was that migrations have a minor flaw, you have to write the SQL for the column! That means they aren’t portable! This bit me in the butt when I had a migration I wrote against Postgres that would run, but wouldn’t give me the results I expected in SQLite3. After spending most of the weekend complaining to Adam about this, he kindly pointed out that I have full commit access to DataMapper, and I should probably just fix the bloody thing myself. So that’s what I’ve done.

The great news is that migrations are now pretty sweet. The bad news is I’m not going to release Mack support for DataMapper 0.9.x until they put out the next release so everyone in the Mack universe can have a nice experience using the new migrations. Although I don’t know just when the next release of DataMapper will be, I estimate that it will be relatively soon. Keep an eye on this space.