Thursday, April 23, 2015

How to Link a Git Folder with an Existing Heroku App


  1. Follow this guide to get Heroku setup on your command line tool of choice.
  2. heroku git:remote -a project_name

where project name is the name of your Heroku app (if your app's URL is stellablog.herokuapp.com, project_name would be stellablog) and you're done! Your local Git folder will be linked with your Heroku app, and you can deploy your latest code to it.

Monday, April 20, 2015

How to Push a Local Branch to a Separate Remote Branch

This is my first post about Git! I'll be talking about how to push the contents of a local branch to a remote branch that is different from what it currently points to. The base syntax is

git push remote local_branch:remote_branch

An example of when to use this is in combination with Heroku. You might want to push your local branch to Heroku's master branch:

git push heroku foo_branch:master

That is also how you make Heroku run a non-master git branch.

Maybe you want to push the contents of your current branch to another branch on git:

git push origin foo_branch:bar_branch

Thursday, April 16, 2015

How to use respond_to? with private methods

respond_to? is an awesome method for testing if an object has a given method. By default, it will return false for methods that are private. If you want to test if an object has a method regardless of its private status, you can just pass true after the method name:

respond_to?(:foo, true)

Monday, April 13, 2015

How to Load Dependencies in a Rails Engine

In a Rails project, generally all you have to do is add a gem to your Gemfile and the dependencies will automagically get taken care of. Unfortunately, for Rails Engines this is not the case. You will have to take the additional step of requiring the gem's library file.

# engine.gemspec s.add_dependency 'jquery-rails' s.add_dependency 'your-foo-gem' # lib/your_engine/engine.rb
require 'jquery-rails'
require 'your-foo-gem'


This is related to the problem of needing to require modules from gems to get them to load properly.

Thursday, April 9, 2015

How to specify a local gem in your Gemfile

If you're developing a gem and you want to test it out locally in another project, this is easily accomplished by specifying the path to the local gem in your Gemfile:

gem 'bears', path: '/path/to/bears/gem'

and boom, it's there. One bundle install later and you'll be good to go.

Monday, April 6, 2015

Removing extra whitespace from Haml

Most of the time, Haml is pretty awesome. One of the cases where it's not so awesome is around multiline mixed Ruby/HTML. For example, when trying to create a timer on the screen:

Because of reasons, Haml decides to add extra whitespace around each of the span tags. Sometimes this is desirable, but sometimes you want to remove the whitespace/extra space around Haml tags. As usual, there is a quick fix, in this case the '>' character:

Thursday, April 2, 2015

Capybara::Poltergeist::TimeoutError

Timed out waiting for response to {"name":"visit","args":["http://127.0.0.1:54242/"]}. 
It's possible that this happened because something
took a very long time (for example a page load was slow). 
If so, setting the Poltergeist :timeout
 option to a higher value will help (see the docs for details). If increasing the timeout does not help, this is probably a bug in Poltergeist - please report it to the issue tracker. (Capybara::Poltergeist::TimeoutError)
While working with Capybara feature specs and Poltergeist, you may have encountered this error before. You also probably tried bumping up the timeout value to no avail. I found a surprisingly easy fix for this issue - update your Poltergeist gem and update PhantomJS to version 2.0! After I did these two things, most of these errors went away.

If you are still having issues after that, read through this issue and see if a solution there helps.

Thursday, March 26, 2015

Using local assets with save_and_open_page

Previously I talked about how to use save_and_open_page with Cucumber. Unfortunately, when you do this it renders an unstyled page. If you add

Capybara.asset_host = 'http://localhost:3000'

to your spec_helper.rb or Capybara config file, save_and_open_page will use your local server's assets - making it much easier to diagnose issues.

Monday, March 23, 2015

undefined method `capture_haml' for RSpec

If you're using Haml in a Rails project, testing with RSpec, you might encounter the "undefined method 'capture_haml' for ..." error while trying to run your specs. I encountered this error in a view spec when trying to use Simple Form along with Haml. Fortunately, like many other obscure bugs there is a quick and dirty solution: The init_haml_helpers section is necessary to prevent other errors from happening.

Note that all lines are required. If you drop the init_haml_helpers line, you'll get the following error:
ActionView::Template::Error: undefined method `capture_position=' for nil:NilClass
and of course if you don't have any of this, you will get:
ActionView::Template::Error: undefined method `capture_haml' for #<RSpec::ExampleGroups::...

Thursday, March 19, 2015

Using save_and_open_page with Cucumber

Capybara has a nice utility method called save_and_open_page that will save the current page's HTML as a temp file and open it in your browser. This method is available by default in Ruby code (for example in an RSpec feature spec). As Cucumber is not direct Ruby, you can't directly say that. Fortunately, you can say

 Then show me the page  

and you'll get the same effect.

Wednesday, March 18, 2015

How to Validate Regular Expressions in Ruby on Rails Models

ActiveRecord has many awesome validators for common things like presence, numericality, etc. Unfortunately, it is missing one common format - regex, or regular expressions. These are normally saved as string fields and, if not validated, can lead to page errors when your app tries to use a field that contains an invalid regular expression. This is especially the case if you allow the user to input a regular expression. With the addition of one small validation class, you will be able to prevent these sorts of bugs with your models.

The above code adds a validator called RegularExpressionValidator to app/validators/regular_expression_validator.rb. It then adds the validation to the Bear model on the field my_regex_field. With this, if you try and create a Bear with an invalid regular expression, an error will be thrown and the save will not complete.

Monday, March 16, 2015

undefined method `fa_icon` for #<#Class:...

If you're trying to use the Font-Awesome gem in your Rails engine, you may run into this "undefined method `fa_icon for #<#Class:.." error. Fortunately, there is a pretty simple fix.

Add

 include FontAwesome::Rails::IconHelper  

to

 engine_name/app/helpers/engine_name/application_helper.rb  

and the error should go away.

Thanks to Github for the solution.

Thursday, March 12, 2015

How to Kill an "open" Rails Server

If you've force-closed your Rails server instance for whatever reason (like a bug that froze up the server), you might run into issues when you try and restart it. For example, you might get the error "WARN TCPServer Error: Address already in use - bind(2) Exiting" What do you do?

Assuming that you're running on port 3000, find the PID of the process with

lsof -wni tcp:3000

and kill the process with

kill -9 PID

Monday, March 9, 2015

Testing with a Dummy Controller in a Rails Engine

If you have a controller in your dummy app (spec/dummy/app/controllers/dummy_controller.rb) for your Rails engine, you might need to access the list of routes within your spec code. You can do this, surprisingly, with Rails.application.routes.routes!

Thursday, March 5, 2015

Using Bundler in a Rake Task

If you want to use Bundler in a rake task to automate something like bundle install, you can't simply call bundle install in a system call. Fortunately, Bundler provides a method called Bundler.with_clean_env. Using that, you can do something like
 require 'bundler'  
 Bundler.with_clean_env  
  system 'bundle install'  
 end  
to run your task.

Monday, March 2, 2015

AssetFilteredError: Assets filtered out and will not be served

If you've decided to use the Teaspoon gem for running your JS tests, you may have encountered this error when trying to navigate to your test suite:
 Error: Sprockets::Rails::Helper::AssetFilteredError: Asset filtered out and will not be served:   
 add `Rails.application.config.assets.precompile += %w( teaspoon.css )` to `config/initializers/assets.rb` and restart your server  
Unfortunately, this is an issue with Teaspoon and newer (>4.0) versions of Rails. For some reason, the asset paths for Teaspoon are no longer included in the list of assets that are automatically precompiled. Therefore, you must add them to your config/initializers/assets.rb file like so:
 unless Rails.env.production?  
  Rails.application.config.assets.precompile += %w(  
   teaspoon.css  
   teaspoon-teaspoon.js  
   teaspoon-mocha.js  
   # other assets  
  )  
Note: I added a surrounding check for production. Since Teaspoon is a testing gem, you shouldn't be using it in production, nor should you need its assets. If you have assets in this file that you need for production, you can separately add them with another addition to Rails.application.config.assets.precompile.

Friday, February 27, 2015

Stubbing Global Methods in JS Specs with Sinon

In your Rails app, your JS should be tested too! Setting that up is a topic for another post. When testing your JS, a lot of the same philosophies apply. One of those is mocking methods other than the one you're testing. How do you do this for methods in other libraries, such as vanilla JS or jQuery?

Vanilla JS (the confirm method):
 sinon.stub(window, 'confirm')  
jQuery (the fadeOut method):
 sinon.stub(jQuery.prototype, 'fadeOut')  

Monday, February 23, 2015

Cleaning out server assets in development

Depending on your server settings (config/environments/development.rb), some of your assets (css, js, images, etc.) may end up being cached by the server and won't reflect your changes. Fortunately, there is a command to clear all of these out so they will be regenerated. With the server shut down, run rake assets:clobber and all of your asset caches will be removed. The next time you run the server and navigate to your app, the assets will be regenerated with the current version of the files.

Thursday, February 19, 2015

Using self.included to Include Dependencies

As part of a project I'm working on, I created a mountable engine for extracting all authentication concerns for the app. I created a TestHelper module that includes methods for mocking various aspects required for authentication. These methods require Devise::TestHelpers to function properly, and my goal was for the calling app to not know or care about this dependency. To solve this, I used self.included to automatically include the helper when necessary (in my case, only in controller specs).
Here is the code:

 def self.included(receiver)  
  if defined?(receiver.metadata) && receiver.metadata[:type] == :controller  
   receiver.send :include, Devise::TestHelpers  
  end  
 end  

Sunday, February 15, 2015

Testing Multiple Attributes of an Input Field

Sometimes in a view or feature spec, you want to test multiple attributes of an input field (or some other field). For example, you might want to test that the input field is a checkbox and is checked, as well as testing that the field has the id #rawr. This is how you would do that in a view spec (feature spec is similar):

 expect(content).to have_css("input[type='checkbox'][checked='checked']#rawr")  

Monday, February 2, 2015

Updating a Rails Model with a Non-default Primary Key

In my last post, I talked about creating a Rails model with a non-default primary key. You can create new instances of the model with no problem, but what happens when you want to update an instance of the model?
 TypeError: nil is not a symbol nor a string  
Oh no!!!!

Fortunately, there is an easy fix. You just have to specify the column name of the primary key from within the model.
 class BearHabitat < ActiveRecord::Base  
   self.primary_key = 'bear_id'  
 end  
Now you should be able to update your model within your code with no problem. Why does this happen in the first place? My guess is that somewhere within ActiveModel, it assumes that the primary_key field is set. Since your migration set id to false, this value gets defaulted to nil. If you don't manually set it, ActiveModel gets sad. Now you can make ActiveModel happy again.

Saturday, January 31, 2015

Creating a Rails Model with a Non-default Primary Key

One of the main Rails philosophies is "convention over configuration". This works great most of the time, but sometimes it's best to do something outside of convention. One example is the primary key for models. Sometimes you want the key to be something other than ID; maybe you want it to be the ID of a related model.

This is possible to set up in a migration, you just need to do a few important things:
  • Set id: false on the create_table line
  • Set your new primary key to null: false
  • Add a unique index on your new primary key
Here is an example:

 class CreateBearHabitats < ActiveRecord::Migration  
   def change  
     create_table :bear_habitats, id: false do |t|  // prevents a default ID column from being created
       t.belongs_to :bear, null: false //creates a bear_id column that can not be null
       t.string :habitat  
     end  

     add_index :bear_habitats, :bear_id, unique: true // ensures that the bear_id column is unique
   end  
 end  
This BearHabitat model will now use bear_id as a primary key instead of the standard id.

Monday, January 26, 2015

Testing Controllers in Rails Engines

Testing your controllers in a Rails engine requires just a few extra steps compared to testing in a Rails application.

For example, you're working on an engine called Animals, and you have a BearsController with an index action that returns all the bears you've registered.

With a controller like this:
 // app/controllers/animals/bears_controller.rb  
 module Animals  
   class BearsController < ApplicationController  
     def index  
       // return all bears  
     end  
   end  
 end  
and a routes file like this:
 // config/routes.rb  
 Animals::Engine.routes.draw do  
   get '/index' => 'bears#index'  
 end  
you will need to update your dummy routes file to look like this:
 // spec/dummy/config/routes.rb  
 Rails.application.routes.draw do  
   mount Animals::Engine => "/animals"  
 end  
and in your controller spec you will need to add one extra line compared to normal:
 // spec/controllers/animals/bears_controller_spec.rb  
 RSpec.describe BearsController do  
   // this is the key line!  
   routes { Animals::Engine.routes }
  
   describe 'GET :index' do  
     it 'does the thing' do  
       get :index
       // test that all bears are returned  
     end  
   end  
 end  
and now your controller test will go to the appropriate routes :)

Monday, January 19, 2015

Testing Loaded Devise Modules In Your Models

So you're using Devise or devise_token_auth for user authentication in your Rails project. Awesome! Both are great libraries for authentication. Now, how are you testing your code? You probably have feature tests to ensure tasks like creating a new user work (and if you don't, stop reading this right now and make them!). You might even have controller tests to ensure, for example, that each action authenticates the user before proceeding.

What about your models? They are important too, and fortunately these libraries handle most of the model work in the background for you. There are still things you can test though! The main thing that come to mind are ensuring that you only load the devise modules that you want. For devise_token_auth, you also want to ensure you load the model concern.

Devise Modules

Let's say that you're only using the Database Authenticateable and Registerable modules. With Devise, your model might look something like this:

 class User < ActiveRecord::Base  
    devise :database_authenticatable, :registerable  
 end  

Devise provides a method called devise_modules that returns an array of symbols representing the modules that you include. With this, you can easily test that you're using only these two modules by doing this:

 // spec/models/user_spec.rb  
 // using RSpec and FactoryGirl for testing  
 RSpec.describe User do  
    it 'has the right devise modules loaded' do  
       user = FactoryGirl.build(:user)  
       expect(user.devise_modules).to eq([:database_authenticatable, :registerable])  
    end  
 end 

What if there was a business requirement that Omniauth was not available? Well, you can test that easily too:

 it 'does not load the Omniauth module' do  
   user = FactoryGirl.build(:user)  
   expect(user.devise_modules.include?(:omniauthable)).to be_falsey  
 end  

DeviseTokenAuth concern

With devise_token_auth, you also include a concern to add extra methods to User that are used internally. How can you test this? Easily!

 it 'loads the DeviseTokenAuth concern' do  
   expect(User.ancestors.include?(DeviseTokenAuth::Concerns::User)).to be_truthy  
 end  

Summary

With these tests, you can be sure that your model includes everything from Devise that you're expecting it too. This is great insurance for when you decide to refactor your model 6 months from now. It makes your assumptions clear, ensures that any changes are explicit, and allows you to test your user model is using Devise without having to run your expensive feature specs.

Friday, January 16, 2015

Rake Database Tasks Outside Rails

My first content post is, ironically, not directly about Rails. It is about using a very common Rails feature - rake database tasks - in a Ruby project that utilizes ActiveRecord but not Rails.

By default, tasks like rake db:migrate are available in Rails but not in a Ruby project that includes ActiveRecord. Fortunately, with a couple of lines added to your Rakefile this issue can be fixed.
 // Rakefile
 DatabaseTasks.env = ENV['YOUR_ENV_VAR'] || 'development'  
 DatabaseTasks.db_dir = 'db'  
 DatabaseTasks.database_configuration = YAML.load_file('config/database.yml')  
 DatabaseTasks.migrations_paths = "#{DatabaseTasks.db_dir}/migrate"  
 task :environment do  
  ActiveRecord::Base.configurations = DatabaseTasks.database_configuration  
  ActiveRecord::Base.establish_connection DatabaseTasks.env.to_sym  
 end  
 load 'active_record/railties/databases.rake'  
And voila. Now, you can use create, migrate, and all of the other rake db tasks you're used to in a Rails project.

Sunday, January 4, 2015

Hello World!

As I have been learning Ruby on Rails the past several months, I have searched the Internet a multitude of times when trying to solve an issue. Sometimes I have found the solution (thanks Stack Overflow), but other times I have had to figure things out on my own, especially when dealing with RSpec. I will be posting the problems I encounter here and how I solved them. I hope you find them useful!