( Source: the mongoid cheatsheet )
  class User
include Mongoid::Document
( Source: the mongoid cheatsheet )
  class User
include Mongoid::Document
| # autoload concerns | |
| module YourApp | |
| class Application < Rails::Application | |
| config.autoload_paths += %W( | |
| #{config.root}/app/controllers/concerns | |
| #{config.root}/app/models/concerns | |
| ) | |
| end | |
| end | 
| class PostsController < ActionController::Base | |
| def create | |
| Post.create(post_params) | |
| end | |
| def update | |
| Post.find(params[:id]).update_attributes!(post_params) | |
| end | |
| private | 
| shared_examples_for "driver with javascript support" do | |
| before { @driver.visit('/with_js') } | |
| describe '#find' do | |
| it "should find dynamically changed nodes" do | |
| @driver.find('//p').first.text.should == 'I changed it' | |
| end | |
| end | |
| describe '#drag_to' do | 
| class Module | |
| # We often find ourselves with a medium-sized chunk of behavior that we'd | |
| # like to extract, but only mix in to a single class. | |
| # | |
| # We typically choose to leave the implementation directly in the class, | |
| # perhaps with a comment, because the mental and visual overhead of defining | |
| # a module, making it a Concern, and including it is just too great. | |
| # | |
| # | |
| # Using comments as lightweight modularity: |