My First CLI Application
It’s week 3 at Flatiron School, meaning it’s the last week for the first module, also meaning it’s our first PROJECT WEEK! Time to put what we’ve learned to the real test.
So far in Mod 1, we’ve learned Ruby, Object Oriented Programming, relationships, and working with databases (via SQL/ActiveRecord). For this project, we partnered with a classmate to build a Command Line Interface (CLI) application that demonstrates what we’ve learned, interacts with a database, and has at least four defined user stories. These user stories had to meet each of the CRUD functions:
- Create
- Read
- Update
- Delete
After brainstorming with my partner, Haleigh, we agreed that we wanted to do something fun and light-hearted. We eventually landed on the idea of “JokeBox,” a simple CLI application where users can submit, discover, and rate quick laughs.
We began the project by discussing what we wanted the user to do with the application. To reach minimal viable product (MVP), we decided that we wanted a user to be able to create a joke, edit and/or delete their joke, read other users’ joke, and be able to rate random jokes. We thought of other ideas we wanted to incorporate, but wanted reach MVP so we knew that we had a product to present by the due date. From there, we decided to tackle our stretch goals of incorporating an API, enhancing the user stories, and pretty-ing up our application.
Haleigh and I collaborated pretty well and worked together to get through writing the methods for each user story pretty quickly. When it came to the actual structure of the application itself, we realize that we had too many stories to operate on just one menu. We decided to have two separate menus so the available user tasks didn’t look too overwhelming on one page. While completing pre-work prior to attending Flatiron School, we had some exposure to creating CLIs, using case statements, and obtaining user input. With this project, we had to take a deeper dive into this process. We incorporated do-while statements in conjunction with case statements to get are two menus working together.
By day 3 of project week, we were able to get through to MVP, as well as tackle many of our stretch goals. As part of a bonus goal for the project, we decided to incorporate a free API. This was our first time working with APIs and had a brief overview on how to work with them. Haleigh was able to locate a great Jokes API online, but it was not aligning with our initial structure of our database. Since we had extra time, we decided to go ahead and restructure our database in order to use this API. Wow, this was a tough task to tackle!
First step, we had to rename one of our columns that held the actual jokes, as well as add a new column that added a punchline to these jokes. Once we did that, we had to tackle using JSON for the first time in order to incorporate the API. Luckily, we were able to download the actual JSON file and add it into our directory as oppose to using a URL link to retrieve it. However, it was still a task in order to link the directory correctly, parse through the file, and incorporate the information using the correct hash keys. Eventually, we were able to get it to work! However, we now had to go back into our code to make sure we made adjustments to our new column name, as well as add code to include our new column to the delivery and creation of new jokes. While it was tough to go back, it was definitely worth it.
Going through the code again, it help us realize that we could have organized thing better as we were going through the different files. We were having a hard time finding the different user stories as we were just building things as we were going. It taught us to be organized for any of our future projects from the start. Also, we were able to see a lot of code that was repeating so it gave us practice in refactoring our code and try to follow the single responsibility principle with programming.
One of the final things I helped add to the project was our goodbye message when a user quit the app. I spent a lot of time trying to incorporate ASCII art, but was having a lot of trouble with some of the characters not showing up when we ran the program. Most of them were caused by backslashes (“\”) thinking they were trying to escape characters. Therefore, the art was showing up funky on the screen. I was playing a lot with the code and was able to finally land on a way. I created a .txt file with the ASCII art and created a method that would read the file as a variable and then “puts” that variable.
This project had many learning experiences with finally building my first program. It definitely reinforced what I learned the last three weeks into one application, while also teaching me new things at the same time. Early in the project, I would say that I would be writing a code somewhere as a placeholder, but as we wrote more and more code, it would get more and more disorganized. Through our struggles of incorporating an API and then having to really revamp a lot of our code, it taught me how important it was to stay organized. Through this project, we also started to use GitHub for the first time for version control. Boy, that was a struggle on its own. Though we were able to get through it, there’s still a lot of learn with it for future projects.
Now with Mod 1 and this first project under my belt, it’s time to tackle Mod 2! Time to get back to labs! :)
