Living Without script/generate
One thing that's great about working with Rails is that it's really easy to generate the boilerplate for your project, and you also have a well defined directory structure to start with. When writing standalone scripts, you'll need to do most of that stuff by hand. Luckily, it's not a particularly hard thing to do.
What follows are essentially several recipes for how to handle some of the tasks that the generators typically do for you. Feel free to skip by the ones you already are comfortable with.
Before hooking everything up, it is worthwhile to set up a basic directory layout for your project. EarGTD's looks like this:
data/ ear_gtd.db test_ear_gtd.db lib/ ear_gtd.rb test/ test_ear_gtd.rb Rakefile earGTD
For a simple app, this is about all we need. Usually when code is actually distributed, the scripts you can run from the command line will go in a folder called
bin/, but we skipped that step for simplicity.
Otherwise, this structure is fairly common among Ruby projects:
lib/ holds your library files,
data/ holds any of the projects data files,
test/ your unit tests, and your
Rakefile will go in the top-level directory.
There's nothing mandating this project layout, if you want to put all your code in one big file, including your tests and data, Ruby will not stop you. Still, the conventions are handy, and many tools rely on them in order to function properly.
Connecting to a Database
When working with Rails, you normally stash your configuration information in
config/database.yml, but when using
ActiveRecord standalone, you have to do a tiny bit more leg work.
Below is an example of how to convert the YAML configuration to a Ruby call.
development: adapter: sqlite3 database: db/my_database.sqlite3
ActiveRecord::Base.establish_connection( :adapter => :sqlite3, :database => "db/my_database.sqlite3" )
As long as this code is defined before you try to work with your model data, ActiveRecord (AR) will work as normal.
Though it's not really necessary, it's also pretty trivial to emulate the rails style config file approach by just feeding a parsed YAML file to
Fun Ruby stuff: The YAML library
Let's say you have a YAML file called
config/database.yml that looks like this:
adapter: sqlite3 database: data/ear_gtd.db
If you wanted to use this to configure AR, you'd just do:
require "yaml" ActiveRecord::Base.establish_connection(YAML.load_file("config/database.yml"))
The loaded YAML file actually just represents a Ruby
Hash, so you can pass it directly to
Of course, it's often fine just to keep everything in Ruby and not worry about configuration files.
Database Schema Definition
For small standalone apps, you probably won't need the power of migrations. Still, it is nice to not have to write SQL when you can avoid it. This is where
ActiveRecord::Schema comes in.
The relationships for EarGTD are extremely simple. Contexts and Projects both have many tasks. The code below is what I'm using for my schema definition:
ActiveRecord::Schema.define do create_table :tasks do |t| t.column :description, :string t.column :status, :string t.column :context_id, :integer t.column :project_id, :integer end create_table :contexts do |t| t.column :name, :string end create_table :projects do |t| t.column :name, :string end end
As you can see, aside from the explicit method call, the code you write is identical to that which would go in migrations.
ActiveRecord::Base.establish_connection, you have the tools you'll need to use AR outside of Rails. Model definitions work exactly the same way as they do in Rails, so there is nothing special to worry about there.