Are you searching for an expedient way to control State in your Web and Mobile applications?

React’s Context API can offer a straightforward yet alluring resolution. Its formidable attributes equip developers to store and fetch data from any point of their application effortlessly. This blog post will examine how to use the Context API for state management in web and mobile applications. You’ll also learn why the Context API is preferable to other options when managing State, along with a few best practices that should be kept in mind while employing it.

Understanding React’s Context API

The Context API of React is a remarkably potent tool for managing State in React applications, providing an uncluttered manner to pass data down the component tree without having to feed props from one element to another manually. Initially released with version 16.3, it has become increasingly sought-after by developers due to its simplicity and scalability compared to alternative solutions for administering global State in apps featuring this library. This inclusion presents some unique features such as being able to assemble multiple contexts within a single application; sharing these among varied components while also allotting their own set of values; achieving improved performance through lazy loading rather than charging all data upfront; organizing related values into distinct contexts facilitating greater reusability throughout the app; plus gaining enhanced clarity on any given time regarding where precisely particular pieces of information are employed across the entire codebase thanks indeed allowing debugging capabilities increased visibility over usage locations. These characteristics make the Context API compellingly beneficial for overseeing universal states inside projects built upon React combined, granting greater stability yet offering considerable adaptiveness concerning how you arrange your source code!

Benefits of using Context API for State Management

React’s Context API is a highly potent and supple tool used for managing application state. It allows developers to keep track of data while sharing it amongst components without transferring props manually or utilizing other libraries such as Redux. Furthermore, using the Context API is generally more straightforward than conventional tools utilized for State Management.

The primary profit from employing React’s Context API when handling application state lies in its scalability capabilities; dealing with expansive applications with numerous nested components can be difficult because multiple elements need pass-down properties throughout each layer present within them. Utilizing React’s context object at this topmost component permits all embedded layers access through every aspect of propagation, thus making maintenance painless compared to complex property passing methods or outside resource provisioning from another library.

In addition, utilizing Reacts’ phase benefits even more by enabling direct access explicitly into any contained area inside your app - eliminating slow database calls and complicated object hierarchies so that you can obtain something needed for UI element rendering! The suppleness offered concerning different pieces of state separation is interconnected if required, making usage convenient too, allowing distinct contexts to be created separately depending on what type authentication tokens are desired before connecting these altogether where needed – simplifying various types of data segregation though still attainable quickly whenever wanted! Finally, because React’s contextual objects are merely JavaScript based, they aren’t tasking nor arduous, further finding appeal among starters seeking uncomplicated solutions akin to those found via Redux during the initial stages of deploying and implementing development entirely around React’s hooks!

Setting up the Context API in your project

The Context API offered by React is a powerful tool that can easily manage the State of web and mobile applications. It provides an interface between components to share variables and functions, thus facilitating developers in tracking various aspects of their applications. The primary benefit of using this API is decreased complexity due to storage at one site instead of several components or files.

Implementing the Context API into a project necessitates constructing an instance by calling React’s createContext() function; it will return two properties: Provider and Consumer. The former enables furnishing values for sharing among assorted elements while the latter equips them with access from any point within your app via wrapping those constituents inside {children}. Furthermore, these providers are able to pass down functions as well, so they become globally available, which simplifies state management, avoiding prop drilling problems often experienced when dealing with extensively profoundly nested data structures without utilizing this API. Additionally, multiple contexts are supported in an application; it permits separating states distinctively, making oversight easier instead keeping related ones enclosed in single-context objects, which could prove troublesome for more complicated projects encompassing more intricate conditions requiring frequent alterations., To use such a feature during setup, call upon createContext() again but include further details like name or id attribute following the documentation provided on the official website pertaining to the React library.”

Creating and providing a context in web and mobile apps

Promoting and delivering a context in web apps is of the utmost importance when looking to manage State. React’s Context API provides an enormously valuable tool for developers that permits them to maintain this State easily across components while keeping their code neat and orderly. The Context API offers a system allowing developers to build variables that are available throughout the whole application, no matter where they may be required from. This makes it far more straightforward than having to pass down props through several levels of components or employing more complex solutions such as Redux or MobX.

The Context API also enables convenient customization regarding how data is accessed, stored, and updated too. For instance, if you need to store user information within your app, you can use the createContext method to create a specific context item with whatever required attributes. Providing this Context object by way of the prop so other components have access without needing to explicitly define it each time use occurs. This prop makes life much simpler for developers who must keep track of their own data and employ consistently among different parts of their program without rewriting code regularly.

Moreover, React’s Context API allows coders further freedom when controlling the State inside applications. It enables them to designate what types of updates will occur based on selected conditions being met or variable values changing. An example would include; if specific requirements are fulfilled (such as someone logging into the app), then prearranged actions could follow suit (like fetching new material from an external source). This suggests that programmers do not require manually checking every single parameter anytime something changes – instead, they might arrange regulations causing specified moves automatically whenever those criteria become satisfied. This assists in managing abundant amounts of State since all logic needed is appropriately hidden away at one site instead widespread amongst multiple elements with various states triggers necessitating monitored singularly any point modification transpires.

Finally, React’s Context APT improves debugging practice due supplying helpful communication errors that don’t feature correctly because its inherent error management scheme captures any mistakes before reaching main production level programming- resulting in fewer malfunctions and smoother performance integrated! To sum up, using React’s Context APIs eases rule handling vastly while increasing execution speed, forming a tremendously invaluable resource for both mobile development & web!

Updating State using the useContext hook

The Context API of React offers developers a highly efficient approach to managing the State in their applications. One significant advantage associated with using the Context API is that it allows for direct updating of states from inside a component by the way and means of utilizing the useContext hook feature present within React itself. With this modernized form of data storage, information can be shared between components without having to pass props down through them manually.

By providing access to an application’s context object, changes can occur conveniently directly off any given component rather than needing said prop drilling throughout various levels in order achieve this same outcome–which leads towards improved efficiency by removing redundant propagation passing all together as well as making life easier on those maintaining codebases over time due its clean nature compared other processes requiring manual input instead. Additionally, when used correctly, users see enhancement performance-wise due to avoidance of unnecessary rerendering happening caused by either unrelated elements sharing passed props or extreme nesting children calling upon parent objects more so than contextual usage like provided out-of-the-box per se, React’s own systemization thereof; henceforth noting importance understanding such tool potential pitfalls accompany careless utilization lack thereof respectively.

Overall, React’s Context API is a practical solution tackling complex organizational structures found in web/mobile programming and provides a seamless method of transitioning data states internally through the useContext hook. However, utmost caution is advised against mismanagement or consequences stemming from the incomplete adoption of bonus features made available therein.

Integrating with external APIs for dynamic data

The React Context API provides a powerful and effective way to manage State in web and mobile applications. Using the Context API, developers can store global application data in one location that is accessible by all components within their app, thus, enabling them to keep an account of any changes across the entire application as well as providing a method for easy sharing of data between components without requiring manual props passing down.

Integrating with external APIs is one among many utilization cases for React’s Context API. When necessitating dynamic information-gathering from other sources, Context becomes ideal since it permits storage while ensuring the availability of such collected detail throughout the entirety or parts of this program, either through page loadings or user interactions like pressing buttons or picking items off dropdown menus. To begin setting up the react’s context API, make sure you establish a new object where initial values are stored prior to obtaining any particular info externally. Then, inside your parent component (where creation takes place), add functions/hook which calls out toward this outside source when necessary. Lastly, use the useContext hook so children components may effortlessly read shared states without having direct access.

React’s Context API significantly simplifies system operations compared to using prop drilling / redux alternatives, including rapid building capabilities for and better structured maintainable Apps over time due to its ability to pass values swiftly at once instead of writing unique code each time.

Handling complex state structures efficiently

The React Context API is a handy tool for managing complex state structures in web and mobile development. It allows designers to conveniently store, access, and modify data within their applications without resorting to bulky global variables or frameworks such as Redux. This makes it appropriate for small-scale and larger projects requiring more powerful solutions for managing states.

Context API offers an approach by which elements can access information from the parent component without forwarding props down numerous levels of the element tree, making it much easier and quicker when constructing apps with elaborate navigation systems. Furthermore, using Context instead of conventional methods like sending props through each level of the element tree lets developers decrease excessive rerenders caused by prop modifications from higher stages in construction.

Context also permits developers to share info across components regardless if they have different positioning inside the complete application structure, resulting in teams working on separate parts at once, not needing any worries regarding relocating props between sections of code or assembling exhausting universal variables to watch over multiple files.

Employing React’s Context API would afford software engineers several merits while building web & mobile applications: fastening up development time because it lessens complication considering management status; and augmenting execution thanks to reducing the number of unnecessary remounts: additionally allowing uncomplicated sharing based on facts all across features no matter where situated within general app design. The effortlessness of utilizing Context renders brilliant solutions, whatever kind of job requires proficiently organized handling either large scale /small scale, facilitating creators allotment period inventiveness rather than fussing how to handle them.

Best practices and tips for optimizing performance

Utilizing React’s Context API is an effective method of managing the State within applications. It can be used in mobile and web-based apps, allowing a unified means to handle data. By using this tool, developers can maintain consistency between multiple components that span their entire application.

Let’s review several techniques and tips that should be implemented during development to maximize performance with React’s Context API. Firstly, always use the most recent version available when creating any program by utilizing this particular context object, as doing so will ensure all newly added features or bug fixes make their way into your personalized app, something that could lead to greater levels of security while increasing overall performance at the same time.

Secondly, do not pass in anything more than what is necessary when constructing a context object before establishing its value property; if you happen to need only one component’s State inside another tree, then just send through the said piece rather than overdoing yourself by sending across bulk from either source - doing such might result in prolonged calculations alongside rerendering troubles which would ultimately lower general response speed. Similarly, whenever updating values within these contexts, exercise caution again because passing complete arrays or objects back into identical ones produces unhelpful results like excessive calculations and other similar issues related to rendering processes, hence why it should be avoided as well!

Lastly, keep track of whether inputted props have been altered before attempting different changes on states since taking note counts allows you to dodge unwanted updates involved but especially in larger scale programs affiliated with intricate structures where throughout the render cycle, changing must take place due to changed props transferred down via parent sets. Finally, after nesting them together, try keeping nested forms shallow otherwise resulting overhead load caused by extra computations run on each frame up rise above reasonable limits.

Conclusion

In conclusion, the Context API supplied by React is a potent instrument for managing State in web and mobile applications. It facilitates an intuitive method of accessing, handling, and updating data across the entire application. The API permits the easy establishment of global state variables that can be used in any component without passing props down multiple levels of components. This process simplifies keeping track of all data within the app, guaranteeing that changes are reflected promptly through each part. By utilizing this Context API, developers may streamline state management in their respective projects resulting in improved overall efficiency.

Need help with your React project?

Visoft Inc. is a clear choice for those searching for coding aid. Our company provides various services, from training to products, making it feasible for clients to receive the assistance they require concerning coding matters. Our highly proficient and educated team will collaborate with you to create tailor-made solutions that suit your needs and budget constraints. Moreover, regardless of whether the task is simple or intricate, we possess all the relevant qualifications and knowledge to complete tasks correctly on one first attempt. Therefore there should be no more hesitation - contact us today if coding help is what you are looking for!

Introduction

Today I was attempting to use Rails’ counter cache feature to save on expensive queries. My model’s association is a has_many :through. I ran into issues on my first attempt but eventually came across the answer after beating my head against a wall for quite some time.

TL;DR: If you use a custom counter_cache column on your belongs_to, duplicate that on the has_many associations as well.

Models

Let’s work with a standard, easy to understand, has_many :through models:

class Physician < ApplicationRecord
  has_many :appointments
  has_many :patients, through: :appointments
end

class Appointment < ApplicationRecord
  belongs_to :physician
  belongs_to :patient
end

class Patient < ApplicationRecord
  has_many :appointments
  has_many :physicians, through: :appointments
end

Counter Cache, Attempt #1

Now let’s implement counter cache on these models with custom column names. On the belongs_to side of the association, we’ll set up our counter caches for physicians and patients.

class Appointment < ApplicationRecord
  belongs_to :physician, counter_cache: :patients_size
  belongs_to :patient, counter_cache: :physicians_size
end

Migration

Now, we need to add these counter cache columns with a migration:

class AddRenderingCountsToCampaign < ActiveRecord::Migration[6.0]
  def change
    add_column :physicians, :patients_size, :integer, default: 0, null: false
    add_column :patients, :physicians_size, :integer, default: 0, null: false

    reversible do |dir|
      dir.up do
          Physician.find_each { |p| Physician.reset_counters(p, :patients) }
          Patient.find_each { |p| Patient.reset_counters(p.id, :physicians) }
      end
    end
  end
end

This migration will set up our database with these new columns and set values for existing Physicians and Patients via reset_counters.

Be sure to run rails db:migrate

Test It

After that, we can now test it in the Rails console.

1] pry(main)> p = Physician.last
  Physician Load (4.5ms)  ...
=> #<Physician:0x00007fd7aa4acb60. ..>
[2] pry(main)> p.patients.size
   (5.6ms)  SELECT COUNT(*) FROM ...
=> 1

Hmm, from my understanding, the size method should be using our counter cache, not issuing a SQL COUNT query in the database. What’s going on here?

Digging into the Documentation

So, it’s not working. Querying the web, it’s difficult to find help with this issue. That is until you dig into the Rails docs, specifically the has_many method

Scrolling through the options for has_many, you’ll come across :counter_cache and it says: “This option can be used to configure a custom named :counter_cache. You only need this option, when you customized the name of your :counter_cache on the #belongs_to association.”

Eureka! We customized the name of our :counter_cache, so let’s give this a try!

Attempt #2

Let’s revisit the models and make this modification.

class Physician < ApplicationRecord
  has_many :appointments, counter_cache: :patients_size
  has_many :patients, through: :appointments, counter_cache: :patients_size
end

class Appointment < ApplicationRecord
  belongs_to :physician, counter_cache: :patients_size
  belongs_to :patient, counter_cache: :physicians_size
end

class Patient < ApplicationRecord
  has_many :appointments, counter_cache: :physicians_size
  has_many :physicians, through: :appointments, counter_cache: :physicians_size
end

Now, we’ll hop back into the Rails console and test it out:

1] pry(main)> p = Physician.last
  Physician Load (4.5ms)  ...
=> #<Physician:0x00007fd7aa4acb60. ..>
[2] pry(main)> p.patients.size
  => 1

Yay! Now it works!

Note that I added the :counter_cache option on both has_may associations. If not, and you tried to do p.appointments.size, it would query the DB again.

Conclusion

This was a tough nut to crack. Again, most blog posts on the web don’t outline this gotcha. The answer is in the Rails docs but somewhat hidden. I hope this post helps another dev save some time and sanity.

Introduction

I started a brand new Ember Octane project today. The first thing I wanted to do was set up prettier in my Ember app. I started using prettier for a client, and I adopted the practice myself. If you aren’t familiar with prettier, it’s a library that formats your code in an opinionated way. Not everyone will like the defaults, but prettier is very configurable (which I will show you).

Note these steps can be used for any JavaScript project. I’ll show the changes to a new Ember Octane project, but the NPM libraries will work in other projects as well.

Overview

If you aren’t familiar with prettier, take the example below (from the README on GitHub).

Input

// Given this line of code...
foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

Output

// You'll end up with something like this...
foo(
  reallyLongArg(),
  omgSoManyParameters(),
  IShouldRefactorThis(),
  isThereSeriouslyAnotherOne()
);

As you can see it really cleans up your code.

Install

You are going to need a few node packages:

npm install --save-dev eslint-plugin-prettier
npm install --save-dev --save-exact prettier
npm install --save-dev eslint-config-prettier

Let’s look at these packages.

• The first, eslint-plugin-prettier, allows prettier and eslint to work together.
• The second, prettier, is the prettier library.
• Finally, eslint-config-prettier turns off eslint rules that conflict with prettier.

Configuration

Once you install these, you’re going to have to modify your .eslintrc.js file.

Your extends section should look like this:

extends: [
  'plugin:prettier/recommended',
  'eslint:recommended',
  'plugin:ember/recommended',
],

The new item there is: 'plugin:prettier/recommended',

This does three things:

1. Enables eslint-plugin-prettier.
2. Sets the prettier/prettier rule to "error".
3. Extends the eslint-config-prettier configuration.

Now you can customize prettier with a .prettierrc file. This can be YAML or JSON. I’ve opted for JSON, and the following is my config:

{
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "avoid",
  "requirePragma": false,
  "insertPragma": false,
  "proseWrap": "preserve"
}

This config was generated by Michael Larson’s Generator. It’s an excellent tool for customizing prettier easily. I recommend that you use this to personalize prettier to your liking.

Running Prettier on Your Code

I have a new Ember Octane project that I started. There is one commit in the git history for the initial Ember Octane application. I wanted to start with a clean, pretty project. I executed prettier from the terminal to update everything in my project:

prettier --write '\*_/_.{js,css,html}'

This updates all the default files for a new Ember Octane project. You’ll end up modifying ten of Ember Octane’s default files. Also, in Figure 01 below, you’ll notice the changes to package.json and package-lock.json for the addition of the node libraries. Another file is .prettierrc which holds our prettier configuration.

Editor Enhancements

To enhance our developer experience, we can use editor packages to make using prettier easier. I use Atom, and there is a prettier package that will automatically format your code on save (if you choose, Figure 02).

Note in Figure 02, there is the first option to use prettier with eslint, make sure you check that for your Ember Octane project.

Once installed, when you are on a JavaScript file, you’ll notice a prettier option in your status bar (Figure 03)

If, for some reason, you don’t want your file to be formatted, you can click on the green icon and disable it from updating on save. Of course, that sort of defeats the purpose of keeping your code “pretty.”

Conclusion

I like using it to format my code in a deterministic way. I don’t have to worry about other devs or even myself from creating messy code. If you want to take this to the next level, have prettier run when you commit to GitHub with an Action

Hello again and congrats! You’ve made it to the end of the series (Part 5) of Riding Rails. Today we’ll develop a details view for each job and wrap up the series. This series is just a taste of what you can do with Rails. Anyway, let’s get started

Yikes! Here you are at Part 5 and you haven’t read the others? Check out Part 1, Part 2, Part 3, and Part 4.

Last Time

Last time you had some homework to work on creating a better partial view for each job. How did you make out? I’m sure yours look better than Figure 1!

And the tiny bit of ERB code that produced Figure 1.

<li class="job">
  <h6><%= job.title %></h6>
  <p>
    <%= job.company %> &#183; <%= job.type %> &#183;
    Posted on <%= job.posted_at %></p>
</li>

This sets us up to change the title into a link to the details, but before we venture into that, there are two glaring issues with our search results. First, they aren’t sorted by date. Second, that date isn’t exactly friendly. Let’s fix that sort first.

Sorting

We get jobs in two places in our app, and from two different sources. First, we’ll tackle the homepage. Since we are querying our database and utilizing ActiveRecord, there is a method we can use called order. Hop into the HomeController and make that change, tacking it on the end of limit.

If you review the ordering docs, you’ll see that the default order is ascending. Not exactly what we want, so we’ll specify descending.

class HomeController < ApplicationController
  def index
    @jobs = Job.limit(10).order(posted_at: :desc)
  end
end

That was easy, right? Now onto the SearchController. We are querying GitHub Jobs here and just taking them in the order that they come to us. The jobs here are in an Array. Here we’ll use Ruby’s sort_by method to do the sorting.

class SearchController < ApplicationController
  def index
    redirect_to root_url if params[:term].blank?

    results = GithubJobs.import(params[:term])
    @jobs = results.sort_by { |r| -r.posted_at.to_i }
  end
end

The code is separated into two lines for clarity. You can also call sort_by tacked on the end of the import method. Anyhoo, what’s going on here in the code block is that it’s taking a result (job) from GitHub, and converting it to an integer so that we can sort it in descending order (denoted by the minus sign). By default, the sort would be ascending, like Rails. We could have also used Ruby’s sort to do the same thing.

With that out of the way, let’s work on that date.

DateHelpers

Rails has a bunch of DateHelpers available. We can utilize time_ago_in_words to give our date a nice look. To see something like “2 days ago” is nicer than a big long date string. Using this is super simple, open up your _job partial and call the method with the date like so:

<li class="job">
  <h6><%= job.title %></h6>
  <p>
    <%= job.company %> &#183; <%= job.type %> &#183;
    Posted <%= time_ago_in_words(job.posted_at) %></p>
</li>

This is a handy, built-in helper that Rails provides. If it didn’t, we could have written a custom helper, which is just a function to do what we wanted. We’d call it the same way as time_ago_in_words.

Details View

Our app is coming along; however, without being able to see the details of the job, it provides minimal value. We’ll fix this shortcoming in the following sections.

Resource Routing

We’ll start by creating a JobsController, and we’ll utilize resource-based routing, one of the greatest features of Rails. The concept of resources in Rails simply equates to setting up actions for CRUD based operations related to a model. Instead of specifying seven routes, we can denote a resource and only have one route in our routes.rb file. You’re probably wondering about the seven routes. Well, they are all related to CRUD operations, so you have (this is the HTTP verb and the action name): GET index, GET show, GET new, GET edit, POST create, PUT/PATCH update, and DELETE destroy.

Let’s see it in action and see what Rails does. Navigate to http://localhost:3000/foo (an undefined route) in development. You’ll see we have two routes right now, root and search. Now open up config/routes.rb and add the following line under the two routes we previously added:

Rails.application.routes.draw do
  ...
  resources :jobs
end

Refresh the browser, and you’ll see the new routes:

Now for our app, we don’t need full resource routing because we won’t have CRUD operations available to the user for now. All we need is the GET jobs#show route. We can do this two ways, by specifying a get route, as we saw in an earlier part of this tutorial, or we can tell Rails either the actions we want to include (only) or exclude (except). Since we only need one, we’ll use the only option:

Rails.application.routes.draw do
  …
  resources :jobs, only: [:show]
end

If you refresh http://localhost:3000/foo, you’ll see that we now have only three routes. Now let’s work on the controller and view for the show route.

JobsController

Let’s create the JobsController now. Create a new file in app/controllers called jobs_controller.rb. In that file, we’ll need just one action, show:

class JobsController < ApplicationController
  def show
  end
end

Now in this action, we need to handle two use-cases. The first is if the user clicks on our homepage where we have the job records stored in our database. This is the typical use case. But in ours, we need to handle results from our database and ones from the search. For jobs not in our database, we’ll look up the details based on the details_url that will be passed to us.

class JobsController < ApplicationController
  def show
    id = params[:id].to_i
    if id > 0
      @job = Job.find(id)
    else
      result = JSON.parse open("#{params[:details_url]}.json").read
      @job = Job.build(result)
    end
  end
end

That code should be pretty self-explanatory. First, we convert the params hash’s :id to an integer. Normally, we could just pass in the params[:id] directly to find, but here we want to make sure the value is greater than zero. We’ll be passing in an id of zero when the record isn’t part of our database. In the else we’ll get a :details_url passed in via the params, and from there we can query GitHub Jobs and get the details. If you’re new to Ruby, the string may look a little strange ("#{params[:details_url]}.json"). This is Ruby’s string interpolation. First, you need to use double quotes for this. Next anything between #{...} is a Ruby command/variable. So here we’re just appending .json to the end of the details_url.

Show View

Let’s see if you can add the view without guidance. Remember, it’s convention based. We have a JobsController with a show action; what does Rails expect? Here is a sample layout for your job show view:

<div class="container">
  <div class="row">
    <h1><%= @job.title %></h1>
    <div class="col-md-8">
      <p>
        <a href="<%= @job.company_url %>">
          <%= @job.company %>
        </a>
        &#183; <%= @job.type %> &#183;
        Posted <%= time_ago_in_words(@job.posted_at)%> ago
      </p>
      <p><%=raw @job.description %></p>
    </div>
  <div class="col-md-4">
    <img src="<%= @job.company_logo %>" alt="Logo" />
    <p><%=raw @job.how_to_apply %></p>
  </div>
</div>

Most of this should be easy to understand, except for raw. By default, ERB will escape HTML characters with the standard output brackets (<%= ... %>). In this case, we’re getting our description and how_to_apply from a trusted source (GitHub Jobs), and we want the HTML to render. To do this, we specify the raw helper, which will do exactly what we want. Be cautious with raw; we’re only using it here because of the trusted source. If this were user input, there could be malicious code, and we wouldn’t want to execute it.

Did you figure out where to put the file? If not, it’s app/views/jobs/show.html.erb. All views go into the app/views directory. Since we have a JobsController, Rails will look for a jobs directory. In the controller, we have one action, show, thus the show.html.erb file.

Linking

At this point, we need to change our _job partial to link to the show action. The route helper methods created are job_path (relative path) and job_url (absolute URL). With this knowledge, we can change the job partial. We need to have a condition here; if we have an id we’ll link to the job with just a path of /jobs/:id. However, for models that have an id of nil (ones from GitHub Jobs), we will pass in a zero for the :id and pass along the source_url as a query string parameter.

<li class="job">
  <h6>
    <% if job.id %>
      <%= link_to job.title, job %>
    <% else %>
      <%= link_to job.title, job_path(0, details_url: job.source_url) %>
    <% end %>
  </h6>
   ...
</li>

In the first case, we can just pass along the job model and Rails will automatically use the id property passing it to the jobs_path. This is simply a shortcut method on link_to. Otherwise, we’ll explicitly build the job path using the helper method job_path giving it an id of 0 and a details_url query param of job.source_url.

Now go ahead and give both use cases a try (from the database, assuming you have some records and the search results). Both should work, and you’ll see the different URLs based on the way you entered the show route.

Wrap Up

Congrats, you’ve made it! It’s been a reasonably long ride over the past five parts of this tutorial, Riding Rails. We walked through building a simple application with Rails. In this last part, we skipped testing because of time, but I would encourage you to go back and add tests. That’s one of the advantages of using generators since it creates a test file for you. However, there’s no reason why we can’t build one ourselves.

Remember, this application works, but could use some more coding. For example, we only handled GitHub Jobs, and we wanted to make this an aggregator of jobs from different sites. We didn’t persist any jobs to our database, but we saw in Part 3 how to do so. Like any app, there is always room for improvement.

Anyway, I hope you enjoyed the series. Feel free to leave a comment or contact us. Happy Rubying!

Thanks for coming back, this is Part 4 of Riding Rails. Today we’ll be discussing routing, controllers, and views. These will finally bring our application to life. I’m going to try to keep this part short, but we have a lot to cover. Let’s get started!

Missed Part 1, Part 2, or Part 3? No worries, we’ll wait for you while you catch up.

To Generate Or Not

In Part 3, we added all the files we needed by hand. It took a little extra time to set everything up. While that’s typical, it doesn’t make for a great tutorial. Because of this, we’ll use another of Rails’ generators, the controller generator. Before generating anything, let’s look at the help:

rails g controller --help

We’re going to customize the generator with switches. We don’t need a lot of files right now, so we’ll turn off the creation of JavaScript and the Helper. We will also turn off Routes and add these manually. Once you learn about routing, you can have Rails create the routes for you. Finally, we will start with one controller action called index. Here is the full command:

rails g controller Home index --no-javascripts --no-helper --skip-routes

Tack on a --pretend to the end if you want to preview what is going to happen.

With this command, four files will be generated for us: a controller, a view, a test, and a stylesheet. Isn’t that easier than listing all the paths, the files, and the base contents for each one? I hear a resounding, “Yes!”

Routes

Rails is an MVC (model, view, controller) framework. I’ll skip the typical drawing of the three pillars of MVC and just show it to you in action.

If you’re truly missing the MVC diagram, there are already hundreds on the web.

Start by re-running Guard, and have it run all the tests (hit Enter or type all and Enter at the prompt). We have a failing test. Let’s see what Rails generated by opening up the controller test (test/controllers/home_controller_test.rb). Well, hey! Rails created a test that we would have had to write ourselves. It simply tests that the index action can be retrieved. It’s failing because we haven’t entered a route yet. Luckily, creating a route is super simple. Open config/routes.rb and inside the Rails.application.routes.draw block add one line:

get 'home', to: 'home#index'

In doing that we’re simply saying, direct HTTP GET requests to the HomeController’s index action. Now, in the test that’s failing, change home_index_url to just home_url. With the way this route is written, the routing helpers created by Rails would be home_url and home_path. The home_path (which we’ll just call “the path” for this home route), is just the relative path to the action, like /home. The URL (home_url) is the full path: http://localhost:3000/home. We could change the name of the helpers by passing an explicit as: 'something', and that would give you helpers named something_url and something_path. If you want to be explicit, just tack on , as: 'home' to the route you created in config/routes.rb.

Rails Server

Back in Starting With Rails we started the Rails server. If you don’t remember the command, it’s merely rails s or rails server. Open a new Terminal instance for the server and go ahead and run it. Remember that you have to be in the root directory of your project. Then open your browser and navigate to http://localhost:3000. You’re greeted with Figure 1.

Now try, http://localhost:3000/home, and we see Figure 2.

Routing - The Return

Before we go any further, we want our home#index action to be the root of the site. We can tell Rails that we have a root easily in the routes.rb. In fact, do we want people hitting /home anymore? Probably not, simply the / of the root would look cleaner. We can shrink our routes file just to be the following:

Rails.application.routes.draw do
  root 'home#index'
end

Go to the root URL in the browser again. The welcome message is gone, and we see our home#index view. Perfect. Try hitting http://localhost:3000/home, and since we’re in the development environment, you get what I think every MVC framework should give you, a list of all your routes (Figure 3).

Isn’t that awesome? Of course, we only have one route, but that’s rare.

Before we move on, let’s fix that failing test. Match the code below, and the test should now pass:

class HomeControllerTest < ActionDispatch::IntegrationTest
  test "should get index" do
    get root_url
    assert_response :success
  end
end

Views

Now that we have our homepage/root all set let’s work on adding content. For ease of styling and such, I’m going to use Bootstrap v4, which has finally been released to production. We could include it from the CDN, but there is a gem available. Since we’re doing everything in Rails, let’s install the gem. We need two again, because Bootstrap relies on jQuery as well (and popper.js, but that’s already required by the bootstrap-rubygem). Time to add them to the .gemfile.

# use bootstrap
gem 'bootstrap', '~> 4.0.0'
# bootstrap needs jquery
gem 'jquery-rails'

You know the drill by now, bundle install and then restart your Rails server.

Last step, we have to import Bootstrap in our stylesheet. We’ll use the app/assets/stylesheets/home.scss stylesheet here, and it should look like:

// Custom bootstrap variables must be set or imported *before* bootstrap.
@import "bootstrap";

Refresh your browser, and you’ll see a style change right away (Figure 4)

Alright, on the homepage we’re going to show a form for searching as well as a list of jobs loaded from our database. That means we need some data from our controller. Let’s hop over there and get a list of jobs for the homepage; then we’ll come back and use the data.

Controllers

Open up app/controllers/home_controller.rb and take a look. There is a class with one method. This method is an action because we route to it. With just that empty little method, Rails, by convention will search for a view file to render. So, if you have a HomeController, Rails will look for app/views/home/index.html.erb. Notice the name of the view matches that of the action, and that it’s under a home directory. Rails does all this for us, without us having to specify anything. That’s the beauty of convention over configuration.

Let’s do some work on the index action and query the jobs that we have in our database. To use ActiveRecord, you simply use the class name of the domain model and call methods off of it.

class HomeController < ApplicationController
  def index
    @jobs = Job.limit(10)
  end
end

There is an all method which obviously returns all items in the set, but I don’t think we want to show everything we have on the homepage. Here we are using limit(10) so we’ll only get back ten records. Now you’re probably wondering what’s up with @jobs. This is called an instance variable. In Ruby, a variable that starts with an @ is an instance variable. In Rails, these are special because they are exposed to the view.

Back to Views

Can you believe that’s all we need to do on the controller side? Don’t believe it? Well, I’ll prove it. Let’s use the @jobs collection in our view (app/views/home/index.html.erb).

<div class="container">
  <h1>Jobs</h1>

  <ul>
  <% @jobs.each do |job| %>
    <li><%= job.title %></li>
  <% end %>
  </ul>
</div>

This is very simple markup. With ERB, when you are doing something (like each) you use <% ... %>. Notice there is no equals sign in there for the loop. When you want to display something, you add an equal sign like this, <%= ... %>. This yields the output in Figure 5. Note that I only have one record in my database at the moment.

Before we add a search form, we need a new action to handle the post. We could use the same controller to do this, but let’s add a challenge and use a different controller and action. We’ll call this search and only accept an HTTP POST.

This is no different (apart from the name) than what we just did earlier. If you choose to generate it, here’s the command:

rails g controller Search index --no-helper --skip-routes --no-assets

Add a route called search that points to search#index, remember this will be POST only. Here’s the whole file:

Rails.application.routes.draw do
  root 'home#index'
  post 'search', to: 'search#index'
end

Finally don’t forget to fix the new broken test that we have from generating the new controller. When you have done it should look like the following.

...
class SearchControllerTest < ActionDispatch::IntegrationTest
  test "should post to index" do
    post search_url
    assert_response :success
  end
end

Now let’s look at the form on the homepage.

  <%= form_tag search_path, class: 'form-inline' do %>
    <div class="form-group mb-2">
      <%= label_tag :term, nil, class: 'sr-only' %>
      <%= text_field_tag :term, nil, class: 'form-control', placeholder: 'Enter a Search Term' %>
    </div>
    <button type="submit" class="btn btn-primary mb-2">Search</button>
  <% end %>

That’s straight Bootstrap v4 with Form Helpers provided by Rails.

Wiring Up the Search

Everything is pretty much in place at this point. The only thing we need to do is handle the search. Where do you do work like that? If you said the controller, awesome! Open up app/controllers/search_controller.rb. Inside the index action we’ll query GitHub Jobs, which we built in Part 3. Our term parameter will be passed to the controller via the params hash. Let’s see the code in action.

class SearchController < ApplicationController
  def index
    redirect_to root_url if params[:term].blank?

    @jobs = GithubJobs.import(params[:term])
  end
end

There are just two lines here, but the only thing you haven’t seen yet is the redirect_to method. This is provided to our controller from Rails. It redirects the user back to the homepage if they try just to submit the form without a term. The other line should look pretty familiar from Part 3. We’re just storing the results in a @jobs instance variable. Now we can use it in app/views/search/index.html.erb.

<div class="container">
  <ul>
  <% @jobs.each do |job| %>
    <li><%= job.title %></li>
  <% end %>
  </ul>
</div>

Hmm, that code is the same that we have on the homepage. Remember our job model is the same from the database or our GitHub Jobs parser. That’s not very DRY (don’t repeat yourself), let’s fix it.

Partials

Let’s break out the code we have to render a job. There’s not much there yet, it’s just li with the title of the job. Create a new folder jobs under views, in that folder we’ll create a partial view. By convention partials in Rails start with an underscore. Thus your file should be called _job.html.erb. In that file, for now, just put in the code that renders a job:

<li><%= job.title %></li>

Now, here comes the “magic.” I wrote about this back in 2010, but I didn’t mention this excellent shortcut we can use. Ready?

<ul>
  <%= render @jobs %>
</ul>

That’s all we need. Rails is incredible! Because we have a jobs folder, with a _job partial and we have a @job collection, Rails looks for the _job partial and renders it. No need to specify anything else.

Now go ahead and change the code for the search page; it’s the same code as above.

Wrap Up

We have the basic functionally working. It’s nothing significant to look at, but it works.

For your weekly homework, go ahead and style up the _job.html.erb file. Just having the title shown isn’t very user-friendly. If you need docs on Bootstrap, head over to their site. Feel free to further style the search form, the homepage, etc. If you want to use some of the JavaScript components in Bootstrap, you’ll need to follow the instructions in their README.

Next time, we’ll look at drilling down into a job so we can see a detailed view of the position. We also should be able to wrap up the series.

Welcome back to Riding Rails, this is Part 3. In this part, we’ll be working with GitHub Jobs and persisting the information in our database. We’ll see how far we get today. I think there will at least be four parts to this series. I’m coding this application live, and I’m trying to keep these parts from being too long.

If you’re just stumbling in, you probably missed Part 1 and Part 2. This builds on the other two parts, so you’ll probably want to hop back and read those first.

Recap

We left off last time learning about testing, fixtures, model validation and Guard for running our tests automatically.

Before we get started today, how did you go about solving the URL validation? There’s no real wrong answer. I guess if you skipped it that could be considered incorrect. Did you find the format validator and tried your hand at validation by regular expression? If you went this route, I hope you have a lot of tests. URL testing can be tricky. Hmm, if there were only other options. Did you happen to search the web for Rails URL validation? You may have stumbled on at least a couple of gems that solve this issue. The benefit of using a gem here would be that someone already did testing on it. Notice I didn’t say “maybe did testing,” because the Ruby community is awesome.

Yes, yes, I’m sure there are gems without tests/specs, but I can’t imagine them being very popular. In fact, read on.

You also could have written a custom validator. The would also require a lot of tests. My choice was to use the valid_url gem as it states it has “The highest test coverage with more than a hundred different valid and invalid URL examples.” That’s cool, have a look at the specs. Another option I quickly came across was validates_url. It’s similar to valid_url, and I’m sure just as good.

Gem or No Gem

The first thing we’ll do today is look at utilizing the github-jobs gem. If you inspect the code for the gem, you’ll find that it’s straightforward. It merely queries GitHub Jobs and puts the results into an OpenStruct. We need the results in the job_slayer jobs model, which we could fill pretty easily from an OpenStruct. After reviewing the specs that exist for the gem, it’s not worth using it, sadly. It won’t save us from testing at all because there are just a few specs in the gem. This is a good example of a non-popular one. I didn’t take the time back in Part 1 to review the gem, and it’s specs. No worries though, we can pivot from the initial plan without issue.

Jump Right In

Let’s get to work querying GitHub Jobs. We will test-drive this feature (remember TDD) and since we are using Guard, there is no need to run your tests manually.

Guard is still running, correct? If not, spin it up with the command guard. Make sure you are in your application’s root directory.

Let’s walk through a test or two and then I’ll give you the requirements before moving on to the actual code so that you can get familiar with writing tests yourself. The first thing we have to do is create a test file. Create a directory (parsers) under test and a new file github_jobs_test.rb. Full path should be test/parsers/github_jobs_test.rb. We’ll add in the GithubJobsTest class and our first test. Note also the require test_helper at the top.

require 'test_helper'

class GithubJobsTest < ActiveSupport::TestCase
  test "should have a class method of import" do
    assert_respond_to GithubJobs, :import
  end
end

In this basic test, we’re asserting that our class GithubJobs has a method (responds to) called import. We need to be able to call GithubJobs.import

You might be more familiar with the term static methods instead of class methods. Class methods in Ruby are “close” to static methods in say C#.

We now need to add the class and class method of import to make this test pass. Here’s the full class (this is a new file/directory that you need to add, app/parsers/github_jobs.rb):

class GithubJobs
  def self.import
  end
end

This is some new syntax here. By defining a method with self creates a class method. That is called like so: GithubJobs.import. There isn’t any reason to instantiate anything here since this is a “utility method.”

From import we want to get back an array of job models. But before we do, think about what we expect to get from not supplying any parameters to the method. Should we return all of GitHub Jobs’ jobs? It will limit the result to 50, so I guess it’s ok to do that, though I don’t see us using that feature. Perhaps we should require a parameter, something like a search term. Let’s do that and make sure the param is not empty. Add this to the GitHubJobsTest

test "should not work without the term param" do
  assert_raises(ArgumentError) { GithubJobs.import }
end

We’ll raise an error if the import method gets called without an argument. We’ll utilize Rails’ blank? method. The blank? method returns a boolean. In Ruby if a method returns a boolean, it typically is appended with a question mark. This isn’t a hard/fast rule; it’s at the option of the developer. But something to keep in mind for good practice as we’re developing.

def self.import(term)
  raise ArgumentError, 'You must supply a term' if term.blank?
end

Ruby is beautiful and expressive, so instead of using the block form of if we can put it after a method. Oh, you don’t need parentheses to call a method, so raise ArgumentError, 'You must supply a term' can also be written as raise(ArgumentError, 'You must supply a term'). Just as with the question mark appended to a boolean, this is up to the developer.

Getting Results

Now that we have our method set up, we’re going to start calling GitHub Jobs. This is a problem with testing. Imagine we write this test and it’s run 100 times, that’s 100 calls (for one test) to GitHub Jobs. We don’t want to do this to their service, so we need to think of a better option. We could mock the return from GitHub, but there is an easier way. Here is another gem that we’ll use in our project. It’s called vcr. We also need the gem webmock which will intercept web calls for us.

You remember how to install/use a gem in our tests, right? Add them to the group :development, :test like so:

group :development, :test do
  ...
  gem 'vcr'
  gem 'webmock'
end

Then run bundle install. Within the test_helper.rb file, add the following between require 'rails/test_help' and the class definition:

...
require 'vcr'

VCR.configure do |config|
  config.cassette_library_dir = "test/vcr_cassettes"
  config.hook_into :webmock
end
...

Don’t put your cassettes directory under test/fixtures, as Rails will try to load them for each test and error.

We have set up vcr, I’ll explain how it works later, now let’s use it in a test. We need to do one thing. First, we need to go out to GitHub Jobs’ site and find a term that has a couple of jobs available to test our method. Depending on when you do this, you will likely get different results from what’s listed here, but the concepts will all be the same. I searched for my favorite JavaScript framework, Ember.js, and that yielded just one job. I’ll use this for the example test.

The first thing to test is to make sure the method import returns an array.

test "should return an array" do
  VCR.use_cassette('search-ember') do
    results = GithubJobs.import 'Ember.js'
    assert_kind_of Array, results
  end
end

We can satisfy this with just the following:

def self.import(term)
  raise ArgumentError, 'You must supply a term' if term.blank?
  []
end

Tacky, huh? Oh, that probably looks weird if you are new to Ruby. That [] is an empty array, and because it’s the last line of the method, it’s returned automatically without you having to specify return. You can if you like, but other Rubyists may point and laugh at your code.

Anyway, that’s all we need for this test which now passes, let’s keep going. Add another test method as below and see if you can figure out how to make it pass on your own.

test "should return an array of job models" do
  VCR.use_cassette('search-ember') do
    results = GithubJobs.import 'Ember.js'
    assert_kind_of Job, results.first
  end
end

Did it pass? Fail? Are you confused? Did you change that last line in the import to be:

[Job.new]

Kudos! Obviously, we need more tests. Oh, you’ve probably noticed the VCR.use_cassette('search-ember') block in the past two tests. This is all we need to do to use VCR. What will happen is once we make a web call, it will record it and file it for us. The second run of the test will make the same request to a URL, but VCR will intercept it and give us back the recorded records. Pretty sweet, eh? This gives us a snapshot of results that we can test against, and it will be constant regardless of what happens at GitHub Jobs.

Now, let’s keep testing! We need to make sure each property of the job is filled in. So we’ll add a test for each property. Remember, one assertion per test (thank you, Roy Osherove). I’m not going to copy all the tests here, but I’ll give you one to get you started:

  test "should fill in the job model's title" do
    VCR.use_cassette('search-ember') do
      results = GithubJobs.import 'Ember.js'
      assert_equal results.first.title, 'Javascript Application Engineer'
    end
  end

At this point, we need to actually query GitHub Jobs to satisfy the test. This is going to be super simple thanks to Ruby’s built-in JSON parser. We also are going to need the OpenURI library, which is part of Ruby, we just have to require it so Rails can tell which open we want (if you don’t do this, Rails will try to open the URL as a file, not what we want). Here is what app/parsers/github_jobs.rb should look like:

require 'open-uri'

class GithubJobs
  def self.import(term)
    raise ArgumentError, 'You must supply a term' if term.blank?

    params = "description=#{URI.encode(term)}"

    result = JSON.parse(open("https://jobs.github.com/positions.json?#{params}").read)
    result.map { |job| Job.new(job) }
  end
end

This will give you three UnknownAttributeError errors, because the job hash contains keys that Rails doesn’t know about, like url. Also, it’s going to have a problem with both id and created_at, because those get handled automatically, and we don’t want GitHub’s data in those fields, we want our own. Finally, we also need to set the other attributes to custom values, such as source and source_url. Because of this, Job.new won’t work for us.

We’ll fix this with a class method on job called build that will build a job model for us.

You may be thinking “why are we creating a job this way and not using the constructor?” It’s because overwriting initialize on ActiveRecord objects is a bad idea.

In app/parsers/github_jobs.rb, change the last line:

class GithubJobs
  def self.import(term)
    ...
    result.map { |job| Job.build(job) }
  end
end

Now create the class method on the job model:

class Job < ApplicationRecord
  ...

  def self.build(attributes)
    new do |j|
      j.title = attributes['title']
    end
  end
end

Make sure you use strings for the hash keys here instead of symbols. This is because JSON gives us string keys/values. Generally, in Ruby, you use symbols for hash keys.

Go ahead and add tests for each attribute of the job model, making sure it’s filled. Did you forget the names? Look back at Part 1. I’ll show you one more test:

test "should fill in the job model's posted_at date" do
  VCR.use_cassette('search-ember') do
    results = GithubJobs.import 'Ember.js'
    assert_equal results.first.posted_at, DateTime.new(2018, 2, 7, 3, 12, 1)
  end
end

Remember, my data is probably different from yours, so make sure you look at the JSON result for the first job that comes back. You can access the JSON from GitHub Jobs by tacking on a .json to the end of the URL.

And the code to make it pass:

def self.build(attributes)
  new do |j|
    j.title = attributes['title']
    j.posted_at = attributes['created_at']
  end
end

Continue writing a test and then mapping each attribute from the hash to our new job object. When you finish, you should have 24 total tests and assertions. I know it’s tempting to skip tests, but it’s important to ensure that all our attributes have values. In Guard, you can run all your tests by just hitting Return in the Terminal that’s running Guard. You can also type all at the prompt, but that’s what the Return key does.

Rails Console

For our last topic today, let’s try out querying GitHub Jobs and saving the job model to the database. We don’t have time to build the interface as this tutorial is pretty long already. Instead, we’ll take a look at the Rails console. Open a new Terminal instance in the job_slayer directory and fire up the Rails console with the command rails c or rails console.

To start off, let’s try using the GithubJobs.import method, remember to give it a search term or you’ll get an ArgumentError. For example:

2.5.0 :002 > jobs = GithubJobs.import 'javascript'
 => [#<Job id: nil, title: "Senior Product Engineer"...

Now, if you want to persist the array returned from our parser, all we need to do is loop over each job and call the method save on it, you can do it like so:

jobs.each {|job| job.save!}

But with Ruby, we can shorten this code up:

jobs.each(&:save!)

This will iterate through the array and call save! on each job. Note that I’m using save! vs. just save. The one with the exclamation point will throw an exception if it fails, where save returns a boolean. When looping like this, it’s a good idea to use save!

The exclamation point is another convention that Rubyists use to denote that something is either going to modify the object directly or could potentially throw an exception. Again, it’s up to the developer. This is just like the question mark for boolean operations, like blank?.

To exit the Rails console, just type exit and hit Return.

Wrap Up

This tutorial went a little long today, but we learned valuable lessons. We discovered the VCR gem, which allows us to record our web interactions, and automatically play them back when we query again. We found that parsing JSON is a piece of cake with Ruby. We also saw how to test-drive a complete class using TDD.

In the next part of “Riding Rails,” we’ll put all this to work. We’ll work on a front-end for searching GitHub Jobs. This will entail routing, controllers, and views. Don’t worry though, it sounds like a lot, but it isn’t with Rails.

Welcome back to Riding Rails, this is Part 2. In this installment, we’ll talk more about models and introduce testing. In case you missed it, check out Part 1 as this builds on what we started.

We left off last time learning about migrations. We just scratched the surface with models and used the Rails model generator to create it and supporting files.

Testing Within Rails

Now that you know about migrations, we’ll get back to working with our model. We’re going to use test-driven development to work on our model, and because you’re a Ruby developer now, we test our code.

By default, Rails is set up for Test Driven Development (TDD), not the common alternative Behavior Driven Development (BDD). Tests in Rails inherit from ActiveSupport::TestCase, which in turn inherits from Minitest::Test. Minitest also has a Minitest::Spec option available, but to use BDD syntax like describe and it in Rails, we would have to install a gem. If we were going to do that, I would have installed RSpec (my preferred spec library) before generating the files. If we were using RSpec, then we would see *_spec.rb files instead of *_test.rb files. It’s not a big deal to install the gem, but I’m trying to keep extraneous installs to a minimum to avoid confusion. Thus we’ll use TDD. If you aren’t familiar with BDD, there are specs in place of tests. So I apologize in advance if I call something a “spec” instead of a “test!”

If we were using Minitest::Test directly, we would have to write tests with underscores for the method name like so:

def test_jobs_title_attribute
…
end

With ActiveSupport::TestCase running on top of Minitest::Test, we can write the same test like this:

test "jobs title attribute"
…
end

The key takeaway is that with ActiveSupport::TestCase we can use the test method and pass it a string, rather than being forced to provide a Ruby “test class friendly” name. This will allow us to be more descriptive with our test case names.

Testing Models

Open up test/models/job_test.rb, and let’s write our first test.

You’ll notice that in job_test.rb there is a class defined as we saw in the migration. There is also an include and some comments in the class. Go ahead and delete the comments (the lines that start with a #). That leaves us with the class definition and the include. We’ll use this included file (test_helper.rb) in all of our tests. So if we need to write any custom logic to be commonly shared across all of our tests, it can go in here.

Now let’s write our first failing test. We’re going to assert one requirement per test. This is something I learned long ago by reading “The Art of Unit Testing” by Roy Osherove. If you are not familiar with the concepts of writing unit tests, such as what “assertions” are and the important role they play in unit testing, I highly recommend reading that book. Let’s start with validations. We want to ensure that the Job object has a title, otherwise it should not be allowed to save. You’ll see in the test below that we create a new Job object without a title, and then tell the test method, using assert_not, that we expect the job to NOT be saved.

  test "should not save job without a title" do
    job = Job.new(title: nil)
    assert_not job.save
  end

Now that we have our test, let’s run it with the command rails test. You’ll see it fails as expected:

F

Failure:
JobTest#test_should_not_save_job_without_a_title [../job_slayer/test/models/job_test.rb:6]:
Expected true to be nil or false

The F indicates a failure, and you can see the message Expected true to be nil or false. That’s not very specific. Let’s fix that by passing a message to the assert_not method:

  test "should not save job without a title" do
    job = Job.new(title: nil)
    assert_not job.save, 'Saved the job without a title'
  end

Now, when you run the test again, we have a more meaningful failure message:

Failure:
..
Saved the job without a title

With the failing test, we’ll want to fix it by adding validations to the Job class. Open up models/job.rb and fix it by matching the class below:

class Job < ApplicationRecord
  validates :title, presence: true
end

Are you surprised by the Job class? Where are our attributes we defined in the last part? The answer lies in app/models/application_record.rb, see how it inherits from ActiveRecord::Base? Well, ActiveRecord, Rails’ default ORM (object-relational mapping), does the mapping from the database for us. Seems almost magical, doesn’t it? Still curious? Read more about ActiveRecord in the docs.

Re-run the test, and now it passes. Let’s do another! We want to make sure more fields are required. Let’s target the metadata that we are storing about a job. In your same test file, underneath the previous test we just made, add the new test code as shown here:

  test "should not save job without a source" do
    job = Job.new(source: nil)
    assert_not job.save, 'Saved the job without a source'
  end

Now that you are familiar with the syntax from our first test, you should be able to see that this second test expects that the source attribute needs to have a value in order for the Job to save successfully. Since we are providing a null value to source this test should fail. Run the failing test using rails test and… wait… what? It passed?! Hmm, that’s not right. Do you see the problem? We are specifying source: nil, but the now required title isn’t set, so THAT is causing our Job to not save even though we haven’t added validations to the source attribute yet. I guess we can add the title with a value to the hash we are sending to Job.new, but that’s going to get old fast when we add more validation of attributes. “There must be a better way,” I can hear you exclaiming. You are right!

Fixtures

There are a few ways to tackle this problem that we have. Rails provides us with Fixtures, which is just a fancy word for “sample data.” We could use these Fixtures in our tests. We could also create a hash of all the attributes needed to create a model and change just the attributes we are interested in for each specification. A third option, which I personally use, is a gem called FactoryBot (previously known as FactoryGirl). That said, let’s use what we have instead of introducing another gem. Plus Factories vs. Fixtures is an another conversation entirely. Let’s go the Fixture route since Rails has already set it up for us. If you hop over into test/fixtures/jobs.yml, you’ll see some basic code that Rails created for us. Let’s use the attributes it provides to save typing. Change the file to look like this:

one:
  title: Senior Software Developer
  posted_at: 2018-02-20 13:01:47
  location: Remote
  type: Contract
  description: MyText
  how_to_apply: Apply here: https://visoftinc.com
  company: Visoft, Inc.
  company_url: https://visoftinc.com
  company_logo: https://images.visoftinc.com/logos/visoftinc.png
  source: https://jobs.github.com
  source_url: https://jobs.github.com/positions/1234567890

If you look at test/test_helper.rb, you’ll notice that it is already set up to load all of our fixtures before each test:

  # Setup all fixtures in test/fixtures/*.yml for all tests in alphabetical order.
  fixtures :all

With that in place, let’s change our two tests to the following:

class JobTest < ActiveSupport::TestCase
  test "should not save job without a title" do
    job = jobs(:one)
    job.title = nil
    assert_not job.save, 'Saved the job without a title'
  end

  test "should not save job without a source" do
    job = jobs(:one)
    job.source = nil
    assert_not job.save, 'Saved the job without a source'
  end
end

As you can see, we are initially loading up our test data from the Fixture, and then nullifying the field that we want to test. Rerun the tests using the command rails test, and uh oh!

An Error

Since we’re going along with actual development, this could happen. Let’s take a closer look at the error:

E

Error:
JobTest#test_should_not_save_job_without_a_title:
ActiveRecord::SubclassNotFound: The single-table inheritance mechanism failed to locate the subclass:
'Contract'. This error is raised because the column 'type' is reserved for storing the class in case of
inheritance. Please rename this column if you didn't intend it to be used for storing the inheritance class
or overwrite Job.inheritance_column to use another column for that information.
    test/models/job_test.rb:5:in `block in <class:JobTest>'

It looks like we used a reserved word in ActiveRecord, type in our job model. Now, we could go and change this, but job.type sounds a lot better than job.job_type or something. ActiveRecord reserves the word type for doing single table inheritance (STI). We can change this, telling ActiveRecord that we’re not going to be using STI with our job model. Open the model file (app/models/job.rb) and inside the class add the following line:

self.inheritance_column = :_type_disabled # disable STI

Save, and re-run the tests. The error goes away, and we’re left with what we expected back when we started this second test, a failure. Let’s fix that the same as we did with the first test we wrote; you’re job model class should now look like this:

class Job < ApplicationRecord
  self.inheritance_column = :_type_disabled # disable STI
  validates :title, presence: true
  validates :source, presence: true
end

Run the tests again (rails test) and voilà, success!

Other Validation Helpers

Now that you know about the presence validator, we can add this to other attributes. But what about other types of validation in Rails? There are a ton of other built-in helpers available. Let’s say we want to make sure that the type attribute must contain only certain values like “Full Time”, “Part Time”, and “Contract”. To add such a validation we can utilize the inclusion validator which lets us specify a set of valid values for the attribute. Let’s test that out now. Remember we are using TDD so let’s write the test first. Add the following to your test file below the second test we just finished.

  test "should not save job without a valid type" do
    job = jobs(:one)
    job.type = 'Seasonal'
    assert_not job.save, 'Saved the job without a vaild type'
  end

You know the drill by now, run the test making sure it fails. Now let’s fix it, add this to your job model:

  validates :type, inclusion: { in: ['Contract', 'Part Time', 'Full Time']}

Re-test, and it works!

Save, Test, Rinse, Repeat

We’ve repeated saving and running the tests a bunch of times now. You’re probably a bit annoyed having to repeat these steps over and over. The good news is that there is a better way. It involves installing a gem (well 2), but that’s a simple task in Rails thanks to Bundler. I thought about omitting this since it’s a separate install, but this isn’t new syntax that you need to learn or anything. It’s a merely an automated test runner. It will make your development process much better.

Open up your Gemfile and add we will add two gems in the group :development, :test, like so:

group :development, :test do
  ...
  gem 'guard'
  gem 'guard-minitest'
end

Now, from a terminal window aimed at your project root, run the command below to install the two new gems we just added:

bundle install

Once that’s completed, initialize guard-minitest from the same terminal with this command:

guard init minitest

This creates a Guardfile telling guard what to run. Open the Guardfile in the root of your project and uncomment the section that starts with # Rails 4. Finally, where it says guard :minitest do change that to read guard :minitest, spring: "bin/rails test" do. If done correctly your Guardfile should look like this:

guard :minitest, spring: "bin/rails test" do
  # with Minitest::Unit
  watch(%r{^test/(.*)\/?test_(.*)\.rb$})
  watch(%r{^lib/(.*/)?([^/]+)\.rb$})     { |m| "test/#{m[1]}test_#{m[2]}.rb" }
  watch(%r{^test/test_helper\.rb$})      { 'test' }

  ...
  # Rails 4
  watch(%r{^app/(.+)\.rb$})                               { |m| "test/#{m[1]}_test.rb" }
  watch(%r{^app/controllers/application_controller\.rb$}) { 'test/controllers' }
  watch(%r{^app/controllers/(.+)_controller\.rb$})        { |m| "test/integration/#{m[1]}_test.rb" }
  watch(%r{^app/views/(.+)_mailer/.+})                    { |m| "test/mailers/#{m[1]}_mailer_test.rb" }
  watch(%r{^lib/(.+)\.rb$})                               { |m| "test/lib/#{m[1]}_test.rb" }
  watch(%r{^test/.+_test\.rb$})
  watch(%r{^test/test_helper\.rb$}) { 'test' }

  ...
end

Open up a new Terminal tab/window in the same application root folder. Then fire up guard by just typing guard. If it all worked correctly, you should see 3 runs, 3 assertions, 0 failures, 0 errors, 0 skips. Every time we save from now on, rails test will be run for us. Much easier!

Trying Out Guard

Since this is the first time you’re using Guard, let’s make sure it’s working as expected. Add a new test inside job_test.rb. You are familiar with the process so go ahead and make sure that the source_url is provided, and here’s something new, make sure that it’s actually a URL. There are various ways to enforce that, and there isn’t a wrong way providing you really test it out. Save the test(s), and Guard will run it. Fix the failure and Guard will jump into action and rerun the test. Continuous feedback from Guard makes TDD/BDD very productive. When you’re done with testing the new requirements, you should have at least five total tests. Remember, one assertion/unit of work per test. I’ll leave it to you to decide how many tests you add depending on the solution you choose. Don’t shy away from any option, this is how we learn.

Homework

In this post, we only validated a few of the attributes in our model. Look at what we have and where it can be improved. Even though users won’t be entering data into the database directly, remember the mantra of “garbage in, garbage out.” We don’t want just anything entered for say the company_url, do we? If you need a refresher, just have a look at Figure 2 under the heading Models. You could potentially require every attribute in our job model. However, this may limit what we’re able to store from other sources. However, if you plan to stick to just one source (GitHub Jobs), then that would probably be beneficial. Don’t forget to test out any validations that you add.

Wrap Up

In this second part of the tutorial, we saw how we could test-drive requirements with models. We learned that Rails comes with Fixtures, what they are, and how they can be used in our tests. After numerous times of saving and running the tests manually, we discovered that Guard is a fantastic tool that will give us constant, automated feedback.

Look out for part 3 of this series, in which we will discuss moving our application forward. With our job model in place, we’ll start using the model when we are querying GitHub Jobs and persisting everything to our database. I hope that you found the information here useful. If you have any questions, please leave a comment below or you can contact us.

Now that you have Ruby and Rails installed, let’s put Rails to work by creating a real application. In this post, we’ll build a job search application. We’ll utilize GitHub Jobs as our initial data source, but the idea behind this app is to aggregate different job APIs eventually.

If you’re a developer, the last thing I need to tell you about is data types and constructs. I find those topics to be not only dull, but a waste of time. Thank you, but I know about loops, conditions, etc. I’d rather see a project-based approach to teaching, and that’s what I plan to do in this series.

The Plan

Before we venture into development, let’s take a moment and plan our approach. We know we’re going to utilize GitHub Jobs API and that we’ll be using Rails as our framework. Now we absolutely can send and parse data ourselves, but I did a quick search on Web and found a little Gem that will do that for us. It hasn’t been updated since 2014. However, if we see it’s out-of-date, we can always fork it and make the modifications needed.

We should decide on what templating syntax we’d like to use. The default is ERB, but personally, I like Slim. There is also HAML, but I find Slim to be nice and fast and the syntax is straightforward. For this application, I’m going to stick with ERB. This is the easiest since it’s what Rails uses out-of-the-box. That said, it’s cake to change to something else like Slim, it’s just adding a Gem to our Gemfile. Most importantly, I don’t want to introduce something new like Slim in this first tutorial.

Finally, let’s talk about testing. Personally, I practice BDD (behavior driven development) using RSpec in my Rails projects. BDD is similar to TDD (test driven development). The difference is how you look at the problem. While TDD focuses on units of work, BDD focuses more on the bigger picture of how the application will be used. Rails is set up for testing from the start. One of the things I absolutely love about Rails is how the environments work. We’ll see this in action as we start development. Rails’ default test framework is minitest. With minitest, we’re able to practice either TDD or BDD because the syntax adapts to whatever style we wish. Again, we’ll stick with the default test framework for ease of understanding.

Rails New

Do you recall how to create a new Rails application? Navigate to a “Development” directory of your choosing, and we’ll create a new application called job_slayer.

rails new job_slayer

This will create a job_slayer directory with our new application. Simply change into it using the command: cd job_slayer. Once there, fire up your favorite text editor and open the directory. Take a look at the folder structure of the application; it should look similar to Figure 1.

This is the structure of all Rails applications. We’ll be spending a lot of time in the app and test folders in this tutorial.

The last thing, you use source control, right? Well, Rails actually initialized our application as a git repository automatically. We just need to add the files that Rails created for us and commit the changes.

git add .
git commit -m "Initial commit"

We’re in a good place. Let’s start writing some code!

Models

We’ll start by creating models for our application. Let’s think about this a little bit. What models are we going to develop? This app is called job_slayer, so we probably want a job model. We’ll use this to capture information about a job. Since our end goal is to make this a job aggregator, we need to standardize the different results from the various sources (remember, we’re just going to be targeting GitHub Jobs for this tutorial). We should also cache the jobs we receive locally, so we aren’t pinging the API each time. This way, we can have a list of jobs on our homepage that users can browse through.

We have to think about the attributes we want on our model. If you look at the GitHub API docs, you’ll see some sample URLs and responses. I took a screenshot (Figure 2) of the fields that are provided to us.

Í

This is probably a good starting point for our job model. Of course, not all APIs are going to provide the same attributes, but we can always make changes to our model in the future.

We saw in the last tutorial how Rails comes with generators. You’ve seen the scaffold generator in action, and I promised no scaffolding for this application. That doesn’t mean there aren’t other generators that we can use. If you want to see all the things you can generate, run the command rails g --help. Since we need a model, we’ll utilize the model generator. This will create four files for us: the model, a database migration, a test, and a fixture file. You can see this from looking at the Rails generator docs (rails g model --help). The last thing that I’d like to mention is that if we provide the Rails model generator with the attributes we want, it will generate some code for us. You don’t need to provide attributes, but then you just get blank files for free. Notice that we aren’t specifying an attribute id, nor any timestamps. We’ll discuss this later. The list of attributes is pretty much identical to what we are receiving, with the addition of posted_at, source, and source_url. We’ll use these to store metadata about the job.

rails g model Job title posted_at:datetime location type description:text how_to_apply:text company company_url company_logo source source_url

Whew! That’s a long command because we have a fair amount of attributes that we want to store. Now let’s look at what was created and start working with this model.

What if you make a mistake with a generator command? Well, there is an “undo” that Rails provides, for our example, it’s merely rails d model Job. The d is a shortcut for the word destroy. Go ahead, give it a try before we make any modifications. Just remember to regenerate the model!

Figure 3 shows the four files that were created.

You’ll notice the first item is the database migration. Let’s take a detour before continuing with our job model and discuss it.

Migrations

Let’s look closer at the database migration that was created for us. It can be found in the directory db/migrate. You’ll see one file in that directory with a timestamp, that is the migration that was created. The migration is Ruby code that creates a table called jobs with the attributes that we specified in the command. Let’s investigate this file a bit more. You can see a shortened example of the file below.

class CreateJobs < ActiveRecord::Migration[5.1]
  def change
    create_table :jobs do |t|
      t.string :title
      t.datetime :posted_at
      ...
      t.text :description
      t.text :how_to_apply
      ...
      t.timestamps
    end
  end
end

It’s all pretty straightforward. Everywhere we didn’t provide a specific type is created as a string, which is exactly what we wanted. For the attributes where we specified a type, the type is represented in the migration. Assuming this is the first time you’re seeing a migration, let’s talk about the oddities of the file. At the top, class CreateJobs < ActiveRecord::Migration[5.1] This is how you define a class in Ruby. It inherits from ActiveRecord::Migration[5.1]. The [5.1] refers to the version of ActiveRecord (Rails’ ORM) created this file, and the double colons indicate that ActiveRecord is the “namespace” and that Migration is the class that we are inheriting for our new CreateJobs class.

This class has a single method, change. This same method gets called when we migrate and if we rollback the database. Everything from this point on is part of the DSL (domain specific language) that we use to modify the database. The create_table :jobs do |t| does what you’d expect, creates a table called jobs.

If you’re new to Ruby and you’re looking at that statement, the :jobs, specifically the colon, may be confusing. This is what’s known as a Ruby symbol. If you follow that link, you can find more information about symbols. The easiest way to understand them is to think of them as “constants.” Unlike a string they don’t store anything, they are just a name. If you’re still curious, there is plenty of information on symbols out there.

I feel that the Ruby code is pretty simple to understand, even if you aren’t a developer. The one oddity you’re probably wondering about is t.timestamps. No magic here, it’s just a little helper method that creates the created_at and updated_at columns. The cool thing about those columns’ names is that Rails will, by default, manage them for us. Now that is magical! To get the magic, all you need to do is name the columns correctly, and by using the timestamps method, it will do that for us.

You may be looking at this class and thinking that it’s pretty simple. There are no constraints of anything specified. If we wanted to, we could define things like defaults and indexes, but we’re not going to get into that level of complexity in this tutorial. Don’t worry though; we’ll handle things on the code side to prevent garbage data by way of validations.

Hmm, there’s still no id column specified, what’s going on? Well, create_table will automatically add the id column (unless you tell it not to). Honestly, without an id how would you identify and delete records easily?

Now to migrate your database (which will create it automatically for us in SQLite), it’s a simple command:

rails db:migrate

If you’re using an older version of Rails, < 5, then the command is similar, it’s rake db:migrate instead. Go ahead and migrate your database now.

Review

In the first part of this tutorial, we got our first look at models and migrations in Rails. We used the Rails model generator, and you saw there is no magic involved. Your mileage may vary using generators, and you may find you prefer to create files yourself instead. There’s no harm in that at all. In fact, I often do that exact thing when I’m developing. I invite you to explore the help files for the generators, as there are various customization options (rails g model --help for example). You can even customize the files generated with your own templates if you want. Finally, Rails has both the model and a migration generator (that command, you guessed it, rails g migration,). Personally, I find the migration generator to be the most useful as it gives me a starting point quickly.

In the next part of the tutorial, we’ll go back to working on the job model. We still have work to do there, as we need things like validations and tests. I hope you found this first part of “Riding Rails” to be helpful. As always, let us know what you think.

In my last post I walked you through installing Ruby on your machine, be it a Mac, Windows, or Linux computer. If you remember, I planned to help my developer friend set up Rails on his machine. So with Ruby set up, you’re ready to install Rails. Let’s get started.

Windows Specifics

Like last time, I’ll start with Windows. If you followed along last time, you might have used the Rails Installer. If you did, excellent, you can skip ahead to the next section. If you went the Ruby Installer route, we’re going to need to install one thing before working with Rails. Out of the box, Rails uses SQLite as it’s default data store. SQLite is an easy to install, self-contained SQL database engine. It’s easy to use and supports up to 140 TB of data; Rails chose SQLite. Even if you decide to move to something else, like Postgres, you might find yourself using SQLite in your local test environment. Once you use something that is Postgres specific, you’ll then need to use it in all your environments, but that’s getting ahead of ourselves.

Head over to the SQLite Download Page, and grab the precompiled binary for Windows. There is a 32-bit and 64-bit version of SQLite; I’d match the version to your version of Windows, which is most likely 64-bit. Unpack the zip archive to a folder in your PATH, such as the C:\WINDOWS\system32 folder, or even the Ruby bin folder (typically C:\Ruby\bin). That’s all there is to it.

RubyGems

Before we install Rails, I’d just like to talk a little about RubyGems. Gems (for short) are either written in Ruby or C, as I mentioned in the last post. When you issue a gem install command, by default, the gem will be installed as well as documentation for the gem. Honestly, this is just a waste of local space. To change the default behavior, tell it to skip documentation, run the following command:

echo 'gem: --no-document' >> ~/.gemrc

That command will work on Mac and Linux, for Windows, where you don’t really have a “home directory,” the one-liner command for you is:

(echo install: --no-document && echo update: --no-document) >> c:\ProgramData\gemrc

Note that by installing it in ProgramData it applies to all users.

With the .gemrc (or gemrc in Windows) in place, you can install any gem and know that it will skip installing documentation for every gem you install.

Installing Rails

This section is going to be very short. Rails is just a collection of gems.

All we need to do is run the command to install the latest version of Rails:

gem install rails

That’s it! Gems are a snap to install.

Running an Existing Rails Application

Installing Rails is super easy, but what if you want to run an existing Rails application that you download from say GitHub. You don’t have to install Rails directly. As long as the project has a Gemfile, you can use a gem called Bundler. The Gemfile in the root of the project specifies it’s dependencies, and in a Rails project you’re going to find an entry like gem 'rails', '5.1.5'. This line tells Bundler to install Rails v5.1.5. Because of this, we don’t have to install Rails separately; we can just use Bundler. But before we use Bundler, we need to install it, note we’ll only need to do this once:

gem install bundler

Now that we have Bundler, we can navigate to the project’s root folder (where the GemFile is and run the simple command:

bundle install

Bundler will kick into action and install all the dependencies required by the Gemfile.

Want to work on different Rails project? Just bundle install in its root directory, that’s all there is to it.

A Simple “App”

Congrats, you’ve reached the end of the tutorial. You now know how to install Rails, easy, isn’t it? We learned a little more about RubyGems and then discovered Bundler.

If you want to test your Rails install out, we can create a little, super-simple application in just a few commands. Now, this is nowhere near a production app, but it will get you to verify everything works. I’m going to use the scaffold generator that Rails has to whip up something quickly, but you’ll see that the scaffold generator generates a lot of things we don’t want. With that said, open up a Terminal session and type the following:

rails new notepad
cd notepad
rails g scaffold note title content:text
rails db:migrate
rails s

These five commands will do the following:

1. Create a new application called notepad and run bundle install - rails new notepad
2. Change into the newly created notepad directory - cd notepad
3. Create scaffolding - rails g scaffold note title content:text
   1. This will generate a database migration file
   2. A Note model with title as a string and content as a text field
   3. A NotesController which will have actions defined on it
   4. A /notes route that will handle GET, POST, PUT/PATCH, and DELETE
   5. Tests for your model, route, controller
   6. A NotesHelper
   7. Views for your controller actions, both ERB and JBuilder files
   8. A CoffeeScript file
   9. Finally two SCSS files, one for scaffolds and one specifically for notes.
4. Create the SQLite database and run the migration file - rails db:migrate
5. Finally, run the development server

Now browse to http://localhost:3000/notes, and you’ll see you can add, update, create, and delete notes. A straightforward and simplistic app. Oh, by the way, the rails g command is a shortcut for rails generate and rails s is short for rails server. You can use either command, but I prefer less typing with the shortcuts. Below you can see the result in action.

Wrap Up

I hope you enjoyed this post. We just scratched the surface of Rails, but we installed it and made sure it worked. We utilized the scaffold generator, and I’m sure you realized that the scaffolding generates a lot of files that we don’t need. We’ll see in another post other Rails generators so we can pick and choose what we want. As always, please let us know what you think, either leave a comment or Contact Us.

The other day I was working with another developer who primarily develops within the Microsoft space, such as .NET. My goal was to get him to try Rails, but the precursor to Rails is Ruby. Ruby isn’t hard to install at all, and some platforms, namely macOS and Linux, have excellent options available. This post is going to show you how to set up Ruby on your machine, regardless of your operating system.

Windows

We’ll get Windows out of the way first. It is a cinch to install Ruby on Windows. There are two easy options available. First is the Ruby Installer. You can just download their installer and be on your way with Ruby, easy peasy. As of this post, Ruby v2.5.0 is the latest version out.

Ok, you have Ruby installed on Windows. With Ruby Installer though, there’s a slight catch. It has to do with RubyGems. Gems (for short) are packages you can use. An example of one would be like the ruby_odata library that I wrote. This gem allows you to work with an OData server using Ruby instead of complex web calls. Another gem, called nokogiri allows you to navigate XML documents with ease. This is where the “catch” exists. This particular gem is written in C, not Ruby. Nokogiri isn’t the only C-based gem, there are others, and you’re bound to hit one when installing gems. To install these on your system, they need to be compiled. Windows doesn’t ship with build tools that can do this, so you need to install what’s known as the DevKit. It looks like if you installed Ruby 2.4 or greater, you can install the DevKit with a command bundled with the Ruby Installer.

Another option on Windows, that’s an all-inclusive installer (no need to install the DevKit separately) is the Rails Installer. As the name suggests, this will setup Rails for you as well, plus other tools like the DevKit. These installers are tied to specific versions of Ruby and Rails. As of this post, the newest Rails Installer is based on Ruby v2.3.3, not the latest version of Ruby (v2.5.0). Not the end of the world, but just be aware of your version.

If I had to choose on Windows, I’d go the Rails Installer route. I’ll talk about installing Rails in a different post, but if you want to use Rails out-of-the-box on Windows, you’re going to need things like SQLite. This and other tools are included with the Rails Installer, so it will get you going quickly.

macOS

MacOS has various options for installing Ruby, and in fact, most of these work on Linux too. First, let’s start with the Rails Installer. While I’d go with it for Windows, I wouldn’t choose the macOS versions. As of this post, the macOS options are pretty out of date. Besides, there are better options for installing Ruby on a Mac.

Let’s start with a precursor. If you’re on Mac, grab a copy of Xcode. It’s free in the Mac App Store. Why Xcode? Well, it comes with various command line tools that it will install the first time you run it. These tools make your Mac able to compile C-based gems. Now I know Xcode is large for just command line tools. Of course, there are other options. Another option that I just read is this:

“Apple now provides an official Command Line Tools for Xcode package that you can install without needing to install Xcode itself! You can install it with xcode-select --install on Mavericks and Yosemite or download it from Apple’s developer site (free registration required) and search for “Command Line Tools” –OSX GCC Installer

Honestly, if you’re a software developer on macOS or OSX, you’re probably going to tinker with Mac or iOS development. If that’s the case, just grab Xcode. If not, try the command or download the tools from Apple’s Developer Site.

Now that we have the appropriate tools, we can install Ruby and even compile Ruby from source if needed. I’d recommend a Ruby Version Manager. There are two big players in this space, RVM or rbenv. Personally, I like RVM and haven’t tried rbenv at all. Rbenv can’t be installed alongside RVM, so it’s hard to test both without getting rid of the other. You’ll find developers who swear by both, but I’m going to go with RVM for this guide. But before I start, check out rbenv’s list of why you should choose it over RVM. Know that whatever one you pick, you’ll be able to switch between versions of Ruby with ease.

Follow my guide for using RVM below, the process is the same on both systems. I’d recommend that you review the Linux steps below as I dig into some of the prerequites of RVM a little deeper.

Linux

For Linux, we have most of the same choices as macOS, except for the Rails Installer (which again, I wouldn’t recommend on macOS due to its age (as of this post). On Linux, I’d recommend RVM again, but rbenv is available here as well. We’ll talk about installing RVM below, but here I will go over here is it’s requirements. Well, having just installed RVM on a Virtual Machine, I can tell you that RVM will prompt you for your password so it can install prerequisites for you. I’m assuming this requires sudo or root privileges. I had sudo rights on the VM, and I didn’t need to install the requirements manually. Pretty sweet, eh?

Maybe you don’t like that RVM does that for you automatically, or maybe you don’t have root permissions. That feature of RVM is called autolibs. You can disable these or pick and choose the scenarios you want RVM to handle. To do this during the install, before you install Ruby with RVM, type the command:

rvm requirements

This will show you what RVM needs to be able to install and you can install these packages yourself or have someone with root permissions do it for you. Note that this is only for installing versions of Ruby. RVM’s requirements for installation are standard *nix tools, such as curl.

RVM

With the prerequisites out of the way, let’s do this!

To install RVM, just follow the commands on the homepage. I’ll repeat them here, but know that the RVM site has the most up-to-date information. Ok, here we go, just copy and paste these two commands into Terminal window:

gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

Then:

\curl -sSL https://get.rvm.io | bash -s stable

Done.

Read the instructions at the end of the install (the 2nd command), the easiest thing to do is just restart Terminal, or you’re able to load RVM manually just for your current session. Once that’s done, it’s time to install a version of Ruby.

Now, installing any version of Ruby is just a Terminal command away, for example, to install the latest (as of this post) 2.5.0, you can use the following command:

rvm install 2.5.0

Now, if you want to use 2.5.0, you can issue a command to RVM:

rvm use 2.5.0

Oh, what? Do you want that as your default version of Ruby? RVM has you covered:

rvm use 2.5.0 --default

Make sure you notice the two dashes before default.

That’s all there is to it. Now RVM comes with other tools that are available to us, but I’ll leave that for a future post.

Wrapping Up

There you have it; Ruby is now installed on your machine. Look for more posts in the future where we’ll explore installing Rails and friends on our machine. Yes, I did write about installing Rails eight long years ago, but that’s, obviously, a little out of date.

I hope you found this post helpful. If you have any problems installing Ruby, feel free to leave a comment below or contact us.