models_to_utc – Rails >= 2.1

The Skinny…

This plugin adds a “models_to_utc” method to your migrations that converts all legacy :datetime and :timestamp records in a model to UTC.  It also provides the “revert_models_to_utc” method for your down migration.  The method takes two arguments:

1. One or more models
2. The time zone that you are converting from – run rake time:zones:all|local|us for a list

So, if your application was originally developed for the Eastern US time zone, it will add 4 or 5 hours (depending upon DST) to each timestamp.

Migration Example

class MyUtcMigration < ActiveRecord::Migration

  class User < ActiveRecord::Base; end
  class Dog < ActiveRecord::Base; end
  class Cat < ActiveRecord::Base; end

  self.up
    models_to_utc([User, Dog, Cat], 'Eastern Time (US & Canada)')
  end

  self.down
    revert_models_to_utc([User, Dog, Cat], 'Eastern Time (US & Canada)')
  end

end

Git it!

The repository is located at GitHub:
http://github.com/bilson/models_to_utc/tree/master

Standard Disclaimer: Always thoroughly test on sample data to make sure this is performing the desired effect on your data. Patches welcome.

For me, out-of-the box time zone support is the most useful upgrade in Rails 2.1. For new applications, it just works. However, if your app was originally devised for a single time zone, there is still a bit of work ahead of you. You need to convert all of those timestamps in your database to UTC. If the app was originally developed for use in Iceland, then you’re done! Otherwise, read on…

I am in the process of migrating an app with about 20 different timestamps (outside of the created_at/updated_at) in various models. Leveraging the time zone support built into Rails makes it reasonably simple to update a number of timestamps with a migration. The example below is ugly, but seems to do the trick for a User model…

User.find(:all).each do |u|

  created_at, last_logged_in_at, last_appointment_at = '','',''

  %w[created_at last_logged_in_at last_assigned_at].each do |t|
    eval("#{t} = !u.#{t}.blank? ? (u.#{t}.utc - u.#{t}.in_time_zone('UTC').in_time_zone('Eastern Time (US & Canada)').utc_offset) : u.#{t}")
  end

  u.update_attributes(
    :last_lead_assigned_at => last_lead_assigned_at,
    :created_at => created_at,
    :last_appointment_at => last_appointment_at
  ) 

end

Add this task to the :db namespace in rails/railties/lib/tasks/database.rake

desc 'Pushes the schema to the next version. Specify the number of steps with STEP=n'
task :forward => :environment do
  step = ENV['STEP'] ? ENV['STEP'].to_i : 1
  ActiveRecord::Migrator.forward('db/migrate/', step)
  Rake::Task["db:schema:dump"].invoke if ActiveRecord::Base.schema_format == :ruby
end

Then add this method to the Migrator class in rails/activerecord/lib/active_record/migration.rb

def forward(migrations_path, steps=1)
  migrator = self.new(:up, migrations_path)
  start_index = migrator.migrations.index(migrator.current_migration)

  return unless start_index

  finish = migrator.migrations[start_index + steps]
  up(migrations_path, finish ? finish.version : 0)
end

Now to step forward through your migrations simply run:
Step forward 1 migration

rake db:forward

Or…step forward 7 migrations

rake db:forward STEP=7

git clone git://github.com/bilson/conman_demo.git

You release the site and it looks perfect…for the first two weeks. Then the client starts to add and revise content. You’ve given them carte blanche to add all kinds of content…headings, colors, underlines, strike-throughs, images, etc. Before long the site looks like it has been designed in 1995 or on some hallucinogenic drug.

You’ve given too much control and power to the client. In practice, this usually results in one of three outcomes:

1. You have given the client so many options that they are completely confused about how to use any of them. Therefore, they don’t use them and see little value in the work you have completed for them. And they aren’t all that pleased with you.
2. You have given the client so many options that they are completely confused about how to use any of them. Yet they push forward and make changes, butchering the site and code and getting frustrated each time they want to make a change. And they aren’t all that pleased with you.
3. Your client is ecstatic about the plethora of options you have given them. They make constant changes to the site and even send you congratulatory emails about the changes they have made. They also have no design sense and think that “rainbow” is a clean and powerful color scheme. Your client loves you!

Now I am assuming that a major factor in your client shelling out the dough for you to design this website was…for you to design this website. It wasn’t for you to design a pretty shell and for them to trample it. You need to take back control of your designs. The more you can strictly define what your client can and cannot do, the better chance that your client’s brand will stay intact and convey the intended message. If the site starts to look shoddy, the client is damaged. And you’re damaged too. You have one less site to display in your portfolio and one bad example of your work for all to see.

So how do you take back control while still allowing the client to update content? First, limits need to be set. Anything that is going to damage the design structure of the site just can’t be updated. Sorry. Second, there needs to be a way to update specific pieces of a page without disrupting said design structure.

Enter ConMan. Wow, was that ever a long and overly-dramatic lead-in. Anyway, ConMan is a Rails generator that allows you to do exactly what I have mentioned and to do it fairly easily. The system is broken into parts that are familiar to you if you are using Rails. They consist of…

Layouts – These are exactly what you think they are. You set up a basic layout for different page types and enter defaults for stylesheets, javascripts, keywords, descriptions, etc. You just place a placeholder named {content} in the layout wherever you want the unique page content to show up.

Stylesheets & Javascripts – You can manage your stylesheets and javascripts directly in the browser and call them out in your page layout.

Pages – These are simply set up by choosing a layout and entering your unique content. Meta info can be overriden, additional code appended to the area, the tag rewritten, etc. These pages will pull from the database, but they don’t have to. You can also choose to make the page refer to a page that is hard-coded into your application. This allows you to setup the page title, meta info and layout in the database and then simply refer to it in the controller of your application. That way all of your pages, from the database or not, are using the same page layout.

Snippets – You’ve seen snippets before. They are just reusable pieces of HTML that can be used in layouts and pages. However, these snippets are, dare I say, more flexible than what you may be imagining. There are a few different kinds of snippets:

1. Static Shareable Snippets: A basic static snippet that is reusable in any layout or page. Suppose we make a snippet that is just the Navigation portion of the website. It is the same in every layout. We just give this snippet a placeholder name…let’s called it “nav”. Then you can call this out anywhere with {snippet-nav}.
2. Dynamic Shareable Snippets: These are essentially the same as their static brethren. The only difference being that you can enter the {content} tag into any snippet and it suddenly becomes dynamic. This allows you to, from any layout or page, to add an instance of this snippet with unique content that will appear in place of that {content} tag. The instance will automatically be named with the ID of the record and will be something like {snippet-23}. Perhaps you have a sidebar structure that is used throughout the site that appears in various layouts, with very minor changes to the content within. This might be a good candidate for dynamic shareable snippets. Honestly, in practice, I haven’t found these to be overly useful.
3. Unshared Snippets: Lastly are the snippets that I find to be most useful in achieving the goal of limiting what clients can update on their site. An unshared snippet is basically just a snippet that is tied to a specific page on the site. These snippets are also automatically named by ID…{snippet-47}. You just call them out with the tag name in your page.

The upshot of #2 and #3 is that you can now have a snippet as small as a single letter and tie it to a specific page. And these snippets can be called out from a database or hard-coded page. In a hard-coded page you would simply use the “include_snippet” helper (ex. include_snippet(‘snippet-34′)). That way all of your snippets are managed online without having to touch the hard-coded page.

All of this is well and good, but this may sound slightly convoluted and trying to explain how to manage this to a client would likely be an exercise in futility. And, lest we forget, we are hired to make our clients lives slightly better and easier, not slightly worse and more complex. So we need to limit what the client sees. Luckily the structure we have built with the snippets allows us to do just that.

And the solution is a surprisingly simple one to implement. Since all of the snippets run through the same basic method before being written to the page, we can wrap this content with whatever we so choose. This creates an easy way to flip the site into “Edit Mode” by wrapping each dynamic or unshared snippet with a div with an id of “edit_mode” and a button at the top linking to the page to edit that specific snippet. The end result is that the client can look at their regular website and see 6 different updateable snippets called out right within the page and click on them to make an update. It might only be an update to a few words. Or it might be more. You have the option to set each snippet to be a simple text area or an FckEditor text area. The text area is usually the best option as it allows for the most control and least chance of the client messing it up.

Installing ConMan

Installation of ConMan is quite simple. It is really just a generator that will create the following models/tables:

• page_layouts
• pages
• snippets
• snippet_owners
• styles
• jscripts

Note: I will likely prefix these tables with a “cm_” in the future, as “pages” could easily collide with a table already existing in your application.

Git it:

git submodule add git@github.com:bilson/conman.git vendor/plugins/conman

Also, note that you will need Haml installed in your application for this to work
Get it here…
http://haml.hamptoncatlin.com/download/

Also, highly recommended (unless you don’t want to allow any fckeditor instances)
fckeditor plugin – svn://rubyforge.org//var/svn/fckeditorp/trunk/fckeditor

Note: If you are using the role_requirement and restful_authentication plugins there is some basic code commented out for your use in each of the controllers. There is also some example authorization code commented out in lib/conman.rb that limits who can view the site in “Edit Mode”.

STEP 1

script/generate conman

STEP 2
Add these routes to your routes.rb:

map.resources :pages, :collection => {:hardcoded_example => :get}
map.resources :page_layouts
map.resources :styles
map.resources :jscripts
map.resources :snippets
map.resources :snippet_owners, :collection => {:unshared_management => :get, :edit_single => :get}

STEP 3

rake db:migrate

STEP 4
Add this to app/controllers/application.rb…

include Conman
before_filter :edit_mode

Usage

You should now be able to navigate to the pages controller and see a sample layout, a database page example, a hard-coded example, various sample snippets and some stylesheets created for you.

ConMan is meant to fully integrate with the rest of your site rather than sitting out on an island by itself. I use it as the basis of my sites and build on top of both the administrative area and the public facing area. These two areas use layouts located within the app/views/layouts/conman folder. Any administrative areas can use the “conman” layout by entering the following into the controller…

layout "conman/conman"

The pages that will make up the public-facing portion of your website will use the following layout…

layout "conman/show_pages"

You can, of course, call this layout for specific actions with…

render :layout => 'conman/show_pages'

An action can reference a page from the database by simply calling out the specific id of the page. Here is the hardcoded_example action that will be automatically generated when running db:migrate…

def hardcoded_example
  @page = Page.find(2)
  render :layout => 'conman/show_pages'
end

Or, if the id is present in the URL, just call it like so…

def show
  @page = Page.find(params[:id])
  render :layout => 'conman/show_pages'
end

The main target of ConMan is to manage the content of a site with fine-grained control. However, given that it is meant to blend in with the rest of your application, one could easily only use some of the layout features, build on top and leave the rest. I will likely add additional features in the future, but will try to stay away from adding things that would force the developer to “buy-in” to a certain way to build their app.

Give it a run and give me some feedback…good or bad or really bad. Regardless, let your clients manage the content, not the design, of their site. Your client’s clients will thank you for it.

Another cool kid technology is OpenID. OpenID allows someone to create an account with an OpenID provider such as myopenid.com and then use that same login across multiple sites. After creating your account you will be provided with a unique ID. I happen to have an account with MyOpenID and my address is bilson.myopenid.com. Basically all I have to do to make use of this ID is to:

1. Login to myopenid.com with my username and password.
2. Login to any site that supports OpenID with just my OpenID username… bilson.myopenid.com.

Thus, in a future perfect world I could potentially login to myopenid.com when I get to work and then log into every other website I want to without ever having to enter a different username. And I wouldn’t have to enter a password for any of the sites. Sweet, magical technology.

Unfortunately, competition between the major web outposts are already starting to suck the productivity out of this technology. And WordPress is complicit in this sucking. See WordPress is very technologically advanced and, as such, they have also become an OpenID provider. In fact, by simply setting up a blog on WordPress you are automatically provided an OpenID ID. Mine happens to be bilsonrails.wordpress.com.

This is very nice of them and I appreciate their generosity. However, what if I already have an ID elsewhere (I do.) and I don’t want to accept their ID? (I don’t. Or I do…double negatives confuse me). Actually accepting or not accepting is not a problem. The problem is that I want to use my MyOpenID ID to login to WordPress and every other site. Unfortunately, WordPress does not itself allow OpenID logins. What?! They probably lack the technological know-how to support such functionality, right? Not hardly. They are simply being smart business people. Get everyone to use WordPress as their OpenID Provider and they have a reason to login to the site every day of their lives. Brilliant.

The problem that I see is that many large web players (see AOL, Blogger, Flickr, LiveJournal, Technorati, Yahoo) are also now OpenID Providers. And just like WordPress, they don’t “support” OpenID login on their own sites.

The eventual outcome of this is that OpenID becomes a technology for all the sites that nobody actually uses. But what about all of the sites you actually use? Sorry, you’ll need to enter your various usernames and passwords to enter those sites, but you can use one of your 47 OpenID’s to login into www.someboringuselesssite.com that you visit every 8 months.

Truthfully, I can’t fault any of these companies for this scheme. It is a flaw with OpenID as I see it. Ironic that decentralization is the culprit behind one major flaw of a technology aimed at centralization. This leads me to my one issue with my new favorite technology, Git. That is for another day though.

Thanks for nothing, WordPress! Well, other than the great blogging software that allows me to bash you.

Initially, I thought the following might do the trick…

add_column :my_table, :id, :integer, :null => false, :auto_increment => true

However, I quickly found that the auto_increment option is not actually an option to add_column after all. Consequently, my :id column was being created, but the value for each record was set to 0.

So it looks as though my only option was to resort to plain old SQL. The following seems to have worked nicely…

def self.up
  execute "ALTER TABLE `my_table`
              ADD COLUMN `id` INT(11) AUTO_INCREMENT NOT NULL FIRST,
              ADD PRIMARY KEY(`id`)"
end