Welcome back to the second post of this capstone blog. To recap from last time, the project my team is working on is creating a web app for a climate change board game. Since the last post, a lot has happened behind the scenes getting ready for the project. This included four major meetings, alongside some asynchronous chats about the project.
The four meetings (with a fifth one happening in two days time from the time of this post) included an initial meeting with the team to set expectations, a meeting with our projects sponsor, and two more meetings discussing our vision for what our sponsor wants, as well as develop our initial project plan. What we got out of all these meetings was a solid idea of what technologies we want to use for our project. It’s these technologies that I want to discuss in this post.
Much like the last time, I’ll be breaking the post into sections based off of the questions I chose to answer from the assignment page for this post. Those questions are as follows.
- Why did you and your team choose the technologies you did?
- What do you like or dislike about your server/backend system/API?
- What do you like or dislike about your design modularity? Does it enable each of your to work independently?
I think that by breaking the post into these three sections, it will give you a good idea of how the past few weeks have gone for me in terms of planning, as well as my feelings in regards to the next steps of the project.
Why did you and your team choose the technologies you did?
For this project, we plan to construct an HTML web app that can be used by our projects sponsor and her students to study for their midterm exams of the class SUS 101 at Oregon State. We could have chosen to make a mobile app, but since none of our group has experience in mobile app development, we decided that we wanted to use and improve upon the skills we already have in web development.
For the backend of the site, we plan to use a Flask framework with Python3. We could have gone with Javascript and Node.js but our team unanimously agreed that since we’ve used Python throughout the program, and it’s what we’re most comfortable with, that’s what we would want to use. We want to be able to deliver our projects sponsor the highest quality product we can, so we wanted to use technologies we already had experience with.
The exception to that rule is with how we plan to host our website. The site will be hosted through Google Cloud, which is actually something I’m learning about in my cloud development course this term. Since it’s what I’m learning and have the most experience in the group with, we decided that this was going to be part of the project that I’m going to be in charge of.
What do you like or dislike about your server/backend system/API?
When it comes to using the Google Cloud servers, I’m nervous but also excited to show what I can do and how fast I can implement what I learn. From what I’ve used of them so far, I think they’re fairly manageable when it comes to making a website live, and it’s also fairly easy to implement. I think the harder part will be for me to learn how to implement games into the website. It’s not something I’ve ever done before, but I like that we’re going to be using Python to code since it’s a language I’m very familiar with. Flask is also something I have a few classes worth of experience with now, and I’m continuing to use it in my cloud development course this term, so I’m excited to use it in a more open ended environment.
What do you like or dislike about your design modularity? Does it enable each of your to work independently?
Overall I feel pretty good about the design modularity of our project. We broke up the project into three major parts
- The front end HTML/CSS
- The Backend Python/Flask
- The Google Cloud server connection
Each of us has decided which part we want to be the lead on after discussing each of our strengths and weaknesses, so I think we’re all happy with what we’re the lead on. The nice part about how we have it set up is that even though one of us is the lead for a particular section, that doesn’t mean we can’t help the other’s with their parts. It helps with planning out what needs to be done by when, but it also allows the flexibility to ask for help or to schedule time to assist our teammates. By having one of us be the lead for each section of our project, it also allows us to practice modularizing our own part in the way that works best for us which I think is also a nice bit of added flaxibility.
Overall I think the amount of planning we put into the project is going to pay off as we get started on actually coding it. I want to have one more meeting with our sponsor to make sure we have their requirements met, but after that I think we’ve set ourselves up for a successful rest of the term. I think the technologies we decided to use allow for all of us to have a sense of comfort and confidence going into the project, while also allowing us to continue to develop our skills as we get ready to enter into the workforce.
Thanks for reading and I hope to see you in the next post!
