Sprint 3 included the hardest parts of the site that we saved for last, so we knew we were in for a challenge. My group conducted more frequent meetings where we updated our plans for the week and brainstormed ideas for difficult problems. The last meeting was focused on Trips, or user-curated collections of travel Experiences. My teammates have been making impressive pages for creating, viewing, and deleting the Trips themselves, but we had to work out the best way for adding and removing Experiences to and from Trips.

At the meeting all three of us had completely different but solid ideas to properly associate Experiences with Trips in the database, so we were really spoiled for choice. I proposed expanding our existing SQLAlchemy models and creating relationships similar to those that I made to link Experiences to Keywords and Ratings. The team member in charge of implementing the Trips database has already been performing strange magic with jQuery that completely goes over my head, and he proposed a solution using those skills. I deferred to him and in the end he created a hybrid of our approaches that works quite well. I have been testing my partners’ submissions and providing feedback, and as far as I can tell the Trips system now works exactly as it should.

While my teammates were focused on Trips I worked on the mechanism by which users can rate each others’ Experiences. At first this didn’t seem like a very daunting task, but it turned out to be more complicated than I expected. Oh sure, it would be easy to allow each user to submit an unlimited amount of ratings for each Experience and then calculate the average, but I wanted to ensure that each user can submit a maximum of one vote for each Experience. Users must also be able to rescind their votes if they choose to do so. These measures would help to prevent review bombing and always keep the average rating accurate. The hardest parts of implementing the Ratings system were working out the logic for adding user votes to an Experience and formulating the corresponding SQLAlchemy queries. So far it seems to work, but I’m still testing and watching out for bugs.

At this point I had some free time, so I added Folium maps to each Experience Details page. I wanted to give the user a reason to click on an Experience’s Details page so they would not just get all the information from the Experience displays on the Landing page. I also thought it would be fun to see the surrounding area for each Experience’s location. Another interesting addition was the large world map on the Search Experiences page, which is populated with markers for each Experience. I’m not sure if it satisfies the stretch goal of “Search for Experiences by map,” but I wanted to create a cool visual representation of Experiences around the world and provide users with another option for browsing them.

All of us were staying busy and uploading our code to our own GitHub branches. Since we were all going in wildly different directions, code conflicts would be inevitable when we would have to consolidate all our work onto the main branch. I previously discussed my concerns with managing code conflicts in my second blog post. The real conflict resolution process was somewhat stressful, but not as horrible as it could have been. Rather than each of us just adding our code to the main branch whenever we wanted, we worked out a specific order for merges that would minimize conflicts. Since my partners were working on the Trips system and mostly adding new code sections, their submissions were comparatively easy to merge using GitHub’s automated system. In contrast, my work involved removing placeholders I set earlier and other extensive rewrites, so it would have to be merged manually. This was actually pretty easy since GitHub’s Compare feature highlights the differences between two branches, but I still needed to concentrate when making manual edits and make sure I didn’t miss anything. It felt kind of like defusing a bomb. Eventually we managed to upload all of our work, and the main branch now contains a nearly finished product.

While there is still much work to be done and improvements that can be made, I am proud of the progress my teammates and I have made so far. It’s hard to believe that just two months ago I loathed the prospect of working on another group project. Almost all of my experiences with group assignments have been positive during my time in this OSU CS program, but the major exception to that occurred just last summer with my very dysfunctional CS 352: Usability Engineering group. For whatever reason the other group members did not take our work seriously, possibly because CS 352 focused on design and did not involve any coding. I had to singlehandedly complete most of the project myself and spend time fixing problems with the others’ contributions. The whole ordeal was kind of a shock, and it was one of my few low points of the last two years.

The last thing I wanted to do was start another group project in the Fall. Needless to say, I was pleasantly surprised by my current teammates, who have had my back the whole time. I was lucky to find compatible teammates who had similar goals, produced high quality results, and are just all around cool dudes. Right now our site fulfills all of the project objectives, and we threw in a few stretch goals just for fun. I am glad to be finishing this OSU CS program on a high note.