What I Did For My Senior Capstone Project
During my last semester at university, I took a required course that gave me a chance to take everything I learned previously and apply it to a final project (Senior Capstone Project). I worked on an agile team with three other students with my main focus on front-end UX/UI design with mobile support and creating a custom back-end JSON API scraper for recipes and Google images.
We decided to create a mobile-friendly web-based application that delivers food recipes based on the users’ custom food pantry. We named it Presto Pantry.
During our initial Sprint planning phase, we decided to use Figma to lay out our web pages and organize what functionality we wanted to implement on each page.
Here is a list of the technologies we used:
Initial Planning, Database Modeling and Sprint Management
Figma, Trello, dbdiagram.io
Web Framework
Python3/HTML/CSS, Django, BootStrap, PostgreSQL (prior to AWS RDS deployment)
Cloud Services (AWS)
RDS, S3, EC2, IAM (Group and User Management), CloudWatch
Recipe and Image API
Spoonacular API, Google Images Custom Search API
User Authorization and Authentication
Google OAuth 2.0
CI (Continuous Integration), Security, Metrics
Travis CI, GitGuardian, Python Radon, Sonar Cloud
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Why This Tech Stack?
One of the conversations my team and I had during the initial planning phase was about the technologies we should use based on the time frame we were given to complete the project.
Each of us discussed what technologies we’ve used in the past and what we’re familiar with and also what technologies none of us have touched before but were interested in learning.
What We Were Familiar With
Python
We wanted to create something that was Python-based because all four of us had been exposed to Python before so instinctively we decided to use Django for our web framework.
What We Wanted To Learn
AWS
All of us were interested in using (AWS Amazon Web Services) to deploy our application. We thought it would be a great way to gain some exposure to one of the most popular cloud service providers and to gain some hands experience with some of the popular services like EC2, RDS (management of our data), IAM (group and user management), S3 (for our static files like images and CSS)
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Landing Page
The Landing Page Sign Up / Login buttons are easily accessible for a newcomer. Active carousel options are provided for alternate user-driven routings such as our Recipe Search page and Recipe Community Page.
Sign Up Page and Login Page
There are various enforcements in place to drive stable back-end design and secure user experience with meaningful error messaging provided during sign-up and login and a supplemental option is available through Google OAuth.
My Account Page
Enables users to edit all account details such as display name, email address, password, and profile name after account creation.
Ingredient Search Page
Upon searching for ingredients, users will be offered various products to add to their personal pantry for use in recipe searches. During the time of the project Spoonacular API did not return an image of the ingredient that was searched for, so in tandem, we would use Google Images search API to retrieve an image of the ingredient and return detailed results to the user.
Pantry Ingredients page
Displays current ingredients present in a user’s pantry. From here, users can choose to add more ingredients, remove some or all ingredients, or begin searching for recipes matching their ingredients. The information is stored using PostgreSQL prior to our deployment with AWS RDS during our production phase.
Recipe Results Page
Once a user is satisfied with the pantry ingredients they’ve personalized, they can search for recipes detailed with used ingredients, unused ingredients, and missing ingredients from their list.
Key Takeaways
One of the most important things I learned during this project was keeping an open line of communication between team members. This is useful because everyone has a different schedule outside of this project and things change very quickly due to that fact.
Sprint planning was also crucial. During our initial planning phase, we took almost two weeks to understand exactly what we wanted to implement moving forward. I believe this saved us an abundance of time when it came to creating the project because we had a clear idea of what we wanted to do!
Documentation takes a little extra time initially but when having to reference back on certain features that we implemented it was easy for others on the team to look through and understand the functionality of the code.
Summary
After a semester of work with a team of four we were able to successfully complete our project including some icebox features that were created during the beginning phases of the project.
We wanted to create a responsive web application that was mobile-friendly for users to add ingredients from their physical pantry to an e-pantry and simply receive a list of recipes that they can create based on those ingredients.
