Up to this point in my coding career, I’ve basically felt like I had no idea what was going on. I learned a ton of Ruby. Great! SQL? Awesome! ActiveRecord? You betcha. The thing is, they were all disparate parts of the same vehicle. Sort of like learning about what a steering wheel does. Then learning about the accelerator, followed by the engine. Cool, but how do you drive the freakin thing. Wax the car you say? Ok. Sand the floor? Ok (but what the hell does that have to do with karate?). Paint the fence? Alright I’ve had it up to here…wait a minute, I just did karate! Aha! Well, Sinatra brought it all together.
Now, all of a sudden, I am driving (or doing karate, if you will). I’m by no means a NASCAR driver or Black Belt, mind you, but I’m doing it baby! I’m experiencing what I’m sure most developers learning to code experience. That Aha! moment. Getting comfortable behind the wheel, so to speak. Now if I break down, I am pretty confident in my ability to fix the problem and get the old jalopy back on the road.
Now onto my project. Like I mentioned earlier, this is where everything comes together. Models. Views. Controllers. Bam. Application active! To keep up with the car analogy, imagine the Models as being the steering wheel and accelerator/brakes ; the Controllers being the driver, and the Views being what the driver sees out the windshield. Imagine if you will, sitting in your car outside your home. You have an idea of where you want to go so you step on the gas. That’s one of our Models. The car accelerates and you see a new View out of the windshield. Now you, the Controller, want to make a turn so you turn the steering wheel (another model) and the car is on another street which gives you different View. I think you get the idea. Where this analogy falls short is the belongs_to, has_many relationships. But that’s for another blog post.
My projects so far have been based on living in California. One of the best things about living here is the Farmer’s Markets. Freshly picked produce. Farm to table. It’s a blessing. Most of the time though, I buy much more than I can use. Or I forget about some veggies, only to find the poor neglected things shriveled up in the back of my fridge a month later. How can I keep track of all of them?
Enter Produce Organizer! Now there will be no more spoilage in my fridge! Yay! Alrighty then, let’s get on with it. First things first; to make sure I had bundler installed by typing “gem install bundler” on the command line. Next: “bundle gem produce_organizer”, to create the gem. This gives us our basic files with a ‘Readme’, ‘Gemfile’, ‘License’, etc. I added what I needed to my Gemfile and typed ‘bundle install’ in the terminal to get all of the gems installed. Now onto the good stuff.
To drive the car, your accelerator, brakes, and steering wheel have to know what they can do. So let’s start there. Getting the tables set up fits the bill. The questions to ask here are: what tables do we need? What columns in the tables do we need? And how will the tables relate to each other (think – has_many, belongs_to). After those questions are answered, we must migrate! First we’ll create our tables and then migrate them to create our schema. That will take care of our backend, unless things weren’t thought through completely (which was true in my case); in which case we can easily add or remove columns from the tables.
Next comes the Models. These are fairly easy. By inheriting from ActiveRecord::Base, we have every method known to man at our disposal (ok, not every one – but close). All we have to do is setup our has_many, belongs_to relationships. The Produce Organizer basically has three tables: a Users, Produce, and ProduceDatabase. The Users table has_many Produce and has_many ProduceDatabase. The Produce belongs_to Users and belongs_to ProduceDatabase. And ProduceDatabase belongs_to Users and has_many Produce. ActiveRecord will want these tables pluralized, which in our case didn’t make sense for the Produce and ProduceDatabase. There is a quick patch to fix this problem. Inside our config folder lies the environment.rb file. This file keeps everything running smoothly. Here we add this block:
This tells ActiveRecord to accept ‘produce’ and ‘produce_database’ for what they are, without looking to pluralize them. Cool.
Now that our backend is nice and tidy, lets look at the Views and Controllers. How the application will run is as such:
‘/’ – Index – signup or login
‘/users/signup’ or ‘/users/login’ – Signup or login sends us to
- The controller action, ‘post “/users/login”‘, which will validate the username and password (protected by fierce attack dogs. No, not really. More like Sinatra/ActiveRecord magic.), and let them through or send them back to the login page with a polite message. If they pass the test they will be sent to
‘/users/user’ – Users Homepage –
- The get request here will make sure that it’s sending the correct user to their homepage by using session[:user_id]. We have to enable sessions in our ApplicationController. Once the page is loaded, there will be a list of all of their produce, with days left until expiration and a ‘remove from list’ button next to each item
- Below the list, there are a few links
/produce/new – Add more items to users list
- This view gives users a list of all the available items in the database with an option to check as many as you want to add to your list, plus a form to create a new item. If a user adds a new item, the controller will first check to make sure the item doesn’t already exist. If it does, the item will not be added to the database but will be added to the users list. If it doesn’t, then it will be added to the database and to the users list. The user will then be routed back to their respective homepage.
/produce_database/new – Add more items to the database
- Here the user can add an item to the database
- the ‘post’ action in the ProduceDatabaseController, will make sure the item doesn’t already exist and then add it if that is true.
‘/produce_database/edit – is another link to edit items already it the database
- This page gives us all of the items in the database and their shelf lives. Only the creator of the item can edit it. So if the user chooses to edit one, the control action will make sure the current user created it and either create the item or give the user a failure message, telling them that they don’t have the editing power because they were not the creator of the item.
- Here the user can add an item to the database
/users/logout – Logs the current user out and brings them to the Log In page
That’s the basic structure and flow. There will be flash messages for each action the user makes based on success or failure on what they are trying to do. All in all, I learned a ton working on this project and feel a newly found confidence!