My name is Carolyn Manning, and I am a student at Flatiron School. I spent the couple days tackling my third portfolio project using Rails. Let’s walk through my process!

Carolyn Manning
3 min readMar 14, 2022

Prior to my interest in software engineering, I spent nearly 10 years as a yoga teacher in New York and Boston. Having seen studios and gyms us various apps used in the past, I had an idea to create a simple schedule management app.

As opposed to my first two portfolio projects, I much less intimidated to start with an empty workspace, as Rails creates a very comprehensive file structure. With that in mind, as with my other 2 portfolio projects, I started small and worked on one part at a time.

For my Phase 2 portfolio project review, I was told that I should really increase my number of git commits. I made it my first priority to work on this, which turned out to be wildly helpful as noted in my takeaways below.

For actually building the app, at the simplest level, I wanted the program to: 1.) Have an admin account that could create and update the schedule 2.) List the current schedule and 3.) Allow a user book a class for their personal schedule. I decided that in order to fulfill or the requirements for the project, I would work with 5 models (User, Yoga Class, Teacher, Style). I briefly mapped out my association and began creating my tables, models, controllers, views, and routes with different kinds of Rails generators.

On certain labs I had worked on throughout this Phase and Phase 2, I had had some difficulty testing an app without the User “sign in” and “sign out” functions working as simply as possible, so this is where I decided to start after using the generators. First, I enabled Sessions in my application controller and created helper methods to determine if a user is logged in and who the current “User” is since this had been helpful with projects in the past. Once these forms and routes were working, the remainder of the app came together pretty seamlessly.

However, I did hit a few roadblocks that set me back a bit. I definitely have noted how important it is to thoroughly plan out your app before you begin developing it. This is especially true with these portfolio projects that have certain requirements. While I had planned on making a yoga studio scheduling app, I was constantly running into some glitches and confusion with certain naming conventions during my build. For example, I could not name a model simply “Class” as that is a reserved term that already has a use in Ruby. After feeling uncomfortable with the confusion this was causing, I haphazardly decided to change my idea and quickly began working on a different concept without much thought. Of course, this didn’t go well, and my UX became a mess in trying to meet the requirements of the project! This is why it was so helpful to have a thorough record of my got commits. When I decided to revert back to my original concept, I had a comprehensive map of exactly how to begin to build!

As with my last 2 portfolio projects, this project definitely gave me even more confidence continuing to move forward in the program.

--

--