Tropiary

In retrospect it seems fitting that I picked novels and novel-writing as the subject matter for my Sinatra project, because I have a tendency to let my imagination run away with me in the process of writing fiction, and so too has the project.

In my other life, in my free time, I write fiction. Usually genre fiction but not always, often novels but not always, and I keep track of all these projects in a couple of different spreadsheets. I used this information to create three different models to use in my MVC application: a novel model, owned by a user and containing several different attributes as well as many character models, each of which has its own array of trope models. A trope, as used here, is a shorthanded narrative device that is repeated often enough to enter public reader or viewer consciousness, often tied to genres but not always. The frantic rush to make a last-minute love confession, usually at an airport or wedding, is a romance trope. The moment when the last heroes standing believe the monster is dead, only to have it rise up one last time, is a horror trope.

Originally I had it in mind to assign the relationships thusly: a novel has many characters, a character has many tropes, a novel has many tropes through characters, and tropes belong to characters while characters belong to novels. Halfway through writing this I remembered that the assignment was also to create a user class and apply sessions, login/logout functions, etc. Easily enough fixed, a user could have many novels.

Overall the project was refreshingly simple, despite the number of moving parts I had to shuffle around. Models, views, and controllers fall into the category of computer logic that I learned at a very young age: to put it into Logo terms a model is the turtle, the controller is the series of commands used to move the turtle and instruct the turtle to generate the content one wants, and views are the colors you can change the turtle. (I believe Logo is now taught in schools as MicroWorlds.) The application did not have to be this complicated to fulfill the requirements of the project, but I enjoyed expanding it to this degree both because I enjoyed the process and because the repetition reinforced the knowledge for me.

I will admit that towards the end of the project my ambition nearly got me. Once I had all the model interactions functioning properly in their controllers and the styling was done to my satisfaction I decided to add a description field and attribute to each model: Trope, Novel, and Character. The novel and character descriptions coded simply, but probably owing to a need to put the code down and go to bed I accidentally coded the patch action to receive input and code it all into the Trope class rather than a specific instance of the trope class. Suddenly, instead of adding a summary of the “There Was Only One Bed” comedy trope to its name, I had turned all of my tropes into that one. The irony of there now being Only One Trope kept me giggling while I found my error and fixed it. Lesson learned: after a certain point no matter how energized I am by my success at coding it’s time to go to sleep and finish it in the morning.

The main conclusion I drew from this project, apart from enjoying it thoroughly and being comforted that a career in web development is probably the right one for me, is that computer logic is a specific kind of sub-language unto itself. Knowing intuitively how the model-view-controller application works, how each part connects to the other and mainly getting hung up on issues of syntax is a skill set akin to being fluent in Spanish or Japanese. As such, it is varyingly difficult to learn but once you become fluent in it, it becomes much more comfortable to code and debug.