Photo by dusan jovic on Unsplash

Making It Real

My coding journey continues. The mechanics of Ruby, the basics of object relationships, and how things work under the hood are slowly becoming abstracted away into larger frameworks and libraries. I had a blast building a CLI app for my first portfolio project, but as I began working with the Sinatra framework and getting a taste of what is to come with Rails, the thought that kept coming to me was that things are getting more and more real. Rather than working primarily in the terminal, I am now getting broader views of what is possible through building apps that have their own databases, models, and functionalities that extend beyond simply using the command line. After putting in a lot of time and energy into practicing the basics of Ruby, the payoff of seeing its power in action is well worth it.

So what makes an app real? In my opinion, I think it lies somewhere in how we interact with actual data. Creating my app, Access Actors, started with focusing on the back end of the project, or setting up a database using my models — actors, headshots, and auditions. I found that a lot of planning is crucial to solidify the relationships between the models and the database itself. Later, it becomes clear this is necessary for an app to function correctly. You can really spend a lot of time in the weeds of Object Relational Mapping, but fortunately for us ActiveRecord is another framework that abstracts away the details of how models interact with the database. Understanding the mechanics of different types of relationships (belongs_to, has_many, has_many :through, etc) is what allows everything to run smoothly later on. Moreover, how a user is able to interact with data and what actually gets persisted to the database is where the magic happens, so having a strong foundation on the back end is key.

Other areas that were particularly interesting as I built my app were authentication and validation. Once again, Sinatra (and Rails) provide excellent options that are easy to use and ensure user data is protected. Here’s an example of how to set up a user class that uses some of these tools:

class User < ActiveRecord::Base
  has_secure_password  
  validates_uniqueness_of :name, :email
end

The first line of code checks that a new user signs up with a valid password before an object is saved to the database. The second line of code checks for any matches of the name or email attributes in the database and prevents the object from being persisted if they are present.

Next, using session cookies and checking authentication allows you to secure views and routes throughout your application. Here are helper methods I used to make this happen:

helpers do
 def logged_in?
  !!session[:user_id]
 end
 def current_user
  User.find(session[:user_id])
 end
end

There are many more layers of security worth checking out (and certainly a lot more to learn about), but these are a few relatively simple ways to add logic within your models and routes to protect the integrity of users and data.

Feel free to check out my Access Actors app on GitHub. As things continue to get more real and my applications expand to include more capabilities, the excitement of getting to build keeps growing as well. I can’t wait for the next chapter in this journey — Ruby on Rails!