Copy the above string of input (gray box above labeled /Input HTML/into the “Your test string” box, and then let’s figure out a simple regexp to match an individual line.

changed email to "(.*?)"

The .*? syntax means to get the non-greedy match. In order to see this, let’s use this string below into the “Your test string” box (note, the text scrolls way to the right):

1

Updated User (4)<br>     changed first_name to &quot;Karina&quot;<br>     changed last_name to &quot;Senger&quot;<br>     changed phone to &quot;2133432154&quot;<br>     changed email to &quot;brenna.treutel@runolfsdottirdonnelly.org&quot;<br>     changed street to &quot;123 Main St&quot;<br>     changed city to &quot;Paia&quot;<br>     changed state to &quot;HI&quot;<br>     changed zip_code to &quot;96677&quot;<br>     changed social_security_number to &quot;555-33-4444&quot;<br>   changed date_of_birth to &quot;2000-10-03&quot;

Notice that you see the correct result for the match.

Now, remove the ? in the .*?, using this regexp:

changed email to "(.*)"

And you’ll see this:

Now, add back the ? after the .*, and you’ll see the right value.

The Ruby docs for Class Regexp explain this:

Repetition is greedy by default: as many occurrences as possible are matched while still allowing the overall match to succeed. By contrast, lazy matching makes the minimal amount of matches necessary for overall success. A greedy metacharacter can be made lazy by following it with ?.

How do we match any of the PII fields of email, social_security_number, date_of_birth?

The answer is to use alternation.

The vertical bar metacharacter (|) combines two expressions into a single one that matches either of the expressions. Each expression is an alternative.

changed (email|social_security_number|date_of_birth) to "(.*?)"

Open up your rails console (rails c) and paste the following 2 lines. This will set you up with what we’ve been testing in Rubular.

1
2

log_entry = "Updated User (4)<br>     changed first_name to &quot;Karina&quot;<br>     changed last_name to &quot;Senger&quot;<br>     changed phone to &quot;2133432154&quot;<br>     changed email to &quot;brenna.treutel@runolfsdottirdonnelly.org&quot;<br>     changed street to &quot;123 Main St&quot;<br>     changed city to &quot;Paia&quot;<br>     changed state to &quot;HI&quot;<br>     changed zip_code to &quot;96677&quot;<br>     changed social_security_number to &quot;555-33-4444&quot;<br>     changed date_of_birth to &quot;2000-10-03&quot;"
regexp = /changed (email|social_security_number|date_of_birth) to &quot;(.*?)&quot;/

Then enter the following. Feel free to experiment!

1
2
3
4
5

log_entry.match(regexp)
$~
$1
$2
$&

Here’s the doc of the globals set by a regexp. These are thread-local and method-local variables. So they are safe in a multi-threaded environment.

Pattern matching sets some global variables :

$~ is equivalent to ::last_match;
$& contains the complete matched text;
$` contains string before match;
$' contains string after match;
$1, $2 and so on contain text matching first, second, etc capture group;
$+ contains last capture group.

The $~ will come in particularly handy when we try to use gsub.

String#scan does it!

1

log_entry.scan(regexp)

$1 and $2 are not the most illuminating names for the capture group values. Ruby offers a way to give them readable names. Quoting the Ruby doc for Class Regexp:

Capture groups can be referred to by name when defined with the (?<name>) or (?'name') constructs.

/\$(?<dollars>\d+)\.(?<cents>\d+)/.match("$3.67")
    => #<MatchData "$3.67" dollars:"3" cents:"67">
/\$(?<dollars>\d+)\.(?<cents>\d+)/.match("$3.67")[:dollars] #=> "3"
Named groups can be backreferenced with \k<name>, where name is the group name.

/(?<vowel>[aeiou]).\k<vowel>.\k<vowel>/.match('ototomy')
    #=> #<MatchData "ototo" vowel:"o">
Note: A regexp can't use named backreferences and numbered backreferences simultaneously.

When named capture groups are used with a literal regexp on the left-hand side of an expression and the =~ operator, the captured text is also assigned to local variables with corresponding names.

/\$(?<dollars>\d+)\.(?<cents>\d+)/ =~ "$3.67" #=> 0
dollars #=> "3"

Let’s try that in rubular first by copying this regexp into rubular:

changed (?<field>email|social_security_number|date_of_birth) to &quot;(?<value>.*?)&quot;

And then try this in the console:

1
2
3
4
5
6
7

regexp_named_captures = /changed (?<field>email|social_security_number|date_of_birth) to &quot;(?<value>.*?)&quot;/
match_data = log_entry.match(regexp_named_captures)
match_data[:field]
match_data[:value]
log_entry.scan(regexp_named_captures)
arr[0]
arr[0][0]

Now, back to the task at hand, which was to convert the original log entry with PII so that the PII is redacted. We’ll change the lines to something like this:

changed email to XXXXXX

Let’s take a look at the documentation for String#gsub

If replacement is a String it will be substituted for the matched text. It may contain back-references to the pattern’s capture groups of the form \d, where d is a group number, or \k<n>, where n is a group name. If it is a double-quoted string, both back-references must be preceded by an additional backslash. However, within replacement the special match variables, such as $&, will not refer to the current match.

1

log_entry.gsub(regexp_named_captures, "changed \\k<field> to XXXXXX")

And that results in mission accomplished!

Suppose you want to use the block syntax of String#gsub. Given the use case in this example, there’s no particular reason to use it. However, you might come across a use case where you’d like some logic in the bock to determine the substitution value. Here’s how you do it.

In the block form, the current match string is passed in as a parameter, and variables such as $1, $2, $`, $&, and $’ will be set appropriately. The value returned by the block will be substituted for the match on each call.

To use the block syntax with named capture groups is not exactly obvious.

You might think that the value passed into the block is the match data. Instead, it’s the full value of what was matched.

For example:

1

log_entry.gsub(regexp_named_captures) { |match| "XXXXXX" }

That’s not what we want. We want to show the field that was redacted.

Maybe we can use the same syntax as the non-block form:

1

log_entry.gsub(regexp_named_captures) { |match| "changed \\k<field> to XXXXXX" }

That doesn’t work!

The solution is that you have to use the globals mentioned above, like $1.

1

log_entry.gsub(regexp_named_captures) { |match| "changed #{$1} to XXXXXX" }

This works!

But what if you want to use the named capture groups?

Then you have to use the $~ which gives you the MatchData.

1

log_entry.gsub(regexp_named_captures) { |match| "changed #{$~[:field]} to XXXXXX" }

Nice! That works!

As the docs say, it’s a good idea to use the default value from the database declaration, like:

1
2
3

create_table :conversations do |t|
  t.column :status, :integer, default: 0, null: false
end

More specifically, consider using the first declared status (enum db value zero) be the default and to not allow null values. I’ve found that when I’ve allowed null values in enums, it makes all my code more complicated. This is an example of the Null Object Pattern. Nulls in your data and checking for these in your code will make your life more difficult! Instead, have an enum value for “I don’t know” if that really is a possibility, and make that first value, which is an index of zero, and you can set that as the database column default.

The docs say:

In rare circumstances you might need to access the mapping directly. The mappings are exposed through a class method with the pluralized attribute name

1

Conversation.statuses # => { "active" => 0, "archived" => 1 }

This is not rare! This is critical!

For example, suppose you want to query where the status is not “archived”:

You might be tempted to think that Rails will be smart enough to figure out that

1

Conversation.where("status <> ?", "archived")

Rails is not smart enough to know that the ? is for status and that is an enum. So you have to use this syntax:

1

Conversation.where("status <> ?", Conversation.statuses[:archived])

You might be tempted to think that this would work:

1

Conversation.where.not(status: :archived)

That throws an ArgumentError. Rails wants an integer and not a symbol, and symbol does not define to_i.

What’s worse is this one:

1

Conversation.where.not(status: "archived")

The problem is that ActiveRecord sees that the enum column is of type integer and calls #to_i on the value, so archived.to_i gets converted to zero. In fact, all your enums will get converted to zero! And if you use the value of the enum attribute on an ActiveRecord instance (say a Conversation object), then you’re using a string value!

If you’re curious what the Rails source is, then take a look here: ActiveRecord::Type::Integer.

Here’s a guaranteed broken bit of code:

1
2

# my_conversation.status is a String!
Conversation.where.not(status: my_conversation.status)

You’d think that Rails would be clever enough to see that the key maps to an enum and then check if the comparison value is a String, and then it would not call to_i on the String! Instead, we are effectively running this code:

1

Conversation.where.not(status: 0)

An acceptable alternative to the last code example would be:

1

Conversation.where.not(Conersation.statuses[my_conversation.status])

If you left out the not, you could also do:

1

Conversation.send(my_conversation.status)

However, I really would like to simply do these, all of which DO NOT work.:

1
2
3

Conversation.where(status: my_conversation.status)
Conversation.where(status: :archived)
Conversation.where(status: "archived")

Here’s another subtle issue with enums.

Should these two lines of code give the same result or a different result:

1
2

statuses_with_map = Conversation.select(:status).where.not(status: nil).distinct.map(&:status)
statuses_with_pluck = Conversation.distinct.where.not(status: nil).pluck(:status)

It’s worth experimenting with this in the Pry console!

In the first case, with map, you get back an Array with 2 strings: ["active", "archived"]. In the second case, with pluck, you get back an Array with 2 integers: [0, 1].

What’s going on here?

In the code where map calls the status method on each Conversation record, the status method converts the database integer value into the corresponding String value!

In the other code that uses :pluck, you get back the raw database value. It’s arguable whether or not Rails should intelligently transform this value into the string equivalent, since that is what is done in other uses of ActiveRecord. Changing this would be problematic, as there could be code that depends on getting back the numerical value.

Let’s suppose we have this persisted in the database:

Conversation {
  :id => 18,
  :user => 25            
  :status => "archived" (1 in database)
}

And then we do a find_or_initialize_by:

[47] (pry) main: 0> conversation = Conversation.find_or_initialize_by(user: 25, status: "archived")
  Conversation Load (4.6ms)  SELECT  "conversations".* FROM "conversations"
    WHERE "conversations"."user_id" = 25
       AND "conversations"."status" = 0 LIMIT 1
#<Conversation:> {
         :id => nil,
    :user_id => 25,
     :status => "archived"
}

We got nil for :id, meaning that we’re creating a new record. Wouldn’t you expect to find the existing record? Well, maybe not given the way that ActiveRecord.where works, per the above discussion.

Next, the status on the new record is created with “archived”, which is value 1. Hmmm….If you look closely above, the query uses

AND "conversations"."status" = 0

Let’s look at another example:

Conversation {
  :id => 19,
  :user => 26            
  :status => "active" (0 in database)
}

And then we do a find_or_initialize_by:

[47] (pry) main: 0> conversation = Conversation.find_or_initialize_by(user: 26, status: "active")
  Conversation Load (4.6ms)  SELECT  "conversations".* FROM "conversations"
    WHERE "conversations"."user_id" = 26
      AND "conversations"."status" = 0 LIMIT 1
#<Conversation:> {
         :id => 19,
    :user_id => 26,
     :status => "active"
}

Wow! Is this a source of subtle bugs and some serious yak shaving?

Note, the above applies equally to ActiveRecord.find_or_create_by.

It turns out that the Rails methods that allow creation of a record via a Hash of attributes will convert the enum strings to the proper integer values, but this is not case when querying!

You may find it useful to know which Rails methods call the “Default Accessor” versus just going to the database directly. That makes all the difference in terms of whether or not you can/should use the string values for enums.

The key thing is that that “Uses Default Accessor” means that string enums get converted to the correct database integer values.

For more information on this topic, see

1. Different Ways to Set Attributes in ActiveRecord by @DavidVerhasselt.
2. Official API of ActiveRecord::Base
3. Official Readme of Active Record – Object-relational mapping put on rails.

While these don’t mention Rails enums, it’s critical to understand that enums create default accessors that do the mapping to and from Strings.

So when you call these methods, the default accessors are used:

1
2
3

conversation.status = "archived"
conversation.status = 1
puts conversation.status # prints "archived"

So keep in mind when those default accessors are used per the above table.

If you look at the Rails source code for ActiveRecord::Enum, you can see this at line 91, for the setter of the enum (I added some comments):

1
2
3
4
5
6
7
8
9
10
11
12
13

_enum_methods_module.module_eval do
  # def status=(value) self[:status] = statuses[value] end
  define_method("#{name}=") { |value|
    if enum_values.has_key?(value) || value.blank?
      # set the db value to the integer value for the enum
      self[name] = enum_values[value]
    elsif enum_values.has_value?(value) # values contains the integer
      self[name] = value
    else
      # enum_values did not have the key or value passed
      raise ArgumentError, "'#{value}' is not a valid #{name}"
    end
  }

From this definition, you see that both of these work:

1
2

conversation.status = "active"
conversation.status = 0

Here’s the definition for the getter, which I’ve edited a bit for illustrative purposes:

1
2
3
4
5

# def status() statuses.key self[:status] end
define_method(name) do
  db_value = self[name] # such as 0 or 1
  enum_values.key(db_value) # the key value, like "archived" for db_value 1
end

In response to this issue, I submitted this github issue: Rails where query should see value is an enum and convert a string #17226

1. @Bounga and @rafaelfranca on Github suggest that we can’t automatically convert enum string values in queries. I think that is true for converting cases of a ? or a named param, but I suspect that a quick map lookup to see that the attribute is an enum, and a string is passed, and then converting the string value to an integer is the right thing to do for 2 reasons:
   1. This is the sort of “magic” that I expect from Rails.
   2. Existing methods find_or_initialize_by and find_or_create_by will result in obscure bugs when string params are passed for enums.

   However, it’s worth considering if all default accessor methods (setters) should be consistently be called for purposes of passing values in a map to such methods. I would venture that Rails enums are some Rails provided magic, and thus they should have a special case. If this shouldn’t go into Rails, then possibly a gem extension could provide a method like Model.where_with_enum which would convert a String into the proper numerical value for the enum. I’m not a huge fan of the generated Model scopes for enums, as I like to see what database field is being queried against.

2. Aside from putting automatic conversion of the enum hash attributes, I recommend we change the automatic conversion of Strings to integers to use the stricter Integer(some_string) rather than some_string.to_i. The difference is considerable, String#to_i is extremely permissive. Try it in a console. With the to_i method, any number characters at the beginning of the String are converted to an Integer. If the first character is not a number, 0 is returned, which is almost certainly a default enum value. Thus, this simple change would make it extremely clear when an enum string is improperly used. I would guess that this would make some existing code crash, but in all circumstances for a valid reason. As to whether this change should be done for all integer attributes is a different discussion, as that could have backwards compatibility ramifications. This change would require changing the tests in ActiveRecord::ConnectionAdapters::TypesTest. For example, this test:

   1	assert_equal 0, type.type_cast_from_user('bad')

   would change to throw an exception, unless the cases are restricted to using Integer.new() for enums. It is inconsistent that some type conversions throw exceptions, such as converting a symbol to an integer. Whether or not they should is much larger issue. In the case of enums, I definitely believe that proper enum string value should not silently convert to zero every time.

My foray down the Node rabbit hole began with a desire to use the React framework, including its JSX transpiler. In a nutshell, the React library stands out as unique, innovative, and impressive. You can simply think about the client-side UI as a set of components that are recursively composed and which render based on set of data that flows in one direction, from the top level component to each of its children. For further details into the benefits of React, see my article React on Rails Tutorial. For purposes of this article, you can imagine substituting my example of using React with your favorite rich client JavaScript framework. I’d be thrilled if somebody would fork my project and create a version using EmberJs.

At first this mission of integrating React seemed easy, as there is a Ruby Gem, the react-rails gem, that provided a relatively painless mechanism of integrating react into a Rails project. This is definitely the simplest method. I’ve created a tutorial, React on Rails Tutorial, with a companion github repository, justin808/react-rails-tutorial, that walks you through using the react-rails gem with the Rails 4.2 scaffold generator. Then I wanted to plug in the react-bootstrap library. With no gem available, I considered manually copy-pasting the source to my /vendor/assets/javascripts directory, but that just seemed to smell for the following reasons:

1. JavaScript has a mature system for managing dependencies (packages & modules): npm (and bower).
2. Dependencies often depend on other dependencies, in both the Ruby and JavaScript worlds. Imagine managing Ruby dependencies by hand.
3. JavaScript modules often depend on either CommonJs or RequireJs being available.

(Side note: in terms of Node, a module is a special case of package that JavaScript code can require(). For more info, see the npm faq and Stack Overflow).

Here’s a good summary of other ways to handle the assets in a Rails app: Five Ways to Manage Front-End Assets in Rails. I briefly tried those techniques, plus the browserify-rails gem. However, they seemed to conflict with the react-rails gem, and if I didn’t use that gem, I’d need a way to convert the jsx into js files. This led me to try the webpack module bundler.

You’ll need to install Node.js following. I’m assuming you already have Ruby and Rails installed.

1. Node.js: You can find the Node.js download file here. Note, some friends of mine recommended the Node.js installer rather than using Brew. I did not try Brew.

2. Many articles recommend running the following command, so that you don’t need to run node commands as sudo, thus changing the ownership of your /usr/local directory to yourself.

   1	sudo chown -R $USER /usr/local

3. Your /package.json file describes all other other dependencies, and running npm install will install everything required.

Once I got this working, it felt like Santa Clause came to my app with the whole Node ecosystem!

All Rails developers are familiar with gems and Bundler (bundle). The equivalent for Javascript are package.json files with Node Package Manager (npm) (see discussion in next point on why not Bower).

Both of these package manager systems take care of retreiving dependencies from reputable online sources. Using a package.json file is far superior to manually downloading dependencies and copying the /vendor/assets/ directory!

The most popular equivalants for JavaScript are Node Package Manager (npm) and Bower. For use with webpack, you’ll want to prefer npm, per the reasons in the documentation:

In many cases modules from npm are better than the same module from bower. Bower mostly contain only concatenated/bundled files which are:

• More difficult to handle for webpack
• More difficult to optimize for webpack
• Sometimes only useable without a module system

So prefer to use the CommonJs-style module and let webpack build it.

To integrate webpack with Rails, webpack is used in 2 ways:

1. Webpack is used soley within the /webpack directory in conjunction with the Webpack Dev Server to provide a rapid tool for prototyping the client side Javascript. The file webpack.hot.config.js sets up the JS and CSS assets for the Webpack Dev Server.
2. Webpack watches for changes and generates the rails-bundle.js file that bundles all the JavaScript referenced in the /webpack/assets/javascripts directory. The file webpack.rails.config.js converts the JSX files into JS files throught the JSX and ES6 transpilers.

The following image describes the organization of integrating Webpack with Rails.

To reiterate, we needed Webpack for the following reasons:

1. To enable the use of JS “modules”, using either the either the AMD (aka require.js) or CommonJs module syntax.
2. To convert JSX files (ES6 and JSX syntax) into JS files. Note, you probably don’t want to blindly convert all JS files into ES6, as that may conflict with some imported modules.

This setup with the webpack.config file. We need 2 versions of this file for the two different needs, the Webpack Dev Sever and the Asset Pipeline.

While waiting for webpack to create the rails-bundle.js file and then reloading the Rails page is not terribly time consuming, there’s no comparison to using the Webpack Dev Server with Hot Module Replacement which loads new JavaScript and Sass code without modifying the existing client side data if possible. If you thought Live Reload was cool, you’ll love this feature. To quote the documentation:

The webpack-dev-server is a little node.js express server, which uses the webpack-dev-middleware to serve a webpack bundle. It also has a little runtime which is connected to the server via socket.io. The server emit information about the compilation state to the client, which reacts on that events.

It serves static assets from the current directory. If the file isn’t found a empty HTML page is generated whichs references the corresponding javascript file.

In a nutshell, the file /webpack/server.js is the http server utilizing the Webpack Dev Server API:

1. /webpack/webpack.hot.config.js configures the webpack assets.
2. Has a couple of json responses.
3. Configures “hot” to be true to enable hot module replacement.

Webpack handles the following aspects of the /webpack/assets/javascripts directory:

1. Preparing a “bundle” of the JavaScript files needed by either Rails or the Webpack Dev Server. This includes running the files through the jsx and es6 loaders which transpile the jsx and es6 syntax into standard javascripts. Heres’ the configuration that does the loading:

   1	module.loaders = [{ test: /\.jsx$/, loaders: ["react-hot", "es6", "jsx?harmony"] }]

2. Webpack also normalizes whichever module loading syntax you choose (RequireJs, CommonJs, or ES6).

For the Webpack Dev Server build (not the Rails build that creates rails-bundle.js), Sass is loaded via webpack for 2 reasons:

1. Webpack takes care of running the sass compiler.
2. Any changes made to sass or css files are loaded by the hot module loader into the browser.

The file /webpack/scripts/webpack_only.jsx contains this:

1
2

require("test-stylesheet.css");
require("test-sass-stylesheet.scss");

This “requires” stylesheet information just like a “require” of JavaScript. Thus, /webpack/index.html does not reference any output from the Sass generation. This file, webpack_only.jsx is referenced only in the webpack.hot.config.js file as an “entry point”, which means that it gets loaded explicitly in the created bundle file.

Images were a bit tricky, as during deployment, you want your images fingerprinted for caching purposes. This is nearly invisible to users of newer versions of the Rails, thanks to the fingerprinting feature of the Rails asset pipeline. While webpack can also fingerprint images, that’s not needed as we’re not depending on this feature of webpack for our Rails deployments. So we just need the Webpack Dev Server to access the same image files. I.e., we need to be able to use a syntax in the scss files to reference images that works for both the Webpack Dev Server as well as the Rails asset pipeline.

For example, here’s a snippet of sass code to load the twitter_64.png image from the top level of the /app/assets/images directory. This needs to work for both the Asset Pipeline as well as the Webpack Dev Server.

1
2
3

.twitter-image {
  background-image: image-url('twitter_64.png');
}

The problem of how to get the same images into the stylesheets of both Rails and Express server versions was solved by using a symlink, which git will conveniently store.

1. /webpack/assets/images is a symlink for the /app/assets/images directory.

2. The image-url sass helper takes care of mapping the correct directories for images. The image directory for the webpack server is configured by this line:

   1	module.loaders = [{ test: /.scss$/, loader: “style!css!sass?outputStyle=expanded&imagePath=/assets/images”}]

   The sass gem for rails handles the mapping for the Asset Pipeline.

3. The symlink was necessary, as the Webpack Dev Server could not reference files above the root directory.

This way the images are signed correctly for production builds via the Rails asset pipeline, and the images work fine for the Webpack Dev Server.

When debugging JavaScript using the Rails app, I did not want to have to scroll through a giant rails-bundle.js of all js assets. Sourcemap support in Webpack addressed that issue. At first I tried to use plain sourcemaps (separate file rather than integrated), but that resulted in an off by one error. Furthermore, I had to do some fancy work to move the created file to the correct spot of /public/assets. Also note that building the sourcemap file when deploying to Heroku breaks the Heroku build. Both of these cases are handled at the bottom of the file webpack.rails.config.js.

This is what sourcemaps looks like in Chrome

There are several things needed to get builds working on Heroku.

1. It’s critical that package.json has all tools required by the Heroku build in dependencies and not devDependencies as Heroku only installs those modules in dependencies. You should use devDependencies for tools that only your local Webpack Dev Server uses.

2. Clean up your build cache:

   1 2	heroku plugins:install https://github.com/heroku/heroku-repo.git heroku repo:purge_cache -a <my-app>

3. Be sure to run npm-shrinkwrap after ANY changes to dependencies inside of package.json.
4. I needed to configure the compile_environment task to create the rails-bundle.js via Webpack using the file /lib/tasks/assets.rake.
5. Heroku needs both the node and ruby environments. In order to deploy to heroku, you’ll need run this command once to set a custom buildpack:

1

heroku config:add BUILDPACK_URL=https://github.com/ddollar/heroku-buildpack-multi.git

This runs the two buildpacks in the /.buildpacks file courtesy of the ddollar/heroku-buildpack-multi buildpack.

While it would be tidier to put node_modules and package.json into the /webpack directory, the problem is that this would require a custom buildpack for installing the node_modules on Heroku.

At first, I had Webpack reference the JSX files from the /app/assets/javascripts directory. However, I wanted to be able to use a WebStorm project just based on the JavaScript code. I’d either have to put the WebStorm project at the root level, thus including all the Ruby directories, or I could use a sym link to the javascripts directory. You NEVER want run two different JetBrains products simultaneously on the same directory, so that ruled out using WebStorm at the top of my Rails app. The symlink approach seemed to work, but that got confusing especially given I’d sometimes open the JSX files in Emacs.

The approach of putting the webpack bundled assets under the /webpack/assets directory worked out well for me. It seems natural that Webpack bundles those assets and puts them into the rails-bundle.js file in the /app/assets/javascripts directory.

For the same reasons, I’m keeping style sheets referenced by Webpack under the /webpack directory. Note, I’m using Webpack to load stylesheets, as that allows the style sheet changes to be hot loaded into the browser! If you edit any of the files in the /webpack/assets/stylesheets directory, you’ll see the browser update with the style changes almost immediately after you hit save. The standard Rails file /app/assets/stylesheets/application.css.scss references the file style sheets in /webpack/assets/stylesheets.

This is a bit like modifying your Gemfile with a new gem dependency.

1. Modify your /package.json file with the appropriate line for the desired package inside the “dependencies” section. You’ll want to specify an exact version, as that’s the recommendation in the Node community. Just google “npm <whatever module>” and you’ll get a link to the npm page for that module where you can see the version. For example, to add marked as a dependency, I added this line to package.json.

   1	"marked": "^0.3.2",

2. Include the appropriate line to require the module. For example, to include the marked library:

   1	var marked = require("marked");

When you’re ready to take the time to ensure that upgrading your packages will not break your code, you’ll want to take the following steps. Refer to npm-check-updates and npm-shrinkwrap.

1
2
3
4
5
6

cd <top level of your app>
rm -rf node_modules
npm install -g npm-check-updates
npm-check-updates -u
npm install
npm-shrinkwrap

1. Install Ruby 2.1.2 or whichever recent Ruby you prefer. I use rvm.
2. Install Rails gem

   1	gem install rails --pre

   NOTE: There is a bug if you RubyGems versions newer than 2.2.2. This detailed in this question on Stack Overflow.

3. Create the Rails app

   1	rails new react-rails-tutorial

4. cd react-rails-tutorial
5. Create .ruby-version and .ruby-gemset per your preferences inside react-rails-tutorial directory.
6. Run bundler

   1	bundle install

7. Create new git repository

   1	git init .

8. Add and commit all files:

   1	git add . && git commit -m "rails new react-rails-tutorial"

1. Run generator. Be sure to use the exact names below to match the React tutorial.

   1	rails generate scaffold Comment author:string text:text

2. Migrate the database

   1	rake db:migrate

3. Commit

   1	git add . && git commit -m "Ran rails generate scaffold Comment author:string text:text and rake db:migrate"

1. Run the controller generator

   1	rails generate controller Pages index

2. Fix your config/routes.rb to go to the home page, by changing

   1	get 'pages/index'

   to

   1	root 'pages#index'

1. Start the server

   1	rails server

2. Open your browser to http://0.0.0.0:3000 and see the your blank home page.
3. Open your browser to http://0.0.0.0:3000/comments and see the comments display.
4. Add a comment. Click around. Neat!

   

5. Test out the json API, automatically created by Rails:

   1	curl 0.0.0.0:3000/comments.json

   and see

   [{"id":1,"author":"Justin","text":"My first comment.","url":"http://0.0.0.0:3000/comments/1.json"}]%
   

6. View your routes

   > rake routes                                                                                                                                    ✹ ✭ [19:44:29]
            Prefix Verb   URI Pattern                  Controller#Action
              root GET    /                            pages#index
          comments GET    /comments(.:format)          comments#index
                   POST   /comments(.:format)          comments#create
       new_comment GET    /comments/new(.:format)      comments#new
      edit_comment GET    /comments/:id/edit(.:format) comments#edit
           comment GET    /comments/:id(.:format)      comments#show
                   PATCH  /comments/:id(.:format)      comments#update
                   PUT    /comments/:id(.:format)      comments#update
                   DELETE /comments/:id(.:format)      comments#destroy
   

7. If all that worked, then commit your changes

   1	git add . && git commit -m "Ran rails generate scaffold Comment author:string text:text and rake db:migrate"

This is what we’ll be converting to Rails 4.2.

1. Create a new branch, in case we want to test the same design with AngularJS or EmberJS:

   1	git checkout -b "react"

2. Take a look at the React Tutorial and the github repo: reactjs/react-tutorial.
3. Open up a new shell window. Pick a directory and then do

   1	git clone git@github.com:reactjs/react-tutorial.git

4. cd to the react-tutorial.git directory and open up the source code.
5. Optionally run the tutorial example per the instructions on the README.md

1. We’ll be using the reactjs/react-rails gem. Plus we’ll need to include the showdown markdown parser, using the showdown-rails gem. Add these lines to your Gemfile and run bundle

   1 2	gem 'react-rails', github: 'reactjs/react-rails', branch: 'master' gem 'showdown-rails'

   Note, I’m using the tip of react-rails. Depending on when you try this tutorial, you may not wish to be using the tip, and don’t do that for a production application!

2. Per the gem instructions, let’s add the js assets below the turbolinks reference in app/assets/javascripts/application.js

   1 2 3 4 5 6

   //= require jquery //= require jquery_ujs //= require turbolinks //= require showdown //= require react //= require_tree .

3. Once you verify that you can load 0.0.0.0:3000 in your browser, then commit the files to git:

   1	git commit -am "Added react-rails and showdown-rails gems"

Now the fun starts. Let’s take the parts out of the node tutorial and put them into the Rails app.

1. Copy the necessary line from react-tutorial/index.html to replace the contents of app/views/pages/index.html.erb. You’ll just have one line there:

   1	<div id="content"></div>

2. Now, the meat of the tutorial, the JS code. Copy the entire contents of react-tutorial/scripts/example.js into app/assets/javascripts/comments.js.jsx (Renamed from comments.js.coffee).
3. Commit the added files, so we can see what we change from the original versions.

   1	git commit -am "index.html.erb and comments.js.jsx added"

4. Start the rails server (rails s). Visit 0.0.0.0:3000. Nothing shows up!

In the example, the call to load example.js comes after the declaration of the DOM element with id “content”. So let’s run the renderComponent after the DOM loads. Wrap the React.renderComponent call at the bottom of comments.js.jsx like this:

1
2
3
4
5
6

$(function() {
  React.renderComponent(
    <CommentBox url="comments.json" pollInterval={2000} />,
    document.getElementById('content')
  );
})

Let’s commit that diff: =git commit -am “React component loads”=

Then copy the css from react-tutorial/css/base.css over to app/assets/stylesheets/comments.css.scsss

The styling in is not quite right.

1. Add the gems

   1 2	gem 'bootstrap-sass' gem 'autoprefixer-rails'

2. Run bundle install
3. Rename app/assets/stylesheets/application.css to application.css.scss and change it to the following:

   1 2	@import "bootstrap-sprockets"; @import "bootstrap";

4. Optionally, add this line to app/assets/javascripts/application.js

   1	//= require bootstrap-sprockets

5. Restart the application. Notice that there is no padding to the left edge of the browser window. That’s an easy fix. Let’s put the content div inside a container, by changing app/views/pages/index.html.erb to this:

   1 2 3

   <div class="container"> <div id="content"></div> </div>

6. Let’s spruce up the data entry part. Take a look at the Boostrap docs for CSS Forms. You’ll have to refer to the diffs on github for this change. Or you can take creative license here!

The first issue is that we’re not submitting the JSON correctly to add new records.

Started POST "/comments.json" for 127.0.0.1 at 2014-08-22 21:48:55 -1000
Processing by CommentsController#create as JSON
  Parameters: {"author"=>"JG", "text"=>"Another **comment**"}
Completed 400 Bad Request in 1ms

ActionController::ParameterMissing (param is missing or the value is empty: comment):
  app/controllers/comments_controller.rb:72:in `comment_params'
  app/controllers/comments_controller.rb:27:in `create'

If you look at this method in comments_controller.rb, you can see the issue:

1
2
3

def comment_params
  params.require(:comment).permit(:author, :text)
end

The fix to this is to wrap the params in “comment”, by changing this line in comments.jsx.js, in function handleCommentSubmit.

1

data: comment,

to

1

data: { comment: comment },

Here’s a enlarged view of that diff from RubyMine.

After that change, we can observe this in the console when adding a new record:

Started POST "/comments.json" for 127.0.0.1 at 2014-08-22 21:55:18 -1000
Processing by CommentsController#create as JSON
  Parameters: {"comment"=>{"author"=>"JG", "text"=>"Another **comment**"}}
   (0.1ms)  begin transaction
  SQL (0.7ms)  INSERT INTO "comments" ("author", "created_at", "text", "updated_at") VALUES (?, ?, ?, ?)  [["author", "JG"], ["created_at", "2014-08-23 07:55:18.234473"], ["text", "Another **comment**"], ["updated_at", "2014-08-23 07:55:18.234473"]]
   (3.0ms)  commit transaction
  Rendered comments/show.json.jbuilder (0.7ms)
Completed 201 Created in 22ms (Views: 5.0ms | ActiveRecord: 3.9ms)

If you go to the url 0.0.0.0:3000/comments and look at browser console, you’ll see an error due the page load script looking for a component of id content that doesn’t exist. Let’s fix that by checking that the DIV with id content exists before calling React.renderComponent.

1
2
3
4
5
6
7
8
9

$(function() {
  var $content = $("#content");
  if ($content.length > 0) {
    React.renderComponent(
      <CommentBox url="comments.json" pollInterval={2000} />,
      document.getElementById('content')
    );
  }
})

It’s necessary to make a couple changes to the Gemfile. Use pg in production and add the rails_12factor gem.

1
2
3
4

gem 'sqlite3', group: :development
gem 'pg', group: :production

gem 'rails_12factor'

If you’re going to have other pages in the application, it’s necessary to change when React.renderComponent is called, switching from document “ready” event to to the document “page:change” event. You can find more details at the Turbolinks Gem repo.

1
2
3
4
5
6
7
8
9

$(document).on("page:change", function() {
  var $content = $("#content");
  if ($content.length > 0) {
    React.renderComponent(
      <CommentBox url="comments.json" pollInterval={2000} />,
      document.getElementById('content')
    );
  }
})

The configuration of Discourse for blogging is super easy.

1. Configure the following settings, taking note that:
   1. The urls are to your blog and include the subdomain, like www.railsonmaui.com.
   2. The embeddable host does not include http://
   3. The feed polling URL does include http://

   

2. I added a category called “Blog”.
3. I created a user called “disqus” for users not found in the Disqus comment import.

1. Remove or comment out your Disqus setup in your /_config.yml file:

   1 2 3 4

   # Disqus Comments # Removed as support for Discourse comments added # disqus_short_name: railsonmaui # disqus_show_comment_count: true

   Note, I first commented it out, because I toggled this on and off as I was ensuring that the comment migration worked correctly, and none were missed.

2. Add the plugin contained in discourse_comments.rb to your /plugins directory. This plugin will append a DIV to your posts like this:

   1 2 3 4 5 6 7 8 9 10 11

   <div id="discourse-comments"></div> <script type="text/javascript"> var discourseUrl = "#{@site.config['discourse_url']}", discourseEmbedUrl = "#{@site.config['url']}#{@site.config['baseurl']}#{url}"; (function() { var d = document.createElement('script'); d.type = 'text/javascript'; d.async = true; d.src = discourseUrl + 'javascripts/embed.js'; (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d); })(); </script>

3. Note that the display of comments only works on your live website, due the fact that the Discourse server checks the source of the request for the comments (per the above image of the configuration).

The following instructions will allow you to import the comments from Disqus, along with creating associated users for those comments. This is a GREAT way to kickstart the forum.

1. Download an XML backup of your Disqus comments by logging into your Disqus dashboard. The URL is like https://youraccount.disqus.com/admin/discussions/.
2. That should bring you to the Discussions tab. Then click the Export sub-tab. It should look like this: You’ll have to wait a few minutes for the creation email. I then saved the file to my ~/Downloads directory.
3. Ssh to your docker instance

   1	ssh root@XXX.XXX.XXX.XXX

4. Get into your docker instance.

   root@forum:~# cd /var/discourse/
   root@forum:/var/discourse# ./launcher ssh app
   

   You’ll see this message:

   Welcome to Discourse Docker
   Use: rails, rake or discourse to execute commands in production
   

5. Sudo to discourse:

   root@forum:~# sudo -iu discourse
   discourse@forum:~$ cd /var/www/discourse
   discourse@forum:/var/www/discourse$ bundle exec thor list
   

6. Then you need to copy the XML file you downloaded from Disqus that contains an archive of your comments. The easiest way to do this is to scp the file from some place accessible on the Internet. What I did was to scp the file from my local machine to my Digital Ocean machine, and then from my Digital Ocean machine to the Docker container. Here’s an example:

   On your local machine, with the XML file (XXX.XXX.XXX.XXX is the ip of your droplet):

   1	scp ~/Downloads/railsonmaui-disqus.xml root@XXX.XXX.XXX.XXX

   Then inside of your docker container:

   discourse@forum:/var/www/discourse$ scp root@XXX.XXX.XXX.XXX:railsonmaui-disqus.xml .
   

   That puts the file railsonmaui-disqus.xml in the current directory.

7. Run the thor command:

   discourse@forum:/var/www/discourse$ bundle exec thor disqus:import --file=railsonmaui-disqus.xml --post-as=disqus --dry-run
   /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.6/lib/active_record/connection_adapters/postgresql_adapter.rb:898:in `rescue in connect': FATAL:  database "discourse_development" does not exist (ActiveRecord::NoDatabaseError)
   Run `$ bin/rake db:create db:migrate` to create your database
     from /var/www/discourse/vendor/bundle/ruby/2.0.0/gems/activerecord-4.1.6/lib/active_record/connection_adapters/postgresql_adapter.rb:888:in `connect'
   

   The problem is that we need to specify the environment, as is standard with Rails apps:

   1	RAILS_ENV=production bundle exec thor disqus:import --file=railsonmaui-disqus.xml --post-as=disqus --dry-run

   That command does the trick and gives you a nice message indicating what it will do once you remove the --dry-run flag.

   discourse@forum:/var/www/discourse$ RAILS_ENV=production bundle exec thor disqus:import --file=railsonmaui-disqus.xml --post-as=disqus --dry-run
   Creating Favorite RubyMine Tips - Rails on Maui... (8 posts)
   Creating Octopress Setup with Github, Org Mode, and LiveReload - Rails on Maui... (3 posts)
   

   Once you verify, run:

   1	RAILS_ENV=production bundle exec thor disqus:import --file=railsonmaui-disqus.xml --post-as=disqus

   This creates the comments and the users. Creating the users surprised me as I didn’t know that the Disqus export contained the users’ email addresses. So this script ends up triggering activation emails to all those users!

Large libraries, like Rails, RSpec, Twitter Bootstrap, etc. are going to take more elbow grease to update. Typically if a major version number is updating, like Rails 3.x to 4.x and RSpec 2.x to 3.x, that’s going to require lots of code changes. Semantic versioning also comes into play. Going from Rails 3.x to Rails 4.x is more difficult than Rails 4.0 to Rails 4.1. There’s a similar story with RSpec 2.x to 2.99, compared to going to RSpec 3.0.

Unless you have a good reason, don’t lock a gem to a specific version as that makes updating gems more difficult. In general, consider only locking the major Rails gems, such as rails, RSpec, and bootstrap-sass, as these are the ones that will likely have more involved upgrades.

Tools that speed up Rails like Zeus and Spring are awesome productivity enhancers, except when upgrading gems. I found that they sometimes correctly reloaded new versions of gems. That means massive frustration when they are not picking up the gems you actually have specified. The corollary to this is to run your tests using plain rspec rather than the recommended ways for speeding up testing, such as the parallel_tests gem..

It’s not necessary to introduce the added complexity of the test accelerators when doing major library updates. Once you’ve updated your gems, then try out your favorite techniques for speeding up running tests. I’ve learned the hard way on this one. The pgr and pgk scripts below are awesome for ensuring that pre-loaders are NOT running.

1
2
3
4
5
6
7
8
9
10
11

pgr() {
  for x in spring rails phantomjs zeus; do
    pgrep -fl $x;
  done
}

pgk() {
  for x in spring rails phantomjs zeus; do
    pkill -fl $x;
  done
}

There are a lot of discussions about the value or lack of for an emphasis on Test-Driven Development (TDD). However, one thing that’s indisputable is that having a large library of tests is absolutely helpful for upgrading your gems.

Naturally, it’s an iterative process to get tests passing when updating gems. First, make sure your tests suite is passing.

You can try updating the gems one by one until you get a test failure. Then the issue becomes one of figuring out which related gems you might want to update to fix the test failure.

If you don’t have good tests coverage, a great place to start is with integration tests that do the basics of your app. At least you’ll be able to quickly verify a good chunk of your app can at least navigate the “happy path” as you iterate updating your gems.

If you’ve updated gems recently, sometimes you can run bundle update and everything works great. Recently, that strategy failed miserably when I tried going from Rails 4.0 with RSpec 2.2 to Rails 4.1 and RSpec 3. An eariler attempt shortly after the releases of Rails 4.1 and RSpec 3 clearly showed that many dependent gems would have to get updated. A few months later, I still had many issues with trying to update too much at once.

When this happens, take small steps and kept tests passing. I.e., don’t do a bundle update without specifying which gems to update. You might update 60 gems at once! And then when tests fail, you won’t be able to easily decipher which dependency is the problem. Specify which gems to update by running the command:

1

bundle update gem1 gem2 etc

Then after updating a few gems, run rspec and verify your tests pass.

Then commit your changes. Consider putting a summary of how many tests pass and how long it takes. The length of time is useful in case some change greatly increases test run time. Or if you notice run time or the number of tests dramatically decrease. Plus, this ensures you ran the test before committing!

On a related note, you can see which gems are outdated with this command: bundle outdated.

Remember I told you not to do a bundle update? Once you’re getting closer to finishing your gem updates, all big gems are updated, and all tests are passing, and deprecation warnings are addressed, then it’s time to run bundle update and then run rspec to see if your tests pass. If you don’t have adequate tests, then be ready to do some adequate manual testing. Even if you have lots of tests, you still need to do manual testing if you upgrade a UI library such as sass-bootstrap. Besides testings, check the bundler output or the diff of your Gemfile.lock to see what got updated.

Too often Ruby developers will blindly copy-paste their error messages into a Google search without really reading the console output carefully. This can actually waste more time, since thinking about the problem for a moment can often give you a solution without Google, or you’ll write a better search query. If you don’t find what you need on Google and you have an idea what gem is causing issues, the next place to search is the issues page for the gem’s Github repository.

Remember to do these 2 types of searches rather than spending too much time inserting print statements or launching the debugger! If you don’t get any search hits, then typically you have some problem in app customizations (see below).

Some essential places to look at when upgrading gems are:

1. README.md file (shown on the main page of repository). Some projects might have a NEWS.md or CHANGELOG.md file.
2. The Github issues list for a gem (and search here)
3. The Github commit history for a gem, sometimes switching branches.

Errors or deprecation messages can come from compatibility issues among your gems. The RSpec 3 upgrade had many such issues. If you’re having an upgrade issue, then a concise, detailed post of a new issue typically results in a very quick response.

Sometimes the fix you need has already been released to RubyGems in an RC version (RC means Release Candidate). bundle update <gem> seems to not pick RC versions. You have to specify these manually. I search for gems on RubyGems so often that I created a Chrome search shortcut. Here’s an example of an RC version gem that I’m currently using:

1

gem 'simple_form', '>= 3.1.0.rc2'

Sometimes what you need has not been shared with RubyGems, yet the issue has received commits on Github. In that case, you can use the Github version of a gem. This might be on a specific branch of a gem, or even another user’s fork of a gem.

For example, this image shows that the last version bump of the gon gem is behind several commits.

If you needed those commits post gem release, here’s an example of the syntax to specify the very-latest version of a gem (the tip of the master branch):

1

gem 'gon', github: "gazay/gon", branch: "master"

Sometimes what you need is something less than the most current version, or a specific branch, or a fork of the gem.

Sometimes you need to fork a gem for some changes. If you’ve never done this, it’s a very worthwhile thing to try out, and it’s easy! For example, if you had wanted to update to rspec 3 sooner than later and didn’t want to see tons of deprecation messages, then your only option was to fork the gems that had the deprecated syntax. Once you’ve verified the validity of your changes, consider submitting a pull request. Here’s an example of a fork and commit of the zeus-parallel_tests gem that loosened a gem dependency.

You should typically prefer a rubygems version of a gem rather than a github version. Thus, after some months, you should try to remove any previously necessary github references in your Gemfile.

I ran into a case where including rspec-instafail before rspec resulted in zeus failing due to rspec-instafail failing to recognize that I was using rspec 3. Simply placing rspec-instafail after loading rspec in the Gemfile fixed that issue.

I had a clue that was the issue due to this stack dump. Note how the bundler is loading rspec-instafail, and when I looked at the source code, I could see why file rspec_2.rb was being loaded (2nd line of the below stack dump)

zeus test                                                                                                                                                                                                 ✹ ✚ ✭ [15:37:26]
/Users/justin/.rvm/gems/ruby-2.1.2@bpos/gems/rspec-core-3.0.3/lib/rspec/core/formatters/progress_formatter.rb:1:in `<top (required)>': uninitialized constant RSpec::Support (NameError)
	from /Users/justin/.rvm/gems/ruby-2.1.2@bpos/gems/rspec-instafail-0.2.5/lib/rspec/instafail/rspec_2.rb:1:in `<top (required)>'
	from /Users/justin/.rvm/gems/ruby-2.1.2@bpos/gems/rspec-instafail-0.2.5/lib/rspec/instafail.rb:11:in `<module:RSpec>'
	from /Users/justin/.rvm/gems/ruby-2.1.2@bpos/gems/rspec-instafail-0.2.5/lib/rspec/instafail.rb:1:in `<top (required)>'
	from /Users/justin/.rvm/gems/ruby-2.1.2@global/gems/bundler-1.6.2/lib/bundler/runtime.rb:85:in `require'
	from /Users/justin/.rvm/gems/ruby-2.1.2@global/gems/bundler-1.6.2/lib/bundler/runtime.rb:85:in `rescue in block in require'
	from /Users/justin/.rvm/gems/ruby-2.1.2@global/gems/bundler-1.6.2/lib/bundler/runtime.rb:68:in `block in require'
	from /Users/justin/.rvm/gems/ruby-2.1.2@global/gems/bundler-1.6.2/lib/bundler/runtime.rb:61:in `each'
	from /Users/justin/.rvm/gems/ruby-2.1.2@global/gems/bundler-1.6.2/lib/bundler/runtime.rb:61:in `require'
	from /Users/justin/.rvm/gems/ruby-2.1.2@global/gems/bundler-1.6.2/lib/bundler.rb:132:in `require'
	from /Users/justin/.rvm/gems/ruby-2.1.2@bpos/gems/zeus-0.13.3/lib/zeus/rails.rb:162:in `test_environment'
	from /Users/justin/.rvm/gems/ruby-2.1.2@bpos/gems/zeus-0.13.3/lib/zeus.rb:166:in `run_action'
  ...
	from -e:1:in `<main>'

In general, when doing relatively major gem upgrades, you really need to evaluate customizations to these places. Typically, deprecation messages will tell you which customizations to remove or alter. Sometimes, you’ve monkey patched some gem to work around some issue, and this would be the place where you’d do that (and forget that you did it!).

1. Any initializers in the config/initializers directory. Review each file there.
2. Any customizations in your environment files in the config/environments directory, such as test.rb, development.rb.
3. Any customizations for running specs: a. spec/spec_helper.rb b. Each file in the spec/support directory.

RubyMine’s Find in Path, searching Project and Libraries, is extremely useful to getting more context around an error message. In this case, RubyMine found the error message in a C file.

Here’s the C code containing the error message. The Ruby stack trace did not go this far:

1
2
3
4
5
6
7
8
9
10
11
12
13

/*
 * Fetch the data pointer and check it for sanity.
 */
PGconn *
pg_get_pgconn( VALUE self )
{
  PGconn *conn = pgconn_check( self );

  if ( !conn )
    rb_raise( rb_eConnectionBad, "connection is closed" );

  return conn;
}

And this is where in the Ruby Code that came from the stack trace:

1
2
3
4
5
6
7

# Disconnects from the database if already connected, and establishes a
# new connection with the database. Implementors should call super if they
# override the default implementation.
def reconnect!
  clear_cache!
  reset_transaction
end

In the really troubling issue I saw below, I put in breakpoints in the connection adapter gem. I correctly guessed the cause of the error was disconnect! rather than the reconnect!

Here’s a few images that show how the debugger really helped me figure out the obscure “connection is closed” error:

That is what led me to try out removing the heroku-resque gem, as I noticed that was what was closing the connections in my test runs. Removing that gem fixed my rspec errors with the upgrades.

Note, an alternative to using breakpoints in RubyMine would have been to put in a puts caller in the suspect methods of the libraries. However, one would have to remember to remove that later! I think the debugger was a good pick for this issue. If you don’t use RubyMine, you might try the ruby debugger or the pry gem.

NoMethodError:
  undefined method `shuffle!' for #<ActiveRecord::Relation []>

The fix for that is to convert the relation to an array before calling shuffle. Naturally, you only want to do this with a limited set of data.

This one bit me: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#flash-structure-changes

I was comparing symbols when converting from the flash type to the bootstrap class. Since the keys are always normalized to strings, I changed the code to compare to strings.

It’s a good idea to review all changes in that the Rails Upgrade Guide

Here’s the method where I was previously comparing the flash type to symbols rather than strings:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

def twitterized_type(type)
  # http://ruby.zigzo.com/2011/10/02/flash-messages-twitters-bootstrap-css-framework/
  case type
    when "alert"
      "warning"
    when "error"
      "danger"
    when "notice"
      "info"
    when "success"
      "success"
    else
      type.to_s
  end
end

1. Both save time for running basic commands like rspec, rake, rails, etc. The performance of both is very similar.

1. Both can be extremely confusing when they fail to update automatically. This tends to happen after updating gems or running database migrations. You end up yak shaving when you don’t see your changes taking effect! I.e., put in some print statements, and then you don’t see them shown when they should. Arghhhh!
2. Rspec-retry seems essential in dealing with random Capybabara failures with either Zeus or Spring. I often see less of these errors when I don’t use Zeus/Spring nor parallel_tests.

1. Zeus works with the parallel_tests gem. This more than halves my time for running my entire test suite. However, when writing this article, I found that it made little difference, at least when slowed down by sporadically failing capybara tests that are retried. That being said, I’m certain that Parallel Tests with Zeus is faster or at worse the same as without Zeus.

1. You need to start up separate shell process, running zeus start. An advantage of this is that if there’s a problem starting up, the output in the Zeus console window is fairly clear.
2. You run the command “zeus rake” rather than just “rake”. Consequently, I made some shell aliases (see below).
3. Zeus only uses the environment from when Zeus was started and ignores any environment variables when commands are run.

1. Spring is a default part of Rails, so you know it’s well supported, and bugs will be fixed fast.
2. Slightly simpler to install and use than Zeus.

1. Spring lacks support for parallel_tests. See this Github issue: incompatible with spring #309. You can, however run parallel_tests so long as run the command like this: time DISABLE_SPRING=TRUE parallel_rspec -n 6 spec. I.e., you need to set DISABLE_SPRING so that parallel_rspec does not use Spring.
2. Spring is a bit opaque in terms of errors given there’s no console window. See README for how to see the Spring log.

The right combination of gems seem pretty critical in getting all the parts to play nicely together. As of August 15, 2014 the most recent compatible versions of the following gems worked well together. This means running “bundle update” without locking the gem versions.

capybara-screenshot (0.3.21)
capybara (2.4.1)
guard (2.6.1)
guard-bundler (2.0.0)
guard-livereload (2.3.0)
guard-rails (0.5.3)
guard-resque (0.0.5)
guard-rspec (4.3.1)
guard-unicorn (0.1.1)
parallel_tests (1.0.0)
poltergeist (1.5.1)
rails (4.1.4)
resque_spec (0.16.0)
rspec (3.0.0)
rspec-instafail (0.2.5)
rspec-its (1.0.1)
rspec-mocks (3.0.3)
rspec-rails (3.0.2)
rspec-retry (0.3.0)
vcr (2.9.2)
webmock (1.18.0)
zeus (0.13.3)
zeus-parallel_tests (0.2.4)

• RailsConf 2014 All Photos in one Album
• RailsConf 2014 Speaker Dinner
• RailsConf 2014 Day 1
• RailsConf 2014 Day 2
• RailsConf 2014 Day 2 BaseCamp Party
• RailsConf 2014 Day 3
• RailsConf 2014 Day 3 Public House Party
• RailsConf 2014 Day 4

The same photo albums on my Rails on Maui Facebook Page. Please tag yourself and your friends.

• RailsConf 2014 Day 0, speaker dinner
• RailsConf 2014 Day 1, including after party at the Public House
• RailsConf 2014 Day 2
• RailsConf 2014 Day 2, Basecamp Party
• RailsConf 2014 Day 3
• RailsConf 2014 Day 3, Public House Party
• RailsConf 2014 Day 4

I hope you like the pictures.