Hey everyone!
As part of my software engineering program at Flatiron, we wrapped up our first 2 weeks of the program by using Ruby, ActiveRecord (an ORM framework) & OOP principles to build a Command Line Interface (CLI) application.
I love games, so I decided I'd use my rudimentary knowledge to scrap one together. I soundboarded my idea with some of my peers at Flatiron and came up with the idea for Town Hall Brawl.
'Town Hall Brawl': A probability game with elements of randomness (both in the mathematical and metaphorical sense).
Never having built a CLI before, my first step was to plan!
My thought process from a top level was:
1) Establish a user story
2) Plan out the Ruby objects (classes) I would need to accomplish my user story
3) Establish the relationships between classes and leverage the ActiveRecord framework to make the connection between my ruby classes and my SQLite database so data could persist
4) Bring in any external resources (gems) I might need to finish the project
5) Actually start coding (tracking my process with git hub)
6) Test, refactor, and test some more!
User Story
- As a user, I want to start a game with a blank score and base
- As a user, I want to be able to see a list of citizens who have initiatives to make an educated guess
- etc.
It helped me create real deliverables to structure the CLI around. Definitely something I will be doing during my future projects.
Plan Out Classes
From my user story, I realized I would have 4 main classes:
- A Citizen Class (would brawl with each other)
- An Initiative Class (would be tied to many citizens)
- An Advocacy Class (the association for Citizen and Initiative)
- A TownHallBrawl Class (for managing the game)
Establish Relationships
Active Record does a lot of work for you in terms of making a database connection so you can store instances of your classes, but it also generates setters/getters and a bunch of useful methods. However I needed to make sure that I was establishing the right kind of relationships between Citizen, Advocacy, and Initiative
Citizen has many Advocacies
Citizen has many Initiatives through Advocacies
An Advocacy belongs to one Citizen
An Advocacy belongs to one Initiative
Initiative has many Advocacies
Initiative has many Citizens through Advocacies
Recognizing this was super helpful when writing my ruby classes, because ActiveRecord has very specific macros that would prevent you from having to write CRUD (Create, Read, Update, Delete) methods.
Bringing In External Resources
Besides ActiveRecord, there were a couple really helpful gems. You can see the full list in my git repo for this project! Doing research beforehand saved me a lot of time (especially the tty-prompt gem, which took care of a me having to write awkward menu selection statements).
Actually Start Coding
We had approximately 3-4 days to build our application out, so eventually I had to start typing things. I wrote the application method by method, using binding.pry to test all my classes and methods incrementally.
Test, Refactor, and Test Again!
I definitely did not write the most efficient code the first time through (and it probably could still be improved). I constantly had to go back and refactor. Sometimes I realized ActiveRecord had built in methods that I was trying to code out myself. Other times I was creating variables or storing information and not re-using it. Testing was super important to make sure my CLI wouldn't break if I used it in weird ways.
My Overall Experience
This was a super fun project to work on, and it was a huge challenge for me. I learned a ton, and I can't wait to apply the stuff I learned at future hackathons or other projects.
It was incredibly satisfying sharing my application with other people and hearing them laugh and get into the game.
I'd love to get your feedback! Please feel free to clone TownHallBrawl and let me know what you think:
https://github.com/shawnhuangfernandes/ruby-project-guidelines-seattle-web-100719
Cheers,
Shawn Huang Fernandes
Top comments (0)