Since starting at Varvet I’ve discovered two things — I love pingpong and so do my co-workers. Maybe not to the same extent as me, but still. I’ve never considered myself the competitive type, but when it comes to pingpong, I have to admit, I do enjoy the occasional win and the admiration of my co-workers. So I combined my love for Ruby and this game and made a web app to help us determine, once and for all, who really is the office champion!
I set up the project as I would a real client project. I used Pivotal Tracker to keep track of what had to be done and for estimating the time it would take. This proved to be a somewhat difficult task. Since I had very limited experience of Ruby I had no idea how long anything would take. I gave it my best guess and with time the estimate adjusted to my speed.
Being a frontend developer, I struggled a lot with database construction. Wrapping my head around that felt like being smashed. Pun intended.
What Wiff Waff does is that it allows you to create players and save games between said players. This means a player can have many games, and games have many players. So it’s a many-to-many relation? Yes, but it turns out there were a couple of different ways to go about building this particular database.
A player can always have many games. However, I know for certain that a game will always have precisely two players.
class Player < ApplicationRecord has_many :games_as_player_one, class_name: "Game", foreign_key: "player_one_id" has_many :games_as_player_two, class_name: "Game", foreign_key: "player_two_id" end
class Game < ApplicationRecord belongs_to :player_one, class_name: "Player" belongs_to :player_two, class_name: "Player" end
You could also argue that a game can have many players and that it doesn’t matter whether it’s as
player_two. Say you wanted to add the possibility of recording double games, then this might be a reasonable approach, assuming that you limit the number of participations per game to 2 for singles or 4 for doubles.
class Player < ApplicationRecord has_many :participations has_many :games, through: :participation end
class Participation < ApplicationRecord belongs_to :player belongs_to :game end
class Game < ApplicationRecord has_many :participations has_many :players, through: :participations end
I decided to go with the first one, with the belongs_to/has_many association between Players and Games, since I didn’t want to make the first version of the app overly complicated. Also, because of the rating system, it would make more sense to let each unique pair combination in double games to be seen as one player, ie. “LouiceJens” vs. “MickanJovan”. Then that rating would not affect the single player rating.
What did I learn?
Initially I had a list of things I learned that I wanted to mention. It looked something like this:
- database: relations, associations, migrations
- capybara test
And maybe I should have written something about the factual knowledge I acquired here, but to me that’s the least interesting thing about what I actually learned.
It wasn’t always a smooth ride. Besides the challenge of learning a new language, I also took a long and hard look at myself and my idea of perfection. This project has given me a chance to practice being comfortable with not knowing beforehand how I would go about every step, but trusting that I’d learn along the way.
It’s starting to sink in that this is what it means to do what I do. It is being curious about what you do not know and sharing with others what you do. It is constantly pushing the boundaries of one’s knowledge, evolving, improving and refining one’s manner of thinking and problem solving.
It is not, however, about perfection.