Wiff Waff - My Journey on Rails
One year ago I came to Varvet as a student. I was studying frontend development at YH, which is Higher Vocational Education or Yrkeshögskolan. It’s a post-secondary form of education where a significant part of the education is an internship. I had the pleasure of doing mine here for 7 months. I focused mainly on JavaScript then, but towards the end I dove deeper into Ruby and felt a strong attraction to this elegant language. When I graduated in May I was hired as an apprentice, and one of my tasks has been to do a project of my own. Of course I chose to dive even deeper into Ruby.
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.
Challenges
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.
1)
A player can always have many games. However, I know for certain that a game will always have precisely two players.
player.rb
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
game.rb
class Game < ApplicationRecord
belongs_to :player_one, class_name: "Player"
belongs_to :player_two, class_name: "Player"
end
2)
You could also argue that a game can have many players and that it doesn’t matter whether it’s as player_one or 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.
player.rb
class Player < ApplicationRecord
has_many :participations
has_many :games, through: :participation
end
participation.rb
class Participation < ApplicationRecord
belongs_to :player
belongs_to :game
end
game.rb
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:
- enumerables
- validation
- database: relations, associations, migrations
- mvc
- capybara test
- heroku
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.
Comments