Skip to content
View quadrant.rb
class Todo
attr_accessor :title, :description
attr_reader :priority, :urgency
def initialize(priority: 1, urgency: 1)
@priority, @urgency = priority, urgency
raise ArgumentError, "urgency must be between 1 and 10" unless (1..10).cover?(@urgency)
raise ArgumentError, "priority must be between 1 and 10" unless (1..10).cover?(@priority)
def quadrant
View gist:e8ca8fae17eb3324d26d
class Todos
attr_accessor :priority, :urgency, :title, :description
def initialize(priority = 1, urgency = 1)
@priority, @urgency = priority, urgency
raise ArgumentError, "urgency must be between 1 and 10" unless 1..10 === @urgency
raise ArgumentError, "priority must be between 1 and 10" unless 1..10 === @priority
def quadrant
@quadrant ||=
View gist:ef2f8d7732d87d7eb9ed
<core name="catalyst" instanceDir="catalyst" >
<property name="enable.searcher" value="true" />
<property name="enable.master" value="true" />
View gist:a73eb6a8b6289e59d64d
| Debug
Please submit text block below with your ticket to Fastly
View gist:053a54c82a970da6d810
<title>Fastly Debug App</title>
* { box-sizing: border-box; }
body {
font-size: 12px;
font-family: 'Helvetica Neue', helvetica, sans-serif;
View gist:4864c69a33ba605e72da
Class Something
attr_accessor :foo
something =
something.respond_to?(:foo) # => true
something.respond_to?(:foo=) # => true
something.respond_to?(:bar) # => false
View gist:22ee1b97a3cb581f9138
to_field "something" do |record, accumulator|
leader = record.leader
# The only reason you want the leader is becuase you are going to do
# SOMETHING with it, right? You're not just gonna index the leader, are ya?
output = do_something_to(leader)
accumulator << output
View gist:488d4c5e63677038149d

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

View gist:12e3479c63a76d78b8ae
<container xmlns:foo="http://one">
<container xmlns:foo="http://two">
View gist:901138fb10b666918244
^Crake aborted!
/Users/jrochkind/.gem/ruby/1.9.3/gems/activesupport-4.0.4/lib/active_support/core_ext/kernel/agnostics.rb:7:in ``'
/Users/jrochkind/.gem/ruby/1.9.3/gems/activesupport-4.0.4/lib/active_support/core_ext/kernel/agnostics.rb:7:in ``'
/Users/jrochkind/.gem/ruby/1.9.3/bundler/gems/blacklight_marc-3959de95eb3f/lib/railties/solr_marc.rake:37:in `block (4 levels) in <top (required)>'
/Users/jrochkind/.gem/ruby/1.9.3/bundler/gems/blacklight_marc-3959de95eb3f/lib/railties/solr_marc.rake:20:in `block (3 levels) in <top (required)>'
Tasks: TOP => solr:marc:index:work
(See full trace by running task with --trace)
Error running fixtures
D, [2014-08-26T14:48:18.070539 #12386] DEBUG -- : Instance stop method called for pid '12397'
Something went wrong with that request. Please try again.