The project I built using Ruby on Rails is a private group class tracker for a yoga studio.
Sounds like a mouthful, I know, but I noticed that the yoga studio I work for has a niche problem. Local organizations such as universities, non-profits, corporations etc. request for a yoga teacher to come onsite to teach a class. Most of the time, these requests are inconsistent. For example, an organization will want a class for their “Wellness Week” which only happens a couple of times per year. Since requests are inconsistent, the same client will have a different teacher each time. The teacher assigned for this offsite class has no idea what kind of class to plan. What kind of practice do the participants want? What is the space like? It would be nice if they could take a look at the class plan from the previous class, that was perhaps taught by a different teacher! That’s where my web application comes into play!
My enthusiasm for my idea fueled the creation of the project, however this was the toughest project yet. Here’s what I learned:
The importance of having a clear vision for your project before you get started.
I had to restart my project twice! I had to restart my project because both times my domain was not clearly defined from the get-go, which made building complicated (lesson learned!). However, each iteration of my project led to my final product, which I’m very proud of. While I shared with my friends and family about my tribulations, I compared my process to something they were familiar with, writing a thesis paper.
The first step is to clearly construct a thesis statement, in coding world this would be constructing our domain models and defining relationships. The thesis statement steers the ship as you’re writing the paper. Similarly, your models and relationships can create the backbone of your Ruby on Rails application. If you write a thesis paper without properly researching a topic, as you’re writing, you may have a change of heart with your beloved thesis statement. Now that you’re reading additional sources and are really diving into the topic, perhaps you want to change your stance. So you go back to the drawing board and rewrite a thesis statement that better represents your positioning now that you have new information. You have to start your paper all over again. Similarly, as I began to bring my project to life, I realized there was a better way to represent my project— different from the models and relationships than what I had set up. Since I wanted to change the infrastructure of my project, I had to restart my project.
Knowing when to let go if a certain idea isn’t working out.
It’s tough to abandon a project after spending a lot of time on it. I spent 4 days on my first iteration, knowing most of the time that I wanted to restart it and take it in a different direction. I was so resistant to restarting, but once I took action and restarted, I felt a surge of momentum because I knew it was aligned with my vision. To make myself feel better about my situation, I thought about how artists record entire albums that never get released and fall to the wayside. Authors write novels that never get published. Although these pieces never make it to the public, I bet these creative pursuits influenced other pieces that eventually did reach a broader audience. Similarly, my failed projects influenced the success of the final version of my project.
Get to know the gems you’re using.
Since I restarted my project twice, I can now set up Devise and enable Omniauth using Facebook with confidence. This was my first time using both Devise and Facebook Omniauth. Typically when I use a gem for the first time I find a blog or video to guide me through step by step. The downside of this method is that I blindly follow step my step without internalizing or completely understanding what’s happening. For this project I was able to set up Devise and enable Facebook’s Omniauth three times, so now it’s solidified in my brain. It got me thinking, that for future projects when I’m using a new gem I should make sure I really know what the gem is doing, so when if I run into a bug I’m better equipped to resolve the issue.
Nested resource show page
A feature of the app I was excited to implement was to view the history of classes by client. This would help the user zoom in on which templates to research and take ideas from.
Each class would be represented by a link that would then take the user to a nested resource show page, which would have all the available information about the class.
The code behind this feature was fairly simple, yet important to break down.
<p>History of Classes:</p> <% @client.yoga_classes.each do |yoga_class| %> <%= link_to yoga_class.title, client_yoga_class_path(@client, yoga_class)%> <% end %>
In my client model I defined the relationship that a client has_many yoga_classes. This then gave me access to call on an instance of a client and a list of their associated yoga_class objects which are assorted in an array. Then, I called an iteration on each yoga_class to create a link for the specific yoga_class. With link_to, the first part of the link is what the name of the link is, and the second piece is the path the link takes. So, I named each link the title of the yoga_class. Then, I used the route helper (route helpers are a piece of magic given by Rails) client_yoga_class_path(@client, yoga_class) so that a specific class would be nested underneath the client. @client was the first argument of the path because the helper needs to know which client_id will have all of its associated yoga_classes listed. Then, the url needs to know which yoga_class to route to based on the yoga_class id attribute. This helper is constructing the following template of the url: /clients/:client_id/yoga_classes/:id. As you can see in the screenshot above, the yoga_class has a client_id of 5 and an id of 4.
Just getting started….