Project Retrospective

-Work Flow-

-What was the process or branching model each person used to pull, develop and push?
Each of us created our own development branch to make sure that we made changes separately. We pulled from the master branch to update our branch regularly. When we wanted to combine changes, we pushed to our branch, then merged to master

-What development tools/frameworks did your project use?
We used Grails as the framework for the backend. This offered support and organization for the groovy and java classes. For our front end we used REACT and react-router along with Javascript, HTML and CSS.

-How effectively did your team manage task distribution among team members?
We managed task distribution by breaking down each stage into specific task. Everyone on the team was assigned to user stories and we ensured that the work was distributed evenly. We kept each other updated on our progress and communicated through Slack. Every week, we met once to twice to discuss our progress. At each meeting, detailed minutes were taken to ensure progress.

-MVC / Design Patterns-

-What is the relationship between user interfaces, application logic, and data in your project?
We adhered to the MVC design pattern. Our user interfaces are written in javascript and communicate with the back end of our program by calling Grails controllers (typically with a fetch call). The grails controllers in turn call our groovy and/or java domain classes and then return the requested information to the calling javascript file typically as a json.
Our data is stored in the back end with GORM (Grails Object Relational Mapping) and hibernate. This allows us to easily save and modify information in our database.

-Did you implement your server-side program as a REST API?
Yes. The client and server in our project are independent of each other. Additionally, the client only deals with the front end and the server only deals with the back end. The client never interacts with the server through anything other than REST calls.
If, for some reason, we were to change the front end of our program entirely, it could still communicate with the back end since they are independent. The same applies if we were to change the back end of our program.
Some of the back end of our program queries outside databases. In these cases, our back end acts as a client to query an outside server. This allows us to access information from the internet and pass it to our users. So in this way, our server-side program is also implemented as a REST API.

-Which collection of classes serve as the M, V, and C in MVC?

-How do these classes communicate with each other? Give an example based on a user action.
Consider the example of creating a user account:
createAccount.js is coded as a React component. The component has initial states userName, password, confirmPassword, invalidPassword, success, email. (invalidPassword is a boolean, and the other states are strings)
Whenever a user modifies information in a text box, the corresponding state is modified. Thus, when the user has entered all of their information, all of the states will have been updated.
When the user clicks submit, password and confirmPassword are checked against each other to make sure they match. If they do, the component calls the CreateAccountController’s ‘create’ method via a fetch call and passes the username and password via the URL.
The CreateAccountController receives the username and password passed to it through the URL. The create method queries the database to see if there is an account with that username.
Provided the account does not already exist, the create method creates a new instance of a UserAccount object with the given userName and password parameters and saves it to the database. It then creates a new instance of a Profile object and passes the new userAccount as the ownerAccount for the profile.
The response status is set to 200 (okay) and control is returned to createAccount.js.
createAccount.js checks the response status from the fetch call and updates the success state accordingly, thereby making the result visible to the user.

-If you were to start the project again today, what aspects of code organization could be improved in your project?
We ended up with many files and dependencies that we didn’t end up using. We should have edited them out when we decided to go in new directions with our code.
We accessed accounts and profile information by username, which meant that we could not easily edit usernames. It would have been better to use the id assigned to a UserAccount by GORM to access accounts instead.
Our passwords were stored in plaintext and this is a major security issue that would need to be addressed.

-Refactor Retrospective-

-Areas of your design that you felt were strong:
Some of our design that worked out well was the listing of our trending restaurants, the design was laid out as dynamically created React objects inside of a specific, created from data that we had retrieved from an API call in the backend. This allowed us to easily retrieve a dynamic amount of data and display it seamlessly. Secondly, the organization and usage of our domain and controller classes allowed the team to easily be able to store the relevant data, as well as access it on demand without having to know how the data was stored in the first place.

-Areas of your design that you felt were weak:
Some of the greatest challenges we faced throughout the project was controlling the flow and access of our data between the various layers of our project. Sharing parameters that had been created on separate React pages with no direct path of inheritance had no clear way of being resolved to begin with, and we eventually settled on globally emitted events, which felt like really bad to have to do as it breaks the encapsulation that should have been there. The ideal solution would have been to implement a combination of EventEmitters and Redux or Flux to be able to properly control where our data is “emitted to” and when. The second challenge would have been implementing real data security practices into the website as a whole, there was no HTTPS, encryption of user data, or even security tokens for viewing different pages – it was definitely disappointing to not be able to explore that aspect of our project, as cyber security practices are more important now than ever before. The best way to have begun to implement this would have been to get familiar with the SpringSecurity Package and implement all of the various features that are available to add boilerplate level security to our project.

-Project Retrospective-

-What did your group do well?
The group did several things well. We had an open line of communication at all times through Slack. If someone had an idea, a concern or simply needed clarification they cold reach another member and have a response almost instantly. The group as a whole was very professional and courteous of one another. If disagreements came up they were usually met with a middle ground. Meetings were held once a week (or more if needed) with meeting minutes and topics of discussion recorded for future reference. Members worked together to overcome any confusions that came up over the use of Grails and React as these were new experiences for many in the group.

-What could your group have done better?
Time management could have been improved as some tasks were left till the day before submission, however this is understandable as many members have work in other courses as well.

-What did you like about the tools and frameworks you used?
Grails was a great framework to build our backend end from, as it supplied a database that allowed us to store user information. This in turn allowed the users credentials and preferences to be accessed at a later time even after the web application was terminated.
REACT was very helpful for the front end as it allowed us to create a single page web application. We were able to change the view based on user input as well as keep a user history, so in case the user uses the browser’s back buttons the program would not crash, but redirect them to the previous view. REACT also allowed us to integrate jvector map, which is a vector map that scales when zoomed in and out of, for the DISCOVER feature of our application.

-What didn’t you like about the tools and frameworks you used?
While IntelliJ is a great IDE for editing and running our application we were initially excited because of its github integration. While we did like the ability to manually merge two separate files when conflicts existed, we did encounter several occasions where files would overwrite each other without notice. We are sure this is due to the learning curve and we think it would be a great asset once the team has sufficient experience with IntelliJ and git.

CS2212 - Introduction to Software Engineering | Western University | London, ON