Green Light: Combining Software, Television, and Film Development

Claire McCleskey
5 min readJan 10, 2021

--

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:

From L-R: landing, add script, and list pages without CSS/additional 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:

From L-R: landing, add script, and list pages with Materialize + additional custom CSS.

Where to Find & How to Use Green Light

Demo video of Green Light in action

You can find the GitHub repository for the project here. Please reference the README file for instructions on how to run.

--

--

Claire McCleskey
Claire McCleskey

Written by Claire McCleskey

Software Engineering Student @ Flatiron School by day, TV/Film Script Analyst by night. NYC via FSU.

No responses yet