Through the magic that Rails gifts us to make our own sort of magic happen in the dev world, it’s definitely been a learning curve to say the least. Though we’re offered so many more tricks to whip up a function that typically would take longer to accomplish via Sinatra, it’s no simple feat to piece your puzzle of an app together using all the additional pieces you’re provided. What’s been the more difficult part of putting it all together is the conceptual understanding behind the relationships between all the pieces. It’s like, if you’re off by a shade of 1 graphic pixel of 1 puzzle piece, you could potentially be… in trouble.
Up until now, we’ve studied the inner mechanics of how/why it’s significant to code each line into an app. Even with all that knowledge, the abstracting away of hard code replaced by conceptual interrelationships of more powerful operators demands evolved application for strategic placement.
Adhering to the Single Responsibility Principle is sensical enough to understand its value of delegating single functions/responsibilities per class, module, etc. in a program to make the machine come alive. However, to apply, is challenging. Through my final project on Rails, the Product-App, I quickly learned (rather, got slapped on my conceptual face) how each method I called, defined, chained… each variable, instance and otherwise… each file, folder, etc. operates interdependently of its counterparts — particularly, the understanding of Rails resources in all its glory.
Diving even deeper to make full, efficient use of the Rails structured setup, nesting resources and route methods vs. how they impact controller actions and tapping into the database. Am I being explicit enough or am I digging myself into a deeper hole restrictions that I’ll later regret is the constant, looming fear that I’d have to go numerous commits deep and hours on resolving any potential issues. Meant to be helpful, no doubt, nesting resources and its corresponding requests and determining responses drove home the concept of how interrelated an app is.
It’s like the iPhone vs. an Android. iPhones, appreciated for its power built on simplicity vs. Android, opted for based on its power of customizability. Through customization, you have more options. You’d think a question of more options and pathways to achieve near anything you’d want equals bliss; and that certainly depends on who’s asking and who’s answering…