# Friday 11b
[toc]
## WEEK_2
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.
### GROUP_1 AERO
|Input|output|
|-|-|
|len(firstname) < 3 characters| false|
|len(firstname) > 30 characters| false|
|len(lastname) < 3 char | false|
|len(lastname) > 50 char | false|
|len(lastname) > 50 char | false|
|len(middlename) > 50 char | false|
|len(middlename) > len(firstname) | false|
|len(middlename) > len(lastname) | false|
|firstname contains anything but letters and "-" |false|
|lastname contains anything but letters and "-" and " "|false|
|If anything else| true|
### GROUP_2 BLINKER
|Input|output|
|-|-|
|len(firstname) < 3|false|
|len(firstname) > 30|false|
|len(lastname) < 3|false|
|len(lastname) > 30|false|
|firstname contains anything but ("a-z")("A-Z") or ("-"")|false|
|lastname contains anything but ("a-z")("A-Z") or ("-") or (" ")|false|
|middlename = ()|true|
|len(middlename)>len(firstname) or len(middlename) > len(lastname)|false|
### GROUP_3 CACTUS
|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|
### GROUP_4 DORITO
|Input|output|
|-|-|
|len(firstname) < 3 characters| false|
|len(firstname) > 30 characters| false|
|len(lastname) < 3 characters| false|
|len(lastname) > 50 characters| false|
|len(middlename) > len(firstname)|false|
|len(middlename) > len(lastname)|false|
### GROUP_5 ECHO
|Input|Output|
|-|-|
|len(firstname) < 3 characters| false|
|len(firstname) > 30 characters| false|
|len(lastname) < 3 characters| false|
|len(lastname) > 50 characters| false|
|len(middlename) > len(firstname)| false|
|len(middlename) > len(lastname)| false|
|len(middlename) > 50 | false|
## 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
### GROUP_1 AERO
* We have had synchronous standups.
* We conduct meetings two times a week on Wednesdays and Sundays. We meet using the voice chat feature on Microsoft Teams. Primary goals include establishing a common data structure, completing testing, clarifying specs, discussing assumptions, etc.
* We have not, and possibly will not try pair programming.
* Some group members are struggling to balance tasks.
### GROUP_2 BLINKER
* Both synchronous and asynchronous standups, two or three times a week.
* Meet on Wednesdays, smaller meeting on Friday during labs, used to catch up on individual progress and how problems might be solved.
* Haven't engaged in pair programming practices.
* Time is difficult for some, getting used to git etiquette and interpreting project spec has caused some minor problems.
### GROUP_3 CACTUS
* Synchronous meetings - Friday, will need to schedule asynchronous meetings throughout the week
* Dividing iteration 1 into functions for each person to complete
* Haven't tried pair programming
* Challenges : finding a time where everyone is available
### GROUP_4 DORITO
* synchronous meetings - 2 a week (wed/fri)
* asynchronous standups - 3 per week (Sun, Tues, Thurs)
* Challenges: Iteration 1 :'(
*
### GROUP_5 ECHO
* meeting up on fridays during lab times
* Meetings on monday mornings
* Running asynchronous standups on a teams channel.
* We may try pair programming for Iteration 2
## WEEK_4
```python
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?
```
```python
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?
```
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.
### GROUP_1 AERO
Second code is much better style wise
* Contains docstring
* Has proper variable names and splits it up instead of calling several functions and using their output
* Declaring horrible passwords at start more readable
* Clearer if statements, as they are concise and not 3 lines long
* Cringe nested if statements (ewww) ._.
### GROUP_2 BLINKER
Code 2 looks a lot nicer and is a lot easier to follow.
* The first if statement in code 1 is far too long and the replacement with the "password in list" is a lot easier to read
* The if/elif statement were broken up in a way that makes it easier to read in code 2
* Code 2 contains a doc string that explains what the code is doing
* The any statements in code 1 are confusing to follow.
### GROUP_3 CACTUS
2nd one
- uses list for horrible passwords
- function docstring
- effective use of variables
### GROUP_4 DORITO
File 2
- has docstring
- list for bad passwords
-
### GROUP_5 ECHO
- 2nd one
- Includes a docstring in the function.
- Uses a list to contain all the horrible passwords.
- Concise lines of code
### Together
Q. What are attributes of good requirements?
* Specficity -> It has to be specific
* Clarity -> It clear
* Direction, Timing
* Feasible -> realistic, we can actually achieve this requirement
* Testable, measuribility
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"
* Who what and how
* someone shoudld something something
* Burger should be delivered in a brown paper bag
* Burger should be delivered warm between 50dc < x < 60dc
* Burger should be delivered within 5mins of makage
* Burger should be made with 5 pickles
* Burger should be made with 1 tablespoon of mayo -> (mayo until not soggy)
* Burger should not be soggy
* Burger should not burn customer
* Burger should be delivered warm
## WEEK_5
https://www.youtube.com/watch?v=GfL5zOhpB14
### GROUP_1 AERO
* Input:
- POST: Commenting on video (post)
- GET: Sharing video to others (gets the unique link)
- POST: Subscribing to channel.
- PUT: Editing video settings (1080p, playback speed)
- DELETE: Deleting comments.
- PUT: Editing comments
* Output:
* GET: Video stream (in VP9 video codec)
* GET: Video recommendations
* GET: Channel details (subscriptions, name)
* GET: Video Details (View count, upload date etc)
* GET: time stamp arguments lead to specific point in video.
* GET comments
### GROUP_2 BLINKER
Get:
* The actual video
* Number of likes/dislike
* Showing other comments
* Show related videos
* Date of upload
* Views
Post:
* Commenting on a video
* Posting a video on youtube(?)
Put:
* Like/Dislike
* Commenting increases number of comments(?)
*
### GROUP_3 CACTUS
Get: Number of views/like/dislikes, the video, recommended videos
Post: Comments, like/dislike
Put:
Delete: delete comments
### GROUP_4 DORITO
* get - login info, sub count, account info, video, recommendations, sharing, settings for vid, captions
* put - sub count, comment, like/dislike, views count, video quality and speed
* post - Posting a toxic comment, uploading a video
* delete - comment, like/dislike, sub,
### GROUP_5 ECHO
* Get - getting list of suscribers, pressing the share button
* Post - posting a comment, posting a video, post reply
* Put - subscribe to channel, or like/dislike video, editing a comment
* Delete - deleting your comment
## WEEK_8
### GROUP_2 BLINKER
* url/channel/invite/decline
* post
* token, c_id
* none
* allows a user to decline an invitation
* url/admin/censor
* post/put
* token, c_id, [censored words]
* complete list of all censored words
* allows admin to censor bad words
* url/admin/uncensor
* delete
* token, c_id, [uncensored words]
* complete list of all censored words
* allows admin to uncensor censored words
* url/user/block
* post/put
* token, u_id
* none
* allows a user to block another user from inviting or tagging the user
* url/user/mute
* post/put
* dm_id, channel_id, token, time
* none
* allows a user to place a time where they can't be notified by a particular dm or channel
### GROUP_3 CACTUS
- user/delete
- DELETE
- token
- Returns { }
- Allows user to delete their account
- channels/delete
- DELETE
- token, channel_id
- Returns { }
- Allows user of channel to delete the channel
-
### GROUP_4 DORITO
* auth/change_handle
* PUT method
* args: {token}
* message/react
* POST method
* "User can react to messages in a DM or Channel they are part of"
* Args: {token, dm_id, message_id, reacc}
* Return: {}
* call people
* POST method
* "User can start a call in a channel or DM they are part of"
* Args: {token, dm_id}
* Return: {}
* channels/delete
* DELETE method
* "Channel owner can delete channel"
* Arguments: (token, channel_id)
* Return: {}
* auth/delete
* DELETE method
* post gifs/memes
* POST method
* Return: {}
* [](https://www.youtube.com/watch?v=dQw4w9WgXcQ)
* * ya got me
* Start voice / video call
### GROUP_5 ECHO
* /groupcall/start
* POST method
* "User can start a group call."
* Arguments: (token, channel_id)
* Return: {group_call_id}
* /groupcall/join
* PUT method
* "Adds a user to a group call if they are apart of the channel"
* Arguments: (token, group_call_id)
* Return:{}
* /groupcall/leave
* DELETE method
* "Removes user from call"
* Arguments: (token, group_call_id)
* Return:{}
*
## WEEK_TEMPLATE
### GROUP_1 AERO
### GROUP_2 BLINKER
### GROUP_3 CACTUS
### GROUP_4 DORITO
### GROUP_5 ECHO