You can find this app here: https://github.com/srolandmarshall/party_planner_app/
While last time I did somewhat of a live code of my project, this time I spent a majority of the time coding rather than blogging. While this makes this recap blog a little more difficult, my ability to work within Git and keeping to small changes was much better, so I’m using this as basically a written history of my Git commits.
My idea for the Rails project was to make a party planning app that helped a user (or users) plan parties and keep track of what their guests were bringing to dine on so that there would be no repeats and so the host would know who is coming.
My first move after installing rails was to create a sketch file that would mock out my structure going forward. After watching enough Avi tutorials I figured that I was a good way of organizing my thoughts here. So I created a notes file within my application and used it as a running tally of what I needed to create. Eventually I would refine this, but it was good to have a scaffolding in place before i started working with rails generators so it kept me sane.
I also started writing out the associations in this document. It really helped me map out what belongs to what.
Next, I started to build the resources. Since this is a party planning application, I started with Parties. Parties would have a name, an address, a date (called ‘time’).
Then, the crux of this application is around the party-goers, thus Users. I used devise to manage this. I tried adding in Facebook log in, but I’m (still) having trouble getting it working with localhost.
Then I added resourses for Foods and Drinks. I ended up scrapping Drinks within the app because everything I was going to develop with it was going to be demonstrated with foods. For functionality, I can see Drinks making a return in V2 of this application, but for now, keeping this a teetotaling party is fine by me.
From there, I built some simple views for the parties. This allowed me to test the parties and user resource. I then realized I needed some authorization for parties. This led me to creating the Host association. As foreign keys and the as: modifier were some of the techniques, I started by making way too much. I made a host controller, model, was adding host_id columns to places it didn’t need to go. Eventually, I went back to the Learn.co lessons and sorted it all out and got it straightened out.
After this, I got tired of creating dummy accounts and parties so I started creating Seed data using faker, a great resource for creating dummy data so you don’t have to. I then made a <code>rake db:reseed</code> function which flushes the database and regenerates seed data, so I could keep party data fresh and in case I messed up anything in the database.
Then I had to start making associations. A party belonged to a user (host), but how could I get Food to belong to more than one party but also belong to more than one user? I ended up making a 3-way join called Dish, with the Party ID, User ID, and Food ID stored. This allowed the food to be brought to party without worrying about changing anything within the actual food objects. So food had many dishes, and had many users and parties through dishes.
I created some helper methods for the Dish class that ended up being really helpful for setting up Party views. This allowed me to show different kinds of foods to create a menu for the party. I also created some User views which allowed users to see what foods users had brought in the past (maybe they didn’t want to invite a guy that just brought chips for every meal?) and the parties they had attended, through the associations created.
Some modification of the devise routes and soon enough I was halfway to a working application. I could log in, log out, see a profile page and check out different parties. But from the onset I always wanted to make sure users could only see parties they were invited to or hosting. It hurts people’s feelings to see parties they aren’t invited to!
So using the <code>current_user</code> helper method, I created a rudimentary authentication system predicated on these principles:
- Users could only see parties they were invited to or hosting.
- Hosts can edit events they are hosting, but not others.
- Users could remove dishes they were bringing, but not others.
So using a bunch of <code>if @user == current_user</code> or <code>if @party.host == current_user</code> checks, we were able to create some great authentication without any Gem bloat. No need for admin powers or different user roles. If you made the party, you were the host. Period.
Things started to click from there. Adjusting routes and controllers to account for the different actions users needed to do, like add/remove dishes to a party, add a new party, and edit attendees to parties.
I pulled some of the forms and display functions into helper methods and partials to make it a bit more DRY. I think there’s still some I can DRY up but there are some complications due to Dishes and Food being separate entities but relying upon eachother. The code I have now is pretty tight and I only partially hate it, which is a good deal less than I normally hate my Rails code.
Finally, I started adding validations in the models.. I ended up using the validates_timeliness gem for checking if a party was being created in the past (unless you’re Steven Hawking, that’s a pretty useless concept).
I started checking off things in Spec.md and I realized I never wrote this blog… so here we are! A semi-coherent rambling and walkthrough of how I made my first Rails app. I’d certainly like to be more interactive with the next one, as this was kinda cookie cutter. Once I learn how to incorporate CSS into Rails, I think I will be able to make a prettier and more in-depth app.