Lightening Talk Redux

On December 19, my friend, Anisha Ramnani gave a lightning talk on the implementation of sessions in Sinatra. What follows is a summary of that discussion. Please note that Anisha’s writing is italicized and mine is normal.

Last week we learned how to use Sinatra, which according to Wikipedia, “…is a free and open source software web application library and domain-specific language written in Ruby.” It’s really great because we are able to move away from primarily working in Ruby and also involve some CSS styling and HTML.

The first assignment we were given was to replicate the website emergency compliment. We were challenged to create a simple web application that generated a new compliment, color and image each time a user refreshed the site page. This led to the question: how could we write our web application to avoid the same images and colors appearing on after another?

Having just finished learning object-oriented programming (OOP) in Ruby, my esteemed colleague Anisha and I were stoked. We knew that each visit to our site would be an instance of the class Compliment. To instantiate each object, we created the constants COMPLIMENTS, IMAGES, COLORS and called .sample on each constant in the initialize method. At the very least, this ensured a random sampling for each visit to our site.

But we were only halfway there. We had to keep track of state for all of our compliments and avoid duplicates. To that end, we created a history constant, shovelling each instance into it via self in our initialize method. Armed with a record of each compliment, we thought we could avoid dups by comparing the index value of the last compliment (HISTORY[-2]) with each initialized compliment (HISTORY[-1]).

In order to check duplicates, we created a method called self.check_duplicates that compares the second to last element in the history array with the most recent element in the constant HISTORY array. While the colors for the most recent compliment and the previous compliment were the same, we would initialize a new complement color to replace it until the colors were different.

We soon realized that even though this method worked within Ruby, we could not use this same logic in Sinatra. The class was not remembering the history when it was run in the sinatra app class. This is because once the page was refreshed, the logic was forgotten.

The idea of state within the newer, more expansive parameters of a Sinatra web application took us completely by surprise, but left us intrigued. How could we avoid those pesky dups? With a little help from our teacher and classmates, we stumbled upon the idea of sessions.

Sessions, like cookies, store information about a user’s interaction with a web app, and programmers can define which variables a session stores, such as the last color displayed on a page.

The first thing to know about sessions is that you must explicitly enable them in your app. Easy enough, just add ‘enable :sessions’ right after you define your class. Second, sessions store data in hashes, so you read and write their data as key-value pairs. That’s basically all you need to get started.

To implement sessions in our logic, we used an if/else statement to check whether a session key existed. If not, we instantiated a new compliment and set the session key color equal to that compliment’s color. With the session key, we were now keeping state (at least for the variable compliment color) for each user’s first visit to our site.

In the else portion of our logic, for each successive visit, we instantiated a new compliment and compared its color with the value of the last session via a while loop. So long as the last session color matched the new compliment color, the logic reset it by sampling the COLORS constant in our class.

We then set the session[:last_color] to the compliment color, so that we can use this method for the following instances of the app class.

Presto! We had solved the mystery of keeping state in the Sinatra Application. 

This intel on sessions leads to the grand question: why does it matter? Sessions matter, because they serve as a way to store information in web applications. The example base case can be applied to other web applications where we need to be able to store information of a particular instance of a website.

Keeping state in your web applications is fundamental to how the internet works. Each time you visit an e-commerce site, it’s sessions that keep track of the items in your shopping cart. Without them, your cart would be empty each time you visited a new page.

So through the simple concept of creating a compliment page, we were able to learn more about sessions! Our page was able to work successfully, and we hope to continue to apply the sessions logic elsewhere.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s