---
# System prepended metadata

title: CSC 301 A2 Pair Programming README.md

---

# CSC 301 A2 Pair Programming README.md

**Server URL**: http://ec2-13-233-207-153.ap-south-1.compute.amazonaws.com:5000/


**Program Design**: 
* We split up the tasks into two parts: Gwen was responsible for coding the APIs for "time_series", and Rahul was responsible for coding the APIs for "daily_reports", and each was to write tests for their respective APIs. 
* We decided early on to use Python's pickle library to store files uploaded, rather than using a formal database. This is because we valued performance over convinence. Spawning a database and having that enforce constraints would heave been an easier feat, although we choose to have in-memory database to save the roundtrip from our server to the database and back. Since the spec specifically mentioned that the tested values will be for a small number of records, in-memory data storage is the way to go.
* We used Python and the Flask framework. We used Blueprints from Flask to organize the endpoints, and then registered the blueprints with the app with the appropriate url_prefixes. This way, we can test and deploy the APIs regardless of where the app is served/what the root path is. 
* We used the pipe and filter architecture to decouple every query as a filter that can be added on demand. This keeps the code clean and maintaniable. If a future requirement requests for another filter option, the Pipe and filter architecture simply requires the reation of another filter and added to the filteration pipe.
* While the time_series and daily_report APIs could potentially employ similar logics, we decided to use pandas dataframe to perform the filtering functions for the time_series APIs and a custom pipe-and-filter architecture for the daily_report APIs, for the sake of learning and comparison. Therefore, the two parts present minimal coupling but high internal cohesion. 
* We deployed the APIs on an AWS EC2 instance. First, Github Actions will call a build api to jenkins, jenkins will then do a git pull, run tests and verify if they have passed. If yes, it will proceed to stop the existing API then redeploy the new version of the APIs.

**Pair Programming Challenges**: 
Our team setup the "Code with Me" feature on PyCharm to work on our pair programming tasks. This required one party to invite the other to their pycharm IDE.

1. After combining the APIs and running the tests, Gwen found that pytest generated error messages from Rahul's part. It would have been time-consuming for Gwen to debug Rahul's part, so Gwen asked Rahul to join a pair programming session with a concurrent voice call. Rahul remotely observed the test results and identified the source of the error messages, researched the issue on his local machine, and edited his code on Gwen's local machine remotely. The issue was resolved within 15 minutes. 
    
2. After writing the CI pipeline for "build" using Github Actions, Gwen had difficulty incorporating the CD pipeline into the workflow file. Using a pair programming session, Rahul examined the workflow file Gwen was working on, explored alternatives options for CI/CD, and demonstrated how to use jenkins to accomplish the same goals (i.e. automatically deploy to an AWS ec2 instance).


**Test Coverage Values**:

We used pytest and pytest-cov to run our tests and generate the test coverage report. This report can be seen on the terminal when the following command is run: 

```
python3 -m pytest --cov-report term --cov=app --cov=blueprint_time_series --cov=blueprint_daily_report tests/
```

![](https://i.imgur.com/dAEPHD8.png)




**CI/CD Screenshots**:
![](https://i.imgur.com/XmoEAPL.png)
![](https://i.imgur.com/tBaDBPn.png)
