auto update

content/cheatsheets/puml-cheat-sheet.md

@@ -0,0 +1,9 @@
+---
+title: "puml-cheat-sheet"
+tags: 
+- cheatsheet
+---
+
+# 1 Activity Diagram
+[docs](https://plantuml.com/activity-diagram-beta)
+

content/daily_notes/2022-04-07.md

@@ -7,19 +7,19 @@
 Screamadelica - Primal Scream - spotify:album:3Kkocxhs4Ek537j67DFNd7
 
 ## 1.1 Todos
-- [ ] 12:00 Cosc201 lab
+- [x] 12:00 Cosc201 lab
 - [ ] 12:00 Info201 Lab
 - [ ] 11:00 Cosc201 Lecture
-- [ ] 14:00 Info203 Tutorial
+- [x] 14:00 Info203 Tutorial
 - [ ] 16:00 Cosc201 Tutorial
-- [ ] Add review meta data to new vault
+- [x] Add review meta data to new vault
 - [ ] inquire about dataview in quartz
 
 ## 1.2 Lecture/Labs
 
-- [ ] 11:00 Cosc202 Lecture
+- [x] 11:00 Cosc202 Lecture
 - [ ] 12:00 Cosc201 Lab
-- [ ] 16:00 Info201 Lecture
+- [x] 16:00 Info201 Lecture
 
 ## 1.3 Assignments
 

content/daily_notes/2022-04-08.md

@@ -0,0 +1,46 @@
+[[notes/daily-notes]]
+
+---
+
+# 1 2022-04-08
+
+Autobahn - Kraftwerk - spotify:album:0DzC0tyowMi2O9QfkDRvfJ
+
+## 1.1 Todos
+- [x] Info201 Lab 05
+- [ ] info 201 lab 04
+- [ ] Cosc201 Lecture
+- [ ] Cosc201 Tutorial
+- [ ] inquire about dataview in quartz
+- [ ] Cosc201 Lab Shuffle
+- [ ] Assignment 3
+- [x] Decide individual or not
+
+## 1.2 Lecture/Labs
+
+- [x] 09:00 Cosc202 Lab
+- [ ] 11:00 Cosc201 Lecture
+- [ ] 12:00 Info201 Lab 06
+
+## 1.3 Assignments
+
+## 1.4 Projects
+- python ai weekly review
+- CI notes site
+- my own password manager
+
+## 1.5 Timetable
+
+![[Pasted image 20220311102444.png]]
+
+## 1.6 Links
+
+### 1.6.1 cosc 202
+
+[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
+
+### 1.6.2 info 201
+
+[tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
+
+[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)

content/daily_notes/2022-04-09.md

@@ -0,0 +1,45 @@
+[[notes/daily-notes]]
+
+---
+
+# 1 2022-04-09
+
+Toys In The Attic - Aerosmith - spotify:album:36IxIOGEBAXVozDSiVs09B
+
+## 1.1 Todos
+- [x] Cosc201 Lecture 11
+- [x] Cosc201 Lecture 12
+- [x] info 201 lab 05
+- [ ] info 201 lab 05
+- [ ] 12:00 Info201 Lab 06
+- [ ] Assignment 3
+- [ ] Cosc201 Tutorial
+- [ ] inquire about dataview in quartz
+
+- [ ] Cosc201 Lab Shuffle
+## 1.2 Lecture/Labs
+
+
+
+## 1.3 Assignments
+
+## 1.4 Projects
+- python ai weekly review
+- CI notes site
+- my own password manager
+
+## 1.5 Timetable
+
+![[Pasted image 20220311102444.png]]
+
+## 1.6 Links
+
+### 1.6.1 cosc 202
+
+[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
+
+### 1.6.2 info 201
+
+[coursework](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
+
+[Assignments](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)

content/notes/08-mergesort-2.md

@@ -1,7 +1,7 @@
 ---
 title: "08-mergesort-2"
-sr-due: 2022-04-06
+sr-due: 2022-06-05
-sr-interval: 8
+sr-interval: 59
 sr-ease: 270
 tags: 
 - cosc201

content/notes/11-continuous-integration-2.md

@@ -8,42 +8,40 @@ tags:
 - lecture
 ---
 
-1. apprecitae that gitlab is a xomplex software
+1. Apprecitae that GitLab is a complex software
 2. Understand where CI jobs scripts get run
-3. explain why reposityory servers can host websites
+3. explain why repository servers can host websites
-4. Understandhow gitblab dternmimines awhen a CI script failed
+4. Understand how gitblab dternmimines awhen a CI script failed
-5. Describe a way in which CI scrupts scan handle secrets
+5. Describe a way in which CI scripts scan handle secrets
-6. OUtline uses of local git hook scripts
+6. Outline uses of local git hook scripts
 
+CI runs pipelines defined in .gitlab-ci.yaml asynchronously
 
+CI usually tests and builds your projects
 
-CI runs pipellines defined in .gitlab-ci.yaml asynchronously
+Runs on a repo server. Usually persistent, internet accessible
 
-CI usually tets abd buiolds your prokects
+# 1 GitLab overall architecture
-
-runs on a repo server. Usuially persistent, internet accessible
-
-# 1 Gitlab overall architecture
 ![](https://i.imgur.com/whU7QoF.png) : not in exam
-- many different services used
+- many services used
 
-# 2 Gitlab runners
+# 2 GitLab runners
 run CI scripts
 
 - gitlab.com is a cloud computing service
 - allows elf hosting which is what CS does
-	- altitude is a gitlab instance at CS
+	- altitude is a GitLab instance at CS
 		- servers to host runners that run CI scripts
 		- servers that host websites, e.g., cspages.otago.nz
-- Gitlab can invoke runners that you host
+- GitLab can invoke runners that you host
 	- e.g., to use a particular GPU, or other hardware you have
-	- GItlab runner itself is a small program written in Go
+	- GitLab runner itself is a small program written in Go
 
 ## 2.1 Runner architecture
 
 - runs jobs
 	- on isolated infrastructure
-	- ... to maintain secrity
+	- ... to maintain security
 - that is set up on demand
 	- ... handle load variation
 - suits cloud computing
@@ -54,30 +52,30 @@ RHS shows GitLab.com's CI hosting: uses google cloud
 
 ![](https://i.imgur.com/RaeYc1I.png) : not in exam
 
-# 3 How CI chagned website hosting
+# 3 How CI changed website hosting
 
-- need to share stifacts produced by CI jobs
+- need to share artifacts produced by CI jobs
-	- using the web to share artefacts is ideal
+	- using the web to share artifacts is ideal
 	- so now most repo servers also  host websites
 	- these are static websites: all content is fixed
 - CI can run static website generators (SSGs)
 	- git repo contains source code of website
-	- CI pipelines transforms souce code into HTML fiels
+	- CI pipelines transforms source code into HTML files
 	- HTML files then hosted as a website by repo sever
 
 e.g., https://cosc202.cspages.otago.ac.nz
 
 # 4 Debugging CI scripts
 
-- first ensure config files YAML is valid
+- First ensure config files YAML is valid
-	- vuilt in gitlab editor checks YAML as you type
+	- built in GitLab editor checks YAML as you type
-- commands runfrom shell that fail return an exit code
+- commands run from shell that fail return an exit code
-	- most unix shells sotre exit code of previous commands in $
+	- most Unix shells store exit code of previous commands in $
-	- So if variable $? (return code of prevous command) is non-zero, the previous command failed
+	- So if variable $? (return code of previous command) is non-zero, the previous command failed
 - Git lab considers CI job as failed if any command fails
 	- your shell scripting can choose to hide this exit code
 		- e.g., `if command supposed to fail; then true; else true; fi`
-	- Complex scripting? Beste to put script in a file and run it from CI
+	- Complex scripting? Best to put script in a file and run it from CI
 
 # 5 Secrets used by CI scripts
 

content/notes/11-sets-maps-trees.md

@@ -0,0 +1,15 @@
+---
+title: "11-sets-maps-trees"
+tags: 
+- cosc201
+- lecture
+sr-due: 2022-04-12
+sr-interval: 3
+sr-ease: 250
+---
+
+A [set](notes/set.md) is a collection of elements with no repetition allowed
+
+A [hash-map](notes/hash-map.md) is a set of key value pairs
+
+A [tree](notes/tree.md) is a general concept of a way of organising data.

content/notes/11-trees-and-ordered-sets.md

@@ -0,0 +1,9 @@
+---
+title: "11-trees-and-ordered-sets"
+tags: 
+- cosc201
+- lecture
+---
+
+
+

content/notes/12-binary-search-tree-operations.md

@@ -0,0 +1,13 @@
+---
+title: "12-binary-search-tree-operations"
+tags: 
+- cosc201
+- lecture
+sr-due: 2022-04-12
+sr-interval: 3
+sr-ease: 250
+---
+
+Recall [binary-search-tree](notes/binary-search-tree.md)
+
+[binary search tree operations](notes/bst-operations.md)

content/notes/12-modelling-behaviour.md

@@ -3,6 +3,9 @@ title: "12-modelling-behaviour"
 tags: 
 - cosc201
 - lecture
+sr-due: 2022-04-10
+sr-interval: 3
+sr-ease: 250
 ---
 [slides](https://blackboard.otago.ac.nz/bbcswebdav/pid-2892846-dt-content-rid-18407618_1/courses/INFO201_S1DNIE_2022/2022/lectures/lecture_12_slides.pdf)
 
@@ -139,3 +142,50 @@ Anything coded to work with Collection will accept *any* Java collection type. (
 ![](https://i.imgur.com/TCNp6vY.png)
 
 
+## 3.2 Contrast with anaemic domain models
+
+- 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. 
+- De facto standard for most programmers/systems
+
+![](https://i.imgur.com/snGpG4m.png)
+
+
+## 3.3 Reducing the plumbing in anaemic models 
+
+- Frequently need to move data between domain objects and other (sub)systems, e.g.: 
+	- GUI components (see INFO 202) 
+	- data stores (also see Lecture 17) 
+	- barcode management subsystem 
+	- shipping (sub)system 
+	- inventory (sub)system 
+	- … 
+- “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)
+
+![](https://i.imgur.com/EoX8sTA.png)
+
+# 4 Lecture summary 
+
+- There are a variety of behavioural diagrams in UML. 
+- 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”. 
+- anaemic more common 
+- use “processors” to encapsulate “plumbing” code
+
+# 5 Revision questions 
+
+1. Compare and contrast the two typical approaches to inheriting behaviour in OO systems. 
+2. What does it mean to “program to an interface” and why is this important?
+3. Compare and contrast “rich” versus “anaemic” domain models with regards to behaviour.
+4. Give an example of a “processor” in the context of OO system design and explain why these are useful.

content/notes/andie.md

@@ -0,0 +1,18 @@
+---
+title: "Untitled"
+tags: 
+- cosc202
+- assignment 
+---
+
+Todo
+
+- [ ] todo
+
+Issues
+
+- [ ] "no obs file" popup when opening new image
+
+
+
+

content/notes/binary-search-tree.md

@@ -0,0 +1,38 @@
+---
+title: "binary-search-tree"
+aliases: binary search tree, BST
+tags: 
+- cosc201
+- datastructure
+---
+
+[code](https://blackboard.otago.ac.nz/bbcswebdav/pid-2890167-dt-content-rid-18354839_1/courses/COSC201_S1DNIE_2022/BST.java)
+
+[bst-operations](notes/bst-operations.md)
+
+a collection of *nodes* with one distinguished node called the root
+
+rules:
+- the node data contains a key which comes from some ordered type e.g., `string`
+- each node can have at most who children - there are two fixed slots called left child and right child
+- the left child node and it descendents are called the left subtree
+- the key value at a nodes *left child* (and all its descendants) must be *less* than the key of the node
+- the key value at a nodes *right child* (and all its descendants) must be *greater* than the key of the node
+- we do not allow duplicate keys
+
+Notation
+- n.key for key
+- n.l and n.r for left and right children
+- n.p for its parent
+- nil for a "not here" marker. e.g.,  n.r = nil means "n has no right child"
+
+e.g., 
+![300](https://i.imgur.com/n0IzHW7.png#invert)
+
+In this example:
+- root.p = nil
+- root.r = n
+- n.p = root
+- n.key = emu
+- n.l = nil
+- n.r.key = rat

content/notes/bst-operations.md

@@ -0,0 +1,131 @@
+---
+title: "bst-operations"
+aliases: binary search tree operations, bst operations
+tags: 
+- cosc201
+---
+
+# Search operation
+
+We want to search in a BST for a key `k` returning `true` if it is found and `false` if it is not
+
+```
+def search(k)
+	n <- root
+	while n ≠ nil do
+		if n.key = k then
+			return true
+		else if n.key < k then
+			n <- n.r
+		else
+			n <- n.l
+		end if
+	end while
+	return false
+```
+
+Its naturally recursive
+
+Method `search(k)` calls `search(k, root)` wher the two-parameter version `search(k, n)` is defined by:
+
+```
+def search(k, root)
+	if n = nil then
+		return false
+	else if n.key = k then
+		return true
+	else if n.key < k then
+		return search(k, n.right)
+	else
+		return search(k, n.left)
+	endif
+```
+
+Cost of search is at  most the length of the longest branch. So we want to keep the trees short and "bushy"
+
+# Add Operation
+
+We want ot add a key `k` to a BST returning `true` if added or `false` if already present.
+
+This is similar to search:
+```
+def add(k)
+	p <- nil, c <- root
+	while n ≠ nil do
+		p <- c
+		if p.key = k then
+			return false
+		else if n.key < k then
+			c <- p.r
+		else
+			c <- p.l
+		end if
+	end while
+	make child node of p with value k
+	return true
+```
+
+To make a child: 
+
+Make sure this is really what we want to do:
+- k is not the key of p
+- the pos where this node will be added is currently nil
+
+```
+def makeChild(p, k)
+	c <- new(k), c.p <- p
+	if p.key < k then
+		p.r <- c
+	else
+		p.l <- c
+	end if
+```
+
+
+# Remove operation
+
+If the node to delete is a leaf, we can simply make it nil.
+
+If the node has only one child, we simply make the nodes child the child of the nodes parent
+
+If the node has two children, we replace it with its *successor* (the leftmost descendant of its right child)
+
+``` java
+private void delete(Node n) {
+    if (n == root) {
+        deleteRoot(); return;
+    }
+    if (n.left == null) {
+		addLink(n.parent, n.right, linkType(n.parent, n));
+		return;
+    }
+    if (n.right == null) {
+        addLink(n.parent, n.left, linkType(n.parent, n));
+        return;
+    }
+    Node sn = successor(n);
+    String s = sn.key;
+    delete(sn);
+    n.key = s;
+}
+```
+
+# Traversal
+
+Visit each node in the tree once. So we need to visit n, all the nodes in L, and all the nodes in R. We can do this in three different ways
+
+preorder
+- visit n
+- traverse L
+- traverse R
+
+Inorder. 
+- traverse L
+- visit n
+- traverse R
+Creating an BST from an array using the add operation then doing an inorder traversal is effectively a [quicksort](notes/quicksort)
+
+postorder
+- traverse L
+- traverse R
+- visit n

content/notes/conceptual-vs-ipmlementation-models.md

@@ -0,0 +1,20 @@
+---
+title: "conceptual-vs-ipmlementation-models"
+tags: 
+- info201
+---
+
+Models like ERDs are used to represent a high level conceptual overview of a system, or to as a lower level specification that can drive the implementation of the database.
+
+** Conceptual
+
+- Abstract/big-picture
+- Useful in inital design stages and for communication
+
+** Implementation
+
+- Concrete/detailed
+- Useful in documenting and specifying structure (for devs etc)
+- Should be detailed and specific enough to allow a dev to implement it without having to guess at details
+- Should be tailored to the specific implementation technologies or systems
+- 

content/notes/continuous-integration-draft.md

@@ -0,0 +1,26 @@
+---
+title: "continuous-integration"
+aliases: continuous integration, CI
+tags: 
+- cosc202
+---
+
+Continuous integration (CI) is the practice of automating the integration of code changes from multiple contributors into a single software project -  [atlassian](https://www.atlassian.com/continuous-delivery/continuous-integration) . It allows you to automatically run tests, builds, etc when the code is changed. 
+
+A continous integration can be defined as a *Pipeline* with several *stages*, each stage with several *jobs*
+
+A continuous integration pipeline will run whenever it is triggered. It can be triggered on a schedule, manually, or whenever code is changed. These pipelines run *asynchronously* i.e., the dev doesnt't have to wait for it to complete.
+
+Pipelines can also be run locally, and can be triggered, as you, commit, save, type etc. 
+
+Pipeline can produce several forms of asynchonous output such as email notifications, web badges, webhooks, etc. In addition, most VCS hosting platforms capture the terminal logs from the CI scripts.
+
+Most CI frameworks use YAML for configuration. YAML has a structured text based format similar to python and json
+
+The CI config (in gitlab it is named `.gitlab-ci.yaml`) file goes in the top level of the repo, and is version-managed. This file specifies the stages and jobs of a pipeline, as well as indicating where the output should go.
+
+#unfinished 
+
+[10-continuous-integration-1](notes/10-continuous-integration-1.md)
+
+[11-continuous-integration-2](notes/11-continuous-integration-2.md)

content/notes/continuous-integration.md

@@ -1,10 +1,10 @@
 ---
 title: "continuous-integration"
+aliases: continuous integration, CI
 tags: 
 - cosc202
 ---
-
+## 0.1 What is it
-## 1 What is it
 continuous --> is always happening
 integration --> connecting software components
 
@@ -17,7 +17,7 @@ integration --> connecting software components
 
 - usually automated
 
-## 2 Purposes
+## 0.2 Purposes
 - checking code syntax
 	- e.g., have CI compile the code and report errors
 	- (local devs compilaer may be different from remote)
@@ -27,14 +27,14 @@ integration --> connecting software components
 - running projects code tests
 	- auto run JUnit, and report fails
 
-## 3 Starting CI jobs
+## 0.3 Starting CI jobs
 - from version control
 	- e.g., every commit triggered CI jobs to run
 	- starts on a push to server
 - manually
 - on a schedule
 
-## 4 Runs asnychronously
+## 0.4 Runs asnychronously
 - dont require devs to wait for completion
 - common to run locally as well as on consistent standard environment
 
@@ -43,7 +43,7 @@ integration --> connecting software components
 	 - checks as you type
 	 - checks as you save
 
-## 5 Output
+## 0.5 Output
 since CI is asynchronous, its feedback is also
 
 - e.g., 
@@ -55,7 +55,7 @@ since CI is asynchronous, its feedback is also
 
 git project websites usually provide logging interface,. They will watch scripts in virtual terminal and capture output from CI scripts
 
-## 6 Github piplines
+## 0.6 Github piplines
 
 - a pipeline has multiple _stages_
 	- e.g., test, build, deploy
@@ -63,13 +63,13 @@ git project websites usually provide logging interface,. They will watch scripts
 - each stages has multiple _jobs_
 	- e.g., JUnit, custom tests, etc
 
-## 7 Yaml
+## 0.7 Yaml
 
 - most Ci frameworks use YAML for their configuration
 - structured text based formats
 - python-like format or ≈JSON
 
-## 8 configurationg from git repo
+## 0.8 configurationg from git repo
 
 - CI config often via file in git top-level directory
 - CI is version managed

content/notes/cosc-201-lectures.md

@@ -9,4 +9,6 @@ links: [[notes/cosc-201]]
 - [07-mergesort-1](notes/07-mergesort-1.md)
 - [08-mergesort-2](notes/08-mergesort-2.md)
 - [09-stacks-and-queues](notes/09-stacks-and-queues.md)
-- [10-heaps-and-heapsort](notes/10-heaps-and-heapsort.md)
+- [10-heaps-and-heapsort](notes/10-heaps-and-heapsort.md)
+- [11-sets-maps-trees](notes/11-sets-maps-trees.md)
+- [12-binary-search-tree-operations](notes/12-binary-search-tree-operations.md)

content/notes/cosc-201.md

@@ -6,7 +6,7 @@ tags:
 - course
 - cosc201
 ---
-links: [_index](/)
+links: [_index](_index.md)
 
 - [cosc-201-outline](notes/cosc-201-outline.md)
 - [cosc-201-lectures](notes/cosc-201-lectures.md)

content/notes/cosc-202.md

@@ -11,9 +11,8 @@ links: [_index](_index.md)
 - [cosc-202-lectures](notes/cosc-202-lectures.md)
 - [cosc-202-outline](notes/cosc-202-outline.md)
 
-## 0.1 Assignments
+# 1 Assignments
 
 - 
-
+# 2 Resources
-## 0.2 Resources
 

content/notes/entity-relationship-diagrams.md

@@ -13,7 +13,7 @@ labels are important - but not always needed
 
 associative entity => changes many to many relationship with additional relationship
 
-## 1 subtypes
+## 0.1 subtypes
 ![](https://i.imgur.com/5sgPCxO.png)
 ![](https://i.imgur.com/Q0jMI3b.png)
 
@@ -21,7 +21,7 @@ uses:
 - model mutual exclusivity
 - better for modelling not for implementation
 
-## 2 parallel relationship
+## 0.2 parallel relationship
 ![](https://i.imgur.com/UJXPI1l.png)
 
 could model as separate relationships via staff subtypes
@@ -31,12 +31,12 @@ not very common
 
 also an example of recursive many-to-many relationships
 
-## 3 recursive relationship
+## 0.3 recursive relationship
 labels are critical
 usually 1:M can be 1:1 or M:M
 ![](https://i.imgur.com/CaEgEkp.png)
 
-## 4 dealing with data history
+## 0.4 dealing with data history
 ![](https://i.imgur.com/cohxggK.png)
 
 could be many to many relationships:![](https://i.imgur.com/g4ynsh2.png)

content/notes/hash-map.md

@@ -0,0 +1,16 @@
+---
+title: "hah-map"
+aliases: map, hash map, hash set
+tags: 
+- cosmc201
+- datastructure
+---
+
+In compsci a map is a comprised of a set of keys and values. (`<K, V>`). For example `<String, Integer>`
+
+So sets are a prerequisite for maps
+
+The fundamental map operations are:
+- `Put(k, v)` --> Add the this key-value pair to the map. If the present: update the key
+- `Get(k)` --> returns the value associated with `` is present
+- `Remove(k)` --> Removes the key `k`

content/notes/info-201-lectures.md

@@ -12,4 +12,4 @@ links: [[notes/info-201]]
 - [09-data-modelling-and-normalisation](notes/09-data-modelling-and-normalisation.md)
 - [10-oop-concepts-and-uml](notes/10-oop-concepts-and-uml.md)
 - [11-class-diagrams](notes/11-class-diagrams.md)
-- 
+- [12-modelling-behaviour](notes/12-modelling-behaviour.md)

content/notes/info-201.md

@@ -10,3 +10,7 @@ links: [_index](_index.md)
 
 - [info-201-lectures](notes/info-201-lectures.md)
 - [info-201-outline](notes/info-201-outline.md)
+
+- [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
+- [assignmentsl](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/info201_assignments.html)
+

content/notes/set.md

@@ -0,0 +1,58 @@
+---
+title: "set"
+aliases: sets, Set, Sets
+tags: 
+- cosc201
+- datastructure
+---
+
+links: [java docs](https://docs.oracle.com/javase/7/docs/api/java/util/Set.html) for set interface
+
+> A collection of items with no repetition allowed
+
+How do we want to be able to use them? 
+- We want to be able to add to them
+- And Remove from them
+- And check if it contains something
+
+This gives us the methods:
+- `Add(x)`
+- `Remove(x)`
+- `Contains(x)`
+
+Binary search trees are data types that supprts this ddata type when there is an ordering on the runderlying elements'
+
+[hash sets and hash maps](notes/hash-map.md) do the same when there is no order.
+
+## 0.1 Basic set
+
+Simplest way would be to use a list or an array.
+
+[Code for basic set](https://blackboard.otago.ac.nz/bbcswebdav/pid-2890167-dt-content-rid-18354837_1/courses/COSC201_S1DNIE_2022/BasicSet.java)
+
+- Contains: Simple linear search
+- Add: Check if it is present, if not add it to the end
+- Remove: Delete the element and replace it with the last element
+	- This leaves empty elements at the end.
+	- So we keep track of the size
+
+All three operations are $O(n)$ as they must all iterate over the entire set
+
+## 0.2 Ordered set
+
+A set with some underlying "natural" order. E.g., dictionary order for `string` objects.
+
+We would also like to be able to do a in order *traversal*
+
+If the set is static
+- store using sorted array
+- use binary search to find elements --> $O(lg\ n)$
+- traverse by incementing a counter --> $O(lg\ n)$ to init then $O(1)$
+
+But then:
+- `Add(x)` Insert `x` if its not already present, so we start a search which is fine, but then insertion is $O(n)$ 
+- `Remove(x)` find `x` if present, then move eyerthing beyond it back over the top --> $O(n)$
+
+This is fine if we dont expect to use the dynamic operations a lot. 
+
+Another approach might be to maintain a `main` array and a subsidary `add` and `remove` arrays and only periodically do the updates to the main array. but this gets complicated very quickly

content/notes/tree.md

@@ -0,0 +1,37 @@
+---
+title: "tree"
+tags: 
+- cosc201
+- datastructure
+---
+
+not so much a data type. More of a data concept of a way in which data can be organised
+
+The first example we saw was with the chains of representatives in [union-find](notes/union-find.md)
+
+The type required for the ordered [set](notes/set.md) data type is the binary tree
+
+Trees in general:
+- Consists of *Nodes*
+- One node is distinguished and called the *root*
+- Each node, except the root, has a uniquw *parent*
+- Any chain that moves from a mnode to its parent , its grandparent etc, eventually reaches the root.
+- The *children* of a nore arll the nodes of which it is the parent
+- Nodes may (and usually do) have additional data associated to them. (does not affect the structure)
+- Nodes with no children are *leaves*
+
+For example: 
+
+- *cat* is the root (root is drawn at the top)
+- the parent of *dog* is cat*,* of *rat* is *emu*
+- some nodes have two children, one has three (*emu* ) and some have none.
+
+![300](https://i.imgur.com/EsrTuFL.png#invert)![300](https://i.imgur.com/bQmzPaU.png#invert)
+
+The only differnce between these two trees is the *order* of the elements. 
+
+We need to specify whether this makes them different or not. In computer science, order usually *does* mater. These are sometimes called*plane trees*.
+
+Sometimes there are fixed slots for the children e.g., 
+
+[binary-search-tree](notes/binary-search-tree.md)

content/notes/version-control-system.md

@@ -1,5 +1,6 @@
 ---
 title: "version-control-system"
+aliases: VCS, version control system
 tags: 
 - info201
 ---
@@ -7,7 +8,7 @@ tags:
 VCSs (version control systems) Are systems to keep track of changes to a set of files
 E.g., [[git]]
 
-## 1 Goals
+## 0.1 Goals
 - allow collaboration
 - track changes
 - restoring previous versions
@@ -15,16 +16,16 @@ E.g., [[git]]
 - backups
 - not restrict workflow
 
-## 2 Terms
+## 0.2 Terms
 [[cheatsheets/git-cheat-sheet]]
 
-## 3 Discipline
+## 0.3 Discipline
 - Pull/Push Regularly
 - Use topic/features branches to keep main clean
 - Dont use -f
 
-## 4 Types
+## 0.4 Types
-### 4.1 Centralised VCS
+### 0.4.1 Centralised VCS
 - Data is stored in one single central location
 - Access is remote
 - Checkout can block other devs
@@ -38,7 +39,7 @@ E.g., [[git]]
 	end
 ```
 
-### 4.2 Distributed VCS
+### 0.4.2 Distributed VCS
 
 ![](https://i.imgur.com/IVXAaFF.png)
 
@@ -49,18 +50,18 @@ E.g., [[git]]
 - Bad
 	- Hard to keep track of "main" files
 
-### 4.3 Distributed + Centralised
+### 0.4.3 Distributed + Centralised
 - Main files are stored on central repo
 - Each user also has their own copy locally
 
 ![](https://i.imgur.com/BxC8Tiq.png)
 
-## 5 Sensitive information
+## 0.5 Sensitive information
 - Passwords and other credentials among other things
 - Data should be stored as encrypted blobs
 	- [BlackBox](https://github.com/StackExchange/blackbox)
 
-## 6 Forking
+## 0.6 Forking
 - Cloning into a new remote repo in your account
 - Allows community to contribute to projects without giving them write access to the original repo
 - Process
@@ -69,7 +70,7 @@ E.g., [[git]]
 	- Pull request to merge fork back into project
 	- Admins of project can acccept modify or reject pull request
 	
-## 7 software dev needs file wrangling
+## 0.7 software dev needs file wrangling
 many copies of a project's source code files needed:
 
 - facilitating different developers private code experiments

content/private/cv.md

@@ -0,0 +1,26 @@
+# **Jet Hughes**
+
+mobile: 0276509548
+email: jethughes0@gmail.com
+
+---
+# **Profile**
+
+Intern with 1 year experience of translating e-learning modules. Currently, studying computer science and finance at Otago University.
+
+---
+# **Education**
+
+Otago University (2021 - present)
+- Bachelor of commerce and science in computer science and finance
+- Expected graduation November 2023
+
+---
+# **Experience**
+
+Intern - Company-X (Dec 2020 - present)
+- Learn't complex process of translating e-learning modules in less than one week
+- Trained new hires in process
+- Increased efficiency of process from ~4 hrs to ~2.5hrs
+- Used Jira, git (with Bitbucket), google sheets, excel, SharePoint, slack
+- Co-ordinated with an international team

content/private/info201-lab05-transcript.md

@@ -0,0 +1,149 @@
+**Analyst:** Good to see you again. I'm hoping to get some more clarity and detail on a couple of main aspects of the system, specifically the information that needs to be stored—data requirements, in other words—and also details of how you conduct some of the main business process.
+
+**Client:** That sounds fine...I'll try to help as best I can.
+
+**Analyst:** Thanks. Hmm, so I remember you described the process of ==enrolling students, which involves an audition that has to be scheduled and passed, and then fees would be paid, with scholarships potentially available for special situations. And presumably you'd want to record which staff member actually conducted the audition==, so perhaps we should start there. What information would you need to record about the staff you employ? Just in general, not necessarily relating to the auditioning process.
+
+**Client:** Right, the ==main information we record on staff would be their name, their contact details,== ...
+
+**Analyst:** So ==postal address, phone number==?
+
+**Client:** Yes. Most have a ==land line in their office, but we'd also want their mobile number and/or home number== for after-hours contact in emergencies. ==They have a standard e-mail address issued through the school==, which we use for all work-related memos and suchlike.
+
+**Analyst:** And ==you're happy to record their surname separately for ease of sorting and searching?==
+
+**Client:** I think that would make sense, yes. Let's see, what ==other details...ah, their qualifications, and also their salary==.
+
+**Analyst:** Right, of course. And are staff issued with any sort of ID card? Specifically, is there already a unique staff ID number that we could use in the system?
+
+**Client:** Yes, actually—==all staff are given a card with their details printed on it, and it also acts as a security swipe card for building access, photocopying, and the like.==
+
+**Analyst:** Great, that's handy. It would be good to have a sample copy of one or two so we can make sure that the data models covers everything. And what do the staff identifier values actually look like?
+
+**Client:** ==They have a letter indicating the kind of job they have—things like “A” for academic staff, “G” for general, “T” for tutors—followed by a number...4 digits==, I think.
+
+**Analyst:** OK, and that==set of job categories would be a well-defined list that you might want to change occasionally==?
+
+**Client:** Well-defined, yes...and I suppose there could be new job types added in future—it's a changing world!
+
+**Analyst:** I'm just thinking it would make certain forms and reports a bit easier to construct if you had a definitive list of them—for example, if you wanted a list of staff grouped and ordered by their job category.
+
+**Client:** OK, yes, could be quite useful then.
+
+**Analyst:** Now back to the ==auditions==: what information needs to be recorded there?
+
+**Client:** Well, there's the ==date and time of the booking, the audition room, the staff members attending...and the student==, of course.
+
+**Analyst:** So there ==could be more than one staff member== attending?
+
+**Client:** Yes, we often assign two or three staff as we like to have assurance of a fair and thorough assessment, especially as the available staff may not be experts in the instrument the student is playing. They can confer to sort out any differences of opinion.
+
+**Analyst:** Now for ==students, I guess you would record similar information to staff==?
+
+**Client:** Yes, let's see...yes, it's ==largely the same, and in fact we give students a school e-mail address as well. But not a phone number==, of course!
+
+**Analyst:** Right. ==And some kind of student ID==?
+
+**Client:** Yes—those are just a ==unique number, 7 digits, no special prefix or anything==.
+
+**Analyst:** And ==when do those get issued? What I'm wondering is, can you book an audition for a student who hasn't been assigned an ID number ye==t?
+
+**Client:** Ah, I think I see the issue there..==.at present we just take their name and contact details and what instrument they play, and make the booking==.
+
+**Analyst:** Mm, that could present a problem because we can't just use their name or even contact details to reliably identify them. ===We could have the system issue an ID number for them immediately they're recorded into the system, even if they end up failing the audition or not enrolling fully for other reasons===. Would that be OK?
+
+**Client:** I think so—I mean, the numbers are just numbers and we're not particularly precious about maintaining the sequence or anything.
+
+**Analyst:** Good, I think that will be a good way to work it, then. And the ==outcome of the audition—how is that recorded==?
+
+**Client:** Just a==pass/fail result.== The staff who attended the audition discuss their impressions and make that decision themselves. At the moment we ==keep their audition sheets in case there are any disputes further down the line==.
+
+**Analyst:** I see...so the system should probably ==record their notes and comments== as well...
+
+**Client:** Yes, that would save having to keep the paper copies hanging around!
+
+**Analyst:** Great, we'll do that then. Now for the ==enrolment details==...
+
+**Client:** That's pretty straightforward: ==if they pass the audition, the student is eligible to enrol fully. We treat each enrolment as lasting a single year==, because they have to pay annually and because students will sometimes drop out after a year or two. But they're ==not considered fully enrolled until their fees for the year are paid up==.
+
+**Analyst:** Yes, and you mentioned they could be eligible for a scholarship as well...
+
+**Client:** That's right—==scholarships are handled by a separate body, so we don't have much to do with that. We only really need to know that it was approved and that the funds are available.==
+
+**Analyst:** OK, but you would want to record any fee demands issued and any payments for accounting purposes?
+
+**Client:** Yes, definitely:==invoices and payment receipts all need to be recorded accurately for accounting==.
+
+**Analyst:** OK, so you would want to ==record the student enrolling, the year of enrolment, and whether their fees are paid for that year==. Oh, ==and their specialist instrument too==...hmm, could they ever have more than one of these?
+
+**Client:** Actually quite a few of our students are multi-instrumentalists, but at this level the training is for a high-level of specialised performance, and so ==each student has just one specialist instrument==.
+
+**Analyst:** If they do have additional instruments they can play, would you you want that recorded anywhere?
+
+**Client:** That could actually be quite useful in looking for possible tutors or understudies or ring-ins for other performing groups.
+
+**Analyst:** OK, so we could potentially list all instruments that each student can play, which would allow easy searching and reporting, or we could ==simply record those additional skills in a notes field associated with the student==.
+
+**Client:** The searching and reporting capability sounds handy...
+
+**Analyst:** I think it would come down to how often such a search would be useful—someone would have to record the information in order for it to be used.
+
+**Client:** Ah, OK...well, it probably doesn't happen very often, so maybe just a notes field would be sufficient.
+
+**Analyst:** OK, we can go for that simpler option and test that it's satisfactory later on. Now, for hiring ==instruments==, you mentioned a ==lettering and numbering scheme for identifying== those—what do those codes typically look like?
+
+**Client:** ==A typical one would be something like VLA37, where the VL tells us it's a violin, the A is for standard size, and 37 is the instrument numbe==r.
+
+**Analyst:** And do all ==instruments have various sizes available?== What would be the typical sizes?
+
+**Client:** No, ==most of them just come in a standard size==. I should note that the sizes are different from registers such as contrabass flute, which plays a different range of notes. The sizes are to accommodate larger or smaller performers, but the instruments are still tuned to the same tuning. Most adult players would be encouraged to play the standard full-sized instrument if possible, but as you can imagine, someone who is naturally physically very small might struggle with a full-sized double bass or bassoon.
+
+**Analyst:** I see. And the ==available sizes==? Is it always just A, B, C, ...? How far along the alphabet do they go?
+
+**Client:** Yes, we just use a==single-letter code. A for full size, B for 3/4, C for 1/2,== and that's as far as we would ever need to go. I should point out that those sizes are just nominal: a quotes-half-size instrument typically isn't literally half the size!
+
+**Analyst:** I'm wondering how many instruments might you have of each type? ==And are the instrument type codes always a two-letter value like VL?==
+
+**Client:** I think they're all two letters; I'd have to check if there are any exceptions to that.
+
+**Analyst:** Right, it ==might be prudent to allow longer codes just in case==. But that shouldn't be a problem. ==And how many instruments might you have of each type?==
+
+**Client:** Not more than 100 for most instruments. We might have a hundred-and-something violins, actually—they're quite popular.
+
+**Analyst:** OK, so we would need to ==support at least 3-digit instrument numbers==. Now for the ==class scheduling and streaming==: how does that work, and what needs to be recorded?
+
+**Client:** The ==first step there is to decide on the available class sessions==. That's ==partly down to how popular the class or instrument is, but is also based on teacher availability==. We==try to cap theory classes to around a dozen students==, and ==instrumental tuition to more like half a dozen==, but it ==depends on the class and the teacher==. We ==need to assign each class to a room as well==. ==Some rooms are set up for different uses==: ==some are basically classrooms with desks and chairs, and others are more like a small auditorium for instrumental classes and small ensembles==. ==We have a couple of larger auditoria for the bigger ensembles such as the symphony orchestra==. ==Once the weekly timetable is worked out, it's basically fixed for the whole year==.
+
+**Analyst:** OK, good. And what about ==results and grades==?
+
+**Client:** OK, that's a big one. At the moment, each teacher maintains a spreadsheet for each of their classes in which they record each student's result for each assessed item, such as a performance exam or theory test. At the moment, collating all of those is a bit of a nightmare, to be honest. Error-prone, fiddly, ...
+
+**Analyst:** I could imagine. What ==we should probably aim to do is put all of the recording of marks into a single place== so that it can be more easily managed and especially if you wanted to calculate the overall marks automatically.
+
+**Client:** That would be a life-saver! As long as ==teachers can have easy access to the system to record and check on grades==.
+
+**Analyst:** Such as ==via the Web or their phone==?
+
+**Client:** Yes, or ==for teachers who prefer to work on paper, it would be good if they could just give the results sheets to secretarial staff for data entry==...
+
+**Analyst:** Of course. And you mentioned earlier that you ==need to withhold final marks until they are confirmed==. How exactly does that process happen?
+
+**Client:** Well, the ==marks get recorded by individual teachers, then collated by admin staff and the total are calculated. Then they're sent back to the teachers for review==, ==in case there are discrepancies or surprises that need to be followed up. This might involve teachers meeting to discuss the discrepancy or reviewing the student's work. It could also trigger a re-count or a re-mark of anomalous assessments. Once that's all sorted out, the results can be made available.==
+
+**Analyst:** So that's ==releasing all of the results for all students at the same time==?
+
+**Client:** Yes, that's right.
+
+**Analyst:** So the exact date and time of release isn't something you would necessarily know in advance? That is, it's more like you would want to press a button to release the results?
+
+**Client:** I think a ==scheduled release would be better==. That way, we could tell the students in advance when to expect their results. At least, ==as long as we could update the release date in case we needed more time to deliberate==.
+
+**Analyst:** And it could be useful to ==have the student results mailed out to them automatically by e-mail?==
+
+**Client:** Yes, definitely—it's always good if we can get the results out to them as quickly as possible. We would still ==send a formal official copy in the post==, however.
+
+**Analyst:** OK, sure. Well, I think that just about wraps it up for now. Thanks again for all your insights and information.
+
+**Client:** Not a problem—hope it all helps!
+
+![](https://i.imgur.com/Njz40F5.png)

content/templates/DailyTemplate.md

@@ -2,26 +2,13 @@
 
 ---
 
-# {{date}}
+# 1 {{date}}
 
 <% tp.user.getAOTD() %>
 
-| # | task | P | A | e time | r time |
+## 1.1 Todos
-|---| ------------------------|---|---|--------| ------ |
-| 1 | | | | | |
-| 2 | | | | | |
-| 3 | | | | | |
-| 4 | | | | | |
-| 5 | | | | | |
-| 6 | | | | | |
-| 7 | | | | | |
-| 8 | | | | | |
 
-> SCORE:
+## 1.2 Lecture/Labs
-
-## 1 Todos
-
-## 2 Lecture/Labs
 
 <%*
 const d = new Date().getDay()
@@ -46,24 +33,24 @@ break;
 }
 %>
 
-## 3 Assignments
+## 1.3 Assignments
 
-## 4 Projects
+## 1.4 Projects
 - python ai weekly review
 - CI notes site
 - my own password manager
 
-## 5 Timetable
+## 1.5 Timetable
 
 ![[Pasted image 20220311102444.png]]
 
-## 6 Links
+## 1.6 Links
 
-### 6.1 cosc 202
+### 1.6.1 cosc 202
 
 [lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
 
-### 6.2 info 201
+### 1.6.2 info 201
 
 [tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)