Meta Bates

I’ve always been a big proponent of Ruby 1.9, I make no bones about it. My question is why wouldn’t you be? It’s faster, more powerful, easier to use, and makes things a lot clearer and cleaner than 1.8. So why then are pretty much all of us still running our applications on 1.8.x? Great question, and as far as I can tell there is really only 1 answer.

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.

Well folks, it’s been a long road, nearly a year since I presented the idea for “Distributed Programming with Ruby” to Obie Fernandez in a hot tub in Florida, but finally my book is done, dusted, back from the printers and available for purchase from a variety of places, include Amazon.com!

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!

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.

So this week I took a small break away from Mack to build another library, Genosaurus. I found that in Mack I had basically written a generator system, so I extracted it out into a stand alone library that anybody can use, and I called it Genosaurus. Genosaurus is, in my opinion, an incredibly easy to use generator framework. Let’s be honest, we’ve all basically built a generator system at one point or another, so I’ve just wrapped it up nicely. The next release of Mack, due out the end of this week, will have all it’s generators converted to use Genosaurus. Let’s take a look at a section of the README for Genosaurus:

Implied Manifests

The easiest way to use Genosaurus is to let it do the work for you. Let‘s looked at what‘s called an ‘implied’ manifest:

  dir:
    simple_generator.rb
    templates:
      hello_world.txt.template

That‘s our folder structure. Now let‘s look at simple_generator.rb:

  require 'rubygems'
  require 'genosaurus'

  class SimpleGenerator < Genosaurus
  end

Now if we run that generator:

  $irb: SimpleGenerator.run

We should get a file called hello_world.txt generated in the current directory. Yes, it truly is that simple! With implied manifests our directory structure under ‘templates’ tells the whole story, and Genosaurus is smart enough to figure it out. All the file names, and the same goes for folders, need to end in .template, and Genosaurus will do the rest. All the files will go through ERB before they generated, so you can put all your lovely little dynamic goodies in there. File, and folder, names also get run through ERB so you can even make the file name dynamic too! Let‘s look at a more complex example:

  dir:
    complex_generator.rb
    templates:
      app:
        views:
          <%=param(:name).plural%>.template:
            hello_world.html.erb
        models:
          <%=param(:name)%>.rb.template

Let‘s run our complex_generator.rb file:

  require 'rubygems'
  require 'genosaurus'

  class ComplexGenerator < Genosaurus
    require_param: name
  end

Now if we run that generator:

  $irb: ComplexGenerator.run("name" => "user")

Now you should end up with the following:

  app:
    views:
      users:
        hello_world.html.erb
    models:
      user.rb.template

In the ComplexGenerator we told Genosaurus that we are requiring that the parameter, name, be passed into it. We are then using that parameter to generate the names of some files and folders. Pretty cool, eh? See how simple that is.

Explicit Manifests

Explicit manifests are used when there is a manifest.yml supplied at the same level as the generator. If there is a manifest.yml file then implied manifests are not used. This means you have to define the entire generation process. This is great if you have a pretty complicated generator, as the manifest.yml is also sent through ERB before being loaded. Let‘s look at the manifest.yml file for our simple_generator example:

  template_1:
    type: file
    template_path: <%= File.join(templates_directory_path, "templates", "hello_world.txt.template")
    output_path: hello_world.txt

Pretty simple. We give the template a name, template_1, it really doesn‘t matter what it is, but Hash objects need keys. The ‘type’ parameter is either file or directory. The template_path is the path to the template. Finally, the output_path is the where you want the file to be generated. Let‘s look at our more complex example. We can change the directory structure a bit, since we really don‘t need ERB in the file names now:

  dir:
    complex_generator.rb
    templates:
      hello_world.html.erb.template
      model.rb.template

Our manifest.yml file would look like this:

  hello_world_template:
    type: file
    template_path: <%= File.join(templates_directory_path, "templates", "hello_world.html.erb")
    output_path: <%= File.join("app", "views", param(:name).plural, "hello_world.html.erb") %>
  model_template:
    type: file
    template_path: <%= File.join(templates_directory_path, "templates", "model.html.erb")
    output_path: <%= File.join("app", "models", "#{param(:name)}.rb") %>

This will generate the exact same thing as our implied manifest.

I’ve been asked by people why I’m not using spec tests to test Mack. I’m currently using just plain old regular unit tests for my tests. It’s a good question, but not really a valid one, I think. Should it matter what type of tests I’m using as long as I’m testing? Tests are tests. The framework you use to do your tests is moot as long as the tests you write are good, solid tests.

I jumped on the spec test bandwagon about a year or so ago. I forced my whole team to start writing in nothing but spec tests. The team, is still not impressed. If I were to tell them we weren’t using spec tests anymore, they would be EXTREMELY happy with that.Spec tests are certainly prettier than ‘regular’ tests. I’ll give you that. They are more ‘human readable’. With that said I find assert_equal to be fairly easy to read.

So why do I use regular tests, and not spec tests? A couple of reasons. First, they’re there and built right in to Ruby, ready to go, no new gems or syntax to learn. They’re fast. They are faster than spec tests. I see it everyday at work. I can also, and this one is HUGE, run just a single test or a regex’d series of tests. I really love that last bit. I have yet to find a way to do that, easily, with spec tests.

Again, how people write tests doesn’t really matter so much to me, it’s just that they write them. Testing is too easy in Ruby, there’s just no reason for not writing them.