Fixtures, for those who don’t know, are YAML files that contain YAML-ized versions of objects that then get loaded into the test database when you run your test suite. These objects can then be pulled back from the database during your tests. Sounds great, doesn’t it? Well, not everybody thinks so. One of the biggest problems with fixtures is they can very quickly get out of control. Keeping track of all the different scenarios your tests needs can get very confusing and frustrating to deal with.

So how do we fix this problem? Well, most developers have turned to using factories. Factories allow us to quickly build the data we need for each test, now the building of the data you need for your test is right there in a setup or before method. Easy to manage and keep track of. Now there are a plethora of different factory libraries meant to make this task nicer, a few of the popular ones are Factory Girl, Machinist, and Object Daddy. The problem with this approach, however, is that it can slow down your tests as you are building database objects for nearly every test, and as we all know, object creation and database inserting can be expensive.

So, what can we do to help solve both of these problems? Well, we can use both of these technologies. Together. Yeah, that’s right I’m saying you should use fixtures as well as factories. Sound crazy? Not really. Let me explain.

Most Rails applications have most, if not all, of their functionality behind a login. So whenever we’re testing some controller action that sites behind a login we need a user to login with. If we were using factories we would have a setup or before method that would create a new User object and save it to the database, and it would do that for every variant of the test, as well as every other test in our suite that needs a user object.

Why not, create one user object and use that repeatedly through our tests? What I like to do is stick one or two users in my fixtures, so that they’re there whenever I need one. I like to do this with most of my major models. Then, when I need to have some custom scenarios, I can break out the factories and build those custom scenarios.

So what does this achieve? Well, I’ve sped up my tests by already having a few objects in the database, and not having to create them (and roll them back) with each single test. I’ve also cleaned up my tests significantly by eliminating a lot of setup and/or before methods where these objects were being created. I’ve also eliminated the biggest problems with fixtures, that they can get overwhelming, because we are only keeping one or two objects in them and using factories for the rest.

I hoped this helped you to understand that we don’t have to throw the baby out with the bath water when it comes to fixtures and factories, we can use both. Not go forth and test! Test like your life depends on it (because it does!!).

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

During the past week or so I’ve spoken with many great companies and people. I’ve been fortunate enough to have a high degree of interest in what I can bring to the table. During those discussions I talked with a really nice guy at a what seems to be a really cool company, I won’t name names, because this isn’t about either the person or the company, but rather something the engineer said during our phone conversation that got me to thinking.

“We don’t have any tests because I couldn’t convince the company to allocate the time for them.” That statement really hung with me. After I got off the phone I started thinking really hard about that statement, and all I could think of was how testing is not an option and people shouldn’t need to be convinced to have time allocated to them.

As developers it is our responsibility to insist on testing. Always include testing in your time estimates. Never give the client (or your company) an option that includes a time estimate without testing. If a feature takes 2 days to code and a day to write tests, then your estimate is 3 days, never 2. You should never say, “Well, I can get it done in two days if I don’t write any tests.” That’s just an unacceptable thing to say. What you should be saying is, “That feature will take three days to code”.

I don’t feel I should sit here and tell you all the reasons why you should test, you should know them already, and frankly, they’re all very obvious! But, if you need a few bullet points to ‘convince’ your client, here are a few:

• Less bugs – The more tests you have the less bugs you will have. It’s just a fact. You won’t have 100% bug free code, that’s a nearly impossible goal, but you highly reduce the likely hood that as soon as you get your code into production your users will find all the breaking points of your code.
• Better maintainability, means faster feature turn around – When you have a large test suite it means adding, updating, or even removing features because a whole lot easier, which means it SAVES time! Why? Simple, you don’t have to go through and manually test every aspect of your code to make sure you didn’t break something elsewhere by adding that validation, or by refactoring that bit of code, etc… That translates into real $ savings.
• Test driven development saves time – this isn’t quite the same as my last bullet point. Imagine, if you will, you are writing a four step wizard in your application. If you write a few test scripts using something like Cucumber first before you write your code you can simply keep re-running those to make sure your code is working. If you don’t have those test scripts written then you continually have to keep going to a browser and entering all the information in each of the steps so you can test something in step four. Which one do you think takes longer, having a few test scripts you can run, or manually going through the four page wizard each time you make a change?
• It’s an investment – thinking of having test scripts like owning a house. When you don’t have tests and you just keep testing in the browser or the command line what you are doing is a kin to “renting”. There is money being spent, but at the end of the day you have nothing to show for it. You’ve spent hours “testing”, but tomorrow when you come in you have to do it all over again. When you spend those hours writing tests you are actually “buying” something. You have something to show for that time and money you’ve spent. Tomorrow, next week, next month, next year, those scripts will still be there, they’ll still be working for you, giving  you a return on your investment.

Well, I hope I have hopefully made a case to you the engineer as to why you should insist on testing. It’s the right thing to do, for you, for your application and for you client. If if anyone tries to give you grief about it, send them my way, I’ll sort em out!

The Boom Box.

I had a two cassette boom box, it was a beast of a machine. It was a ‘portable’ machine, meaning that it took 8 D batteries and a burly man named Attila to carry it. My recordings started simply on this machine. I would use the built in microphone to record my awful wailings and terribly out of tune acoustic guitar.

As my love of bands like the Beatles grew, so did my desire to capture my musical legacy the way I desired. It was around age 12 or so that the true experimentation began. I started playing around with using different input devices. I acquired a rather terrible Radio Shack microphone for the princely sum of $19.95. It sported, and I kind you not, a “built-in on/off switch”. That was actually a feature of this microphone. Actually it was the only feature of this microphone! My other trick for recording was to use a pair of headphones as a microphone. Did it sound good? Absolutely not! But it worked.

While the ‘quality’ of the recordings got marginally better with my new microphone and headphone combinations, I was lacking the studio trickery I so desired. I needed multitrack. If the Beatles had it, why didn’t I? Of course I couldn’t afford an actual multitrack recorder at this age, so again, improvisation proved key. I realized that if I recorded me singing and playing (at the same time), I could then pop that tape into the top player and record me playing and singing again while the first tape plays back into the second tape. How did it sound? How do you think it sounded??

The 4 Track!

At the tender age of 14 I managed to squeeze together enough allowance and saved up enough birthday/Christmas presents to get a Fostex 4-track cassette recorder. It was incredible! Here was what I had wanted all along. I could now discretely record all the wonderful parts (up to four) I could dream up!

I felt like the Beatles making Sgt. Pepper. Never before had anyone wielded such recording power (except for everyone else who had)! I was George Martin. I learned what every last knob on that machine did. I knew all of it’s tricks. I played with the varispeed knob. I recorded backwards parts. I was crazy.

Then I made a huge discovery! I could mix the 4 tracks down to stereo, pop that mix down back in the 4 track and then have another 2 tracks to play with! Brilliant!! The world was my musical oyster, and damn I was rocking it!

The 8 Track!!

When I was 18 years old I took a trip on the green line T to the Guitar Center on Comm Ave in Boston and purchased my musical destiny, a Tascam 488 8-track cassette recorder. Wow! I can still remember that day. Sitting on the T ride back to my house with that box on my lap. Giddy, excited, nervous, anxious, I can’t describe how I felt on that ride. I can say that it felt like it was going to take forever to get home!

I finally got home, rushed out to the little studio room my father and I had built in his garage and proceeded to hook it up. I had a 4 EQs per channel, inserts, sends, cues, all sorts of wonderful things! The sound was better, the quality higher, it even had DBX noise reduction! DBX! I still don’t know what it is, but I get very excited knowing it’s there!

That day I re-recorded a song I had recorded on my 4-track, that song was called, “I and You”. It was a dreadful song that I thought had to be the next big thing. And why wouldn’t it be? I recorded it on an 8-track!

The Computer Age.

In 1996 I moved to Liverpool, England to do my degree in Music. I moved all of my recording equipment across the pond with me. There was no way I was going to go to music college and not have a means to record all the amazing #1 hits I was going to write! The cosmos, on the hand, had slightly different plans for me. In the Spring of 1998 my house was broken into, and everything I owned was stolen, including my beloved 8-track recorder.

My world was shattered. I was a broken and lost man. How could this happen to me? Why Lord? Why?? Thankfully I managed to get a handsome of money from my parent’s insurance company to cover the claims, well, 75% of the total value anyway. Not great, but it was certainly better than nothing.

It was with this insurance money that I bought my own computer. My family had had computers since I was 8 or 9, but this one was mine, and I had plans for it. Since September of 1998 I have been recording music on my computer. Back then it was very difficult, now, it’s incredibly easy. I can record 8 tracks on my iPad should I wish.

So What?

Why am I talking about this now? I was recently doing some work around the house and stumbled across a rather large box full of cassette tapes. When I saw the box it all came flooding back to me. The countless hours spent recording. The incredible amount of songs I wrote, covered, or in most cases just butchered. They were all on these cassettes, and they were fading.

How long could these cassettes last? What would happen to those songs? What if I never heard them again?

Now, I’m under no illusions that these songs are well written, well recorded, or well performed. As a matter of fact, I know it’s the opposite of that. They were poorly written, recorded, and performed. But you know what? They’re mine, and I want to preserve them. That’s why I have undertaken an enormous project to catalog and digitally capture the music on those tapes.

It’s going to be an enormous project, that I know. I’ll do a cassette here, and a cassette there, and eventually I’ll have them all my computer and safely backed up. Will I remix them? Edit them? Release them? Chances are no to all those questions. That’s not really the point. I just want to know that those songs are safe. Maybe I’ll take a couple of them, polish them, and give them a new life with my band, but let’s see what happens, shall we?

I purchased a used Tascam 488 MKII on eBay, and tonight I transferred my first cassette. I’m excited about this project. Hearing these songs again brings up some great memories, and some awful ones. For example, tonight’s cassette contained six recordings. The first five I remember quite vividly. The sixth, however, is clear why I forgot. It was a ‘cover’ of “A Day In The Life” by the Beatles. But it consisted of a click track, a vocal, and 6, yes 6, tracks of drums!!! Oh, during the middle eight of the songs, two of the drum tracks switch to piano!! Why?? That’s a question I would like answered as well.

Anyway, expect a post every now and again about my on going battle with these cassettes. I’m sure there will be some funny, and occasionally horrific, stories to share about the experience.

PS. If anybody out there has some great earplugs they want to lend me, I’ll take them!!

Why do the open source projects always seem to get the ax? Well, let me start by saying that they don’t always get the ax, but they certainly jump to the top of the list. There are certain libraries I’ve written, cachetastic and configatron, are the two most prominent that I use day in and day out. They will always get the love the deserve. Then there are projects like APN on Rails. I wrote it because I had an iPhone app (no longer available) that I wanted notifications for, and there was nothing else available for Ruby to do the job. The plugin took off like crazy and I was overwhelmed with patches, questions, bugs, etc… That was great, and I was happy to help, for a time, but alas, I haven’t written an iPhone app for ages, and I just don’t have time to maintain a plugin that I wasn’t even using.

A while ago I realized that the best thing for APN on Rails, myself, and for the community was to find someone to take over the project so that it got the love it deserved. I put out the call and the good folks over at PRX (Public Radio Exchange) answered the call. The folks at PRX have written some great iPhone apps, including the very popular “This American Life” app.

So I’m happy to announce that the new official home for APN on Rails is now at: http://github.com/PRX/apn_on_rails. I ask that you continue to show the same support to PRX that you have shown to me over the life of this plugin.

Again, thank you to everyone, and thank you to Rebecca Nesson and the folks over at PRX for picking up the project and giving it renewed life.

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.

“Anyone working with distributed programming in Ruby will want this book.”

The only downside they saw in the book, was that they wanted it to be longer! I have to save something for the 2nd edition, don’t I?

If you haven’t purchased yours yet, I encourage you to do so. It’s on sale at Amazon.com right now.

If you have reviewed the book, or know of a review of the book, please pass it along.

It was an absolutely amazing experience and I can’t thank everyone involved with the project enough for all of their help, guidance, and having to put up with me over the past year.

I would go into detail about all the people I wish to thank, but I did that already in the book, and let’s be honest, you’re going to buy it and read it anyway, so I don’t want to ruin the surprise.

I’m sure you’ve already purchased your copy, but if you haven’t might I recommend you pop over to Amazon right now and pick yourself up a copy. They’re selling pretty well and you don’t want to miss out, do you? I didn’t think so.

If you are someone with a popular blog and you would like to do a review of the book, please drop me a line and I’ll see what we can do about hooking you up with a copy. Please understand, though, the publishers aren’t going to send out copies to everyone who requests them, so there will be a bit of vetting going on.

Also, if you have already purchased the book if you wouldn’t mind leaving a review of it on Amazon, that would be much appreciated. It doesn’t matter where you bought the book, if you could leave a review there, it will really make a difference. Thanks.

Buy “Distributed Programming with Ruby” Today!

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