update
BIN
content/Attachments/lofi-prototypes/friends-1.JPG
Normal file
|
After Width: | Height: | Size: 2.8 MiB |
BIN
content/Attachments/lofi-prototypes/general-1.JPG
Normal file
|
After Width: | Height: | Size: 2.4 MiB |
BIN
content/Attachments/lofi-prototypes/general-2.JPG
Normal file
|
After Width: | Height: | Size: 2.8 MiB |
BIN
content/Attachments/lofi-prototypes/general-3.JPG
Normal file
|
After Width: | Height: | Size: 2.7 MiB |
BIN
content/Attachments/lofi-prototypes/general-4.JPG
Normal file
|
After Width: | Height: | Size: 2.7 MiB |
BIN
content/Attachments/lofi-prototypes/home-1.JPG
Normal file
|
After Width: | Height: | Size: 2.9 MiB |
BIN
content/Attachments/lofi-prototypes/home-2.jpg
Normal file
|
After Width: | Height: | Size: 2.1 MiB |
BIN
content/Attachments/lofi-prototypes/home-3.jpg
Normal file
|
After Width: | Height: | Size: 2.0 MiB |
BIN
content/Attachments/lofi-prototypes/navigation.JPG
Normal file
|
After Width: | Height: | Size: 2.7 MiB |
BIN
content/Attachments/lofi-prototypes/other-settings-1.JPG
Normal file
|
After Width: | Height: | Size: 2.3 MiB |
BIN
content/Attachments/lofi-prototypes/schedule-1.JPG
Normal file
|
After Width: | Height: | Size: 1.6 MiB |
BIN
content/Attachments/lofi-prototypes/trick-options-1.JPG
Normal file
|
After Width: | Height: | Size: 1.8 MiB |
BIN
content/Attachments/lofi-prototypes/welcome-1.JPG
Normal file
|
After Width: | Height: | Size: 1.8 MiB |
BIN
content/Attachments/personas/kyle
Normal file
|
After Width: | Height: | Size: 410 KiB |
31
content/daily_notes/2022-05-11.md
Normal file
@ -0,0 +1,31 @@
|
||||
[2022-05-10](daily_notes/2022-05-10) << [daily-notes](notes/daily-notes.md) >> [2022-05-12](daily_notes/2022-05-12)
|
||||
|
||||
---
|
||||
# 11-05-22
|
||||
[Rising Above Bedlam - Jah Wobble's Invaders Of The Heart](spotify:album:2TXvjVOhfNjAYpRpODqmVb)
|
||||

|
||||
|
||||
|
||||
## Todos
|
||||
- [ ] 12:00 Info201 Lab 8
|
||||
- [ ] Info201 Lecture 14
|
||||
- [ ] Info201 Lecture 18
|
||||
- [ ] info 202 api's lecture
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
- [ ] 10:00 Info203 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
|
||||
## Lecture/Labs
|
||||
- [ ] 10:00 Info203 Lecture
|
||||
- [ ] 16:00 Cosc201 Tutorial
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
34
content/daily_notes/2022-05-12.md
Normal file
@ -0,0 +1,34 @@
|
||||
[2022-05-11](daily_notes/2022-05-11) << [daily-notes](notes/daily-notes.md) >> [2022-05-13](daily_notes/2022-05-13)
|
||||
|
||||
---
|
||||
# 12-05-22
|
||||
[Darklands - The Jesus And Mary Chain](spotify:album:1vtsYpapUeoDNMJOWRql9b)
|
||||

|
||||
|
||||
## Todos
|
||||
- [ ] 12:00 Info201 Lab 8
|
||||
- [ ] Info201 Lecture 14
|
||||
- [x] Info201 Lecture 18
|
||||
- [ ] info 202 api's lecture
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
- [ ] 10:00 Info203 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] 10:00 Info203 Lecture
|
||||
- [ ] 16:00 Cosc201 Tutorial
|
||||
|
||||
## Lecture/Labs
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] 12:00 Info203 Tutorial
|
||||
- [ ] 16:00 Info201 Lecture
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
37
content/daily_notes/2022-05-13.md
Normal file
@ -0,0 +1,37 @@
|
||||
[2022-05-12](daily_notes/2022-05-12) << [daily-notes](notes/daily-notes.md) >> [2022-05-14](daily_notes/2022-05-14)
|
||||
|
||||
---
|
||||
# 13-05-22
|
||||
[Darkness on the Edge of Town - Bruce Springsteen](spotify:album:4KT6G8fj8EEIfsyr75hbgc)
|
||||

|
||||
|
||||
|
||||
## Todos
|
||||
- [ ] Cosc201 lab
|
||||
- [ ] Cosc201 Lab
|
||||
- [ ] Info203 Lecture
|
||||
- [ ] Info203 Lecture
|
||||
- [ ] Info201 Lab 8
|
||||
- [ ] Info201 Lecture
|
||||
- [ ] Info201 Lecture 14
|
||||
- [ ] Info201 Lecture
|
||||
- [x] Cosc202 Lecture
|
||||
- [ ] cosc 202 api's lecture
|
||||
- [ ] Cosc202 Lecture
|
||||
|
||||
## Lecture/Labs
|
||||
- [x] 09:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
|
||||
|
||||
|
||||
33
content/daily_notes/2022-05-14.md
Normal file
@ -0,0 +1,33 @@
|
||||
[2022-05-13](daily_notes/2022-05-13) << [daily-notes](notes/daily-notes.md) >> [2022-05-15](daily_notes/2022-05-15)
|
||||
|
||||
---
|
||||
# 14-05-22
|
||||
[The Who Sell Out - The Who](spotify:album:2nbxElNcpz1C8LudsOW3ZH)
|
||||

|
||||
|
||||
|
||||
## Todos
|
||||
- [ ] Cosc201 lab
|
||||
- [ ] Cosc201 Lab
|
||||
- [ ] Info203 Lecture
|
||||
- [ ] Info203 Lecture
|
||||
- [ ] Info201 Lab 8
|
||||
- [ ] Info201 Lecture
|
||||
- [ ] Info201 Lecture 14
|
||||
- [ ] Info201 Lecture
|
||||
- [ ] cosc 202 api's lecture
|
||||
- [ ] Cosc202 Lecture
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
33
content/daily_notes/2022-05-15.md
Normal file
@ -0,0 +1,33 @@
|
||||
[2022-05-14](daily_notes/2022-05-14) << [daily-notes](notes/daily-notes.md) >> [2022-05-16](daily_notes/2022-05-16)
|
||||
|
||||
---
|
||||
# 15-05-22
|
||||
[Rust Never Sleeps - Neil Young & Crazy Horse](spotify:album:5m2MQk77aAXPhwI6Ges8X5)
|
||||

|
||||
|
||||
|
||||
## Todos
|
||||
- [ ] Cosc201 lab
|
||||
- [ ] Cosc201 Lab
|
||||
- [ ] Info203 Lecture
|
||||
- [ ] Info203 Lecture
|
||||
- [ ] Info201 Lab 8
|
||||
- [ ] Info201 Lecture
|
||||
- [ ] Info201 Lecture 14
|
||||
- [ ] Info201 Lecture
|
||||
- [ ] cosc 202 api's lecture
|
||||
- [ ] Cosc202 Lecture
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
44
content/daily_notes/2022-05-16.md
Normal file
@ -0,0 +1,44 @@
|
||||
[2022-05-15](daily_notes/2022-05-15) << [daily-notes](notes/daily-notes.md) >> [2022-05-17](daily_notes/2022-05-17)
|
||||
|
||||
---
|
||||
# 16-05-22
|
||||
[The Specials - The Specials](spotify:album:7kHtInr7Es2tPk5QJO6y6c)
|
||||

|
||||
|
||||
## Today
|
||||
- [x] Cosc201 lab 11
|
||||
- [x] 11:00 Cosc201 Lecture graphs
|
||||
- [x] Info201 Lab 9
|
||||
- [x] Info201 Lab 8
|
||||
- [x] Info201 Lecture 19 sql part 2
|
||||
- [x] Info203 Lecture
|
||||
- [x] Info203 Lecture
|
||||
- [x] 1hr 203 work
|
||||
|
||||
100%
|
||||
|
||||
## Backlog
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Info201 Lab 3
|
||||
- [ ] Info201 Lab 4
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lab 10
|
||||
- [ ] Info201 Lab 11
|
||||
- [ ] Info201 Lecture 20 database
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] cosc 202 api's lecture
|
||||
- [ ] Cosc202 Lecture
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Lecture/Labs
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab 13
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
42
content/daily_notes/2022-05-17.md
Normal file
@ -0,0 +1,42 @@
|
||||
-[2022-05-16](daily_notes/2022-05-16) << [daily-notes](notes/daily-notes.md) >> [2022-05-18](daily_notes/2022-05-18)
|
||||
|
||||
---
|
||||
# 17-05-22
|
||||
[Black Sabbath - Black Sabbath](spotify:album:2T6jeELx5BqH4GMLObBy10)
|
||||

|
||||
|
||||
## Today
|
||||
- [ ] 10:00 Info203 Lecture
|
||||
- [x] 1hr ass work
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [x] Info201 Lecture 20 database
|
||||
- [x] Info201 Lab 10
|
||||
- [x] Cosc202 Lecture
|
||||
- [x] some 202 work
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] Info201 Lab 3
|
||||
- [ ] Info201 Lab 4
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lab 11
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc 202 api's lecture
|
||||
- [ ] Cosc202 Lab 19
|
||||
- [ ] Cosc201 lab 13
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
43
content/daily_notes/2022-05-18.md
Normal file
@ -0,0 +1,43 @@
|
||||
[2022-05-17](daily_notes/2022-05-17) << [daily-notes](notes/daily-notes.md) >> [2022-05-19](daily_notes/2022-05-19)
|
||||
|
||||
---
|
||||
# 18-05-22
|
||||
[Floodland - Sisters Of Mercy](spotify:album:2I5WCmOZo17YkcEwjXbLvc)
|
||||

|
||||
|
||||
## Today
|
||||
- [ ] 10:00 Info203 Lecture
|
||||
- [ ] 10:00 Info203 Lectur vc dbe
|
||||
- [x] Cosc201 Lecture
|
||||
- [ ] Cosc 202 api's lecture
|
||||
- [x] Info201 Lab 3
|
||||
- [ ] 1hr ass work
|
||||
- [x] review today
|
||||
- [x] review extra
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 lab 13
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] Info201 Lab 4
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lab 11
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
- weather api in daily note
|
||||
- drop shipping site
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
39
content/daily_notes/2022-05-19.md
Normal file
@ -0,0 +1,39 @@
|
||||
[2022-05-18](daily_notes/2022-05-18) << [daily-notes](notes/daily-notes.md) >> [2022-05-20](daily_notes/2022-05-20)
|
||||
|
||||
---
|
||||
# 19-05-22
|
||||
[New York Dolls - New York Dolls](spotify:album:2xbTV0Awe4Qm5caUVuPbMr)
|
||||

|
||||
|
||||
## Today
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [x] Info201 Lecture 21
|
||||
- [x] Cosc 202 api's lecture
|
||||
- [x] Info201 Lab 4
|
||||
- [ ] review
|
||||
- [x] 202 work
|
||||
- [x] 10:00 Info203 Lecture
|
||||
- [x] 2 hr ass work
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] Info203 Lectures x2
|
||||
- [ ] Info201 Lecture 22
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
42
content/daily_notes/2022-05-20.md
Normal file
@ -0,0 +1,42 @@
|
||||
[2022-05-19](daily_notes/2022-05-19) << [daily-notes](notes/daily-notes.md) >> [2022-05-21](daily_notes/2022-05-21)
|
||||
|
||||
---
|
||||
# 20-05-22
|
||||
[Highway to Hell - AC/DC](spotify:album:10v912xgTZbjAtYfyKWJCS)
|
||||

|
||||
|
||||
AAPL : 137.44
|
||||
SP500 : 3900.79
|
||||
TSLA : 709.42
|
||||
|
||||
## Today
|
||||
- [ ] 09:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
- [ ] review
|
||||
- [ ] email about labs c201
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] review
|
||||
- [ ] Info203 Lectures x2
|
||||
- [ ] Info201 Lecture 22
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
43
content/daily_notes/2022-05-21.md
Normal file
@ -0,0 +1,43 @@
|
||||
[2022-05-20](daily_notes/2022-05-20) << [daily-notes](notes/daily-notes.md) >> [2022-05-22](daily_notes/2022-05-22)
|
||||
|
||||
---
|
||||
# 21-05-22
|
||||
[The Age Of The Understatement - The Last Shadow Puppets](spotify:album:2y3Rm0cT1xbf2NoTQwKv99)
|
||||

|
||||
|
||||
AAPL : 137.64
|
||||
SP500 : 3901.36
|
||||
TSLA : 663.9
|
||||
|
||||
## Today
|
||||
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 09:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
- [ ] review
|
||||
- [ ] email about labs c201
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] review
|
||||
- [ ] Info203 Lectures x2
|
||||
- [ ] Info201 Lecture 22
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
37
content/daily_notes/2022-05-22.md
Normal file
@ -0,0 +1,37 @@
|
||||
[2022-05-21](daily_notes/2022-05-21) << [daily-notes](notes/daily-notes.md) >> [2022-05-23](daily_notes/2022-05-23)
|
||||
|
||||
---
|
||||
# 22-05-22
|
||||
[ - ](spotify:album:)
|
||||

|
||||
|
||||
AAPL : 137.59
|
||||
SP500 : 3901.36
|
||||
TSLA : 663.9
|
||||
|
||||
## Today
|
||||
- [x] Info203 Lectures x2
|
||||
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 follow up email about labs
|
||||
- [ ] Info201 Lecture 22 performance and security
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lecture 21 optimisation
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
37
content/daily_notes/2022-05-23.md
Normal file
@ -0,0 +1,37 @@
|
||||
[2022-05-22](daily_notes/2022-05-22) << [daily-notes](notes/daily-notes.md) >> [2022-05-24](daily_notes/2022-05-24)
|
||||
|
||||
---
|
||||
# 23-05-22
|
||||
[Q: Are We Not Men? A: We Are Devo - Devo](spotify:album:1u2Qni8cVRptDTaA00fmBC)
|
||||

|
||||
|
||||
AAPL : 137.59
|
||||
SP500 : 3901.36
|
||||
TSLA : 663.9
|
||||
|
||||
## Today
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 follow up email about labs
|
||||
- [ ] Info201 Lecture 22 performance and security
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lecture 21 optimisation
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
41
content/daily_notes/2022-05-24.md
Normal file
@ -0,0 +1,41 @@
|
||||
[2022-05-23](daily_notes/2022-05-23) << [daily-notes](notes/daily-notes.md) >> [2022-05-25](daily_notes/2022-05-25)
|
||||
|
||||
---
|
||||
# 24-05-22
|
||||
[Q: Are We Not Men? A: We Are Devo - Devo](spotify:album:1u2Qni8cVRptDTaA00fmBC)
|
||||

|
||||
|
||||
AAPL : 143.11
|
||||
SP500 : 3973.75
|
||||
TSLA : 674.9
|
||||
|
||||
## Today
|
||||
- [x] 10:00 Info203 Lecture
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 follow up email about labs
|
||||
- [ ] Info201 Lecture 22 performance and security
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lecture 21 optimisation
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
42
content/daily_notes/2022-05-25.md
Normal file
@ -0,0 +1,42 @@
|
||||
[2022-05-24](daily_notes/2022-05-24) << [daily-notes](notes/daily-notes.md) >> [2022-05-26](daily_notes/2022-05-26)
|
||||
|
||||
---
|
||||
# 25-05-22
|
||||
[Playing With Fire - Spacemen 3](spotify:album:0Ju8YUtJB0RMw8NZXgXe6n)
|
||||

|
||||
|
||||
AAPL : 140.48
|
||||
SP500 : 3941.48
|
||||
TSLA : 628.16
|
||||
|
||||
## Today
|
||||
- [x]] 10:00 Info203 Lecture
|
||||
- [ ] 16:00 Cosc201 Tutorial
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 follow up email about labs
|
||||
- [ ] Info201 Lecture 22 performance and security
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lecture 21 optimisation
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
47
content/daily_notes/2022-05-26.md
Normal file
@ -0,0 +1,47 @@
|
||||
|
||||
|
||||
[2022-05-25](daily_notes/2022-05-25) << [daily-notes](notes/daily-notes.md) >> [2022-05-27](daily_notes/2022-05-27)
|
||||
|
||||
---
|
||||
# 26-05-22
|
||||
[Sweet Baby James - James Taylor](spotify:album:2NEQ5Q4sBbUHVVx3Wf8TEZ)
|
||||

|
||||
|
||||
AAPL : 140.38
|
||||
SP500 : 3978.73
|
||||
TSLA : 658.8
|
||||
|
||||
## Today
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] 12:00 Info203 Tutorial
|
||||
- [ ] 16:00 Info201 Lecture
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 16:00 Cosc201 Tutorial
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 follow up email about labs
|
||||
- [ ] Info201 Lecture 22 performance and security
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lecture 21 optimisation
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
48
content/daily_notes/2022-05-27.md
Normal file
@ -0,0 +1,48 @@
|
||||
[2022-05-26](daily_notes/2022-05-26) << [daily-notes](notes/daily-notes.md) >> [2022-05-28](daily_notes/2022-05-28)
|
||||
|
||||
---
|
||||
# 27-05-22
|
||||
[Exile On Main Street - The Rolling Stones](spotify:album:5dBQ20ppdPxo5bqkoeTKnN)
|
||||

|
||||
|
||||
AAPL : 143.75
|
||||
SP500 : 4057.84
|
||||
TSLA : 707.73
|
||||
|
||||
## Today
|
||||
- [ ] 09:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
|
||||
# Review
|
||||
```dataview
|
||||
list from #lecture where sr-due = date(today)
|
||||
```
|
||||
|
||||
## Backlog
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] 12:00 Info203 Tutorial
|
||||
- [ ] 16:00 Info201 Lecture
|
||||
- [ ] 16:00 Cosc201 Tutorial
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 lab
|
||||
- [ ] Cosc201 Lab 12
|
||||
- [ ] Cosc201 follow up email about labs
|
||||
- [ ] Info201 Lecture 22 performance and security
|
||||
- [ ] Info201 Lab 7
|
||||
- [ ] Info201 Lecture 14 activity and state diagrams
|
||||
- [ ] Cosc202 Lecture 21 optimisation
|
||||
- [ ] Cosc202 Lab 19
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
- spotify clone
|
||||
|
||||
## Links
|
||||
- [202 lab book](C:\Users\Jet%20Hughes\Documents\Personal\COSC202LabBook-2.pdf)
|
||||
- [i201 cousework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [i201 Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
|
||||
14
content/notes/02-version-control-system.md
Normal file
@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "02-version-control-system"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-29
|
||||
sr-interval: 9
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[git](notes/git.md)
|
||||
|
||||
[VCS](notes/version-control-systems.md)
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "04-evaluation-methods-birth-of-hci"
|
||||
sr-due: 2022-05-22
|
||||
sr-interval: 40
|
||||
sr-due: 2022-08-22
|
||||
sr-interval: 92
|
||||
sr-ease: 230
|
||||
aliases:
|
||||
tags:
|
||||
@ -17,4 +17,4 @@ Possible exam questions
|
||||
- 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!
|
||||
- Describe the different characteristics of quantitative and qualitative measurements in HCI!
|
||||
|
||||
@ -3,8 +3,8 @@ title: "06-business-functions-and-use-cases"
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-04
|
||||
sr-interval: 17
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
@ -12,12 +12,20 @@ sr-ease: 270
|
||||
|
||||
1. What are the two main approaches to systems development and how do they differ
|
||||
|
||||
- object oriented - system is a collection of objects
|
||||
- tranditional - system is a collectin of processes
|
||||
|
||||
[business-functions](notes/business-functions.md)
|
||||
|
||||
2. What are business functions
|
||||
|
||||
things that a business *ought* to be doing not who, how, structure, tech
|
||||
|
||||
3. What is a use case
|
||||
an interaction between a role and a system to achieve a goal
|
||||
|
||||
4. What is a use case diagram used for
|
||||
a high level descruption of how people interact with a system
|
||||
|
||||
[use-case-diagrams](notes/use-case-diagrams.md)
|
||||
|
||||
|
||||
@ -3,8 +3,8 @@ title: "07-heuristic-evaluation-cont"
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-02
|
||||
sr-interval: 15
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
|
||||
@ -3,11 +3,11 @@ title: "07-testing"
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-18
|
||||
sr-interval: 8
|
||||
|
||||
sr-due: 2022-06-9
|
||||
sr-interval: 22
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
- [testing](notes/testing.md)
|
||||
- [test-driven-development](notes/test-driven-development.md)
|
||||
- [unit-testing](notes/unit-testing.md)
|
||||
@ -18,3 +18,15 @@ sr-ease: 270
|
||||
- explain how unit tests ar developed
|
||||
- indicate how languages integreate unit test support
|
||||
- apppreiciate limitation of software testing
|
||||
|
||||
# Flash cards
|
||||
## Testing
|
||||
what are unit tests::Testing individual pieces of code <!--SR:!2022-5-521,3,270-->
|
||||
what are integration tests::tests checking that code works together <!--SR:!2022-5-521,3,270-->
|
||||
what are end-to-end tests::tests that check the behaviour of the while program <!--SR:!2022-5-521,3,270-->
|
||||
what is the halting problem::you cant fully analyse code using code <!--SR:!2022-5-521,3,270-->
|
||||
|
||||
## TDD
|
||||
what is TDD::a software dev. methodology where tests are written before code <!--SR:!2022-5-521,3,270-->
|
||||
|
||||
## Unit testing
|
||||
|
||||
@ -1,11 +1,11 @@
|
||||
---
|
||||
title: "08-business-patterns"
|
||||
sr-due: 2022-05-19
|
||||
sr-interval: 37
|
||||
sr-due: 2022-08-27
|
||||
sr-interval: 100
|
||||
sr-ease: 270
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
---
|
||||
|
||||
[entity-relationship-diagrams](notes/entity-relationship-diagrams.md)
|
||||
[entity-relationship-diagrams](notes/entity-relationship-diagrams.md)
|
||||
|
||||
@ -3,9 +3,10 @@ title: "08-debugging"
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-03
|
||||
sr-interval: 16
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[debugging](notes/debugging.md)
|
||||
|
||||
|
||||
@ -3,11 +3,19 @@ title: "09-data-modelling-and-normalisation"
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 9
|
||||
sr-due: 2022-06-18
|
||||
sr-interval: 31
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
- [redundancy-and-anomalies](notes/redundancy-and-anomalies.md)
|
||||
- [dependencies](notes/dependencies.md)
|
||||
|
||||
wia functional dependecy::when some attribute has exactly one associated other attribute
|
||||
wia transitive dependency:: A→B, B→C [Transitive dependency](notes/dependencies.md#Transitive%20dependency) <!--SR:!2022-5-521,3,250-->
|
||||
wia partial dependency:: when a subset of the left determines the right<!--SR:!2022-5-521,3,250-->
|
||||
wia multivalued dependency::when something has a set of associated values of another attribute
|
||||
|
||||
- [normalisation](notes/normalisation.md)
|
||||
|
||||
what is normalisation::formal process of eliminanting unnecessary redundancy in relations by splitting relations into smaller chunks
|
||||
@ -8,4 +8,4 @@ sr-interval: 28
|
||||
sr-ease: 290
|
||||
---
|
||||
|
||||
[documentation](notes/documentation.md)
|
||||
[documentation](notes/documentation.md)
|
||||
|
||||
@ -3,11 +3,13 @@ title: "09-stacks-queues-heaps"
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-12
|
||||
sr-interval: 2
|
||||
sr-due: 2022-05-29
|
||||
sr-interval: 11
|
||||
sr-ease: 210
|
||||
---
|
||||
|
||||
- [stacks-and-queues](notes/stacks-and-queues.md)
|
||||
- [dynamic-linear-datatype](notes/dynamic-linear-datatype.md)
|
||||
- [Stack](notes/dynamic-linear-datatype.md#Stack)
|
||||
- [Queue](notes/dynamic-linear-datatype.md#Queue)
|
||||
- [priority-queue](notes/priority-queue.md)
|
||||
- [heap](notes/heap.md)
|
||||
- [heap](notes/heap.md)
|
||||
|
||||
@ -16,4 +16,4 @@ sr-ease: 250
|
||||
4. understand implications of CI running asynchronously
|
||||
5. Exlplain how to manage output from CI jobs
|
||||
6. describe role of stages and jobs within gitlab pipelines
|
||||
7. indicate how CI specifications are stored
|
||||
7. indicate how CI specifications are stored
|
||||
|
||||
@ -3,8 +3,8 @@ title: "10-design-heuristics-1"
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-03
|
||||
sr-interval: 16
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
@ -21,11 +21,10 @@ create multiple ideas in parallel rather than one after the other
|
||||

|
||||
|
||||
## Functional fixation
|
||||
|
||||
This is when you get tunnel vision about some design. This causes you to not consider other possible alternatives.
|
||||
|
||||
For example with nail problem, almost nobody consider using the nails it the way that is needed.
|
||||

|
||||
|
||||
## 4 Design heuristics
|
||||
|
||||
[design-heuristics](notes/design-heuristics.md)
|
||||
|
||||
@ -98,4 +98,4 @@ Merge is preferred because
|
||||
|
||||
extra memory cost of merge sort is negligible
|
||||
|
||||
∴ Merge sort is faster
|
||||
∴ Merge sort is faster
|
||||
|
||||
@ -3,8 +3,8 @@ title: "10-oop-concepts-and-uml"
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-05
|
||||
sr-interval: 18
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
@ -13,4 +13,4 @@ sr-ease: 270
|
||||
3. give an example of how difference UML diagram types can be linked when modelling a system
|
||||
|
||||
- [object](notes/object.md)
|
||||
- [unified-modelling-language](notes/unified-modelling-language.md)
|
||||
- [unified-modelling-language](notes/unified-modelling-language.md)
|
||||
|
||||
@ -9,4 +9,4 @@ sr-interval: 75
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
[class-diagrams](notes/class-diagrams.md)
|
||||
[class-diagrams](notes/class-diagrams.md)
|
||||
|
||||
@ -15,4 +15,4 @@ tags:
|
||||
5. Describe a way in which CI scripts scan handle secrets
|
||||
6. Outline uses of local git hook scripts
|
||||
|
||||
[continuous integration](notes/continuous-integration.md)
|
||||
[continuous integration](notes/continuous-integration.md)
|
||||
|
||||
@ -8,8 +8,8 @@ sr-interval: 33
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
A [set](notes/set.md) is :: a collection of elements with no repetition allowed <!--SR:!2022-04-15,3,270-->
|
||||
A [set](notes/set.md) is :: a collection of elements with no repetition allowed <!--SR:!2022-5-527,9,250-->
|
||||
|
||||
A [hash-map](notes/hash-map.md) is :: a set of key value pairs <!--SR:!2022-04-15,3,270-->
|
||||
A [hash-map](notes/hash-map.md) is :: a set of key value pairs <!--SR:!2022-5-526,8,250-->
|
||||
|
||||
A [tree](notes/tree.md) is :: a general concept of a way of organising data. <!--SR:!2022-04-15,3,270-->
|
||||
A [tree](notes/tree.md) is :: a general concept of a way of organising data. <!--SR:!2022-5-528,10,250-->
|
||||
|
||||
@ -104,4 +104,4 @@ Spreadsheets allow a mix of pattern (using formula) and exceptions (overriding f
|
||||
|
||||
For example. each row is a command invocation. Columns build up command's invocation, including formulae. Then use concatenate function to join text from other columns. And copy and paste the rows into your shell
|
||||
|
||||
This is useful for idempotent commands. i.e., change happens once. As nothing bad will happen if a command is run twice
|
||||
This is useful for idempotent commands. i.e., change happens once. As nothing bad will happen if a command is run twice
|
||||
|
||||
@ -10,4 +10,4 @@ sr-ease: 270
|
||||
|
||||
Recall [binary-search-tree](notes/binary-search-tree.md)
|
||||
|
||||
[binary search tree operations](notes/bst-operations.md)
|
||||
[binary search tree operations](notes/bst-operations.md)
|
||||
|
||||
@ -3,8 +3,8 @@ title: "12-design-heuristics-3"
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-20
|
||||
sr-interval: 27
|
||||
sr-due: 2022-08-06
|
||||
sr-interval: 78
|
||||
sr-ease: 290
|
||||
---
|
||||
|
||||
|
||||
@ -17,9 +17,9 @@ sr-ease: 250
|
||||
- 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.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
@ -64,7 +64,7 @@ e.g.,
|
||||
|
||||
- Search specifies a set of common behaviour.
|
||||
- public methods and constant fields only (no variable fields)
|
||||
- effectively an “inheritable” public API (no implementation) ⇒ Catalogue must implement all Search methods
|
||||
- effectively an “inheritable� public API (no implementation) ⇒ Catalogue must implement all Search methods
|
||||
- independent of inheritance via specialisation
|
||||
- a class can implement multiple interfaces
|
||||
- Things that know how to use Search will also accept Catalogue.
|
||||
@ -82,7 +82,7 @@ e.g.,
|
||||
|
||||
- The public API defines what a class can do
|
||||
- e.g., read and write data, manage a list of items
|
||||
- effectively a “promise” or “contract” to other classes that use it
|
||||
- effectively a “promise� or “contract� to other classes that use it
|
||||
- should be as stable as possible
|
||||
|
||||
- The private implementation defines how a class behaves
|
||||
@ -142,7 +142,7 @@ Anything coded to work with Collection will accept *any* Java collection type. (
|
||||
|
||||
## 3.1 Rich domain models
|
||||
|
||||
- True OO involves sending objects “native instructions” beyond basic getter/setter methods:
|
||||
- True OO involves sending objects “native instructions� beyond basic getter/setter methods:
|
||||
- e.g., they can save, display, update, validate, etc., themselves
|
||||
- often requires communicating with other objects
|
||||
- Advantages:
|
||||
@ -150,9 +150,9 @@ Anything coded to work with Collection will accept *any* Java collection type. (
|
||||
- methods are highly cohesive (focused)
|
||||
- natural fit with programming to an interface
|
||||
- Disadvantages:
|
||||
- many “chicken and egg” situations ⇒ harder to use
|
||||
- many “chicken and egg� situations ⇒ harder to use
|
||||
- bordering on taking things too far (too much abstraction)
|
||||
- well beyond comfort zone of many developers (“exotic”)
|
||||
- well beyond comfort zone of many developers (“exotic�)
|
||||
|
||||
### 3.1.1 Rich domain example: Library system
|
||||
|
||||
@ -161,13 +161,13 @@ Anything coded to work with Collection will accept *any* Java collection type. (
|
||||
|
||||
## 3.2 Contrast with anaemic domain models
|
||||
|
||||
- Objects have relatively little “native” behaviour: (if any)
|
||||
- Objects have relatively little “native� behaviour: (if any)
|
||||
- mostly just state
|
||||
- don’t inherit from anything else (class or interface)
|
||||
- getters/setters don’t really encapsulate much
|
||||
- methods manipulate only internal state (no external communication)
|
||||
- generally referred to as JavaBeans in Java (also POJO)
|
||||
- Require a lot of “plumbing” code to shift data into and out of objects so we can do something useful with it.
|
||||
- Require a lot of “plumbing� code to shift data into and out of objects so we can do something useful with it.
|
||||
- De facto standard for most programmers/systems
|
||||
|
||||

|
||||
@ -182,8 +182,8 @@ Anything coded to work with Collection will accept *any* Java collection type. (
|
||||
- shipping (sub)system
|
||||
- inventory (sub)system
|
||||
- …
|
||||
- “Processor objects” can encapsulate these interactions:
|
||||
- effectively “(sub)system APIs” that group related behaviour
|
||||
- “Processor objects� can encapsulate these interactions:
|
||||
- effectively “(sub)system APIs� that group related behaviour
|
||||
- either classes or (Java) interfaces, as appropriate
|
||||
- methods take relevant domain objects as arguments
|
||||
- Third-party frameworks can reduce the amount of code you need to write even further. (see INFO 202)
|
||||
@ -196,6 +196,6 @@ Anything coded to work with Collection will accept *any* Java collection type. (
|
||||
- Behaviour can be inherited directly via specialisation, or indirectly by implementing an interface.
|
||||
- interfaces decouple public API from private implementation
|
||||
- programming to an interface
|
||||
- Domain models can be “rich” or “anaemic”.
|
||||
- Domain models can be “rich� or “anaemic�.
|
||||
- anaemic more common
|
||||
- use “processors” to encapsulate “plumbing” code
|
||||
- use “processors� to encapsulate “plumbing� code
|
||||
|
||||
@ -4,129 +4,10 @@ aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-18
|
||||
sr-interval: 25
|
||||
sr-due: 20220725
|
||||
sr-interval: 68
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
# Traversals
|
||||
- in any tree
|
||||
- preorder --> visit the root, then for each child of the root, predorder teaverse the subtree rooted at that child
|
||||
- postorder --> for each child of the root posrtorser traverse the subtreeet rooted at that child, then visit the root
|
||||
- level order --> visit the root, then all its children , then all its granchildren
|
||||
- in BSTs only:
|
||||
- inorder --> inorder traverse the subtree rooted at the lefdt cyhild then visit the root, then inorder traverse the subtree rooted at the right child
|
||||
|
||||
## code
|
||||
- returns the perorder tracersal as an arraylist
|
||||
- not usual, traversals are genrally ideas used in algorithms, not independent methods
|
||||
|
||||
### pre post and in order traversal code
|
||||
```java
|
||||
public ArrayList<String> order() {
|
||||
ArrayList<String> result = new Arraylist<>(); //set up the result
|
||||
preorder(root, result); //preorder starting at the root
|
||||
postorder(root, result);
|
||||
inorder(root, result);
|
||||
return result;
|
||||
}
|
||||
|
||||
//helper method for preorder traversal
|
||||
//use r as working storage to preorder traverse the tree below n
|
||||
private void preorder(Node n, ArrayList<String> r){
|
||||
if(n==null) return;
|
||||
r.add(n.key); //add this node the reults
|
||||
preorder(n.left, r); //traverse the left subtree
|
||||
preorder(r.right, r); //traverse the right subtree
|
||||
}
|
||||
|
||||
//helper method for preorder traversal
|
||||
//use r as working storage to preorder traverse the tree below n
|
||||
private void inorder(Node n, ArrayList<String> r){
|
||||
if(n==null) return;
|
||||
inorder(n.left, r); //traverse the left subtree
|
||||
r.add(n.key); //add this node the reults
|
||||
inorder(r.right, r); //traverse the right subtree
|
||||
}
|
||||
|
||||
//helper method for preorder traversal
|
||||
//use r as working storage to preorder traverse the tree below n
|
||||
private void postorder(Node n, ArrayList<String> r){
|
||||
if(n==null) return;
|
||||
postorder(n.left, r); //traverse the left subtree
|
||||
postorder(r.right, r); //traverse the right subtree
|
||||
r.add(n.key); //add this node the reults
|
||||
}
|
||||
```
|
||||
|
||||

|
||||
|
||||
### level order
|
||||
- want to visit the root
|
||||
- visit its children
|
||||
- visit their children
|
||||
- etc
|
||||
|
||||
not recursive
|
||||
maintain a queue of pending visits
|
||||
|
||||
```
|
||||
if root = nil then return []
|
||||
|
||||
res <- [], q <- [root]
|
||||
while q is not empty do
|
||||
n <- q.remove()
|
||||
res.add(n)
|
||||
for c in n.children do
|
||||
q.add(c)
|
||||
end for
|
||||
end while
|
||||
return res
|
||||
```
|
||||
|
||||
```java
|
||||
public Arraylist<String> levelorder() {
|
||||
ArrayList<String> result = new ArrayList<>();
|
||||
if(isEmpty()) return result;
|
||||
ArrayDeque<Node> q = new ArrayDeque<>();
|
||||
q.add(root)
|
||||
while (!q.isEmpty()) {
|
||||
Node n = q.remove()
|
||||
result.add(n.key);
|
||||
if(n.left != null) q.add(n.left);
|
||||
if(n.right != null) q.add(n.right);
|
||||
}
|
||||
return result;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
if we use a stack then its the same as preorder.
|
||||
|
||||
# Balancing trees
|
||||
long branches are a problem
|
||||
the performance bounds for all BST operations are linear of the length of the longest branch of the tree
|
||||
|
||||
ideal shape is a similar to a heap (wide and shallow).
|
||||
|
||||
we want the longest branch to be $\theta(lg\ n)$
|
||||
|
||||
|
||||
one way is to do an iorder traversal and save to a sorted array. then construct a new tree by repeatedly bisecting the array. and recursively building the left and right subtrees
|
||||
|
||||
need some local operation that helps to restore balance
|
||||
|
||||
## Rotation operation
|
||||
|
||||
suppose that in this bst there is a longer chain in e than else where
|
||||
|
||||

|
||||
|
||||
imagine twisting d to be the root
|
||||
|
||||

|
||||
|
||||
changes are
|
||||
- b's right child is now c
|
||||
- d's left child is not b
|
||||
- b parent now points to d
|
||||
[tree-traversal](notes/tree-traversal.md)
|
||||
[balancing-binary-search-trees](notes/balancing-binary-search-trees.md)
|
||||
@ -1,101 +1,19 @@
|
||||
---
|
||||
title: "13-code-librarires"
|
||||
aliases: code libraries, libraries, software library
|
||||
aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-25
|
||||
sr-interval: 30
|
||||
sr-due: 2022-08-14
|
||||
sr-interval: 81
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
# what is a software library
|
||||
|
||||
- collections of potentailly useful code.
|
||||
- implement comon fuunctionality so you dont have to
|
||||
- e.g.,
|
||||
- music processign
|
||||
- game engines
|
||||
- etc.
|
||||
|
||||
- languages may include standard libraries
|
||||
- *standard library* is one that is always available within a language
|
||||
- e.g., Java standard library
|
||||
- these make up only a small part of the broader available library functionality
|
||||
|
||||
|
||||
# Pros and cons of libraries
|
||||
|
||||
- utf-8 conversion tables and collation schemes
|
||||
- e.g., for comparing equality of e.g., 'Māori' and 'Maori'.
|
||||
- this equality depends on the 'collation' scheme that is being used
|
||||
- conversion tables and collations are need for all known languages
|
||||
- it is good to not have to rewite these for each piece of software
|
||||
- just use a library
|
||||
|
||||
- library code quality
|
||||
- well written libraries can propogate great benefits
|
||||
- econoomies of scale from reusilng good implementations
|
||||
- somebody needs to pay for the develp ment of the library
|
||||
- needs to be maintained
|
||||
- There is a downside - code homogeneity
|
||||
- all programs using the same library carry the same security bugs
|
||||
- if you dont know the librar;y in detail you may not be able to fully utilise it
|
||||
|
||||
- deep experience libraries
|
||||
- intel creates libraries that utilise their CPUs the best
|
||||
- they dont have to wait for library to be made that fully utilises their hardware
|
||||
-
|
||||
|
||||
# understand trasitive dependencies in libraries
|
||||
https://xkcd.com/2347/
|
||||
|
||||
libraries rely on other libraries. These are called transitive dependencies.
|
||||
|
||||
Software bill of materials enumerate what you depend on.
|
||||
when one of the libraries you use is updates, you may need to update to .
|
||||
|
||||
# how they are provided
|
||||
- provided within language
|
||||
- some OSs provide large amounts of functionality
|
||||
- e.g., apple ecosystem
|
||||
- co dev of language and OS
|
||||
- microsoft windows ecosystem
|
||||
- .net
|
||||
|
||||
# your obligations from using libraries
|
||||
|
||||
mulitple different ways to interact with libraries
|
||||
- tight integration compiler builds library code into yours
|
||||
- only uses parts of library that you included in your app
|
||||
- but upgrading library requires rebuilding the app
|
||||
- library is packed alongside you app
|
||||
- may bloat youu app: includes unused library parts
|
||||
- licencing of the library
|
||||
- legal obligations
|
||||
|
||||
# considerations when writing libraries
|
||||
- must consider general use cases
|
||||
- proper documentation
|
||||
- future maintenance
|
||||
- include abstractions to facilitate incremental updates
|
||||
- version numbering is important for compatibility
|
||||
- minor changes wont affect existing code
|
||||
- major changes will affect existing code
|
||||
|
||||
# features of Java standard libraries
|
||||
- very large
|
||||
- e.g., two flavours of I/O
|
||||
- traditional
|
||||
- async i.e., non-blocking (NIO)
|
||||
- written in java
|
||||
- portable across OSs
|
||||
- thin layer of OS specific code
|
||||
- this helped it to
|
||||
|
||||
# FYI "Boost"ing C++ library support
|
||||
|
||||
boost is a rich set of libraries for C++
|
||||
|
||||
|
||||
[software library](notes/libraries.md)
|
||||
|
||||
- Explain what a software library is
|
||||
- Describe reasons for/against using libraries
|
||||
- Understand transitive dependencies in libraries
|
||||
- Appreciate your obligations from using libraries
|
||||
- Outline considerations when writing libraries
|
||||
- Highlight features of the Java standard libraries
|
||||
@ -4,49 +4,12 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-01
|
||||
sr-interval: 14
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# aesthetic and minimalist
|
||||
- signal to noise ratio
|
||||
- what are you core functionality
|
||||
- how can you best use your screen space
|
||||
|
||||
recognise diagnore recover from errors
|
||||
- make the problem clear
|
||||
- e.g., username or password is wrong vs username is wrong
|
||||
- provide a solution and inform users (treat the users as adults
|
||||
|
||||
# help
|
||||
- guide the way and show steps
|
||||
- online help
|
||||
- transition from built in help to links to online help
|
||||
- sometimes users dont have an internet connection
|
||||
- e.g., chrons app used all the data
|
||||
- help clearly and transparently
|
||||
- e.g., privacy and terms/conditions
|
||||
|
||||
# anti design heuristics
|
||||
[](https://i.imgur.com/BHJ5iQU.png)
|
||||
[](https://i.imgur.com/DrqSSK5.png)
|
||||
[](https://i.imgur.com/KPW6h19.png)
|
||||
|
||||
## dark patterns
|
||||
turniing patterns against the user.
|
||||
all the dsign heuristics can be used against the user
|
||||
|
||||
- [oxfam example](https://i.imgur.com/mn3oK05.png): defaults to a recurring payment
|
||||
- [comet shop example](https://i.imgur.com/nGfdk7W.png): additional product is automatically included
|
||||
- [complicated contract](https://i.imgur.com/mTJmqwa.png)
|
||||
- [flight booking](https://i.imgur.com/6uwauOB.png)
|
||||
- [amazon cancel prime](https://i.imgur.com/06htsKV.png)
|
||||
- cancel facebook account
|
||||
- [FOMO](https://i.imgur.com/Ikf0DiF.png)
|
||||
|
||||
who is the customer of free products like tiktik, facebook, instagram. WE are not the customer, we are the animals in the zoo, the products
|
||||
|
||||
|
||||
|
||||
|
||||
[aesthetic-and-minimalist-design](notes/aesthetic-and-minimalist-design.md)
|
||||
[help-and-documentation](notes/help-and-documentation.md)
|
||||
[recognise-and-recover-from-errors](notes/recognise-and-recover-from-errors.md)
|
||||
[anti-design-heristics](notes/anti-design-heristics.md)
|
||||
[dark-patterns](notes/dark-patterns.md)
|
||||
|
||||
20
content/notes/14-apis.md
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
title: "14-apis"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-31
|
||||
sr-interval: 9
|
||||
sr-ease: 252
|
||||
---
|
||||
|
||||
- purpose of apis
|
||||
- apis vs code libraries
|
||||
- why web technologies assist API development
|
||||
- REST
|
||||
- apis in cloud mircoservices
|
||||
- building APIs
|
||||
- maintenance of APIs
|
||||
|
||||
[application-programming-interface](notes/application-programming-interface.md)
|
||||
@ -4,8 +4,8 @@ aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-13
|
||||
sr-interval: 11
|
||||
sr-due: 2022-06-10
|
||||
sr-interval: 28
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
|
||||
@ -27,7 +27,9 @@ the designer needs to create mapping from the real world unicers ofb objects and
|
||||
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.
|
||||
$$
|
||||
|
||||
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
|
||||
@ -38,4 +40,4 @@ $$ where C1 and C2 are contstants that depend on the device. A is the distance t
|
||||
|
||||
|
||||
# Combining inputs
|
||||
often multiple ways of doing one thing
|
||||
often multiple ways of doing one thing
|
||||
|
||||
@ -4,119 +4,13 @@ aliases:
|
||||
tags:
|
||||
- lecture
|
||||
- cosc201
|
||||
sr-due: 2022-05-19
|
||||
sr-interval: 10
|
||||
sr-due: 2022-06-13
|
||||
sr-interval: 25
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
- [dynamic-programming](notes/dynamic-programming.md)
|
||||
- [memoization](notes/memoization.md)
|
||||
|
||||
|
||||

|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
What is dynamic programming?
|
||||
|
||||
Dynamic is just a name chosen so that it cannot be used ina bad way i.e., it cannot have bad connotations.
|
||||
|
||||
Programming refers not the just compute programming.
|
||||
|
||||
In three words: remembering useful answers
|
||||
In more than three words: Trading space (remembering useful answers) for time (not having to recompute them later).
|
||||
|
||||
# Fibonacci numbers example
|
||||
|
||||
$f_{0}= f_{1}= 1, f_{n}=f_{n-1}+ f_{n-2}\ for\ n > 1$
|
||||
|
||||
the obvious recursive implementation requires exponential time becuase the recursive sub-problems
|
||||
- compute $f_n-1$, and
|
||||
- compute $f_n-2$
|
||||
overlap (the first generates an instance of the second in the next recurive call)
|
||||
|
||||
DP says "since you know you're goinf to need the values later, remember them as you compute them", and (technically), does one more thing. "while youre at it, since you need to know all the values, you might as well compute from simplest to most complex (bottom up)"
|
||||
|
||||
convert recursive algorithms to counter controlled for or while loops.
|
||||
|
||||
```java
|
||||
public long fibDP (int n) {
|
||||
long[] f = new long[n+1];
|
||||
f[0] = 1; f[1] = 0;
|
||||
for(int i = 2; i <= n; i++){
|
||||
f[i] = f[i-1] + f[i-2];
|
||||
}
|
||||
return f[n];
|
||||
}
|
||||
```
|
||||
|
||||
- initialise memorrt to store the answers for simpler problems
|
||||
- work from bottom up
|
||||
- return answer
|
||||
|
||||
```java
|
||||
static HashMap<Integer, Long> fib = new HashMap<>();
|
||||
public static long fibMEM(int n) {
|
||||
if(n <= 1) return 1;
|
||||
if(!fib.containsKey(n)) {
|
||||
fib.put(n, fibMEM(n-1) + fibMEM(n-2));
|
||||
}
|
||||
return fib.get(n);
|
||||
}
|
||||
```
|
||||
- this technique is called memoization (or caching)
|
||||
- whenever you compute a result store it somewhere before returning it
|
||||
- look it up(if you can) when needed
|
||||
- supported automatically in some languages (e.g., Python's @functools.cache, and any symbolic programming language)
|
||||
|
||||
# DP vs memoization
|
||||
bottom typically compute *all* simpler versions of the problem. When this is neccessary then DP will be faster. However it only a small proportion of the previous case are actually needed it may be better to use memoization. sometimes we can reduct the storage need for DP too. e.g., in the following fibonacci example
|
||||
|
||||
better fibonacci
|
||||
```java
|
||||
public long fibDP (int n) {
|
||||
int a = 1, b = 1, c = 1;
|
||||
for(int i = 2; i <= n; i++){
|
||||
c = a + b;
|
||||
a = b;
|
||||
b = c;
|
||||
}
|
||||
return c;
|
||||
}
|
||||
```
|
||||
|
||||
# DP vs Divide and conquer
|
||||
|
||||
d and c is splitting into chunks with *no overlap*. So there's nothing to gain by remembering one part, since it cant help in solving any other part.
|
||||
|
||||
DP or memozation should be used only when there is value added by remembering answers.
|
||||
|
||||
# Route counting example
|
||||
|
||||

|
||||
|
||||
Compute the number of routes from A to Z travelling only east or south.
|
||||
|
||||
Number of routes to Z is the sum of the number of routes to Z's western and northern neighbors. This is true for all nodes except for the edges.
|
||||
|
||||
The ideas to to fill the grid with numbers, where each node is the sum of its preceding neighbors.
|
||||
|
||||
```java
|
||||
public long count(int rows,int cols){
|
||||
long[][] counts = new long[rows][cols];
|
||||
//init edges to 1
|
||||
for (rows){
|
||||
for (cols){
|
||||
counts[r][c] = counts[r-1][c] + counts[r][c-1];
|
||||
}
|
||||
}
|
||||
return counts[rows-1][cols-1];
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
- since we can copute all the values in one row just from the preceding row, we could reduce the extra space requirement from rows x cols to just cols
|
||||

|
||||
@ -4,29 +4,10 @@ aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-14
|
||||
sr-interval: 12
|
||||
sr-due: 2022-06-21
|
||||
sr-interval: 34
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
- [UML to Java Foward Engineering](notes/uml-java-forward-engineering.md)
|
||||
- [round-trip-engineering](notes/round-trip-engineering.md)
|
||||
|
||||
# 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.
|
||||
- [round-trip-engineering](notes/round-trip-engineering.md)
|
||||
@ -4,12 +4,11 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-12
|
||||
sr-interval: 10
|
||||
sr-due: 2022-06-20
|
||||
sr-interval: 33
|
||||
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.
|
||||
@ -24,4 +23,4 @@ Door is very simple compared to computer interface. Yet they are still done wron
|
||||
|
||||
# Representation Matters and Distributing cognition
|
||||
|
||||
[representation-and-distributing-cognition](notes/representation-and-distributing-cognition.md)
|
||||
[representation-and-distributing-cognition](notes/representation-and-distributing-cognition.md)
|
||||
|
||||
91
content/notes/16-c201-archive.md
Normal file
@ -0,0 +1,91 @@
|
||||
---
|
||||
title: "16-c201-archive"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- archived-lecture
|
||||
---
|
||||
|
||||
## In a perfect world
|
||||
- keys from a class k, valuyes from a class v
|
||||
- there are only 4000 possible keys
|
||||
- each key, k, has a unique four digit identifier than we can obtain in constant time as `k.id();`
|
||||
|
||||
```java
|
||||
V[] map = new V[10000];
|
||||
|
||||
public V put(K key, V value){
|
||||
V old = map[k.id()];
|
||||
map[k.id()] = value;
|
||||
return old; //to match java map interface
|
||||
}
|
||||
|
||||
public V get(K key){
|
||||
return map[k.id()];
|
||||
}
|
||||
|
||||
public V remove(K key){
|
||||
V old = map[k.id()];
|
||||
map[k.id()] = null;
|
||||
return old;
|
||||
}
|
||||
```
|
||||
|
||||
works but:
|
||||
- we need to allocate 10000 spaces of storage
|
||||
- require `k.id();` in constant time
|
||||
- cannot store null values (key not present vs key is mapped to null) (we will need more storage)
|
||||
|
||||
so:
|
||||
- we should only require storage for what we need, not for all possible keys
|
||||
- need to use `Array` for constant time add, remove, get. (we may need to resize the array sometimes)
|
||||
|
||||
## Considering space
|
||||
```java
|
||||
V[] map = new V[53];
|
||||
|
||||
public V put(K key, V value){
|
||||
V old = map[k.id() % v.length];
|
||||
map[k.id() % v.length] = value;
|
||||
return old; //to match java map interface
|
||||
}
|
||||
|
||||
public V get(K key){
|
||||
return map[k.id() % v.length];
|
||||
}
|
||||
|
||||
public V remove(K key){
|
||||
V old = map[k.id() % v.length];
|
||||
map[k.id() % v.length] = null;
|
||||
return old;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Problem:
|
||||
- some keys can be duplicated
|
||||
|
||||
## Solving k.id()
|
||||
- solution is to make one up.
|
||||
- since collisions are inevitable, uniqueness is not required
|
||||
- made up ID called a `hash code`
|
||||
- a *hash function* take objects from a class as input and produces a value from a fixed finite set of values (in Java, an `int`)
|
||||
- properites it should have
|
||||
- should be fast to compute $O(1)$
|
||||
- shoud be uniform (even when we take modulo)
|
||||
|
||||
This sounds hard, but for commonly used classes (e.g., strings) there are already good has functions. Good enough is usually good enough. IDE can usually suggest something that is good enough. A hashcode function will usually come with an equals function to distinguish between collions and actual equal values
|
||||
|
||||
|
||||
## Collisions: Chaining/open addressing
|
||||
- array elements are called buckets
|
||||
- each bucket is a *list* of key-value pairs
|
||||
- when a mapping is added,
|
||||
- if empty add it (creating a new list if required)
|
||||
- otherwise check to see if there is a collision or an actual equality with each item of the list
|
||||
- If there is an equality -> change its value
|
||||
- otherwise just add it to the list
|
||||
- get and removing are handled similarly
|
||||
|
||||
we need to keep the load factor (how full the map is) small so that the chains dont't get to long
|
||||
|
||||
@ -4,8 +4,8 @@ aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-22
|
||||
sr-interval: 13
|
||||
sr-due: 2022-06-24
|
||||
sr-interval: 33
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
@ -21,7 +21,7 @@ sr-ease: 250
|
||||
- [interpreter](notes/interpreter.md)
|
||||
|
||||
# What is a compiler?
|
||||
A [compiler](notes/compiler.md) is used to build stored programs. Things that are stored on the disk that you can run. They use source code in a **high level** language, and output machine code in a binary file. This file can be loaded and run by hardware. Example langauges include C, C++, Java (sorf of)
|
||||
A [compiler](notes/compiler.md) is used to build stored programs. Things that are stored on the disk that you can run. They use source code in a **high level** language, and output machine code in a binary file which is then linked with a [linker](notes/linker.md). This file can be loaded and run by hardware. Example langauges include C, C++, Java (sorf of)
|
||||
|
||||
An [interpreter](notes/interpreter.md) is more of an interactive tool. The interpreter program (e.g., python) runs of the CPU and execute your program. Interpreted laguages include (python, ruby, shell, R, js, PHP).
|
||||
|
||||
|
||||
@ -11,4 +11,4 @@ sr-ease: 250
|
||||
|
||||
- [representation-and-distributing-cognition](notes/representation-and-distributing-cognition.md)
|
||||
- [typography](notes/typography.md)
|
||||
- [visual-design](notes/visual-design.md)
|
||||
- [visual-design](notes/visual-design.md)
|
||||
|
||||
@ -4,98 +4,11 @@ aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-02
|
||||
sr-interval: 15
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# Maps and Sets
|
||||
I the compsci context a *map* contrains a *set* of *keys* each with an associated *value*. A map consists of a set of keys. A map can aslso store a set by igorning the values for each key. Thesre are three fundamental operations.
|
||||
- `put(k, v)` : add the mapping from k to v either by adding k iff its not alreaady present or by changing the associated value
|
||||
- `get(k)` : return the value associated iwht k if k is present
|
||||
- `remove(k)` : remove the key k (and any associated value)
|
||||
|
||||
[BST](notes/binary-search-tree.md) can provide us with a set or map implementation whre the cost of each operation is $O(lg\ n)$ . But his requires an underlying order on keys, which might not be needed.
|
||||
|
||||
## In a perfect world
|
||||
- keys from a class k, valuyes from a class v
|
||||
- there are only 4000 possible keys
|
||||
- each key, k, has a unique four digit identifier than we can obtain in constant time as `k.id();`
|
||||
|
||||
```java
|
||||
V[] map = new V[10000];
|
||||
|
||||
public V put(K key, V value){
|
||||
V old = map[k.id()];
|
||||
map[k.id()] = value;
|
||||
return old; //to match java map interface
|
||||
}
|
||||
|
||||
public V get(K key){
|
||||
return map[k.id()];
|
||||
}
|
||||
|
||||
public V remove(K key){
|
||||
V old = map[k.id()];
|
||||
map[k.id()] = null;
|
||||
return old;
|
||||
}
|
||||
```
|
||||
|
||||
works but:
|
||||
- we need to allocate 10000 spaces of storage
|
||||
- require `k.id();` in constant time
|
||||
- cannot store null values (key not present vs key is mapped to null) (we will need more storage)
|
||||
|
||||
so:
|
||||
- we should only require storage for what we need, not for all possible keys
|
||||
- need to use `Array` for constant time add, remove, get. (we may need to resize the array sometimes)
|
||||
|
||||
## Considering space
|
||||
```java
|
||||
V[] map = new V[53];
|
||||
|
||||
public V put(K key, V value){
|
||||
V old = map[k.id() % v.length];
|
||||
map[k.id() % v.length] = value;
|
||||
return old; //to match java map interface
|
||||
}
|
||||
|
||||
public V get(K key){
|
||||
return map[k.id() % v.length];
|
||||
}
|
||||
|
||||
public V remove(K key){
|
||||
V old = map[k.id() % v.length];
|
||||
map[k.id() % v.length] = null;
|
||||
return old;
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
Problem:
|
||||
- some keys can be duplicated
|
||||
|
||||
## Solving k.id()
|
||||
- solution is to make one up.
|
||||
- since collisions are inevitable, uniqueness is not required
|
||||
- made up ID called a `hash code`
|
||||
- a *hash function* take objects from a class as input and produces a value from a fixed finite set of values (in Java, an `int`)
|
||||
- properites it should have
|
||||
- should be fast to compute $O(1)$
|
||||
- shoud be uniform (even when we take modulo)
|
||||
|
||||
This sounds hard, but for commonly used classes (e.g., strings) there are already good has functions. Good enough is usually good enough. IDE can usually suggest something that is good enough. A hashcode function will usually come with an equals function to distinguish between collions and actual equal values
|
||||
|
||||
|
||||
## Collisions: Chaining/open addressing
|
||||
- array elements are called buckets
|
||||
- each bucket is a *list* of key-value pairs
|
||||
- when a mapping is added,
|
||||
- if empty add it (creating a new list if required)
|
||||
- otherwise check to see if there is a collision or an actual equality with each item of the list
|
||||
- If there is an equality -> change its value
|
||||
- otherwise just add it to the list
|
||||
- get and removing are handled similarly
|
||||
|
||||
we need to keep the load factor (how full the map is) small so that the chains dont't get to long
|
||||
[Hash functions](notes/hash-map.md#Hash%20functions)
|
||||
[Collisions Chaining open addressing](notes/hash-map.md#Collisions%20Chaining%20open%20addressing)
|
||||
[basic implementation](notes/hash-map.md#basic%20implementation)
|
||||
|
||||
@ -4,19 +4,9 @@ aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-07
|
||||
sr-interval: 20
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
|
||||
# Java -> UML reverse engineering
|
||||
reverse of [uml-java-forward-engineering](notes/uml-java-forward-engineering.md)
|
||||
|
||||
- parse java doe and egenerate corresponding uml diagrams
|
||||
- useful to generate models of existing systems
|
||||
- code usually has more detail than can be represented in diagrams
|
||||
- automated diagram layout likely to be ugly ⇒ manual clean up
|
||||
- some language specific features may not translate
|
||||
|
||||
|
||||
[uml-java-reverse-engineering](notes/uml-java-reverse-engineering.md)
|
||||
@ -4,47 +4,9 @@ aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-12
|
||||
sr-interval: 3
|
||||
sr-due: 2022-06-08
|
||||
sr-interval: 19
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[animation demo](https://echo360.net.au/lesson/0e13f645-a91f-46c6-89d9-e3c31097b960/classroom#sortDirection=desc)
|
||||
|
||||
Chaining (lists of k-v pairs in each bucket) breaks locailty of reference within the array and ay not be suitable for high-performance implementations.
|
||||
|
||||
It works in java because objects are stored as references anyway, you need to look elsewhere in memory anyway.
|
||||
|
||||
So the advantage of probing is negated.
|
||||
|
||||
In C you know how many bytes of memory a k v pair will occupy. So you can store them as a continuous block of memory. Now you can take advatage of the locality of reference and the speed it provides.
|
||||
|
||||
To do this the contents of bucket should not be a list. they should be null, or a single kv pair.
|
||||
|
||||
each kv pair has a *home spot* it would like to go to: this is the modulo remainder from last lecture.
|
||||
|
||||
# linear probing
|
||||
- if a kv's home is already full, we move it into the next spot (wrapping to the beginning when we reach the end) in the array.
|
||||
- frequency of collisions and time to find a new space are proportional to the *load factor* (percetage of occupied slots)
|
||||
- the load factor is capped and the array is resized when the cap is exceeded
|
||||
|
||||
## Insertion cost
|
||||
proportional to the number of filled blocks we search before we find an empty one. As long as the load factor is not to high this is on average $O(1)$
|
||||
|
||||
## Search
|
||||
Proportional to the number of cells we search before finding the one we want or an empty cell
|
||||
|
||||
## Resize
|
||||
Create a new table of (about double) the size and insert all the elements of the table into it. If we dont double, exactly, we "scamble" the modulo remainder a bit more to reduce collions. cost is $\theta(n)$. This can be *amortised* across those elements to give $O(1)$ is the amortised sense
|
||||
|
||||
### Amortised cost
|
||||
- the operations of a dynamic data structure have amortised cost $O(1)$, if
|
||||
- there is constant $C>0$ such that,
|
||||
- for every positive integer $k$, and
|
||||
- any sequence of $k$ operations on the data structure (from initalisation),
|
||||
- the average time per operation is less than $C$
|
||||
|
||||
## Deletion
|
||||
we cant just empty cells as this will break search. We could:
|
||||
1. we could replace it by a "tombstone" maker. This counts as "full" for search and load purposes, but empty for insertion.
|
||||
2. we search foward form the element we're removing until we find something that belongs in that location or earlier - swap it back into this location and repeat until an empty cell is found.
|
||||
[linear-probing](notes/linear-probing.md)
|
||||
|
||||
@ -15,4 +15,4 @@ sr-ease: 250
|
||||
- [file-based-storage](notes/file-based-storage.md)
|
||||
- [database-based-storage](notes/database-based-storage.md)
|
||||
- [data-access-object](notes/data-access-object.md)
|
||||
- [java-database-connectibity](notes/java-database-connectibity.md)
|
||||
- [java-database-connectibity](notes/java-database-connectibity.md)
|
||||
|
||||
@ -4,8 +4,8 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-20
|
||||
sr-interval: 11
|
||||
sr-due: 2022-06-16
|
||||
sr-interval: 27
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
|
||||
@ -18,4 +18,4 @@ sr-ease: 250
|
||||
|
||||
- [operating-system](notes/operating-system.md)
|
||||
- [loader](notes/loader.md)
|
||||
- [linker](notes/linker.md)
|
||||
- [linker](notes/linker.md)
|
||||
|
||||
141
content/notes/18-advanced-sql-1.md
Normal file
@ -0,0 +1,141 @@
|
||||
---
|
||||
title: "18-advanced-SQL"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-15
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||

|
||||

|
||||
|
||||
varchar usually bigger than you think
|
||||
|
||||
# CRUD
|
||||
- insert adds a row 
|
||||
- select retrieves rows from the table
|
||||
- ouput can be "saved" as a view 
|
||||
- changes to the underlying table also chagnes the view
|
||||
- update modifies rows 
|
||||
- delete removes rows  
|
||||
- test as a select statement first
|
||||
|
||||
# SQL DAO programming
|
||||
We want to miniminse load on sql as connecting to database is expensive.
|
||||
|
||||
Optimisations:
|
||||
- prefer muultiple row operations
|
||||
- connection pools (keep connections "alive")
|
||||
- reuse prepared statements (reduce unnecessary SQL parsing)
|
||||
- consider combining queries to reduce round trips
|
||||
- batched requests
|
||||
|
||||
Follow Optimistic approach
|
||||
- assume operatios will succeed (no pre checking)
|
||||
- handle errors with exception handling
|
||||
- consider using merge if available
|
||||
|
||||
## Merge
|
||||
 aka replace etc.
|
||||
|
||||
- update if they exist other wise insert
|
||||
|
||||
## JDBC
|
||||
Java framework for interacting with sql databases.
|
||||
|
||||
plaform and DBMS independent
|
||||
- driver provided by DBMS vendors
|
||||
- same Java code will work with any DBMC
|
||||
|
||||
key concepts
|
||||
- connections and connection pools
|
||||
- sql strings and prepared statements
|
||||
- result sets
|
||||
- transactions
|
||||
- batched requrests
|
||||
|
||||

|
||||
|
||||
|
||||
## JDBI
|
||||
- bette version of JDBI
|
||||
- layered on top of [JDBC](#JDBC)
|
||||
- better APIs
|
||||
- less code
|
||||
- simple class <-> table mapping
|
||||
- flexible plugin architecture
|
||||
|
||||

|
||||

|
||||
|
||||
|
||||
# Transactions
|
||||
interaction between two entities
|
||||
- follow explicit or implied forms
|
||||
- usually involves exchange on resources
|
||||
- may require several steps
|
||||
- often considered a single unit
|
||||
|
||||
## In data bases
|
||||
- group of db operations is considered a *single logical unit*
|
||||
- transfer (read and update)
|
||||
- recieve shipement (update accounts)
|
||||
- customer sale
|
||||
|
||||
transactions are all or nothing. (commit vs rollback)
|
||||
|
||||
## ACID
|
||||
- Atomic
|
||||
- all or nothing
|
||||
- operations should be related
|
||||
- Consistent
|
||||
- transactions move dbs from one consistent state to another
|
||||
- "consistent" ⇒ all integrity rules are satisfied
|
||||
- db may be inconsistent during a transaction
|
||||
- require defferable constraints
|
||||

|
||||
- Isolated
|
||||
- concurrent transactios shouldn't interfere with each other
|
||||
- ideally behave as if other transactions dont exist
|
||||
- read committed isolation
|
||||
- uncommited changes are visible to other transactions
|
||||
- require some form of concrrency mangement (e.g., locking)
|
||||
- 
|
||||
- Durability
|
||||
- once a transaction is commited it is permanent
|
||||
- uncommited transaction dont survive crashes
|
||||
- auto rollback of uncommitted transaction
|
||||
|
||||
## commit and rollback
|
||||
- changes are made to "live" data
|
||||
- commit makes database changes permanent
|
||||
- rollback removes all changes since that transaction start
|
||||
|
||||
## Transaction in Java
|
||||
default to auto commit.
|
||||
- each statement is a separate transaction
|
||||
- if transaction has multiple statements
|
||||
- disable auto commit
|
||||
- you must manage commit and rollback yourself
|
||||
|
||||

|
||||

|
||||

|
||||
|
||||
# Select
|
||||
- select <- wahat
|
||||
- from <- from where
|
||||
- where <- filter
|
||||
- group <- aggregation
|
||||
- order <- order
|
||||
|
||||
distinct removes duplicate rows
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
@ -4,8 +4,8 @@ aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-13
|
||||
sr-interval: 3
|
||||
sr-due: 2022-05-21
|
||||
sr-interval: 8
|
||||
sr-ease: 252
|
||||
---
|
||||
|
||||
@ -16,85 +16,3 @@ sr-ease: 252
|
||||
- appreciated that there are many build tools
|
||||
|
||||
|
||||
# Build tools
|
||||
Tools that automate the construction of software,.
|
||||
|
||||
## C
|
||||
if you recompile C you get an object file which can be linked. Automation tools will do the linking for you.
|
||||
|
||||
what they do:
|
||||
- run [compiler](notes/compiler.md)
|
||||
- run [linker](notes/linker.md)
|
||||
- automatically download depencies ([libraries](notes/13-code-librarires.md))
|
||||
- this can also be done using [containers](notes/containers.md) e.g., a docker container
|
||||
- possibly some form of [testing](notes/testing.md)
|
||||
|
||||
# History of build tools
|
||||
|
||||
## Make
|
||||
> check whether targets are older than sources
|
||||
|
||||
Has:
|
||||
- set of targets
|
||||
- set of source files
|
||||
- A list of commands that build the target from the source
|
||||
- internal variables
|
||||
- \$@ - the rules source(s)
|
||||
- \$< - the rules tartet
|
||||
-
|
||||
|
||||
Build things in the correct order (*topologically*. e.g., will run compiler before linker if needed.
|
||||
|
||||
Limitations
|
||||
- doesn't handle subprojects
|
||||
- doesn't handle directories
|
||||
- when make look for changes, it usually only looks in the current dir
|
||||
- big projects will have call make is sub projects, this can get complicated quick
|
||||
- Internal variables do not match with typical shell variables
|
||||
- use \$\$ to use make shell variables
|
||||
- no real constraints or conventions: can \betaused for a lot of things
|
||||
|
||||
## Java programs
|
||||
dont really need the linking step: java can load class files on the fly. The java compiler is more flexible.
|
||||
|
||||
Still needs some automation:
|
||||
- cleaing uneeded .class files
|
||||
- bulding Java archive files (JAR)
|
||||
|
||||
## Ant
|
||||
Written to handle build tasks, e.g., build a JAR, clean up files. Uses an XML file: build.xml. (XML sucks)
|
||||
|
||||
improves upon make by
|
||||
- better at scanning sub dirs
|
||||
- calls javac on many files at once not one at a time
|
||||
|
||||
## Maven
|
||||
maven has conventions:
|
||||
- e.g., file structure:
|
||||
- main app as src/main/java
|
||||
- support resources at src/main/resources
|
||||
- test sources at src/test/java
|
||||
- Support non java languages
|
||||
|
||||
Still XML files: pom.xml
|
||||
|
||||
Colour in output.
|
||||
|
||||
## Gradle
|
||||
speed and flexibility
|
||||
- does not use xml
|
||||
- has its own domain specific language
|
||||
- more complex than maven
|
||||
- faster than maven
|
||||
- particularly in incremental build
|
||||
- i.e. not re-building when it doesn't need to
|
||||
- Support non java languages
|
||||
|
||||
## Others
|
||||
- rake - ruby's version of Make
|
||||
- SCons - builds database about build state
|
||||
- CMake - cross platorm building; uses existing tools/IDEs
|
||||
- SBT scala
|
||||
- languge built in tools
|
||||
- go - Go build
|
||||
- rust - Cargo
|
||||
@ -4,9 +4,9 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-25
|
||||
sr-interval: 16
|
||||
sr-due: 2022-07-07
|
||||
sr-interval: 43
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
[hci-ethics](notes/hci-ethics.md)
|
||||
[hci-ethics](notes/hci-ethics.md)
|
||||
|
||||
@ -4,8 +4,8 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-13
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
sr-due: 2022-06-19
|
||||
sr-interval: 28
|
||||
sr-ease: 270
|
||||
---
|
||||
|
||||
|
||||
172
content/notes/19-advanced-sql-2.md
Normal file
@ -0,0 +1,172 @@
|
||||
---
|
||||
title: "19-advanced-sql-2"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-26
|
||||
sr-interval: 7
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
|
||||
# CASE
|
||||

|
||||
|
||||
basically a switch statement
|
||||
|
||||
- derived valye where calcyulation isnt simple
|
||||
- standardising values e.g., booleans: t/f, y/n, 0/1
|
||||
- flipping between row and col orientation (*privoting*)
|
||||
- all students vs all on one students papers
|
||||
|
||||
# Set operators
|
||||
relations are sets of tuples ⇒ we can use set operators
|
||||
|
||||
combine rows of two table vertically
|
||||
|
||||
source table must be compativble
|
||||
- same set of columns
|
||||
- same data types
|
||||
- = same heading
|
||||
|
||||
get new table with same headings as inputs
|
||||
|
||||
identical rows deleted
|
||||
|
||||

|
||||
|
||||
union: all rows
|
||||
- 
|
||||
- 
|
||||
|
||||
intersect: rows that appear in both
|
||||
- 
|
||||
- 
|
||||
|
||||
difference (except, minus): rows in top that arent in bottom
|
||||
- 
|
||||
- 
|
||||
|
||||
# Aggregation and grouping
|
||||

|
||||
|
||||
## group by
|
||||

|
||||
- groups rows that have equal values across all the columns in \<column-list>
|
||||
- always used with aggregate function(s) in select clause
|
||||
- one row in the result for each differect combined value of the grouped columns
|
||||
|
||||

|
||||
|
||||
- all non computed columns in select clause must normally appear in group y, and vice versa
|
||||
|
||||
### restricting by groups (having)
|
||||

|
||||
|
||||
- similiar to where, restricts output of group by
|
||||
- cant include aggregate functions (where can't);
|
||||
|
||||
## Analytic functions (FYI)
|
||||

|
||||
|
||||
- enchancement of aggregation
|
||||
- aggregate without reshaping the ouput
|
||||
- many more functions avaiable
|
||||
- sliding windows supported
|
||||
- dont use when simple group by is sufficient
|
||||
|
||||
# Select
|
||||

|
||||
|
||||
- select
|
||||
- from
|
||||
- where
|
||||
- group by
|
||||
- having
|
||||
- order by
|
||||
|
||||
order of evaluation
|
||||
- from
|
||||
- where
|
||||
- group by
|
||||
- having
|
||||
- select
|
||||
- order by
|
||||
|
||||
# Joins
|
||||

|
||||

|
||||
|
||||
inner join : matching rows only
|
||||
|
||||
outer join: may include non-matching rows from the left table, right table, or both tables
|
||||
|
||||
also, cross, and semi join
|
||||
|
||||
## Cross join product
|
||||

|
||||

|
||||
|
||||
every possible combination of rows from two tables
|
||||
|
||||
uses:
|
||||
- cards
|
||||
- suits table
|
||||
- ranks table
|
||||
- deck = suits cross join ranks
|
||||
- timetable
|
||||
- days table
|
||||
- timeslots table
|
||||
- timetable = days cross join timeslots
|
||||
|
||||
## Semi join
|
||||
output only trows from one table that match rows from the other
|
||||
|
||||

|
||||

|
||||
|
||||
inverse is antijoin: ouput only rows from one table that dont match rows from the other
|
||||
|
||||
# Subqueries
|
||||
a select expression embedded inside another
|
||||
- inselect clause to compute value using data from other tables
|
||||
- in from: inline view
|
||||
- in where clause with in, all, some , exists
|
||||
|
||||
- can refer to data from "outer" expression (correlated subquery)
|
||||
- tricky to write, so be careful. maybe stepwise
|
||||
- can rewrite joins as subqueries, but not vice versa
|
||||
|
||||
prefer joins to subqueries
|
||||
|
||||
## how to develop
|
||||
- identify components opf multi part query
|
||||
- implement and test the components as separeate select statements
|
||||
- combine into one query, nesting one within the other.
|
||||
|
||||

|
||||

|
||||
|
||||
# Inline views
|
||||
a named subqueriy embedded in the from clause is effectively a temporary view
|
||||
|
||||
visible within thescope of current select expression only
|
||||
|
||||

|
||||
|
||||
## saving sub queries (WITH)
|
||||
- sometimes need to re-use same or very similar subquery severl times in the same query
|
||||
- with saves named subqueries for later re-use (in the same query)
|
||||
- visible iwthin scope of entire select statement
|
||||
|
||||

|
||||
|
||||
# Scope in select
|
||||
- row variable only exist inside the select expression that defines them
|
||||
- a select expression can only directly refer to items declared in:
|
||||
- its own select and from clause
|
||||
- select and from clauses of any elclosing expressions
|
||||
- any preceedin with expression
|
||||
- particularly important for correlated subqueries
|
||||
|
||||
12
content/notes/19-graphs.md
Normal file
@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "19-graphs"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-27
|
||||
sr-interval: 8
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[graphs](notes/graphs.md)
|
||||
105
content/notes/19-security.md
Normal file
@ -0,0 +1,105 @@
|
||||
---
|
||||
title: "19-security"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-16
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
- why cybersecurity is a growing concern
|
||||
- sketch confidentiality, integrity, and avalability security
|
||||
- appreciate that dependencies cause security risks
|
||||
- explain risks from non-validation of user input
|
||||
- outline how injection attack works
|
||||
|
||||
# growing problem
|
||||
- more software around
|
||||
- more dependencies
|
||||
- resuse of old code rather than starting from scratch
|
||||
- more complex programs
|
||||
- "surface area" of risk is growing
|
||||
- speed of development has trumped security
|
||||
- some languages are inherently more secure than other
|
||||
- e.g., C can access any memory
|
||||
- software systems involve large numbers of components
|
||||
- large amounts of code is almost guaranteed to have bugs
|
||||
|
||||
# Security in development
|
||||
- - security isn't a single requiremtn you can tick off
|
||||
- it needs consideration throughtout the whole system
|
||||
- it is a cross-cutting concern
|
||||
- it is hard to retrofit
|
||||
- notion of security engineering is useful
|
||||
- affects design descision fromt the outset
|
||||
- changes how code is written and reviewed
|
||||
- add a specific type of testing to include
|
||||
- needs examination of how users interact with software
|
||||
|
||||
# Threat model
|
||||
- should character what you want to protect against
|
||||
- writin standalone software to be used by one person
|
||||
- typially dont have to worry about malicious attacks (on self)
|
||||
- software on a multi-user operating system
|
||||
- do need to think about cross-user data leaks
|
||||
- all OSs are multi user
|
||||
- software that has network availability
|
||||
- your software can and likely will be attacked
|
||||
- targeteted by state-sponsored teams? Good Luck...
|
||||
|
||||
# Divide into three areas
|
||||
- confidentiality - e.g., sensitive data is not visible
|
||||
- integrity e.g., data is protected from modification
|
||||
- avaliability e.g., services stay accessible
|
||||
|
||||
## Confidentiality
|
||||
- attacks on this involve stealing data
|
||||
- protect using encrytion (unsecured network or disk) or isolation of processes (if you trust the OS)
|
||||
- encrption does not necessarly work forever.
|
||||
|
||||
|
||||
## Integrity
|
||||
- attacks on data may aim to decieve users
|
||||
- defence: apply checksums (e.g., check secure hash of data)
|
||||
- attacks on code are often for *privilege esccalation*
|
||||
- e.g., attacker moves from normal user to super user
|
||||
- defence: avoid decisions being influenced by outside sources
|
||||
|
||||
## Availability
|
||||
- e.g., DDoS
|
||||
- ditributed denial of service
|
||||
- Defence: host services in multiple countries
|
||||
- use CDNs (content delivery networks) for data objects
|
||||
|
||||
## Key soft. dev. security area 1: dependencies
|
||||
- vulnerabilities in dependencies affect your code too
|
||||
- determine and examine your software bill of materials SBOM
|
||||
- subscribe to security alerts for your key dependencies
|
||||
- plan to rapidly rebuild and release you software at short notice
|
||||
- use tools to scan software for know problems
|
||||
- e.g., gitlab auto devOps scancs containers for vulnerabilites
|
||||
|
||||
- doesn't mean dont use them
|
||||
- use them if they are good
|
||||
- e.g.,
|
||||
- dont implement crypto yourself
|
||||
- use a secret manager for authentication
|
||||
- XACML libray
|
||||
- use libraries to parse data
|
||||
|
||||
## Key soft. dev. security area 1: santise input
|
||||
- treat user controlled inpuut to your code as malicious
|
||||
- databases must prevent SQL injection
|
||||
- many input sources
|
||||
- user docs
|
||||
- config files
|
||||
- env variables
|
||||
|
||||
# Injection attacks
|
||||
- rough def$^n$ some structure is not contained properly
|
||||
- 
|
||||
|
||||
# Resolving problems
|
||||

|
||||
150
content/notes/20-database-3.md
Normal file
@ -0,0 +1,150 @@
|
||||
---
|
||||
title: "20-database-3"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-05-20
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||

|
||||
|
||||
# Data Integrity
|
||||
|
||||
GIGO
|
||||
|
||||

|
||||
|
||||
Types of error
|
||||
- ennecessary duplication of data
|
||||
- missing information (expecially nulls)
|
||||
- referential integrity problems: broken links, "orhpan" records (foreign keys)
|
||||
- data entry errors: typos/keying errors, value in wrong field
|
||||
- invalid/nonsensical data, e.g., nefative salary
|
||||
- going against business rules/policy law
|
||||
|
||||
## Validation
|
||||
checking that entered values are plausible.
|
||||
- values must make sens, be valid
|
||||
- simple checks to block obvisously bogus data
|
||||
|
||||
automated by constraints within the data base
|
||||
|
||||
valid ≠ correct
|
||||
|
||||
## Verification
|
||||
Checking that correct value was entered e.g.,
|
||||
- double check input
|
||||
- independent double entry
|
||||
- independent triple entry (or more) for critical checks
|
||||
|
||||
manual process invvolving human input and judgement
|
||||
|
||||
valid + verified ≠ correct.
|
||||
- malicious vandalism
|
||||
- human psychology rtends to promote dertain kinds of error
|
||||
- misread handwritten notes
|
||||
- incorrect for fake information provided
|
||||
|
||||

|
||||

|
||||
|
||||
## Integrity constraints
|
||||
machine readable conditions (true/false)
|
||||
|
||||
checked when data is changed
|
||||
- in oracle all existing data must conform
|
||||
- in SQL erver, you havel to explicity tell it to check existing data
|
||||
|
||||
ideally these are in the daabase. but some this is not possibe and must be implemented in code.
|
||||
|
||||
### Defining constraints
|
||||
col-level constraints
|
||||
- specified in line in col defs
|
||||
- can only refer to that column
|
||||
|
||||
table level constraints
|
||||
- are specified out of line alongside other columns
|
||||
- can refer to any col inthe table
|
||||
|
||||
constrainst should be named
|
||||
|
||||
### Primary and foreign key constraints
|
||||

|
||||
|
||||
primary keys are not null and are unique
|
||||
|
||||
some DBMSs support on delete and on update actios on foreign keys when a parent row is deleted or updated
|
||||
- cascade: "child" rows inherit the same operation as "parent" row
|
||||
- set null: "child" FK is set to null (if permitted)
|
||||
- set default: ""
|
||||
|
||||
### Unique values (other than primary keys)
|
||||

|
||||
|
||||
## Check constrainsts
|
||||

|
||||
|
||||
for chcking if within list. use a lookup table
|
||||

|
||||
|
||||
# Automation
|
||||
## Sequences
|
||||
generate integer values
|
||||
|
||||

|
||||

|
||||

|
||||

|
||||
|
||||

|
||||
|
||||
## Triggers
|
||||
specific operation on table trigger other operations
|
||||
|
||||
normally written in a "proper" language e.g.,
|
||||
- Oracle: PL/SQL, Java
|
||||
- H2: java
|
||||
- SQL server: transact-SQL
|
||||
- PostgreSQL: most languages, e.g., python, ruby, perl, r, bash, java, php etc
|
||||
|
||||
used when:
|
||||
- as a last resort
|
||||
- computed columns
|
||||
- setting status values in reponse to updates
|
||||
- maintaining refernetial integrity
|
||||
- rewriting application input
|
||||
- integrity constraints that involve multiple tables
|
||||
- row based security policies
|
||||
- domain specific auditing (beyond standard logging features)
|
||||
- performing actions outside the DBMS
|
||||
|
||||
specifications
|
||||
- timing: before, after, instead of
|
||||
- type of operation: insert update delete
|
||||
- column affected (update only, optional)
|
||||
- table affected
|
||||
- other conditions (optional)
|
||||
|
||||
triggered operation
|
||||
- what to do
|
||||
- trigger will activate only once unless you tell to to execute once for each row affectted by the activation conditions
|
||||
|
||||

|
||||

|
||||
|
||||
## Stored procedure
|
||||
programming code stored within the database
|
||||
|
||||
why?:
|
||||
- reduce or eliminate application/database round trips
|
||||
- offload database-oriented processing to the DBMS
|
||||
- encapsulate database code in the database for re use (DRY)
|
||||
- encapsulate query details
|
||||
|
||||
triggers often a special case
|
||||
h2 lets you create aliases to java functions, but these aren't stored in the database
|
||||
|
||||

|
||||
36
content/notes/20-graphs-2.md
Normal file
@ -0,0 +1,36 @@
|
||||
---
|
||||
title: "20-graphs-2"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-05-21
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
Graph drawing is its own problem.
|
||||
|
||||
One easy way is to draw the vertices is clockwise order and draw edges between them
|
||||
|
||||
[traversal examples](https://echo360.net.au/lesson/86c6c819-3257-424e-b8e6-d17f4e1e9170/classroom#sortDirection=desc)
|
||||
|
||||
# recurisve depth first traversal
|
||||
same but.. delay the pop of an item from the stack until all its neighbours have been processed, and we only push those one at a time.
|
||||
|
||||

|
||||
|
||||
## topological sorting
|
||||
In a *directed* graph we have edges from v to w which do not necessarily imply an edge from w to v.
|
||||
|
||||
then is a neighbor of v but not (necessarily) vice versa.
|
||||
|
||||
suppose edges indicate some dependency
|
||||
|
||||
we want an order of vertices that finishes with v but never containes any vertex unless all the things that depend on it occur earlier
|
||||
|
||||
this is a (reverse) *topological* sort
|
||||
|
||||
for this to work the graph must be *acyclic*. i.e., we cannot have a depends on v which depends on w which depends on a
|
||||
|
||||
it that condition is met a recursive depth first traversal can be used.3
|
||||
24
content/notes/20-software-licensing.md
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "20-software-licensing"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-30
|
||||
sr-interval: 10
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[pdf](https://cosc202.cspages.otago.ac.nz/lectures/L20-software-licensing.pdf)
|
||||
|
||||
what does it mean for people to use your software. What responsitilities do you have
|
||||
|
||||
- Understand the default protection of code
|
||||
- Contrast ‘libre’ free and ‘gratis’ free
|
||||
- Define what makes open source software
|
||||
- Contrast copyleft and more permissive licences
|
||||
- Appreciate that code can be multi-licensed
|
||||
- Understand how to apply a license to code
|
||||
- Appreciate licenses can be mutually incompatible
|
||||
|
||||
[software-licensing](notes/software-licensing.md)
|
||||
14
content/notes/21-software-architecture-and-templates.md
Normal file
@ -0,0 +1,14 @@
|
||||
---
|
||||
title: "21-software-architecture-and-templates"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-06-15
|
||||
sr-interval: 24
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[software-architectures](notes/software-architectures.md)
|
||||
|
||||
[system-templates](notes/system-templates.md)
|
||||
77
content/notes/22-trends-in-hci.md
Normal file
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: "22-trends-in-hci"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
---
|
||||
|
||||
[slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2827522-dt-content-rid-18612267_1/courses/INFO203_S1DNIE_2022/2022/INFO203_Lecture23.pdf
|
||||
how the the methodology of HCI used.)
|
||||
|
||||
Theory vs practice. There is a lot of work being done t improve the methodology
|
||||
|
||||
# Bad style - HARKing and the replication crisis
|
||||
|
||||

|
||||
|
||||
# Publication bias
|
||||
- Computing research validate research claims using statistical significance as the standard of evidence
|
||||
- Statistical evidence usually assumes 95% confidence (p <= 0.05)
|
||||
- analysis of 362 papers published found that 97% reject the null
|
||||
- papers that were incorrecct are not published
|
||||
- *Publication bias*: Papers supporting their hypotheses are accepted for publication at a much higher rate than those that do not.
|
||||
- HARKing (Hypothesizing After the Results are Known) or known as ‘outcome switching’
|
||||
- Post-hoc reframing of experimental intentions to present a p-fished outcome as having been predicted from the start.
|
||||
- p-hacking: Manipulation of experimental and analysis methods to produce statistically significant results.
|
||||
- p-fishing: seeking statistically significant effects beyond the original hypothesis.
|
||||
|
||||
A survey of over 2000 psychology researchers, John et al. examined the prevalence of questionable experimental practices (forms of HARKing):
|
||||
1. Failing to report all dependent measures, which opens the door for selective reporting of favourable findings – 63.4%;
|
||||
2. Deciding to collect additional data after checking if the effects were significant – 55.9%;
|
||||
3. Failing to report all of the study’s conditions – 27.7%;
|
||||
4. Stopping data collection early once the significant effect is found – 15.6%;
|
||||
5. Rounding off a p value (e.g., reporting p = .05 when the actual value is p = .054) – 22.0%;
|
||||
6. Selectively reporting studies that worked – 45.8%;
|
||||
7. Excluding data after looking at the impact of doing so – 38.2%;
|
||||
8. Reporting an unexpected finding as having been predicted – 27.0%;
|
||||
9. Reporting a lack of effect of demographic variables (e.g., gender) without checking – 3.0%;
|
||||
10. Falsifying data – 0.6%
|
||||
|
||||

|
||||
|
||||
File drawer effect: Null findings tend to be unpublished and therefore hidden from the scientific community.
|
||||
|
||||
## Solutions
|
||||
|
||||
Preregistration: Registries in which researchers preregister their intentions, hypotheses, and methods (including sample sizes and precise plans for the data analyses) for upcoming experiments
|
||||
|
||||
Preregistered Reports: Papers (Reports) are submitted for review prior to conducting the experiment. Registered reports include the study motivation, related work, hypotheses, and detailed method; everything that might be expected in a traditional paper except for the results and their interpretation.
|
||||
|
||||
• Redefine or abdandon statistical significance. • Create data repositories and support replication
|
||||
|
||||
# Trends
|
||||
## Wearable sensing and actuation
|
||||

|
||||
|
||||

|
||||

|
||||
|
||||
applications
|
||||
- vr haptics
|
||||
- on the skin directions
|
||||
- notifications
|
||||
- more
|
||||
|
||||

|
||||
|
||||
## electodermis
|
||||

|
||||
focused more on the manufacturing of the stickers
|
||||
|
||||
## earput
|
||||
[earput paper](https://i.imgur.com/ZqfaHUt.png)
|
||||

|
||||
|
||||
## skin track
|
||||

|
||||
47
content/notes/24-trends-in-hci-2.md
Normal file
@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "24-trends-in-hci-2"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-28
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
|
||||
# Dark patterns
|
||||

|
||||

|
||||
|
||||
# Designing for elderlies
|
||||

|
||||

|
||||
|
||||
the familiarity of local church in full size was good.
|
||||
|
||||
# Digital fabrication
|
||||
3d printing, interfaces which allow you to 3d print etc.
|
||||
|
||||
## things
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
# Explinable AI HCI for AI, fairness of AI
|
||||

|
||||

|
||||

|
||||

|
||||

|
||||

|
||||
|
||||
Most people dont actually understand the AI they create. Finding new ways to create, and understand AI.
|
||||
|
||||
# gaze and Eye tracking
|
||||

|
||||

|
||||
12
content/notes/SQL.md
Normal file
@ -0,0 +1,12 @@
|
||||
---
|
||||
title: "SQL"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
---
|
||||
|
||||
# Principles
|
||||
|
||||
# Sytax
|
||||
|
||||
# Interaction with code
|
||||
@ -13,4 +13,6 @@ signal to noise
|
||||

|
||||

|
||||
|
||||
- what are you core functionality
|
||||
- how can you best use your screen space
|
||||
|
||||
|
||||
62
content/notes/analyzing-experiments.md
Normal file
@ -0,0 +1,62 @@
|
||||
---
|
||||
title: "analyzing-experiments"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
- scott-video
|
||||
sr-due: 2022-06-01
|
||||
sr-interval: 7
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# 3 questions
|
||||
- what does my data look like
|
||||
- graphs, plots, differnent summary plots
|
||||
- what are the overall numbers
|
||||
- aggregate stats e.g., mean average std dev
|
||||
- are the differences "real"?
|
||||
- significance p-value
|
||||
- likihood that results are due to chance
|
||||
|
||||
## p value
|
||||
pearsons chi-squared test. comparing rate of expected value vs observed value
|
||||
|
||||
$$
|
||||
\chi^{2}=\frac{(observed-expected)^2}{expected}
|
||||
$$
|
||||
|
||||
"normal" outcome variance follow normal/gaussian distribution.
|
||||
|
||||
as chi squared gets bigger it is less likey that the coin is unbiased
|
||||
|
||||
e.g., 20 tosses, we got 13 heads. at p<0.05 can we reject the null that the coin is unbiased
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
degrees of freedom num possibilites n-1 = 2-1 = 1
|
||||
|
||||
we cannot reject the null
|
||||
|
||||
 reject the null
|
||||
|
||||
\
|
||||
|
||||
formalieses: "were pretty sure". helps generalize from small samples
|
||||
|
||||
for normal continiuous data
|
||||
- t-tests (compare 2)
|
||||
- annova (compare more than 2)
|
||||
|
||||
data is not always normal.
|
||||
- bi modal - 2 peaks
|
||||
- skewed
|
||||
- e.g., time: can be infiniely slow, but not infinitely fast
|
||||
|
||||
|
||||
non-normal data
|
||||
- knowing is half tha battle
|
||||
- run A/A tests
|
||||
- use randomised testing
|
||||
10
content/notes/anti-design-heristics.md
Normal file
@ -0,0 +1,10 @@
|
||||
---
|
||||
title: "anti-design-heristics"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||

|
||||

|
||||

|
||||
92
content/notes/application-programming-interface.md
Normal file
@ -0,0 +1,92 @@
|
||||
---
|
||||
title: "application-programming-interface"
|
||||
aliases: API
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
Allows code (and people) to interact with other people applications. They define interactions points (*endpoints*) within the code, where data is retrieved (GET) or inserted (POST). Each endpoint is accessed using a *URL* or URI through *HTTP*.
|
||||
|
||||
# REST principles
|
||||
> Representational state transfer.
|
||||
|
||||
These principles describe the best practives for building APIs.
|
||||
|
||||
Some of the main points are:
|
||||
- decoupled
|
||||
- not dependent of e.g., a specific browser
|
||||
- stateless
|
||||
- each interaction is self contained
|
||||
- although sometimes this is not used
|
||||
- e.g., authenticated "sessions"
|
||||
- uniform interface.
|
||||
- codifies principle of using HTTP methods on URLs
|
||||
- internal representation of data id hidden
|
||||
- interactions are based on resources
|
||||
|
||||
REST principles were Co-developed with the web
|
||||
|
||||
# Java REST APIs
|
||||
java servelts are code blocks that handle requests. java.servlet.http library
|
||||
|
||||
framworks like Spring support Java API development
|
||||
- wraps an aplicationserver around you data classes
|
||||
- can persist your data in a database
|
||||
- also provides servers that can host API access to your data
|
||||
|
||||
## Web technologies
|
||||
- resources on the web are identified using URLs
|
||||
- HTTP is the network protocol for data transfer in the web
|
||||
- HTTP describes 'methods' to apply to URLs
|
||||
- GET *read* a resource identified using a URL
|
||||
- PUT *writes* to a resource identified using a URL
|
||||
|
||||
# Cloud computing
|
||||
Uses *mircoservices*
|
||||
|
||||
apps built from intercommunicating microservice components/ each component can scale independently.components are loosely coupled.
|
||||
|
||||
# Bulding an API
|
||||
Use a [library](notes/libraries.md)/framework with:
|
||||
- human readable documentation of functions
|
||||
- ability to manually interact
|
||||
|
||||
Some APIs will provide tools to interactively build snippets which can be copy pasted
|
||||
|
||||
# Maintaining API
|
||||
Similar to maintenance of code [libraries](notes/libraries.md)
|
||||
- need to consider abstractions
|
||||
- need to evolve
|
||||
- future proof as much as possible
|
||||
- avoid complete rewrites
|
||||
- use versioning
|
||||
|
||||
|
||||
# Other stuff
|
||||
## Flask
|
||||
small python web sever
|
||||
|
||||
## code and data
|
||||
APIs define interaction points within code. (Similar to visibilty of methods).
|
||||
- also force a barrier between devs code
|
||||
|
||||
need developer to understand data model
|
||||
- this may appear explicitly in API calls
|
||||
- may be that API calls manipulate unseen data
|
||||
- need ndevs to be comfortable with you *mental model*
|
||||
|
||||
Use of [libraries](notes/13-code-librarires.md) share many of these points
|
||||
|
||||
## Overview
|
||||
Allow code to interact with others applicatioins.
|
||||
|
||||
can be used by people, not only code.
|
||||
|
||||
API differ from libraries because they deal with the interactions between applications at runtime.
|
||||
|
||||
APIs work accross different "distances" of interaction. e.g., intergrating software components within one server vs across the internet
|
||||
|
||||
web technologies have positively impacteed api by
|
||||
- simplfy development - provide base of technologies that can be used to gain access to data in a structure way
|
||||
- normalised tools to using APIs
|
||||
|
||||
@ -4,15 +4,15 @@ tags:
|
||||
- info201
|
||||
---
|
||||
|
||||
## 1 traditional
|
||||
regardless of the approach, the conecpot of the model is import for analysis design and modelling parrasigms
|
||||
regardless of the approach, the concept of the model is import for analysis, design, and modelling paradigms
|
||||
|
||||
### 1.1 system is a collection of process
|
||||
# 1 traditional
|
||||
*system is a collection of process*
|
||||
function programming
|
||||
processes interact with data
|
||||
processes accept inputs and produce ouputs
|
||||
|
||||
### 1.2 object oriented
|
||||
system is a collection of objects
|
||||
# 1 object oriented
|
||||
*system is a collection of [objects](notes/object.md)*
|
||||
these objects interact with each other
|
||||
and send and respond to messages
|
||||
and send and respond to messages
|
||||
13
content/notes/assigning-participants-video.md
Normal file
@ -0,0 +1,13 @@
|
||||
---
|
||||
title: "assigning-participants-video"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
- scott-video
|
||||
sr-due: 2022-05-28
|
||||
sr-interval: 9
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[assigning-participants](notes/assigning-participants.md)
|
||||
84
content/notes/assigning-participants.md
Normal file
@ -0,0 +1,84 @@
|
||||
---
|
||||
title: "assigning-participants"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
|
||||
# Methods
|
||||
## Between Subjects
|
||||
The participants are split into equal groups, each which reviews one of the alternatives
|
||||
## Within Subjects
|
||||
The participants are split into two grops, one group review the first alternative first, the other review the seconds alternative first.
|
||||
## Latin Square
|
||||

|
||||
|
||||
order of each group is different
|
||||
# Counterbalanced assignments
|
||||
e.g., typing speed might affect interface usage
|
||||
you can use a pretest to assign participants to that typing speed is roughly balanced
|
||||
|
||||
many techniques: key is to have equal chance of each participant in each group
|
||||
|
||||
## offline counterbalancing
|
||||
pre-testing then forming matches pairs, which are split between groups]
|
||||
|
||||
## online counterbalancing
|
||||
- of ther is no pre-test pick a threshold that is likely to be about the middle
|
||||
- as they come in
|
||||
|
||||
- dont need to ensure even nubmer of high and low typers.
|
||||
- do need to ensure the same number of high/low typers in a and b
|
||||
## dangers
|
||||
### regression:
|
||||
- find heady coins
|
||||
- first flip them all (pre-test)
|
||||
- if they land heads more than half, call them heady
|
||||
- "feed them a snack"
|
||||
- does snacking increase the natural tendency of coins
|
||||
|
||||

|
||||
|
||||
both regress towards the mean
|
||||
|
||||
### how to avoid
|
||||
if the pretest is used to counterbalance, and assignment is random, then the error goes away
|
||||
|
||||
|
||||
# should every participant use every alternative
|
||||
three major srategies
|
||||
|
||||
- **Within**
|
||||
- everyone tries all options
|
||||
- good when not fussed about learning/practise/exposure isssues
|
||||
- **between participants**
|
||||
- each person tries only only of the options
|
||||
- requires more people, and more attention to fair assignment
|
||||
- has the benefit that each participant is uncorrupted
|
||||
- most common forthings like web studies
|
||||
- **Counterbalancing**
|
||||
-
|
||||
|
||||
# hawthorne effect
|
||||
results are a result of the act of exmperimenting itself not as a resyult of the manupulations of the experiment
|
||||
|
||||
can be avoided with random assignment
|
||||
|
||||
# vaccum cleaner example
|
||||
- manipulation
|
||||
- vacuum type
|
||||
- measures
|
||||
- speed
|
||||
- cleanliness
|
||||
|
||||
- between subjects design: assign half the participants to each type.
|
||||
- worried about individual differences
|
||||
- within subjects design: everyone uses both interfaces:
|
||||
- worried about ordering effects
|
||||
|
||||
- half try one first, the other try the other first (counterbalancing)
|
||||
- each of the tasks should be difference e.g., clean differnt buildings/rooms
|
||||
|
||||
individual differnces: go based of intuition of if it will make a difference.
|
||||
Random assignment is importantg
|
||||
@ -1,9 +1,194 @@
|
||||
---
|
||||
title: "assignment-02"
|
||||
number headings: auto, first-level 1, max 6, 1.1
|
||||
title: "Assignment 02"
|
||||
subtitle: "Jet Hughes, 9474308"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- assignment
|
||||
header:
|
||||
- \documentclass{article}
|
||||
- \usepackage{multirow}
|
||||
---
|
||||
|
||||
# 1 Introduction
|
||||
## 1.1 Setup
|
||||
This report will discuss various strategies for managing a *warehouse* . A warehouse will be simulated as follows:
|
||||
- A warehouse is made up of a grid of *cells*.
|
||||
- Each cell has a collection of *packets*
|
||||
- Each packet has a *destination* cell.
|
||||
- Each cell also has a *robot*
|
||||
- In each step of the simulation a robot can deliver one packet to a robot in an adjacent cell.
|
||||
- The simulation ends when each cell has arrived at its destination.
|
||||
|
||||
|
||||
## 1.2 Managers
|
||||
The goal is to deliver all the packets to their desired destination as efficiently as possible.
|
||||
|
||||
Efficiency is defined as the minimum number of steps required to deliver all the packets divided by the actual number of steps taken.
|
||||
|
||||
The efficiency of the warehouse depends on the delivery scheme used by the robots. There are four managers I will be considering. These are:
|
||||
|
||||
**Basic**
|
||||
- Packets are stored in a FIFO queue
|
||||
- Vertical movements are made before horizontal movements
|
||||
- Received packets are always added to the queue
|
||||
|
||||
**Load Aware**
|
||||
- Packets are stored in a FIFO queue
|
||||
- If its destination is in a straight line from the current location, it just sends it one step in the appropriate direction.
|
||||
- Otherwise, moves to cells with fewer packets are preferred.
|
||||
- In case of an equality, revert to the basic rule
|
||||
- Only packets that need to keep moving are added to the queue
|
||||
|
||||
**Priority**
|
||||
- Packets are stored in a Priority queue
|
||||
- Packets with further distance to their destination have higher priority
|
||||
- If two packets have the same priority, revert to the load aware rule
|
||||
- Only packets that need to keep moving are added to the queue
|
||||
|
||||
**Min Load** [^1]
|
||||
- Same as normal priority, but the priority is changed
|
||||
- A Packet has two (logical) possible cells it could move to next. Its priority is found by checking the load at each of these two cells, and taking the lesser of the two.
|
||||
- If two packets have the same priority, revert to the load aware rule.
|
||||
- Only packets that need to keep moving are added to the queue
|
||||
|
||||
## 1.3 Scenarios
|
||||
There are a number of other factors that affect the efficiency of the warehouse. These are:
|
||||
|
||||
- The total number of packets in the warehouse
|
||||
- The initial distribution of the packets
|
||||
- The distribution of the destination of the packets
|
||||
|
||||
The plan is to analyze the efficiencies of the delivery schemes in a few different scenarios, with a few different map sizes. These scenarios are:
|
||||
|
||||
- **1000 Random:** 1000 packets are added in random locations with random destinations
|
||||
- **One Per Cell:** The number of packets and cells is the same. Each cell contains one packet to begin with, and has a random destination (different packets might have the same destination).
|
||||
- **Chance Per Cell:** As the previous case, but each cell has only a 25% chance of containing a packet.
|
||||
- **Upper Left:** The number of packets and cells is the same. All the packets start in the upper left corner, and each packet has a different destination.
|
||||
- **Center:** The number of packets and cells is the same. All the packets start in center, and each packet has a different destination.
|
||||
|
||||
# 2 Analysis
|
||||
Each result is the average efficiency of 25 runs in that configuration
|
||||
|
||||
## 2.1 N Random
|
||||
$$
|
||||
\begin{tabular}{|c|c|c|c|c|c|c|c|}
|
||||
\hline
|
||||
Scenario&\multicolumn{6}{|c|}{Map Sizes} \\
|
||||
\hline
|
||||
&5&10&20&40&80&100\\
|
||||
\hline
|
||||
Basic&4.0\%&14.6\%&43.7\%&84.6\%&98.2\%&98.9\%\\
|
||||
Load Aware&4.9\%&17.5\%&47.0\%&84.3\%&98.0\%&98.6\%\\
|
||||
Priority&4.9\%&17.7\%&55.6\%&100.0\%&100.0\%&100.0\%\\
|
||||
Min Load&4.8\%&17.0\%&49.2\%&90.2\%&98.1\%&98.9\%\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
$$
|
||||
|
||||
In this scenario. The efficiency of the mangers clearly increased proportionally to the size of the map. This is because the number of packets remained constant, so as the map size increased, the load on the managers decreased and Packets were able to move through the warehouse more quickly.
|
||||
|
||||
At a map size of 100 all managers achieved close to 100% efficiency. However, the Priority manager was the only one able to achieve exactly 100%. In addition, it was about 5% better than the others in a 50x50 map.
|
||||
|
||||
It is also worth noting the basic manager was significantly worse than the others in the very small maps. This is likely due to the high load on each of the managers, amplifying the need to keep them in balance. A since all the other managers have some form of load balancing, the Basic Manager is most affected. I could be interesting to try to create a manger that performs better here than the Basic manager without, using any load balancing. Possibly considering only priority based on distance to destination.
|
||||
|
||||
The Min Load manager was very slightly better than the Load Aware Manager in the mid-sized maps. This implies that prioritizing nodes that can be easily balanced is better than, simply, sending nodes to the least loaded cell.
|
||||
|
||||
The managers tend to perform similarly at the extreme ends of the map size spectrum, and differ most in the middle.
|
||||
|
||||
## 2.2 One Per Cell
|
||||
$$
|
||||
\begin{tabular}{|c|c|c|c|c|c|c|c|}
|
||||
\hline
|
||||
Scenario&\multicolumn{6}{|c|}{Map Sizes} \\
|
||||
\hline
|
||||
&5&10&20&40&80&100\\
|
||||
\hline
|
||||
Basic&73.8\%&76.2\%&72.9\%&73.7\%&74.4\%&73.3\%\\
|
||||
Load Aware&81.0\%&76.2\%&73.7\%&74.0\%&74.3\%&73.4\%\\
|
||||
Priority&88.5\%&97.7\%&99.5\%&100.0\%&100.0\%&100.0\%\\
|
||||
Min Load&85.0\%&81.0\%&83.1\%&82.7\%&81.8\%&83.0\%\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
$$
|
||||
|
||||
In this scenario, overall efficiency was relatively high with the Basic, and Load Aware managers achieving about 70%, Min load achieving about 80%, and Priority manager about 100%. Since the number of packets is proportional to the size of the map, changing the size had little effect on the efficiency of the managers, except for the Priority manager, and to a lesser extent the Load Aware manager.
|
||||
|
||||
The Priority manager significantly outperforms the other managers here. However, it was significantly less efficient (but still better than the other managers) in smaller map sizes. It decreased from 100% in 100x100 to 88.5% in 5x5. The Load Aware manager, on the other hand, *increased* from 73.4% in 100x100 to 81% in 5x5. Since I only have a small sample size of 25, this could be due to random chance.
|
||||
|
||||
The Min Load Manager was consistently better than the Basic and Load Aware managers, but never better than the Priority manager.
|
||||
|
||||
## 2.3 Chance Per Cell
|
||||
Chance = 25%
|
||||
$$
|
||||
\begin{tabular}{|c|c|c|c|c|c|c|c|}
|
||||
\hline
|
||||
Scenario&\multicolumn{6}{|c|}{Map Sizes} \\
|
||||
\hline
|
||||
&5&10&20&40&80&100\\
|
||||
\hline
|
||||
Basic&94.5\%&94.5\%&94.6\%&95.7\%&96.5\%&97.4\%\\
|
||||
Load Aware&95.8\%&94.2\%&94.1\%&95.6\%&96.2\%&96.1\%\\
|
||||
Priority&98.7\%&99.7\%&100.0\%&100.0\%&100.0\%&100.0\%\\
|
||||
Min Load&97.4\%&96.3\%&96.0\%&96.5\%&98.2\%&98.0\%\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
$$
|
||||
|
||||
In this configuration, the efficiency was very high due to the low number of packets, low load-factor and subsequent fast movement of Packets. Hence, the variation in efficiencies was very small, as the need for balanced managers was diminished.
|
||||
|
||||
Here, the Priority manager still performed the best, achieving 100% efficiency, although by a lesser margin than in the previous two scenarios. Once again, the Min Load manager was better than the Basic and Load Aware managers, but not the Priority manager.
|
||||
|
||||
## 2.4 Upper Left
|
||||
$$
|
||||
\begin{tabular}{|c|c|c|c|c|c|c|c|}
|
||||
\hline
|
||||
Scenario&\multicolumn{6}{|c|}{Map Sizes} \\
|
||||
\hline
|
||||
&5&10&20&40&80&100\\
|
||||
\hline
|
||||
Basic&26.3\%&15.8\%&8.9\%&4.7\%&2.4\%&1.9\%\\
|
||||
Load Aware&25.8\%&15.7\%&8.8\%&4.7\%&2.4\%&1.9\%\\
|
||||
Priority&30.7\%&17.5\%&9.4\%&4.8\%&2.5\%&2.0\%\\
|
||||
Min Load&26.6\%&16.0\%&8.8\%&4.7\%&2.4\%&1.9\%\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
$$
|
||||
|
||||
This scenario had by far the lowest efficiency. This is because a single manger initially holds every node. Since most of the load at any given time is being handled by one manager, and most of the packets will wait a long time before getting offloaded to an adjacent cell, they will take longer to reach their destination. As the map size increases, the efficiency decreases rapidly, as the number of packets starting on the top left cell increased exponentially.
|
||||
|
||||
There is little variation in the efficiency of the different managers, except for the Priority manager, which is slightly more efficient than the others. I think this is because by prioritizing packets that need to travel further, the concentration of packets in the corner is reduces faster.
|
||||
|
||||
It would be interesting to know whether placing all the packets in the center of the map would be more efficient. I think it would be, as there are more directions for the packets to spread out, and the packets are on average would be closer to their destination (since destinations are uniformly distributed).
|
||||
|
||||
## 2.5 Center
|
||||
I decided to investigate the idea of starting all the packets in the center. These were the results.
|
||||
|
||||
$$
|
||||
\begin{tabular}{|c|c|c|c|c|c|c|c|}
|
||||
\hline
|
||||
Scenario&\multicolumn{6}{|c|}{Map Sizes} \\
|
||||
\hline
|
||||
&5&10&20&40&80&100\\
|
||||
\hline
|
||||
Basic&14.8\%&9.0\%&4.8\%&2.4\%&1.2\%&1.0\%\\
|
||||
Load Aware&15.0\%&9.0\%&4.7\%&2.4\%&1.2\%&1.0\%\\
|
||||
Priority&16.0\%&9.7\%&4.9\%&2.5\%&1.2\%&1.0\%\\
|
||||
Min Load&14.9\%&9.3\%&4.8\%&2.4\%&1.2\%&1.0\%\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
$$
|
||||
|
||||
Surprisingly, this was about half as efficient as starting is the corner. This is the opposite of what I expected. It's interesting that it reached exactly 1% efficiency in a 100x100 map.
|
||||
|
||||
Aha! It's because the max distance a packet must travel is shorter (about half), so even with a similar number of steps, the efficiency will be twice as bad. This means that Center does not necessarily result in slower delivery, only higher consequences for slow deliveries.
|
||||
|
||||
# 3 Summary
|
||||
Priority managers was clearly the most efficient of the four managers, with the Min Load following. Configurations with extremely large or small amounts of packets per cell made the managers perform more similarly, and scenarios with medium amounts of packets per cell amplified the difference.
|
||||
|
||||
I think the main reason Priority manager was consistently better than the other was because It spreads the load among more managers faster, and ensures that Packets with further destinations arrive about the same time as shorter ones. It effectively removes the advantage that packets closer to their destination have.
|
||||
|
||||
I think Min Load performed better than Load Aware for one reason: It did a better job of distributing load. I think I could have made an even better manager by prioritizing based on a function of both load, and distance.
|
||||
|
||||
[^1]: I couldn't think of a better name
|
||||
|
||||
@ -25,4 +25,4 @@ Big theta defines an *upper and a lower* bound for a the running time (or space)
|
||||
|
||||
## 2 Formal definition
|
||||
|
||||
$f(n) = \theta(g(n))$ if there are some constants $A$ and $B$ where $0 < B < A$ such that for all sufficiently large $n$, $B \times g(n) \geq f(n) \leq A \times g(n)$
|
||||
$f(n) = \theta(g(n))$ if there are some constants $A$ and $B$ where $0 < B < A$ such that for all sufficiently large $n$, $B \times g(n) \geq f(n) \leq A \times g(n)$
|
||||
|
||||
@ -7,14 +7,38 @@ tags:
|
||||
|
||||
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
|
||||
When a tree is being used only occainsonally, we can afford to simply rebalance it periodically. However when it is in constant use we cannot afford this cost
|
||||
|
||||
# Rotations
|
||||
long branches are a problem
|
||||
the performance bounds for all BST operations are linear of the length of the longest branch of the tree
|
||||
|
||||
ideal shape is a similar to a [heap](notes/heap.md) (wide and shallow).
|
||||
|
||||
we want the longest branch to be $\theta(lg\ n)$
|
||||
|
||||
one way is to do an [In order](notes/tree-traversal.md#In%20order) and save to a sorted array. then construct a new tree by repeatedly bisecting the array. and recursively building the left and right subtrees
|
||||
|
||||
need some local operation that helps to restore balance
|
||||
|
||||
# Rotation
|
||||
## How
|
||||
suppose that in this bst there is a longer chain in e than else where
|
||||
|
||||

|
||||
|
||||
imagine twisting d to be the root
|
||||
|
||||

|
||||
|
||||
changes are
|
||||
- b's right child is now c
|
||||
- d's left child is not b
|
||||
- b parent now points to d
|
||||
|
||||
## When
|
||||

|
||||
sometimes two rotations are needed
|
||||
|
||||
## When to rotate and how to do them
|
||||
sometimes two rotations are needed
|
||||
|
||||
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
|
||||
|
||||
|
||||
@ -35,4 +35,4 @@ In this example:
|
||||
- n.p = root
|
||||
- n.key = emu
|
||||
- n.l = nil
|
||||
- n.r.key = rat
|
||||
- n.r.key = rat
|
||||
|
||||
@ -35,24 +35,24 @@ Sutherland, Ivan Edward (January 1963). "Sketchpad: A man-machine graphical comm
|
||||
|
||||

|
||||
|
||||
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||
1968 - “The Sword of Damocles� Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display�
|
||||
|
||||

|
||||
|
||||
|
||||
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||
1968 - “The Sword of Damocles� Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display�
|
||||
|
||||

|
||||
|
||||
1968 - “The Sword of Damocles” Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display”
|
||||
1968 - “The Sword of Damocles� Sutherland, Ivan Edward (1968), “A head-mounted three dimensional display�
|
||||
|
||||

|
||||
|
||||
“The Mother of All Demos”, presented by Douglas Engelbart (1968) at (ACM/IEEE) Computer Society's Fall Joint Computer Conference See full demo: https://www.youtube.com/watch?v=yJDv-zdhzMY
|
||||
“The Mother of All Demos�, presented by Douglas Engelbart (1968) at (ACM/IEEE) Computer Society's Fall Joint Computer Conference See full demo: https://www.youtube.com/watch?v=yJDv-zdhzMY
|
||||
|
||||

|
||||
|
||||
“Dynabook” Alan C. Kay. (1972), “Personal Computer for Children of All Ages”
|
||||
“Dynabook� Alan C. Kay. (1972), “Personal Computer for Children of All Ages�
|
||||
|
||||

|
||||
|
||||
@ -60,11 +60,11 @@ Apple Newton (1993) and Apple iPad (2010)
|
||||
|
||||

|
||||
|
||||
Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||
Graphical User Interface supporting “What You See Is What You Get� (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||
|
||||

|
||||
|
||||
Graphical User Interface supporting “What You See Is What You Get” (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||
Graphical User Interface supporting “What You See Is What You Get� (WYSIWYG), the Desktop metaphor (files, folders, etc.), Xerox Parc/Xeroc Star
|
||||
|
||||

|
||||
|
||||
@ -76,7 +76,7 @@ Ramesh Raskar, Greg Welch, Matt Cutts, Adam Lake, Lev Stesin and Henry Fuchs (19
|
||||
|
||||

|
||||
|
||||
1981 - Steve Manns’s “Wearable Computing” Start of a series of prototypes for wearable computing, cyborgs, and mediated reality (-> Google Glass) www.wearcam.org, www.eyetap.org
|
||||
1981 - Steve Manns’s “Wearable Computing� Start of a series of prototypes for wearable computing, cyborgs, and mediated reality (-> Google Glass) www.wearcam.org, www.eyetap.org
|
||||
|
||||

|
||||
|
||||
|
||||
@ -72,7 +72,7 @@ This will be a mobile app that snowboarders can use to automatically generate ra
|
||||
|
||||
The first core feature of the app is the customisable trick generator. It should be very easy and quick to use. This presents an interesting problem as while snowboarding, users are wearing large mittens, and the air can be very cold for hands. It would be ideal if it could be used while wearing mittens.
|
||||
|
||||
The second core feature of the app is the Daily Trick. This means that users get a notification with a random trick from the trick generator. This feature could allows users to get the benefit of the trick generator without having to open the app on the mountain. However, the issue here is that most people don't snowboard everyday. To get around this, I could allows the users to schedule days on which to recieve a daily trick, or I could alert them whenever they are on a mountain by monitoring their altitude. Of course the second option has some privacy issues that will need to be considered.
|
||||
The second core feature of the app is the Daily Trick. This means that users get a notification with a random trick from the trick generator. This feature could allows users to get the benefit of the trick generator without having to open the app on the mountain. However, the issue here is that most people don't snowboard everyday. To get around this, I could allow the users to schedule days on which to recieve a daily trick, or I could alert them whenever they are on a mountain by monitoring their altitude. Of course the second option has some privacy issues that will need to be considered.
|
||||
|
||||
The third core feature of the app is the link with friends. This is a core feature because snowboarders will typically rider with a group of friends. Being able to join a 'trick group' means these groups can do the same trick and 'compete' against each other.
|
||||
|
||||
@ -113,4 +113,4 @@ Skate dice was one of the most intresting the apps I found. It had a very unique
|
||||
|
||||
|
||||
## Skate tricks
|
||||
This app is a much more fully featured solution. It is oriented towards learning skateboarding, and keeping track of you progress while doing it. It also has a built in trick generator, and game of skate. One of the most unique features it had that the other apps didn't was a trick of the day. This is one of the core features I want to include in my app. Another interesting feature it had was a page informing the user about injury prevention.
|
||||
This app is a much more fully featured solution. It is oriented towards learning skateboarding, and keeping track of you progress while doing it. It also has a built in trick generator, and game of skate. One of the most unique features it had that the other apps didn't was a trick of the day. This is one of the core features I want to include in my app. Another interesting feature it had was a page informing the user about injury prevention.
|
||||
|
||||
@ -112,4 +112,4 @@ private void delete(Node n) {
|
||||
|
||||
# Traversal
|
||||
|
||||
[tree-traversal](notes/tree-traversal.md)
|
||||
[tree-traversal](notes/tree-traversal.md)
|
||||
|
||||
@ -57,4 +57,4 @@ Should:
|
||||
- Dont start with a small program
|
||||
- Show the project to people
|
||||
- Show to recruiters
|
||||
- Demo in interviews
|
||||
- Demo in interviews
|
||||
|
||||
89
content/notes/build-tools.md
Normal file
@ -0,0 +1,89 @@
|
||||
---
|
||||
title: "build-tools"
|
||||
aliases: build tools
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# Build tools
|
||||
Tools that automate the construction of software,.
|
||||
|
||||
## C
|
||||
if you recompile C you get an object file which can be linked. Automation tools will do the linking for you.
|
||||
|
||||
what they do:
|
||||
- run [compiler](notes/compiler.md)
|
||||
- run [linker](notes/linker.md)
|
||||
- automatically download depencies ([libraries](notes/13-code-librarires.md))
|
||||
- this can also be done using [containers](notes/containers.md) e.g., a docker container
|
||||
- possibly some form of [testing](notes/testing.md)
|
||||
|
||||
# History of build tools
|
||||
|
||||
## Make
|
||||
> check whether targets are older than sources
|
||||
|
||||
Has:
|
||||
- set of targets
|
||||
- set of source files
|
||||
- A list of commands that build the target from the source
|
||||
- internal variables
|
||||
- \$@ - the rules source(s)
|
||||
- \$< - the rules tartet
|
||||
-
|
||||
|
||||
Build things in the correct order (*topologically*. e.g., will run compiler before linker if needed.
|
||||
|
||||
Limitations
|
||||
- doesn't handle subprojects
|
||||
- doesn't handle directories
|
||||
- when make look for changes, it usually only looks in the current dir
|
||||
- big projects will have call make is sub projects, this can get complicated quick
|
||||
- Internal variables do not match with typical shell variables
|
||||
- use \$\$ to use make shell variables
|
||||
- no real constraints or conventions: can \betaused for a lot of things
|
||||
|
||||
## Java programs
|
||||
dont really need the linking step: java can load class files on the fly. The java compiler is more flexible.
|
||||
|
||||
Still needs some automation:
|
||||
- cleaing uneeded .class files
|
||||
- bulding Java archive files (JAR)
|
||||
|
||||
## Ant
|
||||
Written to handle build tasks, e.g., build a JAR, clean up files. Uses an XML file: build.xml. (XML sucks)
|
||||
|
||||
improves upon make by
|
||||
- better at scanning sub dirs
|
||||
- calls javac on many files at once not one at a time
|
||||
|
||||
## Maven
|
||||
maven has conventions:
|
||||
- e.g., file structure:
|
||||
- main app as src/main/java
|
||||
- support resources at src/main/resources
|
||||
- test sources at src/test/java
|
||||
- Support non java languages
|
||||
|
||||
Still XML files: pom.xml
|
||||
|
||||
Colour in output.
|
||||
|
||||
## Gradle
|
||||
speed and flexibility
|
||||
- does not use xml
|
||||
- has its own domain specific language
|
||||
- more complex than maven
|
||||
- faster than maven
|
||||
- particularly in incremental build
|
||||
- i.e. not re-building when it doesn't need to
|
||||
- Support non java languages
|
||||
|
||||
## Others
|
||||
- rake - ruby's version of Make
|
||||
- SCons - builds database about build state
|
||||
- CMake - cross platorm building; uses existing tools/IDEs
|
||||
- SBT scala
|
||||
- languge built in tools
|
||||
- go - Go build
|
||||
- rust - Cargo
|
||||