If you need to print the current page’s content, for example to debug your test, you can do so with:

    puts page.body

This trick is a bit hard to find in the documentation.

Update: There is also

    save_and_open_page

which opens the page content in a browser.

/Users/stefan/.../controllers/categories_controller.rb:37: invalid multibyte char (US-ASCII)

The problem is that Ruby 1.9 expects you to use ASCII characters in your source code, and you have used a non ASCII character.

The solution is to tell Ruby that your source file is UTF-8 by including this directive as the first line of your file:

# encoding: utf-8

You probably use UTF-8 for all your files. Once you include a non-ASCII character, the difference between ASCII and UTF-8 becomes relevant for Ruby. That’s when you need this directive.

With the crowd_rails plugin, Ruby on Rails can also benefit from single sign on with Atlassian Crowd 2.0.

Installing the Plugin

The plugin is available at

http://github.com/stefanwille/crowd_rails

To install the crowd_rails plugin, run

gem install crowd_rails
gem crowd-stefanwille

crowd-stefanwille is a Ruby client library for Crowd, and crowd_rails is the Rails plugin.

Installing a Crowd Server

Beyond these gems, you will also need a Crowd server with version 2.0 or greater.
The easiest way to get started is to install an evaluation copy of Crowd on your local machine.

After you have installed your local Crowd server, test it using its demo application. Go to

http://localhost:8095/demo

Make sure that you can log in.

Running the Demo Application

On Github you can clone a simple demo application that uses crowd_rails for authentication. The URL is:

http://github.com/stefanwille/crowd_rails_test

To run it, you will need

• a Crowd server on localhost, port 8095
• an application configured in Crowd with app name and password ‘soaptest’
• the application ‘soaptest’ set ‘directory’ set to ‘True’

Type

git clone git@github.com:stefanwille/crowd_rails_test.git
cd crowd_rails_test
bundle install
ruby script/server

And then point your browser to

http://localhost:3000/demo

You will get the browser’s log in dialog. When you enter correct credentials, you will see a success page. Next, you can try if you are also logged in for Crowd’s demo application, which should run at

http://localhost:8095/demo

on your local Crowd server.

Using the Plugin

To use the plugin in your own application, you need to configure the Crowd client library and then mix the module Crowd::SingleSignOn into your ApplicationController.

Add a file

config/initializers/crowd_setup.rb

and this content:

require ‘crowd’

Crowd.crowd_url = ‘http://127.0.0.1:8095/crowd/services/SecurityServer’
Crowd.crowd_app_name = ‘soaptest’
Crowd.crowd_app_pword = ‘soaptest’
Crowd.crowd_validation_factors_need_user_agent = false  # false for Crowd 2.0.5, true for Crowd 2.0.2
Crowd.crowd_session_validationinterval = 0  # Set > 0 for authentication caching.

This file contains the Crowd configuration for your application. Change the configuration according to your needs.

Then add this to your ApplicationController class:

class ApplicationController < ActionController::Base
include Crowd::SingleSignOn

…
before_filter :authenticate

private
def authenticate
return if RAILS_ENV == “test”

return if crowd_authenticated?

authenticate_or_request_with_http_basic(‘My Application’) do |user_name, password|
crowd_authenticate(user_name, password)
end
end
end

This will give you the browser’s grey password dialog (aka ‘basic auth’). Replace the call to Rails’ authenticate_or_request_with_http_basic() that asks the user for username and password if you want something fancier.

The demo app uses the same basic auth approach.

Log Out

There is little gotcha with respect to log out. The plugin offers the method crowd_log_out, which is also used in the demo application. The problem is that basic authentication makes it more or less impossible to log a user out, because the browser keeps sending the user’s crendentials with every request. So if you want a log out feature, you need to replace basic authentication with a login form.

Interoperability

I haved tested crowd_rails plugin with Crowd 2.0.2 and 2.0.5. Also, I tested single sign on interoperability with Jira, Confluence and Bamboo.

Correct handling of validation factors is necessary for interoperable single sign on with other Atlassian products.

Get it via

gem install crowd-stefanwille

Get more info from http://github.com/stefanwille/crowd.

The solution is to do a bundle lock in development and to add the resulting file Gemfile.lock to your VCS. During bundle lock, Bundler writes all dependent gems and their specific version numbers to Gemfile.lock. This way, it will only search these gems and will not try to use the latest ones. And because these gems are already deployed after the first deployment, bundle install can complete quickly.

Another advantage is that your deployment environment will use exactly the same gem versions as your development system.

The bundler home page explains how to use bundle lock.

Update: The latest bundler version 0.9.26 always performs a bundle lock implicitly when you run bundle install.

How not to do it

We kept the first epic as a single big story. During development, it was hard to see where we really stood with the story and how much work was left. Quite frustrating. And it took longer than estimated. In between we wanted to cut features, but we developers didn’t understand the motivation behind each, so it was hard to come up with suggestions. In the end it was a few 100% over estimate.

Splitting Epics

After this experience, we got smarter and we split the second epic into many small stories. This made a big difference. Estimating the small stories was much easier. We could prioritize the smaller stories against each other. Progress was easily measurable. We could select a subset of stories that would allow us to start using the epic even before it was complete. Which meant that we generated business value and got feedback early on.

Schedule Independently

So far this was great, yet not surprising. But I found an important extra benefit: When it was clear that building all stories in one go would take too much time, we could move the expensive, lower value stories further down in our backlog. It was fairly easy to delay the lower value elements and build other, non related stories first.

Effectively, we categorized the epic’s stories into three categories:

1. The parts that we really couldn’t live without for another month
2. The elements that we really needed at some later point, plus the really quick ones
3. Everything else

We built category 1 immediately. Then we built some other pressing stuff, which was completely unrelated to the epic. Then we got to category 2. Which means we could interleave some important, nonrelated stories within our epic, and yet have cohesive feature sets in each step. A big benefit.

Save Effort

After we build category 2, we axed category 3. We just didn’t build it. This is yet another benefit: Splitting stories makes it easier to find the elements that are not really required.

Next time your PO brings an epic, make sure to slice it into stories that can be completed in a few days or less.

Not so good: I tried to give business people a report generator, and have somebody prepare reports. Doesn’t work well, because reports definitions break with DDL changes.

What works for me is to let business people query the database themselves. In the morning, the production database gets copied to a separate server. There, my colleagues access it using MySQL query browser via an SSH tunnel. We collect the SQL queries that they typically use in a Wiki, and they adapt the queries if they need small variations. Of course, this only works because my colleagues understand a bit of SQL.

Less interruptions, more joy.

Our company offers an internet service called GratisPay that monetarizes virtual goods in online games.

Update: Finished searching