Building My Studio Ghibli CLI Application

The following summarizes the 3 phase process through which I was able to build my CLI program from beginning to end. 


Project Planning


During the initial project planning mode, I had some difficulty coming up with a project that would meet the project requirements and be unique to me. After some mulling about, I initially set my heart out to build a program that gives the user information on local bakeries with the best croissants in San Franciso. I found a pretty good site to scrape and got to coding out my scraper and was able to tell it to retrieve all the necessary data for my program. Setting up the scraper was not as hard I had imagined, considering the scrapeability of the website was quite good. However, I soon realized that writing a CLI that pulled its data from a scraper would be risky since the website would most likely change between the time I finished my project until my review. That would inevitably cause my code to break and then I’d have to adjust my code during the review and I didn’t want to do that, so I began looking for alternative options. I decided I wanted to pull my data from an API instead since they don’t tend to change as often. I went to public APIs on GitHub and began scrolling through the list of APIs and clicked the first thing that caught my eye which was the “Studio Ghibli” API. I am a huge fan so I began working on it right away. 


Project Building and Refactoring


Building my project took me about a week. It felt a little daunting writing a program completely from scratch. However, after running gem bundle to get my project’s file layout going, I had some good ideas on where to begin. I began by writing some notes on which classes I thought my program would need and what I wanted their functionalities to be. I separated the functionalities into groups of essential and non-essential. In the end, I decided that it was essential for my program to print all the information in a legible manner, for my CLI to successfully loop the program until the user was ready to exit, and to also print an error message for unknown input conditions. I knew my API class would be extracting the data I needed for my program and also that I could specify what data I wanted. I implemented the gem ‘httparty’ to extract that specific data. I also knew that I needed a `Film` class and a `CLI` class. The `Film` class would take in the data extracted, then converted to a hash through the `API` class and iterate through it to return in a more presentable fashion for the user. Setting up my `Film` class was a breeze in comparison to the `CLI` application. I think I had built so many classes through Flatirons labs that I kind of just memorized the layout of what this kind of class should look like by this point. In addition to that, its functionalities were relatively simple printing methods. I had more ideas in terms of functionality for this class that I wanted to implement such as printing a “pretty menu,” with all items listed neatly into two rows and a sorting method. However, I wanted to build the bare bone structure first with hopes that I could get to the “nice to haves,” once the core functions were built. After building the `Film` class I began building my `CLI` class. I didn’t know where to began so I referenced the “Kickstarter” lab to gain some inspiration. Looking off of the “Kickstarter,” lab I then started by writing welcome messages. Then I knew I would need a loop to start the beginning of my program and to provide the opportunity for the user to be able to exit the loop/program when ready. I had some issues setting up a loop that did what I wanted to and I could not for the longest time figure out where was the best place to put it. In the end, I figured it out by placing A LOT of binding.pry in places where I wasn’t quite sure what was happening in the code. Learning how to force myself to actually understand what each step of my code was actually doing has been the most frustrating for me. Unfortunately, I have a bad habit of feverously trying out a bunch of things until I happen to stumble across something that works(or not). Ultimately, by placing binding.pry and reading the documentation on the methods I implemented, I found it incredibly helpful in terms of debugging. My end result is not pretty but it does what I want it to. I plan on going back and refactoring, once I get a better hang of how to elegantly implement nested loops. 


The main takeaways from this project was that it was super fun and satisfying to build something of my own and it helped me realize some instances where I was adding too much code or overcomplicating things, then learning how to simplify and make it as DRY as possible. Hopefully, as I look back on this project in the near future, I will be able to refactor the code in an organic manner and make it cleaner and more legible. 



                             ! !       ! !          
                            ! . !     ! . !          
                               ^^^^^^^^^ ^            
                             ^             ^          
                           ^  (0)       (0)  ^       
                          ^        ""         ^       
                         ^   ***************    ^     
                       ^   *                 *   ^    
                      ^   *   /\   /\   /\    *    ^   
                     ^   *                     *    ^
                    ^   *   /\   /\   /\   /\   *    ^
                   ^   *                         *    ^
                   ^  *                           *   ^
                   ^  *                           *   ^
                    ^ *                           *  ^  
                     ^*                           * ^ 
                      ^ *                        * ^
                      ^  *                      *  ^
                        ^  *       ) (         * ^
                            ^^^^^^^^ ^^^^^^^^^

Comments

Post a Comment

Popular posts from this blog

Why Did I Decide to Choose Software Engineering

I guess one could say my interest in software engineering is an a-typical one. I didn’t go to college for computer science and was never very interested in data or math. Subjects, in which I find many software engineers to be either very good in or at the very least interested in. I studied communications and have worked in the service, marketing industry, and as of recently early childhood education. My professional background has jumped from all kinds of different industries and they were all mostly non-technical roles. I moved back to the bay area sometime in 2018. Well, San Francisco specifically. The Meca, if you may, of all the next great applications, tech, and the home of many budding and senior software engineers.  So it came as no surprise when I eventually landed a job in tech as a marketer. I worked in a co-working space and during this time I met so many amazing people building their own apps or working for small start-ups, who were either in the midst of building...
Read more

Navigating Stateful and Stateless Components in my Final React Project

For my final react project I built an app that lets the user search for a specific dog breed and renders a page that displays different information and pictures about that specific breed of dog. The data displayed from the app was persisted from an external API. Utilizing react and redux for this project was definitely a learning curve considering there are noticeable architectural and contextual differences between React and Javascript. I’ll dive deeper into some of those differences below.  Components  One of the key differences between vanilla JavaScript and React is components. Whereas in vanilla JavaScript views would’ve been used to represent different pages, react uses components to both encompass logic such as fetching data and display HTML on the User Interface through render methods. That means components can handle primarily frontend actions and some (would have been backend) actions in a vanilla JavaScript application. In my application, I found the best and most s...
Read more

My Rails App

Building my rails app was in many ways a lot harder than I thought it was going to be and in some ways a lot easier than my previous sinatra app. Rails made it so easy to initiate the project through its readability, simplicity and copious easy to use built in methods such as “form_for”, “current_user”, “.build”, “.valid?” and more. Instead of having to code the logic for these methods I could just use these readily available methods that come with rails and active record.  One of the issues I ran into while building my app was that I was trying to piece together my project by watching different tutorials. I was running into a lot of routing issues due to that. Most of them being that a lot of the tutorials were for different kinds of apps so the logic and routing were different. An example of a routing issue I had in my routes file was that I initially kept my users and unicorns routes separate and nested my superpowers routes in the unicorns route. Towards the end of my project w...
Read more