That answer? Because no one else is. It’s stupid really, but it’s the truth. We’re all afraid to run our applications in 1.9 because we don’t know many other people that are. Because of that it makes it hard for you to make your application work with 1.9 because all those gems and libraries  you use aren’t 1.9 compatible, so you’re forced to keep running your app on 1.8. And so the cycle continues.

Enter Rails 3.0. Here is a major upgrade to the most prominent web framework in the Ruby community, and I would argue the reason that most of us got into Ruby in the first place. This upgrade will force us all to make some pretty severe changes to our applications to make them fully compatible.  The changes in ActiveRecord alone are so sweeping and massive that we, as a community, are going to have to put some serious time into upgrade our applications. Yet, despite this, we are all going to do it.

Why are we all going to upgrade to Rails 3.0? Because it  looks cool and sexy, and we want those great new features and all those performance enhancements to make our applications run faster. Which leads me back to Ruby 1.9.

In Rails 3.0 they are dropping support for Ruby 1.8.6 and below in favor of Ruby >1.8.7 and >1.9.1. I propose that Rails 3.0 becomes Ruby 1.9 compatible only. Think about it. What a perfect opportunity for us all. We are all going to have to upgrade the libraries and gems we maintain to support Rails 3.0 and we are going to be upgrading our applications to Rails 3.0, so why not go full steam into Ruby 1.9?

There is no better time than now to push forward into the future as a whole community. Let’s put Ruby 1.8 behind and reap the benefits of what Ruby 1.9 has to offer. What do you say? Can we do it? I think we can.

Recent changes in my career have meant that I have moved away from doing a lot o iPhone development, and because of that I no longer have the time, nor the desire, to keep maintaining a gem I’m no longer using.

So, because of that, I would to find a new home for the APN on Rails gem so that it gets the love and attention it so desires. Are there any takers out there? Is someone willing to take on the ownership of this, apparently, very useful gem? If you are willing to take it on, please let me know and we can workout the details.

Thanks to everyone who has said good things about the gem, and I’m glad that it has helped people get to using push notifications quicker, hopefully, one of you can take this project and run with it. Thanks again.

I’ve decided to just include my README file below to explain what it is, since it’s a bit lengthy, and I don’t feel like retyping.

This is still in it’s early stages, so use with care, but it does seem to be working for us on a daily basis. Let me know what you think!

What is Warp Drive?

Warp Drive is what Rails Engines wish they could be, and more! They kick Rails templates in the ass, and they beat keeping an ever evolving base Rails app up to date.

What are Rails Engines?

Rails Engines allow you to package up some of a Rails app (controllers, models, views, routes, libs) and put them in a plugin that can be included into a new Rails app, thereby giving it the functionality you had in the engine. That sounds good, but what about the downsides of using an engine? Well, you can’t override or extend any of the functionality from the engine in your main application. You can hack at the plugin, but now you’ve made it difficult to update. So what do you do if you want to add or alter a method to a controller or model? What do you do if you want to change the look and feel of a view? You have to copy everything into your main application. Boo!

Rails Engines also don’t allow you to package up migrations, assets, plugins, initializers, etc… All the fun stuff that you’ve come to know and love about a Rails application.

Enter the Warp Drive!

So what is a Warp Drive? Great question. To put it simply a Warp Drive is a standard, full featured, Rails application that you can easily bundle up into a Ruby Gem, and include into another Rails app. That second Rails app now has all the power of the first Rails. That is all there is to it.

Creating a Warp Drive.

Let’s assume we have an application that implements AuthLogic for handling user registration/authentication. We have controllers, views, models, plugins, initializers, configurations, migrations, tasks, etc… it’s a full featured fully functional Rails application, we call it authenticator.

We want to turn our authenticator application into a Warp Drive. We can do it in three simple steps, the first two steps you only need to do the first time, to set everything up.

1. $ gem install warp_drive
2. $ warpify
   That will add a little bit of code to your Rakefile. That code simply requires the Warp Drive gem, and gives you hooks to configure the gem of your Warp Drive application.
3. $ rake warp_drive:compile (rake warp_drive:install)This will either compile your gem for your (warp_drive:compile) or compile and install your gem (warp_drive:install)

That’s it! You should now have your Rails application bundled up and/or installed as a RubyGem!

Using a Warp Drive.

With your fancy new Warp Drive, authenticator, built and installed how do you use it in that new application your building? Again, it’s stupid easy, and it only takes one step, that only needs to be run once:

$ install_warp_drive authenticator

That will put a few lines of code in your Rakefile, so you have access to all the Rakefile tasks in your Warp Drive, and a line in your config/environment.rb so that it will load your Warp Drive when you launch your application.

That’s it! You’re done. Now you can run rake db:migrate to run the migrations from both your Warp Drive and your new application. Enjoy!

Overriding, Extending, and Other Such Fun Things

Overriding and Extending

You’ve been enjoying your new Warp Drive back application for a little while now, but you decide you really need to change an action in your controller, how do you go about that? Simple, just like you would any normal alteration to a Ruby class.

Example:
Here is what the action looks like in our Warp Drive UsersController:

  def new
    @user = User.new
  end

In our new application we can just open up the UsersController like this:

  class UsersController < ApplicationController

    def new_with_default_name
      new_without_default_name
      @user.login = 'default_name'
    end

    alias_method_chain :new, :default_name

  end

Viola! The same works for any thing else in the system, models, libs, etc… In our example we used alias_method_chain to retain the original method, but we could have completely rewritten the method as well.

You can also plop in a new view and it will override the view that was in your Warp Drive. The sky is really the limit.

Assets

You can easily bundle assets from your public directory in your Warp Drive. Just make sure they are in folders called warp_drive. Those folders will then be symlinked to your new project’s public directory when the application starts up.

Keep Those Rake Tasks Private!

We all them, Rake tasks we have created to help us do all sorts of things, and we usually don’t want them to ship. Well, Warp Drive has you covered there. Just place your tasks in folders called private and Bob’s your uncle they won’t be available in the compiled gem.

  lib/
    tasks/
      foo.rake
      private/
        bar.rake

In this example foo.rake will be available to clients of your Warp Drive, but bar.rake will not be.

Copyright (c) 2009 Mark Bates

While working on it I got to use some new technologies that I really haven’t had a chance to play, so I thought I would talk a bit about some of the ones I liked the most.

Authlogic

Love it! Finally a decent authentication system! The thing I love most about it? It doesn’t generate a lot of crap in your project. If I were to say one bad thing about it, it would be that it doesn’t generate enough in your project. I know that sounds silly, but it’s the truth. It gives you so much power, without having to generate a ton of lib code and crazy controller code, which is awesome. However, it would be nice if it had a generator that generated a ‘basic’ application for you. Just a little thing, apart from that, love it!

http://github.com/binarylogic/authlogic/tree/master

Cucumber/Webrat

I’m sure by now everyone has heard of Cucumber. I’m not going to pretend that I’m the first to that party! Over the last month or so I’ve really started to use it and it has completely changed my life. That’s not an overstatement.

Cucumber lets you write features and scenario in human readable format. Combine that with Webrat, which lets you do things like click buttons and follow links, you can write some amazing tests that look like something a project manager would write! Brilliant!

These tests beat the hell out of Rails integration tests. Trust me! I love watching Cucumber and Webrat click around my site while I just watch.

http://cukes.info/
http://github.com/brynary/webrat/tree/master

Web App Theme Generator

This cool little plugin helps you to quickly generate a very useful, and laid out, theme for your application. The themes would be familiar to anyone who has used sites like Lighthouse. They’re basic, but they are very well coded and get you on your quickly so you can have something that looks fairly decent.

My only gripe with this plugin is that it is a bit clumsy to use, but thankfully you don’t have to run it very often, only when you create a new controller/resource.

http://gravityblast.com/2009/07/30/2-minutes-admin-layout-with-rails-and-the-web-app-theme-generator/

Delayed Job

The last piece of tech is Delayed Job. I first discovered Delayed Job when I wrote about it in my book. It is a great way to handle and process background tasks. It’s easy, reliable, and scales really well. I’ve been using the Collective Idea fork of the project. It has a generator to create the migration you need. It also has a nice binary to run in the background on your server.

I’ve also been using a little gem I wrote that gives me hooks into Hoptoad, the is_paranoid gem, and a nice subclass for writing workers.

I have been completely enamored with Delayed Job from the first moment I used it, and I’m sure if you haven’t checked it out yet, and you do, you’ll feel the same!

http://github.com/collectiveidea/delayed_job/tree/master
http://github.com/markbates/delayed_job_extras/tree/master

There you go, that’s just a few things I’ve been playing with lately, that I think are going to become mainstays in any Rails project I work on. Hopefully this has given you a little for for thought on things you can use in your next project.

Installing/upgrading is easy:

$ sudo gem install apn_on_rails
$ ruby script/generate apn_migrations
$ rake db:migrate


It’s important to always run the migrations generator after each update to get the latest database schema needed for the the gem.

To use the new Feedback integration you have to first make sure that you update the new last_registered_at column when your iPhone application calls home. This column is checked against the timestamp Apple returns with the device token. If the last_registered_at is older than Apple’s date then the device is deleted, otherwise the Feedback is ignored.

To get and process the list of devices from Apple’s Feedback service just run the following Rake task:

$ rake apn:feedback:process

Enjoy!

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.

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/

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.

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

Back on March 26th Mack 0.4.0 was released. This release brought the first of three large distributed features, Distributed Routes. With 0.7.0 Mack fully realizes it’s goal of making it easy to write fully distributed web applications. There is a very nice wiki page, on our new wiki, that shows in detail how to use the new distributed features. That page can found here. Also, don’t forget to watch the screencast of the new distributed features that can be found here.

Distributed Objects

Distributed objects allow you to easily distribute access to your library and model code amongst any of your other Mack applications. Allowing this access is as simple as requiring the mack-distributed gem, adding a few lines to your configuration, and starting the mack_ring_server binary. ‘Client’ applications just need to require the mack-distributed gem.

Distributed Views/Layouts

With distributed views and layouts you can now share the look and feel from one application with all of your applications. Configuration and use is just as easy using distributed objects.

Form and HTML Helpers

People have been requesting more HTML and form helper methods, and we’re more than happy to comply. There are whole bunch of these new methods now to help you more easily build your applications. The generators have been updated to use these new methods, to make your job even easier. There is also now support for doing Date/Time drop downs, similar to Rails and Merb.

‘Tell’ Messaging

Rails folks know ‘tell’ messaging as ‘flash’ messaging and Merb folks know it as ‘message’ messaging. We went with ‘tell’. Tell messages are cleared after any non-redirect request. They’re a great way to send a simple message down to the client.

New Wiki

With this release there is also a new wiki at, http://www.mackwiki.com. This new wiki, incidentally built using Mack 0.7.0, will house all the tutorials and how-to’s for Mack. There are a few entries from the old wiki that still need to brought over during the next day or two.

Changelog:

• [#114] Javascript link_helper
• [#112] Error generating mack application
• [#109] DataMapper 0.9.4
• [#103] Log colors for the console are now configurable per log level.
• [#102] New association method in data_factory
• [#101] Update to file upload testing (build_file -> file_for_upload, and multipart support in put)
• [#100] Inline routing parameters are being mutated
• [#99] Upgraded to facets 2.4.3
• [#98] Fixed mack-facets not being loaded before app_config files.
• [#97] Fixed sessions only working with ‘local_memory’ mode
• [#96] Distributed Views module now uses file cache
• [#92] Removed deprecated app_config.orm code.
• [#91] Fixed Mack blowing up if there is no config/initializers/gems.rb file.
• [#90] Added deprecation system.
• [#89] rake gems:* will now only display warning if any gem required is not installed (and not break)
• [#88] Implemented pending SQLite3 tests in mack-activerecord
• [#87] Refactored out common ORM code from mack-active_record and mack-data_mapper into mack-orm
• [#86] stylesheet link helper
• [#85] Refactored out Mack::ViewHelpers::HtmlHelpers into Mack::ViewHelpers::HtmlHelpers, Mack::ViewHelpers::FormHelpers and Mack::ViewHelpers::linkHelpers
• [#84] Added Mack::Distributed.lookup(url) to retrieve specific distributed services.
• [#83] Added mail_to HTML helper.
• [#82] Added ACL support to mack-distributed
• [#81] Fixed sessions working with redirects in testing
• [#80] Distributed objects present both the DRb::DRbObject inspect and the original object’s inspect when asked.
• [#79] Renamed app_config.mack.use_distributed_routes to app_config.mack.share_routes
• [#76] Move mack_ring_server to mack-distributed
• [#75] Left over mack-distributed rake tasks
• [#74] Added optional feature to disable initialization logging.
• [#73] Tests no longer use the functional/unit directories
• [#69] Added ViewHelperGenerator and ControllerHelperGenerator
• [#68] Transactional support in mack-AR
• [#67] Added test:setup tasks for active_record and data_mapper
• [#62] Removed const redefined warnings if mack-l10n is used along with mack-activerecord
• [#39] HAML 2.0.2 support
• [#28] Refactored out encryption into the mack-encryption gem.
• [#25] Added ControllerGenerator
• [#19] Added HTML form helpers
• [#15] File upload testing support (ability to do multipart form post in testing)
• [#11] Distributed Layout/Views
• [#10] Added distributed objects to mack-distributed.
• [#8] Move distributed code from mack-core to mack-more
• [#5] Added tell messaging
• gem: genosaurus 1.2.2
• gem: haml 2.0.2
• gem: addressable 1.0.4
• gem: facets 2.4.3
• gem: data_mapper 0.9.4