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 where I explain more of the goals around this build be sure to check it out.
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
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) gem called 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)
- 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!
Top comments (0)