The Flatiron School cohort lead comes over the Slack channel 8am Monday morning: “It’s officially Day 1 of building your Rails project!”
My past self would have sat behind my computer, feeling good about my idea and what is to come, watch a few more YouTube videos on some Ruby concepts, and spend a good chunk of the day wire-framing and thinking about the user experience.
That programming self is behind me now. Today I’m going to dive into some things I learned along the way of building my Rails web application.
Minimal Viable Product
If you’ve got an idea, you should run with it. No matter what it is, see if it’s a viable product, but as soon as you determine whether it is or not, create. By spacing out the inception of my idea and the building of it, I left a lot of room for error. Once I began creating my Rails app, I found programming issues I didn’t know existed. I’ll get into these later in the article, but the important thing is that I didn’t have a minimal viable product in mind. I was trying to create something very complex but hadn’t the foundation to do it yet.
Build a minimal viable product first for maximum efficiency.
If I did this, not only would I have put the pieces of the puzzle together a lot easier, I would have become a better programmer in the process. The more I do, the better I get. By reworking the problems of my application over and over again, I began to reinforce the skills I already learned.
Wire-framing was extremely helpful during the creation of my product, but it didn’t substitute for the knowledge gained by creating my models, controllers, and views as soon as possible. I quickly found that I wanted my app to function in complex ways but hadn’t built out the model associations to match this complexity. So, I went more granular.
I created three models: user, venue, and event. The original idea was that users could log into the app, select from a list of events available for that night, find out who’s playing, and go enjoy the event at the venue’s location. A user could also create the events and venues.
Did I want a user to create the events and venues? Or an admin? If users logged in to experience the app, why would they also be creating venues and events? These were just a few problems I encountered.
After a few days of figuring out what I wanted to do, I decided on a minimal viable product, which became my project for the rails app. A user could create an event and browse through all events inside the app. Not exactly what I had in mind, but it got me started on the code, which was most important during that period of the project build.
OmniAuth
Remember how I said I ran into issues I didn’t know existed during the creation of my idea? OmniAuth brought along many of those. I knew I wanted users to have the ability to sign in using Facebook OmniAuth, but I didn’t know Facebook is more difficult to implement than Google or Twitter. My biggest issue was gaining access to Facebook through my app. This was because my URL was not secure. In order to fix this, I had to start my server by running
thin start — sslThis allowed me to run the application on https://localhost3000, which added the security feature to http and give my app to access Facebook.
Using .build To Associate Models
This was one of the most crucial aspects of my project: establishing the relationship from my join table to one of my models. The event model acts as the join table for the application. An event belongs to a venue and belongs to a user. A venue has many users through events. I wanted to give a user the ability to create an event nested under a specific venue. Enter:
.build.build is an Active Record method, providing the same functionality as .new but instantiating with the defined association. Here the association is between venues and events. Let’s take a look at the create method in my events controller:
def create@event = @venue.events.build(event_params)if @event.saveredirect_to venue_event_path(@venue, @event)elserender :newendend
By calling .build, I was able to create a new instance of event associated to a venue. Passing in “event_params” (the strong params) ensures that the instance doesn’t contain data I don’t want inside the event table in my database.
Conclusion
There you have it, I completed the application, but it wasn’t exactly how I intended it to be from the start. Things changed and I quickly figured out that I needed to chase the minimum viable product (MVP): an application that allows a user to create an event that’s associated to a specific venue. Once I determined the MVP, things went a lot smoother. I coded faster, got more things working, learned how to build associations from the join table to other models, and created something I’m happy to call my own. One of the biggest takeaways: save OmniAuth for last when building your Rails application.
