Posts Tagged ‘gem’

CoverMe – Code Coverage for Ruby 1.9

Friday, August 13th, 2010

Ruby 1.9(.2) is an amazing language to develop applications in. It’s faster, more powerful, cleaner, and a huge improvement over Ruby 1.8.x. Because of those reasons every Ruby developer should move to this exciting new version of our language.

When making a move of this size it’s important to have the right tools to help us along. Unfortunately, one of the most useful tools as a Ruby developer, RCov, does not work with Ruby 1.9.
RCov, for those unfamiliar analyzes your code and tells you which part of your code was not executed. This is INCREDIBLY useful when hooked up to your test suite. While, it’s not the only metric you should use when determining how good your test coverage it, it certainly is a great first step to point out exactly which parts of your code haven’t been touched at all!

Enter CoverMe.

History

While working on a Ruby 1.9/Rails 3 project, and loving everything about it (except for the lack of RCov), I came across a post by Aaron Patterson (of Nokogiri fame). In this post he quickly outlined a very basic coverage tool using the new built-in Coverage module in Ruby 1.9.

After spending a morning playing with it, I was quickly able to grow the idea into something useful for the project. Later that day the company I was consulting for (BiddingForGood.com), and in particular their chief architect, Stuart Garner, told me to take a day or two and clean it up and release it for the world to use, and so here it is.

Features

Here is a brief overview of the features of CoverMe:

Index Page

  • Sortable column headers (File, Lines, Lines of Code, Tested %).
  • Searching/filtering by file name.
  • Filtering by coverage percent.
  • Color coded list of files to quickly see which ones are 100% covered, > 90% covered, or less than 90% covered.
  • Large color coded average coverage percent, for quick reference.

Detail Page

  • Line by line coverage report
  • Color coded lines to quickly see which lines where executed and which ones were not.
  • Side by side viewing with the corresponding test/spec file (if one exists).

See the README file for more information on installation and usage.

Thanks

I would just quickly like to give another quick thanks to Aaron Patterson for pointing out the Coverage module in Ruby 1.9 and inspiring this, hopefully, helpful little gem. Also another big thanks to Stuart Garner for pushing me to package this up and release it to the world.

Screenshots

Introducing Warp Drive for Rails

Wednesday, October 7th, 2009

At work recently we had a need to build a large Rails application that we then wanted to, for lack of a better word, subclass. Unfortunately there is no real good way of doing that. Rails Engines and templates have way too may limitations. We wanted to bundle up the entire Rails app (models, controllers, views, routes, migrations, configurations, libs, assets, etc… everything!), but there was no good way of doing that. Well, now there is, it’s called the Warp Drive.

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

APN on Rails 0.3.0 Released

Friday, July 31st, 2009

The latest version of Apple Push Notifications on Rails (APN on Rails) has been released. This release brings a few bug fixes, a new migration, and Feedback processing.

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!

Apple Push Notifications on Rails

Friday, July 24th, 2009

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.

Release 0.4.5

Monday, April 14th, 2008

Well, here it is! The release you all were waiting for, the one that finally gives migration support to Mack! That’s right, now whether you use ActiveRecord or DataMapper, you can use the familiar rake task ‘db:migrate’ to run your migrations. Yippie! The scaffold generator will also generate a migration for you, assuming you have ORM support enabled.

There’s still some work to go on this, like the ability to pass in command line args to the task to build the full migration for you, but it’s a start! It’s now pretty easy to get your app going.

Also in this release is a rewrite of the distributed routing functionality. It’s now been rewritten to use Rinda. This is going to be the standard for all the distributed functionality that will be coming Mack over the next couple of months. As more functionality lke this is developed, the more it will be wrapped in nice, easy to use APIs.

There’s also been some tidying up here in there in the code tree. For example, new applications don’t get generated with a boot.rb file. Looking at it, there’s really no need for it, since everything is done with Rake tasks.

Overall, I’m very happy with the release, and I feel that this release definitely makes Mack a VERY useable framework because of the migration support. Enjoy!

Changelog:

  • Removed boot.rb file. It was unnecessary.
  • When a new Mack application is generated the Rakefile that gets generated is stamped with the Mack gem version used to create it. This ties the project to that gem. This can, of course, be upgraded as new Mack gems come out, but it’s a good way of tying your app to a specific revision of Mack.
  • Added support for migrations for both ActiveRecord and DataMapper. DataMapper migration support requires DataMapper 0.3.0 gem. Please keep in mind, though, that DataMapper 0.3.0 has a serious bug in it, which may prevent you from using it. Please see http://www.mackframework.com/2008/04/09/horrible-bug-in-datamapper-030/ for more information.
  • Rewrote distributed routing support to use Rinda inside of plain old DRb. This makes for an almost zero configuration usage.
  • Added: mack_ring_server binary to start a Rinda ring server for use with distributed routing.
  • Sqlite3 is now the default database for Mack applications configured with ORM support.
  • Added a test helper method, rake_task, to aid in the testing of Rake tasks.
  • Added: rake generate:migration name=<migration_name>
  • Added: rake db:migrate
  • Added: rake db:abort_if_pending_migrations
  • Added: rake db:rollback
  • Added: rake db:version
  • Added: rake mack:ring_server:start
  • Added: rake mack:ring_server:stop
  • Added: rake mack:ring_server:restart
  • Added: rake mack:ring_server:services:list
  • gem: application_configuration 1.2.2
  • gem: daemons 1.0.10