Green Light: Combining Software, Television, and Film Development
Before making the jump to software, I worked in entertainment. Many of the jobs I had involved the development process — reading scripts and pitches, finding ways to improve them, and deciding if the writer or script should be represented or produced. I loved this part of the job. So much in fact, that I still work as a freelance script analyst providing notes, or coverage as it's called in the biz, for writers, producers, and screenwriting competitions. One problem that I’ve encountered is that it can be difficult to keep an efficient running list of each project I’ve read, my recommendation for it, and the notes I gave it. I’ve looked for a tool to do this, but nothing out there was made specifically for keeping track of script coverage. But as we studied our unit on Sinatra and ActiveRecord, I began to realize that these tools could help me build the app myself.
What Does Green Light Do?
Having looked for an app that was specifically built to track script coverage, it was easy to create my functionality wishlist. I wanted the app to have users who could create, save, edit, and delete entries for each script they read and the ability to view their current list at any time. For each entry, I wanted to focus on the key elements of script coverage — the title, writer(s), when it was read, recommendation, and notes on the script.
Behind The Scenes of Green Light
Green Light was built using Sinatra and uses ActiveRecord to maintain databases. The program has two models — scripts and users. These models are tied together via has_many
and belongs_to
: a user has many scripts, and a script belongs to a user. Within my Script class, I used validates_presence_of
to ensure that a title, writer, date, and notes must be included to submit an entry. Within my User class, I used validates
to ensure there is a unique username and has_secure_password
(via the bcrypt gem) to confirm that the password is secure. Within my controller files, I used the RESTful routes of GET
, POST
, PATCH
, and DELETE
to create, read, update, and delete data. Admittedly the PATCH
and DELETE
routes for editing and deleting were the most challenging part of this project. While GET
and POST
routes do not need anything extra, PATCH
and DELETE
are not able to be processed by browsers without some additional coding. To address this, I made sure to include use Rack::MethodOverride
in my config.ru
file and created a hidden
input type with a name of _method
and value of delete
or patch
, which Rack::MethodOverride
would then be able to process appropriately. Using these routes, entries can be saved to a database via ActiveRecord. And finally, sessions are enabled to keep track of the current user and control the ability to log in and sign up.
From Script to Screen, From Data to Display
Like a script needs to be filmed, data must be displayed. To do this, I created several views (essentially pages) for each purpose that needed to be addressed:
- Welcome — The home page. Greets the user and explains the purpose of the site. Also provides additional links beyond the navbar to the login and sign up pages so that users can’t miss them.
- New — Creates a new entry.
- Show — Displays the data for one particular entry, interpolating the correct data based on the
id
of the entry. Will not allow users who did not create the entry to view the show page for the entry. - Index — Displays a table of the current user’s entries. Uses interpolation to display the data appropriately for the entry, as well as iteration to display every entry.
- Edit — Allows the user to edit and save changes to a particular entry, only if created by them. It also includes a delete button. This page will not allow users who did not create the entry to view or use the edit page for an entry that is not theirs.
- Log In — Allows currently registered users to log in. Utilizes user authorization to confirm that the username exists and matches the encrypted version of the password entered.
- Sign Up — Allows new users to sign up. Confirms that the username is unique and that all fields are completed.
The controllers create routes that direct to the appropriate pages, as well as ensure that pages cannot be seen by unauthorized users (i.e., cannot see a list of scripts if not signed in, cannot sign up if already logged in, etc.).
On-Screen Magic: Making Green Light Look More Aesthetically Pleasing
Just like movies rely on make-up, lighting, and special effects to make them look their best, Green Light too must use a few tools to make it look camera-ready. Take a look at what Green Light would look like without any CSS or other formatting:
Luckily, CSS and Javascript exist. Even better — Materialize exists. Materialize is a responsive CSS framework that makes building a design for your application or website — like Green Light — that much easier. It has tons of useful CSS and Javascript tools to customize to your liking. Using Materialize and a bit of custom CSS, I was able to turn the above into the below:
Where to Find & How to Use Green Light
You can find the GitHub repository for the project here. Please reference the README file for instructions on how to run.