How do you update the locate db again? GOTO 11 and return
sudo /usr/libexec/locate.updatedb (receive warning, “the Lord will kill you for running as root”)
Why am I doing this?
I know, I’ll write a funny post on how great it is to be a programmer and how 90% of your time is debugging your system or your code (because no one’s ever written about that before)
Let’s go over the steps again, start from the beginning
rake test:benchmark (database structure loads with errors, but the test runs; what?!)
“rake aborted: undefined method `use_transactional_fixtures=' for Test::Unit::TestCase:Class"
edit test_helper.rb: replace Test::Unit::TestCase with ActiveSupport::TestCase
rake test:benchmark (it works: “wall_time: 5 ms”)
GOTO 32 and return
Why are memory, objects, gc_runs, and gc_time all zero?
Move the untarred directory to your preferred location; this will be SCALA_HOME
Modify ~/.profile (or wherever you modify your PATH variable):
SCALA_HOME=/path/to/your/scala/directory
PATH=$SCALA_HOME/bin:$PATH
$> source ~/.profile
Done.
You should now be able to run the Scala interpreter ($> scala) from the command line. I've only just started with Scala so I don't know about compiling and deploying and all that good stuff yet. Hopefully that's in the documentation somewhere.
The message here is that with automated tests, we don’t have to worry about code being fragile. We can try out some stuff we think might work, and test it in seconds. We can be more courageous with our coding, and not have to code with cotton gloves on. — Test Driven Development
In the last episode I started my Rails code, committed it to a Git repository, and released my first deployment with Capistrano. In this episode I’m going to start my first feature by writing some tests and then implementing the code.
Now edit RAILS_ROOT/features/support/env.rb. This file was created when we ran script/generate cucumber. We need to change a few lines. Here is what my env.rb file looks like after editing.
# Sets up the Rails environment for Cucumber
ENV["RAILS_ENV"] = "test"requireFile.expand_path(File.dirname(__FILE__)+'/../../config/environment')require'cucumber/rails/world'require'cucumber/formatters/unicode'# Comment out this line if you don't want Cucumber Unicode supportCucumber::Rails.use_transactional_fixtures# Comment out the next two lines if you're not using RSpec's matchers (should / should_not) in your steps.require'webrat/rails'require'cucumber/rails/rspec'
We can add autotesting capability by installing the ZenTest gem. Autotest re-runs our tests after every code change, greatly speeding up our testing process. After getting the gem installed, we need to set some global variables so autotest knows to run our RSpec and Cucumber tests. Open up your .bash_profile file (usually located in your user’s home directory on your system). Add the following lines to the bottom of the file.
exportRSPEC=trueexportAUTOFEATURE=true
Additionally, if you’re on a Mac, I think it’s worth setting up Growl notifications for autotest. It’s not a requirement for testing or even using autotest but it’s a nice enhancement. Search Google for “autotest+growl” and you’ll find a number sites that will show you how to set it up.
Note: Growl notifications currently don’t work with Cucumber but they do work with RSpec and we will get into using RSpec eventually.
Let’s write a feature test to check our output from the last episode. If you remember, all we did was set up our home page to say “Hi.” I’m going to write a test to make sure it says that.
Open up the RAILS_ROOT/features/manage_pages.feature file. I’m writing my test like so:
Feature: First TestIn order to prove that I can write a quick feature
Harry
wants to write a simple test
Scenario: Friendly home page
Given I am on the home page
Then I should see "Hi."
Now I save that and run the test with rake:
$> rake features
(in/Users/harry/Sites/jetrecord)
Feature: First Test # features/manage_pages.feature
In order to prove that I can write a quick feature
Harry
wants to write a simple test
Scenario: Friendly home page # features/manage_pages.feature:6
Given I am on the home page # features/manage_pages.feature:7
Then I should see "Hi."# features/step_definitions/webrat_steps.rb:831 scenario
1 step skipped
1 step pending (1 with no step definition)
You can use these snippets to implement pending steps which have no step definition:
Given /^I am on the home page$/do
end
So the test ran but didn’t pass because I don’t have a step defined that tells Cucumber how to get to the home page. Thankfully, it gives me a snippet of code at the end of the output there. I open up RAILS_ROOT/features/step_definitions/page_steps.rb and add that in, filling it in with the code it needs to fulfill that step.
Given /^I am on the home page$/do
visit '/'end
Quite simply, I’m telling Cucumber to visit the URL that looks like ‘/’, which is the home page. I run the test again.
$> rake features
(in/Users/harry/Sites/jetrecord)
Feature: First Test # features/manage_pages.feature
In order to prove that I can write a quick feature
Harry
wants to write a simple test
Scenario: Friendly home page # features/manage_pages.feature:6
Given I am on the home page # features/step_definitions/page_steps.rb:1
No route matches "/" with {:method=>:get}(ActionController::RoutingError)[stacktrace info]1 scenario
1 step failed
1 step skipped
rake aborted!
Okay, we’re getting somewhere but we didn’t move very far. Cucumber barfed because it was looking for a route defined by the Rails application. Cucumber runs in the context of the Rails application, not of the whole site architecture. It doesn’t care that I have an index file in the public directory because it’s not actually crawling my web site like a browser would.
This is not necessarily a bad thing. If I wanted I could install Selenium, hook into it via Cucumber and re-run the tests. This would catch my index.html page because Selenium acts like a web browser. Eventually, I can see myself doing that because I’m going to need to test some Ajax interactions. But right now it’s not necessary.
In order to run my application I need to remove the index file anyway, so the real solution is to define my home page in Rails and then test again. To do that I need to add a route to my RAILS_ROOT/config/routes.rb file. Then I need to define the controller and a view for the home page.
Alright. One last thing. We need to rename or remove the public/index.html file. I’m just going to remove it. Then we try the test again.
$> git rm public/index.html
$> rake features
(in/Users/harry/Sites/jetrecord)
Feature: First Test # features/manage_pages.feature
In order to prove that I can write a quick feature
Harry
wants to write a simple test
Scenario: Friendly home page # features/manage_pages.feature:6
Given I am on the home page # features/step_definitions/page_steps.rb:1
Then I should see "Hi."# features/step_definitions/webrat_steps.rb:831 scenario
2 steps passed
Great! It’s working. Two passing steps (the two dots at the end) and autotest is still running, waiting for me to do something stupid. I’m going to introduce an error into home.html.erb.
# app/views/pages/home.html.erb
Hello.
And then back to the terminal.
/opt/ruby-enterprise-1.8.6-20080810/bin/ruby /opt/ruby-enterprise-1.8.6-20080810/lib/ruby/gems/1.8/gems/cucumber-0.1.15/bin/cucumber features --format progress --format autotest --color--out/var/folders/f1/f1HkdqHjFe43ByUhxU-FO++++TI/-Tmp-/autotest-cucumber.5265.1
.F
Failed:
1)
expected: /Hi./m,
got: "<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html>\n <head>\n <meta http-equiv=\"Content-type\" content=\"text/html; charset=utf-8\" />\n <title>Hello</title>\n\n </head>\n <body>\n Hello.\n </body>\n</html>"(using =~)
Diff:
@@ -1,2 +1,2@@
-/Hi./m
+"<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Transitional//EN\"\n\"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\">\n<html>\n <head>\n <meta http-equiv=\"Content-type\" content=\"text/html; charset=utf-8\" />\n <title>Hello</title>\n\n </head>\n <body>\n Hello.\n </body>\n</html>"[stacktrace info]
./features/step_definitions/webrat_steps.rb:84:in`Then /^I should see "(.*)"$/'
features/manage_pages.feature:8:in `Then I should see "Hi."'
And that’s how it works. We write a test, it fails, we write some code to pass the test, it passes.
I have to apologize. This post has already become too long. I like the direction it took but I don’t think moving on to writing an actual Jetrecord feature would be wise right now. So, really, next time I’m going to write tests for the first feature. I’ll even include some RSpec in there.
Coming Up in the Next Episode
No more rhymes now, I mean it. I’m going to write some tests for the first feature. Until next time, cheers and happy flying.
Material You May Find Useful Related to This Episode
What Mayer thinks will be essential for continued innovation is for Google to keep its sense of fearlessness. “I like to launch [products] early and often. That has become my mantra,” she says. She mentions Apple Computer and Madonna. “Nobody remembers the Sex Book or the Newton. Consumers remember your average over time. That philosophy frees you from fear.” — Managing Google’s Idea Factory
In the last episode I briefly sketched out what I want to build. In this episode I’m going to start the project by creating a Git repository and deploying a test release with Capistrano.
First, I changed my mind about setting up the complicated user management system from the beginning. I realized that I would be violating one of the tenets of Agile/XP: YAGNI. It reminds us to keep focused on the current feature and save details of any related features for the stories that describe them. Flights don’t need to know about the implementation details of users. Therefore, I’m only going to worry about flights for the time being. When called for I will stub out a User model, authentication, et cetera.
Second, I forgot to add a couple gems that will help us write stories and integration tests: Webrat and FactoryGirl. Webrat is a library for writing tests that crawl your site in memory, visiting links, testing inputs, submitting forms, and so on. FactoryGirl is a library that replaces test fixtures with factories. You can install both with RubyGems. We’re not going to need them until the next episode; I just wanted to mention them now.
Some Conventions
$> is the command line prompt. Anything coming after it is a command that I’m typing into my terminal.
RAILS_ROOT is the root directory of the Rails app.
REMOTE is my remote server
Starting the Rails App
Depending on your personality this is either the best part of the project or the worst: the blank canvas. You installed Rails and all of the prerequisites I listed in episode 2. All of our hopes and dreams for a perfect app begin with this command:
$> rails jetrecord
I have set up my development environment to use Apache + Passenger to serve the site and have configured a virtualhost on my local machine to use “ld.com” for the site. (It doesn’t matter if ld.com actually exists or not. As far as my machine is concerned, it points to my local Rails app.) If you’re using Mongrel, Webrick, Thin, or something else as your development server you can run script/server from the RAILS_ROOT.
Since I’m using Apache and I’ve set it to launch at boot time I don’t need to use script/server. I can just browse to ld.com. When I do, I see this.
Great! We’re off and running.
Setting Up Our Repository with Git
Git is installed on my machine. To make a repository, I cd to RAILS_ROOT and do this:
$> git init
Initialized empty Git repository in/Users/harry/Sites/jetrecord/.git/
$> git status
# On branch master## Initial commit## Untracked files:# (use "git add ..." to include in what will be committed)## README# Rakefile# app/# config/# doc/# log/# public/# script/# test/
nothing added to commit but untracked files present (use "git add" to track)
If I run git add right now, Git will recursively add everything in RAILS_ROOT to the repository. But I don’t want that. There are a few items I don’t want to track. To have Git automatically ignore those items, I will create a .gitignore file. Each line tells Git what to ignore.
The application is now being tracked by Git. One last thing before we move on to Capistrano. I’m going to change the default index page to show a simple “Hello, World.” I’m using TextMate, which is the reason for the mate command.
$> mate public/index.html
All I did was replace the dynamic stuff on the home page with “Hi.” You’ll see it in a minute. Alright. That’s all I’m going to do for the first release. Now I need to move the repository to a remote location so I can pull from it when I release new code.
Good. Now I have a remote Git repository. Any changes that I push will go to this remote location that will also be accessible to Capistrano. And so we move on to Capistrano.
Capistrano
I have the Capistrano gem installed. I just need to initialize it for my app and then fix up my deployment recipe.
set :use_sudo, false
set :application, "jetrecord"
set :repository, "ssh://user@REMOTE/home/user/etc/git/jetrecord.git"
set :deploy_to, "/var/www/apps/#{application}"
set :user, 'user'
set :runner, user
set :scm, :git
set :domain, 'REMOTE'
role :app, domain
role :web, domain
role :db, domain, :primary=>true
set :server_name, "landingdeparting.com"
set :server_alias, "*.landingdeparting.com"
depend :remote, :command, :gem# Allow ssh to use ssh keys
set :ssh_options, {:forward_agent=>true}
deploy.task:restartdo# Restart Passenger
run "touch #{current_path}/tmp/restart.txt"end
deploy.task:symlinksdo
run "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"end
after :deploy, 'deploy:cleanup'
after 'deploy:update_code', 'deploy:symlinks'
Okay, one more thing on the remote end. In my deploy recipe I added a symlink from the database.yml file in the shared directory to the RAILS_ROOT/config directory. I’m doing this because I don’t want to track database.yml in my Git repository and it’s cheaper to create a symlink than to copy an actual file from one release to the next. But I still need to create the file manually. I’ll do that now.
Save and exit. Don’t forget to set up the actual database on the remote server with the correct credentials!
With that done, all that’s left to do is make sure my domain name is set up and ready to be seen by the world. This will depend on a great number of things, such as where your site is hosted, what operating system it’s on, what DNS services you’re using, and so on.
I’m not a sysadmin and I’m not going to pretend to be one. The focus of this series is the application so I’ll move on assuming that we’ve got our domain set up and we’ve tested that we can reach the site with a text index page of some kind.
Now we’ll run the setup command, check our deployment recipe, and then do a deploy. For the deploy I’m going to run cap:deploy instead of cap:deploy:cold because I don’t have any database migrations to run yet.
So that’s it. We have our Rails project started. We have our source code in a Git repository. We can deploy the app to our server with Capistrano. And we can view our handiwork live on the web. Now it’s time to build the real application. We’ll take it bird by bird.
Epilogue
From now on when I type something into the terminal I’m only going to show the output of the command if I think it’s relevant for the topic of the episode. In this episode, for instance, I set up Git and Capistrano and I thought it would be good to see how these programs respond. In future episodes I’m not going to show output from Git or Capistrano unless it’s relevant.
I’m going to follow the same general rule for other commands. If it’s relevant to the topic at hand or if a special case needs to be addressed, I’ll show it. Otherwise, I’ll only show the commands I type in. You can also assume that I am making regular commits to git and pushing those changes live with Capistrano. I don’t intend to show you every commit message and the result of every deployment here in the text unless there’s a special case. Some of these things may show up in the videos, but they get a little tedious here. Does that make sense? Each episode will build on previous episodes with regards to the minutiae that I share.
Coming Up in the Next Episode
I’m going to start building the first feature by writing some tests and then writing the code that implements the feature. Until next time, cheers and happy flying.
Material You May Find Useful Related to This Episode
