It's my understanding that with cursor pagination, there are two types of cursor pagination that differ depending on what the cursor represents:

1. cursor represents a single point in the dataset
2. cursor represents a contiguous batch of the dataset

In this type, the cursor points to a specific point (maybe a record) in a dataset. This is the type used by Facebook and the response looks like this:

{

TLDR: keyword arguments only with with symbol-keyed hashes but DON'T symbolize keys on params unless you know what you're doing.

Ruby's keyword arguments only work with Hash objects where all of the keys are symbols.

They do not with:

• ActionController::Parameters
• ActiveSupport::HashWithIndifferentAccess

So here is what I've come up with for the JobSearcher.

Brian suggested that breaking this out into another controller which is what I started doing. I haven't looked too much into what the convention here is, so this is just a spike.

I applied what I learned from looking at the Sunspot source to make the searcher.

The main property that we seem to organize Jobs into is by state. From there, an aspect can be called, returning a Sunspot object. I'm aware that some of this will become the responsibility of Tasks, but what I learned from looking at the Sunspot source can be applied to that as well.

This summarizes the things I learned about Sunspot searching while looking throught the source. I included links to specific parts of the source-code. Be sure to check that out if you are curious.

This Job model will be what the examples below are searching.

class Job < ActiveRecord::Base
  searchable do
    boolean :requires_expertise
    integer :state
 time :deadline_at

I like that this adds a little color to and otherwise dull looking terminal window. From left to right, I'll describe what it includes:

• a fun little alien
• username
• current directory
• Ruby version (via rbenv... you'll have to change this if you use rvm)
• Hearts that deplete throughout the day