# COMP1531 WED13C

## week_1
"How many hours of zoom calls happen everyday (on average)?"
### group1
hello
4.66 Billion internet users
We could say 2.5 billion use zoom

High school students use it for an average 6 hours
300 million daily participants
Students: 6 hours (hs)
workers: 3 hours

### group2
3 million hours maybe,,,, perhaps,,, I guess,,, unlikely,,,
no we didnt
zero thought
no thought head empty
random number

### group3
hello
**50 million hours probably**
nah this ones right trust
wait we're actually right
### group4

45 billion minutes per year
2055 hours per day

### group5

lmao no
hello world: 500 million

The hours 3 + 50 + 500 million / 3 (hrs)

## week_2
Thinking about testing
> The following set_name function is used to set a name according to the follow requirements on input:

> First Name must be at least 3 characters, and no more than 30.
> Last Name must be at least 3 characters, and no more than 50.
> First Name can only contain letters (uppercase or lowercase), and dashes.
> Last Name can only contain letters (uppercase or lowercase), spaces, and dashes.
> Middle Name can be None, but if it's not none, it can be between 1 and 50 characters.
> Middle Name cannot be longer than the first name, and it cannot be longer than the last name.

Your tutor will break you up into your project groups for this activity. Once completed you can come back together to discuss what you have.
The function returns True if the inputs are valid, and False if the inputs are invalid.

def set_name(firstName, middleName, lastName):
	pass

Write a list of inputs and associated return values. This is good practice for trying to conceptualise edge case.

|Input|Output|
|-|-|
|len(firstname) < 3 |false|
|len(firstname) > 30|false|
|len(lastname) < 3 |false|
|len(lastname) > 50|false|
|middlename not None && len(middlename) > 1 && len(middlename) < 50|true|
|len(middlename) > 50 | false|
|last name contains chars between "a-z" or between "A-Z" or "-"|true|
|first name contains chars between "a-z" or between "A-Z" or "-"|true|
|len(middlename) < len(lastname) or len(middlename) < len(first name) |true|

## week_3

Each group in the tutorial should share a summary of their teams plans and progress in relation to:
* When (or if) they are running standups and whether they are synchronous or asynchronous
* How often they meet, how they meet, and what the goals/outcomes of any meetings so far have been
* Have they or will they try pair programming
* Any challenges they've faced already after being in a group for a week
* Other group members (in other teams) are encouraged to ask questions and learn from what other groups are doing/saying.

### Alpaca
* Synchronous meeting usually about 2 times a week.
* Meetings over Teams.
* Meetings provide an update on individual progress and also give the opportunity to bring up overarching issues. Actionables are also established to do until the next meeting.
* No challenges yet.
* Planned to implement pair programming in the next iteration of the project.

### Beagle

Regular synchronous meetings: 2 standups (Monday and Friday's) for small updates and setting objectives and working through challenges, with a larger more focused meeting on Wednesdays during tute to consolidate code.

- More formal meetings will be via zoom and microsoft teams. Smaller group checkups are done via discord.

Challenges face include consistency in code (variable names, using fixtures), understanding and making assumptions regarding how each function needs to be implemented for testing. These were faced in pairs and frequently discussed with the remaining members over dm's.
- pair meetings held in discord

### Camel
Run a mix of synchronous and asynchronous standups throughout the week. Asynchronous standup held on the Sunday morning with in-person meetings on Monday ~5pm & Friday ~4pm as well as the in person meeting held during the tut.
* Asynchronous standups every Sunday
* Goals/Outcomes: discuss what we have done and going to complete, ask any questions we have
Done - Held in-person meetings to distribute tasks after catching up on the assignment spec with follow up standups being held twice for updates in progress & discussing any problems met
To Do - Roughly finish sections by Wednesday for time to edit, merge and polish code

### Dodo
* 3 meetings a week (Wednesday, Friday and Sunday) and synchronous
* On Microsoft Teams: Sunday meetings each week at 3pm, Wednesday meetings each week at 1pm to 4pm, maybe fridays at 1pm 5min before.
* Sunday bigger meeting, other are just standups
* Agreeing on data structures has been the biggest challange
* Pair programming to some extent hope
### Eagle
Synchronous meetings every 3-4 ish days to just update each other on our progress / what we have to prioritise.
Main meeting is during the tutorial where we have an extended period of time to discuss and make sure everyone is fully up to date of what has to be done.
- Meet more formally on MS teams but also short informal meetings on other messenging apps such as Discord.
- Better planning in the early stages of the project
- closer teamwork when working on code, not just when someone submits a merge request
- more frequent synchronous standups
Challenges
- Making sure everyone is on track with the tasks
- Ensuring our code is functional
- Style conflicts

## week_4
Compare these two pieces of code from a pythonic, style, and readability point of view and choose which one you prefer. When you choose one, you must justify your reasoning in the shared document your tutor gives you.

def check_password(password):
    
    if password == "password" or password == "iloveyou" or password == "123456":
        return "Horrible password"
    elif (len(password) >= 12 and any(x.isupper() for x in password) and
        any(x.isdigit() for x in password) and 
        any(x.islower() for x in password)):
        return "Strong password"
    elif len(password) >= 8 and any(x.isdigit() for x in password):
        return "Moderate password"
    else:
        return "Poor password"
   
if __name__ == '__main__':
    print(check_password("ihearttrimesters"))
    # What does this do? 

def check_password(password):
    '''
    Takes in a password, and returns a string based on the strength of that password.

    The returned value should be:
    * "Strong password", if at least 12 characters, contains at least one number, at least one uppercase letter, at least one lowercase letter.
    * "Moderate password", if at least 8 characters, contains at least one number.
    * "Poor password", for anything else
    * "Horrible password", if the user enters "password", "iloveyou", or "123456"
    '''
    horrible_pw = ["password", "iloveyou", "123456"]
    digit = False
    upper = False

    if password in horrible_pw:
        return "Horrible Password"
    elif len(password) >= 8:
        for char in password:
            if char.isdigit():
                digit = True
            elif char.isupper():
                upper = True
        if digit and upper and len(password) >= 12:
            return "Strong Password"
        elif digit:
            return "Moderate Password"
    
    return "Poor Password"

if __name__ == '__main__':
    print(check_password("ihearttrimesters"))
    # What does this do?

### Alpaca
First:
- Is more pythonic,
- Overly long conditions,
- Shorter looking,
Second:
- Has docstrings.
- Put all the horrible passwords into a list,

### Beagle
Why we did not choose First:
- has a lot of repeated code - password, conditions etc.
- conditions are very long
-
Second:
- has doc string, describes the function well
- uses a list for identifying horrible password
- Since it is set out vertically, more easily digestible and code logic is more easily understandable

### Camel
First:
- Is more pythonic in structure
- Utilises in-built libraries for checking digits and case check
- Less readable with long if statements
Second:
- Has docstring which assists to understand the functions purpose
- Has possibly longer runtime due to for loops
- it's more readable: less code in each line
### Dodo
First:
- First one is very attractive (appearance-wise), very pythonic
- Conditions are contained within the if statement
- Uses more built-in functions
- Logic of code is easier to follow (branches are easier to identify)
Second:
- booleans make for simpiler and shorter logic
- Passwords in a list easy to add more passwords that are considered bad
-

### Eagle
- First
Uses more python conventions and syntax, however makes it harder to read to someone who wouldn't know Python.
- Second
Second one is much more readable with explanation of the function and simple code.

We would prefer the the second function to the first despite it being longer, it is much more readable with the docstring explaining the function and more simpler logic. The first function is more pythonic however, the complex functions has longer conditions and is quite overwhelming for a non-python user.
Branched as opposed to long elif statements.

## Week_7
### B. Requirements
Your tutor may break you up into groups to complete this activity.

Q. What are attributes of good requirements?
Q. How could we clean this up into well described requirements? "I want a burger with lots of pickles and mayo but I need to make sure that the mayo doesn't make the burger bun really wet. Oh, and it needs to be warm, like, made less than 5 minutes ago warm but not so hot that I burn myself. I'm also not a big fan of plastic containers so if it could be in a paper bag that would be good. Actually, make that a brown paper bag, I like the colour of that"

---

### ALPACA:

#### Attributes of good requirements:

**Cohesive:** The requirement defines a single aspect of the desired business process or system.

**Complete:** The individual requirement is not missing necessary or relevant information. Additionally, the entire set of requirements should cover all relevant requirements.

**Consistent:** The requirement does not contradict another requirement.

**Modifiable:** Like requirements should be grouped together to allow similar requirements to be modified together in order to maintain consistency.

**Correct:** The requirement meets the actual business or system need. An incorrect requirement can still be implemented resulting in a business process or system that does not meet the business needs.

**Observable:** The requirement defines an aspect of the system that can be noticed or observed by a user. This is often referred to as “Implementation Agnostic” as the requirement should not specify aspects of system architecture, physical design or implementation decisions. These aspects of a system should be defined separately as constraints.

**Feasible:** The requirement can be implemented within the constraints of the project including the agreed upon system architecture or other physical design or implementation decisions.

**Unambiguous:** The requirement is written objectively such that there is only a single interpretation of the meaning of the requirement.

**Verifiable:** It can be shown that the requirement has been met by the final solution via inspection, demonstration, test, or analysis.

Requirements should be :
- Clear
- Testable/Verifiable
- Independent
- Feasible
#### Re-writing client's requirements:

* Maximise pickles count 🥒 and volume of mayo(mayo<not make bun soggy) 🤤,
* Mayo should not touch the buns 👿,
* Serve burger within 5 minutes of completion 👌
* Keep burger in heated area to maintain warmth until pickup 🥵
* Keep the burger sandwiched in your pants to keep it warm using body heat until giving it to the customer, (energy efficient and environmentally friendly)
* Store in a brown paper bag, if brown is not available get another colour and paint it brown. 🎨
* 💯💯💯💯💯 pickle man 💯💯💯 😎😎😎
#### Re-writing client's requirements (for real this time):
* Burger should contain extra pickle and mayo.
* Mayo should not touch the buns (to not make it wet).
* The burger must remain warm.
* Store in brown paper bag (not necessary).

---

### DODO:
- Answer 1:INVEST
- Unambiguous, (no misunderstanding between customer and developer)
- Testable (verifiable, being able to check if requirment is met)
- Clear (concise, terse, simple, precise)
- Correct (Validated by clients/stakeholders, Fits the criteria of the users)
- Understandable.(Well-defined， English)
- Feasible (realistic, possible)
- Independent (Not heavily reliant on other modules)

Answer 2:
- Burger made with pickles and mayonaise (5 pickles, the mayo should cover 1/3 of the patty)
- volume of mayo asymtotic behaviour to making bun soggy
- Burger needs to be warm, let it rest but serve within 5 min of making it
- Delivered in a brown paper bag (want not need)

- Burgers should be served promptly in a paper bag within five minutes and contain no more than five pickles. The amount of mayo placed into the buns should not be dripping out.

---

### CAMEL:
**Q1:**
- Unambiguous: Not using 'either this or maybe that' to avoid confusion.
- Testable: in terms of code, having small tasks/features that could be tested along the way
- Clear and concise
- Easy to understand, good words choice.
- Independent: Often having independent test features will help with debugging and having a cumulative problem

**Q2:**
Overview:
- Burger with extra pickles and mayo.
- Burger needs to be in a brown paper bag, no plastic containers

Mayo:
- Should not make the bun wet

Bun:
- Needs to be warm
- Needs to be made within 5 mins

"I want a burger with lots of pickles and mayo but I need to make sure that the mayo doesn't make the burger bun really wet. Oh, and it needs to be warm, like, made less than 5 minutes ago warm but not so hot that I burn myself. I'm also not a big fan of plastic containers so if it could be in a paper bag that would be good. Actually, make that a brown paper bag, I like the colour of that"

---

### BEAGLE:
Q1. Derived from agreed work to be completed by stakeholders, providing descriptions and contraints of a proposed system. They specify what a system should provide and do, in addition to providing any constraints to how the system will perform. Specify how the system can be tested

Q2. Use numbers. Different amounts for mayo - small, medium, large something like that
Burger should contain adequate
- pickle and mayo, with just enough mayo the bun is still dry

Burger should be served
- within 5 minutes of being made
- in brown paper bag

---

### EAGLE:
Q1.
- Specific elements that the code should provide.
- Not too broad but not too detailed.
- Designed from what the consumer demands / wants from the product.
- Concise and states contraints.
- Realistic and achievable within contraints.
- Provide clear descriptions of what is to be achieved.

Q2:
Q. "How could we clean this up into well described requirements? "I want a burger with lots of pickles and mayo but I need to make sure that the mayo doesn't make the burger bun really wet. Oh, and it needs to be warm, like, made less than 5 minutes ago warm but not so hot that I burn myself. I'm also not a big fan of plastic containers so if it could be in a paper bag that would be good. Actually, make that a brown paper bag, I like the colour of that"
- Create a burger, making sure to add a lot of pickles.
- Add lots of mayo, but ensure that the burger is not too wet.
- Ensure the burger is made recently so it retains its heat, but make sure it is not too hot to a point where it could harm the consumer.
- Place burger in a brown paper bag and deliver to consumer.

- pickles + mayo -> mayo doesn't make it too wet
- made < 5 minutes ago but not too early that it burns
- brown paper bag

### C. User Stories
Consider the core requirements of UNSW Streams:

1. Ability to login, register if not registered, and log out
1. Ability to see a list of channels
1. Ability to create a channel, join a channel, invite someone else to a channel, and leave a channel
1. Within a channel, ability to view all messages, view the members of the channel, and the details of the channel
1. Within a channel, ability to send a message now, or to send a message at a specified time in the future
1. Within a channel, ability to edit, share between channels, remove, pin, unpin, react, or unreact to a message
1. Ability to view anyone's user profile, and modify a user's own profile (name, email, handle, and profile photo)
1. Ability to search for messages based on a search string
1. Ability to modify a user's admin permissions: (MEMBER, OWNER)
1. Ability to send message directly to a user (or group of users) via direct messaging (DM).

Pick two of the above and write a series of user stories that encompass each requirement:
* Discuss as a class the **potential target audience**, and use this as your type of user;
* UNSW STAFF MEMBER
* Write acceptance criteria for each story and discuss when to use Scenario-based and Rule-based acceptance criteria

### D. Use Cases
Pick one of the above requirements you have written stories for and write a use case for the flow of interaction.

### Alpaca
- Target audience: UNSW Staff member

#### Ability to search for messages based on a search string:
- As a UNSW staff member, I would like to be able to search messages so I can reference responses easily to students.

#### Ability to view anyone's user profile, and modify a user's own profile (name, email, handle, and profile photo):
- As a UNSW Staff member, I want to be able to view a student's profile to ensure they are enrolled.

Acceptance Criteria:
- - A list of all available users
- - A way to view detailed information about a single user

### Beagle
6.
Target Audience: STAFF MEMBER

As a UNSW staff member, I would like to be able to (within a channel) have the ability to edit, share between channels, remove, pin, unpin, react, or unreact to a message, so that course announcements in the form of messages are up to date and be able to respond to / oranaise a class.

- I would like to be able to react (correct or incorrect) to student questions without having to reply, which clutters the channel message feed

### Camel
1. Within a channel, ability to send a message now, or to send a message at a specified time in the future

Target Audience: UNSW Staff Member
- As a UNSW Staff member I would like to be able to send a message to students with time-stamps. I can also make sure notifications get sent to students within a scheduled time

Acceptance Criteria:
-
### Dodo
1. Ability to search for messages based on a search string

As a UNSW staff member, I want to search messages so that I can see evidence
of student teamwork and communication.

As a UNSW staff member, I want to be able to search for messages sent by students so that I can look up a student's question and conversation that lead up to that question.

Acceptance Criteria:
- A search bar on top of web page
- Includes a filter to look up messages from a specific student at a specific time frame

### Eagle
Doing 7 and 8!!!! Don't steal !!!😈😈😈😈
7. Ability to view anyone's user profile, and modify a user's own profile (name, email, handle, and profile photo)

Target audience: UNSW student or staff

Any student or teacher will have the ablity to view any other's profile so that they can obtain some basic public information about other users.
Any student or teacher can modify their profile so that they can share basic information about themselves.
Only the user can modify their own profile.

9. Ability to search for messages based on a search string
The teacher and students of a certain class/group can be able to search for

## Week 8
Break into groups of 3. The only rule is that no one in the group of 3 can be in your project team. In your team, you will be given 5-10 minutes to analyse the current API specification for your project, and to (as a team) propose one (or a couple) of new "route(s)" (i.e. url) to the interface to add some cool functionality to the product. Find something that you as a team get excited about. You'll be sharing your answer with the class, and will be expected to provide for each route:

* A route (i.e. /this/url/name)
* A CRUD method (e.g. GET)
* Input parameters
* Return object
* Description of what it does

### Group1
fun stuff

reply to messages

@APP.route("/messages/reply/v1", methods=["POST"])
def message_reply_route():
data = request.get_json()
token = data['token']
u_id = data['u_id']
msg_id = data['message_id']
output = messages_reply(token, u_id, message_id)
return dumps(output)

Description: reply to a message and notify the original sender that their message has been replied to

@APP.route("/calender/v1", methods="")
return dumps(calender_v1().get_json())

@APP.route("/addfriend/v1", methods="")

### Group2
Sending pictures/videos (HTTP METHOD: PUT)
parameters:
- link
- dm_id/channel_id
returns:
- nothing
description:

@APP.route("/messages/sendpicture/v1", methods=["POST"])

def message_sendpicture_v1():
data = request.get_json()
token = data['token']
message_id = data['message_id']

response = message_send_pic(token, message_id)

### Group3
route: /message/all

@APP.route("/message/all", methods=['POST'])

input {message, token}

return {[{message_id, u_id}]}

Sends indivdual message to everyone, stream owners only for annoucments etc
Checks token to see if stream owner (will raise Access Error if not)
Runs general checks for valid user
Will return list of dictionairy containing message_id and u_id to know associated message

### Group4
- Displays a GIF after being passed link into a message chat
route: /messages/sendgifs/v1
@APP.route("/messages/sendgifs/v1", methods = ['POST'])

Parameters: {token, link, channel_id}
return {'message_id'}

Description:
-check if token is valid
-sends a gif to a channel

### Group5
something cool
likes / dislikes for messages
@APP.route("message/like", methods = ["POST"])
Input parameters:
- User token
- Message ID
- Like/dislike ID (e.g like = 1, dislike = 0)

Return: {Total net likes}

Description: Similar to YouTube comments, get a general idea of each user's opinion on the message. This could be added in conjunction with reacts.

call scheduling (calendar/timetable type)
@APP.route("/schedulecall/", methods = ["POST"])I
Input parameters:
- Channel_id / dm_id
- Time
- User token

Return: {
"channel/dm_id": (id)
"scheduled_time": (time)
"creator": (name or user_id)
}

Description: Schedule a call with a dm/channel at specific time, and user must be a pre-existing member. Sends notification at time.

## Template
### Alpaca
### Beagle
### Camel
### Dodo
### Eagle