Well, I’m relieved to say that the course is still going well. My group was assigned our top choice of “Crowd-Sourced Travel Planner” for our project. With a concept like this I’ll get to build a highly interactive website and practice back-end programming and creating a database. As a side benefit, I would also find a site like this useful in real life. I have lived in Chicago for a few years and have only gone to the usual tourist attractions. How many times can I go to the Field Museum or Navy Pier without getting bored? A community-driven travel recommendations web app would hopefully suggest more unique or obscure experiences that would not be found on other travel sites. If the community provides some good suggestions for underground fight clubs or molecular gastronomy restaurants, then my app will have served its purpose.

After receiving our assignment my group had no trouble creating our project plan. We brainstormed ideas for website pages, conceptualized how user-submitted experiences would be represented, and planned out a schedule for how to get everything done. We decided to use Flask as the framework for the web app and created a GitHub repository for the group. The process of getting started has been very smooth and so far we are sticking to our schedule.

While my group is currently functioning well, it’s not all sunshine and rainbows. I usually don’t have a problem with group projects, as in previous classes each teammate would choose a section of the assignment to work on and we would then combine everything at the end. My main concern for this class is that this is my first time working on the same codebase with other people, so there is more potential for my code conflicting with that of my teammates. Basically, I am not well versed in the etiquette for managing code conflicts and not stepping on anyone’s toes.

I did get some experience with resolving code conflicts in CS 362: Software Engineering 2. The group project in that course included a good introduction to working collaboratively using GitHub. I learned a lot by performing code reviews and using GitHub pull requests to integrate my code into the main branch. However, I did not get enough practice resolving actual conflicts since each team member worked on an independent segment of the project. Any conflicting code mostly happened with unit tests we wrote for each other’s functions. These instances of overlapping code were relatively easy to solve after some quick messages back and forth, but I expect that things will be more difficult in the coming weeks.

My team started our capstone project by creating a basic Flask template on the main GitHub branch, and I am trying to be as careful and methodical as possible when adding to it. I’ve set a few rules for myself to help avoid code conflicts, or at least resolve them as easily as possible when they occur. The most important is Rule #1: “Don’t break anything”. I first submit all my code to other GitHub branches, and I won’t even think about merging into main without first testing extensively. Similarly, I will only commit new code to my branch after it is mostly finished. I don’t want to give my teammates a bad impression by uploading faulty or non-functional code. An exception to this would be if I need their help with fixing bugs. Finally, I will try to comment/document my code as much as possible and stick to the general naming and structure conventions found in the original template.

I don’t want to give you the wrong idea. I’m actually not that worried about the inevitable code conflicts that will come up. My team has had many friendly discussions so far, and I’m sure we’ll all be respectful and understanding during future code reviews. Earlier this week I even managed to merge the first versions of my website pages into the main branch. Overall, I would say we’re off to a good start.