mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 13:24:05 -06:00
Merge branch 'hugo' of https://github.com/JetHughes/quartz into hugo
This commit is contained in:
Jet Hughes
commit
a5d494182a
@ -2,12 +2,14 @@
|
|||||||
title: 🪴 Quartz 3.2
|
title: 🪴 Quartz 3.2
|
||||||
---
|
---
|
||||||
|
|
||||||
|
[index](notes/index.md)
|
||||||
|
|
||||||
Host your second brain and [digital garden](https://jzhao.xyz/posts/networked-thought) for free. Quartz features
|
Host your second brain and [digital garden](https://jzhao.xyz/posts/networked-thought) for free. Quartz features
|
||||||
|
|
||||||
1. Extremely fast full-text search by pressing `Ctrl` + `k`
|
1. Extremely fast full-text search by pressing `Ctrl` + `k`
|
||||||
2. Customizable and hackable design based on Hugo
|
2. Customizable and hackable design based on Hugo
|
||||||
3. Automatically generated backlinks, link previews, and local graph
|
3. Automatically generated backlinks, link previews, and local graph
|
||||||
4. Built-in [[notes/CJK + Latex Support (测试) | CJK + Latex Support]]
|
4. Built-in [ CJK + Latex Support](None)
|
||||||
5. Support for both Markdown Links and Wikilinks
|
5. Support for both Markdown Links and Wikilinks
|
||||||
|
|
||||||
## Get Started
|
## Get Started
|
||||||
|
|||||||
58
content/dn/1.md
Normal file
58
content/dn/1.md
Normal file
@ -0,0 +1,58 @@
|
|||||||
|
---
|
||||||
|
title: 1
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-31
|
||||||
|
> Never deny a diagnosis but do deny the negative verdict that may go with it.
|
||||||
|
> — <cite>Norman Cousins</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| 203 writeup | 2hr | |
|
||||||
|
| 201 assignment | 2hr | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## 1 Todo's
|
||||||
|
- [x] 13:00 Info201 Lecture
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [x] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 1hr Question 1
|
||||||
|
- [ ] 45min Question 2
|
||||||
|
- [ ] 30min Question 3
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
18
content/dn/2022-03-07.md
Normal file
18
content/dn/2022-03-07.md
Normal file
@ -0,0 +1,18 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-07
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
#### TODO
|
||||||
|
- [x] mark off cosc202 lab
|
||||||
|
- [x] cosc 202 lecture
|
||||||
|
- [x] cosc 201 lab
|
||||||
|
- [x] 201 lecture 3
|
||||||
|
|
||||||
|
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
|
|
||||||
22
content/dn/2022-03-08.md
Normal file
22
content/dn/2022-03-08.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-08
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
#### TODO
|
||||||
|
- [x] cosc 201 lecture
|
||||||
|
- [x] info 203 lecture
|
||||||
|
- [ ] info 201 lecture
|
||||||
|
- [x] 202 lab (help with grep for {)
|
||||||
|
- [x] stocks notes
|
||||||
|
- [x] review
|
||||||
|
- [x] look at flats
|
||||||
|
- [x] fixes for polish 2,4,5,
|
||||||
|
- [x] fixes for polish 6
|
||||||
|
- [x] review 201 lecture notes
|
||||||
|
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
22
content/dn/2022-03-09.md
Normal file
22
content/dn/2022-03-09.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-09
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
#### TODO
|
||||||
|
- [x] 203 Lecture
|
||||||
|
- [x] module 08 swedish fix
|
||||||
|
- [x] polishes fixes 7 8 10 14
|
||||||
|
- [x] 203 tutorial
|
||||||
|
- [x] 201 tutorial
|
||||||
|
- [ ] copy key
|
||||||
|
- [x] post long point vids / send to leeto
|
||||||
|
- [x] start cosc201 lab03
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
22
content/dn/2022-03-10.md
Normal file
22
content/dn/2022-03-10.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-10
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
#### TODO
|
||||||
|
- [ ] copy key
|
||||||
|
- [x] 3 examples for 203 assignment
|
||||||
|
- [x] polish fixes
|
||||||
|
- [x] 202 lecture
|
||||||
|
- [x] cosc 201 lab
|
||||||
|
- [x] info 201 lecture
|
||||||
|
- [x] get out meat
|
||||||
|
- [x] refactor 201 notes
|
||||||
|
- [x] cosc 201 lecture
|
||||||
|
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
|
|
||||||
33
content/dn/2022-03-11.md
Normal file
33
content/dn/2022-03-11.md
Normal file
@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-11
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-11
|
||||||
|
## Todo's
|
||||||
|
- [ ] work on norwegian modules or polish fixes
|
||||||
|
- [x] 30 min typing
|
||||||
|
- [x] 202 lab
|
||||||
|
- [x] info 201 lecture
|
||||||
|
- [x] info 201 lab
|
||||||
|
|
||||||
|
## Stocks
|
||||||
|
|
||||||
|
|
||||||
|
## Daily metrics
|
||||||
|
- typing time: 27
|
||||||
|
- typing avg: 57
|
||||||
|
|
||||||
|
- work time: 0
|
||||||
|
|
||||||
|
- [x] exercise
|
||||||
|
- [x] surf
|
||||||
|
- [x] leave house
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
|
|
||||||
27
content/dn/2022-03-12.md
Normal file
27
content/dn/2022-03-12.md
Normal file
@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-12
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-12
|
||||||
|
## Todo's
|
||||||
|
- [ ] ...
|
||||||
|
## Stocks
|
||||||
|
brief notes
|
||||||
|
|
||||||
|
## Daily metrics
|
||||||
|
- typing time:
|
||||||
|
- typing avg:
|
||||||
|
|
||||||
|
- work time:
|
||||||
|
|
||||||
|
- [x] exercise
|
||||||
|
- [x] surf
|
||||||
|
- [x] leave house
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
24
content/dn/2022-03-14.md
Normal file
24
content/dn/2022-03-14.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-14
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-14
|
||||||
|
## Todo's
|
||||||
|
- [x] review notes from saturday sunday and toaday
|
||||||
|
- [x] 202 lecture at 11:00
|
||||||
|
- [x] 201 lab
|
||||||
|
- [x] upload module 03 and fix 08
|
||||||
|
- [x] 4th example for 203 What is Usability
|
||||||
|
- [x] put hdmi cable back
|
||||||
|
- [ ] add git usage note
|
||||||
|
- [x] start 201 assignment 1
|
||||||
|
- [ ] watch 203 videos 1-2
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
34
content/dn/2022-03-15.md
Normal file
34
content/dn/2022-03-15.md
Normal file
@ -0,0 +1,34 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-15
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-15
|
||||||
|
## Todo's
|
||||||
|
- [x] refactor git notes
|
||||||
|
- [ ] watch 203 videos
|
||||||
|
- [x] call dad
|
||||||
|
- [ ] spending review
|
||||||
|
- [x] 203 lecture
|
||||||
|
- [x] 201 lecture
|
||||||
|
- [x] info 201 lecture
|
||||||
|
- [x] 202 lab
|
||||||
|
- [ ] norwegian modules
|
||||||
|
- [x] review notes for today
|
||||||
|
- [x] refactor 203 notes
|
||||||
|
- [x] 201 lab part 1, 2
|
||||||
|
- [ ] review dropping info 201/202
|
||||||
|
|
||||||
|
# Daily Laws
|
||||||
|
## Mind
|
||||||
|
> 'Cause all that's gonna do really is accelerate the anxieties that I wish I could alleviate
|
||||||
|
> I'm ready to lose my mind, but instead I use my mind
|
||||||
|
|
||||||
|
## Body
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#:)
|
||||||
|
|
||||||
44
content/dn/2022-03-16.md
Normal file
44
content/dn/2022-03-16.md
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-16
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-16
|
||||||
|
## Reminders
|
||||||
|
- [ ] investigate python position
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
|
||||||
|
## Todo's
|
||||||
|
- [x] Norwegian 4
|
||||||
|
- [x] Lecture 203
|
||||||
|
- [x] tut 203
|
||||||
|
- [x] tut 201
|
||||||
|
- [x] review notes
|
||||||
|
- [x] review dropping 201
|
||||||
|
- [x] spending review
|
||||||
|
- [x] refactor 203 notes
|
||||||
|
- [x] learn about heading links
|
||||||
|
- [ ] 203 assignment
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| --------------------------| ------ | -------|
|
||||||
|
| no 4 | 2hrs | 1hr40 |
|
||||||
|
| review notes | 0.5hr | 28mins |
|
||||||
|
| review 201 | 0.5hr | 11mins |
|
||||||
|
| spending review | 0.5hr | 1.5hrs |
|
||||||
|
| refactor 203 notes | 0.5hr | 2hrs |
|
||||||
|
| learn about heading links | 15min | 3mins |
|
||||||
|
|
||||||
|
# Daily Laws
|
||||||
|
## Mind
|
||||||
|
> 'Cause all that's gonna do really is accelerate the anxieties that I wish I could alleviate
|
||||||
|
> I'm ready to lose my mind, but instead I use my mind
|
||||||
|
|
||||||
|
## Body
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
47
content/dn/2022-03-17.md
Normal file
47
content/dn/2022-03-17.md
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-17
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-17i
|
||||||
|
## Reminders
|
||||||
|
- [x] investigate python position
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] 203 assignment
|
||||||
|
- [ ] 201 assignment
|
||||||
|
- [x] typing
|
||||||
|
- [ ] norwegian 05, 06
|
||||||
|
- [x] lecture 202
|
||||||
|
- [x] lab cosc 201
|
||||||
|
- [x] lecture info 201
|
||||||
|
- [ ] info201 lecture notes use case diagrams
|
||||||
|
- [x] review notes
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| -------------------------| ------ | -------|
|
||||||
|
| norwegian 05 04 | 2.5hr | |
|
||||||
|
| typing | 0.5hr | 0.5hr |
|
||||||
|
| 203 ass | 2hr | 4hr |
|
||||||
|
| cosc 201 ass | 1hr | |
|
||||||
|
| lecture 202 | 1hr | 1hr |
|
||||||
|
| lab cosc 201 | 1hr | 0mins |
|
||||||
|
| lecture info 201 | 1hr | 1hr |
|
||||||
|
| python job | 0.5hr | 10mins |
|
||||||
|
| review notes | 0.5hr | 5mins |
|
||||||
|
|
||||||
|
# Daily Laws
|
||||||
|
## Mind
|
||||||
|
> 'Cause all that's gonna do really is accelerate the anxieties that I wish I could alleviate
|
||||||
|
> I'm ready to lose my mind, but instead I use my mind
|
||||||
|
|
||||||
|
## Body
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
43
content/dn/2022-03-18.md
Normal file
43
content/dn/2022-03-18.md
Normal file
@ -0,0 +1,43 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-18
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-18i
|
||||||
|
## Reminders
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
## Todo's
|
||||||
|
- [ ] 203 assignment
|
||||||
|
- [ ] 201 assignment
|
||||||
|
- [ ] norwegian 05, 06
|
||||||
|
- [ ] info201 lecture notes use case diagrams
|
||||||
|
- [x] 202 brightness
|
||||||
|
- [ ] 202 add comments
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| -------------------------| ------ | -------|
|
||||||
|
| 202 brightness | 2hr | 2hr |
|
||||||
|
| 202 add comments | 15min | |
|
||||||
|
| norwegian 4 5 6 7 | 4hr | |
|
||||||
|
| 201 lecture notes | 1hr | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
# Daily Laws
|
||||||
|
## Mind
|
||||||
|
> 'Cause all that's gonna do really is accelerate the anxieties that I wish I could alleviate
|
||||||
|
> I'm ready to lose my mind, but instead I use my mind
|
||||||
|
|
||||||
|
## Body
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
44
content/dn/2022-03-19.md
Normal file
44
content/dn/2022-03-19.md
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-19
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
↑
|
||||||
|
|
||||||
|
# 2022-03-19
|
||||||
|
## Reminders
|
||||||
|
- [ ]
|
||||||
|
## Todo's
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| -------------------------| ------ | -------|
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
# Daily Laws
|
||||||
|
## Mind
|
||||||
|
> 'Cause all that's gonna do really is accelerate the anxieties that I wish I could alleviate
|
||||||
|
> I'm ready to lose my mind, but instead I use my mind
|
||||||
|
|
||||||
|
## Body
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
- [ ]
|
||||||
|
- [ ] 203 assignment
|
||||||
|
- [ ] 201 assignment
|
||||||
|
- [ ] norwegian 05, 06
|
||||||
|
- [ ] info201 lecture notes use case diagrams
|
||||||
|
- [ ] 202 add comments
|
||||||
45
content/dn/2022-03-20.md
Normal file
45
content/dn/2022-03-20.md
Normal file
@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-20
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-20i
|
||||||
|
## Reminders
|
||||||
|
- [ ]
|
||||||
|
## Todo's
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| -------------------------| ------ | -------|
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
# Daily Laws
|
||||||
|
## Mind
|
||||||
|
> 'Cause all that's gonna do really is accelerate the anxieties that I wish I could alleviate
|
||||||
|
> I'm ready to lose my mind, but instead I use my mind
|
||||||
|
|
||||||
|
## Body
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
info 201 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket:%5B%5B%2FLabs%2FLab%2002%2FLab%202%3A%20Git%20and%20GitBucket%5D%5D)
|
||||||
|
|
||||||
|
- [ ]
|
||||||
|
- [ ]
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
- [ ]
|
||||||
|
- [ ] 203 assignment
|
||||||
|
- [ ] 201 assignment
|
||||||
|
- [ ] norwegian 05, 06
|
||||||
|
- [ ] info201 lecture notes use case diagrams
|
||||||
|
- [ ] 202 add comments
|
||||||
45
content/dn/2022-03-21.md
Normal file
45
content/dn/2022-03-21.md
Normal file
@ -0,0 +1,45 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-21
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-21
|
||||||
|
| task | e time | r time |
|
||||||
|
| -------------------------| ------ | -------|
|
||||||
|
| info 201 assignment | 1hr | |
|
||||||
|
| info 201 lab | 1.5hr | 1hr |
|
||||||
|
| cosc 201 assignment | 1hr | 3hr |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| norwegian 12 | 1.25hr | 1.5hr |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 21st March ⇒ 201 assignment
|
||||||
|
- [ ] 5pm 1st April ⇒ info 201 assigment
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
|
||||||
|
## Todo's
|
||||||
|
- [ ] info 201 lab
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
## Lectures/labs
|
||||||
|
- [x] 202 lecture @ 11:00
|
||||||
|
- [x] cosc 201 lab @ 12:00
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Links
|
||||||
|
cosc 202 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
61
content/dn/2022-03-22.md
Normal file
61
content/dn/2022-03-22.md
Normal file
@ -0,0 +1,61 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-22
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-22
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| Lectures and labs | 5hr | 3hr |
|
||||||
|
| Norwegian 13 14 | 2.5hr | 3hr |
|
||||||
|
| Info 201 Assignment | 1.5hr | 0hr |
|
||||||
|
| Review notes | 1hr | 1hr |
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 60mins write up
|
||||||
|
- [ ] 5pm 25th March ⇒ info 201 milestone 1
|
||||||
|
- [ ] 30mins process transcript
|
||||||
|
- [ ] 30mins summary and scope
|
||||||
|
- [ ] 120mins functional requirements
|
||||||
|
- [ ] 30mins non functional requirements
|
||||||
|
- [ ] 15mins glossary
|
||||||
|
- [ ] 30mins follow-up checklist
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- 
|
||||||
|
- [ ] Find group
|
||||||
|
- [ ] 30mins heuristic evaulations
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
## Todo's
|
||||||
|
- [ ] info 201 lab
|
||||||
|
- [x] Norwegian 13 14
|
||||||
|
- [x] review notes for today
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [x] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 13:00 Info201 Lecture
|
||||||
|
- [x] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
64
content/dn/2022-03-23.md
Normal file
64
content/dn/2022-03-23.md
Normal file
@ -0,0 +1,64 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-23
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-23
|
||||||
|
> But man is not made for defeat. A man can be destroyed but not defeated.
|
||||||
|
> — <cite>Ernest Hemingway</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| norwegian 17 16 | 2hr | 1hr |
|
||||||
|
| info 201 transc | 30m | 1.5hr |
|
||||||
|
| info 201 summary and sc | 30m | 1hr15 |
|
||||||
|
| info 201 functional reqs | 1.5hr | - |
|
||||||
|
| review notes | 15min | 15m |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## Todo's
|
||||||
|
- [x] info 201 lab 3pm
|
||||||
|
- [x] review notes
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [x] 13:00 Info201 Lecture
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [x] 14:00 Info203 Tutorial
|
||||||
|
- [-] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 60mins write up
|
||||||
|
- [ ] 5pm 25th March ⇒ info 201 milestone 1
|
||||||
|
- [x] 30mins process transcript
|
||||||
|
- [x] 30mins summary and scope
|
||||||
|
- [ ] 120mins functional requirements
|
||||||
|
- [ ] 30mins non functional requirements
|
||||||
|
- [ ] 15mins glossary
|
||||||
|
- [ ] 30mins follow-up checklist
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] Find group
|
||||||
|
- [ ] 30mins heuristic evaulations
|
||||||
|
- [ ] 120mins write up
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
59
content/dn/2022-03-24.md
Normal file
59
content/dn/2022-03-24.md
Normal file
@ -0,0 +1,59 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-24
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-24
|
||||||
|
> When deeds and words are in accord, the whole world is transformed.
|
||||||
|
> — <cite>Zhuang Zhou</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| Norwegian 15 01 | 2hr | |
|
||||||
|
| Functional reqs | 3hr | |
|
||||||
|
| Non Functional reqs | 2hr | |
|
||||||
|
| Review Notes | 30m | 1hr |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## Todo's
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 60mins write up
|
||||||
|
- [ ] 5pm 25th March ⇒ info 201 milestone 1
|
||||||
|
- [ ] 120mins functional requirements
|
||||||
|
- [ ] 30mins non functional requirements
|
||||||
|
- [ ] 15mins glossary
|
||||||
|
- [ ] 30mins follow-up checklist
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] Find group
|
||||||
|
- [ ] 30mins heuristic evaulations
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
58
content/dn/2022-03-25.md
Normal file
58
content/dn/2022-03-25.md
Normal file
@ -0,0 +1,58 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-25
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-25
|
||||||
|
> He who has imagination without learning has wings but no feet. — <cite>Joseph Joubert</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| Review notes | 15m | 15min |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
## Todo's
|
||||||
|
- [ ] 11:00 Cosc202 Lecture (debugging)
|
||||||
|
- [x] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture (advanced data modelling - patterns)
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [x] 09:00 Cosc202 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture (mergesort 2)
|
||||||
|
- [ ] 12:00 Info201 Lab (use case diagrams)
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 60mins write up
|
||||||
|
- [x] 5pm 25th March ⇒ info 201 milestone 1
|
||||||
|
- [x] 120mins functional requirements
|
||||||
|
- [x] 30mins non functional requirements
|
||||||
|
- [x] 15mins glossary
|
||||||
|
- [x] 30mins follow-up checklist
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] Find group
|
||||||
|
- [ ] 30mins heuristic evaulations
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- [ ] save open file state
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
53
content/dn/2022-03-27.md
Normal file
53
content/dn/2022-03-27.md
Normal file
@ -0,0 +1,53 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-27
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-27
|
||||||
|
> Be glad of life because it gives you the chance to love, to work, to play, and to look up at the stars.
|
||||||
|
> — <cite>Henry van Dyke Jr.</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## Todo's
|
||||||
|
- [ ] 11:00 Cosc202 Lecture (debugging)
|
||||||
|
- [ ] 16:00 Info201 Lecture (advanced data modelling - patterns)
|
||||||
|
- [ ] 11:00 Cosc201 Lecture (mergesort 2)
|
||||||
|
- [ ] 12:00 Info201 Lab (use case diagrams)
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 60mins write up
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] Find group
|
||||||
|
- [ ] 30mins heuristic evaulations
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
- [ ]
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
59
content/dn/2022-03-28.md
Normal file
59
content/dn/2022-03-28.md
Normal file
@ -0,0 +1,59 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-28
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-28
|
||||||
|
> Everything that happens as it should, and if you observe carefully, you will find this to be so.
|
||||||
|
> — <cite>Marcus Aurelius</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| Past Lectures | 4hr | |
|
||||||
|
| Today's lectures | 2hr | 2:20 |
|
||||||
|
| Cosc 201 assignment | 1hr | 1hr |
|
||||||
|
| Info 203 assignment | 1hr | |
|
||||||
|
| Review notes | 30min | 15min |
|
||||||
|
| Norwegian 1 15 | 2hr | 1h14 |
|
||||||
|
| 202 work | 1hr | 1hr |
|
||||||
|
## Todo's
|
||||||
|
- [x] andie work
|
||||||
|
- [ ] 11:00 Cosc202 Lecture (debugging)
|
||||||
|
- [x] 16:00 Info201 Lecture (advanced data modelling - patterns)
|
||||||
|
- [ ] 11:00 Cosc201 Lecture (mergesort 2)
|
||||||
|
- [ ] 12:00 Info201 Lab (use case diagrams)
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [x] 11:00 Cosc202 Lecture
|
||||||
|
- [x] 12:00 Cosc201 lab
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 1hr Question 1
|
||||||
|
- [ ] 45min Question 2
|
||||||
|
- [ ] 30min Question 3
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [x] Find group
|
||||||
|
- [ ] 1hr heuristic evaluations
|
||||||
|
- [ ] 120mins write up
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
59
content/dn/2022-03-29.md
Normal file
59
content/dn/2022-03-29.md
Normal file
@ -0,0 +1,59 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-29
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-29
|
||||||
|
> Be as you wish to seem.
|
||||||
|
> — <cite>Socrates</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| past lectures | 2h | |
|
||||||
|
| Norwegian 15 | 1.5h | |
|
||||||
|
| todays lectures | 3hr | |
|
||||||
|
| heruistic evals | 3hr | |
|
||||||
|
| review notes | 5min | 5min |
|
||||||
|
| | | |
|
||||||
|
|
||||||
|
## Todo's
|
||||||
|
- [x] 11:00 Cosc202 Lecture (debugging)
|
||||||
|
- [x] 11:00 Cosc201 Lecture (mergesort 2)
|
||||||
|
- [ ] 12:00 Info201 Lab (use case diagrams)
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 13:00 Info201 Lecture
|
||||||
|
- [x] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 1hr Question 1
|
||||||
|
- [ ] 45min Question 2
|
||||||
|
- [ ] 30min Question 3
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] 3hr heuristic evaluations
|
||||||
|
- [ ] ohyay
|
||||||
|
- [x] skype
|
||||||
|
- [ ] discord
|
||||||
|
- [ ] 120mins write up
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
61
content/dn/2022-03-30.md
Normal file
61
content/dn/2022-03-30.md
Normal file
@ -0,0 +1,61 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-30
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-30
|
||||||
|
> Get busy living or get busy dying.
|
||||||
|
> — <cite>Stephen King</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| norwegian 15 | 2hr | 2hr |
|
||||||
|
| review notes | 5min | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## Todo's
|
||||||
|
- [ ] 12:00 Info201 Lab (use case diagrams)
|
||||||
|
- [x] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 13:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [x] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 1hr Question 1
|
||||||
|
- [ ] 45min Question 2
|
||||||
|
- [ ] 30min Question 3
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [x] 3hr heuristic evaluations
|
||||||
|
- [x] ohyay
|
||||||
|
- [x] discord
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## Links
|
||||||
|
### cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
56
content/dn/2022-03-31.md
Normal file
56
content/dn/2022-03-31.md
Normal file
@ -0,0 +1,56 @@
|
|||||||
|
---
|
||||||
|
title: 2022-03-31
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-03-31
|
||||||
|
> If you think you can, you can. And if you think you can't, you're right.
|
||||||
|
> — <cite>Henry Ford</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## 1 Todo's
|
||||||
|
- [x] 13:00 Info201 Lecture
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
- [x] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [x] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
- [ ] 5pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 1hr Question 1
|
||||||
|
- [ ] 45min Question 2
|
||||||
|
- [ ] 30min Question 3
|
||||||
|
- [ ] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [ ] 120mins write up
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
54
content/dn/2022-04-01.md
Normal file
54
content/dn/2022-04-01.md
Normal file
@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
title: 2022-04-01
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-01
|
||||||
|
> I will give you a definition of a proud man: he is a man who has neither vanity nor wisdom one filled with hatreds cannot be vain, neither can he be wise.
|
||||||
|
> — <cite>John Keats</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| 203 Assignment | 3hr | 3hr |
|
||||||
|
| review notes | 30min | 30min |
|
||||||
|
| 201 Assignment | 3hr | |
|
||||||
|
| Swedish fixes | ? | |
|
||||||
|
| 202 Work | 1hr | |
|
||||||
|
|
||||||
|
## 1 Todo's
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
- [r] 09:00 Cosc202 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
- [ ] 12pm 1st April ⇒ cosc 201 assignment
|
||||||
|
- [ ] 1hr Question 1
|
||||||
|
- [ ] 45min Question 2
|
||||||
|
- [ ] 30min Question 3
|
||||||
|
- [x] 5pm 1st April ⇒ info 203 assignment 2
|
||||||
|
- [x] 120mins write up
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
49
content/dn/2022-04-02.md
Normal file
49
content/dn/2022-04-02.md
Normal file
@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: 2022-04-02
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-02
|
||||||
|
> We all live with the objective of being happy; our lives are all different and yet the same.
|
||||||
|
> — <cite>Anne Frank</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## 1 Todo's
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
52
content/dn/2022-04-03.md
Normal file
52
content/dn/2022-04-03.md
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
---
|
||||||
|
title: 2022-04-03
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-03
|
||||||
|
> I'm not interested in age. People who tell me their age are silly. You're as old as you feel.
|
||||||
|
> — <cite>Elizabeth Arden</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## 1 Todo's
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
- [ ] save open file state
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
|
|
||||||
53
content/dn/2022-04-04.md
Normal file
53
content/dn/2022-04-04.md
Normal file
@ -0,0 +1,53 @@
|
|||||||
|
---
|
||||||
|
title: 2022-04-04
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-04
|
||||||
|
> If you light a lamp for somebody, it will also brighten your path.
|
||||||
|
> — <cite>Buddha</cite>
|
||||||
|
|
||||||
|
| task | e time | r time |
|
||||||
|
| ------------------------ | ------ | ------ |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
| | | |
|
||||||
|
## 1 Todo's
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
- [x] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 lab
|
||||||
|
## 3 Assignments
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- continuously integrate obsidian notes to website
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
- [ ] save open file state
|
||||||
|
- [ ] python ai weekly review
|
||||||
|
- [ ] my own password manager
|
||||||
56
content/dn/2022-04-05.md
Normal file
56
content/dn/2022-04-05.md
Normal file
@ -0,0 +1,56 @@
|
|||||||
|
---
|
||||||
|
title: 2022-04-05
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-05
|
||||||
|
> If you smile when no one else is around, you really mean it.
|
||||||
|
> — <cite>Andy Rooney</cite>
|
||||||
|
|
||||||
|
| # | task | P | A | e time | r time |
|
||||||
|
|---|---------------------------------------------|---|---|--------|--------|
|
||||||
|
| 2 | 201 Lecture | 2 | 2 | | |
|
||||||
|
| 3 | One no fix | 1 | | | |
|
||||||
|
| 1 | Cosc 201 Lab | 3 | | | |
|
||||||
|
| | | | | | |
|
||||||
|
| | | | | | |
|
||||||
|
| | | | | | |
|
||||||
|
| | | | | | |
|
||||||
|
| | | | | | |
|
||||||
|
|
||||||
|
> SCORE: 33%
|
||||||
|
|
||||||
|
## 1 Todos
|
||||||
|
- [ ] 12:00 Cosc201 lab
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [x] 13:00 Info201 Lecture
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
|
||||||
|
### 3.1 Cosc 202 tasks
|
||||||
|
- https://trello.com/b/Fk7lAfEG/andie
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
54
content/dn/2022-04-06.md
Normal file
54
content/dn/2022-04-06.md
Normal file
@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
title: 2022-04-06
|
||||||
|
---
|
||||||
|
[Daily notes](content/notes/daily-notes.md)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-06
|
||||||
|
Raw Power - The Stooges - spotify:album:6mxbG8KrOTZIxlP4gzaliM
|
||||||
|
|
||||||
|
| # | task | P | A | e time | r time |
|
||||||
|
|---| ------------------------|---|---|--------| ------ |
|
||||||
|
| 1 | one norwegian fix | | | | |
|
||||||
|
| 2 | 1hr 202 work | | | | |
|
||||||
|
| 3 | decide about 203 ass | | | | |
|
||||||
|
| 4 | | | | | |
|
||||||
|
| 5 | | | | | |
|
||||||
|
| 6 | | | | | |
|
||||||
|
| 7 | | | | | |
|
||||||
|
| 8 | | | | | |
|
||||||
|
|
||||||
|
|
||||||
|
> SCORE:
|
||||||
|
|
||||||
|
## 1 Todos
|
||||||
|
- [ ] 12:00 Cosc201 lab
|
||||||
|
- [x] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 12:00 Info201 Lab
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
|
## 2 Lecture/Labs
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
|
||||||
|
## 4 Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## 5 Timetable
|
||||||
|
|
||||||
|
|
||||||
|
## 6 Links
|
||||||
|
### 6.1 cosc 202
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### 6.2 info 201
|
||||||
|
[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
|
|
||||||
8
content/notes/2-uml.md
Normal file
8
content/notes/2-uml.md
Normal file
@ -0,0 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: 2 UML
|
||||||
|
---
|
||||||
|
# UML
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
71
content/notes/201-algorithms-and-data-structures.md
Normal file
71
content/notes/201-algorithms-and-data-structures.md
Normal file
@ -0,0 +1,71 @@
|
|||||||
|
---
|
||||||
|
title: 201 Algorithms and data structures
|
||||||
|
---
|
||||||
|
# COSC201 - Algorithms and Data Structures
|
||||||
|
## 1 Lectures
|
||||||
|
- [Merge sort - divide and conquer](content/notes/merge-sort-divide-and-conquer.md)
|
||||||
|
- [Lecture 8 Merge sort 2](content/notes/lecture-8-merge-sort-2.md)
|
||||||
|
- [Lecture 9 Stacks queues and heaps](content/notes/lecture-9-stacks-queues-and-heaps.md)
|
||||||
|
- [Lecture 10 Heaps and heap sort](content/notes/lecture-10-heaps-and-heap-sort.md)
|
||||||
|
|
||||||
|
## 2 Notes
|
||||||
|
### 2.1 Algorithm Complexity
|
||||||
|
- [Big-O](content/notes/big-o.md)
|
||||||
|
- [Big theta](content/notes/big-theta.md)
|
||||||
|
- [Induction](content/notes/induction.md)
|
||||||
|
- [analysis of recursive algorithms](content/notes/analysis-of-recursive-algorithms.md)
|
||||||
|
|
||||||
|
### 2.2 Algorithms
|
||||||
|
- [Minimal spending tree](content/notes/minimal-spending-tree.md)
|
||||||
|
- [Union Find-Disjoint set](content/notes/union-find-disjoint-set.md)
|
||||||
|
-
|
||||||
|
### 2.3 Fundamental Data structures
|
||||||
|
- [Objects](content/notes/objects.md)
|
||||||
|
- Stacks queues, List/arrays
|
||||||
|
- [Union Find-Disjoint set](content/notes/union-find-disjoint-set.md)
|
||||||
|
- Graphs and networks
|
||||||
|
- Priority queue (heap)
|
||||||
|
- Weighted
|
||||||
|
- Unweighted
|
||||||
|
- Trees (search and optimisation)
|
||||||
|
- Maps (link between 'keys' and 'values')
|
||||||
|
- Sets (Unstructured) (no repetition allowed)
|
||||||
|
|
||||||
|
## 3 Assignments
|
||||||
|
[assignment 1](content/notes/assignment-1.md)
|
||||||
|
|
||||||
|
## 4 Information
|
||||||
|
|
||||||
|
**Staff**
|
||||||
|
|
||||||
|
Role | Name | Email | Location | Hours
|
||||||
|
-----|------|-------|----------|-----|
|
||||||
|
Lectures | Michael Albert | michael.albert@otago.ac.nz | owheo g.52 | na |
|
||||||
|
Labs | Reuben Crimp | reuben.crimp@otago.ac.nz | owheo g.37a | na |
|
||||||
|
|
||||||
|
**Resources**
|
||||||
|
[blackboard](https://blackboard.otago.ac.nz/webapps/blackboard/execute/modulepage/view?course_id=_45042_1&cmp_tab_id=_508507_1&mode=view+)
|
||||||
|
[intro to algorithms book](https://otago.hosted.exlibrisgroup.com/permalink/f/1ihp3dt/OTAGO_ALMA51297974690001891)
|
||||||
|
|
||||||
|
**Assessment**
|
||||||
|
- Internal
|
||||||
|
- two asignments
|
||||||
|
- end of week 5 10%
|
||||||
|
- end of week 10 20%
|
||||||
|
- labs total 10%
|
||||||
|
- Exam - 60%
|
||||||
|
|
||||||
|
**Course_plan**
|
||||||
|
- Extension and refinement of Big-O notation for algorithmic analysis.
|
||||||
|
- The union-find data structure (a case study)
|
||||||
|
- Merge sort
|
||||||
|
- Priority queues and heap sort
|
||||||
|
- Search trees and balancing
|
||||||
|
- Hashing and hash maps
|
||||||
|
- Graphs and graph algorithms (shortest paths, minimal spanning trees)
|
||||||
|
- String algorithms
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
54
content/notes/201-information-systems.md
Normal file
54
content/notes/201-information-systems.md
Normal file
@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
title: 201 Information Systems
|
||||||
|
---
|
||||||
|
# INFO 201 - Information Systems
|
||||||
|
## 1 Lectures
|
||||||
|
- [Lecture 6 Business Functions and Use Cases](content/notes/lecture-6-business-functions-and-use-cases.md)
|
||||||
|
- [Lecture 7 Business process modelling(BPM)](content/notes/lecture-7-business-process-modellingbpm.md)
|
||||||
|
- [Lecture 8 Business patterns](content/notes/lecture-8-business-patterns.md)
|
||||||
|
- [Lecture 9 Data Modelling and Normalisation](content/notes/lecture-9-data-modelling-and-normalisation.md)
|
||||||
|
- [Lecture 10 OOP Concepts and UML](content/notes/lecture-10-oop-concepts-and-uml.md)
|
||||||
|
- [Lecture 11 Class diagrams](content/notes/lecture-11-class-diagrams.md)
|
||||||
|
|
||||||
|
## 2 Notes
|
||||||
|
- [Business analyst](content/notes/business-analyst.md)
|
||||||
|
- [Systems analyst](content/notes/systems-analyst.md)
|
||||||
|
- [Developer](content/notes/developer.md)
|
||||||
|
- [Models](content/notes/models.md)
|
||||||
|
- [Systems development lifecycle (SDLC)](content/notes/systems-development-lifecycle-sdlc.md)
|
||||||
|
- [Agile Development](content/notes/agile-development.md)
|
||||||
|
- [Predictive adaptive spectrum](content/notes/predictive-adaptive-spectrum.md)
|
||||||
|
- [Version Control Systems](content/notes/version-control-systems.md)
|
||||||
|
- [Requirements elicitation](content/notes/requirements-elicitation.md)
|
||||||
|
|
||||||
|
|
||||||
|
### 2.1 Information
|
||||||
|
|
||||||
|
**Staff**
|
||||||
|
|
||||||
|
Role | Name | Email | Location | Hours
|
||||||
|
---------|----------------|-----------------------------------------------------------------|----------|------
|
||||||
|
Lecures | Nigel stanger | [nigel.stanger@otago.ac.nz](mailto:nigel.stanger@otago.ac.nz) | OBS 340 |
|
||||||
|
Lectures | Daniel Costa | [danielcalencar@otago.ac.nz](mailto:danielcalencar@otago.ac.nz) | OBS 345 |
|
||||||
|
Labs | Chris Edwards | [chris.edwards@otago.ac.nz](mailto:chris.edwards@otago.ac.nz) | OBS 328 |
|
||||||
|
Labs | Mark George | [mark.george@otago.ac.nz](mailto:mark.george@otago.ac.nz) | OBS 332 |
|
||||||
|
|
||||||
|
**Resources**
|
||||||
|
[Domain Driven Design with BDD](https://www.youtube.com/watch?v=Ju50D11EIoE)
|
||||||
|
|
||||||
|
**Assessment**
|
||||||
|
Must pass at least 7 labs
|
||||||
|
Must get total of at least 40%.
|
||||||
|
|
||||||
|
Grade Componentsh
|
||||||
|
- milestone 1 - 10%
|
||||||
|
- milestone 2 - 20%
|
||||||
|
- milestone 3 - 20%
|
||||||
|
- exam - 50%
|
||||||
|
|
||||||
|
**Course_plan**
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
48
content/notes/202-software-development.md
Normal file
48
content/notes/202-software-development.md
Normal file
@ -0,0 +1,48 @@
|
|||||||
|
---
|
||||||
|
title: 202 Software development
|
||||||
|
---
|
||||||
|
# COSC 202 - Software development
|
||||||
|
## 1 Lectures
|
||||||
|
- [Lecture 07 Unit Testing](content/notes/lecture-07-unit-testing.md)
|
||||||
|
- [Lecture 08 Debugging](content/notes/lecture-08-debugging.md)
|
||||||
|
- [Lecture 09 Documentation](content/notes/lecture-09-documentation.md)
|
||||||
|
- [Lecture 10 Continuous integration](content/notes/lecture-10-continuous-integration.md)
|
||||||
|
- [Lecture 11 Continuous Integration 2](content/notes/lecture-11-continuous-integration-2.md)
|
||||||
|
|
||||||
|
## 2 Notes
|
||||||
|
- [Consoles Terminals Shells](content/notes/consoles-terminals-shells.md)
|
||||||
|
- [Git](content/notes/git.md)
|
||||||
|
- [Ethics](content/notes/ethics.md)
|
||||||
|
- [Branch](content/notes/branch.md)
|
||||||
|
- [Integrated Development Environments](content/notes/integrated-development-environments.md)
|
||||||
|
|
||||||
|
## 3 Project
|
||||||
|
A non destructive image editor ANDIE
|
||||||
|
- [CROCS](content/notes/crocs.md)
|
||||||
|
- [Teamwork](content/notes/teamwork.md)
|
||||||
|
|
||||||
|
## 4 Information
|
||||||
|
**Staff
|
||||||
|
- David Eyers - Lectures
|
||||||
|
- Steven mills - Project
|
||||||
|
- Reuben Crimp - Labs
|
||||||
|
- Student demonstrators
|
||||||
|
|
||||||
|
**Contact**
|
||||||
|
cosc202-staff@otago.ac.nz
|
||||||
|
|
||||||
|
**Resources**
|
||||||
|
lab book -> https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf
|
||||||
|
https://www.youtube.com/channel/UCD8yeTczadqdARzQUp29PJw
|
||||||
|
|
||||||
|
**Assessment**
|
||||||
|
20% x 2 group project
|
||||||
|
20% individual
|
||||||
|
40% exam
|
||||||
|
|
||||||
|
**Course plan**
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
72
content/notes/203-human-computer-interaction.md
Normal file
72
content/notes/203-human-computer-interaction.md
Normal file
@ -0,0 +1,72 @@
|
|||||||
|
---
|
||||||
|
title: 203 Human-Computer interaction
|
||||||
|
---
|
||||||
|
# INFO203 - Human Computer Interaction
|
||||||
|
## 1 Notes
|
||||||
|
### 1.1 Lectures
|
||||||
|
- [Lecture 7 Personas and Scenarios](content/notes/lecture-7-personas-and-scenarios.md)
|
||||||
|
- [Lecture 8 Personas and Scenarios](content/notes/lecture-8-personas-and-scenarios.md)
|
||||||
|
- [Lecture 9 Paper Protoypes, Wizard of OZ, Video Prototyping](content/notes/lecture-9-paper-protoypes-wizard-of-oz-video-prototyping.md)
|
||||||
|
- [Lecture 10 Design Heuristics](content/notes/lecture-10-design-heuristics.md)
|
||||||
|
- [Lecture 11 Design Heuristics 2](content/notes/lecture-11-design-heuristics-2.md)
|
||||||
|
- [Lecture 12 Design Heuristics 3](content/notes/lecture-12-design-heuristics-3.md)
|
||||||
|
|
||||||
|
### 1.2 Videos
|
||||||
|
- [Heuristic Evaluation](content/notes/heuristic-evaluation.md)
|
||||||
|
- [Storyboards mockups, paper prototypes](content/notes/storyboards-mockups-paper-prototypes.md)
|
||||||
|
- [Faking it Wizard of OZ](content/notes/faking-it-wizard-of-oz.md)
|
||||||
|
- [Faking it video prototyping](content/notes/faking-it-video-prototyping.md)
|
||||||
|
|
||||||
|
### 1.3 Atomic
|
||||||
|
- [HCI Big Picture](content/notes/hci-big-picture.md)
|
||||||
|
- [Birth of HCI](content/notes/birth-of-hci.md)
|
||||||
|
- [Prototyping](content/notes/prototyping.md)
|
||||||
|
- [Evaluating designs](content/notes/evaluating-designs.md)
|
||||||
|
- [Needfinding](content/notes/needfinding.md)
|
||||||
|
- [Observation](content/notes/observation.md)
|
||||||
|
- [Interviews](content/notes/interviews.md)
|
||||||
|
- [User Experience](content/notes/user-experience.md)
|
||||||
|
- [Usability](content/notes/usability.md)
|
||||||
|
- [HCI](content/notes/hci.md)
|
||||||
|
|
||||||
|
### 1.4 Assignments
|
||||||
|
- [What is Usability](content/notes/what-is-usability.md)
|
||||||
|
- [Heuristics Evaluation Assignment](content/notes/heuristics-evaluation-assignment.md)
|
||||||
|
- [Assignment 3](content/notes/assignment-3.md)
|
||||||
|
|
||||||
|
### 1.5 Exam
|
||||||
|
[Possible exam questions](content/notes/possible-exam-questions.md)
|
||||||
|
|
||||||
|
## 2 Information
|
||||||
|
|
||||||
|
**Staff**
|
||||||
|
|
||||||
|
Role | Name | Email | Location | Hours
|
||||||
|
-----|------|-------|----------|------
|
||||||
|
Lectures | Tobias Langlotz | [tobias.langlotz@otago.ac.nz](mailto:tobias.langlotz@otago.ac.nz) | OBS 713 |
|
||||||
|
Labs | Jonatan Sutton | [sutjo752@student.otago.ac.nz](mailto:sutjo752@student.otago.ac.nz) | |
|
||||||
|
|
||||||
|
**Resources**
|
||||||
|
- [Course Outline](https://blackboard.otago.ac.nz/bbcswebdav/pid-2827486-dt-content-rid-17936119_1/courses/INFO203_S1DNIE_2022/INFO203%20Course%20Outline%281%29.pdf)
|
||||||
|
- [Stanford HCI Videos](https://blackboard.otago.ac.nz/webapps/blackboard/content/listContent.jsp?course_id=_45153_1&content_id=_2827496_1)
|
||||||
|
- [Lectures Slides](https://blackboard.otago.ac.nz/webapps/blackboard/content/listContent.jsp?course_id=_45153_1&content_id=_2827495_1)
|
||||||
|
- [Lab docs and assignments](https://blackboard.otago.ac.nz/webapps/blackboard/content/listContent.jsp?course_id=_45153_1&content_id=_2827497_1)
|
||||||
|
- mark weiser "Calm technology"
|
||||||
|
|
||||||
|
|
||||||
|
**Assessment**
|
||||||
|
Total > 50%
|
||||||
|
Exam > 40%
|
||||||
|
|
||||||
|
- Usability analysis 5%
|
||||||
|
- Usability analysis 2 10%
|
||||||
|
- Prototype 35%
|
||||||
|
- Exam 50%
|
||||||
|
|
||||||
|
**Course_plan
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
25
content/notes/agile-development.md
Normal file
25
content/notes/agile-development.md
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
---
|
||||||
|
title: Agile Development
|
||||||
|
---
|
||||||
|
tags: review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Agile Development
|
||||||
|
> guilding philosphy to develop info systems in unkown, rapidly changing evnironments
|
||||||
|
|
||||||
|
"Chaordic"
|
||||||
|
|
||||||
|
[The agile manifesto](https://www.agilealliance.org/agile101/the-agile-manifesto)
|
||||||
|
|
||||||
|
## 1 [SCRUM](content/notes/scrum.md)
|
||||||
|
Development is split into many short (~30 day) "sprints" of intense focus where the entire team is involved
|
||||||
|
|
||||||
|
## 2 [Extreme programming (XP)](content/notes/extreme-programming-xp.md)
|
||||||
|
take current industry practices to the extreme
|
||||||
|
|
||||||
|
## 3 [Unified process (UP)](content/notes/unified-process-up.md)
|
||||||
|
Interative and incremental architecture-centric which has four main phases
|
||||||
|
- inception
|
||||||
|
- elaboration
|
||||||
|
- construction
|
||||||
|
- transition
|
||||||
24
content/notes/all-the-light-we-cannot-see.md
Normal file
24
content/notes/all-the-light-we-cannot-see.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: All the light we cannot see
|
||||||
|
---
|
||||||
|
# All the light we cannot see
|
||||||
|
## Quotes
|
||||||
|
|
||||||
|
The entropy of a closed system never decreases
|
||||||
|
|
||||||
|
Sublimity: "the instant when on on ething is about to become something else. Day to night, catepillar to butterfly. Fawn to doe. Experiment to result. Boy to man"
|
||||||
|
|
||||||
|
-
|
||||||
|
"Do you know what happens, etienne, " says madame manec from
|
||||||
|
the other side of the kitchen, "when you drop a frog in a pot of boiling
|
||||||
|
water?"
|
||||||
|
"You will tell us, I am sure."
|
||||||
|
"It jumps out. But do you what what happens when you put the
|
||||||
|
frog in a pot of cool water and then slowly bring it to a boil? You know
|
||||||
|
what happens then?"
|
||||||
|
Marie-Laure waits. The potatoes steam.
|
||||||
|
Madame Manec says, "The frog cooks."
|
||||||
|
|
||||||
|
Science, my lad, is made up of mistakes, but the are mistakes which it is useful to make, because they lead little by little to the truth.
|
||||||
|
|
||||||
|
|
||||||
153
content/notes/analysis-of-recursive-algorithms.md
Normal file
153
content/notes/analysis-of-recursive-algorithms.md
Normal file
@ -0,0 +1,153 @@
|
|||||||
|
---
|
||||||
|
title: analysis of recursive algorithms
|
||||||
|
aliases: Proof by induction, induction
|
||||||
|
sr-due: 2022-05-02
|
||||||
|
sr-interval: 29
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
## 1 Review Questions
|
||||||
|
Do one practice problem
|
||||||
|
|
||||||
|
### 1.1 MaxNum
|
||||||
|
```
|
||||||
|
maxNum = -1
|
||||||
|
for num in numbers
|
||||||
|
if num < maxNum then
|
||||||
|
maxNum = num;
|
||||||
|
end
|
||||||
|
end
|
||||||
|
```
|
||||||
|
|
||||||
|
parameter n is length of the array of number
|
||||||
|
|
||||||
|
we will prove that, for every non-negative integer n, the maximum time to find the max num is Ο(n)
|
||||||
|
|
||||||
|
for n = 1 this is true because the maximum number is always the first number we check
|
||||||
|
for n =2 this is true because the maximum number is always on of the first two numbers we check
|
||||||
|
|
||||||
|
for any n >0, assuming this is true for all n-1, this is true at n because the maximum amount of number to check is never greater than n
|
||||||
|
|
||||||
|
∴ by induction, the time comnplexity is Ο(n)
|
||||||
|
|
||||||
|
___
|
||||||
|
|
||||||
|
# Analysis of recursion algorithms
|
||||||
|
- induction and recursion are linked
|
||||||
|
- inductive approach is esential for understanding time-complexity of resursive algorithms
|
||||||
|
|
||||||
|
## 2 Proof by induction
|
||||||
|
[Induction](content/notes/induction.md)
|
||||||
|
Find a (positive integer) _parameter_ that gets smaller in all recursive calls
|
||||||
|
Prove inductively that "for all values of the parameter, the result computed is correct"
|
||||||
|
To do that:
|
||||||
|
- check correctness is all non-recursive cases
|
||||||
|
- check correctness in recursive cases assuming correcness in the recursive calls
|
||||||
|
|
||||||
|
## 3 Examples
|
||||||
|
### 3.1 Quicksort
|
||||||
|
[divide and conquer](None) algorithm
|
||||||
|
sorts a range in an array (a group of elements between some lower index, $lo$ inclusive and some upper index $hi$ exclusive) as follows:
|
||||||
|
- If length of range $(hi - lo)$ is at most 1 -> do nothing
|
||||||
|
- otherwise, choose a pivot p (e.g., the element at $lo$) and:
|
||||||
|
- place all items less that p in positions $lo$ to $lo +r$
|
||||||
|
- place all items >= p in positions $lo +r+1$ to $hi$
|
||||||
|
- place p in position $lo+r$
|
||||||
|
- call quicksort on the ranges $lo$ to $lo + r$ and $lo+r+1$ to $hi$
|
||||||
|
|
||||||
|
#### 3.1.1 Proof
|
||||||
|
parameter is $hi - lo$
|
||||||
|
|
||||||
|
the parameter gets smaller in all recusive call because we always remove the element $p$ so, even if it is the smallest or largest element of the range ,,the recursive call has a range of size at most $hi - lo - 1$
|
||||||
|
|
||||||
|
the non-recursive case is correct because if we have 1 or fewer elements in a range they are already sorted
|
||||||
|
|
||||||
|
in the recirsive case, since all the elements before $p$ are smaller than it and we assume they get sorted correctly be quicksort, and the same happens for the elements larger than p, we will get a correctly sorted array
|
||||||
|
|
||||||
|
|
||||||
|
### 3.2 Fibonacci 1
|
||||||
|
```python
|
||||||
|
def fib(n)
|
||||||
|
if n <= 1
|
||||||
|
return 1
|
||||||
|
return fib(n-1) + fib(n-2)
|
||||||
|
```
|
||||||
|
|
||||||
|
line 1 -> always executed
|
||||||
|
line 2 -> executed if n<=1
|
||||||
|
line 4 -> executed if n>1, cost equal to cost of callling fib(n-1), fib(n-2), and some constant cost for the addition and return
|
||||||
|
|
||||||
|
#### 3.2.1 Cost bounds/Proof
|
||||||
|
if we let T(n) denote the time required for evaluating fib(n) using this algorithm this analysis gives:
|
||||||
|
|
||||||
|
>## $T(0) = T(1) = C$
|
||||||
|
>## $T(n) = D + T(n-1) + T(n-2)$
|
||||||
|
|
||||||
|
where c and d are some positive (non-zero) constants.
|
||||||
|
|
||||||
|
- this shows that T(n) grows at least as quick as fib(n)
|
||||||
|
- even if $D=0$ we'd get $T(n) = C \times fib(n)$
|
||||||
|
- growth rates are the same $\therefore$ exponential (at least $1.6^n$) and far too slow
|
||||||
|
|
||||||
|
> A recurive algorithm that makes two or more recurive calls with parameter values close to the original will generally have exponential time complexity
|
||||||
|
|
||||||
|
### 3.3 Fibonacci 2
|
||||||
|
```python
|
||||||
|
def fibPair()
|
||||||
|
if n == 1
|
||||||
|
return 1, 1
|
||||||
|
a,b = fibpair(n-1)
|
||||||
|
return b, a+b
|
||||||
|
```
|
||||||
|
line 1 -> always executed some constant cost
|
||||||
|
line 2-> executed if n=1, some constant cost
|
||||||
|
line 4-> executed if n>1, cost equal to cost of calling fibPair(n-1)
|
||||||
|
line 5 -> executed if n>1, some constant cost
|
||||||
|
|
||||||
|
#### 3.3.1 Proof
|
||||||
|
it's true for $n-1 by design$
|
||||||
|
If it's true at n-1 then the result of computing fibpair(n) is:
|
||||||
|
|
||||||
|
$(f_{n-1}, f_{n-1} + f_{n-1}) = (f_{n-1}, f_n)$
|
||||||
|
|
||||||
|
which is what we want
|
||||||
|
|
||||||
|
#### 3.3.2 Cost bounds
|
||||||
|
if we let P(n) denote the time required for evaluating fib(n) using this algorithm this analysis gives:
|
||||||
|
|
||||||
|
$P(1) = C$
|
||||||
|
$P(n) = P(n-1) + D\ for\ n>1$
|
||||||
|
|
||||||
|
where $C$ and $D$ are some positive (non-zero) constants.
|
||||||
|
|
||||||
|
|
||||||
|
Claim: $P(n) = C + D(n-1)$
|
||||||
|
|
||||||
|
By induction:
|
||||||
|
it's true for n = 1 since,
|
||||||
|
|
||||||
|
$P(1) = C$
|
||||||
|
$C+D\times(1-1)=C$
|
||||||
|
|
||||||
|
suppose that it's true for n-1. Then it's true for n as well because
|
||||||
|
|
||||||
|
$P(n) = P(n-1) + D$
|
||||||
|
$\ \ \ \ \ \ \ \ \ = C+D\times(n-2)+D$
|
||||||
|
$\ \ \ \ \ \ \ \ \ = C+D\times(n-1)$
|
||||||
|
|
||||||
|
$\therefore$ By induction it's true for all $n>=1$
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
$P(n)$ is the time for evaluating $fibPair(n)$ using this algorithm. This analysis gives:
|
||||||
|
|
||||||
|
$P(1) = C$
|
||||||
|
$P(n) = P(n-1) +D$
|
||||||
|
|
||||||
|
where C and D are some positive constants
|
||||||
|
|
||||||
|
#theorem
|
||||||
|
> ## $P(n) = C+D\times(n-1)$
|
||||||
|
> in particular, $P(n) = \theta(n)$
|
||||||
|
|
||||||
|
> A recursive algorithm that make one recurive call with a smaller value and a constant amount of additional work will have at most linear time complexity
|
||||||
7
content/notes/anti-govt-protest-china.md
Normal file
7
content/notes/anti-govt-protest-china.md
Normal file
@ -0,0 +1,7 @@
|
|||||||
|
---
|
||||||
|
title: Anti govt protest china
|
||||||
|
---
|
||||||
|
# Anti govt protest China
|
||||||
|
China used facial recognition to identofy protesters
|
||||||
|
|
||||||
|
these protesters used masks and toppled lamposts to thwart this infrastructure
|
||||||
16
content/notes/approches-to-systems-development.md
Normal file
16
content/notes/approches-to-systems-development.md
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
---
|
||||||
|
title: Approches to systems development
|
||||||
|
---
|
||||||
|
# Approches to systems development
|
||||||
|
## 1 traditional
|
||||||
|
regardless of the approach, the conecpot of the model is import for analysis design and modelling parrasigms
|
||||||
|
|
||||||
|
### 1.1 system is a collection of process
|
||||||
|
function programming
|
||||||
|
processes interact with data
|
||||||
|
processes accept inputs and produce ouputs
|
||||||
|
|
||||||
|
### 1.2 object oriented
|
||||||
|
system is a collection of objects
|
||||||
|
these objects interact with each other
|
||||||
|
and send and respond to messages
|
||||||
114
content/notes/assignment-1.md
Normal file
114
content/notes/assignment-1.md
Normal file
@ -0,0 +1,114 @@
|
|||||||
|
---
|
||||||
|
title: assignment 1
|
||||||
|
---
|
||||||
|
# COSC201 Assignment 1: Counting the seas
|
||||||
|
|
||||||
|
## 1 Due : 11:59 p.m. Friday, April 1, 2022
|
||||||
|
[9474308Hughes](None)
|
||||||
|
## 2 Introduction
|
||||||
|
|
||||||
|
Imagine a square world consisting of cells each of which is either land or water. A
|
||||||
|
computational cartographer’s paradise if you will. Anyhow, it turns out that a number
|
||||||
|
of such worlds exist of varying sizes and varying proportions of land to water. Your
|
||||||
|
continuing mission has been to search out these strange worlds and count how many
|
||||||
|
distinct bodies of water there are on each of them.
|
||||||
|
|
||||||
|
Here’s a world that you discovered recently – its dimensions are 8 × 8 and it has only
|
||||||
|
14 land cells.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Obviously, in this world there is only one giant sea. On the other hand, another world
|
||||||
|
with a 10 × 10 grid was also recently discovered:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
This world is dominated by land, and there are 10 seas. You may disagree, and think
|
||||||
|
there are 15 seas, but water cells are considered to be part of the same sea if they meet
|
||||||
|
along an edge **or** at a corner.
|
||||||
|
|
||||||
|
Exploration is a complicated and expensive business and the thoughts of your superiors
|
||||||
|
have turned to simulation – that is, to creating imaginary worlds of this type in order
|
||||||
|
to try and understand how the number of seas changes depending on the size of the
|
||||||
|
underlying grid and the ratio of water to land.
|
||||||
|
|
||||||
|
### 2.1 Raw materials
|
||||||
|
|
||||||
|
You will be provided with a number of Java classes. These include:
|
||||||
|
|
||||||
|
- All the union-find implementations we’ve looked at.
|
||||||
|
- A classMap.javathat represents maps of the type we’re interested in. This class includes a number of convenience methods for various tasks. For instance:
|
||||||
|
- indexing the cells of a map from 0 in the top left corner and then increasing from left to right and top to bottom (so, in the 10 × 10 grid the first row contains cells 0 to 9, the second 10 to 19, the third 20 to 29, and so on);
|
||||||
|
- recognising the type of each cell (by index or coordinates);
|
||||||
|
- identifying all the neighbours of a given cell (by index).
|
||||||
|
|
||||||
|
Using these classes, you are asked to produce some more code and to conduct and
|
||||||
|
report on some experiments.
|
||||||
|
|
||||||
|
|
||||||
|
### 2.2 Code submission (5 points)
|
||||||
|
|
||||||
|
The code you submit for this assignment will be a single class calledMapAnalyser.
|
||||||
|
Skeleton code for that class will be provided and its Javadoc will specify the require-
|
||||||
|
ments in detail. However, these and the required underlying algorithms are also dis-
|
||||||
|
cussed briefly below.
|
||||||
|
|
||||||
|
MapAnalyser(Map m)
|
||||||
|
|
||||||
|
The constructor for aMapAnalyserrequires aMapinstance. All of its methods refer to
|
||||||
|
this underlyingMap.
|
||||||
|
|
||||||
|
countSeas()
|
||||||
|
|
||||||
|
This method returns an integer which is the total number of seas of the underlyingMap.
|
||||||
|
To compute this number you must be able to identify the seas, i.e., which water cells
|
||||||
|
belong to the same seas. This is exactly the kind of task that the union-find framework
|
||||||
|
is designed for.
|
||||||
|
|
||||||
|
Specifically, given a map you can initialise aUnionFindinstance whose size is the
|
||||||
|
total number of cells in the map. Then, you can iterate once over the cells of the map –
|
||||||
|
whenever you find a water cell, you can do a union operation between it and its water
|
||||||
|
neighbours. At the end of this process, two water cells belong to the same sea if and
|
||||||
|
only if they are in same set of the partition (i.e., if and only if they have the samefind
|
||||||
|
value).
|
||||||
|
|
||||||
|
There are a number of options about how to use this idea to count seas (you can do it
|
||||||
|
as you construct the final state of the union-find instance, or after you have done so).
|
||||||
|
The choice is up to you.
|
||||||
|
|
||||||
|
seaSize(int r, int c)
|
||||||
|
|
||||||
|
This method just returns the total number of cells belonging to the same sea as the cell
|
||||||
|
in rowrand columnc. If this cell is land rather than water it should just return the
|
||||||
|
value 0.
|
||||||
|
|
||||||
|
### 2.3 Written submission (5 points
|
||||||
|
|
||||||
|
Please submit the answers to the following questions as a single **PDF** document with
|
||||||
|
filename of the form314159Pi.pdfwhere 314159 is replaced by your ID number
|
||||||
|
andPiis replaced by your surname. There are no formal requirements for the format
|
||||||
|
of your submission, but presentation, spelling and grammar are all important elements
|
||||||
|
which will account for roughly 40% of the marks for this part of the assignment.
|
||||||
|
|
||||||
|
The written answers to questions one and two could be a couple of paragraphs each
|
||||||
|
(or a bit longer) along with supporting data. A single paragraph (and possibly some
|
||||||
|
pseudocode) is enough to answer question three.
|
||||||
|
|
||||||
|
1. The efficiency of the various union-find instances affects how large a square map
|
||||||
|
can be analysed. A reasonable length of time for a single computation might be
|
||||||
|
something on the order of a second. Conduct experiments usingUF1,UF2,UF3,
|
||||||
|
andUF4to determine rough values for that limit on the hardware you are us-
|
||||||
|
ing when the probability of a cell being water is 0. 5. Describe those experiments
|
||||||
|
(including the number of repetitions) and report on their results (a table or chart
|
||||||
|
would be appropriate). Comment briefly on whether the outcomes match our the-
|
||||||
|
oretical discussions of the four different algorithms and how changing the water
|
||||||
|
probability might affect their performance.
|
||||||
|
2. Consider 10 × 10 , 100 × 100 , and 1000 × 1000 maps. Conduct experiments to
|
||||||
|
try and determine the proportion of water needed on each so that on average
|
||||||
|
there are two or fewer seas. Describe those experiments (including the number of
|
||||||
|
repetitions - this should be large enough that you have confidence in the results
|
||||||
|
you’re claiming) and report on their results.
|
||||||
|
3. Suppose that we also wanted to count the islands. How would you do that - and
|
||||||
|
what changes to the code might be needed?
|
||||||
|
|
||||||
|
|
||||||
61
content/notes/assignment-3.md
Normal file
61
content/notes/assignment-3.md
Normal file
@ -0,0 +1,61 @@
|
|||||||
|
---
|
||||||
|
title: Assignment 3
|
||||||
|
---
|
||||||
|
[203 Human-Computer interaction](content/notes/203-human-computer-interaction.md)
|
||||||
|
|
||||||
|
# Assignment 3
|
||||||
|
|
||||||
|
**Deadline: Friday 27th of May 2022, 5pm via Blackboard (35% of final mark)**
|
||||||
|
|
||||||
|
## 1 Project: Prototypical Mobile App Development
|
||||||
|
### 1.1 Aim
|
||||||
|
- conecptual design and prototypical implementation of a application for mobile devices
|
||||||
|
- Usage of an iterative development model increasing the fidelity of the developed prototype
|
||||||
|
- Conduct brainstorming, develop personas and scenarios, create storyboard, create low fidelity prototypes (explore alternatives), informal evaluation, create high fidelity prototypes
|
||||||
|
|
||||||
|
### 1.2 Deadlines
|
||||||
|
- Friday 8th of April: Email to Jonthan (sutjo752@student.otago.ac.nz) to indicate group/ indivdual work and preliminary topic idea
|
||||||
|
- Friday 27th of May: Final recorded presentation and additional material summarising the prototypical mobile App development
|
||||||
|
|
||||||
|
### 1.3 Brainstorming:
|
||||||
|
- Explore user interface alternatives and compare against existing products similar to your app (or most similar apps)
|
||||||
|
- Document process: E.g. what are the different ideas, alternatives developed and existing solutions, what was the reason the choosing the winning idea
|
||||||
|
- Keep it short, make use of visual documentation (e.g. drawings, photos, Post-Its) and support it with text, mindmap(s) can me usefull to document brainstorming
|
||||||
|
- Documentation needs to provide evidence that you a) considered existing solutions (needfinding) and b) explored different alternatives
|
||||||
|
|
||||||
|
### 1.4 Personas and Scenarios:
|
||||||
|
- Conceptually develop personas and scenarios (at least two)
|
||||||
|
- Document final personas (also considering different type of personas) and scenarios
|
||||||
|
- Keep it short and see examples in the lectures for guidance
|
||||||
|
|
||||||
|
### 1.5 Storyboard:
|
||||||
|
- Develop a visual storyboard out of your scenario description
|
||||||
|
- See lecture on storyboards for tricks on developing a short and concise storyboard
|
||||||
|
- Digital storyboard or free hand sketch are both fine
|
||||||
|
|
||||||
|
### 1.6 Low fidelity prototypes:
|
||||||
|
- Develop low fidelity prototypes for your envisioned app using techniques explained in the lecture (paper-based prototypes)
|
||||||
|
- We expect 6-10 “screens” that should be prototypically developed
|
||||||
|
- Explore alternatives for the interface and document all (photos are ok when using pen-based sketches)
|
||||||
|
- Consider and document the flow within the app (relation and pathways between different screens)
|
||||||
|
|
||||||
|
### 1.7 Document design decisions / informal evaluation
|
||||||
|
- Which of the ideas from the different low fidelity prototypes did or did not work
|
||||||
|
- Document the identified issues by linking them to the design heuristics and mention the proposed solution(s)
|
||||||
|
- E.g. one aspect from one prototype worked better than in the alternative prototype because there was an issue with “Consistency”….
|
||||||
|
|
||||||
|
### 1.8 High fidelity prototype:
|
||||||
|
- Develop a high fidelity prototype from the knowledge gained with your low fidelity prototype
|
||||||
|
- Create the higher fidelity prototype by choosing a method (e.g. could be prototype toolkits such as Balsamiq, Adobe XD, …, some of them have a free trial period you are not expected to buy those, could be template based approaches using images of UI elements, …)
|
||||||
|
- Consider which interface elements you use because of size constraints within a mobile interface
|
||||||
|
- Outline the flow within the app (relation and pathways between different screens)
|
||||||
|
- Document using screenshots etc.
|
||||||
|
|
||||||
|
### 1.9 Submission:
|
||||||
|
- ~7min presentation slides with max. 7 slides (Powerpoint, Keynote, or Pdf) summarising the key aspects of your prototypical development
|
||||||
|
- Professional look: Less text more graphics, illustrations, and other media material (video?)
|
||||||
|
- This presentation is no advertisement or sales pitch but a summary of the work you did with some key insights you learned along the way
|
||||||
|
- Record your presentation (slides and with audio, video optional), we recommend Zoom for doing this
|
||||||
|
- Submit the recording of your presentation
|
||||||
|
- Submit all material (e.g. more detailed storyboards, alternatives explored, paper-based prototypes not covered in the presentation, full high level prototypes)
|
||||||
|
- Deadline: Friday 27th of May 2022, 5pm via Blackboard (35% of final mark)
|
||||||
17
content/notes/behaviour-driven-development.md
Normal file
17
content/notes/behaviour-driven-development.md
Normal file
@ -0,0 +1,17 @@
|
|||||||
|
---
|
||||||
|
title: Behaviour Driven Development
|
||||||
|
aliases: BDD
|
||||||
|
sr-due: 2022-04-14
|
||||||
|
sr-interval: 23
|
||||||
|
sr-ease: 292
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
# Behaviour Driven Development
|
||||||
|
Models should be created with the users needs in mind.
|
||||||
|
Required bahaviour determines acceptance criteria
|
||||||
|
This is called Behaviour Driven Development [BDD](None)
|
||||||
|
|
||||||
|
**Resources**
|
||||||
|
[Domain Driven Design with BDD](https://www.youtube.com/watch?v=Ju50D11EIoE)
|
||||||
|
[DDD videos](https://www.youtube.com/playlist?list=PLZBNtT95PIW3BPNYF5pYOi4MJjg_boXCG)
|
||||||
20
content/notes/big-o.md
Normal file
20
content/notes/big-o.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
---
|
||||||
|
title: Big-O
|
||||||
|
sr-due: 2022-06-01
|
||||||
|
sr-interval: 62
|
||||||
|
sr-ease: 271
|
||||||
|
---
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Big-O
|
||||||
|
>Big O means $f(n) = O(g(n))$ if there is some constant $A > 0$ such that for all sufficiently large n, $f(n) ≤ A × g(n).$
|
||||||
|
|
||||||
|
- Big O provides *upper bounds* only. (usually on worst case runtimes)
|
||||||
|
- sometimes cost will be much less
|
||||||
|
- does not take special cases into account
|
||||||
|
- upper bound
|
||||||
|
- $O$ says that $g(n)$ provides an upper bound for $f(n)$
|
||||||
|
- "Insertion sort is $O(n^2)$" -> the maximum number of basic operations in never more than some constanct times $n^2$
|
||||||
|
- if $f(n) =O(g(n))$ then the opposite is also true
|
||||||
|
- usually $f(n)$ is complex but $g(n)$ is very simple
|
||||||
19
content/notes/big-theta.md
Normal file
19
content/notes/big-theta.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
---
|
||||||
|
title: Big theta
|
||||||
|
sr-due: 2022-04-27
|
||||||
|
sr-interval: 41
|
||||||
|
sr-ease: 290
|
||||||
|
---
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### 0.1 Big-Θ
|
||||||
|
>Big theta means $f(n) = \Theta(g(n))$ if there are constants 0 < B < A such that for all sufficiently large n, ==$B × g(n) ≤ f(n) ≤ A × g(n)$==
|
||||||
|
|
||||||
|
- Upper and lower bound
|
||||||
|
- $Θ$ says that $g(n)$ provides **upper** and **lower** bound for $f(n)$
|
||||||
|
- "selection sort is $\Theta(n^2)$" -> the maximum number of operations will be bounded bothh above and below by some constant times $n^2$
|
||||||
|
- $f(n) = \Theta(g(n))$ means that f and g have similar growth rates
|
||||||
|
- if $f(n) = \Theta(g(n))$ then the opposite is also true
|
||||||
|
- usually $f(n)$ is complex but $g(n)$ is very simple
|
||||||
125
content/notes/birth-of-hci.md
Normal file
125
content/notes/birth-of-hci.md
Normal file
@ -0,0 +1,125 @@
|
|||||||
|
---
|
||||||
|
title: Birth of HCI
|
||||||
|
---
|
||||||
|
# Birth of HCI
|
||||||
|
ENIAC (one of the first programmable, electronic computers) 1946, and the first six programmers: Kay McNulty, Betty Jennings, Betty Snyder, Marlyn Meltzer, Fran Bilas, and Ruth Lichterman
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
DEC PDP-8 and TI 980 (1960’s), PDP-8 is an octal computer (switches in three-bit configurations), TI 980 is a hexadecimal machine (4-bit configuration). Not interactive
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Batch processing using punch cards, still not interactive (1950s -1970s)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
IBM System/360 (mainframe computer in the 70s), Altair 8800 (one of the first home computers)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
visicalc (Dan Bricklin 1979), and Apple II (1977)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical communication system, MIT press.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical communication system, MIT press.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
“The Mother of All Demos”, presented by Douglas Engelbart (1968) at (ACM/IEEE) Computer Society's Fall Joint Computer Conference See full demo: https://www.youtube.com/watch?v=yJDv-zdhzMY
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
“Dynabook” Alan C. Kay. (1972), “Personal Computer for Children of All Ages”
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Apple Newton (1993) and Apple iPad (2010)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
1992/93 - IBM Simon First smartphone Phone, pager, calculator, address book, fax machine, and e-mail device
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Ramesh Raskar, Greg Welch, Matt Cutts, Adam Lake, Lev Stesin and Henry Fuchs (1998) "The Office of the Future : A Unified Approach to Image-Based Modeling and Spatially Immersive Displays,"
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
1981 - Steve Manns’s “Wearable Computing” Start of a series of prototypes for wearable computing, cyborgs, and mediated reality (-> Google Glass) www.wearcam.org, www.eyetap.org
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Nokia N95 (2007) and Apple iPhone (2007)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Major innovations in HCI (Myers 1998)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
5
content/notes/books.md
Normal file
5
content/notes/books.md
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
---
|
||||||
|
title: Books
|
||||||
|
---
|
||||||
|
# Books
|
||||||
|
[All the light we cannot see](content/notes/all-the-light-we-cannot-see.md)
|
||||||
108
content/notes/branch.md
Normal file
108
content/notes/branch.md
Normal file
@ -0,0 +1,108 @@
|
|||||||
|
---
|
||||||
|
title: Branch
|
||||||
|
sr-due: 2022-04-10
|
||||||
|
sr-interval: 13
|
||||||
|
sr-ease: 210
|
||||||
|
---
|
||||||
|
#### 0.1.1 Review Questions
|
||||||
|
1. name and describe two methodologies for using branches. Acronym for methodologies -> (GOOF)
|
||||||
|
- gitflow
|
||||||
|
- very structured
|
||||||
|
- uses a set of branches each with a specific purpose
|
||||||
|
- On the main branch
|
||||||
|
- focused on not creating new branches
|
||||||
|
- smaller self-contained commits are better
|
||||||
|
- Off the main branch
|
||||||
|
- most work occurs on a branch
|
||||||
|
- Feature branches
|
||||||
|
- each features has it's own branch which is merged and ~~deleted~~ can be worked on after completion
|
||||||
|
1. what is the difference between a topic/feature branch and a persistent branch
|
||||||
|
- feature branch
|
||||||
|
- used for a fixed term task such as a bug or a feature
|
||||||
|
- persistent branch
|
||||||
|
- branch that exists for the lifetime of the project
|
||||||
|
|
||||||
|
2. what is continuous intergration
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
#review
|
||||||
|
|
||||||
|
# Branch
|
||||||
|
Split current dev path into two to work on e.g., a bug or a feature
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 1 Overview
|
||||||
|
- allows users to work independently
|
||||||
|
- development continues independently along each branch
|
||||||
|
- can easily switch between branches
|
||||||
|
- can push a branch without affecting others
|
||||||
|
- branches can be merged back into the original
|
||||||
|
- always at least one main branch (usually master, main, trunk)
|
||||||
|
|
||||||
|
## 2 Default branch
|
||||||
|
used to be called master
|
||||||
|
now called main
|
||||||
|
|
||||||
|
## 3 Methodologies
|
||||||
|
### 3.1 Working on the main branch
|
||||||
|
focuses on not creating branches
|
||||||
|
- over time long branches become difficult to merge
|
||||||
|
- smaller, self-contained changes are encouraged
|
||||||
|
- focus on main code objective, avoiding side-experiments
|
||||||
|
|
||||||
|
sometimes this is not possible
|
||||||
|
- complex bugs or features need branches
|
||||||
|
|
||||||
|
pair programming
|
||||||
|
- e.g., vs code allows multiple developers to work on the same code at the same time.
|
||||||
|
|
||||||
|
### 3.2 Working off the main branch
|
||||||
|
- branches can be shared with teams
|
||||||
|
- still isolated commits from the main branch
|
||||||
|
- more commits can be added to a branch _after_ it has been merged
|
||||||
|
|
||||||
|
### 3.3 Feature branching
|
||||||
|
all new features are developed in a separate branch
|
||||||
|
merging to the branch "adds" that feature
|
||||||
|
after a feature is added, it call still be added to using the same branch
|
||||||
|
|
||||||
|
### 3.4 Gitflow
|
||||||
|
viewed as ovecomplicated
|
||||||
|
a set of shell scripts helps it be used
|
||||||
|
highly structured
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- main branch -> branch has commit for release versions
|
||||||
|
- develop branch -> branch is where development occurs
|
||||||
|
- feature branch -> branches branch off development branch
|
||||||
|
- release branch -> branch polishes for release
|
||||||
|
- hotfix -> branches of main branch thence into develop
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 4 continuous integration
|
||||||
|
- [CI vs feature branch](https://www.youtube.com/watch?v=v4lijkq6Myfc)
|
||||||
|
- [cl vs feature branch](https://www.youtube.com/watch?v=IXQEi1O5!OI)
|
||||||
|
|
||||||
|
## 5 Topic/feature branch
|
||||||
|
- created for a specific purpose .e.g, bug/feature
|
||||||
|
- can pull from remote without marge conflicts (should be only one person working on branch)
|
||||||
|
- the more short-lived branches are the less likely there are to be merge conflicts with main
|
||||||
|
|
||||||
|
## 6 Persistent branch
|
||||||
|
- long term branch that exists for the lifetime of the project
|
||||||
|
- e.g.,
|
||||||
|
- release branches
|
||||||
|
- release v1, start on v2
|
||||||
|
- security flaw in v1, needs to be fixed
|
||||||
|
- v2 not finished yet
|
||||||
|
- create branch at last v1 commit and fix there
|
||||||
|
- also fix in v2 (if applicable)
|
||||||
|
- v1 branch will last until v2 is released
|
||||||
|
- specialsed versions of code base
|
||||||
|
- e.g., to support specific platforms or hardware
|
||||||
|
- e.g., to support feaures for a specific customer
|
||||||
|
- features for this specilised version on go on that branch
|
||||||
|
- keeps specialised code out of main codebase
|
||||||
23
content/notes/business-analyst.md
Normal file
23
content/notes/business-analyst.md
Normal file
@ -0,0 +1,23 @@
|
|||||||
|
---
|
||||||
|
title: Business analyst
|
||||||
|
sr-due: 2022-05-14
|
||||||
|
sr-interval: 53
|
||||||
|
sr-ease: 290
|
||||||
|
---
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Business anlayst
|
||||||
|
Gather, document, verify, record business requirements
|
||||||
|
- mostly works with people - not coding
|
||||||
|
- within context of business model and strategy
|
||||||
|
|
||||||
|
Needs both business and ICT knowledge
|
||||||
|
- acts as bridge between mangement, user, and dev team
|
||||||
|
- understands integreation of ICT into business
|
||||||
|
|
||||||
|
Needs good interpersonal skills
|
||||||
|
- uncooperative uers
|
||||||
|
- reluctant managers
|
||||||
|
- free spirited devs
|
||||||
|
|
||||||
38
content/notes/business-functions.md
Normal file
38
content/notes/business-functions.md
Normal file
@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: Business functions
|
||||||
|
---
|
||||||
|
# Business functions
|
||||||
|
- what the business ought to be doing
|
||||||
|
- _not_
|
||||||
|
- who, how, stucture, tech
|
||||||
|
|
||||||
|
each business function becomes a set of features within an info system
|
||||||
|
|
||||||
|
## 1 Id business functions
|
||||||
|
- verb phrases
|
||||||
|
- id what the business ought to be doing ⇒ e.g., "accept payment from customer"
|
||||||
|
- id how => "we accept payments online banking and credit card"
|
||||||
|
- always ask "what is the objective"
|
||||||
|
- remove redundancies
|
||||||
|
- model the id'd functions as _use cases_
|
||||||
|
|
||||||
|
## 2 Use case
|
||||||
|
"A list of actions defining the interactions betweeen a role and a system to achiece a goal"
|
||||||
|
high level description of how people interact with a system
|
||||||
|
|
||||||
|
story of how the business works
|
||||||
|
|
||||||
|
should be:
|
||||||
|
- simple
|
||||||
|
- aimed at stakeholders
|
||||||
|
- understandable by non-tech people
|
||||||
|
- should use ubiquitous language
|
||||||
|
- also useful for system devs
|
||||||
|
|
||||||
|
can use text (Cockburn, fowler) or diagrams (function catalog, UML case diagrams)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 3 UML
|
||||||
|
unified modeling language
|
||||||
|
- use case - class - state - activity - sequence - deployment etc
|
||||||
26
content/notes/business-process-model-and-notation.md
Normal file
26
content/notes/business-process-model-and-notation.md
Normal file
@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
title: Business Process Model and Notation
|
||||||
|
aliases: BPMN
|
||||||
|
---
|
||||||
|
# BPMN - Business Process Model and Notation
|
||||||
|
- graphical diagramming language
|
||||||
|
- free international vendor standard developed by the object management group
|
||||||
|
- shows only the order of activites
|
||||||
|
- when, not under what conditions
|
||||||
|
- do not:
|
||||||
|
- detail the activites
|
||||||
|
- describe how it is informed
|
||||||
|
|
||||||
|
### 0.1 swimlanes
|
||||||
|
identify the business role for each activity
|
||||||
|
|
||||||
|
### 0.2 Other features
|
||||||
|
- looping back
|
||||||
|
- types of branch gateway
|
||||||
|
- parallel execution
|
||||||
|
- collaboration with external entities (pools)
|
||||||
|
- executable if using the right infrastructure
|
||||||
|
|
||||||
|
### 0.3 Examples
|
||||||
|
|
||||||
|
|
||||||
18
content/notes/business-process-model.md
Normal file
18
content/notes/business-process-model.md
Normal file
@ -0,0 +1,18 @@
|
|||||||
|
---
|
||||||
|
title: Business process model
|
||||||
|
---
|
||||||
|
# 3 Business process model
|
||||||
|
- graphical depiction fo one ormore business proccesses
|
||||||
|
- some variant of a flowchart
|
||||||
|
- many different approaches
|
||||||
|
- BPMN
|
||||||
|
- UML activity diagrams
|
||||||
|
- data flow diagrams DFDs
|
||||||
|
- good for security
|
||||||
|
- business process execution language BPEL
|
||||||
|
- prgramm how a proces with go
|
||||||
|
- can be executed
|
||||||
|
- subject oriented business process mangement (s-BPM)
|
||||||
|
- and many more
|
||||||
|
- may be execultable
|
||||||
|
- developed alongside data models (ERDs, class diagrams etc)
|
||||||
29
content/notes/business-process.md
Normal file
29
content/notes/business-process.md
Normal file
@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
title: Business process
|
||||||
|
---
|
||||||
|
# Business process
|
||||||
|
- A sequence of tasks or steps required to carry out a particular business function e.g.,:
|
||||||
|
- pocure new assets
|
||||||
|
- apply for leave
|
||||||
|
- process and orer
|
||||||
|
- enrol a student
|
||||||
|
- paper and or computer based processes
|
||||||
|
- processes can have sub-processes ⇒ nested hierarchy
|
||||||
|
- terminology
|
||||||
|
- business processes are also know as workflows
|
||||||
|
- activity usually means the same thing as tasl
|
||||||
|
|
||||||
|
|
||||||
|
### 0.1 example: processing an order
|
||||||
|
1. sales dept recieves and enters order into system
|
||||||
|
1. system triugger automated credit check bu finance dept
|
||||||
|
2. if credit not OK, STOP order
|
||||||
|
2. warhouse staff fulfill order
|
||||||
|
1. check availability in warehouse
|
||||||
|
2. if any item out of stick transfer to back order process
|
||||||
|
3. pack items for shipping
|
||||||
|
3. finance dept generated invoice
|
||||||
|
4. send shipment and invoice to customer
|
||||||
|
|
||||||
|
|
||||||
|
e.g., www.otago.ac.nz/study/enrolment/index.html
|
||||||
6
content/notes/cheat-sheets.md
Normal file
6
content/notes/cheat-sheets.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
---
|
||||||
|
title: Cheat Sheets
|
||||||
|
---
|
||||||
|
|
||||||
|
[Git Cheat Sheet](content/notes/git-cheat-sheet.md)
|
||||||
|
[WinComposeS](content/notes/wincomposes.md)
|
||||||
47
content/notes/combined-evals.md
Normal file
47
content/notes/combined-evals.md
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: Combined evals
|
||||||
|
---
|
||||||
|
| Heuristic | Severity | Location | Issue | Recommendation |
|
||||||
|
|:-------------------------------------------------------------|:---------------------------|:----------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||||
|
| visibility of system status | 3 | Call | The the close window button does not leave the meeting. It pops up the small view. If the user closes this window. The user still does not leave the meeting and there is not GUI | make closing the windows prompt the user if they want to leave the meeting |
|
||||||
|
| error prevention | 3 | Call | The application crahed when cadence tried to take a snapshot. Then I could still see him even though he didn't know he was still in the meeting | The snapshot feature should not cause a crash. And when the GUI closes, the user should leave the meeting |
|
||||||
|
| Recognition rather than recall | 3 | N/A | I do not know how to add somebody else as a contact. I found a way to share a link to my profile, but I don’t know how to use a link that was shared with me. | There should be clear and obvious steps on how to add a contact. If the person has no contacts then the buttons should be displayed more prominently. |
|
||||||
|
| Visibility of system status | 3 | Call | After Skype restarted from the snapshot button crash, the interface seemed like I wasn’t in a call: there was no call overlay, I couldn’t see or hear the other person, and the buttons prompted to start a call rather than stop it. However, my partner could actually see and hear me the whole time, without me knowing! | The application should always tell you when you are in a call. |
|
||||||
|
| User control and freedom | 3 | Private conversation | Logging out and logging in again permanently deletes the entire private conversation on your side without warning. | It should remember the conversation, or if this isn’t possible, it should warn you about the consequences before you log out. |
|
||||||
|
| Visibility of system status | 3 | Call | If a skype window is closed while in a audio or video call, you remain in the call, despite the app being closed. | Either have a warning that the app is closing but you will remain in the call, or have a warning that closing the app will terminate your connection to the call |
|
||||||
|
| Visibility of system status | 2 | Audio/video settings | It is not clear whether or not the microphone test is running | There should be a visible indicator showing that the microphon test is running |
|
||||||
|
| Visibility of system status | 2 | Screenshare | The only indicator that you are sharing your screen is the button changing from “start sharing” to “stop sharing”. It is easy to forget you are sharing, which could potentially cause huge embarrassment! | There should be a permanent indicator that is visible even while using other applications. |
|
||||||
|
| Help users recognise and recover from errors | 2 | Account creation | You cannot use a PNG image as a profile picture, only a JPEG image. | Allow PNG images too, or automatically convert them when the user tries to pick them. |
|
||||||
|
| Flexibility and efficiency of use | 2 | Audio/video settings | When adjusting your audio and videos settings the setting for your webcam is hidden | It should be moved up so the use doesn't have to scroll |
|
||||||
|
| recognition rather than recall | 2 | Call | After opening the sidebar during a call there is no indication of how to hide it | There should be a button to close the sidebar during a call |
|
||||||
|
| User control and freedom | 2 | Mini Viewer | When ‘minimising’ Skype into a mini-player while on video call, the icon for screen-share is visible, and easily confused with the ‘maximise’ button to return the screen to the normal viewer | Have the button for screen share clearer of its purpose, and have a resize option when in mini-player |
|
||||||
|
| Match between system and the real world | 2 | Contacts list | Contacts who have sent you a message are not displayed in the “chats” section until you send a message back. | Text chats should always be displayed in the text chats section. |
|
||||||
|
| consistency and standards | 2 | Call | When one participant enters together mode, it force all the participant into together mode. But the users must all individually leave together mode. | It should be made clear that this is how is works as this was unexpeted behaviour |
|
||||||
|
| Flexibility and efficiency of use | 2 | Call | To click the horizontal dot menu in the bottom left the user must mouse over the react button which opens a popup. This menu usually closes after the mouse is moved off but sometimes it stays | The react menu should be moved or the mouse over function should be fixed |
|
||||||
|
| User control and freedom | 2 | Call | My partner has the ability to use a custom background image, but I don’t have this feature on my end. | Everybody should have the feature! I don’t know why I don’t have it. |
|
||||||
|
| Match between system and the real world | 2 | Private conversation | There is a feature to start a private conversation. Does this imply that conversations are usually not private? | The application should describe what a private conversation means, and explain whatever the downsides are that mean that it can’t be the default option. |
|
||||||
|
| Aesthetic and minimalist design | 2 | Call | When switching applications, Skype opens a floating window to contain the call, which will overlap other applications. | This feature is helpful but there needs to be a way to permanently dismiss it so people can work while in a call. |
|
||||||
|
| Consistency and standards | 2 | N/A | Quitting and restarting the application caused me to be logged out. | It’s a program that is installed on my computer, so it makes sense to keep me logged in. |
|
||||||
|
| recognition rather than recall | 2 | Call | not clear how to exit together mode | Have some indicator of |
|
||||||
|
| User control and freedom | 2 | Text chat | You cannot send a message that starts with a slash. | You should be able to send messages starting with a slash. |
|
||||||
|
| Recognition rather than recall | 2 | General | The toolbar that typically runs along the top of the screen is only available/viewable on the app after pressing alt, and making any action outside of the toolbar removes it again | Have an option to toggle toolbar on/off, and/or make it clearer that alt engages the toolbar |
|
||||||
|
| Help and documentation | 2 | General | To get help with Skype, the toolbar has to be toggled or settings must be opened and navigated through to find the help section | Have a more easily accessible help button, perhaps near the notifications/create group .etc |
|
||||||
|
| Visibility of system status | 2 | Chat | When removing a message, it is not made clear whether it will remove the message for everyone, or just yourself | Clarify that removing the message removes it for all participants |
|
||||||
|
| Flexibility and efficiency of use | 2 | Chat | To view bookmarked messages the user must navigate through their own profile to the bookmarks tab, where all bookmarks from all chats are kept, unsorted | Have an option to view bookmarked chats from certain groups, or have sorting criteria (date, group etc) |
|
||||||
|
| Aesthetic and minimalist design | 1 | Profile | When trying to click on your profile, if the status symbol is clicked a dropdown menu appears that gives you the ability to set your status (active, away, DnD etc), but this option is already included in the main dropdown from clicking onto your profile | Remove the separate function to help mis-click prevention |
|
||||||
|
| Match between system and the real world | 1 | DnD popup | When entering Do Not Disturb, a pop-up notifies you that you will not receive notifications while this is on. The popup has three options to exit it, ‘OK’, ‘View Settings’, and ‘Don’t ask me again’ | Improve the wording. Instead of Don’t ask me again, have ‘don’t show me this again’ or something of the like |
|
||||||
|
| User coontrol and freedom | 1 | Mini floating window | There is no dedicated button to maximise the floating window | A dedicated button should be added to maximise the floating window |
|
||||||
|
| Match between system and the real world | 1 | New Group | When a new group is created, there are two options presented for adding people to the group. There is ‘invite’ and ‘add people’ as two separate options. One option is for adding people through a link, and one is for inviting contacts. However, the add people option also contains an option for adding via link. | Remove the invite option, as both are covered under add people. |
|
||||||
|
| Consistency and standards | 1 | General | Throughout the app, there are multiple different designs for the add members button. There are three different actions that can be taken to add members to a group, and they all have different icons | Generalise the icons so that they all follow the same design, that way they are recognisable throughout the application |
|
||||||
|
| user control and freedom | 1 | Audio and video settings| cadence cannot add a custom background | It should at least say why he cant |
|
||||||
|
| Flexibility and efficiency of use | 1 | Call | When a user is using multiple displays, even if the large skype window is visible the floating windows opens | The floating window should no open in this situation |
|
||||||
|
| Help and docmentation | 1 | Call | When in a call by yourself the record button is grayed out and not pressable. There is no indication as to why | On mousing ove the button it should say why it is grayed out |
|
||||||
|
| Aesthetic and minimalist design | 1 | Account creation | On one of the screens, the “continue” button must be clicked twice in order to continue. | The continue button should continue. |
|
||||||
|
| help and documentation | 1 | Chat | no information about what private mode is | more information should be iven to the user |
|
||||||
|
| Aesthetic and minimalist design | 1 | Top of the screen | Informational banners appear here and do not go away until they are interacted with. They do not display helpful information. Sometimes duplicates should appear. | The banners should go away when they are no longer relevant. |
|
||||||
|
| Match between system and the real world | 1 | Call | “Together mode” is poorly named and does not accurately indicate what it will do. | This feature could have a name like “background scene”, or tooltip text, or some other help mechanism. |
|
||||||
|
| Match between system and the real world | 1 | Polls | Somebody clicking or unclicking a poll option sends me a notification sound. These poll events contain little information on their own, so there’s no reason for them to notify immediately. | Do not notify for people clicking polls. |
|
||||||
|
| Match between system and the real world | 1 | Contacts list | There is a feature to “send a contact”, though this offers to send a person their own contact card. | Do not offer to send people their own contact cards. |
|
||||||
|
| Consistency and standards | 1 | Call | The “view” button has an inconsistent appearance. It activates a dropdown but looks like a functional button. | Add an arrow indicator to the button so that it matches the rest of the application’s conventions. |
|
||||||
|
| Consistency and standards | 1 | Polls | It’s not obvious that a poll option highlighted in blue indicates that you should clicked that option. | Poll options should be represented as traditional checkboxes, rather than weird coloured rectangles. This also makes it clear that you can click again to undo your vote, which is already a feature. |
|
||||||
|
| Consistency and standards | 1 | Main menu | There is an option to “download the app”. I am already using the desktop application. | The text should state “phone app” to contrast it from desktop app. |
|
||||||
40
content/notes/consoles-terminals-shells.md
Normal file
40
content/notes/consoles-terminals-shells.md
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: Consoles Terminals Shells
|
||||||
|
sr-due: 2022-04-10
|
||||||
|
sr-interval: 27
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Consoles vs Terminals vs Shells
|
||||||
|
- consoles vs terminals/command line shells
|
||||||
|
- console -> io device which is part of a computer (physical terminal)
|
||||||
|
- console is the device: -> terminal is program inside that device
|
||||||
|
- terminal -> text input output environment (can be remote)
|
||||||
|
- windows terminal
|
||||||
|
- [shell](content/notes/shell.md) -> program which the terminal/console sends input to which sends command to the OS
|
||||||
|
- [unix shell](content/notes/unix-shell.md)
|
||||||
|
- powershell
|
||||||
|
- cmd
|
||||||
|
- bash, fish, zsh, ksh, sh, tsch
|
||||||
|
|
||||||
|
#### BREIF HISTORY
|
||||||
|
1. At first only main console
|
||||||
|
2. Then multiple terminals which allowed mulitple people to use one computer
|
||||||
|
3. Graphics support
|
||||||
|
4. Console + terminal merged
|
||||||
|
5. Virtual terminals -> no need for direct hardware control -> replaced by OS
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
graph LR
|
||||||
|
MainConsole --> MultipleTerminals --> GraphicsSupport --> MergeConsole&Terminal --> VirtualTerminals
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
resources:
|
||||||
|
[whats the differnce between a console a terminal and a shell](https://www.hanselman.com/blog/whats-the-difference-between-a-console-a-terminal-and-a-shell)
|
||||||
|
|
||||||
|
---
|
||||||
75
content/notes/continuous-integration.md
Normal file
75
content/notes/continuous-integration.md
Normal file
@ -0,0 +1,75 @@
|
|||||||
|
---
|
||||||
|
title: Continuous Integration
|
||||||
|
---
|
||||||
|
# Continuous Integration
|
||||||
|
## 1 What is it
|
||||||
|
continuous --> is always happening
|
||||||
|
integration --> connecting software components
|
||||||
|
|
||||||
|
inc ontrast to ad hoc, occasional integration:
|
||||||
|
- diverging component developmetnamy break integration
|
||||||
|
- repaiing software may be expensive
|
||||||
|
|
||||||
|
supports 'aglile' software dev
|
||||||
|
- like test driven development, help catch issues early
|
||||||
|
|
||||||
|
usually automated
|
||||||
|
|
||||||
|
## 2 Purposes
|
||||||
|
- checking code syntax
|
||||||
|
- e.g., have CI compile the code and report errors
|
||||||
|
- (local devs compilaer may be different from remote)
|
||||||
|
- checking semantics of code
|
||||||
|
- building docs
|
||||||
|
- e.g., auto run javadoc
|
||||||
|
- running projects code tests
|
||||||
|
- auto run JUnit, and report fails
|
||||||
|
|
||||||
|
## 3 Starting CI jobs
|
||||||
|
- from version control
|
||||||
|
- e.g., every commit triggered CI jobs to run
|
||||||
|
- starts on a push to server
|
||||||
|
- manually
|
||||||
|
- on a schedule
|
||||||
|
|
||||||
|
## 4 Runs asnychronously
|
||||||
|
- dont require devs to wait for completion
|
||||||
|
- common to run locally as well as on consistent standard environment
|
||||||
|
|
||||||
|
other timescales
|
||||||
|
- local checks as you commit
|
||||||
|
- checks as you type
|
||||||
|
- checks as you save
|
||||||
|
|
||||||
|
## 5 Output
|
||||||
|
since CI is asynchronous, its feedback is also
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- web badges showing status
|
||||||
|
- can send emails
|
||||||
|
- messaging platform
|
||||||
|
- e.g., slack, discord, teams
|
||||||
|
- webhooks etc
|
||||||
|
|
||||||
|
git project websites usually provide logging interface,
|
||||||
|
will watch scripts in virtual terminal and capture output from CI scripts
|
||||||
|
|
||||||
|
## 6 Github piplines
|
||||||
|
a pipeline has multiple _stages_
|
||||||
|
- e.g., test, build, deploy
|
||||||
|
each stages has multiple _jobs_
|
||||||
|
- e.g., JUnit, custom tests, etc
|
||||||
|
|
||||||
|
## 7 Yaml
|
||||||
|
most Ci frameworks use YAML for their configuration
|
||||||
|
structured text based formats
|
||||||
|
- python-like format or ≈JSON
|
||||||
|
|
||||||
|
## 8 configurationg from git repo
|
||||||
|
CI config often via file in git top-level directory
|
||||||
|
- CI is version managed
|
||||||
|
|
||||||
|
Gitlab pipeling specs go into .gitlab-ci.yaml:
|
||||||
|
- shows command sequece to run for a jon, within a stage
|
||||||
|
- output from commands is stored for a subsequent viewing
|
||||||
|
- indicates what files 'artifacts' should be kept from jobs
|
||||||
22
content/notes/crocs.md
Normal file
22
content/notes/crocs.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
title: CROCS
|
||||||
|
---
|
||||||
|
# CROCS - Communist republic of computer science
|
||||||
|
 
|
||||||
|
|
||||||
|
## TODO
|
||||||
|
- [ ] Setup gitlab
|
||||||
|
- [ ] add webhooks
|
||||||
|
## Information
|
||||||
|
## Roles
|
||||||
|
- Riley -> Team Leader
|
||||||
|
- Arlo -> gulag Inspector
|
||||||
|
- Jet -> Food Rationer
|
||||||
|
- Will -> Worker Scum
|
||||||
|
- Brad -> Propaganda Distributor
|
||||||
|
|
||||||
|
## Comms
|
||||||
|
Discord
|
||||||
|
|
||||||
|
## Meeting time
|
||||||
|
Friday Afternoon
|
||||||
3
content/notes/daily-notes.md
Normal file
3
content/notes/daily-notes.md
Normal file
@ -0,0 +1,3 @@
|
|||||||
|
---
|
||||||
|
title: Daily notes
|
||||||
|
---
|
||||||
62
content/notes/debugging.md
Normal file
62
content/notes/debugging.md
Normal file
@ -0,0 +1,62 @@
|
|||||||
|
---
|
||||||
|
title: Debugging
|
||||||
|
---
|
||||||
|
# Debugging
|
||||||
|
removing technical faults
|
||||||
|
isolaing and remove technical faults
|
||||||
|
a human process
|
||||||
|
- requires creativity/disipline/knowledge
|
||||||
|
- deepr understanding of code
|
||||||
|
|
||||||
|
debuggers are tools to help debugging
|
||||||
|
|
||||||
|
## 1 common approaches
|
||||||
|
temporarily add output of diagnostic info
|
||||||
|
- "printf" debugging
|
||||||
|
permanently include calls to logging system
|
||||||
|
- route to terminal, log files etc
|
||||||
|
|
||||||
|
## 2 debugging machine code
|
||||||
|
- cpu runs code instruction by instruction
|
||||||
|
- thus debugger can intervene between instructions
|
||||||
|
- most cpus help debugger interrupt and resume programs
|
||||||
|
- cpu reached current code via a sequence on callers
|
||||||
|
- called **stack trace** , aka back frame, stack frame etc
|
||||||
|
- may reach point where it cannot continue
|
||||||
|
- e.g., integer division by zero, program execution must stop
|
||||||
|
- stack trace of stopped program can be analysed
|
||||||
|
|
||||||
|
## 3 Imperative languages
|
||||||
|
These are language that are executed in a step-wise, sequentail manner.
|
||||||
|
|
||||||
|
- debug symbols
|
||||||
|
- e.g., method named, variable named
|
||||||
|
- source code context
|
||||||
|
- line numbers
|
||||||
|
- variable name
|
||||||
|
- function method names
|
||||||
|
|
||||||
|
## 4 doing debugging
|
||||||
|
### 4.1 stepping skipping running
|
||||||
|
- step into --> steps one statement and steps into function calls
|
||||||
|
- step over --> a step that treats function calls as statement
|
||||||
|
- step out --> return to the instruction after the function call you're in
|
||||||
|
- continue --> go back to running code continuously
|
||||||
|
|
||||||
|
### 4.2 controlling debugger execution
|
||||||
|
Can run normally --> debugger wil run when program crashes
|
||||||
|
Set Breakpoint --> debugger will stop program when/if that line is reached
|
||||||
|
- conditional breakpoints only suspend if a condition is true
|
||||||
|
Watch point --> program is suspended when some data changes (e.g., variables)
|
||||||
|
|
||||||
|
## 5 debugging non imperative languages
|
||||||
|
e.g, spreadsheet (Dataflow programming)
|
||||||
|
- no breakpoints
|
||||||
|
- must step through _iterations of computations_
|
||||||
|
|
||||||
|
e.g., Equation
|
||||||
|
- break into smaller parts
|
||||||
|
- try 'compile' it in multiple ways
|
||||||
|
|
||||||
|
e.g., Data base query (declarative programming)
|
||||||
|
- -reexpressign the query and comaring can be useful
|
||||||
182
content/notes/dependencies-among-attributes.md
Normal file
182
content/notes/dependencies-among-attributes.md
Normal file
@ -0,0 +1,182 @@
|
|||||||
|
---
|
||||||
|
title: Dependencies among attributes
|
||||||
|
---
|
||||||
|
# 2 Dependencies among attributes
|
||||||
|
### 0.1 Functional Depenencies (FDs)
|
||||||
|
For any given value of attribute A there is _exactly one_ associated value of attribute B, then A _functionally determines_ B (loosely)
|
||||||
|
|
||||||
|
This is the theoretical basis for normalisation, and uniqueness property of PK (A is unique with respect to B)
|
||||||
|
|
||||||
|
- one to one
|
||||||
|
- Written as: A --> B
|
||||||
|
- Equivalently, "B is functionally dependent on A"
|
||||||
|
- Within a single relation only
|
||||||
|
- every attribute functionally dependent of primary key (PK)
|
||||||
|
|
||||||
|
#### 0.1.1 Example 1
|
||||||
|
- consdier a specific student ID e.g., 123346
|
||||||
|
- this student ID is alwasys associated witha single studnet name (e.g., jane smith)
|
||||||
|
- even it the students name changes, that student ID will still be asociated with the name of only that on student
|
||||||
|
- _The value of studnet id dtermines the value of student name_
|
||||||
|
|
||||||
|
#### 0.1.2 Other examples
|
||||||
|
- student ID --> student name (but not vice versa)
|
||||||
|
- car registration --> car owner (but not vice versa)
|
||||||
|
- rego --> VIN
|
||||||
|
- VIN --> rego
|
||||||
|
- student ID --> name, semester address, mobile number
|
||||||
|
- car rego --> owener name
|
||||||
|
- IRD number + year --> tax payable
|
||||||
|
- product ID + order no --> quantity ordered
|
||||||
|
|
||||||
|
#### 0.1.3 Anti examples
|
||||||
|
- student ID + name --> birth date (ovekill, partial dependency)
|
||||||
|
- home address --> student name
|
||||||
|
- name --> birth date
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 0.2 Using Functional dependencies
|
||||||
|
To determine them:
|
||||||
|
- need detailed knowledge of thebusiness rules
|
||||||
|
- examine existing data sets
|
||||||
|
- not always practical when these are large or unknown
|
||||||
|
|
||||||
|
Can be represented using funcitonal dependency diagrams (FDDs)
|
||||||
|
|
||||||
|
Bottom up approach
|
||||||
|
- ERD is "top-down"
|
||||||
|
- FD best used as a design validation tool
|
||||||
|
|
||||||
|
### 0.3 Types of functional dependencies
|
||||||
|
#### 0.3.1 Dependencies on more that one attribute
|
||||||
|
non primary attributes that are dependent on two or more attributes
|
||||||
|
always arise with composite PKs
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
#### 0.3.2 Partial Dependency
|
||||||
|
Subset of left hand side determines right hand side
|
||||||
|
"extra attributes"
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
![Uploading file...mfewm]()
|
||||||
|
|
||||||
|
#### 0.3.3 Transitive dependency
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- part num determines supplier number
|
||||||
|
- supplier number determines supplier name
|
||||||
|
- part number determines supplier name
|
||||||
|
|
||||||
|
BUT 3 is already implied by 1 & 2 --> redundant supplier names
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 0.4 Multivalued dependencies (MVDs)
|
||||||
|
if for any given value of attribute A there is a _set_ of associated values of attribute S, the a _Multidetermines_ S (loosely)
|
||||||
|
|
||||||
|
- one to many
|
||||||
|
- written: A ↠ S
|
||||||
|
- equivalently, "S is multiply dependent on A"
|
||||||
|
- Generalistion of FDs: all FDs are MVDs, but not vice versa
|
||||||
|
- A is still unique with respect to S
|
||||||
|
|
||||||
|
#### 0.4.1 Examples
|
||||||
|
|
||||||
|
|
||||||
|
[Normalisation](content/notes/normalisation.md)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 2 Dependencies among attributes
|
||||||
|
### 2.1 Functional Depenencies (FDs)
|
||||||
|
For any given value of attribute A there is _exactly one_ associated value of attribute B, then A _functionally determines_ B (loosely)
|
||||||
|
|
||||||
|
This is the theoretical basis for normalisation, and uniqueness property of PK (A is unique with respect to B)
|
||||||
|
|
||||||
|
- one to one
|
||||||
|
- Written as: A --> B
|
||||||
|
- Equivalently, "B is functionally dependent on A"
|
||||||
|
- Within a single relation only
|
||||||
|
- every attribute functionally dependent of primary key (PK)
|
||||||
|
|
||||||
|
#### 2.1.1 Example 1
|
||||||
|
- consdier a specific student ID e.g., 123346
|
||||||
|
- this student ID is alwasys associated witha single studnet name (e.g., jane smith)
|
||||||
|
- even it the students name changes, that student ID will still be asociated with the name of only that on student
|
||||||
|
- _The value of studnet id dtermines the value of student name_
|
||||||
|
|
||||||
|
#### 2.1.2 Other examples
|
||||||
|
- student ID --> student name (but not vice versa)
|
||||||
|
- car registration --> car owner (but not vice versa)
|
||||||
|
- rego --> VIN
|
||||||
|
- VIN --> rego
|
||||||
|
- student ID --> name, semester address, mobile number
|
||||||
|
- car rego --> owener name
|
||||||
|
- IRD number + year --> tax payable
|
||||||
|
- product ID + order no --> quantity ordered
|
||||||
|
|
||||||
|
#### 2.1.3 Anti examples
|
||||||
|
- student ID + name --> birth date (ovekill, partial dependency)
|
||||||
|
- home address --> student name
|
||||||
|
- name --> birth date
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.2 Using Functional dependencies
|
||||||
|
To determine them:
|
||||||
|
- need detailed knowledge of thebusiness rules
|
||||||
|
- examine existing data sets
|
||||||
|
- not always practical when these are large or unknown
|
||||||
|
|
||||||
|
Can be represented using funcitonal dependency diagrams (FDDs)
|
||||||
|
|
||||||
|
Bottom up approach
|
||||||
|
- ERD is "top-down"
|
||||||
|
- FD best used as a design validation tool
|
||||||
|
|
||||||
|
### 2.3 Types of functional dependencies
|
||||||
|
#### 2.3.1 Dependencies on more that one attribute
|
||||||
|
non primary attributes that are dependent on two or more attributes
|
||||||
|
always arise with composite PKs
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
#### 2.3.2 Partial Dependency
|
||||||
|
Subset of left hand side determines right hand side
|
||||||
|
"extra attributes"
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
![Uploading file...mfewm]()
|
||||||
|
|
||||||
|
#### 2.3.3 Transitive dependency
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- part num determines supplier number
|
||||||
|
- supplier number determines supplier name
|
||||||
|
- part number determines supplier name
|
||||||
|
|
||||||
|
BUT 3 is already implied by 1 & 2 --> redundant supplier names
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.4 Multivalued dependencies (MVDs)
|
||||||
|
if for any given value of attribute A there is a _set_ of associated values of attribute S, the a _Multidetermines_ S (loosely)
|
||||||
|
|
||||||
|
- one to many
|
||||||
|
- written: A ↠ S
|
||||||
|
- equivalently, "S is multiply dependent on A"
|
||||||
|
- Generalistion of FDs: all FDs are MVDs, but not vice versa
|
||||||
|
- A is still unique with respect to S
|
||||||
|
|
||||||
|
#### 2.4.1 Examples
|
||||||
|
|
||||||
24
content/notes/developer.md
Normal file
24
content/notes/developer.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: Developer
|
||||||
|
sr-due: 2022-05-13
|
||||||
|
sr-interval: 46
|
||||||
|
sr-ease: 290
|
||||||
|
---
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Developer
|
||||||
|
|
||||||
|
|
||||||
|
## Role
|
||||||
|
- translate technical specs into code
|
||||||
|
- test code
|
||||||
|
- maintin system
|
||||||
|
- fix/locate bugs
|
||||||
|
- add/modify features
|
||||||
|
- test, test, test
|
||||||
|
|
||||||
|
## Skills
|
||||||
|
- logical thinking and problem solving
|
||||||
|
- coding and testing, toolchains
|
||||||
|
- database, networking etc, (as necessary)
|
||||||
64
content/notes/documentation.md
Normal file
64
content/notes/documentation.md
Normal file
@ -0,0 +1,64 @@
|
|||||||
|
---
|
||||||
|
title: Documentation
|
||||||
|
---
|
||||||
|
# Documentation
|
||||||
|
## 1 Who, what where
|
||||||
|
- Audience
|
||||||
|
- users
|
||||||
|
- other devs
|
||||||
|
- your team members
|
||||||
|
- anyone trying to understand you software
|
||||||
|
- your future self
|
||||||
|
- Locations
|
||||||
|
- source code
|
||||||
|
- project repo
|
||||||
|
- emebedding in program
|
||||||
|
- hosted separately
|
||||||
|
- User expectations
|
||||||
|
- evolving towards software that _facilitates experimentation_
|
||||||
|
- No help docs => everything is self-explanatory
|
||||||
|
- high usability
|
||||||
|
- users familar with many abstractions
|
||||||
|
- e.g., touchscreens, menus, links
|
||||||
|
- API's
|
||||||
|
- for devs writing code to interact with your code
|
||||||
|
- typically coupled with docs
|
||||||
|
- entirely technical audience --> tool generated docs are okay
|
||||||
|
- not self explanatory
|
||||||
|
- used by devs unfamiliar with code base
|
||||||
|
- Project Docs
|
||||||
|
- meaningful commit msgs
|
||||||
|
- extra mangement with e.g., github
|
||||||
|
- issue tracking
|
||||||
|
- ensures relevant material is cross linked where possible
|
||||||
|
- can easily refer to source code
|
||||||
|
- Source code docs
|
||||||
|
- header comments
|
||||||
|
- software licencing
|
||||||
|
- support devs
|
||||||
|
- indicate code ownership
|
||||||
|
- in code comments on fields methods etc
|
||||||
|
- keep in sync with code changes
|
||||||
|
- descriptive variable/class/other names
|
||||||
|
|
||||||
|
## 2 Built in language support
|
||||||
|
- basic
|
||||||
|
- syntax for code comments
|
||||||
|
- indicate that the compiler should ingnore
|
||||||
|
- also more advanced like python "doc strings"
|
||||||
|
- Structured comments and docs
|
||||||
|
- machine parseable comments
|
||||||
|
- e.g., javadocs, perl plain old docs
|
||||||
|
- creates a doc website
|
||||||
|
- uses annotations e.g., @author, @returns, @param
|
||||||
|
- Literate programming
|
||||||
|
- donald knuth suggestions (1984)
|
||||||
|
- source code should be primarily natural language documentation
|
||||||
|
- executable code snippetrs are included within the description
|
||||||
|
- tools are used to:
|
||||||
|
- tangle the code snippets
|
||||||
|
- weave out the documentation
|
||||||
|
- Modern implementations
|
||||||
|
- jupyter notebooks
|
||||||
|
- swift playgrounds
|
||||||
|
- r markdown
|
||||||
44
content/notes/domain-driven-design.md
Normal file
44
content/notes/domain-driven-design.md
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
---
|
||||||
|
title: Domain Driven Design
|
||||||
|
aliases: DDD
|
||||||
|
sr-due: 2022-04-12
|
||||||
|
sr-interval: 19
|
||||||
|
sr-ease: 272
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
# Domain Driven Design
|
||||||
|
|
||||||
|
>A method of designing software by designing models of the domain and creating software which conforms to those models
|
||||||
|
|
||||||
|
Ubiquitous language -> The language a team agrees on to describe ideas in the problem domain
|
||||||
|
- This laguage becomes more and more refined as it is used
|
||||||
|
- This reduces misunderstandings
|
||||||
|
|
||||||
|
Diagram:
|
||||||
|
```mermaid
|
||||||
|
flowchart LR
|
||||||
|
subgraph Tactical Design Tools
|
||||||
|
subgraph Service
|
||||||
|
direction TB
|
||||||
|
B(Project)
|
||||||
|
C(Layers)
|
||||||
|
D(Modules)
|
||||||
|
E(Design Patters)
|
||||||
|
F(OOP)
|
||||||
|
G(Classes)
|
||||||
|
H(Objects)
|
||||||
|
I(Exe, jar, zip)
|
||||||
|
end
|
||||||
|
end
|
||||||
|
```
|
||||||
|
|
||||||
|
``` mermaid
|
||||||
|
flowchart LR
|
||||||
|
subgraph Strategic Design Tools
|
||||||
|
direction LR
|
||||||
|
Domain-->Sub-Domain1-->Service1
|
||||||
|
Domain-->Sub-Domain2-->Service2
|
||||||
|
Domain-->Sub-Domain3-->Service3
|
||||||
|
end
|
||||||
|
|
||||||
|
```
|
||||||
47
content/notes/entity-relationship-diagrams.md
Normal file
47
content/notes/entity-relationship-diagrams.md
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
---
|
||||||
|
title: Entity Relationship Diagrams
|
||||||
|
aliases: ERD, ERDs
|
||||||
|
---
|
||||||
|
# Entity Relationship Diagrams
|
||||||
|
|
||||||
|
|
||||||
|
cardinality
|
||||||
|
identifying vs non identifying relationship
|
||||||
|
|
||||||
|
labels are important - but not always needed
|
||||||
|
|
||||||
|
associative entity => changes many to many relationship with additional relationship
|
||||||
|
|
||||||
|
## 1 subtypes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
uses:
|
||||||
|
- model mutual exclusivity
|
||||||
|
- better for modelling not for implementation
|
||||||
|
|
||||||
|
## 2 parallel relationship
|
||||||
|
|
||||||
|
|
||||||
|
could model as separate relationships via staff subtypes
|
||||||
|
not very common
|
||||||
|
|
||||||
|
|
||||||
|
also an example of recursive many-to-many relationships
|
||||||
|
|
||||||
|
## 3 recursive relationship
|
||||||
|
labels are critical
|
||||||
|
usually 1:M can be 1:1 or M:M
|
||||||
|
|
||||||
|
|
||||||
|
## 4 dealing with data history
|
||||||
|
|
||||||
|
|
||||||
|
could be many to many relationships:
|
||||||
|
|
||||||
|
so associative relationship: 
|
||||||
|
|
||||||
|
|
||||||
|
what do we require:
|
||||||
|
- for the current point in time
|
||||||
|
- an histroical record how ⇒ must be selecetive to not use up to much space
|
||||||
62
content/notes/ethics.md
Normal file
62
content/notes/ethics.md
Normal file
@ -0,0 +1,62 @@
|
|||||||
|
---
|
||||||
|
title: Ethics
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
coded biases doco
|
||||||
|
# Ethics
|
||||||
|
## 1 Case studies
|
||||||
|
1. [facial recognition in US riots 2021-01-06](content/notes/facial-recognition-in-us-riots-2021-01-06.md)
|
||||||
|
2. [Anti govt protest china](content/notes/anti-govt-protest-china.md)
|
||||||
|
3. [How is safe enough for autonomous vehicles](content/notes/how-is-safe-enough-for-autonomous-vehicles.md)
|
||||||
|
|
||||||
|
### 1.1 Differences 1 vs 2
|
||||||
|
Govt vs vigilante
|
||||||
|
|
||||||
|
my judgements contain additionl context
|
||||||
|
e.g., pro-democratic vs anti
|
||||||
|
|
||||||
|
world contains vast differences
|
||||||
|
how systems of laws work
|
||||||
|
extent of civil liberties afforded to individuals
|
||||||
|
|
||||||
|
### 1.2 Discussion
|
||||||
|
When developing a technology you dont know what is could be used for
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 2 Ethical handling of data
|
||||||
|
- Data moves very quickly due to computerised systems
|
||||||
|
- privacy act 2020
|
||||||
|
- its unethical to ignore potential security problems
|
||||||
|
- df
|
||||||
|
|
||||||
|
## 3 Ethical handling of bias and errors, e.g., in AI
|
||||||
|
- large datasets oftenb incdlude bias and errors
|
||||||
|
- to AI trained on these datasets with also be biased
|
||||||
|
- e.g., facial recognition trining overrepresenting white males
|
||||||
|
- ML algorithgms are often opqaue
|
||||||
|
- its not possible to understand how decisions are reached
|
||||||
|
- makes asessing suitability of AI for a use case difficult
|
||||||
|
- explainable AI
|
||||||
|
- attacks e.g., 'trapdoors' within ML training data
|
||||||
|
|
||||||
|
## 4 False or misleading claims
|
||||||
|
- pressure to release can lead to false claims
|
||||||
|
- are features fully tested
|
||||||
|
- need to assess risks of bias
|
||||||
|
- e.g., AWS uptime information
|
||||||
|
- rumoured that service status colour is n management decision
|
||||||
|
-
|
||||||
|
|
||||||
|
## 5 Your responsibility
|
||||||
|
- dont stay silent
|
||||||
|
|
||||||
|
## 6 Professional reponsibilities
|
||||||
|
- comp science per se lacks profressional standards
|
||||||
|
- there are some prefessional bodies which encoede responsibilities
|
||||||
|
- ACM coc
|
||||||
|
- IEEE coc
|
||||||
|
- neither are specific to NZ
|
||||||
|
- Within NZ must consider treaty obligations
|
||||||
188
content/notes/evaluating-designs.md
Normal file
188
content/notes/evaluating-designs.md
Normal file
@ -0,0 +1,188 @@
|
|||||||
|
---
|
||||||
|
title: Evaluating designs
|
||||||
|
sr-due: 2022-04-07
|
||||||
|
sr-interval: 10
|
||||||
|
sr-ease: 210
|
||||||
|
---
|
||||||
|
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
#### Review questions
|
||||||
|
1. what are two of the five (PGRCW) isses to consider when evaluating designs
|
||||||
|
- precision and reliability
|
||||||
|
- are your evaulationg repeatable
|
||||||
|
- are they accurate
|
||||||
|
- generalizability
|
||||||
|
- do your findings apply to the real world
|
||||||
|
- realism
|
||||||
|
- do you results apply tot he real world
|
||||||
|
- comparison
|
||||||
|
- better than just "do you like it study"
|
||||||
|
|
||||||
|
3. what are the two styles of evaluation. How do they differ
|
||||||
|
- ~~qualitative and quantitative~~
|
||||||
|
- field and lab studies
|
||||||
|
|
||||||
|
4. when would you use a qualitative methods and when would you use a quantitative method
|
||||||
|
- qualitative when comparing designs
|
||||||
|
- quantitative when evaluating a single design
|
||||||
|
|
||||||
|
5. what are two stages of design and in each cycle which type of method should you use
|
||||||
|
- design stage qualitative
|
||||||
|
- implentation quantitative
|
||||||
|
|
||||||
|
6. give a brief description of one method of evaluation.
|
||||||
|
- feedback from experts
|
||||||
|
- usbility studies
|
||||||
|
- observation
|
||||||
|
- simulation/maths
|
||||||
|
- surveys/focus groups
|
||||||
|
- comparitive experiments
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Evaluating-designs
|
||||||
|
Why to evaluate using 'outside' people:
|
||||||
|
- how do we know if a [prototype](content/notes/prototyping.md) is good
|
||||||
|
- designer/developers are not 'fresh' -> they already have experience with the product
|
||||||
|
- designer/developers don't know what real users will do
|
||||||
|
|
||||||
|
## Issues to consider
|
||||||
|
- Reliability/precision
|
||||||
|
- how accurate is your study?
|
||||||
|
- Is is reproducible -> if it was repeated, would you get the same result
|
||||||
|
- Generalizability
|
||||||
|
- Is your sample representative
|
||||||
|
- Realism
|
||||||
|
- Would observed behaviour also occur in the wild
|
||||||
|
- Comparison
|
||||||
|
- Shows how different options were recieved
|
||||||
|
- rather than a "people liked it" study
|
||||||
|
- work involved/efficiency
|
||||||
|
- How cost efficient are your methods
|
||||||
|
|
||||||
|
## Factors to consider when choosing an evaluation method
|
||||||
|
- Stage in the cycle at which the evaluation is carried out -> (design / implementation)
|
||||||
|
- Style of evaluation -> (lab / field)
|
||||||
|
- Level of subjectivity or objectivity
|
||||||
|
- Type of measurement -> (qualitative / quantitative)
|
||||||
|
- Information provided -> (high-level / low-level)
|
||||||
|
- Immediacy of response -> (real-time / recollection of events)
|
||||||
|
- Level of interference implied -> (intrusiveness)
|
||||||
|
- Resources required -> (equipment, time, money, subjects, expertise, context)
|
||||||
|
|
||||||
|
## Styles of evaluation
|
||||||
|
##### Laboratory Studies
|
||||||
|
- 1st step: Designer evaluates his/her UI
|
||||||
|
- Specialised equipment for testing available
|
||||||
|
- Undisturbed (can be a good or bad thing)
|
||||||
|
- Allows for well controlled experiments
|
||||||
|
- Substitute for dangerous or remote real-world locations
|
||||||
|
- Variations in manipulations possible / alternatives
|
||||||
|
|
||||||
|
##### Field Studies
|
||||||
|
- Within the actual user’s working environment
|
||||||
|
- Observe the system in action
|
||||||
|
- Disturbance / interruptions (+/-)
|
||||||
|
- Long-term studies possible
|
||||||
|
- Bias: presence of observer and equipment
|
||||||
|
- Needs support / disturbs real workflow
|
||||||
|
|
||||||
|
## Quantitative vs Qualitative methods
|
||||||
|
##### Quantitative Measures
|
||||||
|
- Usually numeric
|
||||||
|
- E.g. # of errors, time to complete a certain task, questionnaire with scales
|
||||||
|
- Can be (easily) analysed using statistical techniques
|
||||||
|
- Rather objective
|
||||||
|
- Most useful in comparing alternative designs
|
||||||
|
- Test hypotheses
|
||||||
|
- Confirm designs
|
||||||
|
|
||||||
|
##### Qualitative Measures
|
||||||
|
- Non-numeric
|
||||||
|
- E.g. survey, interview, informal observation, heuristic evaluation
|
||||||
|
- Difficult to analyse, demands interpretation
|
||||||
|
- Rather subjective
|
||||||
|
- User’s overall reaction and understanding of design
|
||||||
|
- Generate hypotheses
|
||||||
|
- Find flaws
|
||||||
|
|
||||||
|
## Stage in cycle
|
||||||
|
##### Design Stage
|
||||||
|
- Only concept (even if very detailed) exists
|
||||||
|
- More experts, less users involved
|
||||||
|
- Greatest pay-off: early error detection saves a lot of development money
|
||||||
|
- Rather qualitative measures (exceptions: detail alternatives; fundamental questions, ...)
|
||||||
|
|
||||||
|
##### Implementation
|
||||||
|
- Artefact exists, sth. concrete to be tested
|
||||||
|
- More users, less experts involved
|
||||||
|
- Assures quality of product before or after deployment; bug detection
|
||||||
|
- Rather quantitative measures (exceptions: overall satisfaction, appeal, ...)
|
||||||
|
|
||||||
|
## Methods
|
||||||
|
### Usability studies
|
||||||
|
- Bringing people in to test Product
|
||||||
|
- Usage setting is not ecologically valid - usage in real world can be different
|
||||||
|
- can have tester bias - testers are not the same as real users
|
||||||
|
- cant compare interfaces
|
||||||
|
- requires physical contact
|
||||||
|
### Surveys and focus groups
|
||||||
|
+ quicly get feedback from large number of responses
|
||||||
|
+ auto tally ressults
|
||||||
|
+ easy to compare different products
|
||||||
|
- responder bias
|
||||||
|
- Not accurate representation of real product
|
||||||
|
* e.g., 
|
||||||
|
* Focus groups
|
||||||
|
* gathering groups of people to discuss an interface
|
||||||
|
* group setting can help or hinder
|
||||||
|
|
||||||
|
### Feedback from experts
|
||||||
|
- [Peer critique](None)
|
||||||
|
- [Dogfooding](None)
|
||||||
|
- Using tools yourself
|
||||||
|
- [Heuristic Evaluation](content/notes/heuristic-evaluation.md)
|
||||||
|
- structured feedback
|
||||||
|
|
||||||
|
### Comparative experiments
|
||||||
|
- in lab, field, online
|
||||||
|
- short or long duration
|
||||||
|
- which option is better?
|
||||||
|
- what matters most?
|
||||||
|
- can see real usage
|
||||||
|
- more actionable
|
||||||
|
|
||||||
|
### Participant observation
|
||||||
|
- observe what people do in the actual evironment
|
||||||
|
- usually more long term
|
||||||
|
- find things not present in short term studies
|
||||||
|
- [Observation](content/notes/observation.md)
|
||||||
|
|
||||||
|
### Simulation and formal models
|
||||||
|
- more mathmatical quantitative
|
||||||
|
- useful if you have a theory to test
|
||||||
|
- often used for input techniques
|
||||||
|
- can test multiple alternatives quickly
|
||||||
|
- typically simulation is used in conjugtion with [monte carlo optimisation](None)
|
||||||
|
|
||||||
|
## Query techniques
|
||||||
|
- [Interviews](content/notes/interviews.md)
|
||||||
|
- questionnaires
|
||||||
|
- less flexible
|
||||||
|
- larger samples possible
|
||||||
|
- design of questionnaire is for expert only
|
||||||
|
- use of standard (proven) questionnaires recommended
|
||||||
|
- types of questions:
|
||||||
|
- general (age, gender)
|
||||||
|
- open ended
|
||||||
|
- scalar (e.g., likert-like scales)
|
||||||
|
- multiple choice
|
||||||
|
- ranking
|
||||||
|
|
||||||
|
## Users
|
||||||
|
- users can come up with great ideas
|
||||||
|
- lead user -> need specific soluton that does not exist -> often make up their own solution
|
||||||
|
- extreme user -> use existing solution for it's intended purpose to an extreme degree
|
||||||
|
- typical user ->
|
||||||
36
content/notes/extreme-programming-xp.md
Normal file
36
content/notes/extreme-programming-xp.md
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
---
|
||||||
|
title: Extreme programming (XP)
|
||||||
|
sr-due: 2022-04-08
|
||||||
|
sr-interval: 17
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Extreme programming (XP)
|
||||||
|
|
||||||
|
^e9fd09
|
||||||
|
|
||||||
|
take current industry practices to the extreme
|
||||||
|
- focus of proven industry practices
|
||||||
|
- combine them innovatively to get better results
|
||||||
|
|
||||||
|
##### Values and principles
|
||||||
|
communication, simplicity, feedback, courage.
|
||||||
|
- Planning -> based on user stories
|
||||||
|
- Testing -> thorough testing at every step
|
||||||
|
- Pair programming -> watch, inspect, and trade off
|
||||||
|
- Simple designs -> based on agile modelling principles
|
||||||
|
- Refactoring -> redo and clean up as you go
|
||||||
|
- Collective code ownership -> egoless development, anyone can review and improve code
|
||||||
|
- Continuous integration -> grow the software continuously
|
||||||
|
- On-site customer -> get sign-off as you go
|
||||||
|
- System metaphor -> what should the final system look like? Small releases given to users frequently
|
||||||
|
- Forty-hour work week -> don’t overload the developers
|
||||||
|
- Coding standards -> follow industry standards for code
|
||||||
|
|
||||||
|
##### Three ring project approach
|
||||||
|
|
||||||
@ -0,0 +1,9 @@
|
|||||||
|
---
|
||||||
|
title: facial recognition in US riots 2021-01-06
|
||||||
|
---
|
||||||
|
# Capital riots face recognition
|
||||||
|
capital riots occured on 2021-01-06
|
||||||
|
|
||||||
|
there was video from the riots which contained faces
|
||||||
|
- facial recognition acquired a pic of each person
|
||||||
|
- faces were uploaded to a website
|
||||||
40
content/notes/faking-it-video-prototyping.md
Normal file
40
content/notes/faking-it-video-prototyping.md
Normal file
@ -0,0 +1,40 @@
|
|||||||
|
---
|
||||||
|
title: Faking it video prototyping
|
||||||
|
---
|
||||||
|
# Video prototyping
|
||||||
|
|
||||||
|
## 1 benefits
|
||||||
|
- cheap and fast
|
||||||
|
- great communication
|
||||||
|
- can serve as spec for devs
|
||||||
|
- ties interface design to tasks
|
||||||
|
|
||||||
|
## 2 fidelity
|
||||||
|
low-fi 2-5min brainstorm
|
||||||
|
mid-fi 1-4 paper prtotypes video
|
||||||
|
hi-fi slick +fancy for investors/management
|
||||||
|
|
||||||
|
## 3 shows
|
||||||
|
- like a storyboard, the whole tasks
|
||||||
|
- motivvationa and success
|
||||||
|
- draw on tasks you've observed
|
||||||
|
- illustrate importand tasks
|
||||||
|
- help scope minimum viable poduct
|
||||||
|
- forces you to make design decisions in a new way
|
||||||
|
|
||||||
|
## 4 steps
|
||||||
|
- outline (maybe use storyboards)
|
||||||
|
- fin to extemporize
|
||||||
|
- equiment
|
||||||
|
- a camera (not fancy needed)
|
||||||
|
- people
|
||||||
|
- realistic location
|
||||||
|
- focus on the message more than production values
|
||||||
|
|
||||||
|
## 5 considerations
|
||||||
|
- silent(with title cards) or with audio
|
||||||
|
- audio can be finicky
|
||||||
|
- interface can be anything
|
||||||
|
- mockups, paper prototypes, code
|
||||||
|
- can show success and failure of interfaces an failure
|
||||||
|
- edit as little as possible (time consuming)
|
||||||
61
content/notes/faking-it-wizard-of-oz.md
Normal file
61
content/notes/faking-it-wizard-of-oz.md
Normal file
@ -0,0 +1,61 @@
|
|||||||
|
---
|
||||||
|
title: Faking it Wizard of OZ
|
||||||
|
---
|
||||||
|
# Faking it Wizard of OZ
|
||||||
|
|
||||||
|
making interactive app quickly with minimal code
|
||||||
|
|
||||||
|
simulate interactive behaviour with human operators
|
||||||
|
|
||||||
|
- make interactive app without much code
|
||||||
|
- front end interface
|
||||||
|
- remote wizard controls user interface
|
||||||
|
- makes sense with is faster/cheaper/easier than making the real thing
|
||||||
|
- get feedback from users people
|
||||||
|
- hi-fi users think its more real
|
||||||
|
- low-fi: more license to suggest changes
|
||||||
|
|
||||||
|
## 1 making wizard protoypes
|
||||||
|
- find scenarios to protoypes
|
||||||
|
- create UI skeleton
|
||||||
|
- develop hooks for wizard input
|
||||||
|
- decide where and how the wizard will provide input
|
||||||
|
- remember not to fake stuff that it not feasible in real life
|
||||||
|
- rehearse wizard rile with colleague
|
||||||
|
|
||||||
|
## 2 running wizard protoypes
|
||||||
|
- practivce with friend
|
||||||
|
- recruit users
|
||||||
|
|
||||||
|
- two roles:
|
||||||
|
- facilitator ⇒ pprovides tasks and takes notes
|
||||||
|
- wizard ⇒ operaties interface
|
||||||
|
|
||||||
|
- user feedback
|
||||||
|
- think aloud
|
||||||
|
- retrospective
|
||||||
|
- heuristic evaluation
|
||||||
|
|
||||||
|
- debrief users
|
||||||
|
|
||||||
|
|
||||||
|
## 3 used throughout development
|
||||||
|
user can do less and less and the prototyp comes closer to realisation
|
||||||
|
|
||||||
|
## 4 advatages
|
||||||
|
- fast
|
||||||
|
- variable
|
||||||
|
- more real than papar prototypes
|
||||||
|
- finds bugs and pronlems with design
|
||||||
|
- places user at center
|
||||||
|
- can envision challenging to built application
|
||||||
|
- ability to look foward and "use" tech that isn't created yet
|
||||||
|
|
||||||
|
|
||||||
|
## 5 Disadvatages
|
||||||
|
- simulations may misrepresent otherwire imperfect tech
|
||||||
|
- mya simulate techs that not not exist (and mnay never)
|
||||||
|
- require training and can be inconsistent
|
||||||
|
- playing the wizard can be exhausting
|
||||||
|
- some features are difficult to simulate
|
||||||
|
- may not be appropriate
|
||||||
9
content/notes/finance.md
Normal file
9
content/notes/finance.md
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
---
|
||||||
|
title: Finance
|
||||||
|
---
|
||||||
|
# Finance
|
||||||
|
## Trading
|
||||||
|
[Options](content/notes/options.md)
|
||||||
|
|
||||||
|
## Tech
|
||||||
|
[Blockchain](None)
|
||||||
46
content/notes/git-cheat-sheet.md
Normal file
46
content/notes/git-cheat-sheet.md
Normal file
@ -0,0 +1,46 @@
|
|||||||
|
---
|
||||||
|
title: Git Cheat Sheet
|
||||||
|
---
|
||||||
|
#CheatSheet
|
||||||
|
# Git Cheat Sheet
|
||||||
|
#### 0.1.1 Commands
|
||||||
|
|
||||||
|
- Clone -> create local copy of remote repo
|
||||||
|
- Commit -> save changes to local repo
|
||||||
|
- Packages logically related collection of changes and save the permanently is repos history
|
||||||
|
- Each commit should address single well defined task
|
||||||
|
- Commits should be small and regular
|
||||||
|
- Should contain a brief, informative, message
|
||||||
|
- one line -> <50 (commit needing more than this are likely too large)
|
||||||
|
- multi line -> <72
|
||||||
|
- well defined, shared terminology
|
||||||
|
- consider what other devs need to know
|
||||||
|
- Stash -> temporarily store uncommited changes
|
||||||
|
- Push -> Upload changes from local repo to remote
|
||||||
|
- Pull -> Download and merge changes from remote repo into local repo (fetch + merge)
|
||||||
|
- Merge -> Merge changes from one brach into another
|
||||||
|
- merge when:
|
||||||
|
- pulling changes from remote into your repo
|
||||||
|
- merging from branch into main codebase
|
||||||
|
- Can merge any branch into any other branch
|
||||||
|
- good idea to regularly rebase specialised persistent branches to keep them in sync with the more general main codebase
|
||||||
|
- rebase topic branches before merging into main
|
||||||
|
- helps to deal with merge conflicts
|
||||||
|
- only branch is broken if you mess up
|
||||||
|
- can test for breakage before merging to main
|
||||||
|
- Merging is usually automatic
|
||||||
|
- sometimes merge algorithm can't resolve conflicting changes to the same code
|
||||||
|
- e.g., two devs change the same method at the same time
|
||||||
|
- conflict must then be manually resolved
|
||||||
|
- All VCS will check that your repo is up to date before pushing, and force you to push if not
|
||||||
|
- Tag -> name a particular commit e.g., for a release
|
||||||
|
|
||||||
|
#### 0.1.2 Terms
|
||||||
|
- Head -> most recent commit on Current branch
|
||||||
|
-[Branch](content/notes/branch.md) -> Split current dev path into two to work on e.g., a bug or a feature
|
||||||
|
- Repository -> Where the codebase/file are stored ^3b3a5d
|
||||||
|
- Contains meta-data about the previous vesions etc
|
||||||
|
- Merge commit -> commits which are derived from multiple parent commits
|
||||||
|
- Git tag -> e.g., v 1.0
|
||||||
|
- cannot be move by commits
|
||||||
|
- record metadata
|
||||||
128
content/notes/git.md
Normal file
128
content/notes/git.md
Normal file
@ -0,0 +1,128 @@
|
|||||||
|
---
|
||||||
|
title: Git
|
||||||
|
sr-due: 2022-04-12
|
||||||
|
sr-interval: 29
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Git
|
||||||
|
Git is a tool to track changes to sets of files
|
||||||
|
It is the most used [[Version Control Systems|VCS]
|
||||||
|
|
||||||
|
## Team git protocols
|
||||||
|
you can develop a team protocol for Git use
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- agree to commit often
|
||||||
|
- know what branches are being used and why
|
||||||
|
- consider pair programming / live sharing
|
||||||
|
- try not to touch lots of files without signalling why
|
||||||
|
- agree who's going to edit files that maight not auto merge
|
||||||
|
|
||||||
|
## web based repo access control
|
||||||
|
owner of repo chooses who can push to project
|
||||||
|
- maintainer -> cant remove data
|
||||||
|
- developer -> cant manage team
|
||||||
|
- reporter -> cant change codebase
|
||||||
|
- guest -> can view
|
||||||
|
|
||||||
|
### open source collaboration
|
||||||
|
you want contributions from everyone
|
||||||
|
but you dont want to manage user-level control
|
||||||
|
|
||||||
|
-> pull/merge requests
|
||||||
|
unknown users can fork then add a feature/bug then do a merge request which can be reviewed
|
||||||
|
|
||||||
|
## git repos
|
||||||
|
[Repositories](content/notes/git-cheat-sheet.md#^3b3a5d) maintain code history
|
||||||
|
can be conceptualised as a graph
|
||||||
|
```mermaid
|
||||||
|
graph RL
|
||||||
|
A[HEAD]-->1[MASTER]-->B((ab348b))-->C((hf33h3))
|
||||||
|
C-->D((3hh39h))
|
||||||
|
C-.Merge.->E((n3383b))
|
||||||
|
3[Branch]-->E
|
||||||
|
D-->H((kfj383))
|
||||||
|
E-->G((gj4jf4))
|
||||||
|
G-->H
|
||||||
|
H-->I((fjfj39))
|
||||||
|
I-->2[Inital Commit]
|
||||||
|
```
|
||||||
|
```mermaid
|
||||||
|
gitGraph:
|
||||||
|
checkout master
|
||||||
|
commit
|
||||||
|
commit
|
||||||
|
branch newbranch
|
||||||
|
checkout newbranch
|
||||||
|
commit
|
||||||
|
commit
|
||||||
|
checkout master
|
||||||
|
commit
|
||||||
|
merge newbranch
|
||||||
|
commit
|
||||||
|
commit
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
- nodes are commits -> immutable snapshots of the tracked files
|
||||||
|
- edges record how nodes emerged over time
|
||||||
|
- arrows can be read as "is derived from"
|
||||||
|
|
||||||
|
git is a [Decentralised and Centralised VCS](content/notes/version-control-systems.md#^98d838)
|
||||||
|
- every team members has their own local copy of the repo
|
||||||
|
- git repos are often syned with a server: github, gitlab,etc
|
||||||
|
|
||||||
|
## levels of complexity/Abstraction
|
||||||
|
```mermaid
|
||||||
|
graph TD
|
||||||
|
w(github gitlab from web browser)-->b(graphical ide's e.g., vscode)-->c(command line git)-->d(low level git plumbing commands)-->e(direct manipulation of records within repo's .git directory)
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
## Limitations/pain points
|
||||||
|
not designed for broad usability
|
||||||
|
- bottom up design stems from its implementaion,
|
||||||
|
- rather than top down design from user interface
|
||||||
|
- thus, command naming and syntax can be unintuitive
|
||||||
|
|
||||||
|
git is not suited to handling large data files
|
||||||
|
- git scans whole files to generate hash codes
|
||||||
|
- can use git lfs (large file support) to get around this
|
||||||
|
|
||||||
|
flexibility of git can lead to high cognitive load
|
||||||
|
- e.g., many ways to get others' commits to your repo
|
||||||
|
|
||||||
|
binary files e.g., JPEG images are treated as whole
|
||||||
|
- no differencing, no content merging
|
||||||
|
|
||||||
|
some text files may not have stable line structure
|
||||||
|
- e.g., XML data can be reordered wihout changing so:
|
||||||
|
- git can auto merge when this is destructive
|
||||||
|
- git may get confused and force you to merge
|
||||||
|
- e.g., node package-lock.json
|
||||||
|
- you can turn of auto-merge if you are working with files that may be problematic
|
||||||
|
|
||||||
|
## advantages
|
||||||
|
git repos' data structures are well designed
|
||||||
|
- clear in structure yet flexible and efficient
|
||||||
|
|
||||||
|
few dependencies
|
||||||
|
- widely available
|
||||||
|
- free and open source
|
||||||
|
|
||||||
|
community support around use of git is great
|
||||||
|
- eforts to get researches to use version control;
|
||||||
|
- github helped open source software flourish by making it easy for citizens to contribute to projects
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
24
content/notes/hci-big-picture.md
Normal file
24
content/notes/hci-big-picture.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: HCI Big Picture
|
||||||
|
sr-due: 2022-04-11
|
||||||
|
sr-interval: 28
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
# HCI Big Picture
|
||||||
|
|
||||||
|
>HCI is the cycle of design, implementation, evaluation of user interfaces
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
>"fail fast so you can succeed sooner"
|
||||||
|
|
||||||
|
**Focus on people**
|
||||||
|
|
||||||
|
Good design is good
|
||||||
|
Bad design costs lives, money, time
|
||||||
|
Bad design can be easily avoided using basic ideas like consistency and feedback
|
||||||
|
|
||||||
|
Joy of good design: When interaction becomes "invisible" - intuitive**
|
||||||
12
content/notes/hci.md
Normal file
12
content/notes/hci.md
Normal file
@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
title: HCI
|
||||||
|
---
|
||||||
|
#flashcards
|
||||||
|
|
||||||
|
# HCI
|
||||||
|
|
||||||
|
HCI definition::The design and use of computer technology, focused on the interfaces between users and computers
|
||||||
|
<!--SR:!2022-03-23,13,250-->
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
22
content/notes/heap.md
Normal file
22
content/notes/heap.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
title: Heap
|
||||||
|
---
|
||||||
|
# Heap
|
||||||
|
A tree
|
||||||
|
1. every elements should be greater than ites children
|
||||||
|
2. the structure should be filled from top to bottom and left to right
|
||||||
|
|
||||||
|
To remove
|
||||||
|
- remove from the top, replace with the last element
|
||||||
|
- to fix the first condition swap the top element with the highest of its children until fixed
|
||||||
|
|
||||||
|
To Add
|
||||||
|
- add to the next position
|
||||||
|
- If its larger than its parent then swap them
|
||||||
|
|
||||||
|
How deep
|
||||||
|
- each layer is twice as deep and the preceding one
|
||||||
|
- layer k can hold $2^k$ elements
|
||||||
|
- to store n elements we use k layers where $k = lg n$
|
||||||
|
- so we need ϴ(lg n) layers
|
||||||
|
- So any algorithm that 'walk along a branch' in while or in part will have Ο(n) complexity (assuming constant time work at each node)
|
||||||
123
content/notes/heuristic-evaluation.md
Normal file
123
content/notes/heuristic-evaluation.md
Normal file
@ -0,0 +1,123 @@
|
|||||||
|
---
|
||||||
|
title: Heuristic Evaluation
|
||||||
|
---
|
||||||
|
# Heuristic evaluation
|
||||||
|
>"Heuristics are strategies derived from previous experiences with similar problems"
|
||||||
|
jacob nielsen and rolf molich
|
||||||
|
|
||||||
|
help find usability problems
|
||||||
|
small set of 3-5 evaluators examine UI
|
||||||
|
independently check for compliance with usability principles
|
||||||
|
different evaluators will find different problems
|
||||||
|
evaluators only communicate afterwaards
|
||||||
|
findings are aggregated at the end
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 1 when?
|
||||||
|
- as part of need finding -> use experts to critique existing solutions
|
||||||
|
- before user testing -> identify minor issues before user testing
|
||||||
|
- before redesigning -> learn what works and what should change
|
||||||
|
- when you know there are problems but you need evidence -> "provide you with ammunition for design"
|
||||||
|
- before release -> smooth off rough edges
|
||||||
|
|
||||||
|
## 2 What
|
||||||
|
### 2.1 Process
|
||||||
|
#### 2.1.1 Overview
|
||||||
|
Helps find problems in design
|
||||||
|
- 3-4 evaluators examine UI
|
||||||
|
- independent reviewers check for compliance with usability principles
|
||||||
|
- each evaluator will find different problems
|
||||||
|
- evaluators only communicate afterwards and the findings are aggregated
|
||||||
|
can perform on working UI or sketches
|
||||||
|
|
||||||
|
#### 2.1.2 Phases
|
||||||
|
1. pre evaluation training ⇒ give evaluators needed domain knowledge and information on the scenario
|
||||||
|
2. evaluation ⇒ individuals evaluate then aggregate result
|
||||||
|
1. first as individuals
|
||||||
|
2. then sit all together and aggregate
|
||||||
|
3. Severity rating ⇒ determine how severe each problem is (priority). Can do first individually and then as a group
|
||||||
|
4. Debriefing ⇒ review with design team
|
||||||
|
|
||||||
|
#### 2.1.3 Individual
|
||||||
|
dont look search for heuristics individually
|
||||||
|
just go through the app (like a user). If we find issues, we assign them to categories
|
||||||
|
|
||||||
|
step through design several times
|
||||||
|
- examine details, flow, an architecture
|
||||||
|
- consult list of usability principles
|
||||||
|
- … and anything else that comes to mind
|
||||||
|
|
||||||
|
which principles
|
||||||
|
- Nielsen's heuristics
|
||||||
|
- category specific heuristics
|
||||||
|
- e.g., design goals, competitive analysis, existing designs
|
||||||
|
|
||||||
|
use violations for redesign/fix problems
|
||||||
|
|
||||||
|
multiple evaluators because no one finds everything
|
||||||
|
some will always find more than others (Rule of thumb 5 evaluators find ~75% of problems)
|
||||||
|
|
||||||
|
#### 2.1.4 Severity rating
|
||||||
|
- independently estimate after viewing
|
||||||
|
- allocate resources to fix problems
|
||||||
|
- estimate need for more usability tests
|
||||||
|
|
||||||
|
0. not problem
|
||||||
|
1. cosmetic problem
|
||||||
|
2. minor usability problem
|
||||||
|
3. major
|
||||||
|
4. catastrophe
|
||||||
|
|
||||||
|
#### 2.1.5 Debreifing
|
||||||
|
- with evaluators observers and dev team
|
||||||
|
- discuss general characteristics of UI
|
||||||
|
- suggest potential imporvements
|
||||||
|
- dev team estimate effort to fix
|
||||||
|
- brainstorm solutions
|
||||||
|
|
||||||
|
### 2.2 Nielsen's ten heuristics
|
||||||
|
visibility of system status
|
||||||
|
match between system and world
|
||||||
|
user control and freedom
|
||||||
|
consistency and standards
|
||||||
|
error prevention
|
||||||
|
recognition rather than recall
|
||||||
|
flexibility and efficiency of use
|
||||||
|
aesthetic and minimalist design
|
||||||
|
help users recognize, diagnose, and recover from errors
|
||||||
|
help and documentation
|
||||||
|
|
||||||
|
### 2.3 Heuristic evaluation vs user testting
|
||||||
|
|
||||||
|
heuristics | user testing
|
||||||
|
----------------- | --------------
|
||||||
|
faster | slower
|
||||||
|
1-2 hrs each |
|
||||||
|
results pre-interpreted |
|
||||||
|
^ done by experts |
|
||||||
|
less accurate | more acurate
|
||||||
|
does not take into account actual users | can find issues that experts might not have
|
||||||
|
value to alternate methods
|
||||||
|
^ find dfferent issues
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.4 Extra tips how to individual
|
||||||
|
- at least two passes each
|
||||||
|
- first get get feel for flow
|
||||||
|
- second to focus on specific elements
|
||||||
|
- if a system is "walk up and use" or evaluators are already domain expers ⇒ no assistance is needed
|
||||||
|
- otherwire might supply evaluators with scenarios
|
||||||
|
- each evaluators should list issues separately
|
||||||
|
- risk of repeating problematic aspect
|
||||||
|
- may not be possible to fix all problems
|
||||||
|
- where problems may be found
|
||||||
|
- single location in UI
|
||||||
|
- two or more locations that need to be compared
|
||||||
|
- problem with overall structure
|
||||||
|
- something is missing
|
||||||
|
- ambiguous with early prototypes
|
||||||
|
- sometimes ....
|
||||||
124
content/notes/heuristics-evaluation-assignment.md
Normal file
124
content/notes/heuristics-evaluation-assignment.md
Normal file
@ -0,0 +1,124 @@
|
|||||||
|
---
|
||||||
|
title: Heuristics Evaluation Assignment
|
||||||
|
---
|
||||||
|
[Jet - Ohyay](content/notes/jet-ohyay.md)
|
||||||
|
[Jet -Discord](content/notes/jet-discord.md)
|
||||||
|
[Combined evals](content/notes/combined-evals.md)
|
||||||
|
# Skype Heuristic Evaluation
|
||||||
|
Jet Hughes 9474308
|
||||||
|
|
||||||
|
Note: I did not recieve the Evaluation from Cadence until Thursday night and 5:52pm
|
||||||
|
|
||||||
|
## 1 Abstract
|
||||||
|
The purpose of this evaluation was to uncover existing usability and functionality issues with the Skype app, so that it's usabilty can be improved. Heuristic Evaluations were carried out by three individuals according to Jakob Nielsen's ten design heuristics and a severity scale of 0 (not an issue) to 4 (usability catastrophe).
|
||||||
|
|
||||||
|
Their tasks were to set up and carry out a meeting using the app, and to look out for violations of Neilsens ten heuristics.
|
||||||
|
|
||||||
|
The key findings of this evaluation revealed that while the app is mostly usable, there are a few major issues that need to be fixed.
|
||||||
|
|
||||||
|
## 2 Executive summary
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
The skype app is one of the most used online messaging and video call desktop applications. It allows users to "make free video and one-to-one and group calls, send instant messges and share files with other people on Skype" (_What Is Skype? | Skype Support_, n.d.).
|
||||||
|
|
||||||
|
In order to set up a meeting the user needed to press the Meet now button which is visible in many places. To add more participants the use can either call a group chat directly, or share a link to the meeting.
|
||||||
|
|
||||||
|
In addition to many minor issues, the evaluators were able to find multiple major usability issues within the app. The three most severe issues were:
|
||||||
|
|
||||||
|
**Finding 1: Visibility of system status** The windows OS close window button clooses skype without leaving the meeting. It opens the small floating window. This is not so bad, however, when the user closes the floating window, the user does still not leave the meeting, and is still visible to other users while having no indicator whatsoever that they are still in a call. This is a major issues as it is a privacy concern for the user.
|
||||||
|
|
||||||
|
It is reccomended that when closing the main window using the windows OS close button, the user should be prompted to leave the meeting.
|
||||||
|
|
||||||
|
**Finding 2: Error prevention and Visibility of system status** When Cadence tried to use the snapshot feature in a video call, the application GUI crashed. However, he was not kicked out of the meeting automatically, and I could still see and here him. Strangely, when he restarted the GUI, it did not show that he was in a meeting (I could still see him the the meeting). Then he called me while we were already in a meeting together (from my perspective). When I accepted his call, I was kicked out of my current meeting and added to the new one.
|
||||||
|
|
||||||
|
It is stongly reccomended that this issue is fixed ASAP. The GUI needs to be properly linked to the calls.
|
||||||
|
|
||||||
|
**Finding 3: Recognition rather than recall** Cadence was unable to find how to add a new contact. He was able to find a way to share a link to his profile. However In my GUI, I was very clear how to add a contact. The buttonw was displayed very prominently at the top of the contacts list. This seems to hint at an underlying issues that the GUI is not consistent across users. It is relevant to note that Cadence was using Linux and I windows.
|
||||||
|
|
||||||
|
There are two recommendation here. Firstly, the linux app should be changed so that it is easy. Secondly, consistency across operating systems should be made taken into account.
|
||||||
|
|
||||||
|
## 3 Acknowledgements
|
||||||
|
Group Members:
|
||||||
|
- Jet Hughes
|
||||||
|
- Cadence Ember
|
||||||
|
- Bradley Francis
|
||||||
|
|
||||||
|
## 4 Appendix
|
||||||
|
### 4.1 Combined
|
||||||
|
|
||||||
|
| Heuristic | Severity | Location | Issue | Recommendation |
|
||||||
|
|:-------------------------------------------------------------|:---------------------------|:----------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||||
|
| visibility of system status | 3 | Call | The the close window button does not leave the meeting. It pops up the small view. If the user closes this window. The user still does not leave the meeting and there is not GUI | make closing the windows prompt the user if they want to leave the meeting |
|
||||||
|
| error prevention | 3 | Call | The application crahed when cadence tried to take a snapshot. Then I could still see him even though he didn't know he was still in the meeting | The snapshot feature should not cause a crash. And when the GUI closes, the user should leave the meeting |
|
||||||
|
| Recognition rather than recall | 3 | N/A | I do not know how to add somebody else as a contact. I found a way to share a link to my profile, but I don’t know how to use a link that was shared with me. | There should be clear and obvious steps on how to add a contact. If the person has no contacts then the buttons should be displayed more prominently. |
|
||||||
|
| Visibility of system status | 3 | Call | After Skype restarted from the snapshot button crash, the interface seemed like I wasn’t in a call: there was no call overlay, I couldn’t see or hear the other person, and the buttons prompted to start a call rather than stop it. However, my partner could actually see and hear me the whole time, without me knowing! | The application should always tell you when you are in a call. |
|
||||||
|
| User control and freedom | 3 | Private conversation | Logging out and logging in again permanently deletes the entire private conversation on your side without warning. | It should remember the conversation, or if this isn’t possible, it should warn you about the consequences before you log out. |
|
||||||
|
| Visibility of system status | 3 | Call | If a skype window is closed while in a audio or video call, you remain in the call, despite the app being closed. | Either have a warning that the app is closing but you will remain in the call, or have a warning that closing the app will terminate your connection to the call |
|
||||||
|
| Visibility of system status | 2 | Audio/video settings | It is not clear whether or not the microphone test is running | There should be a visible indicator showing that the microphon test is running |
|
||||||
|
| Visibility of system status | 2 | Screenshare | The only indicator that you are sharing your screen is the button changing from “start sharing” to “stop sharing”. It is easy to forget you are sharing, which could potentially cause huge embarrassment! | There should be a permanent indicator that is visible even while using other applications. |
|
||||||
|
| Help users recognise and recover from errors | 2 | Account creation | You cannot use a PNG image as a profile picture, only a JPEG image. | Allow PNG images too, or automatically convert them when the user tries to pick them. |
|
||||||
|
| Flexibility and efficiency of use | 2 | Audio/video settings | When adjusting your audio and videos settings the setting for your webcam is hidden | It should be moved up so the use doesn't have to scroll |
|
||||||
|
| recognition rather than recall | 2 | Call | After opening the sidebar during a call there is no indication of how to hide it | There should be a button to close the sidebar during a call |
|
||||||
|
| User control and freedom | 2 | Mini Viewer | When ‘minimising’ Skype into a mini-player while on video call, the icon for screen-share is visible, and easily confused with the ‘maximise’ button to return the screen to the normal viewer | Have the button for screen share clearer of its purpose, and have a resize option when in mini-player |
|
||||||
|
| Match between system and the real world | 2 | Contacts list | Contacts who have sent you a message are not displayed in the “chats” section until you send a message back. | Text chats should always be displayed in the text chats section. |
|
||||||
|
| consistency and standards | 2 | Call | When one participant enters together mode, it force all the participant into together mode. But the users must all individually leave together mode. | It should be made clear that this is how is works as this was unexpeted behaviour |
|
||||||
|
| Flexibility and efficiency of use | 2 | Call | To click the horizontal dot menu in the bottom left the user must mouse over the react button which opens a popup. This menu usually closes after the mouse is moved off but sometimes it stays | The react menu should be moved or the mouse over function should be fixed |
|
||||||
|
| User control and freedom | 2 | Call | My partner has the ability to use a custom background image, but I don’t have this feature on my end. | Everybody should have the feature! I don’t know why I don’t have it. |
|
||||||
|
| Match between system and the real world | 2 | Private conversation | There is a feature to start a private conversation. Does this imply that conversations are usually not private? | The application should describe what a private conversation means, and explain whatever the downsides are that mean that it can’t be the default option. |
|
||||||
|
| Aesthetic and minimalist design | 2 | Call | When switching applications, Skype opens a floating window to contain the call, which will overlap other applications. | This feature is helpful but there needs to be a way to permanently dismiss it so people can work while in a call. |
|
||||||
|
| Consistency and standards | 2 | N/A | Quitting and restarting the application caused me to be logged out. | It’s a program that is installed on my computer, so it makes sense to keep me logged in. |
|
||||||
|
| recognition rather than recall | 2 | Call | not clear how to exit together mode | Have some indicator of |
|
||||||
|
| User control and freedom | 2 | Text chat | You cannot send a message that starts with a slash. | You should be able to send messages starting with a slash. |
|
||||||
|
| Recognition rather than recall | 2 | General | The toolbar that typically runs along the top of the screen is only available/viewable on the app after pressing alt, and making any action outside of the toolbar removes it again | Have an option to toggle toolbar on/off, and/or make it clearer that alt engages the toolbar |
|
||||||
|
| Help and documentation | 2 | General | To get help with Skype, the toolbar has to be toggled or settings must be opened and navigated through to find the help section | Have a more easily accessible help button, perhaps near the notifications/create group .etc |
|
||||||
|
| Visibility of system status | 2 | Chat | When removing a message, it is not made clear whether it will remove the message for everyone, or just yourself | Clarify that removing the message removes it for all participants |
|
||||||
|
| Flexibility and efficiency of use | 2 | Chat | To view bookmarked messages the user must navigate through their own profile to the bookmarks tab, where all bookmarks from all chats are kept, unsorted | Have an option to view bookmarked chats from certain groups, or have sorting criteria (date, group etc) |
|
||||||
|
| Aesthetic and minimalist design | 1 | Profile | When trying to click on your profile, if the status symbol is clicked a dropdown menu appears that gives you the ability to set your status (active, away, DnD etc), but this option is already included in the main dropdown from clicking onto your profile | Remove the separate function to help mis-click prevention |
|
||||||
|
| Match between system and the real world | 1 | DnD popup | When entering Do Not Disturb, a pop-up notifies you that you will not receive notifications while this is on. The popup has three options to exit it, ‘OK’, ‘View Settings’, and ‘Don’t ask me again’ | Improve the wording. Instead of Don’t ask me again, have ‘don’t show me this again’ or something of the like |
|
||||||
|
| User coontrol and freedom | 1 | Mini floating window | There is no dedicated button to maximise the floating window | A dedicated button should be added to maximise the floating window |
|
||||||
|
| Match between system and the real world | 1 | New Group | When a new group is created, there are two options presented for adding people to the group. There is ‘invite’ and ‘add people’ as two separate options. One option is for adding people through a link, and one is for inviting contacts. However, the add people option also contains an option for adding via link. | Remove the invite option, as both are covered under add people. |
|
||||||
|
| Consistency and standards | 1 | General | Throughout the app, there are multiple different designs for the add members button. There are three different actions that can be taken to add members to a group, and they all have different icons | Generalise the icons so that they all follow the same design, that way they are recognisable throughout the application |
|
||||||
|
| user control and freedom | 1 | Audio and video settings| cadence cannot add a custom background | It should at least say why he cant |
|
||||||
|
| Flexibility and efficiency of use | 1 | Call | When a user is using multiple displays, even if the large skype window is visible the floating windows opens | The floating window should no open in this situation |
|
||||||
|
| Help and docmentation | 1 | Call | When in a call by yourself the record button is grayed out and not pressable. There is no indication as to why | On mousing ove the button it should say why it is grayed out |
|
||||||
|
| Aesthetic and minimalist design | 1 | Account creation | On one of the screens, the “continue” button must be clicked twice in order to continue. | The continue button should continue. |
|
||||||
|
| help and documentation | 1 | Chat | no information about what private mode is | more information should be iven to the user |
|
||||||
|
| Aesthetic and minimalist design | 1 | Top of the screen | Informational banners appear here and do not go away until they are interacted with. They do not display helpful information. Sometimes duplicates should appear. | The banners should go away when they are no longer relevant. |
|
||||||
|
| Match between system and the real world | 1 | Call | “Together mode” is poorly named and does not accurately indicate what it will do. | This feature could have a name like “background scene”, or tooltip text, or some other help mechanism. |
|
||||||
|
| Match between system and the real world | 1 | Polls | Somebody clicking or unclicking a poll option sends me a notification sound. These poll events contain little information on their own, so there’s no reason for them to notify immediately. | Do not notify for people clicking polls. |
|
||||||
|
| Match between system and the real world | 1 | Contacts list | There is a feature to “send a contact”, though this offers to send a person their own contact card. | Do not offer to send people their own contact cards. |
|
||||||
|
| Consistency and standards | 1 | Call | The “view” button has an inconsistent appearance. It activates a dropdown but looks like a functional button. | Add an arrow indicator to the button so that it matches the rest of the application’s conventions. |
|
||||||
|
| Consistency and standards | 1 | Polls | It’s not obvious that a poll option highlighted in blue indicates that you should clicked that option. | Poll options should be represented as traditional checkboxes, rather than weird coloured rectangles. This also makes it clear that you can click again to undo your vote, which is already a feature. |
|
||||||
|
| Consistency and standards | 1 | Main menu | There is an option to “download the app”. I am already using the desktop application. | The text should state “phone app” to contrast it from desktop app. |
|
||||||
|
|
||||||
|
### 4.2 Single
|
||||||
|
#### 4.2.1 Bradley
|
||||||
|
|
||||||
|
|
||||||
|
#### 4.2.2 Jet
|
||||||
|
|
||||||
|
| Heuristic | Severity | Location | Description | Recommendation |
|
||||||
|
|:------------------------------------|:-----------------|:-----------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------|
|
||||||
|
| Visibility of system status | 2 | Audio/video settings | It is not clear whether or not the test is running | There should be a visible indicator showing that the microphon test is running |
|
||||||
|
| Flexibility and efficiency of use | 2 | Audio/video settings | When adjusting your audio and videos settings the setting for your webcam is hidden | It should be moved up so the use doesn't have to scroll |
|
||||||
|
| User coontrol and freedom | 1 | Mini floating window | There is no dedicated button to maximise the floating window | A dedicated button should be added to maximise the floating window |
|
||||||
|
| Flexibility and efficiency of use | 2 | Video call | To click the horizontal dot menu in the bottom left the user must mouse over the react button which opens a popup. This menu usually closes after the mouse is moved off but sometimes it stays | The react menu should be moved or the mouse over function should be fixed |
|
||||||
|
| Flexibility and efficiency of use | 1 | Video call | When a user is using multiple displays, even if the large skype window is visible the floating windows opens | The floating window should no open in this situation |
|
||||||
|
| Help and docmentation | 1 | Video call | When in a call by yourself the record button is grayed out and not pressable. There is no indication as to why | On mousing ove the button it should say why it is grayed out |
|
||||||
|
| recognition rather than recall | 2 | Video call | After opening the sidebar during a call there is no indication of how to hide it | There should be a button to close the sidebar during a call |
|
||||||
|
| recognition rather than recall | 2 | Video Call | not clear how to exit together mode | Have some indicator of |
|
||||||
|
| visibility of system status | 3 | Video Call | The the close window button does not leave the meeting. It pops up the small view. If the user closes this window. The user still does not leave the meeting and there is not GUI | make closing the windows prompt the user if they want to leave the meeting |
|
||||||
|
| error prevention | 3 | Video Call | The application crahed when cadence tried to take a snapshot. Then I could still see him even though he didn't know he was still in the meeting | when the GUI closes, the user should leave the meeting |
|
||||||
|
| consistency and standards | 2 | Video Call | When one participant enters together mode, it force all the participant into together mode. But the users must all individually leave together mode. | It should be made clear that this is how is works as this was unexpeted behaviour |
|
||||||
|
| user control and freedom | 1 | Video call | cadence cannot add a custom background | It should at least say why he cant |
|
||||||
|
| help and documentation | 1 | Video call | | |
|
||||||
|
| help and documentation | 1 | Chat | no information about what private mode is | more information should be iven to the user |
|
||||||
|
|
||||||
|
#### 4.2.3 Cadence
|
||||||
|
|
||||||
|
|
||||||
|
## 5 References
|
||||||
|
_What is Skype? | Skype Support_. (n.d.). Microsoft. Retrieved April 1, 2022, from https://support.skype.com/en/faq/fa6/what-is-skype
|
||||||
15
content/notes/how-is-safe-enough-for-autonomous-vehicles.md
Normal file
15
content/notes/how-is-safe-enough-for-autonomous-vehicles.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
---
|
||||||
|
title: How is safe enough for autonomous vehicles
|
||||||
|
---
|
||||||
|
# Case study 3 Autonomous vehicles
|
||||||
|
- How safe is safe enough?
|
||||||
|
- its impossible to be perfect
|
||||||
|
- discalimer about driving assistant in teslas
|
||||||
|
-
|
||||||
|
|
||||||
|
Not driving youself massively reduces reaction time
|
||||||
|
|
||||||
|
Allow user to set ethical bias of their vehicles AI
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
78
content/notes/induction.md
Normal file
78
content/notes/induction.md
Normal file
@ -0,0 +1,78 @@
|
|||||||
|
---
|
||||||
|
title: Induction
|
||||||
|
sr-due: 2022-04-23
|
||||||
|
sr-interval: 29
|
||||||
|
sr-ease: 272
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
tags: #review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Induction
|
||||||
|
## PECS
|
||||||
|
Phases of argument by induction
|
||||||
|
|
||||||
|
- Preparation -> most important
|
||||||
|
- Execution -> becomes routine if prep is good
|
||||||
|
- Checking -> second most important
|
||||||
|
- Satisfaction
|
||||||
|
|
||||||
|
### Preparation
|
||||||
|
- isolate the property that you are trying to verify and the parameter, n, associated with is
|
||||||
|
- e.g., min possible size of set of rank k is $2^n$
|
||||||
|
- Confirm by hand that for small values of the parameter, the property is true
|
||||||
|
- Use previous cases as assumptions
|
||||||
|
- Pause and reflect
|
||||||
|
- If you understand what's going on -> proceed to execution
|
||||||
|
|
||||||
|
### Execution
|
||||||
|
Technical and prescribed (once you're an expert you can take some liberties)
|
||||||
|
|
||||||
|
Four parts
|
||||||
|
- statement
|
||||||
|
- verificatio of base case
|
||||||
|
- inductive step
|
||||||
|
- conclusion
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- we will prove that, for every non-negative integer $n$, *insert property here*
|
||||||
|
- For $n = 0$, *The property* is true because *explicit verification of this case*
|
||||||
|
- for any $n > 0$, assuming *the property* is true for $n-1$ (or, for all $k < n$), *the property* is true at $n$ because *explain why we can take a step up*
|
||||||
|
- Therefore, by induction, *the property* is true for all n.
|
||||||
|
|
||||||
|
### Checking
|
||||||
|
Basically debugging without a compiler to find errors
|
||||||
|
- have you forgotten anything? e.g., the base case
|
||||||
|
- Does the inductive step work fro 0 to 1? or are they irregular
|
||||||
|
- Make sure that you are only assuming the result for things less than $n$
|
||||||
|
- ideally show someone and try to convince them (dont let them be polite)
|
||||||
|
- if necessary go back to execution or preparation
|
||||||
|
|
||||||
|
### Satisfaction
|
||||||
|
Commence satisfaction.
|
||||||
|
Confidence +100. 😆
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
### Union Find - min size for set of rank k
|
||||||
|
|
||||||
|
- Initially every element is its own representative and every element has rank 0;
|
||||||
|
- when we do a union operation, the the two reps have different ranks, the ranks stay the same
|
||||||
|
- when we do a union operation, if the two reps have the same rank, then the rank increases
|
||||||
|
|
||||||
|
minimum (and only) size of a rank 0 rep is 1
|
||||||
|
|
||||||
|
to get a rank 1 representative, we form a union of either a rank 0 and a rank 1 set or two rank 0 sets
|
||||||
|
for the minimum possible size, it must be the second case, and the two rank 0 sets must be each of minimum size 1, so this gives minimum size for a rank 1 set of 2
|
||||||
|
|
||||||
|
To get a rank 2 rep, we form a union of either rank 2 and rank 0 or 1 set, or two rank 1 sets
|
||||||
|
For the minimum possible size, it must be the second cae, and the two rank 1 sets must each be of minimum size 2, so this gives minimum size for a rank 2 set of 4
|
||||||
|
|
||||||
|
To get a rank $n$ rep, we form a union of either rank $n$ and rank $k$ set for some $k<n$ or two rank $n-1$ sets.
|
||||||
|
For the minimum possible size, it must be the second cae, and the two rank $n-1$ sets must each be of minimum size, which we are **assuming** $2^(n-1)$, so this gives minimum size for a rank $n$ set of
|
||||||
|
|
||||||
|
> $2^{n-1} + 2^{n-1} = 2\times2^{n-1} = 2^n$
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
87
content/notes/integrated-development-environments.md
Normal file
87
content/notes/integrated-development-environments.md
Normal file
@ -0,0 +1,87 @@
|
|||||||
|
---
|
||||||
|
title: Integrated Development Environments
|
||||||
|
aliases: IDE, IDEs, Integrated Development Environment, Integrated Development Environments
|
||||||
|
sr-due: 2022-04-28
|
||||||
|
sr-interval: 36
|
||||||
|
sr-ease: 300
|
||||||
|
---
|
||||||
|
#### Review Questions
|
||||||
|
1. How is a source code editor different from an IDE
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
# Integrated Development Environments
|
||||||
|
|
||||||
|
## Source code editors
|
||||||
|
- editor applications to help software development
|
||||||
|
- provide features that help editing code
|
||||||
|
- auto indent, bracket matching, syntax hl, auto completion, rapid navigation
|
||||||
|
- run/test code
|
||||||
|
|
||||||
|
## Integrated dev env
|
||||||
|
- allow you to remain within one application when carrying out software development work
|
||||||
|
- can edit source files
|
||||||
|
- can compile source files
|
||||||
|
- can run debugger
|
||||||
|
- integrates version management
|
||||||
|
- some attach tools to running applications
|
||||||
|
|
||||||
|
### LSP - syntax highlighting
|
||||||
|
- allows IDE's to communicate with a "language enging"
|
||||||
|
- ides dont need
|
||||||
|
|
||||||
|
shift from syntac to semantics
|
||||||
|
e.g.,
|
||||||
|
- vs code chck file on opening
|
||||||
|
- lsp reports type mismatches
|
||||||
|
- rich editor functionality
|
||||||
|
- autocompletion with appropriate context
|
||||||
|
- information displayed on mouse hover
|
||||||
|
- jumping to definitions on mouse hover
|
||||||
|
- safe refactoring -> better than blind search and replace
|
||||||
|
- diagnosticso -> e.g., display results of unit tests within editor
|
||||||
|
|
||||||
|
### Navigation
|
||||||
|
- within files
|
||||||
|
- bracket matching
|
||||||
|
- block folding
|
||||||
|
- multi file
|
||||||
|
- multiple files at the same time
|
||||||
|
- rapidly jump between files
|
||||||
|
- search across all files
|
||||||
|
- collaboration e.g., live sharing
|
||||||
|
|
||||||
|
### Modern IDEs
|
||||||
|
- microsoft
|
||||||
|
- vscode -> free open source, highly popular
|
||||||
|
- visual studio -> integrates mobile and cloud development
|
||||||
|
- java enivronments
|
||||||
|
- eclipse - early leader in java, supports other languages
|
||||||
|
- netbeans -> also includes web dev tooling
|
||||||
|
- jetbrains -> IntelliJ IDEA, pycharm, phpstorm
|
||||||
|
- google's android studio -> official android IDE
|
||||||
|
- apple's Xcode -> free, macOS/iOS focus
|
||||||
|
|
||||||
|
## Early programming
|
||||||
|
- dedicated machines
|
||||||
|
- punched card programmer: separate machine from computer than reads cards
|
||||||
|
- punched cards recore code and or data in binary
|
||||||
|
- grid of positions, each representing a binary digit (bit)
|
||||||
|
- each position in punches out, or not
|
||||||
|
- analgogue electronic devices where you phsyicall wire things up
|
||||||
|
- gaining interest now for use in machine learning
|
||||||
|
|
||||||
|
### Bootstrapping
|
||||||
|
- already built tools can be used to builder better tools for building better tools etc.
|
||||||
|
- e.g., first assembler was made in maching code. But after that they could use the assember to make a better assembler
|
||||||
|
|
||||||
|
### Early dev environments
|
||||||
|
- command line based
|
||||||
|
- text based terminals
|
||||||
|
- command shell is the running application
|
||||||
|
- Can use terminal to drive interactive languages
|
||||||
|
- can edit, store software code
|
||||||
|
- can compile cose and run resulting executables
|
||||||
|
- it is still practical to do software development this way
|
||||||
|
- vim etc
|
||||||
80
content/notes/interviews.md
Normal file
80
content/notes/interviews.md
Normal file
@ -0,0 +1,80 @@
|
|||||||
|
---
|
||||||
|
title: Interviews
|
||||||
|
sr-due: 2022-04-22
|
||||||
|
sr-interval: 30
|
||||||
|
sr-ease: 247
|
||||||
|
---
|
||||||
|
|
||||||
|
#review
|
||||||
|
#### Review questions
|
||||||
|
|
||||||
|
0. what type of questions should you avoid
|
||||||
|
|
||||||
|
2. when/how are interviews used in needfinding
|
||||||
|
|
||||||
|
2. when/how are interview used in requirements elicitaion
|
||||||
|
|
||||||
|
3. when/how are interviews used in evaluating designs
|
||||||
|
|
||||||
|
---------------------------------
|
||||||
|
# Interviews
|
||||||
|
## Use Cases
|
||||||
|
- [Evaluating designs](content/notes/evaluating-designs.md)
|
||||||
|
- [Requirements elicitation](content/notes/requirements-elicitation.md)
|
||||||
|
- [Needfinding](content/notes/needfinding.md)
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
- direct and stuctured
|
||||||
|
- semi structured
|
||||||
|
- usually top down
|
||||||
|
- effective for high level interface evaluation
|
||||||
|
- need careful planning, experts, difficult to analyse
|
||||||
|
- not a controlled experiment technique
|
||||||
|
|
||||||
|
## Conducting an interview
|
||||||
|
### Choosing participants
|
||||||
|
- some is better than none
|
||||||
|
- get pople who are representive of users
|
||||||
|
- users of existing similar system
|
||||||
|
- non-users -> why people arent using a system
|
||||||
|
- e.g., lecture support system
|
||||||
|
- teachers
|
||||||
|
- students
|
||||||
|
- staff
|
||||||
|
- admins
|
||||||
|
- parents
|
||||||
|
- freshman
|
||||||
|
- phd
|
||||||
|
- international domestic
|
||||||
|
- stronger and weaker
|
||||||
|
|
||||||
|
#### Recruiting
|
||||||
|
- Craiglist (in US)
|
||||||
|
- your network
|
||||||
|
- cheaper for less speciales users
|
||||||
|
- if you can convince people you are imporving the world they might volunteer
|
||||||
|
- if they think is is for profict they will expect to be paid
|
||||||
|
- if you cant pay -> you cant use a token of appreciation
|
||||||
|
|
||||||
|
### Process
|
||||||
|
- introduce yourself explaint he purpose
|
||||||
|
- the interview is about them, not you?
|
||||||
|
- begin with open, unbiased questions-> then follow up
|
||||||
|
- ask the questions, and let them answer
|
||||||
|
- have breaks and give them time
|
||||||
|
- have a clear separation between the general introduction, the actual interview, and post inteview discussions
|
||||||
|
|
||||||
|
### Questions to avoid:
|
||||||
|
- leading questions
|
||||||
|
- what would they do / like / want in a hypothetical scenario
|
||||||
|
- how often they do things
|
||||||
|
- how much they like things on an absolute scale
|
||||||
|
- avoid binary questions
|
||||||
|
|
||||||
|
## Pros/cons
|
||||||
|
+ free and open answers
|
||||||
|
+ sense of active contribution
|
||||||
|
+ oppportunity for follow up
|
||||||
|
- time consuming and resource intensive
|
||||||
|
- dependent of commication skills of analyst
|
||||||
|
- location/schedule can make this impractical
|
||||||
13
content/notes/jet-discord.md
Normal file
13
content/notes/jet-discord.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
---
|
||||||
|
title: Jet -Discord
|
||||||
|
---
|
||||||
|
# Discord
|
||||||
|
| Heuristic | Severity | Location | Description | Recommendation |
|
||||||
|
|-|-|-|-|-|
|
||||||
|
| visibility of system status | 1 | In a server | Noise suppresion off icon does not make it clear that noise suppresion is off | Should be made more clear |
|
||||||
|
| flexibility and efficiency of use | 2 | In a server | Not clear where to join calls for new users | Should have a short tutorial which shows this the first time a user enters a server |
|
||||||
|
| recognition rather than recall | 1 | In a server | Unclear what the "01 25" icon next to the voice channel means | should have description on mouse over |
|
||||||
|
| user control and freedom | 2 | Inbox | No option to close all mentions in inbox | Should add a button to close all mention in inbox |
|
||||||
|
| flexibility and efficiency of use | 1 | Chat | No bracket (or * _ ~ { ) matching | Should be added |
|
||||||
|
| user control and freedom | 1 | Chat | No way to customise slash commands | Should be added |
|
||||||
|
| help and documentation | 3 | Settings | No search bar | A search bar should be addeed |
|
||||||
16
content/notes/jet-ohyay.md
Normal file
16
content/notes/jet-ohyay.md
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
---
|
||||||
|
title: Jet - Ohyay
|
||||||
|
---
|
||||||
|
# ohyay
|
||||||
|
| Heuristic | Severity | Location | Description | Recommendation |
|
||||||
|
|-|-|-|-|-|
|
||||||
|
| aesthetic and minimalist design | 1 | General | User interface is ugly | Should be made to look better |
|
||||||
|
| flexibility and efficieny of use | 2 | In a room | not clear to find where to sign out | Should add a button to sign out from within a room |
|
||||||
|
| visibility of system status | 1 | In a room | There is not indication about which rooms you should be using | Should be able to restrict users to only enter certain rooms |
|
||||||
|
| user control and freedom | 2 | In the cafe | There is no way to change, mute, or adjust he volume of the music | A button/group of button should be added for this |
|
||||||
|
| flexibility and effieciency of use | 1 | In a room | The buttons for mute, video, share screen etc which are usually (in most video call apps) in the bottom middle of the screen are instead spread out in the top corners | Move them to the bottom middle of the screen |
|
||||||
|
| recognition vs recall | 2 | In a room | The icon to show and hide the left side bar is not clear | This icon should be changed to be more recogniseable |
|
||||||
|
| aesthetic and minimalist design | 1 | In the cafe | When at a table in the cafe almost a quater of the screen i taken up by a button to go leave the table | Should be made smaller |
|
||||||
|
| flexibility and efficiency of use | 1 | Posting a Question | The checkbox to make a question anonymous is very small and the text is not clickable | The text should be made clickable or the checkbox should be made larger |
|
||||||
|
| recognition vs recall | 1 | In a room | The '+1' icon next to questions is not clearly clickable | Should be made to look more like a clickable button |
|
||||||
|
| error prevention | 3 | In a room | The pop out button below the step to mic button opens a windows which is completely broken | Needs to be fixed or removed |
|
||||||
70
content/notes/lecture-07-unit-testing.md
Normal file
70
content/notes/lecture-07-unit-testing.md
Normal file
@ -0,0 +1,70 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 07 Unit Testing
|
||||||
|
sr-due: 2022-04-29
|
||||||
|
sr-interval: 26
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
|
||||||
|
#review
|
||||||
|
|
||||||
|
# LO's
|
||||||
|
- undnerstand that testing is useful for detecting bugs
|
||||||
|
- contrast different types of testting
|
||||||
|
- descrive the principle of test driven development
|
||||||
|
- explain how unit tests ar developed
|
||||||
|
- indicate how languages integreate unit test support
|
||||||
|
- apppreiciate limitation of software testing
|
||||||
|
|
||||||
|
# Lecture 07 Unit Testing
|
||||||
|
|
||||||
|
### 0.1 [Testing](content/notes/testing.md)
|
||||||
|
1. why is testing needed
|
||||||
|
|
||||||
|
2. what are three types of testing
|
||||||
|
|
||||||
|
3. what are some limitations of testing
|
||||||
|
|
||||||
|
### 0.2 [Test driven development](content/notes/test-driven-development.md)
|
||||||
|
1. what is testing driven development
|
||||||
|
|
||||||
|
### 0.3 [Unit testing](content/notes/unit-testing.md)
|
||||||
|
1. Breifly describe unit testing
|
||||||
|
|
||||||
|
2. What is a testing environment. Why is it useful
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
19
content/notes/lecture-08-debugging.md
Normal file
19
content/notes/lecture-08-debugging.md
Normal file
@ -0,0 +1,19 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 08 Debugging
|
||||||
|
sr-due: 2022-04-09
|
||||||
|
sr-interval: 8
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
1. what is a bug
|
||||||
|
2. debuggers vs debugging
|
||||||
|
3. common approaches
|
||||||
|
4. debug symbols
|
||||||
|
5. debugger operations
|
||||||
|
6. breakpoint and watch points
|
||||||
|
7. why technical faults are not always your fault 
|
||||||
|
|
||||||
|
# Lecture 8 debugging
|
||||||
|
[Debugging](content/notes/debugging.md)
|
||||||
9
content/notes/lecture-09-documentation.md
Normal file
9
content/notes/lecture-09-documentation.md
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 09 Documentation
|
||||||
|
sr-due: 2022-04-08
|
||||||
|
sr-interval: 8
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
# Lecture 09 Documentation
|
||||||
|
[Documentation](content/notes/documentation.md)
|
||||||
21
content/notes/lecture-10-continuous-integration.md
Normal file
21
content/notes/lecture-10-continuous-integration.md
Normal file
@ -0,0 +1,21 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 10 Continuous integration
|
||||||
|
sr-due: 2022-04-11
|
||||||
|
sr-interval: 8
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
1. explain the term continuous integration
|
||||||
|
2. describe different purposes for CI
|
||||||
|
3. indicate how CI jobs are usually triggered
|
||||||
|
4. understand implications of CI running asynchronously
|
||||||
|
5. Exlplain how to manage output from CI jobs
|
||||||
|
6. describe role of stages and jobs within gitlab pipelines
|
||||||
|
7. indicate how CI specifications are stored
|
||||||
|
|
||||||
|
|
||||||
|
# Lecture 10
|
||||||
|
[Continuous Integration](content/notes/continuous-integration.md)
|
||||||
24
content/notes/lecture-10-design-heuristics.md
Normal file
24
content/notes/lecture-10-design-heuristics.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 10 Design Heuristics
|
||||||
|
sr-due: 2022-04-13
|
||||||
|
sr-interval: 10
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Lecture 10 Prototyping and Design Heuristics
|
||||||
|
|
||||||
|
## 1 Wizard of OZ
|
||||||
|
[Faking it Wizard of OZ](content/notes/faking-it-wizard-of-oz.md)
|
||||||
|
simulating machine behavior with human operators
|
||||||
|
|
||||||
|
## 2 Video prototyping
|
||||||
|
[Faking it video prototyping](content/notes/faking-it-video-prototyping.md)
|
||||||
|
|
||||||
|
## 3 Creating and comparing alternatives
|
||||||
|
create multiple ideas in parallel rather than one after the other
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 4 Design heuristics
|
||||||
99
content/notes/lecture-10-heaps-and-heap-sort.md
Normal file
99
content/notes/lecture-10-heaps-and-heap-sort.md
Normal file
@ -0,0 +1,99 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 10 Heaps and heap sort
|
||||||
|
sr-due: 2022-04-08
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Lecture 10 Heaps and heap sort
|
||||||
|
## 1 Overview
|
||||||
|
[Heap](content/notes/heap.md)
|
||||||
|
|
||||||
|
## 2 Operations
|
||||||
|
### 2.1 Add element
|
||||||
|
Assumptions
|
||||||
|
- access first vacant position
|
||||||
|
- set (or find) the value $H.q$ stored in any (occupied) position $q$
|
||||||
|
- access parent of any given position
|
||||||
|
- identify when we're at the root
|
||||||
|
(all in constant time)
|
||||||
|
|
||||||
|
Outcome: Change $H$ by adding x to it, while maintaining the heap conditions
|
||||||
|
|
||||||
|
```
|
||||||
|
p <- first vacancy, H.p <- x
|
||||||
|
while p is not the root and H.parent(p) < H.p do
|
||||||
|
swap H.parent(p) and H.p
|
||||||
|
p <- parent(p)
|
||||||
|
end while
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
### 2.2 Remove the maximum
|
||||||
|
Outcome: Change H by removing its maximum (i.e., root) value wile maintaining the heap conditions
|
||||||
|
|
||||||
|
```
|
||||||
|
v <- H.root
|
||||||
|
set H.root to be the value stored in the last occupied position
|
||||||
|
p <- root
|
||||||
|
|
||||||
|
while p has children
|
||||||
|
if the largest value, H.c of a child of p is greater than H.p then
|
||||||
|
swap H.c and H.p, p <-c
|
||||||
|
else
|
||||||
|
Break
|
||||||
|
end if
|
||||||
|
end while
|
||||||
|
|
||||||
|
return v
|
||||||
|
|
||||||
|
```
|
||||||
|
|
||||||
|
|
||||||
|
### 2.3 Complexity
|
||||||
|
In addition, we move along a branch from an added element up to the root, fixing violations as we go
|
||||||
|
|
||||||
|
In removal, we move from the root down through some branch until all violations are fixed (can only occur if node has children)
|
||||||
|
|
||||||
|
So both loops do most Ο(lg n)
|
||||||
|
|
||||||
|
### 2.4 Storage
|
||||||
|
|
||||||
|
|
||||||
|
- Array
|
||||||
|
- root at position 0 and children at 1 and 2
|
||||||
|
- children of 1 to in 3 and 4, children of 2 go in 5 and 6
|
||||||
|
|
||||||
|
- first vacant pos --> heap[n]
|
||||||
|
- value at pos q --> heap[q]
|
||||||
|
- get parent of q --> parent(q) = (q-1)/2
|
||||||
|
- get children of q --> (2 * q) ± 2
|
||||||
|
- identify if q is root --> q == 0
|
||||||
|
|
||||||
|
### 2.5 Implementation
|
||||||
|
|
||||||
|
Use java.util.PriorityQueue
|
||||||
|
|
||||||
|
## 3 Heap Sort
|
||||||
|
In place and ϴ(n lg n)
|
||||||
|
|
||||||
|
- start with array
|
||||||
|
- using itself as a heap, add the elements one at a time until all been added
|
||||||
|
- Then remove them one at a time - the largest elements gets removed first and the place where is needs to be put gets freed from the map
|
||||||
|
|
||||||
|
## 4 Heap vs Merge
|
||||||
|
heap --> in place, ϴ(n lg n)
|
||||||
|
merge --> not in place, Ο(n lg n)
|
||||||
|
|
||||||
|
Merge is preferred because
|
||||||
|
|
||||||
|
- MS can take advantage of partially sorted data (hence ϴ() vs Ο())
|
||||||
|
- MS memory accesses are good fast
|
||||||
|
- overwrites allow for optimizations that swaps do not
|
||||||
|
|
||||||
|
extra memory cost of merge sort is negligible
|
||||||
|
|
||||||
|
∴ Merge sort is faster
|
||||||
|
|
||||||
20
content/notes/lecture-10-oop-concepts-and-uml.md
Normal file
20
content/notes/lecture-10-oop-concepts-and-uml.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 10 OOP Concepts and UML
|
||||||
|
sr-due: 2022-04-10
|
||||||
|
sr-interval: 7
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
1. what is the concept of encapsulation and how is it enforced for objects
|
||||||
|
2. how does and object refernce differ from a relational foreign key
|
||||||
|
3. give an example of how difference UML diagram types can be linked when modelling a system
|
||||||
|
|
||||||
|
# Lecture 10 OOP concepts and UML
|
||||||
|
[Objects](content/notes/objects.md)
|
||||||
|
|
||||||
|
[2 UML](content/notes/2-uml.md)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
150
content/notes/lecture-11-class-diagrams.md
Normal file
150
content/notes/lecture-11-class-diagrams.md
Normal file
@ -0,0 +1,150 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 11 Class diagrams
|
||||||
|
sr-due: 2022-04-08
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
# Revision questions
|
||||||
|
1. What is the purpose of stereotypes in UML?
|
||||||
|
2. What is multiplicity and how is it represented on associations between classes? Provide a drawn example which uses an association between two classes.
|
||||||
|
3. How are role names used for associations between classes and when should you use them?
|
||||||
|
4. Discuss the issues that arise around the use of composition in the context of “cart-like” entities.
|
||||||
|
5. Describe the relationship between role names and navigability in a class diagram.
|
||||||
|
6. Explain the difference bewteen a domain class diagram and a system class diagram.
|
||||||
|
|
||||||
|
---
|
||||||
|
# Lecture 11 Class Diagrams
|
||||||
|
e.g., 
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 1 Stereotypes
|
||||||
|
add further meaning to fields and methods
|
||||||
|
- e.g., << unique >>, << abstrat >>, << interface >>,
|
||||||
|
|
||||||
|
## 2 Packages
|
||||||
|
group classes together
|
||||||
|
break system to logical chunks
|
||||||
|
package diagram, a class diagram with nothing but packages
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 3 Associations
|
||||||
|
UML anaglogue of ERD relationsips
|
||||||
|
- multiplicity
|
||||||
|
- realtionshpa nd role names
|
||||||
|
|
||||||
|
PlUS
|
||||||
|
- naviagability --> instances of one class can pass messages to instances of another
|
||||||
|
- several differnt types, e.g., composition, aggregation, associateive classes
|
||||||
|
|
||||||
|
### 3.1 multuplicity
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
ERDsd effectively only do zero one many
|
||||||
|
UML can to any non negative integer
|
||||||
|
default is 1
|
||||||
|
|
||||||
|
### 3.2 association names
|
||||||
|
|
||||||
|
|
||||||
|
- usuallya verb phrase like "assings", "manages", "enrols in" ...
|
||||||
|
- more useful is conpetual level diagrams
|
||||||
|
- optional arrow head ()
|
||||||
|
|
||||||
|
### 3.3 Role names
|
||||||
|
|
||||||
|
|
||||||
|
At conceptual level, indicates role of class in association.
|
||||||
|
|
||||||
|
At implementation level:
|
||||||
|
- implies a field in class at opposite end
|
||||||
|
- should include visibility
|
||||||
|
- closely related to navigability
|
||||||
|
|
||||||
|
### 3.4 Navigability
|
||||||
|
|
||||||
|
|
||||||
|
specifies whether we can "navigate from one end of an association to another"
|
||||||
|
affects how we code access paths between objects
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- loan instance can see loanitem instances it contains via private field items
|
||||||
|
- a loanitem instance can't see loan instance that contains it
|
||||||
|
- must alwasy include relevant role names
|
||||||
|
- no arrows = two arrows = bidirectional
|
||||||
|
|
||||||
|
#### 3.4.1 why not always bidirectional
|
||||||
|
|
||||||
|
- more complex code --> many references/collections to manage
|
||||||
|
- navigation paths are not all equally important
|
||||||
|
- e.g., "what items are in this loan" vs "what loans does this item appear in"
|
||||||
|
- determined by requrements and typical usage
|
||||||
|
- some classes are more "central"
|
||||||
|
- usually at the "one" end of accociations
|
||||||
|
- often represent transactional entities e.g., loan, sale, order
|
||||||
|
- navigability readiates outwards from them
|
||||||
|
|
||||||
|
there are exceptions as always e.g., patron <-> item
|
||||||
|
|
||||||
|
|
||||||
|
### 3.5 Aggregation
|
||||||
|
|
||||||
|
|
||||||
|
one class is made up of one or more other classes
|
||||||
|
container and content instances _can_ exist separately
|
||||||
|
usually implied by multiplicity and navigability
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- computer is made u of several components
|
||||||
|
- library catalogue is made up of many items
|
||||||
|
|
||||||
|
|
||||||
|
### 3.6 Composition
|
||||||
|
|
||||||
|
|
||||||
|
stonger form of aggregation
|
||||||
|
container and content _cannot_ exist separately
|
||||||
|
usually implied by multiplicity and navigability
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
- building contains many rooms
|
||||||
|
- loan includes several items
|
||||||
|
|
||||||
|
- coicident lifetime
|
||||||
|
- multiplicity at least 1 at both ends
|
||||||
|
- deleting an containter must also delete all associated contents
|
||||||
|
- creating a container should also create some contents
|
||||||
|
|
||||||
|
|
||||||
|
### 3.7 Associative classes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- used for conceptual design
|
||||||
|
- similar to associative entities
|
||||||
|
- many to many relationship with additional independent fields
|
||||||
|
- resolved into class at implementation level
|
||||||
|
|
||||||
|
### 3.8 Specialisation generalisation
|
||||||
|
|
||||||
|
|
||||||
|
class inheritance
|
||||||
|
- e.g., book and disc are subclasses of (specialise) Item
|
||||||
|
- inherit all public fields and methods of superclass
|
||||||
|
- can add their own fields and methods
|
||||||
|
- Compare with specialisation of actors and use cases
|
||||||
|
|
||||||
|
## 4 Domain class model\
|
||||||
|
|
||||||
|
|
||||||
|
only modles the associations among concepts from problem domain
|
||||||
|
|
||||||
|
can be at conceptual level or implementation level
|
||||||
|
|
||||||
|
## 5 System class model
|
||||||
|
|
||||||
|
Models associations among domain objects and system components; implementation level only
|
||||||
86
content/notes/lecture-11-continuous-integration-2.md
Normal file
86
content/notes/lecture-11-continuous-integration-2.md
Normal file
@ -0,0 +1,86 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 11 Continuous Integration 2
|
||||||
|
sr-due: 2022-04-07
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
\
|
||||||
|
1. apprecitae that gitlab is a xomplex software
|
||||||
|
2. Understand where CI jobs scripts get run
|
||||||
|
3. explain why reposityory servers can host websites
|
||||||
|
4. Understandhow gitblab dternmimines awhen a CI script failed
|
||||||
|
5. Describe a way in which CI scrupts scan handle secrets
|
||||||
|
6. OUtline uses of local git hook scripts
|
||||||
|
|
||||||
|
# Lecture 11 Continuous Integration 2
|
||||||
|
|
||||||
|
Ci runs pipellines defined in .gitlab-ci.yaml asynchronously
|
||||||
|
|
||||||
|
ci usually tets abd buiolds your prokects
|
||||||
|
|
||||||
|
runs on a repo server
|
||||||
|
- usuially persistent, internet accessible
|
||||||
|
|
||||||
|
## 1 Gitlab overall architecture
|
||||||
|
 : not in exam
|
||||||
|
- many different services used
|
||||||
|
|
||||||
|
## 2 Gitlab runners
|
||||||
|
run CI scripts
|
||||||
|
- gitlab.com is a cloud computing service
|
||||||
|
- allows elf hosting which is what CS does
|
||||||
|
- altitude is a gitlab instance at CS
|
||||||
|
- servers to host runners that run CI scripts
|
||||||
|
- servers that host websites, e.g., cspages.otago.nz
|
||||||
|
- Gitlab can invoke runners that you host
|
||||||
|
- e.g., to use a particular GPU, or other hardware you have
|
||||||
|
- GItlab runner itself is a small program written in Go
|
||||||
|
|
||||||
|
### 2.1 Runner architecture
|
||||||
|
|
||||||
|
- runs jobs
|
||||||
|
- on isolated infrastructure
|
||||||
|
- ... to maintain secrity
|
||||||
|
- that is set up on demand
|
||||||
|
- ... handle load variation
|
||||||
|
- suits cloud computing
|
||||||
|
|
||||||
|
RHS shows GitLab.com's CI hosting
|
||||||
|
uses google cloud
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
 : not in exam
|
||||||
|
|
||||||
|
## 3 How CI chagned website hosting
|
||||||
|
|
||||||
|
- need to share stifacts produced by CI jobs
|
||||||
|
- using the web to share artefacts is ideal
|
||||||
|
- so now most repo servers also host websites
|
||||||
|
- these are static websites: all content is fixed
|
||||||
|
- CI can run static website generators (SSGs)
|
||||||
|
- git repo contains source code of website
|
||||||
|
- CI pipelines transforms souce code into HTML fiels
|
||||||
|
- HTML files then hosted as a website by repo sever
|
||||||
|
|
||||||
|
e.g., https://cosc202.cspages.otago.ac.nz
|
||||||
|
|
||||||
|
|
||||||
|
## 4 Debugging CI scripts
|
||||||
|
|
||||||
|
- first ensure config files YAML is valid
|
||||||
|
- vuilt in gitlab editor checks YAML as you type
|
||||||
|
- commands runfrom shell that fail return an exit code
|
||||||
|
- most unix shells sotre exit code of previous commands in $
|
||||||
|
- So if variable $? (return code of prevous command) is non-zero, the previous command failed
|
||||||
|
- Git lab considers CI job as failed if any command fails
|
||||||
|
- your shell scripting can choose to hide this exit code
|
||||||
|
- e.g., `if command supposed to fail; then true; else true; fi`
|
||||||
|
- Complex scripting? Beste to put script in a file and run it from CI
|
||||||
|
|
||||||
|
## 5 Secrets used by CI scripts
|
||||||
|
|
||||||
|
|
||||||
60
content/notes/lecture-11-design-heuristics-2.md
Normal file
60
content/notes/lecture-11-design-heuristics-2.md
Normal file
@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 11 Design Heuristics 2
|
||||||
|
sr-due: 2022-04-08
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Lecture 11 Design Heuristics 2
|
||||||
|
|
||||||
|
## 1 Show system status
|
||||||
|
- show system stats
|
||||||
|
|
||||||
|
- feedback depends on response time
|
||||||
|
- <1s just show outcome
|
||||||
|
- ~1s feedback that activity is underway
|
||||||
|
- >>1s show fractional progress time
|
||||||
|
|
||||||
|
- 0.1 seconds --> feels instantaneusly
|
||||||
|
- 1 second --> about the limit for flow to be uinteruippted
|
||||||
|
- 10 seeconds --> the limit for keeping users attention
|
||||||
|
|
||||||
|
when:
|
||||||
|
- when action is requried
|
||||||
|
- show storage space
|
||||||
|
- making changes
|
||||||
|
- next steps --> user input required
|
||||||
|
- completion --> some task has finished
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 2 familiar metaphors and language
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
imitating familiar real life
|
||||||
|
|
||||||
|
Categories
|
||||||
|
- good
|
||||||
|
- 
|
||||||
|
- bad
|
||||||
|
- 
|
||||||
|
|
||||||
|
## 3 user freedom and control
|
||||||
|
|
||||||
|
wan tt ogive th user the feelin thtey can freelyi explore the app
|
||||||
|
and the freeodm to control i it
|
||||||
|
|
||||||
|
- general flow
|
||||||
|
- undo/redo
|
||||||
|
|
||||||
|
e.g., 
|
||||||
|
e.g., 
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
140
content/notes/lecture-12-design-heuristics-3.md
Normal file
140
content/notes/lecture-12-design-heuristics-3.md
Normal file
@ -0,0 +1,140 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 12 Design Heuristics 3
|
||||||
|
sr-due: 2022-04-15
|
||||||
|
sr-interval: 9
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# Lecture 12 Design Heuristics 3
|
||||||
|
## 1 Consistency and standards
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
good and bad
|
||||||
|
- standards (user interface guidelines) are always chaning
|
||||||
|
|
||||||
|
differ between platforms
|
||||||
|
evolve over time
|
||||||
|
|
||||||
|
e.g., menus
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
general look of webpages evolves over time
|
||||||
|
|
||||||
|
### 1.1 Naming and teminology
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
this is bad
|
||||||
|
you can ask users which categories they understand/know about
|
||||||
|
|
||||||
|
### 1.2 Data loss
|
||||||
|
|
||||||
|
|
||||||
|
standard to minimise loss
|
||||||
|
|
||||||
|
## 2 Error Prevention
|
||||||
|
|
||||||
|
### 2.1 Bad input
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
correct human errors
|
||||||
|
auto completion
|
||||||
|
|
||||||
|
### 2.2 helpful constraints
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 2.3 Suggestions and autocorrection
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
heavily abused by industry
|
||||||
|
- they can influence suggestions
|
||||||
|
|
||||||
|
### 2.4 Forgiving formatting
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- reduce errors
|
||||||
|
-
|
||||||
|
|
||||||
|
## 3 recognition over recall
|
||||||
|
|
||||||
|
### 3.1 avoid codes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.2 Recognition with previews or icons
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.3 use icons that promote recognition
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 4 Flexibility and efficiency
|
||||||
|
|
||||||
|
### 4.1 Choices
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
something with immediate effect can use switch
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
good defaults
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
4.2 shortcuts and advanced options
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
ambient information
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
proactivity
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 5 aesthetic and minimalistic design
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
signal to noise
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
31
content/notes/lecture-6-business-functions-and-use-cases.md
Normal file
31
content/notes/lecture-6-business-functions-and-use-cases.md
Normal file
@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 6 Business Functions and Use Cases
|
||||||
|
sr-due: 2022-05-04
|
||||||
|
sr-interval: 30
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
#review
|
||||||
|
https://blackboard.otago.ac.nz/bbcswebdav/pid-2884153-dt-content-rid-18204846_1/courses/INFO201_S1DNIE_2022/lecture_06_slides.pdf
|
||||||
|
|
||||||
|
----
|
||||||
|
# Lecture 06 - Business functions and use cases
|
||||||
|
[Approches to systems development](content/notes/approches-to-systems-development.md)
|
||||||
|
1. What are the two main approaches to systems development and how do they differ
|
||||||
|
|
||||||
|
[Business functions](content/notes/business-functions.md)
|
||||||
|
2. What are business functions
|
||||||
|
|
||||||
|
3. What is a use case
|
||||||
|
|
||||||
|
4. What is a use case diagram used for
|
||||||
|
|
||||||
|
[Use case diagrams](content/notes/use-case-diagrams.md)
|
||||||
|
|
||||||
|
|
||||||
|
- dependencies
|
||||||
|
- includes
|
||||||
|
- excludes
|
||||||
|
- requries
|
||||||
|
|
||||||
|
what is the difference between requries and indludes
|
||||||
20
content/notes/lecture-7-business-process-modellingbpm.md
Normal file
20
content/notes/lecture-7-business-process-modellingbpm.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 7 Business process modelling(BPM)
|
||||||
|
aliases: BPMN
|
||||||
|
sr-due: 2022-04-25
|
||||||
|
sr-interval: 24
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
#review
|
||||||
|
|
||||||
|
# 1 Lecture 07 Business process modelling
|
||||||
|
## 1 LO's
|
||||||
|
understand core onepts realted to business process mondelling
|
||||||
|
learn about commonly used business process modelling notations
|
||||||
|
understand the elemeents of a UML activity diagram
|
||||||
|
|
||||||
|
1. What is a business process
|
||||||
|
- [Business process](content/notes/business-process.md)
|
||||||
|
- [Business process model](content/notes/business-process-model.md)
|
||||||
|
- [Business Process Model and Notation](content/notes/business-process-model-and-notation.md)
|
||||||
|
- [UML](content/notes/uml.md)
|
||||||
49
content/notes/lecture-7-personas-and-scenarios.md
Normal file
49
content/notes/lecture-7-personas-and-scenarios.md
Normal file
@ -0,0 +1,49 @@
|
|||||||
|
---
|
||||||
|
title: Lecture 7 Personas and Scenarios
|
||||||
|
sr-due: 2022-04-21
|
||||||
|
sr-interval: 20
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
#review
|
||||||
|
|
||||||
|
---
|
||||||
|
# Lecture 7 Heuristic Evaluation
|
||||||
|
[Heuristic Evaluation](content/notes/heuristic-evaluation.md)
|
||||||
|
|
||||||
|
## 1 Review Questions
|
||||||
|
2. Briefly describe the high level process of a heuristic evaluation
|
||||||
|
|
||||||
|
3. What are the four phases of a heuristic evaluations
|
||||||
|
|
||||||
|
4. Breifly describe the process of an individual during a heuristic evaluation
|
||||||
|
|
||||||
|
5. Name 3 of nielsens ten heuristics (VMUCERFA HH)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user