Archive for the ‘General’ Category

Ruby 1.9 & Rails 3.0

Monday, February 8th, 2010

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.

APN on Rails Needs a Home

Monday, December 21st, 2009

Hey there everyone, recently I have been getting a lot of requests for bug fixes and new features for the APN on Rails gem that I wrote. While I appreciate that the gem is getting a lot of use and helping a lot of people out, I, unfortunately, no longer have the time to maintain the gem.

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.

First Book Review is a 5-Star One!

Thursday, November 19th, 2009

About.com became the first, that I know about, to review my book, “Distributed Programming with Ruby”. What a great first review to have as well. They rated the book 5 out of 5 stars! The review can be found here.

“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.

Distributed Programming with Ruby – Now Available

Thursday, November 12th, 2009

Distributed Programming with RubyWell 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!

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