How to discover what is generating an SQL statement in your Rails log

Just spreading a really cool tip I came across. Ryan Bigg has this blog post showing how you can find out what is creating an SQL statement in your log. I was having a devil of a time figuring out where a particular callback was coming from and discovered his great post. Essentially you hook into ActiveSupport::Notifications and then put in logic in the regex piece to describe the query you are looking for. In this case I did this in development.rb:

  ActiveSupport::Notifications.subscribe('sql.active_record') do |_, _, _, _, details|  
   if details[:sql] =~ /UPDATE "answers" SET position =/  
    puts '*' * 50  
    puts caller.join("\n")  
    puts '*' * 50  
   end  
  end  

And then looked at the call stack to see where it was coming from. I could have output to the logger too. And I would not recommend doing this on Production.

A new gem to help monitor Postgres performance in standalone instances

I just released my own gem for querying Postgres Databases for performance issues. I had used Heroku PG Extras and the Go Boundless New Relic Postgres plugin previously. Each are excellent tools with a lot of overlap. The holes for each-- hosting on Heroku needed for PG Extras and the lack of visibility into the queries themselves on New Relic-- pushed me to write this gem. My aim is to build an engine on it that will display the stats in screens that can be plugged into an application. We'll see how that goes.

Using Puma on Heroku instead of Unicorn

A few years back I wrote about using Unicorn on Heroku along with Unicorn Worker Killer. Oyr need was to increase the number of web requests an app could handle on Heroku. Puma tested faster at the time but did not offer worker processes. You have to use threads and for an app that was never intended to be threaded running on Ruby MRI it was too much work to adjust. Puma has since added the concept of Worker Processes and, given the performance advantages found with Puma it made sense to install it. Still, I was used to some variability with Unicorn and wanted to replicate some of the same things. This article from Heroku offered most of the help I needed though I did reduce the default thread count from 5 to 1. Additionally the section on the use of the Rack Timeout gem was helpful though I wound up doing this so that I could adjust the timeout via environment variable:

 Rack::Timeout.timeout = 20 # seconds  

What I did not find was helpful instructions on queue length. Puma defaults to 1024 and the previously mentioned article from Heroku cautions strongly against altering that queue length. Still, from previous performance testing on Heroku sometimes a shorter queue length is warranted (DO YOUR OWN TESTING!). This blog post originally suggested altering the queue length but again he cautions against it on Heroku. If you find that a shorter queue length helps then it is a setting in the config/puma.rb file:

 backlog = Integer(ENV['PUMA_BACKLOG'] || 20)  
 bind "tcp://0.0.0.0:#{port}?backlog=#{backlog}"   

Good luck and Heroku on

Getting PhantomJS to work with Stripe following the POODLE issue

Recently with the POODLE issue we ran into a case where our PhantomJS tests would not run on Codeship. After some swearing and digging we found that PhantomJS defaulted to using 'SSLv3' and Stripe no longer supported that. Therefore when our feature tests went to access Stripe they failed. To get around this we had to change the default for PhantomJS in our spec_helper.rb file. This is done by the phantom_options array in the options hash:

   Capybara.register_driver :poltergeist do |app|  
    options = {  
     phantomjs_logger: WarningSuppressor.new,  
     phantomjs_options: ['--ssl-protocol=tlsv1']  
    }  
    Capybara::Poltergeist::Driver.new(app, options)  
   end  

So if you need to use that, or any of the other PhantomJS command line options listed here, you can do that in the phantomjs_options array.

Installing Cassandra on Digital Ocean

Recently I had a chance to install cassandra on a three node cluster out on Digital Ocean. Here are my steps in a handy markdown gist. YMMV

Testing a Rails/Ember app with Teaspoon & QUnit and watching the tests run

Recently I have had to start working with an Ember application. It is certainly a challenge. For Unit testing we decided to look at QUnit for our front end pieces. Being used to:

save_and_open_page

and looking at tests running visually I was a bit stymied until I realized you could use the `-d` flag to override the phantom.js we set up in the config. So:

teaspoon -d selenium

will run the tests with Firefox & Selenium (normal version issues apply)

Using table_for with HTML elements in Active Admin

Ah yes another foray into ActiveAdmin. Recently I needed to use the table_for feature on a show page and add some html options to it. This required looking into the code itself as the documentation was not exactly clear in either ActiveAdmin or Arbre. Essentially you need to do something like this:

    table_for agent.quotes, {:id => 'agent_quotes'} do
      column 'Quote Number' do |quote|
        quote.slug
      end
      column 'Business' do |quote|
        quote.business.name
      end
      column 'Status' do |quote|
        quote.state
      end
      column '' do |quote|
        link_to 'View Quote', admin_quote_path(quote.id)
      end
    end

It was as simple as adding a hash with the needed items after the collection for the table_for:

table_for collection, {:id => 'html_id', :class => 'html_class'}