Throughout my last couple of projects for the Flatiron School Software Engineering Flex program, I’ve come across a repeating issue. I’ll be doing alright, following along with the project instructions and using what I’ve learned from that particular phase, when I suddenly realize that there are actually two ways of doing something. This can very easily send me into a tailspin. Which way is more inline with the rules and guidelines of the project? Which way is more efficient? Which way would be easier for an outside coder (or even myself a couple of weeks in the future) to immediately grasp and understand? How do I decide the best way of coding a particular project or feature?
This time around, I felt this insecurity most while working on the various fetch routes for my backend. My project is focused on musical artists, the songs they’ve performed, as well as the covers they’ve performed of other artist’s songs.
ActiveRecord::Schema.define(version: 2023_01_10_211010) do
create_table "artists", force: :cascade do |t|
t.string "name"
end
create_table "covers", force: :cascade do |t|
t.integer "song_id"
t.integer "artist_id"
t.string "performance_link"
end
create_table "songs", force: :cascade do |t|
t.string "title"
t.integer "artist_id"
t.string "performance_link"
end
Using ActiveRecord, I was able to link these tables with particular relationships to each other. For example, each Artist has many songs and many covers and each Song belongs to an Artist and has many Covers. This creates a one to many relationship between the artists and songs table, as well as a many to many relationship through the covers table, with each cover belonging to a particular Song and a particular Artist. Just getting to this structure was its own process of decision-making and fretting, but then it came time to actually set that data up to be ready to interact with my React frontend. This was a whole new process of decision-making and fretting… For example, I wanted to create a GET handler to take care of requests made for the data in the artists table:
class ApplicationController < Sinatra::Base
get "/artists" do
artists = Artist.all
artists.to_json
end
end
I also wanted those artists ordered alphabetically by name in the json data that would be returned. So, would it be best to simply handle that ordering in the application controller itself?
class ApplicationController < Sinatra::Base
get "/artists" do
artists = Artist.all.order(name: :asc)
artists.to_json
end
end
Or is it better to define a specific class method in the Artist model then use that in the controller?
class Artist < ActiveRecord::Base
has_many :songs
has_many :covers
def self.sort_by_name
self.all.order(name: :asc)
end
end
class ApplicationController < Sinatra::Base
get "/artists" do
artists = Artist.sort_by_name
artists.to_json( include: [:songs, covers: {include: [:song]}])
end
end
(spoiler this is the one I ended up going with. I also used Active Record to include the associated songs and covers table data for each artist)
I think there could be arguments for both (and even arguments for handling the ordering on the frontend, but I didn’t consider that one here as it didn’t seem inline with the project guidelines). With an application as simple as the one I’m making, It might be easier to read and understand the code if things are all kept in one place in the controller. But, on the other hand, it might be better for compartmentalization and specificity within the program to handle the ordering within the Artist model. Ultimately I chose to go with a separate class method within the model because I felt it offered its own kind of clarity. It might take a couple extra steps and switching between files to see what it is doing, but everything is in a place where it can do its own specific thing. That, and I’d just spent an entire phase learning about how to use Ruby to write methods… and I wanted to use that somewhere in the project…
I think that’s something that’s really struck me about the end of phase project this time around. That there are not only so many ways of getting to a particular functionality or goal with your code, but that there can also be so many reasons for why someone might choose one way over another. And not all of those reasons are entirely centered around the code’s performance or legibility. I’m a student doing a project, so I’m constantly thinking about what’s going to work well within the criteria of the assignment I’m doing. “Based on this assignment’s rules, what will best show that I understand the material?” is a much different headspace to be in than that of someone working towards a deadline on a team within a major tech company, and that is a much different headspace to be in than that of someone working alone on their passion project in their free time. It’s kind of staggering how many “right” answers there can be to a particular problem, or at least how few “wrong” answers there really are.
Lately I’ve been trying to learn more about music making, and one thing in particular I’ve been trying to learn is how to mix and master. Watching this video, “The Art Of Mixing” the other night, I was struck by some of the things David Gibson said about mixing. Replace what he says in this quote about “mixing” and “recording” with words like “coding” and “programming” and I think the quote works pretty well!
[...] no one knows everything about recording. Because every session, every project is a completely new experience. It’s kind of like life, you never know what you’re going to get. We can only do the best with each situation and who knows what the best is? There’s no god of recording out there grading us. Therefore, I’m not here to tell you how to record a certain way. Each mix should be based on the song you’re mixing. I’m not here to tell you how to mix like me. I’m here to help you to prepare yourself to handle the most unlikely type of situation possible. I’m not going to tell you the one way to mix. I want to show you different ways that people mix, so you will have a choice. I’m here to help you do the most difficult job of all, to make art out of technology.”
–David Gibson, The Art Of Mixing
I think if I can apply that philosophy to mixing music (which I have no knowledge of) then I can certainly apply it to coding (which I now have some knowledge of…). Ultimately, I think what these thoughts have led me to is that I don't always need to fret so much about what is the "best" or "right" way to code. Coding is an ongoing process of constant creation, testing, editing, and experimentation. I think its open-ended nature is one of its greatest strengths and it's something I will try to celebrate rather than fear as I continue onward in my coding journey!
Top comments (0)