mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
update
This commit is contained in:
Jet Hughes
parent
f4269a4849
commit
eec8badee0
@ -12,3 +12,20 @@ title: "Jet Hughes"
|
|||||||
# 2 Other
|
# 2 Other
|
||||||
|
|
||||||
- [templates](notes/templates.md)
|
- [templates](notes/templates.md)
|
||||||
|
|
||||||
|
# 3 Projects
|
||||||
|
|
||||||
|
- [bug-tracker](notes/bug-tracker.md)
|
||||||
|
-
|
||||||
|
|
||||||
|
# 5 Independent Learning
|
||||||
|
|
||||||
|
- [networks](notes/networks.md)
|
||||||
|
- random
|
||||||
|
- [propogation-of-ideas](notes/propogation-of-ideas.md)
|
||||||
|
- [model-view-controller-pattern](notes/model-view-controller-pattern.md)
|
||||||
|
- [dotnet](notes/dotnet.md)
|
||||||
|
|
||||||
|
# 6 Books
|
||||||
|
|
||||||
|
- The book of illusions
|
||||||
|
|||||||
@ -1,3 +1,5 @@
|
|||||||
|
#cheatsheet
|
||||||
|
|
||||||
**Busy waiting
|
**Busy waiting
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|||||||
@ -11,7 +11,7 @@ Synchronicity - The Police - spotify:album:28eOriEfl7IGbQDNvWIWXK
|
|||||||
- [ ] info 201 lab 04
|
- [ ] info 201 lab 04
|
||||||
- [ ] info 201 lab 06
|
- [ ] info 201 lab 06
|
||||||
- [ ] change testing of contrast and brightness andie
|
- [ ] change testing of contrast and brightness andie
|
||||||
- [ ] fix 203 notes for disability services
|
- [x] upload 203 notes for disability services
|
||||||
- [ ] work through 202 labs
|
- [ ] work through 202 labs
|
||||||
- [ ] 04
|
- [ ] 04
|
||||||
- [ ] 05
|
- [ ] 05
|
||||||
@ -21,8 +21,8 @@ Synchronicity - The Police - spotify:album:28eOriEfl7IGbQDNvWIWXK
|
|||||||
|
|
||||||
- [x] 10:00 Info203 Lecture
|
- [x] 10:00 Info203 Lecture
|
||||||
- [x] 11:00 Cosc201 Lecture
|
- [x] 11:00 Cosc201 Lecture
|
||||||
- [ ] 13:00 Info201 Lecture
|
- [x] 13:00 Info201 Lecture
|
||||||
- [ ] 14:00 Cosc202 Lab
|
- [x] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
## Assignments
|
## Assignments
|
||||||
- Mobile app
|
- Mobile app
|
||||||
|
|||||||
47
content/daily_notes/2022-04-13.md
Normal file
47
content/daily_notes/2022-04-13.md
Normal file
@ -0,0 +1,47 @@
|
|||||||
|
[[notes/daily-notes]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-13
|
||||||
|
|
||||||
|
Listen Without Prejudice Vol. 1 - George Michael - spotify:album:4lGS8HxU3NYaQxfU0wx2r1
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] remote desktop for IT work
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] change testing of contrast and brightness andie
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
49
content/daily_notes/2022-04-14.md
Normal file
49
content/daily_notes/2022-04-14.md
Normal file
@ -0,0 +1,49 @@
|
|||||||
|
[[notes/daily-notes]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-14
|
||||||
|
|
||||||
|
Happy Sad - Tim Buckley - spotify:album:20CYfxjKvqXkCXBhAgOE39
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] remote desktop for IT work
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] change testing of contrast and brightness andie
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
49
content/daily_notes/2022-04-15.md
Normal file
49
content/daily_notes/2022-04-15.md
Normal file
@ -0,0 +1,49 @@
|
|||||||
|
[[notes/daily-notes]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-15
|
||||||
|
|
||||||
|
Smile - Brian Wilson - spotify:album:4Uc6YCjpfyjj02rZfg2EUv
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] remote desktop for IT work
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] change testing of contrast and brightness andie
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
50
content/daily_notes/2022-04-16.md
Normal file
50
content/daily_notes/2022-04-16.md
Normal file
@ -0,0 +1,50 @@
|
|||||||
|
[[notes/daily-notes]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-16
|
||||||
|
|
||||||
|
No Sleep 'Til Hammersmith (Live) - Mot<6F>rhead - spotify:album:6DJEPyUk9Vqvq5Rh8HD7D8
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] remote desktop for IT work
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] change testing of contrast and brightness andie
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
50
content/daily_notes/2022-04-18.md
Normal file
50
content/daily_notes/2022-04-18.md
Normal file
@ -0,0 +1,50 @@
|
|||||||
|
[[notes/daily-notes]]
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-18
|
||||||
|
|
||||||
|
Tonight's The Night - Neil Young - spotify:album:5FTx6W84UUU14n29QV4saY
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] remote desktop for IT work
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] change testing of contrast and brightness andie
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
- [ ] 14:00 Info203 Tutorial
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 lab
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- bug-tracker
|
||||||
|
-
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
42
content/daily_notes/2022-04-19.md
Normal file
42
content/daily_notes/2022-04-19.md
Normal file
@ -0,0 +1,42 @@
|
|||||||
|
[2022-04-18](daily_notes/2022-04-18) << [[notes/daily-notes]] >> [2022-04-20](daily_notes/2022-04-20)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-19
|
||||||
|
|
||||||
|
Giant Steps - The Boo Radleys - spotify:album:6347aGYak5Dsi0hwPMMpmj
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
42
content/daily_notes/2022-04-20.md
Normal file
42
content/daily_notes/2022-04-20.md
Normal file
@ -0,0 +1,42 @@
|
|||||||
|
[2022-04-19](daily_notes/2022-04-19) << [[notes/daily-notes]] >> [2022-04-21](daily_notes/2022-04-21)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-20
|
||||||
|
|
||||||
|
Giant Steps - The Boo Radleys - spotify:album:6347aGYak5Dsi0hwPMMpmj
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] info 201 lab 04
|
||||||
|
- [ ] info 201 lab 06
|
||||||
|
- [ ] work through 202 labs
|
||||||
|
- [ ] 04
|
||||||
|
- [ ] 05
|
||||||
|
- [ ] 06
|
||||||
|
- [ ] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
37
content/daily_notes/2022-04-21.md
Normal file
37
content/daily_notes/2022-04-21.md
Normal file
@ -0,0 +1,37 @@
|
|||||||
|
[2022-04-22](daily_notes/2022-04-22) << [daily-notes](notes/daily-notes.md) >> [2022-04-24](daily_notes/2022-04-24)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 23-04-22
|
||||||
|
|
||||||
|
John Barleycorn Must Die - Traffic - spotify:album:2TjodugH6rA5ZHPsWVErmw
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
33
content/daily_notes/2022-04-23.md
Normal file
33
content/daily_notes/2022-04-23.md
Normal file
@ -0,0 +1,33 @@
|
|||||||
|
[2022-04-22](daily_notes/2022-04-22) << [daily-notes](notes/daily-notes.md) >> [2022-04-24](daily_notes/2022-04-24)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 2022-04-23
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
37
content/daily_notes/2022-04-24.md
Normal file
37
content/daily_notes/2022-04-24.md
Normal file
@ -0,0 +1,37 @@
|
|||||||
|
[2022-04-22](daily_notes/2022-04-22) << [daily-notes](notes/daily-notes.md) >> [2022-04-24](daily_notes/2022-04-25)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 23-04-22
|
||||||
|
|
||||||
|
John Barleycorn Must Die - Traffic - spotify:album:2TjodugH6rA5ZHPsWVErmw
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Timetable
|
||||||
|
|
||||||
|
![[Pasted image 20220311102444.png]]
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
36
content/daily_notes/2022-04-25.md
Normal file
36
content/daily_notes/2022-04-25.md
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
[2022-04-25](daily_notes/2022-04-25) << [daily-notes](notes/daily-notes.md) >> [2022-04-27](daily_notes/2022-04-27)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 26-04-22
|
||||||
|
|
||||||
|
Selected Ambient Works 85-92 - Aphex Twin - spotify:album:7aNclGRxTysfh6z0d8671k
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [ ] 10:00 Info203 Lecture
|
||||||
|
- [ ] 11:00 Cosc201 Lecture
|
||||||
|
- [ ] 13:00 Info201 Lecture
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
39
content/daily_notes/2022-04-26.md
Normal file
39
content/daily_notes/2022-04-26.md
Normal file
@ -0,0 +1,39 @@
|
|||||||
|
[2022-04-24](daily_notes/2022-04-24) << [daily-notes](notes/daily-notes.md) >> [2022-04-27](daily_notes/2022-04-27)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 26-04-22
|
||||||
|
|
||||||
|
Selected Ambient Works 85-92 - Aphex Twin - spotify:album:7aNclGRxTysfh6z0d8671k
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- book (or not) flights for holiday
|
||||||
|
- watch 203 videos
|
||||||
|
- [Plan](private/Plan.md)
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [x] 11:00 Cosc201 Lecture
|
||||||
|
- [x] 13:00 Info201 Lecture
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
- CI notes site
|
||||||
|
- my own password manager
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
36
content/daily_notes/2022-04-27.md
Normal file
36
content/daily_notes/2022-04-27.md
Normal file
@ -0,0 +1,36 @@
|
|||||||
|
[2022-04-26](daily_notes/2022-04-26) << [daily-notes](notes/daily-notes.md) >> [2022-04-28](daily_notes/2022-04-28)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 27-04-22
|
||||||
|
|
||||||
|
Cee-Lo Green... Is The Soul Machine - Cee Lo Green - spotify:album:0wdleLMeNmGUHChsmx9svt
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
- [ ] use 1001 albums api
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [x] 10:00 Info203 Lecture
|
||||||
|
- [x] 14:00 Info203 Tutorial
|
||||||
|
- [x] 16:00 Cosc201 Tutorial
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
* c201 ass
|
||||||
|
* i201 ass
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
35
content/daily_notes/2022-04-28.md
Normal file
35
content/daily_notes/2022-04-28.md
Normal file
@ -0,0 +1,35 @@
|
|||||||
|
[2022-04-27](daily_notes/2022-04-27) << [daily-notes](notes/daily-notes.md) >> [2022-04-29](daily_notes/2022-04-29)
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
# 28-04-22
|
||||||
|
|
||||||
|
Dr. Octagonecologyst - Dr. Octagon - spotify:album:23DJ3KNE5JXi61G31T2Kni
|
||||||
|
|
||||||
|
## Todos
|
||||||
|
- [ ] 14:00 Cosc202 Lab
|
||||||
|
- [ ] use 1001 albums api
|
||||||
|
|
||||||
|
## Lecture/Labs
|
||||||
|
|
||||||
|
- [ ] 11:00 Cosc202 Lecture
|
||||||
|
- [ ] 12:00 Cosc201 Lab
|
||||||
|
- [ ] 16:00 Info201 Lecture
|
||||||
|
|
||||||
|
## Assignments
|
||||||
|
- Mobile app
|
||||||
|
- Brainstorming
|
||||||
|
|
||||||
|
## Projects
|
||||||
|
- python ai weekly review
|
||||||
|
|
||||||
|
## Links
|
||||||
|
|
||||||
|
### cosc 202
|
||||||
|
|
||||||
|
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||||
|
|
||||||
|
### info 201
|
||||||
|
|
||||||
|
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
|
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||||
29
content/notes/03-agile-methodologies.md
Normal file
29
content/notes/03-agile-methodologies.md
Normal file
@ -0,0 +1,29 @@
|
|||||||
|
---
|
||||||
|
title: "03-agile-methodologies"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-05-17
|
||||||
|
sr-interval: 24
|
||||||
|
sr-ease: 290
|
||||||
|
---
|
||||||
|
|
||||||
|
> 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](notes/scrum.md)
|
||||||
|
Development is split into many short (~30 day) "sprints" of intense focus where the entire team is involved
|
||||||
|
|
||||||
|
# 2 [Extreme Programming](notes/extreme-programming.md) (XP)
|
||||||
|
taking current industry practices to the extreme
|
||||||
|
|
||||||
|
# 3 [Unified Processes](notes/unified-processes.md) (UP)
|
||||||
|
Interative and incremental architecture-centric which has four main phases
|
||||||
|
- inception
|
||||||
|
- elaboration
|
||||||
|
- construction
|
||||||
|
- transition
|
||||||
20
content/notes/04-evaluation-methods-birth-of-hci.md
Normal file
20
content/notes/04-evaluation-methods-birth-of-hci.md
Normal file
@ -0,0 +1,20 @@
|
|||||||
|
---
|
||||||
|
title: "04-evaluation-methods-birth-of-hci"
|
||||||
|
sr-due: 2022-05-22
|
||||||
|
sr-interval: 40
|
||||||
|
sr-ease: 230
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
- lecture
|
||||||
|
---
|
||||||
|
|
||||||
|
- [evaluating-designs](notes/evaluating-designs.md)
|
||||||
|
- [birth-of-hci](notes/birth-of-hci.md)
|
||||||
|
|
||||||
|
Possible exam questions
|
||||||
|
- Define User Experience!
|
||||||
|
- Difference User Experience - Usability
|
||||||
|
- Describe applications where the subject’s satisfaction is of less importance than effectiveness and efficiency
|
||||||
|
- Compare the advantages and disadvantages of a laboratory based and a field based evaluation of a user interface?
|
||||||
|
- Describe the different characteristics of quantitative and qualitative measurements in HCI!
|
||||||
@ -3,9 +3,9 @@ title: "04-requirements"
|
|||||||
tags:
|
tags:
|
||||||
- info201
|
- info201
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-13
|
sr-due: 2022-05-29
|
||||||
sr-interval: 2
|
sr-interval: 32
|
||||||
sr-ease: 230
|
sr-ease: 250
|
||||||
---
|
---
|
||||||
|
|
||||||
[requirements](notes/requirements.md)
|
[requirements](notes/requirements.md)
|
||||||
|
|||||||
@ -1,36 +1,15 @@
|
|||||||
---
|
---
|
||||||
title: "07-mergesort-1"
|
title: "07-mergesort-1"
|
||||||
sr-due: 2022-04-26
|
sr-due: 2022-06-22
|
||||||
sr-interval: 23
|
sr-interval: 57
|
||||||
sr-ease: 250
|
sr-ease: 250
|
||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- lecture
|
- lecture
|
||||||
---
|
---
|
||||||
|
|
||||||
[mergeosrt](notes/mergeosrt.md)
|
[mergesort](notes/mergesort.md)
|
||||||
|
|
||||||
#unfinished
|
[quicksort](notes/quicksort.md)
|
||||||
|
|
||||||
# 1 Divide and conquer
|
[divide-and-conquer](notes/divide-and-conquer.md)
|
||||||
|
|
||||||
1. pre ⇒ break apartinto two or more smaller problems whose size add up to at most n
|
|
||||||
2. Rec ⇒ solve those problems recursively
|
|
||||||
3. post ⇒ combine solutions into a solution of the original problem
|
|
||||||
|
|
||||||
## 1.1 quicksort
|
|
||||||
|
|
||||||
pre ⇒ select pivot and split the array
|
|
||||||
|
|
||||||
rec ⇒ apply quicksort to the partitions
|
|
||||||
|
|
||||||
post ⇒ not much
|
|
||||||
|
|
||||||
designeds when sorting inplace was important
|
|
||||||
|
|
||||||
works best of primitive types as they can be stored in the fastest memory location
|
|
||||||
|
|
||||||
- memory access can be localised and the comparisions are direct
|
|
||||||
- those advantages are limited when sorting objects of reference type
|
|
||||||
- i that case each element of the array is just a reference to where the object really is
|
|
||||||
- so there are no local access advantages
|
|
||||||
|
|||||||
@ -1,8 +1,11 @@
|
|||||||
---
|
---
|
||||||
title: "08-business-patterns"
|
title: "08-business-patterns"
|
||||||
|
sr-due: 2022-05-19
|
||||||
|
sr-interval: 37
|
||||||
|
sr-ease: 270
|
||||||
tags:
|
tags:
|
||||||
- info201
|
- info201
|
||||||
- lecture
|
- lecture
|
||||||
---
|
---
|
||||||
|
|
||||||
[[notes/entity-relationship-diagrams]]
|
[entity-relationship-diagrams](notes/entity-relationship-diagrams.md)
|
||||||
@ -8,4 +8,4 @@ tags:
|
|||||||
- lecture
|
- lecture
|
||||||
---
|
---
|
||||||
|
|
||||||
[mergeosrt](notes/mergeosrt.md)
|
[mergesort](notes/mergesort.md)
|
||||||
|
|||||||
@ -3,6 +3,13 @@ title: "09-data-modelling-and-normalisation"
|
|||||||
tags:
|
tags:
|
||||||
- info201
|
- info201
|
||||||
- lecture
|
- lecture
|
||||||
|
sr-due: 2022-04-30
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
---
|
---
|
||||||
|
|
||||||
|
- [redundancy-and-anomalies](notes/redundancy-and-anomalies.md)
|
||||||
|
- [dependencies](notes/dependencies.md)
|
||||||
|
- [normalisation](notes/normalisation.md)
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@ -3,6 +3,9 @@ title: "09-documentation"
|
|||||||
tags:
|
tags:
|
||||||
- cosc202
|
- cosc202
|
||||||
- lecture
|
- lecture
|
||||||
|
sr-due: 2022-05-21
|
||||||
|
sr-interval: 28
|
||||||
|
sr-ease: 290
|
||||||
---
|
---
|
||||||
|
|
||||||
[[notes/documentation]]
|
[documentation](notes/documentation.md)
|
||||||
@ -3,6 +3,9 @@ title: "09-paper-prototypes-wiz-of-oz-video-prototypes"
|
|||||||
tags:
|
tags:
|
||||||
- info203
|
- info203
|
||||||
- lecture
|
- lecture
|
||||||
|
sr-due: 2022-05-23
|
||||||
|
sr-interval: 26
|
||||||
|
sr-ease: 270
|
||||||
---
|
---
|
||||||
|
|
||||||
- [wizard-of-oz](notes/wizard-of-oz.md)
|
- [wizard-of-oz](notes/wizard-of-oz.md)
|
||||||
|
|||||||
@ -1,8 +1,8 @@
|
|||||||
---
|
---
|
||||||
title: "10-heaps-and-heapsort"
|
title: "10-heaps-and-heapsort"
|
||||||
sr-due: 2022-04-18
|
sr-due: 2022-06-04
|
||||||
sr-interval: 9
|
sr-interval: 42
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- lecture
|
- lecture
|
||||||
@ -11,7 +11,6 @@ tags:
|
|||||||
[heaps-and-heapsort](notes/heaps-and-heapsort.md)
|
[heaps-and-heapsort](notes/heaps-and-heapsort.md)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## 0.1 Overview
|
## 0.1 Overview
|
||||||
[[notes/heap]]
|
[[notes/heap]]
|
||||||
|
|
||||||
|
|||||||
145
content/notes/11-class-diagrams.md
Normal file
145
content/notes/11-class-diagrams.md
Normal file
@ -0,0 +1,145 @@
|
|||||||
|
---
|
||||||
|
title: "11-class-diagrams"
|
||||||
|
aliases: Class Diagrams
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-05-05
|
||||||
|
sr-interval: 20
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
[Class Diagrams](notes/11-class-diagrams.md)
|
||||||
|
|
||||||
|
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
|
||||||
@ -1,14 +1,14 @@
|
|||||||
---
|
---
|
||||||
title: "11-continuous-integration-2"
|
title: "11-continuous-integration-2"
|
||||||
sr-due: 2022-04-19
|
sr-due: 2022-06-06
|
||||||
sr-interval: 10
|
sr-interval: 44
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
tags:
|
tags:
|
||||||
- cosc202
|
- cosc202
|
||||||
- lecture
|
- lecture
|
||||||
---
|
---
|
||||||
|
|
||||||
1. Apprecitae that GitLab is a complex software
|
1. Appreciate that GitLab is a complex software
|
||||||
2. Understand where CI jobs scripts get run
|
2. Understand where CI jobs scripts get run
|
||||||
3. explain why repository servers can host websites
|
3. explain why repository servers can host websites
|
||||||
4. Understand how gitblab dternmimines awhen a CI script failed
|
4. Understand how gitblab dternmimines awhen a CI script failed
|
||||||
|
|||||||
@ -3,49 +3,12 @@ title: "11-design-heuristics-2"
|
|||||||
tags:
|
tags:
|
||||||
- info203
|
- info203
|
||||||
- lecture
|
- lecture
|
||||||
|
sr-due: 2022-05-01
|
||||||
|
sr-interval: 16
|
||||||
|
sr-ease: 280
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1 Show system status
|
- [Show System Status](notes/show-system-status.md)
|
||||||
- show system stats
|
- [Familiar Metaphors And Language](notes/familiar-metaphors-and-language.md)
|
||||||
|
- [User Freedom And Control](notes/user-freedom-and-control.md)
|
||||||
- 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., 
|
|
||||||
|
|
||||||
|
|||||||
@ -3,13 +3,13 @@ title: "11-sets-maps-trees"
|
|||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-12
|
sr-due: 2022-05-26
|
||||||
sr-interval: 3
|
sr-interval: 33
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
---
|
---
|
||||||
|
|
||||||
A [set](notes/set.md) is a collection of elements with no repetition allowed
|
A [set](notes/set.md) is :: a collection of elements with no repetition allowed <!--SR:!2022-04-15,3,270-->
|
||||||
|
|
||||||
A [hash-map](notes/hash-map.md) is a set of key value pairs
|
A [hash-map](notes/hash-map.md) is :: a set of key value pairs <!--SR:!2022-04-15,3,270-->
|
||||||
|
|
||||||
A [tree](notes/tree.md) is a general concept of a way of organising data.
|
A [tree](notes/tree.md) is :: a general concept of a way of organising data. <!--SR:!2022-04-15,3,270-->
|
||||||
|
|||||||
@ -1,9 +0,0 @@
|
|||||||
---
|
|
||||||
title: "11-trees-and-ordered-sets"
|
|
||||||
tags:
|
|
||||||
- cosc201
|
|
||||||
- lecture
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -3,9 +3,9 @@ title: "12-automation"
|
|||||||
tags:
|
tags:
|
||||||
- cosc202
|
- cosc202
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-20
|
sr-due: 2022-05-30
|
||||||
sr-interval: 9
|
sr-interval: 37
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
---
|
---
|
||||||
links: [cosc-202-lectures](notes/cosc-202-lectures.md), [slides](https://cosc202.cspages.otago.ac.nz/lectures/L12-automation.pdf)
|
links: [cosc-202-lectures](notes/cosc-202-lectures.md), [slides](https://cosc202.cspages.otago.ac.nz/lectures/L12-automation.pdf)
|
||||||
|
|
||||||
|
|||||||
@ -3,9 +3,9 @@ title: "12-binary-search-tree-operations"
|
|||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-12
|
sr-due: 2022-05-27
|
||||||
sr-interval: 3
|
sr-interval: 34
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
---
|
---
|
||||||
|
|
||||||
Recall [binary-search-tree](notes/binary-search-tree.md)
|
Recall [binary-search-tree](notes/binary-search-tree.md)
|
||||||
|
|||||||
@ -3,118 +3,13 @@ title: "12-design-heuristics-3"
|
|||||||
tags:
|
tags:
|
||||||
- info203
|
- info203
|
||||||
- lecture
|
- lecture
|
||||||
|
sr-due: 2022-05-20
|
||||||
|
sr-interval: 27
|
||||||
|
sr-ease: 290
|
||||||
---
|
---
|
||||||
|
|
||||||
# 1 Consistency and standards
|
- [Consistency And Standards](notes/consistency-and-standards.md)
|
||||||
|
- [Error Prevention](notes/error-prevention.md)
|
||||||
|
- [Recognition Over Recall](notes/recognition-over-recall.md)
|
||||||
|
- [flexibility-and-efficiency](notes/flexibility-and-efficiency.md)
|
||||||
good and bad
|
- [Aesthetic and Minimalist Design](notes/aesthetic-and-minimalist-design.md)
|
||||||
- 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
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@ -1,19 +1,36 @@
|
|||||||
---
|
---
|
||||||
title: "12-modelling-behaviour"
|
title: "12-modelling-behaviour"
|
||||||
tags:
|
tags:
|
||||||
- cosc201
|
- info201
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-13
|
sr-due: 2022-05-28
|
||||||
sr-interval: 2
|
sr-interval: 31
|
||||||
sr-ease: 230
|
sr-ease: 250
|
||||||
---
|
---
|
||||||
[slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2892846-dt-content-rid-18407618_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_12_slides.pdf)
|
[slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2892846-dt-content-rid-18407618_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_12_slides.pdf)
|
||||||
|
|
||||||
|
[modelling-behaviour](notes/modelling-behaviour.md)
|
||||||
|
|
||||||
- method signatures
|
- method signatures
|
||||||
- inheritance of behaviour
|
- inheritance of behaviour
|
||||||
- lower level sequencing and flow of control
|
- lower level sequencing and flow of control
|
||||||
- compartmentalisation into "subsystems"
|
- compartmentalisation into "subsystems"
|
||||||
|
|
||||||
|
1. Compare and contrast the two typical approaches to inheriting behaviour in OO systems.
|
||||||
|
2. What does it mean to “program to an interface” and why is this important?
|
||||||
|
3. Compare and contrast “rich” versus “anaemic” domain models with regards to behaviour.
|
||||||
|
4. Give an example of a “processor” in the context of OO system design and explain why these are useful.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# Garbage Notes
|
||||||
# 1 Example of Linked UML (not realistic)
|
# 1 Example of Linked UML (not realistic)
|
||||||
|
|
||||||
|
|
||||||
@ -182,10 +199,3 @@ Anything coded to work with Collection will accept *any* Java collection type. (
|
|||||||
- Domain models can be “rich” or “anaemic”.
|
- Domain models can be “rich” or “anaemic”.
|
||||||
- anaemic more common
|
- anaemic more common
|
||||||
- use “processors” to encapsulate “plumbing” code
|
- use “processors” to encapsulate “plumbing” code
|
||||||
|
|
||||||
# 5 Revision questions
|
|
||||||
|
|
||||||
1. Compare and contrast the two typical approaches to inheriting behaviour in OO systems.
|
|
||||||
2. What does it mean to “program to an interface” and why is this important?
|
|
||||||
3. Compare and contrast “rich” versus “anaemic” domain models with regards to behaviour.
|
|
||||||
4. Give an example of a “processor” in the context of OO system design and explain why these are useful.
|
|
||||||
157
content/notes/13-UML-sequence-diagrams.md
Normal file
157
content/notes/13-UML-sequence-diagrams.md
Normal file
@ -0,0 +1,157 @@
|
|||||||
|
---
|
||||||
|
title: "13-UML-sequence-diagrams"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-05-17
|
||||||
|
sr-interval: 24
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
|
||||||
|
sequence diagrams document a *sequence* of particpant interactions required to carry out a use case
|
||||||
|
- actor <-> object
|
||||||
|
- actors are outside the system
|
||||||
|
- objects are otside the system
|
||||||
|
- via a method call
|
||||||
|
- might get a result
|
||||||
|
- object <-> object
|
||||||
|
- lifetime of interactions and objects
|
||||||
|
- when they are created updated destroyed
|
||||||
|
- time is a key aspect
|
||||||
|
- [use-case-diagrams](notes/use-case-diagrams.md) dont have order
|
||||||
|
|
||||||
|
These diagrams are:
|
||||||
|
- detailed, low level, bottom up
|
||||||
|
- behavioural diagram
|
||||||
|
- not structural
|
||||||
|
- common in industry
|
||||||
|
- along with class diagrams
|
||||||
|
- need to be designed and read alongside corresponding class diagrams
|
||||||
|
- e.g., class diagrams with inform sequences diagrams and vice versa
|
||||||
|
- back and forth process
|
||||||
|
|
||||||
|
|
||||||
|
General overview example: [annotated example](https://i.imgur.com/1myG3rU.png)
|
||||||
|
- time goes from top to bottom
|
||||||
|
- however no specific time units
|
||||||
|
- can have actors as participants
|
||||||
|
- but not usually
|
||||||
|
- existence of actor usualy indicates a sequence is owned by a use case
|
||||||
|
- interactions are indicated by messages (solid arrows)
|
||||||
|
- e.g. actor to main menu
|
||||||
|
- actor clicks a button
|
||||||
|
- menu reacts
|
||||||
|
- etc
|
||||||
|
- messges are synchronous
|
||||||
|
- i.e., thing sending message must wait for result
|
||||||
|
- always method calls (or something that equated to a method call)
|
||||||
|
- participants are supposed to be instances of classes
|
||||||
|
- however we are usually more interested in the class name
|
||||||
|
- the dashed lines are lifelines
|
||||||
|
- can also be solid
|
||||||
|
- basically indicate the existenc of something
|
||||||
|
- e.g., Thingform gets destroyed, thingfinder and thing remain throughout
|
||||||
|
- the rectangles (activation bars) indicate when an a thing is doing somethin
|
||||||
|
- caused by incoming message
|
||||||
|
- ended by a return
|
||||||
|
- these can have sub activations
|
||||||
|
- i.e., nested
|
||||||
|
- these can be self-activations
|
||||||
|
- implcit: not all methods return something
|
||||||
|
|
||||||
|
relevant slide:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# Messages
|
||||||
|
[example](https://i.imgur.com/XedVmng.png)
|
||||||
|
- direction
|
||||||
|
- <- or ->
|
||||||
|
- easier to under stand if most messages are ->
|
||||||
|
- however this is not always possible
|
||||||
|
- same object used by multiple other objects
|
||||||
|
- an object calls back to the object that called it
|
||||||
|
- can be conditions (guards) [example](https://i.imgur.com/yWTcD1F.png)
|
||||||
|
- only sent if condition is true
|
||||||
|
- able to approximate if-then-else using multiple branches with exclusive conditions
|
||||||
|
- this is better done in activity diagram
|
||||||
|
- looping messages [example](https://i.imgur.com/tcFZ4bb.png)
|
||||||
|
- an asterisk idicated looping
|
||||||
|
- repeat message until condition id false
|
||||||
|
- send messge to each object in a collection
|
||||||
|
- may also be better in activity diagram
|
||||||
|
|
||||||
|
# Interaction frames (UML 2.x)
|
||||||
|
[example](https://i.imgur.com/V1Jhnd2.png)
|
||||||
|
- loop frame
|
||||||
|
- any kind of loop
|
||||||
|
- replaces * notation
|
||||||
|
- opt frame
|
||||||
|
- optional or conditional processing
|
||||||
|
- can replace [] notation
|
||||||
|
- alt frame
|
||||||
|
- if-then-else
|
||||||
|
- can replace [] notation
|
||||||
|
|
||||||
|
one thing that can cause complications is
|
||||||
|
- when something can a top level loop which is waiting for input.
|
||||||
|
- a cancel anytime option
|
||||||
|
|
||||||
|
|
||||||
|
# Basic process of creation
|
||||||
|
|
||||||
|
- identity participants of a use case (dont always need to use a use-case diagram)
|
||||||
|
- use use case to create first version of the activity diagram. as you implement the code update the class and activity diagrams
|
||||||
|
- identify messges required to carry out use case
|
||||||
|
- for each message
|
||||||
|
- it is always sent
|
||||||
|
- is it sent conditionally
|
||||||
|
- is it sent multiple times
|
||||||
|
- assemble messages in correct sequence and attach to relevant lifelines/activations
|
||||||
|
- add returns where necessary
|
||||||
|
|
||||||
|
# Case study ATM
|
||||||
|
|
||||||
|
bank is developing a new ATM system for their customers
|
||||||
|
|
||||||
|
scope and requirements
|
||||||
|
- each customer has one or mor accounts
|
||||||
|
- transaction types are
|
||||||
|
- view balance
|
||||||
|
- withdraw cash
|
||||||
|
- deposit funds
|
||||||
|
- the customer can cancel at any point before final confirmation
|
||||||
|
- customer authenticates by inserting bank card and entering four digit pin
|
||||||
|
|
||||||
|
process
|
||||||
|
- choose account
|
||||||
|
- choose amount
|
||||||
|
- check customer funds
|
||||||
|
- check amount in cash dipenser
|
||||||
|
- results
|
||||||
|
- withdraw amount
|
||||||
|
- dispense amount
|
||||||
|
- remind user
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
this diagam is probably too general for this case
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
note navigability of domain
|
||||||
|
|
||||||
|
sequence diagram
|
||||||
|
|
||||||
|
- [part 1](https://i.imgur.com/PJJBZav.png)
|
||||||
|
- [part 2](https://i.imgur.com/M3jRM8g.png)
|
||||||
|
- [part 3](https://i.imgur.com/PhCYWsy.png)
|
||||||
|
- [part 4](https://i.imgur.com/L0h4nb8.png)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
[full diagram](https://blackboard.otago.ac.nz/bbcswebdav/pid-2894257-dt-content-rid-18429333_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_13_atm-withdraw-sequence-full.pdf)
|
||||||
|
|
||||||
|
|
||||||
@ -4,9 +4,9 @@ aliases:
|
|||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-15
|
sr-due: 2022-05-18
|
||||||
sr-interval: 3
|
sr-interval: 25
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
---
|
---
|
||||||
|
|
||||||
# Traversals
|
# Traversals
|
||||||
|
|||||||
@ -4,9 +4,9 @@ aliases: code libraries, libraries, software library
|
|||||||
tags:
|
tags:
|
||||||
- cosc202
|
- cosc202
|
||||||
- lecture
|
- lecture
|
||||||
sr-due: 2022-04-14
|
sr-due: 2022-05-25
|
||||||
sr-interval: 3
|
sr-interval: 30
|
||||||
sr-ease: 250
|
sr-ease: 270
|
||||||
---
|
---
|
||||||
|
|
||||||
# what is a software library
|
# what is a software library
|
||||||
|
|||||||
86
content/notes/14-balancing-bsts.md
Normal file
86
content/notes/14-balancing-bsts.md
Normal file
@ -0,0 +1,86 @@
|
|||||||
|
---
|
||||||
|
title: "14-balancing-bsts"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- cosc201
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-04-29
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
the height of a [BST](notes/binary-search-tree.md) is the length of its longest chain. Most operations are $O(n)$ where n is the height of the tree. In an Ideal situation each layer of the tree is full. The height of the tree is logarithmic to the number of nodes.
|
||||||
|
|
||||||
|
When a tree is being used only occainsonally, we can afford to simply rebalance is periodically. However when it is in constant use we cannot afford this cost
|
||||||
|
|
||||||
|
# Rotations
|
||||||
|
|
||||||
|
|
||||||
|
sometimes two rotations are needed
|
||||||
|
|
||||||
|
## When to rotate and how to do them
|
||||||
|
|
||||||
|
basic idea is to modify the add and delete operations fo the BST to be somewhat self-balancing. This does not need to be perfect
|
||||||
|
|
||||||
|
We need a rule to decide when the tree is "balanced enough" and also strategies for fixing problems when the rule is violated.
|
||||||
|
|
||||||
|
We only need to fix the area local to the add or delete operations
|
||||||
|
|
||||||
|
# 1 - AVL tree
|
||||||
|
most basic and obvious.
|
||||||
|
|
||||||
|
each node contains some extra information: the difference between the height of its right and left subtee. balance is maintained by ensuring that at every node this always at most 1
|
||||||
|
|
||||||
|
What is the least possible number of nodes in AVL tree of height k?
|
||||||
|
|
||||||
|
in general
|
||||||
|
|
||||||
|
$A_k= 1 + A_{k-1} + A_{k-2}$
|
||||||
|
|
||||||
|
we need a root 1, on one side a amallest possible tree of height $A_{k-1}$ then the other side must have height at least to $k-2$ to satisfy the rule, so we need at least $A_{k-2}$ more nodes.
|
||||||
|
|
||||||
|
The size if exponential in its height, and therefore its height is logarithmic in the size.
|
||||||
|
|
||||||
|
the operations are the same, but for each one we need to check and fix any excess imbalance along a single path from the affected leaf node up to the root.
|
||||||
|
|
||||||
|
for insertions, at most three rotations are rquired, for deletions the worst case is $O(lg\ n)$
|
||||||
|
|
||||||
|
# 2 - Red Black trees
|
||||||
|
most used current one. Used in java treemap
|
||||||
|
|
||||||
|
each node is either red or black
|
||||||
|
|
||||||
|
the rules are:
|
||||||
|
- the root node is black (optional)
|
||||||
|
- all null nodes are _considered_ black (convention)
|
||||||
|
- A red node may not have a red child
|
||||||
|
- Every path from a node to a descendant null node contains the same number of black nodes
|
||||||
|
|
||||||
|
These guarantee that the longest path frm root to null (which could alternate red and black) is at most twice as long as the shortest path (which could be all black)
|
||||||
|
|
||||||
|
the tree is full up to half its height - growing at least as fast as $2^{h/2}$
|
||||||
|
|
||||||
|
the height is logarithmic in the size sinhce th tree must be complete to the depth of half the height
|
||||||
|
|
||||||
|
Operations that mnodify the tree require in the worst case $O(lg\ n)$ recolourings and (on average a constant number) and not more than three rotations
|
||||||
|
|
||||||
|
## Strategy
|
||||||
|
- do an insertio and color the node red.
|
||||||
|
- recolor and rotate nodes to fix violation
|
||||||
|
- there are four scenarios
|
||||||
|
-
|
||||||
|
|
||||||
|
# 3 - Treaps
|
||||||
|
Link betwen heaps and trees that uses randomisation
|
||||||
|
|
||||||
|
I we are added items to a bst in random order then an unbalanced situation would be possible but highly unlikely.
|
||||||
|
|
||||||
|
a treap (portmanteau of tree and heap) is designed to achieve this even in the elements are not added in random order
|
||||||
|
|
||||||
|
when we add an element, we give it a random priority. Then after doing normal BST insertion we perform a series of rotations to fix the heap-ordering issues
|
||||||
|
|
||||||
|
the effect is that the elements look as if they were inserted in decending order of priority. SInce the priorities were randomly chosen, that means that at any time we see a BST which "thinks" that is elements were added in random order
|
||||||
|
|
||||||
|
# 4 - B-trees
|
||||||
|
not actually a bst, but can be used for the same purpose
|
||||||
|
|
||||||
41
content/notes/14-direct-manipulation-and-mental-models.md
Normal file
41
content/notes/14-direct-manipulation-and-mental-models.md
Normal file
@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "14-direct-manipulation-and-mental-models"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-05-24
|
||||||
|
sr-interval: 31
|
||||||
|
sr-ease: 270
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
Command line vs UI
|
||||||
|
[table](https://i.imgur.com/DW8jnGz.png)
|
||||||
|
|
||||||
|
# Object action models
|
||||||
|
|
||||||
|
object action model: user selects an object then selects the action to perform on the objct
|
||||||
|
|
||||||
|
action object model: user first selects an action to be perdormed and then selects the objects on which this action will be performed
|
||||||
|
|
||||||
|
object action model maps to real life environment
|
||||||
|
|
||||||
|
the designer needs to create mapping from the real world unicers ofb objects and intentios to the intrefac world universe of metaphors and plans
|
||||||
|
|
||||||
|
# fits law
|
||||||
|
time to point to something depends on its size and distance:
|
||||||
|
$$
|
||||||
|
MT = C1 + C2\ log_2(2A/W)
|
||||||
|
$$ where C1 and C2 are contstants that depend on the device. A is the distance that users have to move and W is the target size.
|
||||||
|
|
||||||
|
- buttons and othe controls should be of reasonable size
|
||||||
|
- things done more often should a assigned a larger button
|
||||||
|
- or closer to the average position of the users cursor
|
||||||
|
- edges and coreners are easier to reach as the pointer is "caught" (infinite width)
|
||||||
|
- popup menus can usually be open faster than pull-down menus, since the user avoids movement
|
||||||
|
- pie menu items are typically selected faster and have a lower error rate than linear meny items as they scale with distance
|
||||||
|
|
||||||
|
|
||||||
|
# Combining inputs
|
||||||
|
often multiple ways of doing one thing
|
||||||
107
content/notes/15-containers.md
Normal file
107
content/notes/15-containers.md
Normal file
@ -0,0 +1,107 @@
|
|||||||
|
---
|
||||||
|
title: "15-containers"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- cosc202
|
||||||
|
- lecture
|
||||||
|
---
|
||||||
|
|
||||||
|
* Describe what software containers are
|
||||||
|
- Explain why containers are useful
|
||||||
|
- Outline the role of container registries
|
||||||
|
- Contrast different ways to interact with containers
|
||||||
|
- Understand security risks inherent in container use
|
||||||
|
|
||||||
|
|
||||||
|
# What are (software) containers?
|
||||||
|
|
||||||
|
- Containers encapsulate a computing environment
|
||||||
|
- Facilitates portable and reproducible use of software
|
||||||
|
- Can wrap up application code and data, and much of OS
|
||||||
|
- Containers are lightweight virtual machines
|
||||||
|
- You need to boot them up, as for any OS
|
||||||
|
- . . . but containers start up very quickly
|
||||||
|
|
||||||
|
# What containers do and don’t include
|
||||||
|
- Containers are generally Linux (virtual) machines
|
||||||
|
- Even when hosted on Windows, containers are usually Linux
|
||||||
|
- Microsoft Windows containers do exist though
|
||||||
|
- Containers include the OS user space
|
||||||
|
- e.g., distributions: Ubuntu, Debian, Arch. . .
|
||||||
|
- Containers do not include Linux kernel
|
||||||
|
- ... because all containers share one instance of the Linux kernel
|
||||||
|
- Containers can’t themselves include hardware device drivers
|
||||||
|
|
||||||
|
# Using containers
|
||||||
|
- We won’t explore how containers are hosted
|
||||||
|
- COSC349 explores how the lightweight virtualisation works
|
||||||
|
- We focus on using others’ containers
|
||||||
|
- Making containers usable involves:
|
||||||
|
- Management tools to control containers
|
||||||
|
- Means for interacting with the containerised software
|
||||||
|
- Somewhere from which to get their starter material. . .
|
||||||
|
|
||||||
|
# Container registries
|
||||||
|
- Containers’ start up from an image
|
||||||
|
- Think of images as a hard disk template
|
||||||
|
- Images efficiently overlay layers of files and folders
|
||||||
|
- Container registries store and share images: e.g.,
|
||||||
|
- Docker Hub is a popular container registry
|
||||||
|
- GitHub Container Registry (public; launched 2020)
|
||||||
|
- GitLab Container Registry (private)
|
||||||
|
- All major cloud providers provide registries
|
||||||
|
- You can run on-site, private registry too
|
||||||
|
|
||||||
|
# Example container interacting with files
|
||||||
|
- Let’s build the containers lab website
|
||||||
|
- Input: Markdown files
|
||||||
|
- Output: HTML website
|
||||||
|
- Can use this container within CI
|
||||||
|
- Active container can rebuild ‘live’:
|
||||||
|
- source files are watched for changes
|
||||||
|
- changes trigger rebuilding target files
|
||||||
|
- can reload browser to see changes rapidly
|
||||||
|
- Note: this example is an optional part of containers lab
|
||||||
|
- docker run −−rm −−mount \ type=bind , source=$ {PWD} , ta rge t=/ s r v / j e k y l l \ j e k y l l / j e k y l l : pages j e k y l l bu i ld
|
||||||
|
|
||||||
|
# Example container interacting over network
|
||||||
|
- Lesson builder can host an internal web server
|
||||||
|
- Point browser running on host computer to network URL
|
||||||
|
- Thus test built website, not just opening HTML files within it
|
||||||
|
- Container framework can share container’s network
|
||||||
|
- Typically expose key network ports of container on host
|
||||||
|
- Connections routed through to container
|
||||||
|
- Usually connections limited to interactions with the host OS
|
||||||
|
- . . . but containers can support internet-facing servers
|
||||||
|
- docker run −−rm − i t −−mount \ type=bind , source=$ {PWD} , ta rge t=/ s r v / j e k y l l \ −p 1 2 7. 0. 0. 1: 4 0 0 0: 4 0 0 0 \ j e k y l l / j e k y l l : 3 j e k y l l se rve
|
||||||
|
|
||||||
|
# Inter-container interactions
|
||||||
|
- Can build apps by composing multiple containers
|
||||||
|
- Either or both of file/network-based sharing commonly used
|
||||||
|
- Need to consider how to orchestrate containers
|
||||||
|
- Container orchestration is a COSC349 topic
|
||||||
|
- e.g., coordinating multi-container start up
|
||||||
|
- Kubernetes is the de facto container orchestrator
|
||||||
|
- Creates reliable, scalable services from containers
|
||||||
|
- Supported on all major cloud providers
|
||||||
|
|
||||||
|
# FYI: example multi-container application
|
||||||
|
- Example: say you need to chart time-series data
|
||||||
|
- InfluxDB is a dedicated time-series database
|
||||||
|
- Grafana is a dedicated web-based charting system
|
||||||
|
- Both are large, complex software products
|
||||||
|
- Containers allow using them together
|
||||||
|
- . . . without needing to figure out how to install them
|
||||||
|
- e.g., use Docker Compose tool; there are examples on GitHub
|
||||||
|
- Managing more than a few containers?
|
||||||
|
- Switch over to a container orchestration tool!
|
||||||
|
|
||||||
|
# Managing containerised applications
|
||||||
|
- Containers can (do!) suffer security vulnerabilities
|
||||||
|
- Thus, need management just like any other OS
|
||||||
|
- Many services can notify you about security flaws
|
||||||
|
- e.g., your dependencies may have been patched
|
||||||
|
- Can easily upgrade containers to include security fixes
|
||||||
|
- Upgrading live containers may break applications
|
||||||
|
- Common: whole container-based app is rebuilt & relaunched
|
||||||
|
- Container frameworks themselves also get hacked
|
||||||
142
content/notes/15-from-models-to-code-and-back.md
Normal file
142
content/notes/15-from-models-to-code-and-back.md
Normal file
@ -0,0 +1,142 @@
|
|||||||
|
---
|
||||||
|
title: "15-from-models-to-code-and-back"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-04-29
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
# Round trip engineering
|
||||||
|
|
||||||
|
going from models like UML to code, or ERD's to SQL
|
||||||
|
|
||||||
|
the idea is to try and keep the diagrams and code semantivally equivalent
|
||||||
|
|
||||||
|
foward - diagrams to code
|
||||||
|
reverse - code to diagrams
|
||||||
|
|
||||||
|
former is more common, but both do occur.
|
||||||
|
|
||||||
|
MDA (model driven architecture) is when code is comletely derived from the diagrams. However this is not that easy
|
||||||
|
|
||||||
|
foward engineering can be used to create skeleton code much more easily
|
||||||
|
|
||||||
|
fully representing code is UML is tricks as code is more difficult. It is hard to maintain consistency. This is easier with erds and sql than other types as these dont have to worry about behaviour. so the mappping is more simple. With uml and java is gets complex fast
|
||||||
|
|
||||||
|
this idea sounds good but in practice is not practical. THere is an qgument hat code is part of the design anyway. Code is a detailed form of a model.
|
||||||
|
|
||||||
|
# UML - java
|
||||||
|
|
||||||
|
similar to ERD to sql.
|
||||||
|
|
||||||
|
use case diagrams - more about system structure and features
|
||||||
|
**class diagram - java class
|
||||||
|
- doesn't have to be java
|
||||||
|
- could be any oop language
|
||||||
|
sequence, activity, state etc, may or may not be useful.
|
||||||
|
some code can be automatically generated.
|
||||||
|
|
||||||
|
custom methods cannot be generated automatically. things like getters and setters can be generated automatically.
|
||||||
|
|
||||||
|
## Steps
|
||||||
|
1. uml class -> java class (in its own file) (dont overdo it) (e.g., librarian)
|
||||||
|
1. use conceptual vs implementation level diagrams
|
||||||
|
2. assign data types to explicit class fields
|
||||||
|
3. add fields implied by associations
|
||||||
|
1. unidir ⇒ field in class at tail of -->
|
||||||
|
2. bidir ⇒ field in class at both ends <-->
|
||||||
|
3. multi = 1 ⇒ simple field (e.g., string)
|
||||||
|
4. multi > 1 ⇒ appropraite collection type (e.g., arraylist, hashmap etc)
|
||||||
|
4. field visibilty normally private (should match class diagram)
|
||||||
|
5. add constructors if needed
|
||||||
|
6. add public getter and setter methods (trivial, can be auto generated)
|
||||||
|
7. add remaining public or private methods (includilng implemented interfaces)
|
||||||
|
|
||||||
|
## aside on visibilty
|
||||||
|
|
||||||
|
|
||||||
|
## use case diagrams
|
||||||
|
|
||||||
|
each use case represents a feature. often items in a menu. sub cases can be sub menu items (extnd, include, require) (sometimes).
|
||||||
|
|
||||||
|
actors *can* correspond to domain classes.
|
||||||
|
|
||||||
|
one use case might require/use several classes. e.g., UI, processor, or data classes.
|
||||||
|
|
||||||
|
## other behavioural diagrams
|
||||||
|
|
||||||
|
**sequence:
|
||||||
|
- could be used for looping and branching
|
||||||
|
**activity:
|
||||||
|
- low level in particular
|
||||||
|
- can be used to generate some code
|
||||||
|
- would require discipline in diagram conventions
|
||||||
|
- by this point you are basically writing code in graphical form anyway
|
||||||
|
- might as well just write the code anyway
|
||||||
|
**state:
|
||||||
|
- most useful/likely to be use for code
|
||||||
|
- states machines are tedious
|
||||||
|
- [finite-state-machine](notes/finite-state-machine.md)
|
||||||
|
- often translate to some kind of lookup mechanism
|
||||||
|
- fairly easy to generate correspoding code
|
||||||
|
- boils down to some kind of index.
|
||||||
|
- however these are not used very often
|
||||||
|
- once this code is generated is hard to fix manually
|
||||||
|
- better to just change the diagam and regenerate the code
|
||||||
|
|
||||||
|
|
||||||
|
## subclasses
|
||||||
|
[employe diagram example](https://i.imgur.com/EAiVEkt.png)
|
||||||
|
[eployee code example](https://i.imgur.com/bighWWJ.png)
|
||||||
|
[code continued](https://i.imgur.com/Hxcho66.png)
|
||||||
|
|
||||||
|
- this example is contrived
|
||||||
|
|
||||||
|
- salariedemployee and wagedemployee inherit all public and protected methods of employee (including getters and setters, not including constructors)
|
||||||
|
- salariedEmpoyee and waged employee each have thier own computePay method
|
||||||
|
|
||||||
|
## Interfaces
|
||||||
|
[diagram](https://i.imgur.com/pN660p0.png)
|
||||||
|
[code](https://i.imgur.com/iDyoeSE.png)
|
||||||
|
|
||||||
|
- generally preffered to subclasses
|
||||||
|
- both salaried and waged employees must implement the computePay method
|
||||||
|
|
||||||
|
|
||||||
|
# Domain class model vs ERD structure
|
||||||
|
|
||||||
|
- erd are about long term storage. data persistence
|
||||||
|
- domain models are about application process, temporary storage.
|
||||||
|
- database and class structures dont need to be the same
|
||||||
|
- but you do need to be able to map between them
|
||||||
|
|
||||||
|
[domain class model vs erd structure](https://i.imgur.com/feN6a9W.png)
|
||||||
|
|
||||||
|
# Example: Library system
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
[library example uml diagram](https://i.imgur.com/u4CNXOb.png)
|
||||||
|
the five horizontal items could be meny items. there will be some kind of authorisation for senior librarians. we probably wouldn't make seniour and junior librarian as differnce classes. there is not really any benefit, doing this would be overkill. We should use a single librarian class with `type` field. this field can be used for authorisation. The apply fine use case is an optional sub task. It could be implemented in many ways: checkbox on return form, sub menu item, automatic. shelve item is a differnt, its more of a business process. only thing need in the code it the change the status of the item.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
[code part 1 Loan class](https://i.imgur.com/6VoV54C.png)
|
||||||
|
[code part 2 Loan class 2](https://i.imgur.com/Q8yptdE.png)
|
||||||
|
[code part 2 Loan class 3](https://i.imgur.com/4Xst3ys.png)
|
||||||
|
|
||||||
|
|
||||||
|
## Multiplicity
|
||||||
|
|
||||||
|
|
||||||
|
mih multiplicity of - ⇒ can create instances of Loan withou providing any associated LoanItem instances
|
||||||
|
|
||||||
|
min multiplicity 1 ⇒ must provide associated Loan instand when creating a LoanItem instance
|
||||||
|
1. create loan and loanItem then use LoanItem.setLoan()
|
||||||
|
2. use a custom LoanItem constructor to pass Loan object
|
||||||
|
|
||||||
|
[multiplicity code ](https://i.imgur.com/RKa9NBy.png)
|
||||||
|
|
||||||
|
unidirectional association are preffered as here we need to link things birdirectionally. this example is contrived, in real life it would not be done this way.
|
||||||
@ -0,0 +1,66 @@
|
|||||||
|
---
|
||||||
|
title: "15-mental-models-representation-matters-distributing-cognition"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-04-29
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
doors are simple. But they are still done wrong very often. Incorrect labelling can give the user a wrong mental model - widening the "gulf of execution". Signifiers like handles, can create a certain mental model making you pull it. These are easier to process than labels like push and pull. Our brains are lazy, we will choose the easiest option.
|
||||||
|
|
||||||
|
Door is very simple compared to computer interface. Yet they are still done wrong.
|
||||||
|
|
||||||
|
"A conceptial model mismatch (use has the wrong mental model)"
|
||||||
|
"Increases the Gulf of Execution (suporting the right model narrows it)"
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# Mental Models
|
||||||
|
- mental models are created by experience, metaphors, and analogical reasoning
|
||||||
|
- these models are developed further through interaction with the system
|
||||||
|
- designers (wrongly) often expect the users model to be the same as theirs
|
||||||
|
|
||||||
|
A mental model mistach leads to:
|
||||||
|
- slow performance
|
||||||
|
- errors
|
||||||
|
- frustration
|
||||||
|
|
||||||
|
[participant-observation](notes/participant-observation.md) appretiships (and other techniques such as [evaluating-designs](notes/evaluating-designs.md)) can uncover these mismatches.
|
||||||
|
|
||||||
|
## Slips vs mistakes
|
||||||
|
|
||||||
|
| Slip | Mistake |
|
||||||
|
|:-----------|:----------------------------------|
|
||||||
|
| accidental | on purpose (due to model mistach) |
|
||||||
|
|
||||||
|
|
||||||
|
## How to create good mental models
|
||||||
|
- [Direct Manipulation](notes/direct-manipulation-video.md)
|
||||||
|
- leveraging real world metphors
|
||||||
|
- this gives is a good idea of how each object works and how to control it
|
||||||
|
|
||||||
|
# Representation Matters and Distributing cognition
|
||||||
|
|
||||||
|
use representatio nthat does not require user to memoreise things.
|
||||||
|
|
||||||
|
"solving a problem simply means representing it so as to make the solution transparent" - Herbert Simon, The sciences of the Artificial
|
||||||
|
|
||||||
|
memory games make finding pairs hard by introducing rules. This often happens in computers interfaces needlessly difficult to use
|
||||||
|
|
||||||
|
depeding o nhow you represent a problem, you can make is easy or hard.
|
||||||
|
|
||||||
|
## Working memory
|
||||||
|
|
||||||
|
users have a working memory (2±2 limit). You shouldn't require users to remember anything that you could put on a screen.
|
||||||
|
|
||||||
|
If something takes a lot of time. You wil get distracted, and forget something.
|
||||||
|
|
||||||
|
|
||||||
|
## Naturalness principle
|
||||||
|
|
||||||
|
- experiemental cognition is raised when the properties of the representation match the properties of the thing being represented
|
||||||
|
-
|
||||||
@ -0,0 +1,114 @@
|
|||||||
|
---
|
||||||
|
title: "16-distributing-cognition-and-visual-design-typography"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
- lecture
|
||||||
|
sr-due: 2022-04-30
|
||||||
|
sr-interval: 3
|
||||||
|
sr-ease: 250
|
||||||
|
---
|
||||||
|
|
||||||
|
# Dist cognition
|
||||||
|
|
||||||
|
when interfaces help people disribute cognition it can
|
||||||
|
- exourage experimentsation
|
||||||
|
- scaffold learning and reuce errors through reduncdancy
|
||||||
|
- show (only) differences that matter
|
||||||
|
- convert slow calculation into fast perception
|
||||||
|
- support chunking, especially by experts
|
||||||
|
- increase effieciency
|
||||||
|
- facilitate collaboration
|
||||||
|
|
||||||
|
good representation shows only relevant information and enables:
|
||||||
|
- comparison
|
||||||
|
- exploration
|
||||||
|
- problem solving
|
||||||
|
|
||||||
|
deep vs shallow interface
|
||||||
|
|
||||||
|
# Visual design
|
||||||
|
|
||||||
|
combine text and graphics. how to represent?
|
||||||
|
|
||||||
|
- whitespace for grouping
|
||||||
|
- size contrasts for heiarchy
|
||||||
|
- variable scale and weight
|
||||||
|
- colors
|
||||||
|
|
||||||
|
|
||||||
|
three goals
|
||||||
|
- guide
|
||||||
|
- pace
|
||||||
|
- message
|
||||||
|
|
||||||
|
Three tools
|
||||||
|
- typography
|
||||||
|
- layout
|
||||||
|
- colour
|
||||||
|
|
||||||
|
# Typography
|
||||||
|
|
||||||
|
most common
|
||||||
|
- gill sans
|
||||||
|
- helvetica
|
||||||
|
- calibri
|
||||||
|
- arial
|
||||||
|
- times
|
||||||
|
|
||||||
|
three types
|
||||||
|
- serif
|
||||||
|
- sans serif
|
||||||
|
- handwritten
|
||||||
|
|
||||||
|
point size
|
||||||
|
|
||||||
|
|
||||||
|
leading depends on the font and the user setting but usually is 20% of the font
|
||||||
|
|
||||||
|
|
||||||
|
x height depends on the font.
|
||||||
|
- smaller x height adds "elegance"
|
||||||
|
- larger x height isbettwe to low res displays
|
||||||
|
|
||||||
|
|
||||||
|
ascenders and descender usually correlates with x height (small x-height > large ascenders and descenders)
|
||||||
|
|
||||||
|
|
||||||
|
weight: usually regullar and bold, also light semibold, ultrabold
|
||||||
|
|
||||||
|
|
||||||
|
sans serifs have less line width variation
|
||||||
|
|
||||||
|
|
||||||
|
some fonts provide small caps and lowercase numbers
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
- serif hypothesis
|
||||||
|
- serif fonts are easier to read
|
||||||
|
- preferable for long stretches of text because serifs provide anchors and guide the eye
|
||||||
|
- not proven
|
||||||
|
|
||||||
|
more info on the top than the botton
|
||||||
|
|
||||||
|
|
||||||
|
expectation plays an important role
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## which font to use?
|
||||||
|
- depends on context
|
||||||
|
- recoomentations
|
||||||
|
- slides and posters sans serif
|
||||||
|
- printed text serif
|
||||||
|
- web sans serif
|
||||||
|
- sans serif is better in lower resolutions
|
||||||
|
- combinations: (header sans, text serif)
|
||||||
|
- comic sans good for dyslexia
|
||||||
|
- logos should catch the eye
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -0,0 +1,8 @@
|
|||||||
|
---
|
||||||
|
title: "<% tp.file.cursor(1) %>Untitled"
|
||||||
|
aliases: <% tp.file.cursor(2) %>
|
||||||
|
tags:
|
||||||
|
- <% tp.file.cursor(3) %>
|
||||||
|
---
|
||||||
|
|
||||||
|
<% tp.file.cursor(4) %>
|
||||||
16
content/notes/aesthetic-and-minimalist-design.md
Normal file
16
content/notes/aesthetic-and-minimalist-design.md
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
---
|
||||||
|
title: "aesthetic-and-minimalist-design"
|
||||||
|
aliases: Aesthetic and Minimalist Design
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
signal to noise
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -1,18 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Untitled"
|
|
||||||
tags:
|
|
||||||
- cosc202
|
|
||||||
- assignment
|
|
||||||
---
|
|
||||||
|
|
||||||
Todo
|
|
||||||
|
|
||||||
- [ ] todo
|
|
||||||
|
|
||||||
Issues
|
|
||||||
|
|
||||||
- [ ] "no obs file" popup when opening new image
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
title: "ass-01-what-is-usability"
|
|
||||||
tags:
|
|
||||||
- info203
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
@ -1,7 +0,0 @@
|
|||||||
---
|
|
||||||
title: "ass-02-heuristic-evaluation"
|
|
||||||
tags:
|
|
||||||
- info203
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
@ -1,5 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: "asymptotic-notation"
|
title: "asymptotic-notation"
|
||||||
|
aliases: Big O, Big Theta, Algorithm Analysis
|
||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- analysis-of-algorithms
|
- analysis-of-algorithms
|
||||||
@ -10,7 +11,7 @@ Asymptotic notations are used in computer science to classify algorithms based h
|
|||||||
|
|
||||||
# big O notation
|
# big O notation
|
||||||
|
|
||||||
Big O defines a bound for the *upper* bound of the running time (or space) of a algorithm. However, it is possible that the actual running time is much less as it does not take into account special cases
|
Big O defines a bound for the *upper* bound of the running time (or space) of a algorithm. However, it is possible that the actual running time is much less as it does not take into account special cases ^fb2c3f
|
||||||
|
|
||||||
|
|
||||||
## 1 Formal definition
|
## 1 Formal definition
|
||||||
|
|||||||
@ -112,20 +112,4 @@ private void delete(Node n) {
|
|||||||
|
|
||||||
# Traversal
|
# Traversal
|
||||||
|
|
||||||
Visit each node in the tree once. So we need to visit n, all the nodes in L, and all the nodes in R. We can do this in three different ways
|
[tree-traversal](notes/tree-traversal.md)
|
||||||
|
|
||||||
preorder
|
|
||||||
- visit n
|
|
||||||
- traverse L
|
|
||||||
- traverse R
|
|
||||||
|
|
||||||
Inorder.
|
|
||||||
- traverse L
|
|
||||||
- visit n
|
|
||||||
- traverse R
|
|
||||||
Creating an BST from an array using the add operation then doing an inorder traversal is effectively a [quicksort](notes/quicksort)
|
|
||||||
|
|
||||||
postorder
|
|
||||||
- traverse L
|
|
||||||
- traverse R
|
|
||||||
- visit n
|
|
||||||
60
content/notes/bug-tracker.md
Normal file
60
content/notes/bug-tracker.md
Normal file
@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
title: "bug-tracker"
|
||||||
|
aliases: Bug Tracker
|
||||||
|
tags:
|
||||||
|
- project
|
||||||
|
---
|
||||||
|
|
||||||
|
link: https://youtu.be/oC483DTjRXU
|
||||||
|
|
||||||
|
potential employer needs to now i
|
||||||
|
|
||||||
|
need to target toward the dev/hiring manager. built wha the need/want to see. They should be able to instantly recognise if its what they want.
|
||||||
|
|
||||||
|
doesn't matter what tools you use. Try to build a project that uses the same stack as the company you are applying for.
|
||||||
|
|
||||||
|
Should built an app not 1 hour a day. Should do in large blocks. e.g., spend one saturday.
|
||||||
|
|
||||||
|
# The Project
|
||||||
|
|
||||||
|
Should:
|
||||||
|
- follow a design pattern
|
||||||
|
- e.g., for web apps: mvc: model view controller [MVC](notes/model-view-controller-pattern.md)
|
||||||
|
- clean professional UI
|
||||||
|
- mobile and desktop
|
||||||
|
- people are "visual buyers"
|
||||||
|
- use a bootstrap template
|
||||||
|
- database
|
||||||
|
- must perform all of CRUD operations
|
||||||
|
- security
|
||||||
|
- authorisation --> giving people permissions once they are logged in
|
||||||
|
- authentication --> logging in
|
||||||
|
- use a third party service like auth zero
|
||||||
|
- solve a business problem
|
||||||
|
- i.e., not a toy app (tic tac toe, etc)
|
||||||
|
|
||||||
|
|
||||||
|
## Bug/Issue Tracker
|
||||||
|
- e.g., JIRA, etc
|
||||||
|
- This can be easily adjusted to fit different industries.
|
||||||
|
|
||||||
|
# Building the Project
|
||||||
|
|
||||||
|
## 1 SRS
|
||||||
|
- compile the requirements
|
||||||
|
- divide these into sprints.
|
||||||
|
- these are the blocks discussed earlier
|
||||||
|
- blocks rabbit holes
|
||||||
|
|
||||||
|
## 2 Track your progress
|
||||||
|
- keeps details
|
||||||
|
- use the bug tracker you are building
|
||||||
|
- show this to the interviewer
|
||||||
|
|
||||||
|
# Common Mistakes
|
||||||
|
|
||||||
|
- Build using .NET, ASP.net mvc, C#. This is the most common.
|
||||||
|
- Dont start with a small program
|
||||||
|
- Show the project to people
|
||||||
|
- Show to recruiters
|
||||||
|
- Demo in interviews
|
||||||
@ -1,9 +0,0 @@
|
|||||||
---
|
|
||||||
title: "class-diagrams"
|
|
||||||
aliases: class diagrams, Class Diagrams
|
|
||||||
tags:
|
|
||||||
- info201
|
|
||||||
---
|
|
||||||
|
|
||||||
[slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2891358-dt-content-rid-18381804_1/xid-18381804_1)
|
|
||||||
|
|
||||||
33
content/notes/consistency-and-standards.md
Normal file
33
content/notes/consistency-and-standards.md
Normal file
@ -0,0 +1,33 @@
|
|||||||
|
---
|
||||||
|
title: "consistency-and-standards"
|
||||||
|
aliases: Consistency And Standards
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
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
|
||||||
@ -12,4 +12,5 @@ links: [[notes/cosc-201]]
|
|||||||
- [10-heaps-and-heapsort](notes/10-heaps-and-heapsort.md)
|
- [10-heaps-and-heapsort](notes/10-heaps-and-heapsort.md)
|
||||||
- [11-sets-maps-trees](notes/11-sets-maps-trees.md)
|
- [11-sets-maps-trees](notes/11-sets-maps-trees.md)
|
||||||
- [12-binary-search-tree-operations](notes/12-binary-search-tree-operations.md)
|
- [12-binary-search-tree-operations](notes/12-binary-search-tree-operations.md)
|
||||||
-
|
- [13-bst-traversals-and-balance](notes/13-bst-traversals-and-balance.md)
|
||||||
|
- [14-balancing-bsts](notes/14-balancing-bsts.md)
|
||||||
@ -15,3 +15,5 @@ links: [[notes/cosc-201]]
|
|||||||
- [[notes/heapsort]]
|
- [[notes/heapsort]]
|
||||||
- [[notes/mergesort]]
|
- [[notes/mergesort]]
|
||||||
- [[notes/quicksort]]
|
- [[notes/quicksort]]
|
||||||
|
- [divide-and-conquer](notes/divide-and-conquer.md)
|
||||||
|
- [unite-and-conquer](notes/unite-and-conquer.md)
|
||||||
@ -11,7 +11,7 @@ links: [_index](_index.md)
|
|||||||
- [cosc-201-outline](notes/cosc-201-outline.md)
|
- [cosc-201-outline](notes/cosc-201-outline.md)
|
||||||
- [cosc-201-lectures](notes/cosc-201-lectures.md)
|
- [cosc-201-lectures](notes/cosc-201-lectures.md)
|
||||||
|
|
||||||
## 0.1 Assignments
|
# 0.1 Assignments
|
||||||
|
|
||||||
- [[notes/assignment-01]]
|
- [[notes/assignment-01]]
|
||||||
- [[notes/assignment-02]]
|
- [[notes/assignment-02]]
|
||||||
@ -6,6 +6,7 @@ tags:
|
|||||||
---
|
---
|
||||||
links: [cosc-202](notes/cosc-202.md)
|
links: [cosc-202](notes/cosc-202.md)
|
||||||
|
|
||||||
|
-
|
||||||
- [07-testing](notes/07-testing.md)
|
- [07-testing](notes/07-testing.md)
|
||||||
- [08-debugging](notes/08-debugging.md)
|
- [08-debugging](notes/08-debugging.md)
|
||||||
- [09-documentation](notes/09-documentation.md)
|
- [09-documentation](notes/09-documentation.md)
|
||||||
|
|||||||
93
content/notes/dependencies.md
Normal file
93
content/notes/dependencies.md
Normal file
@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
title: "dependencies-among-attributes"
|
||||||
|
aliases: dependencies among attributes
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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)
|
||||||
|
|
||||||
|
## 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_
|
||||||
|
|
||||||
|
## 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
|
||||||
|
|
||||||
|
## 1.3 Anti examples
|
||||||
|
- student ID + name --> birth date (ovekill, partial dependency)
|
||||||
|
- home address --> student name
|
||||||
|
- name --> birth date
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
## 1.4 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
|
||||||
|
|
||||||
|
## 1.5 Types of functional dependencies
|
||||||
|
### 1.5.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.,
|
||||||
|
|
||||||
|
|
||||||
|
### 1.5.2 Partial Dependency
|
||||||
|
Subset of left hand side determines right hand side
|
||||||
|
"extra attributes"
|
||||||
|
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
![Uploading file...mfewm]()
|
||||||
|
|
||||||
|
### 1.5.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
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 1.5.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
|
||||||
|
|
||||||
|
## 1.6 Examples
|
||||||
|
|
||||||
16
content/notes/design-heuristics.md
Normal file
16
content/notes/design-heuristics.md
Normal file
@ -0,0 +1,16 @@
|
|||||||
|
---
|
||||||
|
title: "design-heuristics"
|
||||||
|
aliases: Design Heuristics
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
- [show-system-status](notes/show-system-status.md)
|
||||||
|
- [familiar-metaphors-and-language](notes/familiar-metaphors-and-language.md)
|
||||||
|
- [consistency-and-standards](notes/consistency-and-standards.md)
|
||||||
|
- [user-freedom-and-control](notes/user-freedom-and-control.md)
|
||||||
|
- [error-prevention](notes/error-prevention.md)
|
||||||
|
- [recognition-over-recall](notes/recognition-over-recall.md)
|
||||||
|
- [flexibility-and-efficiency](notes/flexibility-and-efficiency.md)
|
||||||
|
- [aesthetic-and-minimalist-design](notes/aesthetic-and-minimalist-design.md)
|
||||||
|
-
|
||||||
@ -1,6 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: "direct-manipulation-video"
|
title: "direct-manipulation-video"
|
||||||
aliases:
|
aliases: Direct Manipulation
|
||||||
tags:
|
tags:
|
||||||
- info203
|
- info203
|
||||||
- video
|
- video
|
||||||
|
|||||||
13
content/notes/divide-and-conquer.md
Normal file
13
content/notes/divide-and-conquer.md
Normal file
@ -0,0 +1,13 @@
|
|||||||
|
---
|
||||||
|
title: "divide-and-conquer"
|
||||||
|
aliases: Divide and Conquer
|
||||||
|
tags:
|
||||||
|
- cosc201
|
||||||
|
- paradigm
|
||||||
|
---
|
||||||
|
|
||||||
|
Divide an conquer algorithms have three parts:
|
||||||
|
|
||||||
|
1. pre ⇒ break apartinto two or more smaller problems whose size add up to at most n
|
||||||
|
2. Rec ⇒ solve those problems recursively
|
||||||
|
3. post ⇒ combine solutions into a solution of the original problem
|
||||||
30
content/notes/docker-containers.md
Normal file
30
content/notes/docker-containers.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "docker-containers"
|
||||||
|
aliases: Docker Containers
|
||||||
|
tags:
|
||||||
|
- video
|
||||||
|
- networks
|
||||||
|
---
|
||||||
|
|
||||||
|
link:https://www.youtube.com/watch?v=eGz9DS-aIeY
|
||||||
|
|
||||||
|
where virtual machines virtualise hardware, docker virtualises OSs. Each of the containers uses the same underlying kernel. This is why its so fast. It is also why you cant run a windows OS and a Linux OS at the same time - because they use different kernels.
|
||||||
|
|
||||||
|
Crontrol groups control how much OS resources each container can use.
|
||||||
|
|
||||||
|
VM:
|
||||||
|
- hardware
|
||||||
|
- hypervisor
|
||||||
|
- windows
|
||||||
|
- ubuntu
|
||||||
|
- debian
|
||||||
|
- etc
|
||||||
|
|
||||||
|
Docker
|
||||||
|
- hardware
|
||||||
|
- ubuntu
|
||||||
|
- docker
|
||||||
|
- debian
|
||||||
|
- ubuntu
|
||||||
|
- windows
|
||||||
|
- etc
|
||||||
24
content/notes/dotnet.md
Normal file
24
content/notes/dotnet.md
Normal file
@ -0,0 +1,24 @@
|
|||||||
|
---
|
||||||
|
title: "dotnet"
|
||||||
|
aliases: .NET
|
||||||
|
tags:
|
||||||
|
- framework
|
||||||
|
---
|
||||||
|
|
||||||
|
.NET is an open source developer platform for building different types of apps.
|
||||||
|
|
||||||
|
A developer framework is Langages and libraries that you use.
|
||||||
|
|
||||||
|
You can use:
|
||||||
|
- c#
|
||||||
|
- f#
|
||||||
|
- VB
|
||||||
|
|
||||||
|
on:
|
||||||
|
- .NET core for Windows, Linux, and macOS
|
||||||
|
- .NEt framework for websites, services, and apps on windows
|
||||||
|
- Xamarin/Mono for mobile.
|
||||||
|
- .NET Standard --> the shared set of libraries for the above.
|
||||||
|
|
||||||
|
|
||||||
|
ASP.NET is an open source web framework for building webapps within .NET. It is cross platform
|
||||||
@ -1,5 +1,6 @@
|
|||||||
---
|
---
|
||||||
title: "entity-relationship-diagrams"
|
title: "entity-relationship-diagrams"
|
||||||
|
aliases: ERDs, ERD, entity relationship diagram, Entity Relationship Diagram
|
||||||
tags:
|
tags:
|
||||||
- info201
|
- info201
|
||||||
---
|
---
|
||||||
|
|||||||
31
content/notes/error-prevention.md
Normal file
31
content/notes/error-prevention.md
Normal file
@ -0,0 +1,31 @@
|
|||||||
|
---
|
||||||
|
title: "error-prevention"
|
||||||
|
aliases: Error Prevention
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
### 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
|
||||||
|
-
|
||||||
@ -1,8 +1,5 @@
|
|||||||
---
|
---
|
||||||
title: "evaluating-designs"
|
title: "evaluating-designs"
|
||||||
sr-due: 2022-04-07
|
|
||||||
sr-interval: 10
|
|
||||||
sr-ease: 210
|
|
||||||
tags:
|
tags:
|
||||||
- info203
|
- info203
|
||||||
---
|
---
|
||||||
|
|||||||
28
content/notes/extreme-programming.md
Normal file
28
content/notes/extreme-programming.md
Normal file
@ -0,0 +1,28 @@
|
|||||||
|
---
|
||||||
|
title: "extreme-programming"
|
||||||
|
aliases: extreme programming, xp, XP, Extreme Programming
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
take current industry practices to the extreme
|
||||||
|
- focus of proven industry practices
|
||||||
|
- combine them innovatively to get better results
|
||||||
|
|
||||||
|
# 1 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
|
||||||
|
|
||||||
|
# 2 Three ring project approach
|
||||||
|
|
||||||
|
|
||||||
18
content/notes/familiar-metaphors-and-language.md
Normal file
18
content/notes/familiar-metaphors-and-language.md
Normal file
@ -0,0 +1,18 @@
|
|||||||
|
---
|
||||||
|
title: "familiar-metaphors-and-language"
|
||||||
|
aliases: Familiar Metaphors And Language
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
imitating familiar real life
|
||||||
|
|
||||||
|
Categories
|
||||||
|
- good
|
||||||
|
- 
|
||||||
|
- bad
|
||||||
|
- 
|
||||||
|
|
||||||
38
content/notes/flexibility-and-efficiency.md
Normal file
38
content/notes/flexibility-and-efficiency.md
Normal file
@ -0,0 +1,38 @@
|
|||||||
|
---
|
||||||
|
title: "flexibility-and-efficiency"
|
||||||
|
aliases: Flexibility and Efficiency
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
### 4.1 Choices
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
something with immediate effect can use switch
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
good defaults
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
4.2 shortcuts and advanced options
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
ambient information
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
proactivity
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -5,6 +5,7 @@ tags:
|
|||||||
---
|
---
|
||||||
links: [[notes/info-201]]
|
links: [[notes/info-201]]
|
||||||
|
|
||||||
|
-
|
||||||
- [04-requirements](notes/04-requirements)
|
- [04-requirements](notes/04-requirements)
|
||||||
- [06-business-functions-and-use-cases](notes/06-business-functions-and-use-cases.md)
|
- [06-business-functions-and-use-cases](notes/06-business-functions-and-use-cases.md)
|
||||||
- [07-business-process-modelling](notes/07-business-process-modelling.md)
|
- [07-business-process-modelling](notes/07-business-process-modelling.md)
|
||||||
@ -13,3 +14,5 @@ links: [[notes/info-201]]
|
|||||||
- [10-oop-concepts-and-uml](notes/10-oop-concepts-and-uml.md)
|
- [10-oop-concepts-and-uml](notes/10-oop-concepts-and-uml.md)
|
||||||
- [11-class-diagrams](notes/11-class-diagrams.md)
|
- [11-class-diagrams](notes/11-class-diagrams.md)
|
||||||
- [12-modelling-behaviour](notes/12-modelling-behaviour.md)
|
- [12-modelling-behaviour](notes/12-modelling-behaviour.md)
|
||||||
|
- [13-UML-sequence-diagrams](notes/13-UML-sequence-diagrams.md)
|
||||||
|
- [14-direct-manipulation-and-mental-models](notes/14-direct-manipulation-and-mental-models.md)
|
||||||
@ -6,11 +6,13 @@ tags:
|
|||||||
links: [[notes/info-201]]
|
links: [[notes/info-201]]
|
||||||
|
|
||||||
- [version-control-system](notes/version-control-system.md)
|
- [version-control-system](notes/version-control-system.md)
|
||||||
|
- [stakeholders](notes/stakeholders.md)
|
||||||
- [business-analyst](notes/business-analyst.md)
|
- [business-analyst](notes/business-analyst.md)
|
||||||
- [developer](notes/developer.md)
|
- [developer](notes/developer.md)
|
||||||
- [models](notes/models.md)
|
- [models](notes/models.md)
|
||||||
- [systems-development-life-cycle](notes/systems-development-life-cycle.md)
|
- [systems-development-life-cycle](notes/systems-development-life-cycle.md)
|
||||||
- [agile-development](notes/agile-development.md)
|
- [agile-development](notes/agile-development.md)
|
||||||
|
- [scrum](notes/scrum.md)
|
||||||
- [predictive-adaptive-spectrum](notes/predictive-adaptive-spectrum.md)
|
- [predictive-adaptive-spectrum](notes/predictive-adaptive-spectrum.md)
|
||||||
- [requirements](notes/requirements.md)
|
- [requirements](notes/requirements.md)
|
||||||
- [requirements-document](notes/requirements-document.md)
|
- [requirements-document](notes/requirements-document.md)
|
||||||
@ -25,3 +27,8 @@ links: [[notes/info-201]]
|
|||||||
- [business-process-model-and-notation](notes/business-process-model-and-notation.md)
|
- [business-process-model-and-notation](notes/business-process-model-and-notation.md)
|
||||||
- [UML](notes/UML.md)
|
- [UML](notes/UML.md)
|
||||||
- [entity-relationship-diagrams](notes/entity-relationship-diagrams.md)
|
- [entity-relationship-diagrams](notes/entity-relationship-diagrams.md)
|
||||||
|
- [modelling behaviour](notes/modelling-behaviour.md)
|
||||||
|
- [conceptual-vs-ipmlementation-models](notes/conceptual-vs-ipmlementation-models.md)
|
||||||
|
- [redundancy-and-anomalies](notes/redundancy-and-anomalies.md)
|
||||||
|
- [dependencies](notes/dependencies.md)
|
||||||
|
- [normalisation](notes/normalisation.md)
|
||||||
|
|||||||
@ -11,8 +11,6 @@ links: [_index](_index.md)
|
|||||||
- [info-201-lectures](notes/info-201-lectures.md)
|
- [info-201-lectures](notes/info-201-lectures.md)
|
||||||
- [info-201-outline](notes/info-201-outline.md)
|
- [info-201-outline](notes/info-201-outline.md)
|
||||||
|
|
||||||
-
|
|
||||||
|
|
||||||
- [coursework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
- [coursework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||||
- [assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
- [assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||||
- [labs folder](file:///"C:/Users/Jet%20Hughes/Documents/Personal/courses/info-201/Labs")
|
- [labs folder](file:///"C:/Users/Jet%20Hughes/Documents/Personal/courses/info-201/Labs")
|
||||||
|
|||||||
@ -5,9 +5,14 @@ tags:
|
|||||||
---
|
---
|
||||||
link: [[notes/info-203]]
|
link: [[notes/info-203]]
|
||||||
|
|
||||||
|
- [04-evaluation-methods-birth-of-hci](notes/04-evaluation-methods-birth-of-hci.md)
|
||||||
- [07-heuristic-evaluation-cont](notes/07-heuristic-evaluation-cont.md)
|
- [07-heuristic-evaluation-cont](notes/07-heuristic-evaluation-cont.md)
|
||||||
- [08-personas-and-scenarios](notes/08-personas-and-scenarios.md)
|
- [08-personas-and-scenarios](notes/08-personas-and-scenarios.md)
|
||||||
- [09-paper-prototypes-wiz-of-oz-video-prototypes](notes/09-paper-prototypes-wiz-of-oz-video-prototypes.md)
|
- [09-paper-prototypes-wiz-of-oz-video-prototypes](notes/09-paper-prototypes-wiz-of-oz-video-prototypes.md)
|
||||||
- [10-design-heuristics-1](notes/10-design-heuristics-1.md)
|
- [10-design-heuristics-1](notes/10-design-heuristics-1.md)
|
||||||
- [11-design-heuristics-2](notes/11-design-heuristics-2.md)
|
- [11-design-heuristics-2](notes/11-design-heuristics-2.md)
|
||||||
- [12-design-heuristics-3](notes/12-design-heuristics-3.md)
|
- [12-design-heuristics-3](notes/12-design-heuristics-3.md)
|
||||||
|
- [13-design-heuristics-4](notes/13-design-heuristics-4.md)
|
||||||
|
- [14-direct-manipulation-and-mental-models](notes/14-direct-manipulation-and-mental-models.md)
|
||||||
|
- [15-mental-models-representation-matters-distributing-cognition](notes/15-mental-models-representation-matters-distributing-cognition.md)
|
||||||
|
- [16-distributing-cognition-and-visual-design-typography](notes/16-distributing-cognition-and-visual-design-typography.md)
|
||||||
@ -7,13 +7,22 @@ links: [[notes/info-203]]
|
|||||||
|
|
||||||
- [big-picture](notes/big-picture.md)
|
- [big-picture](notes/big-picture.md)
|
||||||
- [birth-of-hci](notes/birth-of-hci.md)
|
- [birth-of-hci](notes/birth-of-hci.md)
|
||||||
|
- [user-experience](notes/user-experience.md)
|
||||||
|
- [usbability](notes/usbability.md)
|
||||||
- [prototyping](notes/prototyping.md)
|
- [prototyping](notes/prototyping.md)
|
||||||
- [evaluating-designs](notes/evaluating-designs.md)
|
- [evaluating-designs](notes/evaluating-designs.md)
|
||||||
|
- [Design Heuristics](notes/design-heuristics.md)
|
||||||
|
- [error-prevention](notes/error-prevention.md)
|
||||||
|
- [flexibility-and-efficiency](notes/flexibility-and-efficiency.md)
|
||||||
|
- [aesthetic-and-minimalist-design](notes/aesthetic-and-minimalist-design.md)
|
||||||
|
- [consistency-and-standards](notes/consistency-and-standards.md)
|
||||||
|
- [recognition-over-recall](notes/recognition-over-recall.md)
|
||||||
|
- [user-freedom-and-control](notes/user-freedom-and-control.md)
|
||||||
|
- [familiar-metaphors-and-language](notes/familiar-metaphors-and-language.md)
|
||||||
|
- [show-system-status](notes/show-system-status.md)
|
||||||
- [needfinding](notes/needfinding.md)
|
- [needfinding](notes/needfinding.md)
|
||||||
- [participant-observation](notes/participant-observation.md)
|
- [participant-observation](notes/participant-observation.md)
|
||||||
- [interviewing](notes/interviewing.md)
|
- [interviewing](notes/interviewing.md)
|
||||||
- [user-experience](notes/user-experience.md)
|
|
||||||
- [usbability](notes/usbability.md)
|
|
||||||
- [storyboards](notes/storyboards.md)
|
- [storyboards](notes/storyboards.md)
|
||||||
- [personas-and-scenarios](notes/personas-and-scenarios.md)
|
- [personas-and-scenarios](notes/personas-and-scenarios.md)
|
||||||
-
|
-
|
||||||
@ -9,4 +9,6 @@ links: [[notes/info-203]]
|
|||||||
- [storyboards-mockups-paper-prototypes](notes/storyboards-mockups-paper-prototypes.md)
|
- [storyboards-mockups-paper-prototypes](notes/storyboards-mockups-paper-prototypes.md)
|
||||||
- [wizard-of-oz](notes/wizard-of-oz.md)
|
- [wizard-of-oz](notes/wizard-of-oz.md)
|
||||||
- [video-prototyping](notes/video-prototyping.md)
|
- [video-prototyping](notes/video-prototyping.md)
|
||||||
- []
|
- [direct-manipulation-video](notes/direct-manipulation-video.md)
|
||||||
|
- [mental-models-video](notes/mental-models-video.md)
|
||||||
|
* [visual-design-video](notes/visual-design-video.md)
|
||||||
@ -11,3 +11,5 @@ links:[_index](_index.md)
|
|||||||
- [info-203-outline](notes/info-203-outline.md)
|
- [info-203-outline](notes/info-203-outline.md)
|
||||||
- [info-203-lectures](notes/info-203-lectures.md)
|
- [info-203-lectures](notes/info-203-lectures.md)
|
||||||
- [info-203-videos](notes/info-203-videos.md)
|
- [info-203-videos](notes/info-203-videos.md)
|
||||||
|
|
||||||
|
- [mobile-app-ass-03](203-mobile-app/mobile-app-ass-03.md)
|
||||||
41
content/notes/mental-models-video.md
Normal file
41
content/notes/mental-models-video.md
Normal file
@ -0,0 +1,41 @@
|
|||||||
|
---
|
||||||
|
title: "mental-models-video"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
- video
|
||||||
|
---
|
||||||
|
|
||||||
|
The users mental model is how the user thinks the interface works.
|
||||||
|
|
||||||
|
for example the fridge with two dials, or the doors.
|
||||||
|
|
||||||
|
The goal is for the design to create the correct mental model in the user. Designers often expect the user to have the same mental model as them, but this is not always the true. The users model is developed through iteraction with the system
|
||||||
|
|
||||||
|
This is why its important to have other people test the system.
|
||||||
|
|
||||||
|
A conceptual model mistach can lead to slow performance, erros, and frustration.
|
||||||
|
|
||||||
|
Mental models arise from experience, metaphor, and analogical reasoning. We can leverage what people have learnt from old interfaces to inform new ones. Our mental models are iconsistent, unstable in time, and often rife with superstition.
|
||||||
|
|
||||||
|
# Slips vs Mistakes
|
||||||
|
|
||||||
|
A slip is when you have the right model but accidentally do the wrong thing.
|
||||||
|
|
||||||
|
A mistake is when you do what you intended, by you have the wrong mental model.
|
||||||
|
|
||||||
|
Slips with be prevented by improving ergonomics or visual design.
|
||||||
|
|
||||||
|
Mistakes can be prevented by providing better feedback and making options more clear.
|
||||||
|
|
||||||
|
re using existing designs reduced mistakes.
|
||||||
|
|
||||||
|
|
||||||
|
# World in miniature interface
|
||||||
|
|
||||||
|
for example the seat interface
|
||||||
|
[](https://i.imgur.com/J8d9Q0N.png)
|
||||||
|
|
||||||
|
> "Is technology is providing an advantage, the correspondance to the real world must break down at some point" - Jonathan Grudin
|
||||||
|
|
||||||
|
We should minimise the gap between current technology and new technology.
|
||||||
@ -26,7 +26,6 @@ e.g.,
|
|||||||
0 1 2 3 4 4 6 7 8 9
|
0 1 2 3 4 4 6 7 8 9
|
||||||
|
|
||||||
# 1 Implementation
|
# 1 Implementation
|
||||||
|
|
||||||
## 1.1 Merge
|
## 1.1 Merge
|
||||||
|
|
||||||
Given: a and b are sorted arrays. m is an array whose size is the sum of their sizes
|
Given: a and b are sorted arrays. m is an array whose size is the sum of their sizes
|
||||||
@ -153,4 +152,4 @@ The bottom-up version does exactly the same thing as the top-down version, just
|
|||||||
|
|
||||||
# 2 Variations of Mergesort
|
# 2 Variations of Mergesort
|
||||||
|
|
||||||
[[unite and conquer]] #unfinished
|
[unite and conquer](notes/unite-and-conquer.md)
|
||||||
@ -1,9 +0,0 @@
|
|||||||
---
|
|
||||||
title: "milestone-2"
|
|
||||||
aliases:
|
|
||||||
tags:
|
|
||||||
- assignment
|
|
||||||
- info201
|
|
||||||
---
|
|
||||||
|
|
||||||
|
|
||||||
15
content/notes/model-view-controller-pattern.md
Normal file
15
content/notes/model-view-controller-pattern.md
Normal file
@ -0,0 +1,15 @@
|
|||||||
|
---
|
||||||
|
title: "model-view-controller-pattern"
|
||||||
|
aliases: MVC
|
||||||
|
tags:
|
||||||
|
- pattern
|
||||||
|
---
|
||||||
|
|
||||||
|
**Model:** An object carrying data
|
||||||
|
- handles data logiv
|
||||||
|
- interacts with database
|
||||||
|
|
||||||
|
**View**: The visualisation of the data that model contains
|
||||||
|
- rendered dynamically
|
||||||
|
|
||||||
|
**Controller:** Controls the data flow into model object and updates the view whenever data changes. Keeps view and model separate.
|
||||||
@ -6,16 +6,15 @@ tags:
|
|||||||
- info201
|
- info201
|
||||||
---
|
---
|
||||||
|
|
||||||
[relevant slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2892846-dt-content-rid-18407618_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_12_slides.pdf), [lecture recording](https://echo360.net.au/lesson/3807232c-e251-4818-a098-c61f6a6b455a/classroom#sortDirection=desc)
|
[relevant slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2892846-dt-content-rid-18407618_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_12_slides.pdf), [lecture recording](https://echo360.net.au/lesson/3807232c-e251-4818-a098-c61f6a6b455a/classroom#sortDirection=desc), [relevant article](https://thevaluable.dev/anemic-domain-model/)
|
||||||
|
|
||||||
Modelling behaviour is more complex than modelling the structure of OOP systems (e.g., [class-diagrams](notes/class-diagrams.md). There are more digrams types, it more general, and more complicated.
|
Modelling behaviour is more complex than modelling the structure of OOP systems (e.g., [class-diagrams](notes/class-diagrams.md). There are more diagram types, they are more general, and more complicated.
|
||||||
|
|
||||||
Although class diagrams specify some behaviour (public vs private, method signature and implementations, api (what methods are available), inheritance and behaviour).
|
Class do diagrams specify *some* behaviour (public vs private, method signature and implementations, api (what methods are available), inheritance and behaviour).
|
||||||
|
|
||||||
Models of system and object behaviour cover these and also lower level sequencing and flow of control, and compartmentalisation into "subsystems"
|
Models of system and object behaviour cover these and also lower level sequencing and flow of control, and compartmentalisation into "subsystems"
|
||||||
|
|
||||||
# 1 Inheritance
|
# 1 Inheritance
|
||||||
|
|
||||||
## 1.1 Via Specialisation
|
## 1.1 Via Specialisation
|
||||||
Inheritance via specialisation is when something is subclass of something else. Subclasses inherit all public members of their parents. They are able to replace or customise inherited existing methods and add their own specialsed methods (including constructors). [example class diagram](https://i.imgur.com/Nul5ECp.png), [example java code](https://i.imgur.com/D7nZ2ON.png)
|
Inheritance via specialisation is when something is subclass of something else. Subclasses inherit all public members of their parents. They are able to replace or customise inherited existing methods and add their own specialsed methods (including constructors). [example class diagram](https://i.imgur.com/Nul5ECp.png), [example java code](https://i.imgur.com/D7nZ2ON.png)
|
||||||
|
|
||||||
@ -59,6 +58,27 @@ in Java:
|
|||||||
- subclass or implement this to create specific implementations
|
- subclass or implement this to create specific implementations
|
||||||
- use the top-level class or interface everywhere you would otherwise use the specialised implementations
|
- use the top-level class or interface everywhere you would otherwise use the specialised implementations
|
||||||
|
|
||||||
|
|
||||||
# 2 Behaviour
|
# 2 Behaviour
|
||||||
|
## 2.1 Anaemic domain models
|
||||||
|
In an anaemic domain model the **domain objects** also called **Models** contain (mostly) only data, and very little logic.
|
||||||
|
|
||||||
|
The **services** set the properties of the models via getters and setters. This defines the logic of the application
|
||||||
|
|
||||||
|
[anaemic example](https://i.imgur.com/PeaBhnX.png)
|
||||||
|
|
||||||
|
**Processor objects** are often used in anaemic systems to move data between objects. Also called **services**
|
||||||
|
|
||||||
|
[processor example](https://i.imgur.com/jw3Xbc1.png)
|
||||||
|
|
||||||
|
|
||||||
|
## 2.2 Rich domain models
|
||||||
|
In a rich domain model logic is contained within **real domain models**. And the service layer thin and used only for third party services.
|
||||||
|
|
||||||
|
This means that the behaviour of the domain models is encapsulated within them
|
||||||
|
|
||||||
|
[rich example](https://i.imgur.com/eHmda7A.png)
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
#unfinished
|
#unfinished
|
||||||
10
content/notes/networks.md
Normal file
10
content/notes/networks.md
Normal file
@ -0,0 +1,10 @@
|
|||||||
|
---
|
||||||
|
title: "networks"
|
||||||
|
aliases: Networks
|
||||||
|
tags:
|
||||||
|
-
|
||||||
|
---
|
||||||
|
|
||||||
|
- [docker-containers](notes/docker-containers.md)
|
||||||
|
- [virtual-machines](notes/virtual-machines.md)
|
||||||
|
- [SSH](notes/ssh.md)
|
||||||
32
content/notes/normalisation.md
Normal file
32
content/notes/normalisation.md
Normal file
@ -0,0 +1,32 @@
|
|||||||
|
---
|
||||||
|
title: "normalisation"
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
formal process of eliminanting unnecessary redundancy in relations by splitting relations into smaller chunks
|
||||||
|
|
||||||
|
bottom up approach
|
||||||
|
- functional dependencies ⇒ normalised relations
|
||||||
|
- requirements ⇒ conceptual ≫ logical is "top down"
|
||||||
|
- use normalisation to verify your logical design
|
||||||
|
- to ensure you haven't missed anything
|
||||||
|
|
||||||
|
# 1 Pros ans cons
|
||||||
|
|
||||||
|
+ frees from anomalies
|
||||||
|
+ separates data the belong to different entities
|
||||||
|
+ reduces data redundancy
|
||||||
|
+ doesn't bias db design infaour of certain queries at the expense of others
|
||||||
|
|
||||||
|
- more relations required
|
||||||
|
- more complex queries can imply slower performance in some DBMSs
|
||||||
|
|
||||||
|
# 2 Normal forms
|
||||||
|
- 1NF ⇒ Single valued attributes only
|
||||||
|
- 2NF ⇒ all on-key attibutes fully dependent on PK (i.e., no dependencies on part of the PK) (no partial dependencies)
|
||||||
|
- 3NF/BCNF ⇒ no non-key transitive dependencies
|
||||||
|
- 4NF ⇒ no multivalued dependencies
|
||||||
|
- 5NF ⇒ all join dependencies implied by Composite key (CKs)
|
||||||
|
- 6NF ⇒ irreducible relations
|
||||||
@ -34,7 +34,7 @@ Why they want to accomplish end goals /long term desires/self-image
|
|||||||
|
|
||||||
- activities ⇒ what the user does, frequency and volume
|
- activities ⇒ what the user does, frequency and volume
|
||||||
- attitudes ⇒ how the uers thinks about the product domian and knowledge
|
- attitudes ⇒ how the uers thinks about the product domian and knowledge
|
||||||
- aptitudes ⇒ what education and trainging the user has
|
- aptitudes ⇒ what education and training the user has
|
||||||
- motivations
|
- motivations
|
||||||
- why the user is engaged in the product domain
|
- why the user is engaged in the product domain
|
||||||
- skills
|
- skills
|
||||||
@ -66,3 +66,5 @@ Have a good story to tell
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
25
content/notes/propogation-of-ideas.md
Normal file
25
content/notes/propogation-of-ideas.md
Normal file
@ -0,0 +1,25 @@
|
|||||||
|
---
|
||||||
|
title: "Untitled 2"
|
||||||
|
aliases: Memes and the Eploitation of Imagination
|
||||||
|
tags:
|
||||||
|
- article
|
||||||
|
- philosophy
|
||||||
|
- art
|
||||||
|
---
|
||||||
|
|
||||||
|
link:https://ase.tufts.edu/cogstud/dennett/papers/memeimag.htm
|
||||||
|
|
||||||
|
The david and miriam mandel lecture
|
||||||
|
american society for aesthetics
|
||||||
|
oct 27 1989
|
||||||
|
|
||||||
|
How (or whether) are promotes human evolution or development
|
||||||
|
|
||||||
|
# What is a Meme
|
||||||
|
Richard Dawkins defines a meme as: a unit of cultural transmission, or a unit of imitation
|
||||||
|
|
||||||
|
**Art:** all artifice, all human invention
|
||||||
|
|
||||||
|
The paper compares memes to genes and explores the way they evolve similar to genes
|
||||||
|
|
||||||
|
|
||||||
22
content/notes/quicksort.md
Normal file
22
content/notes/quicksort.md
Normal file
@ -0,0 +1,22 @@
|
|||||||
|
---
|
||||||
|
title: "quicksort"
|
||||||
|
aliases: Quicksort
|
||||||
|
tags:
|
||||||
|
- cosc201
|
||||||
|
- algorithm
|
||||||
|
---
|
||||||
|
|
||||||
|
pre ⇒ select pivot and split the array
|
||||||
|
|
||||||
|
rec ⇒ apply quicksort to the partitions
|
||||||
|
|
||||||
|
post ⇒ not much
|
||||||
|
|
||||||
|
designeds when sorting inplace was important
|
||||||
|
|
||||||
|
works best of primitive types as they can be stored in the fastest memory location
|
||||||
|
|
||||||
|
- memory access can be localised and the comparisions are direct
|
||||||
|
- those advantages are limited when sorting objects of reference type
|
||||||
|
- i that case each element of the array is just a reference to where the object really is
|
||||||
|
- so there are no local access advantages
|
||||||
18
content/notes/recognition-over-recall.md
Normal file
18
content/notes/recognition-over-recall.md
Normal file
@ -0,0 +1,18 @@
|
|||||||
|
---
|
||||||
|
title: "recognition-over-recall"
|
||||||
|
aliases: Recognition Over Recall
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
### 3.1 avoid codes
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.2 Recognition with previews or icons
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
### 3.3 use icons that promote recognition
|
||||||
|
|
||||||
|
|
||||||
42
content/notes/redundancy-and-anomalies.md
Normal file
42
content/notes/redundancy-and-anomalies.md
Normal file
@ -0,0 +1,42 @@
|
|||||||
|
---
|
||||||
|
title: "redundancy-and-anomalies"
|
||||||
|
aliases: redundancy and anomalies
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
### 0.1 Redundancy
|
||||||
|
when values are stored repetitively in database relations
|
||||||
|
- usually in poorly designed relations
|
||||||
|
- - potential for anomalous data to be stored
|
||||||
|
e.g., 
|
||||||
|
|
||||||
|
#### 0.1.1 How it arises
|
||||||
|
- ad hoc database
|
||||||
|
- flat file
|
||||||
|
- spreadsheet (no contraints)
|
||||||
|
- Poor database design
|
||||||
|
- poor analysis
|
||||||
|
- poorly designed ERDs (not thinkiing properly about the relationships)
|
||||||
|
- modifications to existing systems
|
||||||
|
- "bolting on" new attributes
|
||||||
|
- schema evolution over time
|
||||||
|
|
||||||
|
### 0.2 Anomalies
|
||||||
|
#### 0.2.1 Update anomaly
|
||||||
|
An anomaly that occurs follows an UPDATE operation
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
#### 0.2.2 Delete anomaly
|
||||||
|
An anomly that occurs following a DELETE operation
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
#### 0.2.3 Insert anomaly
|
||||||
|
An anomly that occurs following a INSERT operation
|
||||||
|
e.g.,
|
||||||
|
|
||||||
|
|
||||||
|
Causes the process of putting johnson in system is delayed
|
||||||
27
content/notes/scrum.md
Normal file
27
content/notes/scrum.md
Normal file
@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
title: "scrum"
|
||||||
|
aliases: SCRUM
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
---
|
||||||
|
|
||||||
|
Intense effort involving entire team for defined period of time
|
||||||
|
Product backlog - prioritied list of requirements
|
||||||
|
Product owner - cllient stakeholder who controls backlog
|
||||||
|
Scrum master - project manager
|
||||||
|
|
||||||
|
# 1 Scrum sprint
|
||||||
|
A time controlled mini-project to implement part of the system
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
# 2 Scrum practices
|
||||||
|
scope of sprint is frozen
|
||||||
|
- can reduce
|
||||||
|
- cannot expand
|
||||||
|
time period is kept constant
|
||||||
|
|
||||||
|
daily scrum meeting
|
||||||
|
- what have you done since last scrum
|
||||||
|
- what whill you do by next scrum
|
||||||
|
- what kept you or is keeping you from compeleting your work
|
||||||
@ -1,4 +1,5 @@
|
|||||||
---
|
---
|
||||||
|
number headings: auto, first-level 1, max 6, 1.1
|
||||||
title: "set"
|
title: "set"
|
||||||
aliases: sets, Set, Sets
|
aliases: sets, Set, Sets
|
||||||
tags:
|
tags:
|
||||||
@ -20,13 +21,13 @@ This gives us the methods:
|
|||||||
- `Remove(x)`
|
- `Remove(x)`
|
||||||
- `Contains(x)`
|
- `Contains(x)`
|
||||||
|
|
||||||
Binary search trees are data types that supprts this ddata type when there is an ordering on the runderlying elements'
|
Binary search trees are data types that supprts this data type when there is an ordering on the underlying elements
|
||||||
|
A [binary search tree](notes/binary-search-tree.md) can be used to implement a set when there is no order. [hash sets and hash maps](notes/hash-map.md) can be used when there is order.
|
||||||
|
|
||||||
[hash sets and hash maps](notes/hash-map.md) do the same when there is no order.
|
# 1 Implementations
|
||||||
|
## 1.1 Basic set
|
||||||
|
|
||||||
## 0.1 Basic set
|
Simplest way to implement a set is using an array.
|
||||||
|
|
||||||
Simplest way would be to use a list or an array.
|
|
||||||
|
|
||||||
[Code for basic set](https://blackboard.otago.ac.nz/bbcswebdav/pid-2890167-dt-content-rid-18354837_1/courses/COSC201_S1DNIE_2022/BasicSet.java)
|
[Code for basic set](https://blackboard.otago.ac.nz/bbcswebdav/pid-2890167-dt-content-rid-18354837_1/courses/COSC201_S1DNIE_2022/BasicSet.java)
|
||||||
|
|
||||||
@ -38,11 +39,11 @@ Simplest way would be to use a list or an array.
|
|||||||
|
|
||||||
All three operations are $O(n)$ as they must all iterate over the entire set
|
All three operations are $O(n)$ as they must all iterate over the entire set
|
||||||
|
|
||||||
## 0.2 Ordered set
|
## 1.2 Ordered set
|
||||||
|
|
||||||
A set with some underlying "natural" order. E.g., dictionary order for `string` objects.
|
A set with some underlying "natural" order. E.g., dictionary order for `string` objects.
|
||||||
|
|
||||||
We would also like to be able to do a in order *traversal*
|
We would also like to be able to do an in order traversal of an ordered set
|
||||||
|
|
||||||
If the set is static
|
If the set is static
|
||||||
- store using sorted array
|
- store using sorted array
|
||||||
@ -56,3 +57,5 @@ But then:
|
|||||||
This is fine if we dont expect to use the dynamic operations a lot.
|
This is fine if we dont expect to use the dynamic operations a lot.
|
||||||
|
|
||||||
Another approach might be to maintain a `main` array and a subsidary `add` and `remove` arrays and only periodically do the updates to the main array. but this gets complicated very quickly
|
Another approach might be to maintain a `main` array and a subsidary `add` and `remove` arrays and only periodically do the updates to the main array. but this gets complicated very quickly
|
||||||
|
|
||||||
|
A better way of doing this is using a [binary search tree](notes/binary-search-tree.md)
|
||||||
26
content/notes/show-system-status.md
Normal file
26
content/notes/show-system-status.md
Normal file
@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
title: "show-system-status"
|
||||||
|
aliases: Show System Status, System Status
|
||||||
|
tags:
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
This is the first of neilsens ten usability heuristics. fr
|
||||||
|
|
||||||
|
- 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
|
||||||
|
|
||||||
|
|
||||||
26
content/notes/ssh.md
Normal file
26
content/notes/ssh.md
Normal file
@ -0,0 +1,26 @@
|
|||||||
|
---
|
||||||
|
title: "ssh"
|
||||||
|
aliases: SSH
|
||||||
|
tags:
|
||||||
|
- networks
|
||||||
|
---
|
||||||
|
|
||||||
|
# What is it
|
||||||
|
telnet was a set of protocols for one xomputer to control another. This was not secure
|
||||||
|
|
||||||
|
Telnet then spawned secure shell (SSH). This encytped
|
||||||
|
|
||||||
|
The computer to be controlled needs to be running an SSH server.
|
||||||
|
|
||||||
|
To connect to and control the device with the server we need to install SSH software on the device we will use to connect
|
||||||
|
|
||||||
|
to login: ssh username@ip-address then enter password
|
||||||
|
|
||||||
|
# Where is it used.
|
||||||
|
|
||||||
|
While users access a server by TLS or HTTP(S), admins access a server using SSH via the command line.
|
||||||
|
|
||||||
|
It can also be used for automated operations. Usually this will also invole file transfer using SCP for SFTP
|
||||||
|
|
||||||
|
|
||||||
|
0 juyt
|
||||||
27
content/notes/stakeholders.md
Normal file
27
content/notes/stakeholders.md
Normal file
@ -0,0 +1,27 @@
|
|||||||
|
---
|
||||||
|
title: "stakeholders"
|
||||||
|
aliases: Stakeholders
|
||||||
|
tags:
|
||||||
|
- info201
|
||||||
|
- info203
|
||||||
|
---
|
||||||
|
|
||||||
|
People with interest in successful implementation
|
||||||
|
|
||||||
|
three primary groups
|
||||||
|
- users
|
||||||
|
- clients -> pay for and own systems
|
||||||
|
- technical staff -> ensure system operation
|
||||||
|
|
||||||
|
Analyst should id every type of stakeholder during [systems-development-life-cycle](notes/systems-development-life-cycle.md)
|
||||||
|
|
||||||
|
### 0.2 users as stakeholders
|
||||||
|
horizontal user roles -> information flow across dept's
|
||||||
|
- ?
|
||||||
|
|
||||||
|
vertical user roles ->information needs of staff, middle management, senior execs
|
||||||
|
- business users perform day to day operations
|
||||||
|
- information users need current information
|
||||||
|
- mangement users need summary information
|
||||||
|
- executive users need strategic information
|
||||||
|
- external users may have access to the systems
|
||||||
@ -15,6 +15,21 @@ short and concise
|
|||||||
low fidelity
|
low fidelity
|
||||||
not about pretty picures. ⇒ about communicating ideas
|
not about pretty picures. ⇒ about communicating ideas
|
||||||
|
|
||||||
|
Shows:
|
||||||
|
- setting
|
||||||
|
- people
|
||||||
|
- environment
|
||||||
|
- task being done
|
||||||
|
- sequence
|
||||||
|
- what steps
|
||||||
|
- what leads someone to the app
|
||||||
|
- task task
|
||||||
|
- satisfaction
|
||||||
|
- what is the users motivation
|
||||||
|
- what does it enable people to accomplish
|
||||||
|
- what need does the system fill
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
@ -43,17 +58,3 @@ simplify and develop vocabulary/your own style
|
|||||||
|
|
||||||
using tracing and templates
|
using tracing and templates
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
- setting
|
|
||||||
- people
|
|
||||||
- environment
|
|
||||||
- task being done
|
|
||||||
- sequence
|
|
||||||
- what steps
|
|
||||||
- what leads someone to the app
|
|
||||||
- task task
|
|
||||||
- satisfaction
|
|
||||||
- what is the users motivation
|
|
||||||
- what does it enable people to accomplish
|
|
||||||
- what need does the system fill
|
|
||||||
|
|||||||
@ -1,7 +1,69 @@
|
|||||||
---
|
---
|
||||||
title: "systems-development-life-cycle"
|
title: "systems-development-life-cycle"
|
||||||
|
aliases: SDLC, sdlc, Systems Development Life Cycle, Systems Development Lifecycle
|
||||||
tags:
|
tags:
|
||||||
- info201
|
- info201
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
||||||
|
Provides overall framework for managing the systems
|
||||||
|
There are many methodologies to help guide us through this cycle
|
||||||
|
Each methodology sits on the [predictive-adaptive-spectrum](notes/predictive-adaptive-spectrum.md)
|
||||||
|
A very common methodology at the moment is [agile-development](notes/agile-development.md)
|
||||||
|
|
||||||
|
## 1 Phases
|
||||||
|
### 1.1 Analysis
|
||||||
|
^2d7976
|
||||||
|
- Lots of communication with [stakeholders](notes/stakeholders.md)
|
||||||
|
- Gather detailed information
|
||||||
|
- define system requirements
|
||||||
|
- prioritise requirements (what is risky, what brings value to business) -> increase proability of success
|
||||||
|
- develop UI dialogs ([prototyping](notes/prototyping.md)' where the user can interact with the system)
|
||||||
|
- evaluate requirments
|
||||||
|
- review reccomendations with management
|
||||||
|
|
||||||
|
## 2 Business process re-engineering
|
||||||
|
method of organising company
|
||||||
|
- streamline processes to be efficient and efffective
|
||||||
|
- question basic assumptions
|
||||||
|
|
||||||
|
use ICT to help with BPR
|
||||||
|
|
||||||
|
sys analyst may find opportunites to improve processes
|
||||||
|
- any project can include components of BPR
|
||||||
|
|
||||||
|
simpler business processes -> simpler requirements -> simpler system
|
||||||
|
|
||||||
|
## 3 Requirements
|
||||||
|
- [requirements](notes/requirements.md)
|
||||||
|
- [requirements-elicitation](notes/requirements-elicitation.md)
|
||||||
|
- Something the system should do
|
||||||
|
- Some constraint the system should have
|
||||||
|
- Can be functional or non functional
|
||||||
|
- Good requirements prevent failure
|
||||||
|
|
||||||
|
## 4 SDLC Variations
|
||||||
|
- different terminology
|
||||||
|
- change focus on people
|
||||||
|
- change speed of development
|
||||||
|
- [prototyping](notes/prototyping.md)
|
||||||
|
- Rapid application development (RAD)
|
||||||
|
|
||||||
|
## 5 Failure
|
||||||
|
main goal: Avoid project failure
|
||||||
|
- complete fail implies nothing delivered
|
||||||
|
- Types of fail
|
||||||
|
- cost overruns
|
||||||
|
- sw quality issues
|
||||||
|
- missed deadlines
|
||||||
|
- unhappy [stakeholders](notes/stakeholders.md)
|
||||||
|
|
||||||
|
Suprisingly very common with large projects
|
||||||
|
|
||||||
|
reasons for fail:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
**coding rarely causes problems**
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@ -8,3 +8,6 @@ tags:
|
|||||||
- [[templates/note-header]]
|
- [[templates/note-header]]
|
||||||
- [[templates/course]]
|
- [[templates/course]]
|
||||||
- [[templates/post]]
|
- [[templates/post]]
|
||||||
|
- [date-day](private/templates/date-day.md)
|
||||||
|
- [DailyTemplate](private/templates/DailyTemplate.md)
|
||||||
|
- [induction-proof-template](private/templates/induction-proof-template.md)
|
||||||
30
content/notes/tree-traversal.md
Normal file
30
content/notes/tree-traversal.md
Normal file
@ -0,0 +1,30 @@
|
|||||||
|
---
|
||||||
|
title: "tree-traversal"
|
||||||
|
aliases: traversal
|
||||||
|
tags:
|
||||||
|
- cosc201
|
||||||
|
---
|
||||||
|
|
||||||
|
Visit each node in the tree once. So we need to visit n, all the nodes in L, and all the nodes in R. We can do this in four different ways
|
||||||
|
|
||||||
|
preorder
|
||||||
|
- visit n
|
||||||
|
- traverse L
|
||||||
|
- traverse R
|
||||||
|
|
||||||
|
Inorder.
|
||||||
|
- traverse L
|
||||||
|
- visit n
|
||||||
|
- traverse R
|
||||||
|
Creating an BST from an array using the add operation then doing an inorder traversal is effectively a [quicksort](notes/quicksort)
|
||||||
|
|
||||||
|
postorder
|
||||||
|
- traverse L
|
||||||
|
- traverse R
|
||||||
|
- visit n
|
||||||
|
|
||||||
|
level order
|
||||||
|
- vist the root
|
||||||
|
- visit the roots children
|
||||||
|
- visit their children
|
||||||
|
- etc
|
||||||
@ -2,7 +2,6 @@
|
|||||||
title: "tree"
|
title: "tree"
|
||||||
tags:
|
tags:
|
||||||
- cosc201
|
- cosc201
|
||||||
- datastructure
|
|
||||||
---
|
---
|
||||||
|
|
||||||
not so much a data type. More of a data concept of a way in which data can be organised
|
not so much a data type. More of a data concept of a way in which data can be organised
|
||||||
@ -14,7 +13,7 @@ The type required for the ordered [set](notes/set.md) data type is the binary tr
|
|||||||
Trees in general:
|
Trees in general:
|
||||||
- Consists of *Nodes*
|
- Consists of *Nodes*
|
||||||
- One node is distinguished and called the *root*
|
- One node is distinguished and called the *root*
|
||||||
- Each node, except the root, has a uniquw *parent*
|
- Each node, except the root, has a unique *parent*
|
||||||
- Any chain that moves from a mnode to its parent , its grandparent etc, eventually reaches the root.
|
- Any chain that moves from a mnode to its parent , its grandparent etc, eventually reaches the root.
|
||||||
- The *children* of a nore arll the nodes of which it is the parent
|
- The *children* of a nore arll the nodes of which it is the parent
|
||||||
- Nodes may (and usually do) have additional data associated to them. (does not affect the structure)
|
- Nodes may (and usually do) have additional data associated to them. (does not affect the structure)
|
||||||
|
|||||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user