SneakrFreakr Sinatra App

For our second project at the Flatiron School, we were asked to create a web application using Sinatra. Given that we had very specific requirements to meet, it was a little challenging to come up with something that both interests me and meets all the specifications. Truthfully, this project seemed way more daunting to me than the first CLI project, because of the moving parts. However, once I got started, productivity started to flow easier than I first imagined.

Requirements

The app was required to have the following:

Brainstorming

Like I mentioned previously, my brainstorming session was a little more lengthy this time around. I was originally going to create a portal for artists to display their works or post about art that they like. This idea was short-lived as browsing the web for video demonstrations to assist with my build, I stumbled across this very idea. My plan B became my plan A, and I decided to go with an app where sneaker collectors could post anything and everything sneaker related.

Set-Up

Setting up the structure of my overall project was amazingly handed to me on a plate by a former Flatiron student! The corneal gem is magical. Literally, all you have to do is install the gem by typing “gem install corneal” in the terminal, and then generate your app by entering “corneal new (app-name)”. After corneal is done generating, a quick bundle install in the application’s directory and since the MVC file structure is provided I was ready to start building.

Don’t forget to commit to Github.

Creation, Migration & Models

In order to set up my database, I needed to create tables for my two models. I am working with 2 models for this project, my users, and their posts. To ensure I was meeting project requirements I have a “has_many”(posts) model and “belongs_to”(user) model, and also that both inherit from ActiveRecord::Base.

Another vital requirement to note here is validations. Once again these are handed to you on a platter but from Active Record this time. I have used validations to ensure the presence of required data from my users in their posts, and unique usernames, shown below:

Don’t forget to commit to Github.

Testing & Seed Data

To allow for easy testing throughout the build process, I required the ‘shotgun’ gem. When the ‘shotgun’ command is entered into the terminal it allows you to see real-time changes in the web browser.

I created some seed data to get started on logging users in and viewing some pre-seeded posts.

Don’t forget to commit to Github.

Controllers

The controllers are the busiest part of the program. There are three, the Application Controller, the User Controller (which inherits from the Application Controller), and the Posts Controller (which also inherits from the Application Controller). They are responsible for handling the ‘HTTP verbs’ aka CRUD actions (create, read, update, delete), which request and receive data from the client to the server.

This portion of the project was the most challenging for me. At one point I got a little spun around with my routes and had to enlist the help of some rockstar classmates to see the things I was unable to after staring at my screen for countless hours.

This was all due to some discrepancies within my file structure and how my routes were written. One major thing to call out on this is to always pay close attention to your file paths, and that they are matching up to your routes.

Don’t forget to commit to Github.

User & Post Protection

The specifications state that Users should not be able to edit or delete the posts of other users. To make this happen and provide proper password protection you need a few things:

• To ensure the ‘bcrypt’ gem is required in the Gemfile. This provides the “has_secure_password” macro but in order to use it, you must include a column with a “password_digest” key in the users table.
• “Sessions” is enabled in Application Controller, and set session to secret.
• The password input types in forms, located in the login and signup views folders, are set to “password” and not “text”. This will offer protection to the user by preventing passwords from appearing from plain text, and instead bullets. A method to check if the current user is authorized to edit or delete the current post, shown below:

Don’t forget to commit to Github.

Flash Messages

Flash messaging sort of ties in with authorization. It will display a message to the user when certain tasks are not authorized, or successful. They can be customized to read whatever you like, and are useful to inform the user if they are missing required fields, or that the post they just created was successful.

Final Thoughts

This project was stressful but super eye-opening. It opened my eyes to what happens behind the scenes on the world wide web every single day when we log into our favorite apps like Facebook, Twitter, and Instagram.

If you would like to take a look at my repo you can find it →here←.

Thank you for reading & please don’t forget to commit to Github :)