Designing an app is an opportunity to explore strange new worlds and boldly go where no one has gone before. But before you set off into space, you need to create some boilerplate code. The initial setup of an application can be daunting and tedious, but it’s necessary to get your app up and running. So how do you go from idle to warp speed in development? Ruby generators! Ruby on Rails provides an extensive list of generators that will write core application functionality code for you. That means development will be faster and more consistent, and you will not need to worry about memorizing repetitive code. This is a powerful tool for any Ruby developer.
Movies have always been a big part of my life. Before starting my journey to become a software developer, I worked on film sets and held positions with Chicago-area film festivals. As part of this work, I had the opportunity to learn the art of film projection. While doing so, I discovered the importance of the craft and why film preservation is so important. I also noticed that the industry lacks a formal inventory and tracking system for the film prints held by collectors, theaters, and film preservation organizations worldwide. For my second Flatiron portfolio project, I decided to create a film print management app that allows users to sign in, create records of their film prints, view their film collection, and update and delete films when necessary. Both registered and unregistered users can view the collections of others.
As I sit here at my computer desk, with my Baby Yoda figurine watching over me like an encouraging mentor, I think back on the process of creating my first portfolio project for Flatiron and for my new career. It began with an idea that became another idea that became another idea….well you get where I’m going. Project planning is a mountain in itself, and I was determined to climb it no matter how long it took me. When I discovered the Dungeons and Dragons API, I immediately knew I could create a fun and rewarding CLI from the data.
I wanted to create an application that would display different Dungeons and Dragons (D&D) character options and give the user enough information to create the most epic character. I originally wanted to go many levels deep and return all the data on character creation. I have never played D&D, but I have played enough role-playing games to know that would be a daunting task. I started thinking in terms of MVP (minimum viable product) and decided to start with the foundation of character creation: choosing the character’s race. My CLI returns stats on each race that the user is interested in. It is a fantastic start to my CLI.
I first created my GitHub repository and then worked on creating the essential files and folders for my project to work. Next, I created an API get request and iterated over the data so I could find the race names and display that list to the users. All of this seemed comprehendible to me until I had to verify if the user’s input was valid. My goal was to create abstract code that was not hard-coded. After much trial and error, I ended up using each.with_index() and corresponded each index with a race name. From there I could use my find_by_name method and not only verify if the name was an actual D&D race name, but I could also pass that name as a parameter for calling my second API get request. After that, it was all gravy! Well, not exactly…I often found that by changing one method I would have to refactor other methods just to make my code work again. For example, when I implemented the to_i method I forgot that the method will take a letter or word string and return 0. That led me to refactoring my code to account for a user accidentally entering a letter key. I wanted to make sure my interface worked first and foremost but also wanted concise and DRY code. I wanted it all!
Looking over my project now, I have a working CLI that is user-friendly and fun to use. Is my code perfect? Absolutely not! But that is the purpose of this course: to refine my coding skills over time. My code has come a long way. I am polishing up aspects of it and refactoring methods to make it more abstract. I know that I learned a great deal over these past few weeks. I also know that I still have much to learn, but as the older Yoda would say, “Much to learn you still have, my young padawan.”
A year ago, I never imagined I would be coding every day, let alone enrolled in a software engineering program. As long as I can remember, I’ve wanted a creative career. I wanted to walk the fine line between artist, builder, and storyteller. Naturally I was drawn to film, thinking I was destined to become a director. Early in my career, however, I discovered that I enjoyed creating through camera movement and lighting more than I enjoyed directing actors. This was the first of several career pivots I made within film. I do not regret my decade-long journey in film, and I feel proud of all that I accomplished, but until recently I have felt lost. Then I discovered the possibilities of programming.
I can’t remember how I stumbled upon coding, but I do recall that it was my girlfriend who recommended a coding bootcamp to me. I was already drawn to the technical side of filmmaking, and I have always had a passion for creativity and problem solving, so coding seemed like a great fit. After visiting several coding bootcamps, I decided that Flatiron was the right fit for me and would allow me to code while maintaining a full-time job.