Cli with Ruby — My first App
Last week I developed first app — a CLI application using Ruby. While not much, I was proud I was able to develop my first project under such a short amount of time.
The Happy Trails app was built in my third week in Flatiron School’s software immersive program. The majority of the project was built with a partner, where we worked on our pair-coding techniques together. Pair-coding is a technique used which tries to combine both coder’s brain functions simultaneously (one partner is the driver while the other directs). Below is a short summary of the techniques we used in our project and some of the things we learned along the way!
Backend Setup
Our project was required to have a many:many relationship. To do this, we created three Ruby files for our model. Being a hiking app we formed: a hiker class, a trail class and a review class. Within our models, Hikers and Trails have many reviews through each other, making the Review class belonging to each and is the join relationship. We developed our schema using ActiveRecord and Rake commands. Our schema maintains attributes related to each class (hiker: name, age…; trail: length, elevation, location…; review: rating, comment, and ). After migration, we seeded our database manually. As I keep progressing with BE development, I’d love be able to tap-in to a public API for this project.
Frontend Design
Happy Trails’ front-end application is designed in a primitive form of programming. The code was written in a Ruby file stored within our models (cli.rb). A runner.rb file is the executable form of the program and calls some of the methods used in our app. The user is welcomed with a banner, which is formatted using a TTY prompt. TTY prompt was a Ruby gem we were able to tap-into for some of the aesthetics of our app. Aside from the banner, the user is also greeted with voice message:
system `say "Welcome to the Happy Trails USA app! Please enter your name:`
The system say functionality was one of the coolest features we were able to use with app and really impressed our classmates. No gem was required to run the command, as “system (say)” is a built-in, out-of-the-box Ruby function. It works with any word and also with interpolation!
After the user is welcomed to the app, a series of case statements are designed to walk the user through their hike options and information on the hikes. Most of the menu options were used using TTY Prompt commands. After a hiker selects a trail, an ActiveRecord function pulls out information regarding the trail, using:
Trail.find_by name: trail_answer
The hiker can view the trail information and the connected trail reviews. This design implements the Read functionality of CRUD (create-read-update-destroy. The user is able to create a new review for the trail, but unfortunately the user’s changes do not update the system. As I progress through my program, it’s becoming easier and easier to execute the update and destroy designs of CRUD but my partner and I ran out of time to implement these into our app. I plan to go back and add these features into our app soon!
After leaving a review for the trail, the user is prompted to exit the app. An exit point is left for the user throughout most menu options of the app, by using the exit! command through Ruby.
Final Thoughts
Building a CLI app is a good starting point for any aspiring programmer. While it took SEVERAL burns, as the week went on, it became easier-and-easier to design our backend with ActiveRecord and rake commands. After our BE was finalized, I always suggest starting very small for the CLI commands, to ensure the app is functioning how you envision. After that, you can continue to grow your app through thin, vertical slices. Happy Trails and Happy Coding!
