So the front-end is messy. I think that’s why I am more drawn to the back-end, it’s just cleaner, more succinct with a little less ‘magic’. One thing that I realized is that how it is organized is so much more important. Files are imported so if you need to change the name of one to have it make sense you then have to find every place you used it so you can change that name too. It’s a scavenger hunt. However, as a newbie using React, figuring out exactly what containers and components you will need is impossible and inevitable this happens a LOT. I started out with a lot of files that were overly specific in their naming, like RecipeIngredientSearchContainer (talk about a mouthful), only to realize later that I should really just be called SearchContainer. The extra words and syllables created extra confusion for me, the developer, making it harder to figure out what goes where.
When creating my Rails capstone I was so enthralled by the backend and loved what I made that I didn’t give a ton of thought to the front-end design. I was not even sure how a front-end worked nontheless how it functioned with a back-end. Now I have a much better idea!
Falling off the coding wagon is bad but sometimes life happens and the combination of a big shift change at work, your partners employer suddenly going a little crazy, and planning a wedding makes things a little difficult to get done. This didn’t even include the family drama that occurred. However, it made completing my Rails project a bit more of an adventure.
So far one of the more difficult topics I have encountered in Rails is nested forms and how it produces HTML and interacts with objects. A first glance it seems simple, it’s like a nested array…sort of…right? Well sort of…also not sort of. First off when white-listing attributes and nested attribute it comes out a hash. Second off, when you add the nested attributes (ie categories_attributes in the following code) it gets confusing. There are very specific naming conventions that must be followed.
Sinatra was my first exposure to working with a framework. Compared to my CLI Gem it was harder to figure out what to make. I am not a listmaker but realized that when my partner and I have friends over we often forget which dvds we have or can’t find one that we were convinced we owned. So I thought it would be useful to create a simple app that allows you to create movies and associate them with genres. This way we won’t forget about a movie and we could sort them by genre so we won’t end up looking at detective movies when really we want a musical. One thing that I felt was important when I made it was for the user to create and manage their own genres. I debating setting up the generic genres, like action and romance, and not allowing the user to manage them but in reality everyone categorizes things differently. I know when I am deciding on a movie or show or even episode to watch I don’t think about if it’s a romantic comedy I think about if I want a movie that has dogs, or feels ‘edgy’, or is nostalgic. I wanted everyone to be able to make that decision themselves since it is unique to each person.
Making a Sinatra project from scratch wrote itself. The framework makes it easy to figure out how all the pieces fit together and often I found myself reusing code from each of the controllers and views. The hardest part was by far figuring out the best way of setting up the relationships. I actually had to go back and rebuild the database when I was close to done deciding to change the associations since I realized it was too complicated. I needed to simplify. Luckily, it wasn’t too difficult to change it so that I wouldn’t create Cthulu in Sinatra form.