Open ATS – setting the scene

By | 13/08/2019

The first part of any app is understanding what you’re actually building!  There are a number of key components to the ATS, candidates, vacancies and users – and they’re all intrinsically linked.

A user (hiring manager generally) can have a number of open vacancies, and has visibility over many candidates through that vacancy.  Flipping that around, a candidate can apply for many vacancies, and so can access many hiring managers.  Recruiters are a class of user with more… powers for want of a better phrase.  they can see all vacancies, not just the ones in their name and have editing rights to create new users and candidates where relevant.
Recruiters can also create vacancies on behalf of hiring managers… you get the picture – they can do a lot more than your standard user!

The system is built for autonomy, not need to match candidates to vacancies, if a candidate is on the system and has the right skills (should be auto coded from a cv scan and edited by… you guessed it; the recruiter) they’ll automatically get added to the vacancy.

Side note: I’m still in two minds as to whether to call them vacancies or requisitions.

First stage is to build out a skeleton app with Devise for user authentication, bootstrap for styling and rspec for testing.  Rails 6 is in RC2 and comes with webpack as well as a host of features to dip into.

To create a new application with a pre-release version of rails you need to add the –pre-release argument to the command line but also ensure you’ve run

$ gem install rails -v6.0.0rc2
$ rails new open_ats -d postgresql --pre-release -T -B

 

We’re skipping the test unit as we’ll be using RSpec for testing.

So here’s what my test and dev sections of my Gemfile look like:

group :development, :test do
  gem 'byebug', platforms: [:mri, :mingw, :x64_mingw]
  gem 'rspec-rails', '~> 3.8'
  gem 'capybara', '~> 3.20'
  gem 'database_cleaner', '~> 1.7'
  gem 'dotenv-rails'
  gem 'selenium-webdriver'
  gem 'webdrivers'
end

group :development do
  gem 'web-console', '>= 3.3.0'
  gem 'listen', '>= 3.0.5', '< 3.2'
  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'
  gem 'better_errors'
  gem 'html2haml'
  gem 'rack-mini-profiler'
  gem 'erb2haml', '~> 0.1.5'
  gem 'binding_of_caller'
  gem 'faker', '~> 1.9', '>= 1.9.3'
end

##  Custom Gems ##

gem 'devise', '~> 4.6', '>= 4.6.2'
gem 'bootstrap-sass', '~> 3.4', '>= 3.4.1'
gem 'jquery-rails', '~> 4.3', '>= 4.3.3'
gem 'simple_form', '~> 4.1'
gem 'haml', '~> 5.0', '>= 5.0.4'

$ bundle install

Next off time to install RSpec for testing.

$ rails generate rspec:install

You’ll now see a new spec directory appear… and that’s where the magic happens!

Let’s start by creating some static pages to host some content that’s unlikely to change that often, namely a home, about, faq and contact pages.

$ rails g controller Pages home about faq contact

heading to config/routes and change the routes so you don’t have the ‘pages’ prefix

Rails.application.routes.draw do
  
  root 'pages#home'
  
  get 'home', to: 'pages#home'
  get 'about', to: 'pages#about'
  get 'faq', to: 'pages#faq'
  get 'contact', to: 'pages#contact'

end

We don’t really need to write any tests for this as they’re not dynamic and will very rarely change.Time to initialise our git repo and start committing the changes… almost forgot! Create a new git repo locally and add all new files, then commit changes

$ git init

$ git add -A

$ git commit -am "Initialising repo and first push with static pages"

Next, let’s sort out some content for the static pages and Devise!