I recently discovered a ruby gem that acts as a wrapper for the Mac Core Audio API (it’s written in C) and decided to play around with it. I started by using an example from the gem’s github repo and just tinkered until I ended up with something cool. You can find that repo here.
I was working on a project yesterday with my group when we came across a problem. We have an Answer table, Issue table, and a Comment table. We wanted to be able to comment on both an answer and an issue, but didn’t know how to set up the associations in our models.Originally, we thought of creating separate models for AnswerComments and IssueComments, but after some discussion we decided it would be good practice to create a polymorphic association.
So, what are polymorphic associations? It is when a model belongs to more than one model without using more than one association. While we may only have two models that we want to comment on right now, this allows us the freedom in the future to comment on more things without setting up extra tables.
The other day I was going through presentations on www.speakerdeck.com, a site from the same guys who created Github, and found a cool little presentation on Git branching. The presentation was by Gregorz Wilczynsky of TAPteam. The slides are demonstrations of the Git workflow model used within the company.
I really like how they standardize the naming of branches so that each developer knows not only what each feature branch is for, but who it is by. They do this by prefixing their branches with their first and last initials, then by naming it after the feature they are working on. This also helps know who deleted the branch.
They also make use of another practice in Git that I believe really helps get rid of some clutter and headaches…deleting local branches that are tracking remote branches which have been merged. This seems like common sense, but sometimes when you’re working on many different features common sense gets harder and harder to recognize.
Aside from the features noted above, there are still things that you can do that will not only help you with Ruby variables, but also make your program more comprehensible. I thought I would share some of the Do’s and Don’ts that have helped me over the last few months.