jrochkind

{
	"@context": "http://iiif.io/api/presentation/2/context.json",
	"@id": "http://173e44ba-166b-4db0-82a4-da0686ec63dc",
	"@type": "sc:Manifest",
	"label": "[Click to edit label]",
	"metadata": [],
	"description": [
		{
			"@value": "[Click to edit description]",
			"@language": "en"

jrochkind

namespace :invoke do

  #     cap <stage> invoke:rake TASK=chf:data_fix:something[,other:task]
  desc "Execute a rake task on a remote server"
  task :rake do
    if ENV['TASK']
      tasks = ENV['TASK'].split(',')

      on roles(:app) do
        within current_path do

jrochkind

#!/usr/bin/env ruby

# Call the file just `gem-visit`, not `gem-visit.rb`, and put it in your path
# (maybe you want ~/bin in your $PATH), to be able to do:
#
# .   gem-visit name_of_gem
#
# And have a browser window opened pointing to the (preferable, if it can) github
# homepage of the gem, or other gem project page (last resort). 

jrochkind

VCR.configure do |c|
  c.cassette_library_dir = 'spec/vcr_cassettes'
  c.hook_into :webmock # or :fakeweb
  c.configure_rspec_metadata!


  # Let's you set default VCR mode with VCR=all for re-recording
  # episodes. :once is VCR default
  record_mode = ENV["VCR"] ? ENV["VCR"].to_sym : :once
  c.default_cassette_options = { :record => record_mode }

jrochkind

threads Integer(ENV['PUMA_MIN_THREADS']  || 16), Integer(ENV['PUMA_MAX_THREADS'] || 16)

preload_app!

port        ENV['PORT']     || 3000
environment ENV['RACK_ENV'] || 'development'

workers Integer(ENV['PUMA_WORKERS'] || 3)

before_fork do

jrochkind

Thread Pools

A Thread Pool is an abstraction that you can give a unit of work to, and the work will be executed by one of possibly several threads in the pool. One motivation for using thread pools is the overhead of creating and destroying threads. Creating a pool of reusable worker threads then repeatedly re-using threads from the pool can have huge performace benefits for a long-running application like a service.

concurrent-ruby also offers some higher level abstractions than thread pools. For many problems, you will be better served by using one of these -- if you are thinking of using a thread pool, we especially recommend you look at and understand Futures before deciding to use thread pools directly instead. Futures are implemented using thread pools, but offer a higher level abstraction.

But there are some problems for which directly using a thread pool is an appropriate solution. Or, you may wish to make your own thread pool to run Futures on, to be separate or have different characterist

jrochkind

# an action method in a Rails controller, Rails5
def show
  futures = 2.times.collect do |n|
    Concurrent::Future.execute do
      # NEED to wrap here, in case _any_ autoloading is going to happen,
      # need to tell Rails so it can be done thread-safely. Or else we might
      # get a deadlock. 
      Rails.application.executor.wrap do
        SomeExpensiveNetworkOrIoWorker.new(n).call
      end

jrochkind

# NOT OKAY for Rails5, WILL deadlock if dev-mode class-reloading

# an action method in a Rails controller
def show
  futures = 2.times.collect do |n|
    Concurrent::Future.execute do
      SomeExpensiveNetworkOrIoWorker.new(n).call
    end
  end
  

jrochkind

require 'spec_helper'
require 'carmen'

# Really more of a set of integration tests, we're proving that tax is actually
# calculated how we want on an order
describe ByZipTaxCalculator do
  let!(:taxable_category) { create(:tax_category, name: "Sales and Use Tax", is_default: true) }
  let!(:non_taxable_category) { create(:tax_category, name: "Non Taxable") }

  before do

jrochkind

def my_method
  yield
  "method"
end

my_method { return 'block' }

# => raises `LocalJumpError: unexpected return`