StudioAssistastant — A Rails App for the Working Producer
How it started, how it went, and where it’s going.
StudioAssistant is an app idea that I initially developed for my Flatiron School module 2 Sinatra project. Essentially, StudioAssistant is an attempt to help working musicians and producers navigate an erratic work schedule with a web app that organizes their upcoming sessions in a way that is catered to their needs. Developing the app on Sinatra was a great way of getting my grounding with web development, but, as someone who believes in the importance of understanding the domain in which you are working, especially when you’re developing an app on such a rich framework as Rails, I found myself being drawn to this concept again for my module 3 project.
Initial Design
Having done a version of this app already, I had a solid idea of what my associations and tables would look like. I knew I wanted to expand the initial design of my User model by splitting it into a User model and a Studio model. This would give the front-end user the option of adding multiple, inherently different studio spaces that they use, as well as letting our RecordingSession join-table model grab those Studio-specific attributes to incorporate an even more dynamic way of delivering content to the front-end.
Debugging
Working on Rails was, despite all the great things it does under the hood, quite daunting throughout most of the process. This being my first Rails app build from the ground up, I went into it with plenty of theory, but little practice. A big part of learning how to code is compartmentalizing concepts, but the actual practice of coding requires connecting these concepts in precise ways that may not be obvious until you’re running into error messages that don’t have an obvious solution. Thankfully, for me, it was an opportunity to debug in ways I wasn’t used to and understand blind spots in my own mental models.
One particular roadblock that stopped me dead in my tracks was putting together my RecordingSessions#new nested form. A project requirement involved using nested routing to associate a child object with its parent via the params from the URL. So in this case, Studio/1/RecordingSessions/new would create a RecordingSession object associated to a Studio object with an id of 1. For the sake of my design, I knew I wanted to go a step further by putting a nested form (RecordingSession and Client) within a nested route(Studio), so I could associate my RecordingSession join table with both its parents without adding a collection_select for Studio.
This nested form within the nested route direction lead me to many different error messages, but I want to focus less on the specifics of the error messages and more on how I got through them.
Byebug
Byebug was the primary instrument I used to try to understand what was happening underneath the hood. The nastiest bug my app had involved a dreaded uniqueness evaluation being thrown for my nested Client object. Surprisingly, it was its id attribute that was being ringed for not being unique. I knew this wasn’t common behavior, but I also didn’t really understand where exactly in the flow of the app this was happening. This made it incredibly hard to do a quick google search because so many different events can lead to the same error being thrown.
Byebug didn’t magically solve the issue immediately, but what it allowed me to do was follow the process of my code line by line, and see what the console was telling me about my params. I followed it to my #client_attributes= method in my RecordingSession model and discovered my client’s ID was being reassigned to 1 somewhere within #client_attributes=. I confirmed that this was the issue by having my .find_or_create_by method search by email instead of id. This created the expected behavior.
I was happy I could persist a client object now, but this was definitely not optimal, so I kept digging. Then I noticed I left something out…
Fixed everything. Always check your strong params…
Process
Another takeaway from working on this project was I need to sit down and work out my own workflow the same way I worked out my website’s flow and associations. My workflow started at getting my database and models established and working, but after that, I sprawled to trying to finish the entire backend of my app before I touched any views. This created a lot of ground for errors to spring up. Since I had done a decent amount of work everywhere, suddenly I had no orientation as to where errors were coming from besides the messages themselves.
This inspired me to google some different workflows for inspiration. One concept that addressed the crux of my work issues was “Outside-in testing”. This is where a developer implements an app feature by writing high-level tests first, then going about solving the tests from the perspective of the front-end user (or outside-in). The errors that get thrown guide the development process. When you’ve completed the feature, simply writing the next test and going from there. This means solving many obvious, simple errors instead of solving many ambiguous, difficult errors, while also documenting the process of creating the app. I haven’t started writing tests yet, but I intend on following a similar workflow next go around!
What’s Next?
StudioAssistant on Sinatra was a rough draft for StudioAssistant on Rails. In a similar vein, StudioAssistant’s current iteration is a rough draft for what I hope for it to be. Rails can do so many things in such an accessible way that I anticipate I will be coming back to this project often as I continue to learn.
First, I want to incorporate the Client class into the User class as an alias so that StudioAssistant can have a client-facing interface for users who are looking for producers or studio spaces. So much of networking in music is via social media channels that are great for spreading a reputation, but there isn’t a centralized place for musicians to network and work together on a platform that caters to them. A client could look for a producer with a certain specialty, or a band can rent a studio space to rehearse by hourly rate and availability. So much of the music economy is at a more micro level than in the past, so being able to facilitate these micro-interactions would be a great service to the community at large.
The Studio model should also have a HomeStudio model that inherits from Studio. This could be a type of Studio for the user to select that has a whole host of personalized inputs for the user. This could also be a great model for remote work, which is how more and more music is being recorded. Producers and engineers could list their mixing and mastering services from their own studio, saving both the user and the client money on studio space.
I look forward to finessing what I have in the app already and speaking to more and more musicians/coders on what they might want from something like this. If you have something to contribute, please head over to my GitHub repository for StudioAssistant and submit a pull request!
