My First Real Web App

Breakable Toy

In the final 2 weeks of the program at Launch Academy you will embark on a personal project of your choosing. You decide what you want to build and how far you want to take it. This is called a Breakable Toy and it is the capstone project that you present to hiring partners on Career Kickoff.

For my final project I decided to make something that aligned with my passion for music. I used to be a freelance music instructor for a number of years and I really liked everything about it except for the unnecessary hustle of finding students. Keeping students was relatively easy but finding them was so much harder than it should have been. I was marketing myself on about 6 or 7 different platforms and it was tedious to keep track of them all.

So I created (began working on) an app called Let’s JamIt is designed to be a kind of meetup app for musicians wanting to either teach or receive lessons. As it stands right now, there is limited functionality. Users are able to Sign up, designate themselves as either Teacher or Student and then join or create lessons depending on what type of User they are.

I didn’t end up including all the features I originally wanted and that’s ok. The goal of this project wasn’t to build a first-rate site with all the bells and whistles in 2 weeks, although some did just that. The object of this project was to reinforce what I had learned over the last 8 weeks then push myself a little further.

Breakdown

  • Backend is all Rails with ActiveRecord.
  • Front-End is a mix of Rails and React. All content, with the exception of the forms are done entirely in React.
  • Styling is done with custom SASS and CSS3
  • Database uses a self-join on the users table to distinguish Teacher from Student

Features to Add

Here is a list of features that I originally wanted to include in my project. I plan on including these features one by one, beginning immediately:

  • Google Maps API to search by location
  • Stripe API for payments
  • Trillo for text alerts
  • Completely React Front-End
  • Fully responsive and Mobile-First design overhaul
  • Restructured database to allow for more complex user interaction
  • OAuth (Get rid of Devise for authentication)

Obstacles

Now that the whirlwind that was the last 2 weeks is now over, I can finally look back and assess where I can improve. Upon reflection, I noticed a few things:

  1. I ran into issues early on with my database
  2. This was due to being overly excited to get started and ‘freestyling’ the backend architecture
  3. Once I had a clear picture of my MVP (Minimum Viable Product), and it was set up, everything moved super smooth

What did those database issues look like? Well, I had an incredibly clear vision for what I wanted the app to be and I tried my best to build my database in a way that would allow for the functionality I envisioned. What I had not accounted for, however, was that backend processes are not my strongest skill and the backend I was attempting to build was much more complex than I had previously thought.

Originally, I had something like 6 or 7 tables in my database with varying associations amongst them all. Once I had it built in the backend I began building it out in the front end but ran into issues and things broke. What I know now is that I should have started small and simple and built in the complexity as a progressed.

The first draft of the database consisted of 2 types of users, students and teachers then a join table for the two, tutorships which contained a has_many relationship with lessons and finally, each user had a relationship with instruments.

In the end though, this was reduced to 2 simple tables. users and lessons. My 2 types of users (students and teachers) were reduced to one table – users and I did this after discovering self-join tables. Then, I determined that lessons was acting as a join table itself and as such, I could scrap the tutorships table and then furthermore, I collapsed the instruments table into the lessons table. This way each lesson contained the instruments instead of on each instance of a User.

I will be retooling the database back to the original design I constructed in the beginning, as this is allows for scalability and further complexity. Looking back, I tried to take on too much, too quick, and as a result, the functionality of my final product suffered. Thankfully, now that the dust has settled, I can actually devote more of my free time to carefully crafting the site to be what I originally intended it to be.

Drawbacks

The way you arrange your backend will determine the types of interactions that will happen in your app among users and content. With the database structure the way I have above, I am limited in what I can do.

For instance, all instruments and skill levels for that instrument are tied to the lesson. The proper way to do this would be a many to many relationship with instruments being its own table. From there, users can have multiple instruments, with corresponding skill levels for each instrument. Then, they can join lessons aligned with those associations through a join table, like I originally wanted, tutorships.

Why a join table between lessons and users? Because, when a Teacher and a Student meet up, they are creating a relationship between themselves. This relationship consists of many Lesson events. So in this sense, tutorships would have a one to many relationship with lessons such that a Lesson belongs to Tutorship and Tutorship has many lessons.

I feel like this would make a lot more sense. From here, it would be possible for a Teacher or Student to have multiple Tutorship relationships with various users. Then, you could display all lessons with those associated users with which you have Tutorship with, both completed, past and future.

Accomplishments

I was able to finally indulge myself with design and front-end work like I have been wanting to do for some time. I was able to mess around with React and React Router a lot more which was nice because it gave me a lot of grief during the program. Also, I was able to refactor my entire front end to use React Router in one day, something I wasn’t confident I would be able to pull off – but I did. I was able to experiment with SASS, CSS3 & Foundation as well. Moving forward, I want to be able to do everything that Foundation does (i.e grid layout, page structure) in pure CSS.

jam44.png

I figured that since I was having issues with the backend I would devote more time to working on the front-end, where I knew I would excel. To that end, I tried to spice up the site with little things here and there.

  • Fixed backgrounds on the main pages of the site to give it a more modern feel.
  • Class names in React tied to state changes and onClick events to alter the page in real-time to make it more interactive.
  • A simple and elegant layout of user cards on the homepage that automatically adjusts despite a dynamic amount of users.

 

jam1

I had a blast when it came to design but it was React that I had the most fun with. Why? I had a lot of cool stuff going on. I wanted to render different types of data based on user events (onClick()). What’s more? I had to use API endpoints for the first time, this was a really fun challenge.

jam2

I really wanted the API fetch calls to be as elegant as possible. At first, I was just fetching all users in my database and then filtering them out using a .filter method. I knew this wasn’t efficient though, what if my database consisted of a million users? This would bog things down big time!

To remedy this, I created 2 new API controllers for teachers and students and then used some logic and onClick functions in React to redirect the fetch call, through string interpolation, to either the student or teacher API endpoint. This proved to be a much more efficient way of retrieving data from the Rails backend.

What I Learned

I learned that my understanding of databases and associations is not as strong as I originally thought it was. This is certainly a blind spot for me that needs to be addressed. Because of this, I have already taken steps towards building up my knowledge of ActiveRecord and the general concepts of relational databases. This is something I am now committed to becoming highly proficient in.

Something else I learned was that I am biased towards the Front-End. I love the validation of seeing your work on the screen and being able to manipulate the way it works, behaves and appears. I learned that I approach adversity on the Front-End with optimism, intrigue and curiosity whereas I approach similar problems from the Back-End with a kind of reluctance – this is a disposition I believe will change as I become more proficient and knowledgeable in backend processes.

I also learned some valuable tools for stress-management. In the beginning, I paid little attention to the backend, thinking this would be cakewalk. When it became apparent that I was wrong, I rushed through the reworking of the database, thinking I was running out of time. I panicked. I never panic. I did this time though and that caught me off guard.

It is in the moment that I should have done the exact opposite. I should have slowed down, taken my time and given care to the process of rebuilding my database. Had I approached the problem in this way initially, it likely would have eliminated a number of headaches I ended up having later on in the following days. It’s always better to move slowly, yet methodically, than to move quickly and have to come back to fix mistakes later in the project. I plan to implement this way of working from now on.

The final thing I wanted to mention was TDD. Test Driven Development. When I began, I said I would do this entire project with TDD. That worked for the first couple of days. By day 2 I had something like 30 tests written which wasn’t too bad and I was feeling good about that.

As the project grew in size, and goals shifted, it became increasingly difficult to utilize TDD. I strongly believe this is directly correlated to not having a clear enough image and action plan for the project. If I knew exactly what was to be created beforehand, writing tests would be no problem. Instead, it slowed me down significantly – so I abandoned it entirely. I will go back now that I have the time, but in the future I really want to use TDD and to do that I need to start by having a more clearly defined action plan before starting.

Final Thoughts

The final 2 weeks of the program at Launch Academy is a very stressful, yet exciting time. You are finally using the skills that you’ve acquired over the last 8 weeks to build something of your own. You will be given many deadlines that need to be met. You will be drilling on your pitch every single morning from 9:38am to sometimes 11am.

Given the time constraints, it is very important that you begin planning out, at least in a high-level way, how your app will function, what it needs in the backend to accomplish these goals and probably most important – prepare yourself a detailed action plan complete with day to day deadlines of various features that need to be completed in order for you to have a finished product to present to hiring partners.

Do these things and you will succeed, fail to do so and you will likely suffer. Don’t suffer. Succeed.

Resources

One comment

Submit a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s