Workflow

In this section you will describe the workflow your team used to do development.

What was the process or branching model each person used to pull, develop and push?
We had a master branch and a dev branch from the master. Each team member branched from the dev branch in order to work on the codebase. Changes were first merged with the dev branch then once everything was running smoothly, the changes were merged to the master branch.

What development tools/frameworks did your project use?
Our project used: Firebase, angularjs, angularfire, JavaScript, HTML, CSS, nodeJS,

How effectively did your team manage task distribution among team members?
Each member was assigned an equal amount of tasks. However, in the end certain tasks were more difficult than others causing some members to have a larger work load than others, however if a group member struggled another would join and help that member which allowed us to finish our work.

MVC / Design Patterns

What is the relationship between user interfaces, application logic, and data in your project?
We tried to separate the user interface, application logic and data as best we could. Codetivity.ejs held our user interfaces while Firebase.js, Codetivity.js, Firepad.js and ChatApp.js held most of the application logic and data.

Did you implement your server-side program as a REST API?
No. Data transfer and requests were facilitated by Firebase.

Which collection of classes serve as the M, V, and C in MVC?
In general, Codetivity was our view, Firebase our controller and Firepad our model.

How do these classes communicate with each other? Give an example based on a user action.
Codetivity sends user input to Firepad which notifies the database (Firebase). Firebase then syncs these changes to the database and Firepad is able to push these changes to every running Codetivity session. As an example, if the user enters a word into the coding window (in Codetivity), Firepad receives the word, and pushes it to the Firebase database. Firebase updates the database with this word and Firepad is able to push these changes too all running Codetivity sessions, so every user sees the new word added to the coding window in real time.

If you were to start the project again today, what aspects of code organization could be improved in your project?
As we were getting started with the project, using a FAN (Firebase, Angular, Nodejs) template seemed to help with getting acquainted with the strucutre of a typical FAN stack web application. However, as we added our own files, classes and funcitnality, we often had to spend a lot of time understanding the organization of the template in order to understand how to organize our files. If I were to start the project again, I would begin with a clean slate and add folders, files and classes as necessary. Doing this would require understanding Nodejs at a deeper level in order to set up the website framework properly. However, I belive this would be worth it as the web app footprint would be decrased and the overall strucutre of our code would be cleaner.

Refactor Retrospective

In this section, suggest possible refactoring of your code in order to improve its design and software quality.

Areas of your design that you felt were strong:
The decision to use the Firebase database significantly improved our interaction with the database in our project. Firebase offers simple but powerful abstracted commands that allowed us to easily accomplish a lot with our code without necessarily having to write a lot of code. For example, the function firebase.auth().onAuthStateChanged() allowed us to easily ensure certain parts of code were run only when there was a change in the autorization state of the user - for example the user logging in. Using the above function, we could grab the user's id only when the authorization state changed and a valid user was using Codetivity.
Another nice decision was to separate the chat functionality into chatApp.js. This helped in integrating chat functionality since the chat could be worked on completely separate from the rest of Codetivity. This also allowed our developers to use a dummy UI in order to test chat functionality without having to first integrate chat with our main page. This saved a lot of integration time and also meant that we could be almost certain that any issue with the chat was likely a result of the code inside chatApp.js

Areas of your design that you felt were weak:
One area we could have improved on was the overall integration and usage of Angular featrues in our website. For the most part, only the chat and coding window used Angular, while other features such as the file viewer were done in vanilla JS and HTML/CSS. While the end result was still beautiful and funcitonal, the overall cohesion suffered as we had to integrate Angular specfici features such as decalring a controller with vanilla JS parts. A reason why this ended up happening was our team had to learn Javascript, HTML, CSS and Angular all at the same time. This meant in order to get the website running quickly and to meet our project deadlines, the website had to begin using vanilla JS, with Angular parts and features added later. If more time was allowed to get familiar with JS and Angular, the website could've been made using Angular from the get-go.
Another area we could have improved on was the separation of CSS styling in our project. Since we used a bootstrap template to help design the website, we had CSS styling commands spread accross many different files. For example, when we were adding the online members functinality, the styling for this part was split across codetivity.ejs, codetivity.css, firepad-userlist.js, firepad-userlist.css and index.css. There was a specific bug where the current members would sink below the page. This meant we had to look at multiple files in order to track down and fix the cause of the bug. If all the styling for the online members was in a single file, it would be straightforward to read the file, and debug the styling to figure out the cause. Again, limited time meant we were often satisfied with leaving the styling wherever it was once it was working, so we could move on to the next stage of the project. Given more time, we would be able to consolidate styling into a single file.

Project Retrospective

What did your group do well?
Each member took time to get familiar with the frameworks and languages we proposed would be required to finish specific parts of the project. This made it easier for different members to specialize and focus on certain parts of the project as not everyone had to be an expert in every field. Our group members also had meetings outside of weekly meeting hours with each other to collaborate and finish work that was assigned to a small sub section of members. This ensured key parts of the project were being worked on in a timely manner. The back and front end also had key members who communicated with each other to specifically put together everyone’s work.

What could your group have done better?
In the end certain parts of the front end and back end were more significant than others causing some group members to have a larger work load than others. This could have been avoided if more members were assigned to the more difficult tasks rather than assigning an equal number of tasks to each individual.

What did you like about the tools and frameworks you used?
The primary tools and frameworks we used; firebase, angularjs, angularfire, and nodejs were all popular tools, because of this the documentation was more modern and easy to understand as many questions we had were already posted and answered online on popular sites such as stackoverflow.

What didn’t you like about the tools and frameworks you used?
A majority of the tools and frameworks we used required experience in JavaScript which our group was not familiar with. This meant we had to spend time getting familiar with JavaScript before we could even spend time getting familiar with the frameworks we were going to utilize.