DIY Doom index is a project I made while at The Flatiron School’s web development immersive. DIY Doom Index allows users to sift through daily political, economic and environmental datasets to build a personalized Doom index. Similar to how the S&P 500 or Dow Jones stock indices aggregate multiple companies’ stock performance into one number, DIY doom index aggregates a number of different “pro-doom” and “anti-doom” metrics into one over-all doom number. Users build a single index that tells them how much better or worse the world is everyday based on their political, economic, and environmental sensitivities. You can use the app here (It’s hosted for free on Heroku and may take a few mins to load, try refreshing if you get an error). The code is on my GitHub and I made a video demo you can checkout. In this series of posts I’m going to go over how I made DIY doom index and suggest some areas for improvement. In this post I’m going to cover how I calculated the index to give each user a personalized experience.
Calculating the index
All of the API calls and index calculations happen in the Ruby on Rails backend. This helps avoid CORS related errors and allows me to quickly load updates as the user adjust their doom preferences.
Model
My ActiveRecord / Postgres model was comprised of Users, User-datasets (a join class), and Datasets.
Users (diy_doomsday_backend/app/models/user.rb):
class User < ApplicationRecord
# Adds methods to set and authenticate against a Bcrypt password
# requires "password_digest" in user schema/migration
has_secure_password
# sets up relationships
has_many :user_datasets
has_many :datasets, through: :user_datasets
#!!! add additonal validation
end
This class is fairly simple, it sets up the relationships the other database tables and invokes has_secure_password
which utilizes the bcrypt gem and allows my backend to store user authentication details without saving plain text passwords to my database (more on authentication later). The other classes are even simpler. I just set up the relationships and didn’t do any real validation in the backend. This is certainly an area where the app could be improved. When building the front end, I structured the various requests and forms to validate most of the data before sending it to the backend. These classes could be reworked to make the API more resilient, secure and usable with other front end apps.
User-Datasets (diy_doomsday_backend/app/models/user_dataset.rb):
class UserDataset < ApplicationRecord
# sets up relationships
has_many :users
has_many :datasets
end
Datasets (diy_doomsday_backend/app/models/dataset.rb):
class Dataset < ApplicationRecord
# sets up relationships
has_many :user_datasets
has_many :users, through: :user_datasets
end