DEV Community: Robert Hustead

How to use a non-mac mouse to move between spaces and open Mission Control on MacOS

Robert Hustead — Wed, 22 Oct 2025 03:57:01 +0000

TL;DR Just follow these steps, full explanation will follow.

1) Download and install "MacGesture" using homebrew with
brew install --cask macgesture

2) In "Preferences", navigate to the AppleScript tab.

3) Click the "+" button to create 3 new AppleScripts, giving them the following names and scripts:
a) Navigate Left: tell application "System Events" to key code 123 using control down
b) Navigate Right: tell application "System Events" to key code 124 using control down
c) Open Mission Control: tell application "System Events" to key code 126 using control down

4) Navigate to the "Gestures" tab, and delete any gestures that might exist. Add 3 new Gestures, selecting "Add a AppleScript Rule" when prompted by clicking the "+" button.

5) Give these new Gestures the following properties. Yes, I really do mean give Gesture Left the Navigate Right action, etc.
a) Gesture: L, Filter *, Action: Navigate Right, Note: [Whatever you want, not necessary], Lightening Bolt: [Unchecked]
b) Gesture: R, Filter *, Action: Navigate Left, Note: [Whatever you want, not necessary], Lightening Bolt: [Unchecked]
c) Gesture: U, Filter *, Action: Open Mission Control, Note: [Whatever you want, not necessary], Lightening Bolt: [Unchecked]

6) Adjust any other General settings you want.

Finished. You can now hold down the right mouse button, flick the mouse to the left, and it will slide your current Screen to the right. Same with the opposite. Holding right mouse button and flicking up will open Mission Control. Have fun!

Fuller Explanation that I expect no one to read

I have a Mac I use for work, and while I love all the 'gestures' you can do with the track pad, mine recently blew up and I needed to go back to my boring windows style mouse. However, I really like being able to scroll between different Desktops (called Spaces I guess?). I want to keep that functionality, but I wanted to be able to do it with my mouse and not a track pad.

I found the app mentioned above, and I tried making a custom gesture to be able to hold down the right mouse button, and flick the screen to the left or right. I knew you could hold down CONTROL and press RIGHT or LEFT on the keyboard and it would switch Spaces, so I wanted to do the same but have my mouse's right button be CONTROL, and then it's movement be the LEFT or RIGHT. My problem was, whenever I tried to key in the macro for MacGesture, it wouldn't register CONTROL as part of the macro.

AppleScript to the rescue! Now, I set the custom macro to be a LEFT or RIGHT (or UP) movement while also holding down the CONTROL key, and I map them to basic Gesture "L" for left and "R" for right, setting them to run during any and all applications (the "*" in Filter)

This took me longer than I want to admit to figure out, and every other explanation I found online has huge wordy explanations or a long Youtube video that no one wants to watch. So hopefully this quick tutorial helps you out and you can get back to coding. Good luck!

What to do when "Service page is currently unavailable." on AWS Console

Robert Hustead — Thu, 02 Jan 2020 01:03:02 +0000

tl;dr

Take a chill pill and wait for a few minutes(hours). It's likely just a bug on Amazon's end. I'm writing this because I couldn't find any other mention of this page when I googled.

Explanation

While going through this tutorial to create a serverless stack architecture on AWS, I was required to create a Federated Identity through Cognito using the AWS Console GUI on us-east-1.

Having created the Federated Identity, I attempted to access it's Dashboard through the AWS Console but was greeted by a strange error.

When it comes to AWS services not working as intended, 99% of the time it's a User error problem, but this error message was a bit different than normal. I had a Federated Identify on another account on another Region, and I was able to access that one just fine. Something seemed wrong with us-east-1.

I tried changing regions, and then going back to us-east-1 and accessing the Federated Identity Dashboard, and sometimes I was able to access it. But whenever I tried to edit settings, it would kick me back to the above 500 error page.

I tried googling for this specific error, but I couldn't find either 1) a fix or 2) any mention of this specific error page.

It turned out that it just took some time (about an hour for me), but then I was able to access the page as normal. However, diagnosing problems on AWS can be hugely difficult for those like me who are not well versed in it, and that difficulty is compounded when the problem isn't even on your end. So, I felt I should leave some sort of record for the next poor engineer who goes searching for this specific error.

(Of course, this is assuming you DIDN'T have any issues with the settings/code you have written. As always, you should do a sanity check of your services and settings.)

Good luck, and happy coding!

How to use Global Navigation Guards with Nuxt Middleware, and why you absolutely should NOT

Robert Hustead — Fri, 09 Aug 2019 10:40:26 +0000

TLDR:

It's possible to use Global Navigation Guards with Nuxt by using Middleware
In the Middleware, you have access to the context, by which you can directly access the Vue Router.
By adding a Global Navigation Guard, that code will run every time your router is used, leading to unintended consequences
Instead, use in-component Navigation Guards within your pages

I'm still very new to Vue and Nuxt, but as we are using it at my job I'm trying to pick it up as I go. We are building a task management system similar to Pivotal Tracker or Trello. We have Lists, and within these Lists we have Tasks, and one Task showing its TaskDetails. By clicking on the Tasks in the List you can change which TaskDetail is shown. I was faced with what I initially thought was an easy task.

TASK: When a user is editing a text box within the TaskDetail, ensure the user does not accidently navigate away from the page (and losing their edit) by adding a confirm popup.

Enter Navigation Guards (Navigation Guards | Vue Router) , which are "primarily used to guard navigations either by redirecting it or canceling it." By using a Global Navigation Guard, I could ensure that anytime the Vue Router changes the route (when someone clicks on a different Task), I could check if they are editing a text box and then use a confirm popup.

Something like this:

const router = new VueRouter({ ... })

router.beforeEach((to, from, next) => {
  if(confirm("Are you sure?")) {
    next()
  } else {
    next(false)
  }
})

Problem: We are using Nuxt, which sets up the Vue-router automatically based on your file structure. But there must be a way to use a Global Navigation Guard with Nuxt, right?

I googled, and all I could find addressing this was one lone Stack Overflow question, which had no answer but at least a useful comment about how middleware was designed for exactly that.

What is middleware in Nuxt?

"Middleware lets you define custom functions that can be run before rendering either a page or a group of pages." (Routing - Nuxt.js) Also importantly, the Middleware has access to the Context (API: The Context - Nuxt.js), which has access to the store, which has access to the Vue Router!

So my idea is now simple: create a middleware that accesses the router directly, add a Global Navigation Guard so that whenever the router changes pages it confirms with the user if they really want to move. Let's do it!

For my middleware I created this basic file

in check-before-move.js

export default function ({ store }) {
  store.app.router.beforeEach((to, from, next) => {
    if(confirm("Are you sure?")) {
      next()
    } else {
      next(false)
    }
  })
}

Then added that to the config for nuxt

in nuxt.config.js

  router: {
    middleware: "check-before-move"
  }

This lead to a sticky little problem. Can you spot it? If my middleware really does run every time the router runs, what is going to happen?

That's right, every time the router runs I'm adding ANOTHER Global Navigation Guard. My user has to confirm once, then twice, then three times..etc every time they navigate to different Tasks. Remember, that middleware file is running from start to finish every time the router moves. And each time that middleware file runs, we are doing another beforeEach. It's obvious looking at it now, but it took me a long time to figure out at the time!

So my dumb brain said, "Oh ok I just need to add a check to see if I've set it up already", and I immediately changed my code to:

in check-before-move.js

export default function ({ store }) {
  let setup = false
  if(!setup) {
    store.app.router.beforeEach((to, from, next) => {
      setup = true
      if(confirm("Are you sure?")) {
        next()
      } else {
        next(false)
      }
    })
  }
}

That, as you can imagine, also did not work (read above where I said the code runs from start to finish every time and you'll see why my master plan failed)

So as we can see, YES you can add a Global Navigation Guard in Nuxt by using Middleware, but NO you should not do it(or at least be very sure about what you're doing before implementing it).

Afterword

For anyone else who may be trying to figure out how to implement the same feature in their own project and is suffering like I did, I'll tell you how I managed to implement a solution. Instead of going global, I introduced an In-component Guard. Be careful though, those In-component Guards only work on PAGES, not components (even though Pages are Components but Nuxt has opinions on these matters), so look into In-component Guards here (Navigation Guards | Vue Router)

Good luck, and happy coding!

(Note: I am new to Vue/Nuxt as I stated before, so if you spot any mistakes, feel free to point them out!)

Loading and Authorizing ActsAsTaggable tags using the Cancan authorization library

Robert Hustead — Sat, 27 Oct 2018 12:56:05 +0000

tl;dr (Too long, didn’t read)

class SomeController < ApplicationController
  load_and_authorize_resource class: ActsAsTaggableOn::Tag

  def index; end  #@tags is available in this action
  def show; end #@tag is available in this action
end

Explanation:

The Cancan library is very useful for controlling resources and what users are allowed to read, write, modify, or change them. Normally, when load_and_authorize_resource is included into a RESTful style Controller, it uses a before filter to load an instance variable into memory. However, things can get difficult if you want to load a resource from another class or if the model you wish to use is namespaced differently from the controller.

If you’re using ActsAsTaggableOn to add tags to some models in your app, you can still load those tags as a resource using the code above. From the Cancan documentation on github (https://github.com/ryanb/cancan/wiki/authorizing-controller-actions#custom-class)
“If the model class is namespaced differently than the controller you will need to specify the :class option.”

Remember to set your user abilities for accessing Tags in your abilities files when using Cancan!

Good luck, and happy coding!

How to stop API calls in RSpec and Return your Own Data

Robert Hustead — Sat, 27 Oct 2018 12:53:03 +0000

tl;dr You can explicitly return whatever data you want from external API requests using Webmock and stubbing requests.

How do you test a Controller that makes an API request to another website, but you want to control what exactly is returned? For example, you want to test a Controller that queries Twitter for tweets, but you don’t want to be at the mercy of whatever tweets are being created that second because you want to test how well you can scrape certain keywords.

That’s where Webmock comes in. https://github.com/bblimke/webmock

By adding the code below to your spec_helper or rails_helper file, you can stub external API requests and control the data that is returned to your controllers.

config.before(:each) do
 stub_request(:get, /some.website.api/).
 with(headers: {‘Accept’: ‘*/*’, ‘User-Agent’: ‘Ruby’ }).
 to_return(status: 200, body:’{“test”: 0}’, headers: {})
end

Lets go through each line:

config.before(:each) do This tells RSpec to run the following code before each spec.

stub_request(:get, /some.website.api/). This is the first part of the stub_request method we get from Webmock. It specifies the type of request (:get -> GET), but you can also use any other RESTful request, including the symbol :any to stub any request that comes in. The second part is the URI. You can use reqex as used above, or strings such as "www.example.com". Basically, this stub_request is now waiting for a GET request to be made to a URI that matches the reqex /some.website.api/

with(header: {'Accept': '*/*', 'User-Agent': 'Ruby' }). In the second part, you can explicitly set the header information you want to match. If in your code you make a GET request to /some.website.api/, but the ‘User-Agent’ is something other than ‘Ruby’, then this stub_request will not be invoked.

to_return(status: 200, body: '{"test": 0}', headers: {}) Finally we reach the line that specifies what response we want when our code calls the API at /some.website.api/. In particular, we can set the status code (Here is 200 which means OK). The body, unsurprisingly, is the data returned to us. In can be one of the following types: [Proc, IO, Pathname, String, Array] . You can also explicitly set the headers of the response.

To Summarize: By using the Webmock gem and the code above in your RSpec helper file, you can stop API requests made by your code and return whatever data you would like.

More info here: https://robots.thoughtbot.com/how-to-stub-external-services-in-tests
Webmock Gem: https://github.com/bblimke/webmock

Happy coding!

Avoid Ransack's N+1 Pitfall!

Robert Hustead — Wed, 17 Oct 2018 10:40:00 +0000

I've written about Ransack before, because it's a handy, little gem for searching quickly through both models and their relationships. But you may be surprised to know it's deceptively easy to create N+1 queries using Ransack! The good news is, it's just as easy to fix.

To review basic Ransack use, let's say you have a model Service, which has properties for name and description. If you wanted to search both of those properties, you'd set up your view with something like this:

<%= search_form_for @q do |f| %>
  <%= f.label :name_cont %>
  <%= f.search_field :name_description_cont %>
<% end %>

And your controller would be:

def index
  @q = Service.ransack(params[:q])
  @services = @q.result(distinct: true)
end

Pretty basic stuff, right? But what if you have another model associated with Services? For example, let's say you have a Provider model with name and address properties, and each Provider has_many Services.

Now, you want to search the name and description properties for Service, but you also want to include the Providers name property as well. How do you do that?

Ransack provides an easy approach. You can change your view to:

<%= search_form_for @q do |f| %>
  <%= f.label :name_cont %>
  <%= f.search_field :name_description_provider_name_cont %>
<% end %>

Things are working smoothly. But hold on, let's look at the SQL query that runs when we try to search for something:

Yikes! That's not what we want at all!

Those familiar with rails will know the dreaded N+1 Problem, but will also likely know we can usually solve it with eager loading and using includes(:model_name) . But where do we put it? Easy, in the Controller of course!

def index
  @q = Service.includes(:provider).ransack(params[:q])
  @services = @q.result(distinct: true)
end

Running our search again:

(Please note that in my examples, I also have Sub Categories loading for another part of my view)

This isn't a difficult problem to solve, but many may not be aware that using Ransack with associated models can end up creating this N+1 problems.

Good luck, and happy coding!

Adding Models to an already large Codebase without using scaffold.

Robert Hustead — Thu, 27 Sep 2018 08:45:49 +0000

tl;dr
Follow this Order:

Create an ERD
Create a Migration
Create the Model
Manage Permissions to the Model
Specify the Routes
Create the Controller
Create the Views

If you're just joining a team of developers for the first time, it can be daunting trying to figure out where to start when adding functionality or new models. There are hundreds of files of code and so many moving parts that you may or may not have any idea what they do. While there is a lot of talk about TDD (Test Driven Development) and writing specs before writing any bit of code, I've found it helpful to create a basic prototype or skeleton of what I'd like before getting too deep into tests. And the good thing is, adding models to an already large codebase is easy!

There are many ways to develop, but I've found following a series of logical steps helps me. So here is my general thought process and steps toward adding functionality to an already large codebase. I won't go into major details for syntax(like how exactly to set up a migration), as you can google that information easily and I'm assuming the reader has a base knowledge of Rails. Moreover, every codebase and team is different. Instead, I'm focusing creating an overall guide to influence your decision process when you stand back and go 'what next?' This post is aimed towards beginner developers who understand the basics about Rails but may not have enough experience yet to feel fully comfortable and to get to them to the point where they don't have to worry about setting things up and to get right into the 'real coding'.

It should be noted that much of this work can be done using Rails generate scaffold command from the command line. However, if you're not 100% sure what exactly Rails will create and do, or if you're not yet comfortable creating basic scaffolding on your own, I suggest following these steps.

1. Create an ERD (Entity Relationship Diagram)

Before you write any code at all, you need to plan out what exactly you're going to be creating. You should take some time to figure out what type of model you will need, what attributes it will have, and how it will be related to other models within your codebase.
Example ERD:
Built at www.draw.io
Creating a solid ERD is argueably the most important step in the creation process, so take your time! As the old adage goes, "Measure twice, cut once."

2. Create a Migration!

The first step for creating a new model is to prepare the database to store it's information. If you're coming into a code base and have already gotten it working locally, then the databases (usually defined in your config/database.yml file) have likely already been created. So, you'll only need to create a migration.

General syntax for Migration: $ rails generate migration name_here

This will create a migration file for you, using the name you used in name_here and adding a timestamp to it. Open that file, and create the table you need with the fields you need. Note that the name of the table will be plural. For example, if you wanted to create an Article model, the name of the table in the database will be articles.
See: Active Record Migrations — Ruby on Rails Guides

When your migration file is finished, run: $: rails db:migrate
If for some reason you notice a mistake, or want to undo the changes, you can rollback with: $: rails db:rollback

After the migration runs successfully, you now have a table in your database to store the data for your new model!

3. Create the Model

Next, we will need to write the Rails code for the actual model. Depending on your project, you may have various domains for models, but you can often find all the models you'll need in the app/models directory. Some things to note: the filename should begin with a lowercase letter and be singular. The name of the class within the file should be uppercase and singular as well. So, create a new file in your models directory with the name of your model.

Let's look at an example. Let's say you just created a new table articles through a migration.
In your app/models/article.rb file(notice lowercase and singular)

class Article < ApplicationRecord

end

That's it! You now have a model. Jump into the rails console ($ rails c) to check that it's working as expected. Don't worry about validations or relationships just yet. Let's get everything working correctly first, then we can worry about wiring it all up.

4. Manage Permissions to use the Model

Who will be able to use your Model? By that I mean, will every user to your site be able to read information the model contains? Will they be able to create new ones? Or will you reserve the right to create new models only to admins? If you're coming into a large codebase, likely there will already be some sort of User Authentication service (like Devise(GitHub - plataformatec/devise: Flexible authentication solution for Rails with Warden.)) and Resource Permission Management Service(like CanCan(GitHub - plataformatec/devise: Flexible authentication solution for Rails with Warden.))

Whatever library you use, you should look into how to add (or restrict) permissions to your Model. In the case of CanCan, you will have an ability file in your app/models directory. Within that ability file, you can add permissions based on the type of user.

For example, your ability file may look something like this:

class UserAbility
  include CanCan::Ability

  def initialize(user)
    can :read, Instruction
    can :manage, Gadget if user.admin?
    can [:show, :map], Restaurant
  end
end

It's not imperative to understand everything that's going on here, but you should look into how whatever library you use works when you can. In CanCan's case, within an initialize method you specify what actions(in the Controller) a user can perform on a Model. :read is shorthand for :show, :index, while :manage allows for all normal CRUD actions. If you have other actions you will need to perform, you can add them as well by using an array of symbols.

If you're not sure, for the time being you can just add your model and allow the user to :manage and change it later, but you should think about who exactly will be using the model and what they will be doing with it.

This step is must be completed now because if you do not give permission to access the Model, you won't be able to test your controllers or views later. Each request to use the resource will be stopped by the Application controller and you'll get an error.

5. Create your Routes

After you've given permission to access the model, you'll need to define the route a user will take to reach that resource. It's easy to forget setting up routes, so I find doing this before creating controllers and views to be a logical next step in the process.

Within your config/routes.rb file, you'll need to specify the routes that will access your controller(which we will make next). If your application uses many namespaces, you should take care that you specify routes within the correct namespace or nested within the proper related resource. Also, you'll need to specify any actions that fall outside the realm of the normal CRUD actions. If you nested the routes within another resource, take note of it, as you'll need that information for the next step.

6. Create the Controller

Finally we can create the Controller for our Model. You may already be worried about all the functionality or data parsing or logic you know you'll need to add, but don't worry about all that yet! All we should worry about right now is making sure that when we put in a URL, our application reacts as expected and routes our request to our Controller.

First, we must create the Controller file, and this can be a little tricky. If your Controller is not nested within a namespace or other resource, you can just create a new file in your app/controllers directory. However if your Controller IS nested within another resource, you'll need to either create directory for your new Controller, or be sure to create your Controller within the proper directory if it already exists.

In the proper directory, create a new file to serve as the controller. This file will need to follow the basic naming structure of the plural of your model + underscore + controller. For example, articles_controller.rb

In your Controller, define all the actions the Controller will have. You don't need to add any logic to them; just define them. This example is for a non nested resource. Note the Model name is in uppercase, plural, and there is no underscore:

class ArticlesController < ApplicationController
  def show; end
end

If your controller is nested, you'll have something like this:

class AdminDomain::ArticlesController < AdminDomain::ApplicationController
  def show; end
end

A couple things to note: Remember that the AdminDomain::ArticlesController is NOT inhereiting from something called AdminDomain. The :: is a scope resolution operator, and is serving to tell the compiler that this ArticlesController is located within the AdminDomain, not that it inherits anything. The inheritance is shown after the <, which states the AdminDomain::ArticlesController inherits from AdminDomain::ApplicationController, but you could just as easily have it inhereit from WriterDomain::ApplicationController or ApplicationController (thought this would likely lead to unexpected behavior.) Also, it's technically unnecessary to define blank methods as Rails is kind enough to do default actions without an explicit method declaration. But for clarity sake (and for you to double check what methods you'll have), I suggest declaring them.

7. Create the Views

The default behavior for an action in a controller is to render the view that shares the same name. So, with our blank actions declared in the controller, we should go about making our Views. Like with the controller, you will need to remember if your resource is nested or not. If not, you can simply create a folder in your app/views directory that is the plural of your model name. For example, you would create a app/views/articles directory for all Article views assuming the ArticleController is not nested inside another resource.

Inside your new directory, create a blank file for your view, and give it the file name that reflects the action in the controller. Rails uses ERB out of the box, but check what templating language your team uses and create a file that ends with that extension.
For ERB, app/views/articles/show.html.erb
For HAML, app/views/articles/show.html.haml
etc.

For now, just add a single line in the file to make sure it's working properly. Something like,

<h1>Hello World!</h1>

Now you should be able to put in the URL for the show action of the Topics Controller (check your routes if you're not sure how to access it), and recieve a large "Hello World!" response.

Start Coding!

You're all done! That is to say, you've just started. But you've done all the basic work required to add a Model, Controller, Routes, and Permissions to the codebase. Now you can start worrying about more practical matters, like how you want the page to look, or what data you want to query from the database, or what data you want the Model to validate, the tests you'll need to create, or any of the other concerns that come with creating new functionality.

Good luck and happy coding!

Creating Ransack params without search_form_for

Robert Hustead — Thu, 27 Sep 2018 08:23:14 +0000

Sometimes you have a search box in one area, but you want to display the results of that search with a totally separate controller and view. It can be a little confusing trying to do so with a gem like Ransack, so this tutorial aims to give a basic run down of how you could implement search in one controllers action, and display the results in another controllers action.

First, you'll need to ensure the Ransack gem is in your Gemfile and you run bundle install. You can find further documentation for Ransack here: GitHub - activerecord-hackery/ransack: Object-based searching. This tutorial assumes basic knowledge of how to use Ransack.

Normally, when using Ransack, you'll have a form that uses the search_form_for helper that Ransack provides. Something like:

# in index.html.erb

<%= search_form_for @q do |f| %>

  # Search if the name field contains...
  <%= f.label :name_cont %>
  <%= f.search_field :name_cont %>

  <%= f.submit %>
<% end %>

and in your controller you'll have something like:

# in ItemsController.rb

def index
  @q = Person.ransack(params[:q])
  @people = @q.result(distinct: true)
end

Pretty standard stuff. But what if you want to render a different view with the Ransack results? For example, you want to send users to a specific 'Search Results' page using your Search Controller?

To do this, you'll need to get the search query from the user and format it in a way that Ransack wants to receive it using basic form helpers. Specifically, Ransack wants a parameter with the key 'q', which contains the value of another hash. The hash value of 'q' is a single key value pair where the key is a string containing the methods for how Ransack should look for the object, and the value of that key is a string that is the actual search query from the user.

Basically, your params variable should look something like this:

params = {"q": {"name_or_description_or_id_cont": "Actually query from the User"}}

You can create this 'q' param that Ransack expects explicity with the following:

# in whatever view you'd like users to search from

<%= form_tag search_path, method: :get do %>
  <%= text_field_tag :"q[name_or_description_or_id_cont]" %>
  <%= submit_tag "Search", data: { disable_with: "Searching..." }
<% end %>

This form will create our 'q' param and format it in the way Ransack wants it, and send it along to whatever Controller and Action you set up in your routes. You can of course change the name_or_description_or_cont to whatever fits your needs.

In the Controller you want to use to display the results, you will have the normal Ransack process

  # in whatever controller you'd like to handle the search request

  def search
    @q = Item.ransack(params[:q])
    @items = @q.result
  end

You can now use the @items instance variable in your view to display the results of the query.

Good luck, and happy coding!

How to add "Preview Mode" style functionality to a Rails application

Robert Hustead — Sun, 23 Sep 2018 11:35:42 +0000

Implementing a 'Preview Mode' style functionality is deceptivly simple in Rails. Let's assume we have an application where we introduce items to customers. We have a normal customer domain, and a back end Admin domain where we perform basic CRUD actions like creating, editing and updating items with information.

Now, our writers want the ability to preview the item they are creating to see how it will look when published. However, we don't want normal users to be able to access our draft items. If a user visits an item page that's a draft, they should get a 404 error. However, writers should be able to visit an item page that is a draft to see how it will look (with a banner or something indicating that the page is in preview mode).

Let's implement that functionality. This tutorial will use Cancan for resource authorization, but it can be changed based on whatever library you currently use.

Add Status column to your Model.

First, we should add a status column to our model. In practice, this column should have either values "draft" or "published". So, this column should be of type String, and given a default of "draft" so newly created items are not displayed by default. Also, we should set it so that null is not acceptable. The following migration will work for our purposes:

  # In your Migration file

  def change
    add_column :items, :status, :string, default: "draft", null: false
  end

Update the Model

In your item.rb model file, we should add some Constants for our statuses, as well as a scope to access them easily in our views.

For our Constants:

  # In item.rb

  STATUS_PUBLISHED = "published".freeze
  STATUS_DRAFT = "draft".freeze
  enumerize :status, in: [STATUS_PUBLISHED, STATUS_DRAFT]

And scopes:

  # In item.rb

  scope :published, -> { where(status: STATUS_PUBLISHED) }
  scope :draft, -> { where(status: STATUS_DRAFT) }

Change the Items#show lookup method

We need to change how our Items controller looks up items. You're likely already using a resource authentication library (like CanCan), but we will need to bypass that default functionality. In the case of Cancan, be sure to exclude the show action from any loading and authorization of resources.

We want to see if there is a 'draft' param being passed to the controller. If so, we can look for our item in all of the Items. If the request is not looking for a draft, then we should only look in published Items.

  def show
    items = params[:draft].present? ? Item.all : Item.published
    @item = items.find(params[:id])
  end

Let's assume we have an item with id: 4, and it's status is draft. If a user visits ~/items/4, they will get a 404 error (because services.find(params[:id]) will turn up nothing because it's only looking in Services.published). However, if your writers access ~/items/4?draft=true, they will be able to see the item in draft mode.

What about normal users looking up the above url, and they add ?draft=true to it? Won't they be able to see the item in draft mode? That's not what we want at all. Let's make sure only our writers can access that page.

Update CanCan(or whatever library you use) to remove permission from Normal Users

You need to ensure that normal users are only given read access to items with a status of "published". Check the documentation for your authorizaion library of choice, but for Cancan you may have something like this:

# in models/ability.rb

class Ability
  include CanCan::Ability

  def initialize(user)
    if user.type == "writer"
      can :manage, Item
    else
      can :read, Item do |item|
        item.status == Item::STATUS_PUBLISHED
      end
    end
  end
end

Basically, this ensures that non "writer" users will be able to see Items. However, the only items they will be able to see are those that are published. So, if a user attempts to access ~/services/2?draft=true, Cancan will stop them before the ItemsController attempts to find the record.

We now have all the back end code for "Preview Mode" style functionality. All that remains is updating our Views.

Add the Ability to Update the Item Status

Wherever you have your form setup to create items, be sure to include a selector to choose if the item is in draft mode, or published.

Or, you could use buttons when the writer is saving an Item. The choice is yours, but be sure to give writers the choice when saving Items.

Update Views for Writers and Normal Users

In the Admin domain, add a way to access the draft view with something like:

# in views/admin/items/index.html.haml

# when displaying all the Items
%li= link_to "Preview", service_path(service, draft: true), target: "_blank"

Here, we link to the services page in the normal user domain while also including the draft param set to true. If you remember, this was used in the ItemsController to decide wether to look up from all Items, or only published Items.

In normal users views, if you're displaying services in places other than Item#show, be sure that you only display services that are published. Use the previously created published scope wherever you display services to users.

For example if you want to list all the items related to a category, you might have had something like this:

@category.items.each do |item|
  #display code
end

But you need to change it to this:

@category.items.published.each do |item|
  #display code
end

Add something to the top of Draft Views

Finally, we want something to signify to writers that the service they are looking at is in Preview mode. In the normal Service#Show view file, add some HTML at the top:

- if params[:draft].present?
  %p.draftMessage You are in Preview Mode

Then update the CSS to look however you see fit!

There you have it! You've now emplemented a basic "Preview Mode" feature into your application. Good luck and happy coding!