Week 8 - What I Learned

This was supposed to be the last week working on the RADs application (as explained in previous posts), but there was a turn of events, that I will mention later on, which changed the schedule. So, this week we presented the third live demo of the application.

The third live demo included topics about authentication, the invitation system, search functionality, and a dashboard for visualizing data. One of the more complicated things that we worked on this week was integrating the backend functionality with the frontend (User Interface), because we divided ourselves into those two teams and we were working mostly independently. When the time came to mix the work of those two teams, it was certain that problems would arise: unused endpoints, different data structures, etc. This situation was both a setback and a huge learning opportunity! No one in the team had worked with (big) projects before, so even if the flow may seem obvious to other people, it was not so obvious for us. We learned that communication is vital: clearly communicating what information your program will need at a certain time to another team who is working on a related function, clearly identifying what needs to be done and assigning responsibilities, and learning about the other team’s work more than just a quick overview.

Also, it is worth mentioning that even though we were divided into two teams, the codebase lived in a single repository, using separate folders as a distinction between the backend and the frontend. This, apparently, was a bad idea, because it led to a plethora of problems when trying to deploy the application; mainly while configuring tools to do CI/CD (Continuous Integration & Continuous Deployment) because they rely on a repository to work, but there was no easy way to configure them to look inside a specific folder (they are designed to work with files on the root of the repository). All of these problems led to a team decision of splitting up the project into two separate repositories, which now allowed us to deploy, the first action was to get the backend working with Heroku.

In addition, one important lesson learned throughout this past few weeks is how to work with clients, mainly how to interpret the client’s need and manifest them in the application. We were struggling with that for a couple of week, so naturally our work got a little behind, and since the time was already so limited (just four weeks) we were worried that the application wouldn’t be ready for this last demo. We expressed our concerns, and based on other things too it was decided that we can work for another week on the project! This makes me nervous, because getting extra time usually means that the end result’s expectations are now higher, but happy to have some extra time to polish the application and motivated to show off our work.

Regarding code, this week I learned about the Interceptor Design Pattern. It was really eye-opening, because of the amount of time and work you can save by using a common or ideal design pattern for the technical problem you could be facing. This pattern allowed us to store a token and use it for requests in just a couple lines of code, while all other parts of the application are oblivious to the need of the token, meaning it gets automatically added to every request.