Learning RoR has been quite challenging to say the least. Add in the personal grief that I’ve been going through for the past few months and I can say it has been one of the hardest things I’ve ever had to do. I was keeping a good pace through June and was nearing the final assessment for the Rails section of the course when I had to do some self-assessing. I realized that even though I was getting through the material, not much of it was sticking. I thought it would be a good idea to take a bit of time off (which the good people at Flatiron allowed me to do) and review. So I took about 6 weeks off and did just that. I came back feeling strong and ready to code.
I thought I would stay with the theme that I started with using Sinatra, which was a Produce App. It basically keeps track of produce that you have in your fridge and lets you know how many days left until spoilage (because finding rotten fruit in the back of the fridge is the worst!). Pretty simple right? Well I ran into some trouble because I didn’t fully understand all of the instructions. Maybe I should rephrase that. I understood the instructions, but jumped in the deep end without making sure there was water in the pool. Although in the end, I learned a ton and feel much more confident in my abilities and understanding of programming and debugging.
So back to the part about jumping in the deep end. Well, it turns out that a little more thinking is involved in an app creation before any actual coding is done. Of course you can always add another column to a table in your database. Or in my case a whole new table itself. It worked this time, but I know in the future I will have to do a little more thinking before I start coding. The initial design of my app was very basic:
- users table with columns:
- produce table with columns:
- type (fruit or veggie)
- shelf life (integer)
- users_produce joins table with columns:
- user_id (foreign key)
- produce_id (foreign key)
- created_at (date)
- eaten? – a boolean value, set to false as default and turned to true if it was taken out of the fridge.
The joins table would have a method to calculate how many days left until expiration. This is accomplished by calculating the difference between the created_at value of the user_produce and Time.now and subtracting that value from the shelf_life value from the produce. Looks something like this:
I added some nice bootstrap styling, a Devise authentication system, and had a working app pretty quickly. Then I went back and re-read the instructions. One of the trickiest parts of Rails is nested attributes and my current configuration left me no way to implement this feature. Back to the drawing board. I needed the ability when creating a new ‘something’ in one table, it would also cause the nested attributes to create a new ‘other something’ in another table. I know that is super technical and will go over most heads. I do apologize. So I thought about it. And thought some more. I needed another table that could associate with my produce table. I would have to expand my app.
I decided on a Juices table with just a name column and a JuiceProduce joins table with produce_id, juice_id, and quantity columns. This would enable the user to create a new produce item by way of nested attributes from the creation of a new juice. Cool. Implementation was quite difficult and I would be lying if I said it didn’t take me a few days. It seems like it’s always these sticking points where high frustration ends in the most learning. Lesson to self: don’t get so frustrated…there is an answer and it will make you learn! You just have to keep moving forward and ‘get your hands dirty’. That’s what I like to call prying. Sometimes I’ll put a binding pry after each line of code in my controller action and in the instance method in my model. Here I can see exactly what is going on after each line of code. I likey. It feels like I’m getting my hands dirty:)
I made it a lot harder on myself by having dropdowns for produce (which were already in the database) to choose from in the New Juice form, while also having input fields for new produce (which was not in the database). But like I said earlier, it’s these sticking points that really challenge you and end up speeding up the learning process by leaps and bounds. I’m proud of myself for sticking with it and have a new found confidence that I’m actually going to be a web developer…and a good one too! Check it out in action!