Let's Build for Ruby and Rails developers - Part 2
Tags: ruby, rails, product, community
Published: 2020-07-28 15:22:49

---
title: Let's Build for Ruby and Rails developers - Part 2
published: true
date: 2020-07-23 14:00:00 UTC
tags: ruby, rails, product, community
canonical_url: https://web-crunch.com/posts/lets-build-for-ruby-and-rails-developers-part-2
---

### Data modeling and gem overview

Welcome back to the second part of my series I'm calling "Let's build for Ruby and Rails developers".

This series is a complete behind the scenes guide to building a production worthy rails application designed to help both Ruby and Rails developers find jobs, meet other developers, and keep the Ruby and Rails community going strong.

If you missed [part one](https://dev.to/justalever/let-s-build-for-ruby-and-rails-developers-2g1) where I explain more of the goals around this build be sure to check it out.

{% youtube VjPqa0eZZgo %}

## Data modeling

Before diving into any code I wanted to take a step back and create an outline of what type of data I predict we need inside the application.

The app itself will of course be a Ruby on Rails application. From there I wanted to think about the different use cases for a user in the app as well as some characteristics of a job or community posting.

### The User model

A user model will have fairly plain characteristics besides a few boolean properties that are core to making the application work as advertised. We'll be using [Devise](https://github.com/heartcombo/devise)  
for authentication and possibly some omni-auth as well.

I didn't mention it in the video but I think for developers to sign in with Github might make more sense than Google or Twitter if I get that far. We shall see.

For the User model, I anticipate having only a handful of fields at first. I mentioned in the video not being sure if I would use an entirely different object for both Developers and Employers but I think I've decided to keep a generic User model with boolean properties for employers and admins only. If both of those properties are false then it defaults to a developer user role.

- first\_name: - `String`
- last\_name: - `String`
- email: - `String`
- admin: - `Boolean`
- employer: - `Boolean`

This list assumes the additional fields provided by Devise will be present as well.

### The Job model

- title: `String`
- link\_to\_apply: `String`
- description: `RichText`
- company\_name: `String`
- company\_website: `String`
- company\_logo: `ActiveStorage`
- company\_headquarters: `String`
- company\_description: `RichText`
- role\_type: `String`
- compensation\_range: `String`
- remote: `Boolean`
- years\_of\_experience: `String`

### The Community

For the community, I don't think we need to reinvent the wheel. I'll likely lean towards Chris's (the creator of [gorails.com](https://gorails.com)) gem called [simple discussion](https://github.com/excid3/simple_discussion). That should take care of our modeling for the community side all in itself.

### Newsletter

As the app progresses I might revisit the newsletter. We may need a subscription model of some sort so users can subscribe or unsubscribe to different digests I might send out dynamically. This is all up in the air but it's a decent way to promote the site more and make it easier for those looking for jobs to get notified about new listings.

## Gems

I made a list of gems I think we'll make use of. This list will almost certainly change but most of these are fantastic. I go over each in more context in the video.

**Core**

- Devise (auth)
- Sidekiq (background job queuing service)
- Whenever (Cron jobs for the win)
- Stripe (Charge with Stripe)
- Stripe Event (listen for Stripe events)
- Pay (payments with Stripe and Braintree)
- Pagy (fast pagination)
- aws-sdk-s3 (active storage)
- image\_processing (active storage)
- inline\_svg (rendering svgs from file)
- Honeybadger - (error tracker)
- Redis (for all the redis things)
- pg (PostGreSQL)
- sendgrid-ruby (hook up email sending service)
- name\_of\_person (cool gem for working with names) ([https://github.com/basecamp/name\_of\_person](https://github.com/basecamp/name_of_person))
- FriendlyId (make slugs more human)
- OmniAuth - Google/Twitter (Login with Google and Twitter with Devise-omniauth)

**Development:**

- faker (generate fake data for tests or seeds)
- pry-rails (useful for debugging)
- annotate (adds comments to models for reminders about the database design)

### Coming up next

With this list somewhat complete I think the next step might be to start getting our hands dirty. We'll kick off a new app and get it optimized for the work ahead. I'll see you in part 3!