Fortunately, when resque starts a job it forks a child process and places the time it began the job in the process description.  You can tell if your worker is stale by using this timestamp to compare it to the current time.  Epoch Converter is one of a number of websites to help you convert the timestamp manually.

If you’re using god to monitor your processes, resque provides an example to eliminate these “stale” workers.  I don’t use god and instead use monit to monitor my processes.  Resque comes with a monit example too, but it only handles workers that consume too much memory.  If you happen to find yourself with stale workers, try using the following bash script I made.

#!/bin/bash 

# Simple script to kill stale resque workers
# Adam St. John [astjohn] [@] [gmail]
# 2011-06-24

# Timeout set to 10 minutes
TIMEOUT=600

# 21028 resque-1.16.1: Forked 17674 at 1308879414 
output=$(ps -e -o pid,command | grep -e [r]esque.*Forked | awk '{printf "%i#%i#%i\n", $1, $6, $4}')
now=`date +%s`

echo "`date` - Looking for stale workers."
# output should produce something like: 21028#1308879414#17674
if [ -z "$output" ] ; then
  echo "Stale workers were not found."
else
  echo "$output" | while read -r line ; do
  
    pid=$(echo $line | cut -d\# -f1)
    ftime=$(echo $line | cut -d\# -f2)
    fpid=$(echo $line | cut -d\# -f3)

    if ! [[ "$pid" =~ ^[0-9]+$ ]] ; then
      exec >&2; echo "Unable to find PID of stale resque worker"; exit 1
    fi

    if ! [[ "$ftime" =~ ^[0-9]+$ ]] ; then
      exec >&2; echo "Unable to find Forked time for stale resque worker"; exit 1
    fi

    difference=$(($now - $ftime))
    if [ "$difference" -ge "$TIMEOUT" ] ; then
      echo "Found a stale worker!"
      kill -s USR1 $pid
      echo "Kill signal USR1 sent to worker $pid so that it will shut down forked child $fpid"
    fi  
  done
  echo "Finished dealing with stale workers."
fi
exit 0

The script checks the timestamp that each worker leaves and kills a worker that has exceeded the TIMEOUT value. I run this script from a cron job.

where several options are available, including full and mountable. Run with
--help to find out more.

Generating a new engine produces a file structure similar to a regular rails application, but with a few notable differences which have been explained in several great articles.

Setting up Rspec

I enjoy using rspec in my testing and instead of using the test folder which was generated automatically, I decided to rename it to spec. Inside this spec folder, I set up the usual rspec environment. For example, inside my spec folder, I have additional folders named models, controllers, views, support, etc. Rspec needs to load the dummy application’s environment in order to function. To allow it to do so, a few changes are necessary to spec_helper.rb.

# /spec/spec_helper.rb

# This file is copied to spec/ when you
# run 'rails generate rspec:install'
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../dummy/config/environment", __FILE__)
require 'rspec/rails'

ENGINE_RAILS_ROOT = File.join(File.dirname(__FILE__), '../')

# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/ and its subdirectories.
#Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}
Dir[File.join(ENGINE_RAILS_ROOT, "spec/support/**/*.rb")].each {|f| require f }

RSpec.configure do |config|
  # == Mock Framework
  #
  # If you prefer to use mocha, flexmock or RR, uncomment
  # the appropriate line:
  #
  # config.mock_with :mocha
  # config.mock_with :flexmock
  # config.mock_with :rr
  config.mock_with :rspec

  # Remove this line if you're not using ActiveRecord
  # or ActiveRecord fixtures
  config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run
  # each of your examples within a transaction, remove
  # the following line or assign false instead of true.
  config.use_transactional_fixtures = true

  config.include Cornerstone::Engine.routes.url_helpers
end

Of course, renaming the test folder to spec did have some unintended consequences. For one, running rake tasks did not work. In order to fix that, I had to change Rakefile to load the dummy application’s environment from the new location.

# /Rakefile

#!/usr/bin/env rake
begin
  require 'bundler/setup'
rescue LoadError
  puts 'You must `gem install bundler` and `bundle install` to run rake tasks'
end
begin
  require 'rdoc/task'
rescue LoadError
  require 'rdoc/rdoc'
  require 'rake/rdoctask'
  RDoc::Task = Rake::RDocTask
end

RDoc::Task.new(:rdoc) do |rdoc|
  rdoc.rdoc_dir = 'rdoc'
  rdoc.title    = 'EngineName'
  rdoc.options << '--line-numbers' << '--inline-source'
  rdoc.rdoc_files.include('README.rdoc')
  rdoc.rdoc_files.include('lib/**/*.rb')
end

# notice the path change in the following line
APP_RAKEFILE = File.expand_path("../spec/dummy/Rakefile", __FILE__)
load 'rails/tasks/engine.rake'

require 'rake/testtask'

Rake::TestTask.new(:test) do |t|
  t.libs << 'lib'
  t.libs << 'test'
  t.pattern = 'test/**/*_test.rb'
  t.verbose = false
end

task :default => :test

Bundler::GemHelper.install_tasks

Finally, running rails on the console will not work until you change the dummy application’s environment reference in the rails script.

# /script/rails

#!/usr/bin/env ruby
#!/usr/bin/env ruby
# This command will automatically be run when you run "rails" with Rails 3 gems installed from the root of your application.

ENGINE_PATH = File.expand_path('../..',  __FILE__)
# notice the path change on the following line
load File.expand_path('../../spec/dummy/script/rails',  __FILE__)

I believe that’s all it took to get rspec working again after renaming the test folder to spec. Of course, since I’m using rspec, I no longer needed test_helper.rb and so I removed it. If there’s something I missed, or if you can’t get rspec to work, please let me know.

Preparing Cucumber

As with Rspec, Cucumber also needs to load the dummy application’s environment in order to function. After adding cucumber-rails to your gemspec or Gemfile, running rails generate cucumber:install will generate the necessary files and folder structure for cucumber to function properly. Unfortunately, the files generated are geared toward normal rails applications and not rails engines. To make it work for a rails engine, I had to make the following changes to env.rb.

# /features/support/env.rb

# IMPORTANT: This file is generated by cucumber-rails - edit at your own peril.
# It is recommended to regenerate this file in the future when you upgrade to a
# newer version of cucumber-rails. Consider adding your own code to a new file
# instead of editing this one. Cucumber will automatically load all features/**/*.rb
# files.

ENV["RAILS_ENV"] = "test" # had to explicity state the test environment (or cucumber env.)
ENV["RAILS_ROOT"] = File.expand_path(File.dirname(__FILE__) + '/../../spec/dummy/')
require File.expand_path(File.dirname(__FILE__) + '/../../spec/dummy/config/environment')

require 'cucumber/rails'

# If you use factory girl, I had to add the following...
require 'factory_girl_rails'
require File.expand_path(File.dirname(__FILE__) + '/../../spec/support/factories')

# Capybara defaults to XPath selectors rather than Webrat's default of CSS3. In
# order to ease the transition to Capybara we set the default here. If you'd
# prefer to use XPath just remove this line and adjust any selectors in your
# steps to use the XPath syntax.
Capybara.default_selector = :css

# By default, any exception happening in your Rails application will bubble up
# to Cucumber so that your scenario will fail. This is a different from how
# your application behaves in the production environment, where an error page will
# be rendered instead.
#
# Sometimes we want to override this default behaviour and allow Rails to rescue
# exceptions and display an error page (just like when the app is running in production).
# Typical scenarios where you want to do this is when you test your error pages.
# There are two ways to allow Rails to rescue exceptions:
#
# 1) Tag your scenario (or feature) with @allow-rescue
#
# 2) Set the value below to true. Beware that doing this globally is not
# recommended as it will mask a lot of errors for you!
#
ActionController::Base.allow_rescue = false

# Remove/comment out the lines below if your app doesn't have a database.
# For some databases (like MongoDB and CouchDB) you may need to use :truncation instead.
begin
  DatabaseCleaner.strategy = :transaction
rescue NameError
  raise "You need to add database_cleaner to your Gemfile (in the :test group) if you wish to use it."
end

# You may also want to configure DatabaseCleaner to use different strategies for certain features and scenarios.
# See the DatabaseCleaner documentation for details. Example:
#
#   Before('@no-txn,@selenium,@culerity,@celerity,@javascript') do
#     DatabaseCleaner.strategy = :truncation, {:except => %w[widgets]}
#   end
#
#   Before('~@no-txn', '~@selenium', '~@culerity', '~@celerity', '~@javascript') do
#     DatabaseCleaner.strategy = :transaction
#   end
#

Note the two lines at the top which reference the dummy application. These lines are required because cucumber attempts to boot a rails application from the normal environment.rb which is usually located in the config folder. In a rails engine, this file doesn’t exist. It only exists within the dummy application. Adding the additional lines at the top of env.rb forces cucumber to bootstrap the dummy application’s environment. With these changes, cucumber should be fully functional.

One further change that had me stumped for a while was using Cucumber’s path_to helper located in paths.rb. I just could not make cucumber return the correct path when referencing using a path helper such as some_controller_method_path. In order to use these helpers (thanks Robin – see below) you can add the engines’ url_helpers to the World object of Cucumber like this:

module EngineRoutesHelper
  include MyEngine::Engine.routes_url_helper
end
World(EngineRoutesHelper)

Now, you will be able to rewrite the path_to method like this:

def path_to(page_name)
  case page_name
    when /^the discussions page$/
      discussions_path
    # etc…
  end
end

I hope my stumblings have helped others out there. Give me a shout if you run into any problems.

To convert your data, you will need to set up two databases. The rake task is designed to move data from the production database to the development database. To kick start things, download a backup of your production database and move it to your local computer. Next, establish a production MySQL database and then build the schema. rake db:schema:load RAILS_ENV=production. After the database is built, import the data to the local production database. mysql -u USER -p -D data_prod < backup.sql

Now, because the rake task moves data from a production database to a development database, you must configure your project’s database.yml file. This is what it could look like:

production:
  adapter: mysql2
  encoding: utf8
  username: rails_dev
  password: password
  host: localhost
  database: db_prod

development:
  adapter: postgresql
  encoding: utf8
  username: rails_dev
  password: password
  host: localhost
  database: db_dev

Note that the development database is set up for PostgreSQL. Therefore, before running the rake task you must establish this database as well. Build the database in PostgreSQL and then load the schema as above: rake db:schema:load RAILS_ENV=development. Also, do not forget to add a PostgreSQL adapter to your project’s Gemfile. I prefer the pg gem: gem "pg"

With the databases all set up, converting your data to the PostgreSQL database is as simple as:

rake db:convert:prod2dev

This worked great using ruby 1.9.2 and rails 3.0.8.

Mountable Engines

Engine Details

To generate a mountable engine, run rails plugin new MyEngine --mountable on the console. This will generate the engine’s basic structure.

The first difference I noted with a mountable engine is that, by default, the engine is namespaced. The engine’s starting config is:

module MyEngine
# my_engine/lib/my_engine/engine.rb

  class Engine < Rails::Engine
    isolate_namespace MyEngine
  end
end

Since the engine has an isolated namespace, the controllers, models, helpers, etc. are all bundled within the module MyEngine. The folder structure reflects this change as well. Unlike a full engine, the mountable engine generated the typical assets that are normally associated with a Rails application, namely application.js, application.css, and application_controller.rb. Note the namespacing that occurs with the application controller:

# my_engine/app/controllers/my_engine/application_controller.rb

module MyEngine
  class ApplicationController < ActionController::Base
  end
end

This namespacing occurs throughout the engine. There are subtle differences in terms of routing as well. With a mountable engine, the engine’s route file looks like this:

# my_engine/config/routes.rb

MyEngine::Engine.routes.draw do
  # route stuff goes here
end

Remember, the full application’s routes start with Rails.application.routes.draw. The dummy application’s routes file was generated as:

# my_engine/test/dummy/config/routes.rb

Rails.application.routes.draw do

  mount MyEngine::Engine => "/my_engine"
end

Notice that the engine is bundled under a “mounted” route at /my_engine. This means that all of the engine’s functionality will be located under the engine’s root location of /my_engine within the dummy (parent) application. This type of structure suggests that a mountable engine is best suited for situations when a developer wants the engine to behave as its own application operating in parallel with the parent application. Most of the engine’s features are isolated and independent of the parent application. To test this, I plugged the mountable engine into a test application.

Routing

I used a model within the engine called “Post”, along with the migration, controller, and helper to match (rails generate scaffold post title:string body:text). Now my engine’s routes file looks like this:

# my_engine/config/routes.rb

MyEngine::Engine.routes.draw do
  resources :posts
end

With a full engine, the Post routes were included directly into the parent application automatically. This time, using the mountable engine and running rake routes within the parent application, nothing happened! That’s because I did not mount the engine in a similar manner to what the dummy application in our engine is using. The parent application’s route file had to be adjusted like so:

# parent_app/config/routes.rb

ParentApp::Application.routes.draw do
 mount MyEngine::Engine => "/my_engine"
end

rake routes now produced the following:

my_engine  /my_engine {:to=>MyEngine::Engine}

…and that’s it. All of the engine’s functionality is bundled into the parent application underneath the route /my_engine.

After running rake my_engine:install:migrations and rake db:migrate in the parent application, I was ready to test how the engine’s controllers and helpers would integrate. [note: running migrations from an isolated engine will prefix your database tables with the engine name]. As with the full engine, I established a simple view template:

# my_engine/app/views/my_engine/posts/index.html.erb

<p>Hi There!</p>

Of course, navigating to /my_engine/posts in the parent application showed an almost blank page with the words “Hi There!” The controller actions and views from the engine were incorporated into the parent application, but only under the namespaced route /my_engine.

Next, I tested if the view could be overridden by the parent application. I created a new view template for the Post index action within the parent application that looked like this:

# parent_app/app/views/posts/index.html.erb

<p>Good Bye!</p>

No change and of course not! Our engine is namespaced, remember? Instead, I moved the template to parent_app/app/views/my_engine/posts/index.html.erb. Now visiting /my_engine/posts in the parent application showed “Good Bye!” That’s better. Next I decided to test out the engine’s helpers. I added a method to the Post helper inside the engine.

# my_engine/app/helpers/my_engine/posts_helper.rb

module MyEngine
  module PostsHelper
    def test
      raw("<p>hello world</p>")
    end
  end
end

I then changed the parent application’s view template to use the helper.

# parent_app/app/views/posts/index.html.erb

<p>Good Bye!</p>
<%= test %>

Visiting the page resulted in the words “Good Bye!” and “hello world.” Therefore, the engine’s helper methods were directly exposed to the parent application, allowing the parent to use them. 

 To be honest, I did not expect this to work. There is a section in the Rails comments about sharing an isolated engine’s helpers with the parent application by using helper MyEngine::Engine.helpers in the application controller of the parent. It states that in doing so “[the parent application] will include all of the helpers from engine’s directory.” Perhaps this is a bug in the release candidates of Rails 3.1? Maybe my interpretation of the instructions is way off? I’m not sure. If this does change by the time you use it, and you can’t access the engine’s helpers, I suggest trying the method described.

Summary

It seems as though mountable engines are best suited as complete applications in themselves which run along side a parent application. The engine routes, controllers, models, helpers, etc. are namespaced and bundled into the mounted route within the parent application, thus avoiding namespace conflicts. If I’m way off in my assessment or there are other things which I have missed, drop me a line and I’ll add them!

Full Engines

Engine Details

To generate a full engine, run rails plugin new MyEngine --full on the console. This will generate the engine’s basic structure.

The first thing I noticed was that the typical assets associated with a normal Rails application were not generated; application.js and application.css were not created. In fact, the application controller was completely omitted, alluding that perhaps a full engine is feared toward supplementing a parent application only. As far as routing goes, the engine’s route looked like this:

# my_engine/config/routes.rb

Rails.application.routes.draw do
end

… and the dummy application’s routes file looked like this:

# my_engine/test/dummy/config/routes.rb

Dummy::Application.routes.draw
  # route stuff
end

Another item that was missing from the basic application structure was the database folder. For engine configuration, a full engine is not namespaced, so the engine.rb file was essentially blank.

# my_engine/lib/my_engine/engine.rb

module MyEngine
  class Engine < Rails::Engine
  end
end

Now, the rails comments state that engines allow you to add a “subset of functionality to an existing Rails application.” Since the full engine is missing an application controller, it seems that its purpose is to plug into an existing application without namespacing to add functionality to the parent application. To test this theory, I generated a new application and referenced my engine in the parent application’s Gemfile.

Routing

Since the engine is not namespaced, the engine’s routes are incorporated into the parent application’s routes directly. To test this, I created a model within the engine called “Post”, along with the migration, controller, and helper to match. To create the migration, I also had to build the my_engine/db/migrate/ folder, which was not created when I generated the engine. Running rake routes within the parent application resulted in the following:

    posts GET    /posts(.:format)          {:action=>"index", :controller=>"posts"}
          POST   /posts(.:format)          {:action=>"create", :controller=>"posts"}
 new_post GET    /posts/new(.:format)      {:action=>"new", :controller=>"posts"}
edit_post GET    /posts/:id/edit(.:format) {:action=>"edit", :controller=>"posts"}
     post GET    /posts/:id(.:format)      {:action=>"show", :controller=>"posts"}
          PUT    /posts/:id(.:format)      {:action=>"update", :controller=>"posts"}
          DELETE /posts/:id(.:format)      {:action=>"destroy", :controller=>"posts"}

As you can see, the Post routes from the engine were included directly into the parent application.

After running rake my_engine:install:migrations and rake db:migrate in the parent application, I was ready to test how the engine’s controllers and helpers would integrate. In my engine, I had a simple view template:

# my_engine/app/views/posts/index.html.erb

<p>Hi There!</p>

Of course, navigating to /posts in the parent application showed an almost blank page with the words “Hi There!” The controller actions and views from the engine were incorporated into the parent application.

One helpful feature of engines is the fact that their controller methods and views can be overridden simply by placing similar files within the parent application. For example, I created a new view template for the Post index action within the parent application that looked like this:

# parent_app/app/views/posts/index.html.erb

<p>Good Bye!</p>

Now visiting /posts in the parent application shows “Good Bye!” That’s great, but what about the engine’s helpers? I tested that functionality by adding a method to the Post helper back inside the engine.

# my_engine/app/helpers/posts_helper.rb

module PostsHelper

  def test
    raw("<p>hello world</p>")
  end

end

I then changed the parent application’s view template to use the helper.

# parent_app/app/views/posts/index.html.erb

<p>Good Bye!</p>
<%= test %>

This time, visiting the page again in the parent application resulted in the words “Good Bye!” and “hello world.” Therefore, the engine’s helper methods were directly exposed to the parent application, allowing the parent to use them.

Summary

In summary, it seems as though full engines are best suited to augment a parent application. The engine routes, controllers, models, helpers, etc. are exposed to the parent application which allows for easy access, but could result in namespace conflicts.

It looks like this post is getting a bit lengthy so I’ll stop it here and talk about mountable engines soon.

When we arrived at the station, we walked out into the middle of the city. This moment was the only time in our whole trip that we ever felt nervous walking around. We walked a few city blocks to our hostel and right away were handed a map. The guy checking us in proceeded to draw a big circle with the letters DNG on top of it. This, he explained, is the Do Not Go zone, and is the bad part of the city.

We were tired from the flight, so we went to bed right away. The next morning, we woke up at 6am from jetlag, and went to the kitchen of the hostel to make some free pancakes. We decided to explore the city this day. Walking through China town was not as impressive as it would have been if we had not been to China. Then, we wandered down rolling roads through the financial district, and onward to Fisherman’s Wharf. On the way, we stopped to walk up Telegraph Hill. On the top of this hill is a building resembling a lighthouse that was built by a rich woman who dedicated it as a memorial for the firemen of San Francisco. We then walked past Lombard Street and into the Fisherman’s Wharf area which was packed with buskers, eateries, and plenty of shopping. We stopped here and split a bowl of San Francisco’s famous clam chowder in a sourdough bread bowl from one of the many food stalls just outside the seafood restaurants. The chowder was pretty tasty. While we ate, we listened to a busker who played synthesized music through a digital clarinet/wind instrument. It was really cool how he had to learn to play the drums with his mouth and fingers!

After lunch, we followed “The Embaradero”, a wide street that the cable cars run down the middle of, along all the piers. We stopped at pier 39 to watch the sea lions sprawled out on wooden planks. When the sea lions are there, no boat traffic is allowed. Therefore, these sea lions have basically taken over the pier for themselves. We walked all the way back along the piers to pier 1/2 where the ferry building is located. The ferry building is a huge building with a clock tower, and is filled with gourmet restaurants and specialty gourmet grocery stores. One store only sold mushrooms, and must have had at least 50 different types.

It was late afternoon by this time, so we walked back to our hostel through the financial district and through another plaza where a North American market was set up. People there were selling everything from souvenirs to photographs. We didn’t try bargaining for anything. We continued walking and ran into a square that had artwork on display and for sale. On the stage in the square were some live performances put on by a church group.

By the time we got back it was dinner time, and we found a neat retro 50’s/60’s diner complete with jukeboxes at each table. There was a small plane hanging from the ceiling, the waiters all wore aprons with silly looking hats, etc. We were both so tired that we just ate quickly and then collapsed at the hostel.

The next morning, we woke up early and had a huge breakfast at a small diner. Then we walked to the South Of Market Area (SOMA) and stopped at the San Francisco Museum of Modern Art (SFMOMA). We figured that if we were going to experience San Francisco, we needed to try and appreciate some of the artistic culture that the city is known for. We spent most of the morning being amused by abstract art such as works by Salvidor Dali, a white paint painting, and a toilet that an artist picked from a hardware store and stated “it is art because I say it is art”. Some of the exhibits were crazy, and some were really good. Luckily, we were fortunate enough to visit the museum at the same time they were having an exhibit on Frida Kahlo, a talented Mexican painter, who was overshadowed by her more famous husband Diego Rivera, also a painter. We were both very impressed with her work.

After the museum, we dared to walk into the DNG zone in order to get a great picture of one of San Francisco’s infamous rolling roads. Although we were still on the outskirts of the area, we must have passed at least 10 to 20 crazy people having conversations with themselves. We couldn’t imagine what the heart of the DNZ zone would be like, but neither of us was willing to find out. We walked along the edge of the area very quickly, and walked onto Haight Street, which is located in an area lined with private/independent fashion stores, rehab clinics, smoke shops, etc. The Lonely Planet mentioned that a Gap store opened in this district, and the people living in the district weren’t happy about the commercialism moving into their area. The store had numerous windows broken, graffiti, etc. and was basically pushed out by the residents.

We stopped for lunch at a store that only sells homemade BBQ/grilled sausages. There were many types to choose from. Tara had a beer sausage, and Adam had an Italian sausage with a root beer from a local soda store. After lunch we walked to Alamo square, which is a small park the size of a city block, set in a neighbourhood of old Victorian houses, called the painted ladies. They’re called this because they’re all painted different pastel colours. These painted ladies are a famous San Francisco landmark, and can be seen in the opening credits of “Full House”. After walking around this area, we wound up at a trolley car stop, and took the “F” trolley to pier 33 for the Alcatraz night tour. Along the way, a woman entered the trolley with crutches and sat down next to a crazy woman. We eavesdropped on a conversation between the two. The woman with crutches explained that she had “a hip problem and that’s all they would tell her”. The other crazy woman kept telling her she had to fix it and to just “snap it back in there”, and then just kept repeating that phrase. The woman with the crutches said “I don’t know, just please stop it…” and put her hands on her ears. It turns out she was crazy too. Then a third guy started talking about how his femur and hip were replaced with titanium. All three of these people got off in the DNG zone. The woman with the crutches stood up and walked off without using them. This was quite a site to experience.

The F trolley curved along the piers and we got off at pier 33. There was a short wait until we were ferried over to Alcatraz island. After a short introduction with some anecdotes from a park officer, we were given headphones and an mp3 player for a self guided audio tour through the cell blocks. The audio guide was actually pretty good with excellent actors and sound effects. The stories were about life in prison, attempted breakouts, etc. One of the stories talked about one prisoner who spent his time in solitary confinement playing a game. He would pull a button off his shirt, and since the cells were pitch dark, he would flip the button and spend time finding it. It sounded very lonely. There was also a story about how a few of the prisoners managed to overtake the guards and hold them hostage for a few days while they attempted to get off the island. Eventually, there was a gunfight and most of those prisoners and a few guards were killed.

We wandered up and down the cell blocks and other parts of the buildings listening to all stories. This whole tour lasted about 2 hours. Some parts briefly took us outside where it was extremely cold and very windy. As it got darker, the island took on a whole new look, and started to become more and more creepy. We took the early ferry back to the mainland before the sun totally set because Tara was extremely cold. Then we took the cable car over the hills and back to the hostel.

Our last full day in San Francisco, we woke up and had another hearty breakfast at a diner. Then we walked along the cable car tracks until we reached the cable car museum. The cable car system in San Francisco now consists of four major lines. There is one loop of cable that runs the length of the track and ends at the museum where the tension on the lines can be adjusted if they stretch too much. These cables are in constant motion. To move the cable car, the driver has two levers: one lever clenches or loosens a clamp on the cable car to adjust traveling speed, and the other applies the breaks to slow the car down. The system is very similar to a ski lift. When the car travels around corners, the driver may decide to use the cable to drag it along, or they could decide to drift around the turn.

After the cable car museum, we continued walking over the hill and back to fisherman’s wharf. There, we rented bicycles for ridiculously more compared to anywhere in Asia. For the same price, we could have lived for 3 days in Thailand. We followed the path along the cost, up and over the Golden Gate Bridge. Luckily, we had great weather this day, and the views were fantastic. It was extremely windy on the bridge. After we crossed we zig-zagged down the hill into Sausalito, a small neighbourhood across the river from San Francisco. We stopped there to enjoy a late lunch of fish and chips, then caught the ferry back with almost 200 other tourists on bicycles. Unfortunately, we ran out of time, and wasn’t able to see the Golden Gate park, or the beach on the west side of the city. We were so tired from the exercise, that we went to bed early, and got up at 4am just in time to catch the first BART train to the airport. The rest of the day, we were in transit through Vancouver and then finally back in Ottawa.

It was a once in a lifetime trip that we won’t ever forget, and we both sincerely hope that everyone enjoyed the blog.

Hong Kong is a city composed of many islands, mainly Hong Kong Island, and Kowloon Island. It is a financial and architectural metropolis located just off the East cost of mainland China. We left Singapore early in the afternoon, and arrived in Hong Kong in the evening, just after dusk. As soon as we arrived at the airport, we picked up our bags, and purchased an airport express ticket and an “octopus” card. The octopus card is a multi-purpose card that can be used for almost all forms of public transport including the ultra modern MTR subway, buses, tram cars, as well as at stores such as 7-11 and KFC. It only cost 7HKD (1 USD) with a 50 HKD refundable deposit. If more money was put on the card and not used before returning the card, there is a full refund issued. The airport express ticket was good for a single trip into the city on a modern subway/train with few stops.

During our journey into the downtown area we were concerned about how far the stop was to our hostel, and began to make a plan to take other forms of public transportation. When we arrived at our destination, we exited the MTR and found that there is a free bus shuttle to the major hotels in the area, one of which was only a block away from ours. This was a pleasant surprise, as we were loaded down with baggage at this point, and it was also late at night. We walked to our hostel, located in a massive apartment building, past touts trying to sell us suits and fake goods (watches, purses, etc). Our building had a tiny mall on the first floor and the rest of the 16 floors had apartments. It was so busy in this building, that there were multiple elevators serving certain floors to make the ride to the top floors faster. When we were shown to our floor, we could see that the building was square and hollow in the middle overlooking a courtyard. As we opened the door to our room, we entered a tiny hallway much cleaner than the rest of the building. From this hallway, a second door led us to our room, which was actually quite nice.

The following day, we woke up early and decided to do a walking tour recommended in the guidebook through the old central part of Hong Kong Island. We took the subway there from our hostel on the Kowloon side, and jumped off into some small winding streets. The Hong Kong MTR system is an efficient way to move around the city. In addition to this useful traveling network, there is also an underground network of tunnels that have entrance and exits inside buildings, malls or any street intersection corners. These tunnels can be km’s long, and at one point link a subway station with a light rail station underground for at least a 15 minute walk. We never tried, but it might be possible to walk through central downtown without going outside. If not, it’s certainly possible to walk it with a roof overhead from the covered walkways.

We were still a walk away from the beginning of the tour, so we jumped on the tram. This old, slow and rickety double-decker tram was rammed full of riders, and was pretty fun to take. We finally jumped off, and began our walk through streets lined with Chinese herbal medicine stores, and small walking streets with cheap souvenirs. It was just about lunchtime and we were getting very hungry. Unfortunately we were in a very expensive area, so we started to walk to the SOHO district, known for its many bars and eateries. On the way there, we stopped by the Graham St. market, which is known for its fresh market filled with fruits and vegetables, and live fish. According to our Lonely Planet, this is one of the best markets in Hong Kong. However, compared to other markets we saw in rural China, this market was pretty tame (we didn’t see any fish get beaten over the head in the middle of the walkway).

After lunch in SOHO, we took a ride on the world’s largest travelator, a horizontal escalator. This travelator was really just a bunch of escalators up some hills (not all horizontal) lined up between streets. We then walked to the financial district to 2nd Finance Blvd. which had an exhibit on monetary, etc. which was set up on the 56th floor. We were only there to see the view. At first we were nervous walking in the building because we had to show our passports to have official visitor passes printed. But when we stepped into the elevator which had two floors to choose from: Ground or 56th, we figured that a lot of people probably did the same thing. This high up, the views of Kowloon bay and the harbour were excellent, as it was a clear and sunny day. Next, we walked to the Bank of China’s 46th floor for more views of the city. By this time, it was evening so we went near the water outside the EXPO centre for sunset. We wanted to enter the EXPO centre, but there was a jewelry conference, so we weren’t allowed to enter.

After a disappointing sunset, we took the MTR back under the harbour and north to the Mong Kok district. Here we walked through the Temple St. night market, full of fake designer goods, souvenirs, karaoke and fortune tellers (tarot/palm readers). Halfway through, we stopped at a corner for a cheap dinner of friend noodles with chicken. The second half of the market was similar to the first. All in all, it took at least an hour to walk through the whole street.

On our second day in Hong Kong, we woke up and took the STAR ferry across the harbour from Kowloon to Hong Kong. The ferry was so old, it might have been the original ferry, complete with wooden seats and interior. The views from the ferry were fabulous, but the ride was shorter than we expected. We were visiting Hong Kong this morning to go to an authentic Dim Sum teahouse in the old part of town. In a Dim Sum restaurant, the eater sits at a table with their plates and cutlery and wait for the food to be brought to the table on a small cart. In small bamboo baskets are steamed foods, such as dumplings, etc. that are selected. The cart lady then stamps the card of the eater to show what they had. At the end of the meal, the card is taken to the cashier to pay the bill.