mirror of
https://github.com/jackyzha0/quartz.git
synced 2025-12-24 05:14:06 -06:00
update quartz
This commit is contained in:
Jet Hughes
parent
eec8badee0
commit
2b8c007e90
@ -12,9 +12,9 @@ Dr. Octagonecologyst - Dr. Octagon - spotify:album:23DJ3KNE5JXi61G31T2Kni
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
- [ ] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] 16:00 Info201 Lecture
|
||||
- [x] 11:00 Cosc202 Lecture
|
||||
- [x] 12:00 Cosc201 Lab
|
||||
- [x] 16:00 Info201 Lecture
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
@ -32,4 +32,4 @@ Dr. Octagonecologyst - Dr. Octagon - spotify:album:23DJ3KNE5JXi61G31T2Kni
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
35
content/daily_notes/2022-04-29.md
Normal file
35
content/daily_notes/2022-04-29.md
Normal file
@ -0,0 +1,35 @@
|
||||
[2022-04-28](daily_notes/2022-04-28) << [daily-notes](notes/daily-notes.md) >> [2022-04-30](daily_notes/2022-04-30)
|
||||
|
||||
---
|
||||
|
||||
# 29-04-22
|
||||
|
||||
A Hard Day's Night - Beatles - spotify:album:6wCttLq0ADzkPgtRnUihLV
|
||||
|
||||
## Todos
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] use 1001 albums api
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
- [ ] 09:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
- Brainstorming
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
|
||||
## Links
|
||||
|
||||
### cosc 202
|
||||
|
||||
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
36
content/daily_notes/2022-04-30.md
Normal file
36
content/daily_notes/2022-04-30.md
Normal file
@ -0,0 +1,36 @@
|
||||
[2022-04-29](daily_notes/2022-04-29) << [daily-notes](notes/daily-notes.md) >> [2022-05-01](daily_notes/2022-05-01)
|
||||
|
||||
---
|
||||
|
||||
# 30-04-22
|
||||
|
||||
american dream - LCD Soundsystem - spotify:album:4AF1M7bGCFL3LHCtXUUXw5
|
||||
|
||||
## Todos
|
||||
- [ ] 14:00 Cosc202 Lab
|
||||
- [ ] use 1001 albums api
|
||||
- [ ] 09:00 Cosc202 Lab
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
- Brainstorming
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
|
||||
## Links
|
||||
|
||||
### cosc 202
|
||||
|
||||
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
35
content/daily_notes/2022-05-02.md
Normal file
35
content/daily_notes/2022-05-02.md
Normal file
@ -0,0 +1,35 @@
|
||||
[2022-05-01](daily_notes/2022-05-01) << [daily-notes](notes/daily-notes.md) >> [2022-05-03](daily_notes/2022-05-03)
|
||||
|
||||
---
|
||||
|
||||
# 02-05-22
|
||||
|
||||
Who's Next - The Who - spotify:album:5MqyhhHbT13zsloD3uHhlQ
|
||||
|
||||
## Todos
|
||||
- [ ] use 1001 albums api
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab 8
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
- [x] 11:00 Cosc202 Lecture
|
||||
- [x] 12:00 Cosc201 lab
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
- Brainstorming
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
|
||||
## Links
|
||||
|
||||
### cosc 202
|
||||
|
||||
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
37
content/daily_notes/2022-05-03.md
Normal file
37
content/daily_notes/2022-05-03.md
Normal file
@ -0,0 +1,37 @@
|
||||
[2022-05-02](daily_notes/2022-05-02) << [daily-notes](notes/daily-notes.md) >> [2022-05-04](daily_notes/2022-05-04)
|
||||
|
||||
---
|
||||
|
||||
# 03-05-22
|
||||
|
||||
Led Zeppelin III - Led Zeppelin - spotify:album:6P5QHz4XtxOmS5EuiGIPut
|
||||
|
||||
## Todos
|
||||
- [ ] use 1001 albums api
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab 8
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
- [x] 10:00 Info203 Lecture
|
||||
- [x] 11:00 Cosc201 Lecture
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
- [x] 14:00 Cosc202 Lab
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
- Brainstorming
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
|
||||
## Links
|
||||
|
||||
### cosc 202
|
||||
|
||||
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
37
content/daily_notes/2022-05-04.md
Normal file
37
content/daily_notes/2022-05-04.md
Normal file
@ -0,0 +1,37 @@
|
||||
[2022-05-03](daily_notes/2022-05-03) << [daily-notes](notes/daily-notes.md) >> [2022-05-05](daily_notes/2022-05-05)
|
||||
|
||||
---
|
||||
|
||||
# 04-05-22
|
||||
|
||||
Meat Is Murder - The Smiths - spotify:album:5DM1qCdgGt2zbknnsVn1Ca
|
||||
|
||||
## Todos
|
||||
- [ ] use 1001 albums api
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab 8
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
- [x] 10:00 Info203 Lecture
|
||||
- [x] 14:00 Info203 Tutorial
|
||||
- [x] 16:00 Cosc201 Tutorial
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
- Brainstorming
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
|
||||
## Links
|
||||
|
||||
### cosc 202
|
||||
|
||||
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
38
content/daily_notes/2022-05-05.md
Normal file
38
content/daily_notes/2022-05-05.md
Normal file
@ -0,0 +1,38 @@
|
||||
[2022-05-04](daily_notes/2022-05-04) << [daily-notes](notes/daily-notes.md) >> [2022-05-06](daily_notes/2022-05-06)
|
||||
|
||||
---
|
||||
|
||||
# 05-05-22
|
||||
|
||||
The Notorious Byrd Brothers - The Byrds - spotify:album:5UI2X5VAmgu9xrlXDd5U7B
|
||||
|
||||
## Todos
|
||||
- [ ] use 1001 albums api
|
||||
- [ ] 11:00 Cosc201 Lecture
|
||||
- [ ] 12:00 Info201 Lab 8
|
||||
- [ ] 13:00 Info201 Lecture
|
||||
|
||||
## Lecture/Labs
|
||||
|
||||
- [x] 11:00 Cosc202 Lecture
|
||||
- [ ] 12:00 Cosc201 Lab
|
||||
- [ ] 12:00 Info203 Tutorial
|
||||
- [ ] 16:00 Info201 Lecture
|
||||
|
||||
## Assignments
|
||||
- Mobile app
|
||||
- Brainstorming
|
||||
|
||||
## Projects
|
||||
- python ai weekly review
|
||||
|
||||
## Links
|
||||
|
||||
### cosc 202
|
||||
|
||||
[lab book](https://cosc202.cspages.otago.ac.nz/lab-book/COSC202LabBook.pdf)
|
||||
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
@ -1,7 +1,7 @@
|
||||
---
|
||||
title: "08-personas-and-scenarios"
|
||||
sr-due: 2022-04-30
|
||||
sr-interval: 23
|
||||
sr-due: 2022-07-01
|
||||
sr-interval: 60
|
||||
sr-ease: 250
|
||||
tags:
|
||||
- info203
|
||||
|
||||
@ -3,8 +3,8 @@ title: "09-data-modelling-and-normalisation"
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-04-30
|
||||
sr-interval: 3
|
||||
sr-due: 2022-05-11
|
||||
sr-interval: 9
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
|
||||
@ -3,8 +3,8 @@ title: "11-design-heuristics-2"
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-01
|
||||
sr-interval: 16
|
||||
sr-due: 2022-06-17
|
||||
sr-interval: 46
|
||||
sr-ease: 280
|
||||
---
|
||||
|
||||
|
||||
@ -4,83 +4,13 @@ aliases:
|
||||
tags:
|
||||
- cosc201
|
||||
- lecture
|
||||
sr-due: 2022-04-29
|
||||
sr-interval: 3
|
||||
sr-due: 2022-05-13
|
||||
sr-interval: 11
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
the height of a [BST](notes/binary-search-tree.md) is the length of its longest chain. Most operations are $O(n)$ where n is the height of the tree. In an Ideal situation each layer of the tree is full. The height of the tree is logarithmic to the number of nodes.
|
||||
|
||||
When a tree is being used only occainsonally, we can afford to simply rebalance is periodically. However when it is in constant use we cannot afford this cost
|
||||
|
||||
# Rotations
|
||||
|
||||
|
||||
sometimes two rotations are needed
|
||||
|
||||
## When to rotate and how to do them
|
||||
|
||||
basic idea is to modify the add and delete operations fo the BST to be somewhat self-balancing. This does not need to be perfect
|
||||
|
||||
We need a rule to decide when the tree is "balanced enough" and also strategies for fixing problems when the rule is violated.
|
||||
|
||||
We only need to fix the area local to the add or delete operations
|
||||
|
||||
# 1 - AVL tree
|
||||
most basic and obvious.
|
||||
|
||||
each node contains some extra information: the difference between the height of its right and left subtee. balance is maintained by ensuring that at every node this always at most 1
|
||||
|
||||
What is the least possible number of nodes in AVL tree of height k?
|
||||
|
||||
in general
|
||||
|
||||
$A_k= 1 + A_{k-1} + A_{k-2}$
|
||||
|
||||
we need a root 1, on one side a amallest possible tree of height $A_{k-1}$ then the other side must have height at least to $k-2$ to satisfy the rule, so we need at least $A_{k-2}$ more nodes.
|
||||
|
||||
The size if exponential in its height, and therefore its height is logarithmic in the size.
|
||||
|
||||
the operations are the same, but for each one we need to check and fix any excess imbalance along a single path from the affected leaf node up to the root.
|
||||
|
||||
for insertions, at most three rotations are rquired, for deletions the worst case is $O(lg\ n)$
|
||||
|
||||
# 2 - Red Black trees
|
||||
most used current one. Used in java treemap
|
||||
|
||||
each node is either red or black
|
||||
|
||||
the rules are:
|
||||
- the root node is black (optional)
|
||||
- all null nodes are _considered_ black (convention)
|
||||
- A red node may not have a red child
|
||||
- Every path from a node to a descendant null node contains the same number of black nodes
|
||||
|
||||
These guarantee that the longest path frm root to null (which could alternate red and black) is at most twice as long as the shortest path (which could be all black)
|
||||
|
||||
the tree is full up to half its height - growing at least as fast as $2^{h/2}$
|
||||
|
||||
the height is logarithmic in the size sinhce th tree must be complete to the depth of half the height
|
||||
|
||||
Operations that mnodify the tree require in the worst case $O(lg\ n)$ recolourings and (on average a constant number) and not more than three rotations
|
||||
|
||||
## Strategy
|
||||
- do an insertio and color the node red.
|
||||
- recolor and rotate nodes to fix violation
|
||||
- there are four scenarios
|
||||
-
|
||||
|
||||
# 3 - Treaps
|
||||
Link betwen heaps and trees that uses randomisation
|
||||
|
||||
I we are added items to a bst in random order then an unbalanced situation would be possible but highly unlikely.
|
||||
|
||||
a treap (portmanteau of tree and heap) is designed to achieve this even in the elements are not added in random order
|
||||
|
||||
when we add an element, we give it a random priority. Then after doing normal BST insertion we perform a series of rotations to fix the heap-ordering issues
|
||||
|
||||
the effect is that the elements look as if they were inserted in decending order of priority. SInce the priorities were randomly chosen, that means that at any time we see a BST which "thinks" that is elements were added in random order
|
||||
|
||||
# 4 - B-trees
|
||||
not actually a bst, but can be used for the same purpose
|
||||
[balancing-binary-search-trees](notes/balancing-binary-search-trees.md)
|
||||
|
||||
- [avl-trees](notes/avl-trees.md)
|
||||
- [red-black-trees](notes/red-black-trees.md)
|
||||
- [treaps](notes/treaps.md)
|
||||
|
||||
@ -4,104 +4,16 @@ aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-09
|
||||
sr-interval: 7
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
[containers](notes/containers.md)
|
||||
|
||||
* Describe what software containers are
|
||||
- Explain why containers are useful
|
||||
- Outline the role of container registries
|
||||
- Contrast different ways to interact with containers
|
||||
- Understand security risks inherent in container use
|
||||
|
||||
|
||||
# What are (software) containers?
|
||||
|
||||
- Containers encapsulate a computing environment
|
||||
- Facilitates portable and reproducible use of software
|
||||
- Can wrap up application code and data, and much of OS
|
||||
- Containers are lightweight virtual machines
|
||||
- You need to boot them up, as for any OS
|
||||
- . . . but containers start up very quickly
|
||||
|
||||
# What containers do and don’t include
|
||||
- Containers are generally Linux (virtual) machines
|
||||
- Even when hosted on Windows, containers are usually Linux
|
||||
- Microsoft Windows containers do exist though
|
||||
- Containers include the OS user space
|
||||
- e.g., distributions: Ubuntu, Debian, Arch. . .
|
||||
- Containers do not include Linux kernel
|
||||
- ... because all containers share one instance of the Linux kernel
|
||||
- Containers can’t themselves include hardware device drivers
|
||||
|
||||
# Using containers
|
||||
- We won’t explore how containers are hosted
|
||||
- COSC349 explores how the lightweight virtualisation works
|
||||
- We focus on using others’ containers
|
||||
- Making containers usable involves:
|
||||
- Management tools to control containers
|
||||
- Means for interacting with the containerised software
|
||||
- Somewhere from which to get their starter material. . .
|
||||
|
||||
# Container registries
|
||||
- Containers’ start up from an image
|
||||
- Think of images as a hard disk template
|
||||
- Images efficiently overlay layers of files and folders
|
||||
- Container registries store and share images: e.g.,
|
||||
- Docker Hub is a popular container registry
|
||||
- GitHub Container Registry (public; launched 2020)
|
||||
- GitLab Container Registry (private)
|
||||
- All major cloud providers provide registries
|
||||
- You can run on-site, private registry too
|
||||
|
||||
# Example container interacting with files
|
||||
- Let’s build the containers lab website
|
||||
- Input: Markdown files
|
||||
- Output: HTML website
|
||||
- Can use this container within CI
|
||||
- Active container can rebuild ‘live’:
|
||||
- source files are watched for changes
|
||||
- changes trigger rebuilding target files
|
||||
- can reload browser to see changes rapidly
|
||||
- Note: this example is an optional part of containers lab
|
||||
- docker run −−rm −−mount \ type=bind , source=$ {PWD} , ta rge t=/ s r v / j e k y l l \ j e k y l l / j e k y l l : pages j e k y l l bu i ld
|
||||
|
||||
# Example container interacting over network
|
||||
- Lesson builder can host an internal web server
|
||||
- Point browser running on host computer to network URL
|
||||
- Thus test built website, not just opening HTML files within it
|
||||
- Container framework can share container’s network
|
||||
- Typically expose key network ports of container on host
|
||||
- Connections routed through to container
|
||||
- Usually connections limited to interactions with the host OS
|
||||
- . . . but containers can support internet-facing servers
|
||||
- docker run −−rm − i t −−mount \ type=bind , source=$ {PWD} , ta rge t=/ s r v / j e k y l l \ −p 1 2 7. 0. 0. 1: 4 0 0 0: 4 0 0 0 \ j e k y l l / j e k y l l : 3 j e k y l l se rve
|
||||
|
||||
# Inter-container interactions
|
||||
- Can build apps by composing multiple containers
|
||||
- Either or both of file/network-based sharing commonly used
|
||||
- Need to consider how to orchestrate containers
|
||||
- Container orchestration is a COSC349 topic
|
||||
- e.g., coordinating multi-container start up
|
||||
- Kubernetes is the de facto container orchestrator
|
||||
- Creates reliable, scalable services from containers
|
||||
- Supported on all major cloud providers
|
||||
|
||||
# FYI: example multi-container application
|
||||
- Example: say you need to chart time-series data
|
||||
- InfluxDB is a dedicated time-series database
|
||||
- Grafana is a dedicated web-based charting system
|
||||
- Both are large, complex software products
|
||||
- Containers allow using them together
|
||||
- . . . without needing to figure out how to install them
|
||||
- e.g., use Docker Compose tool; there are examples on GitHub
|
||||
- Managing more than a few containers?
|
||||
- Switch over to a container orchestration tool!
|
||||
|
||||
# Managing containerised applications
|
||||
- Containers can (do!) suffer security vulnerabilities
|
||||
- Thus, need management just like any other OS
|
||||
- Many services can notify you about security flaws
|
||||
- e.g., your dependencies may have been patched
|
||||
- Can easily upgrade containers to include security fixes
|
||||
- Upgrading live containers may break applications
|
||||
- Common: whole container-based app is rebuilt & relaunched
|
||||
- Container frameworks themselves also get hacked
|
||||
@ -4,11 +4,14 @@ aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
sr-due: 2022-04-29
|
||||
sr-interval: 3
|
||||
sr-due: 2022-05-14
|
||||
sr-interval: 12
|
||||
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
|
||||
@ -26,117 +29,4 @@ foward engineering can be used to create skeleton code much more easily
|
||||
|
||||
fully representing code is UML is tricks as code is more difficult. It is hard to maintain consistency. This is easier with erds and sql than other types as these dont have to worry about behaviour. so the mappping is more simple. With uml and java is gets complex fast
|
||||
|
||||
this idea sounds good but in practice is not practical. THere is an qgument hat code is part of the design anyway. Code is a detailed form of a model.
|
||||
|
||||
# UML - java
|
||||
|
||||
similar to ERD to sql.
|
||||
|
||||
use case diagrams - more about system structure and features
|
||||
**class diagram - java class
|
||||
- doesn't have to be java
|
||||
- could be any oop language
|
||||
sequence, activity, state etc, may or may not be useful.
|
||||
some code can be automatically generated.
|
||||
|
||||
custom methods cannot be generated automatically. things like getters and setters can be generated automatically.
|
||||
|
||||
## Steps
|
||||
1. uml class -> java class (in its own file) (dont overdo it) (e.g., librarian)
|
||||
1. use conceptual vs implementation level diagrams
|
||||
2. assign data types to explicit class fields
|
||||
3. add fields implied by associations
|
||||
1. unidir ⇒ field in class at tail of -->
|
||||
2. bidir ⇒ field in class at both ends <-->
|
||||
3. multi = 1 ⇒ simple field (e.g., string)
|
||||
4. multi > 1 ⇒ appropraite collection type (e.g., arraylist, hashmap etc)
|
||||
4. field visibilty normally private (should match class diagram)
|
||||
5. add constructors if needed
|
||||
6. add public getter and setter methods (trivial, can be auto generated)
|
||||
7. add remaining public or private methods (includilng implemented interfaces)
|
||||
|
||||
## aside on visibilty
|
||||
|
||||
|
||||
## use case diagrams
|
||||
|
||||
each use case represents a feature. often items in a menu. sub cases can be sub menu items (extnd, include, require) (sometimes).
|
||||
|
||||
actors *can* correspond to domain classes.
|
||||
|
||||
one use case might require/use several classes. e.g., UI, processor, or data classes.
|
||||
|
||||
## other behavioural diagrams
|
||||
|
||||
**sequence:
|
||||
- could be used for looping and branching
|
||||
**activity:
|
||||
- low level in particular
|
||||
- can be used to generate some code
|
||||
- would require discipline in diagram conventions
|
||||
- by this point you are basically writing code in graphical form anyway
|
||||
- might as well just write the code anyway
|
||||
**state:
|
||||
- most useful/likely to be use for code
|
||||
- states machines are tedious
|
||||
- [finite-state-machine](notes/finite-state-machine.md)
|
||||
- often translate to some kind of lookup mechanism
|
||||
- fairly easy to generate correspoding code
|
||||
- boils down to some kind of index.
|
||||
- however these are not used very often
|
||||
- once this code is generated is hard to fix manually
|
||||
- better to just change the diagam and regenerate the code
|
||||
|
||||
|
||||
## subclasses
|
||||
[employe diagram example](https://i.imgur.com/EAiVEkt.png)
|
||||
[eployee code example](https://i.imgur.com/bighWWJ.png)
|
||||
[code continued](https://i.imgur.com/Hxcho66.png)
|
||||
|
||||
- this example is contrived
|
||||
|
||||
- salariedemployee and wagedemployee inherit all public and protected methods of employee (including getters and setters, not including constructors)
|
||||
- salariedEmpoyee and waged employee each have thier own computePay method
|
||||
|
||||
## Interfaces
|
||||
[diagram](https://i.imgur.com/pN660p0.png)
|
||||
[code](https://i.imgur.com/iDyoeSE.png)
|
||||
|
||||
- generally preffered to subclasses
|
||||
- both salaried and waged employees must implement the computePay method
|
||||
|
||||
|
||||
# Domain class model vs ERD structure
|
||||
|
||||
- erd are about long term storage. data persistence
|
||||
- domain models are about application process, temporary storage.
|
||||
- database and class structures dont need to be the same
|
||||
- but you do need to be able to map between them
|
||||
|
||||
[domain class model vs erd structure](https://i.imgur.com/feN6a9W.png)
|
||||
|
||||
# Example: Library system
|
||||
|
||||
e.g.,
|
||||
[library example uml diagram](https://i.imgur.com/u4CNXOb.png)
|
||||
the five horizontal items could be meny items. there will be some kind of authorisation for senior librarians. we probably wouldn't make seniour and junior librarian as differnce classes. there is not really any benefit, doing this would be overkill. We should use a single librarian class with `type` field. this field can be used for authorisation. The apply fine use case is an optional sub task. It could be implemented in many ways: checkbox on return form, sub menu item, automatic. shelve item is a differnt, its more of a business process. only thing need in the code it the change the status of the item.
|
||||
|
||||
|
||||
|
||||
[code part 1 Loan class](https://i.imgur.com/6VoV54C.png)
|
||||
[code part 2 Loan class 2](https://i.imgur.com/Q8yptdE.png)
|
||||
[code part 2 Loan class 3](https://i.imgur.com/4Xst3ys.png)
|
||||
|
||||
|
||||
## Multiplicity
|
||||
|
||||
|
||||
mih multiplicity of - ⇒ can create instances of Loan withou providing any associated LoanItem instances
|
||||
|
||||
min multiplicity 1 ⇒ must provide associated Loan instand when creating a LoanItem instance
|
||||
1. create loan and loanItem then use LoanItem.setLoan()
|
||||
2. use a custom LoanItem constructor to pass Loan object
|
||||
|
||||
[multiplicity code ](https://i.imgur.com/RKa9NBy.png)
|
||||
|
||||
unidirectional association are preffered as here we need to link things birdirectionally. this example is contrived, in real life it would not be done this way.
|
||||
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.
|
||||
@ -4,8 +4,8 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-04-29
|
||||
sr-interval: 3
|
||||
sr-due: 2022-05-12
|
||||
sr-interval: 10
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
@ -20,47 +20,8 @@ Door is very simple compared to computer interface. Yet they are still done wron
|
||||
|
||||
|
||||
# Mental Models
|
||||
- mental models are created by experience, metaphors, and analogical reasoning
|
||||
- these models are developed further through interaction with the system
|
||||
- designers (wrongly) often expect the users model to be the same as theirs
|
||||
|
||||
A mental model mistach leads to:
|
||||
- slow performance
|
||||
- errors
|
||||
- frustration
|
||||
|
||||
[participant-observation](notes/participant-observation.md) appretiships (and other techniques such as [evaluating-designs](notes/evaluating-designs.md)) can uncover these mismatches.
|
||||
|
||||
## Slips vs mistakes
|
||||
|
||||
| Slip | Mistake |
|
||||
|:-----------|:----------------------------------|
|
||||
| accidental | on purpose (due to model mistach) |
|
||||
|
||||
|
||||
## How to create good mental models
|
||||
- [Direct Manipulation](notes/direct-manipulation-video.md)
|
||||
- leveraging real world metphors
|
||||
- this gives is a good idea of how each object works and how to control it
|
||||
[mental-models](notes/mental-models.md)
|
||||
|
||||
# Representation Matters and Distributing cognition
|
||||
|
||||
use representatio nthat does not require user to memoreise things.
|
||||
|
||||
"solving a problem simply means representing it so as to make the solution transparent" - Herbert Simon, The sciences of the Artificial
|
||||
|
||||
memory games make finding pairs hard by introducing rules. This often happens in computers interfaces needlessly difficult to use
|
||||
|
||||
depeding o nhow you represent a problem, you can make is easy or hard.
|
||||
|
||||
## Working memory
|
||||
|
||||
users have a working memory (2±2 limit). You shouldn't require users to remember anything that you could put on a screen.
|
||||
|
||||
If something takes a lot of time. You wil get distracted, and forget something.
|
||||
|
||||
|
||||
## Naturalness principle
|
||||
|
||||
- experiemental cognition is raised when the properties of the representation match the properties of the thing being represented
|
||||
-
|
||||
[representation-and-distributing-cognition](notes/representation-and-distributing-cognition.md)
|
||||
79
content/notes/16-compilers.md
Normal file
79
content/notes/16-compilers.md
Normal file
@ -0,0 +1,79 @@
|
||||
---
|
||||
title: "16-compilers"
|
||||
aliases:
|
||||
tags:
|
||||
- cosc202
|
||||
- lecture
|
||||
sr-due: 2022-05-05
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
- describe what it is and what is does
|
||||
- compilers vs interpreters
|
||||
- compile stages
|
||||
- why java is atypical of compiled languages
|
||||
- compiler front vs back end
|
||||
- why producing precise compiler errors is hard
|
||||
|
||||
# What is a compiler?
|
||||
Compilers are 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)
|
||||
|
||||
An interpreter is more of an interactive tool. The interpreter program (e.g., python) runs of the CPU and execute your program. Interpretee laguages include (python, ruby, shell, R, js, PHP).
|
||||
|
||||
Usually compiled program are smaller and run faster, but interpreted languages are more convienient
|
||||
|
||||
The line between compiled and interpreted is becoming less clear with things like the JVM, Scala, and python .pyc files.
|
||||
|
||||
# Compiler stages (traditional)
|
||||
- lexical analysis (lexing) - source code -> tokens
|
||||
- a token is a meaningful substring of source code
|
||||
- e.g.,
|
||||
- input - "x=10+y"
|
||||
- ouput - [var(x), ASSIGN, int(10), PLUS, var(y)]
|
||||
- parsing - convert token stream to abstract syntax tree (AST)
|
||||
- output given above input
|
||||
- assign(v(x), expression(add(10, v(y))))
|
||||
- defines the structure of the program
|
||||
- optimising - rework AST, e.g., drop unreachable code
|
||||
- dead code removal
|
||||
- e.g.,:
|
||||
```java
|
||||
if(false){
|
||||
//do stuff
|
||||
}
|
||||
```
|
||||
- emitting - output machine code to e.g., binary file
|
||||
|
||||
# Compiler stages Modern
|
||||
new langauge being released. Not really a common solution. Originally we would for example design a compiler for each language like C and Fortran.
|
||||
|
||||
Now we split the front end and the back end.
|
||||
## Front end
|
||||
- language specific
|
||||
- lexing and parsing
|
||||
- output compiler-internal intermediate code
|
||||
## Back end
|
||||
- optimise intermediate code
|
||||
- output machine code e.g., for target CPU hardware
|
||||
|
||||
## Compiler families
|
||||
- GCC - Gnu compiler collection - old and messy code
|
||||
- LLVM - low level virtual machine - cleaner code - open-source
|
||||
- Microsoft and Intel compilers
|
||||
- ms compilers aim to support development for windows
|
||||
- mentioned before: Intel compilers optimise for Intel Hardware
|
||||
|
||||
# Compiler output
|
||||
Typically compiler output object code. This contains machine code, but is not yet executable.
|
||||
|
||||
There is another linking stage, where the object code is linked together into executable programs. At this stage code from libraries and other languages can be joined. e.g., assembly and C.
|
||||
|
||||
Most compilers compile and link.
|
||||
|
||||
# Java Compilers
|
||||
javac produces JVm bytecode. this bytecode was orginally interpreted by `java`. This extra layer was initally created to help with porting java on new hardware. Now `java` recompiles to java hardware CPU. This is done 'just-in-time' in RAM and doesn't ouput machine code. The JIT compiler is triggered when code is first (or repeatedly used).
|
||||
|
||||
# Compiler errors
|
||||
Producing good error messages is important and difficult as the compiler doesn't usually know exactly where/what the error was. Errors can occur within expanded macros
|
||||
|
||||
@ -4,111 +4,11 @@ aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-04-30
|
||||
sr-interval: 3
|
||||
sr-due: 2022-05-10
|
||||
sr-interval: 8
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# Dist cognition
|
||||
|
||||
when interfaces help people disribute cognition it can
|
||||
- exourage experimentsation
|
||||
- scaffold learning and reuce errors through reduncdancy
|
||||
- show (only) differences that matter
|
||||
- convert slow calculation into fast perception
|
||||
- support chunking, especially by experts
|
||||
- increase effieciency
|
||||
- facilitate collaboration
|
||||
|
||||
good representation shows only relevant information and enables:
|
||||
- comparison
|
||||
- exploration
|
||||
- problem solving
|
||||
|
||||
deep vs shallow interface
|
||||
|
||||
# Visual design
|
||||
|
||||
combine text and graphics. how to represent?
|
||||
|
||||
- whitespace for grouping
|
||||
- size contrasts for heiarchy
|
||||
- variable scale and weight
|
||||
- colors
|
||||
|
||||
|
||||
three goals
|
||||
- guide
|
||||
- pace
|
||||
- message
|
||||
|
||||
Three tools
|
||||
- typography
|
||||
- layout
|
||||
- colour
|
||||
|
||||
# Typography
|
||||
|
||||
most common
|
||||
- gill sans
|
||||
- helvetica
|
||||
- calibri
|
||||
- arial
|
||||
- times
|
||||
|
||||
three types
|
||||
- serif
|
||||
- sans serif
|
||||
- handwritten
|
||||
|
||||
point size
|
||||
|
||||
|
||||
leading depends on the font and the user setting but usually is 20% of the font
|
||||
|
||||
|
||||
x height depends on the font.
|
||||
- smaller x height adds "elegance"
|
||||
- larger x height isbettwe to low res displays
|
||||
|
||||
|
||||
ascenders and descender usually correlates with x height (small x-height > large ascenders and descenders)
|
||||
|
||||
|
||||
weight: usually regullar and bold, also light semibold, ultrabold
|
||||
|
||||
|
||||
sans serifs have less line width variation
|
||||
|
||||
|
||||
some fonts provide small caps and lowercase numbers
|
||||
|
||||
|
||||
|
||||
|
||||
- serif hypothesis
|
||||
- serif fonts are easier to read
|
||||
- preferable for long stretches of text because serifs provide anchors and guide the eye
|
||||
- not proven
|
||||
|
||||
more info on the top than the botton
|
||||
|
||||
|
||||
expectation plays an important role
|
||||
|
||||
|
||||
|
||||
|
||||
## which font to use?
|
||||
- depends on context
|
||||
- recoomentations
|
||||
- slides and posters sans serif
|
||||
- printed text serif
|
||||
- web sans serif
|
||||
- sans serif is better in lower resolutions
|
||||
- combinations: (header sans, text serif)
|
||||
- comic sans good for dyslexia
|
||||
- logos should catch the eye
|
||||
|
||||
|
||||
|
||||
- [representation-and-distributing-cognition](notes/representation-and-distributing-cognition.md)
|
||||
- [visual-design-typography](notes/visual-design-typography.md)]
|
||||
- [visual-design](notes/visual-design.md)
|
||||
19
content/notes/16-reverse engineering.md
Normal file
19
content/notes/16-reverse engineering.md
Normal file
@ -0,0 +1,19 @@
|
||||
---
|
||||
title: "16-reverse engineering"
|
||||
aliases:
|
||||
tags:
|
||||
- info201
|
||||
- lecture
|
||||
---
|
||||
|
||||
|
||||
# Java -> UML reverse engineering
|
||||
reverse of foward engineering
|
||||
|
||||
- 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
|
||||
|
||||
|
||||
112
content/notes/17-dynamic-programming.md
Normal file
112
content/notes/17-dynamic-programming.md
Normal file
@ -0,0 +1,112 @@
|
||||
---
|
||||
title: "17-dynamic-programming"
|
||||
aliases:
|
||||
tags:
|
||||
- lecture
|
||||
- cosc201
|
||||
sr-due: 2022-05-07
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
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 require 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
|
||||
23
content/notes/17-ethics-in-hci.md
Normal file
23
content/notes/17-ethics-in-hci.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "17-ethics-in-hci"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-07
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# Reading and navigation
|
||||
we have a tendency to focus on certain areas first. Usually the top left.
|
||||
|
||||
# Ethics
|
||||
steve mann example - too far?
|
||||
|
||||
hypocratic oath - do no harm
|
||||
|
||||
should there be one like this in computing?
|
||||
|
||||
should self driving cars protect the driver or pedestrians.
|
||||
|
||||
@ -0,0 +1,107 @@
|
||||
---
|
||||
title: "17-grids-grouping-alignment-reading-and-navigation"
|
||||
aliases:
|
||||
tags:
|
||||
- info203
|
||||
- lecture
|
||||
sr-due: 2022-05-06
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
# Grouping
|
||||
Gestaltkriterien “Gestalt Principles” - Law of Proximity
|
||||
|
||||
Our brain is trying to help us understand the world. For example we look for eye contact. Our brain is looking with our eyes for contrast, parrallel lines, etc. Criteria that help us understand the world.
|
||||
|
||||
The Gestalt priciples have identified how our functions. One of these is the law of proximity. Things that a close to each other are grouped together by our brain.
|
||||
|
||||
[](https://i.imgur.com/m8lTltN.png)[](https://i.imgur.com/EMeV5Gg.png)
|
||||
|
||||
|
||||
Another law is the law of similarty. Things with similar appearance are grouped by our brains.
|
||||
[](https://i.imgur.com/lVlE1z8.png)
|
||||
[](https://i.imgur.com/8BhtgTa.png)
|
||||
|
||||
|
||||
Another law is the law of closure. Where our brain tries to "autocomplete" things
|
||||
[](https://i.imgur.com/1bcanTN.png)
|
||||
[](https://i.imgur.com/MW9r7PR.png)
|
||||
|
||||
|
||||
These techniques, similarity, proximity and (to a lesser extent) closure, can be used to organise and groupu our interfaces. Often the grouping and layout is done before the rest of the design.
|
||||
|
||||
Examples:
|
||||
- [](https://i.imgur.com/RfkC6Fq.png)
|
||||
- [](https://i.imgur.com/FjF8c98.png)
|
||||
- [](https://i.imgur.com/P1m9XH8.png)
|
||||
|
||||
This is relatively easy. However, when done badly it can quickly confuse the user.
|
||||
|
||||
|
||||
## Jan Tschichold and Bauhaus
|
||||
|
||||
There was a sudden change from the right images to the left. This was partly due to advances in technology. This change was made by the Bauhaus group/school which became a way of thinking. Their ideas were inspired by architecture. The style was simple, functional, well grouped. These elements are also present in their visual design.
|
||||
|
||||
Examples:
|
||||
- [](https://i.imgur.com/nbEzVeP.png)
|
||||
- [](https://i.imgur.com/MlP9Lra.png)
|
||||
- [](https://i.imgur.com/jOCvCkw.png)
|
||||
- [](https://i.imgur.com/LXsRpCb.png)
|
||||
|
||||
## In summary
|
||||
- alignment guides the eye and reduces clutter
|
||||
- avoid slight misalignments that undermine your ability to beacon organisation
|
||||
- we automatically notice patterns and deviations
|
||||
- when you deviate do so strategically
|
||||
- use visual proximity and scale to convey semantic information
|
||||
|
||||
## Uses of grouping
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# Color
|
||||
|
||||
- design grayscale first.
|
||||
- keep luminance values from grayscale when moving to color
|
||||
- use color harmonisers
|
||||
- [](https://i.imgur.com/KdwaNzi.png)
|
||||
- about 5-8% of men are colorblind (red-green, blue–yellow, total color blindness)
|
||||
|
||||
# Reading and navigating
|
||||
Information scent
|
||||
- how to represent things so people can find what they want
|
||||
- do they realize their options
|
||||
- can they figue out how to get what they want
|
||||
How to find Poor scent
|
||||
- flailing (loss of orientation, reported or observed)
|
||||
- low confidence (in what link with will do or where it will go) (measured before and after using a web link)
|
||||
- back button (count usage of back button)
|
||||
|
||||
Low scent navigation
|
||||
- unfamiliar terms
|
||||
- suprising categories
|
||||
- short links
|
||||
- hidden navigation
|
||||
- icons provide little information
|
||||
- generic icons rarely help
|
||||
- they help when
|
||||
- they facilitate repeat recognition
|
||||
- when you know what something looks like but not what its called
|
||||
- good redundant coding can help
|
||||
|
||||
improving scent
|
||||
- multiword links
|
||||
- specific recognisable terms
|
||||
- trigger words not "clever" terms
|
||||
- help accessibility
|
||||
- speaking block navigation
|
||||
- subheadings
|
||||
- explanations
|
||||
- design for glanceability
|
||||
- [](https://i.imgur.com/pMNYIUB.png)
|
||||
92
content/notes/17-linkers-and-loaders.md
Normal file
92
content/notes/17-linkers-and-loaders.md
Normal file
@ -0,0 +1,92 @@
|
||||
---
|
||||
title: "17-linkers-and-loaders"
|
||||
aliases:
|
||||
tags:
|
||||
- lecture
|
||||
- cosc202
|
||||
sr-due: 2022-05-08
|
||||
sr-interval: 3
|
||||
sr-ease: 250
|
||||
---
|
||||
|
||||
- Appreciate kernel / userspace distinction
|
||||
- Sketch what OS loaders need to achieve
|
||||
- Contrast running Java versus C code
|
||||
- Outline abstractions that hide OS from developers
|
||||
- Describe what linkers achieve
|
||||
- Contrast static and dynamic linking of libraries
|
||||
|
||||
# Operating Systems
|
||||
## Userspace
|
||||
This is where applications run. Computer resources are isolated in compute and data
|
||||
- cannot access memory belonging to another process
|
||||
- cannot directly access hardware
|
||||
- cannot occupy all of the CPUs time on one application
|
||||
|
||||
## Kernal
|
||||
"all seeing and all powerful" The kernel sits below the userspace and manages resource allocation and directly controls harware. Usuallly you dont directly interact with the kernel when developing software. You do interact indirectly with the kernel, it permits your interactions with the environment (input/output from/to files, network, and terminals). The standard library usually insulates you from the OS kernel, may abstract over different OSs, and do operations in an OS-agnostic way.
|
||||
|
||||
## C program example
|
||||
[400](https://i.imgur.com/1PlLlQ5.png) [400](https://i.imgur.com/bBQp3TH.png)
|
||||
|
||||
## OS Program loaders
|
||||
There identify the types of file that is being executed. E.g., a #! at the beginning of a file tells the OS which interpreter to run that file through. Otherwise it will look into the binary file, loads any dynamic libraries, and adjusts the executable code to point to shared libraries in RAM. Eventaully the OS will point the CPU at the binary machine code, first creating an OS process to contain code execution so it cannot overwrite memory belonging to another process
|
||||
|
||||
## Java Program "loader"
|
||||
Java was designed to be portable, and minimose effort to port to another OS. Java "hides" the OS from you. It can dynamically load classes at runtime, thus avoiding an explicit linking stage. Java class loaders can read .class files. The Top-level ClassLoader is written in native code. It loads internal classes like HashMap. Then ClassLoader subclasses written in java can be loaded.
|
||||
|
||||
## Even higher level computing abstractions
|
||||
- Java Enterprise edition
|
||||
- run code is exisintg application server
|
||||
- most of the time the app framework is running
|
||||
- your code injects key classes with custom business logic
|
||||
- .NET is similar
|
||||
- Web application programming
|
||||
- stacks offer page templating, business rules, databases
|
||||
- Cloud native application
|
||||
|
||||
# Linkers
|
||||
- Linkers facilitate use of code in multiple languages, e.g.
|
||||
- use C for programming speed of developer;
|
||||
- use Assembly language for running speed of code
|
||||
- But these days: often hard to beat optimising compilers!
|
||||
- Linkers effect interaction with libraries in two ways:
|
||||
- Static linking: build libraries’ code into your application
|
||||
- Dynamic linking: library connected in at load or run-time
|
||||
- Linkers facilitate interaction with OS
|
||||
|
||||
|
||||
## Static linking
|
||||
- Statically linked libraries are built into executable
|
||||
- We’ve previously discussed the dependency problems:
|
||||
- Every executable carries the weight of the library code
|
||||
- Also, bug fixing requires rebuilding the whole program
|
||||
- However, static linking is straightforward
|
||||
- e.g., nothing much OS-specific about static linking
|
||||
- Library calls are just function calls within userspace
|
||||
- Alternative is for linking not to finish at compile-time
|
||||
- Linker could add code to link at runtime
|
||||
- More commonly, linker tells OS more linking needed later
|
||||
|
||||
## Dynamic linking
|
||||
- Dynamic linking is common on modern OSs, e.g.,
|
||||
- DLLs on Windows: Dynamic Link Libraries
|
||||
- SOs on Linux, Solaris: Shared Objects
|
||||
- DyLibs on macOS: Dynamically loaded modules
|
||||
- One copy of dynamic library shared by all executables
|
||||
- efficiently uses memory: load into RAM once; share to all
|
||||
- Fixing bugs / security flaws is streamlined:
|
||||
- just upgrade the single copy of the library
|
||||
- all processes will adopt fixed library (when they next start)
|
||||
|
||||
## Managing dynamic libraries
|
||||
- Dynamic libraries may have different ownership
|
||||
- Some dynamic libraries will be part of the OS distribution
|
||||
- Others installed along with apps that need those libraries
|
||||
- Can track installable library use with reference counters
|
||||
- Software installer checks whether library is already present:
|
||||
- if not, install library, set reference count to one
|
||||
- if so, increase reference count by one
|
||||
- Uninstaller decreases reference count: deletes if at zero
|
||||
- But your reference counting needs to be reliable
|
||||
- ... unlike early Windows OSs: so called ‘DLL hell’
|
||||
26
content/notes/avl-trees.md
Normal file
26
content/notes/avl-trees.md
Normal file
@ -0,0 +1,26 @@
|
||||
---
|
||||
title: "avl-trees"
|
||||
aliases: AVL
|
||||
tags:
|
||||
- cosc201
|
||||
- datastructure
|
||||
---
|
||||
|
||||
AVL tree
|
||||
most basic and obvious.
|
||||
|
||||
each node contains some extra information: the difference between the height of its right and left subtee. balance is maintained by ensuring that at every node this always at most 1
|
||||
|
||||
What is the least possible number of nodes in AVL tree of height k?
|
||||
|
||||
in general
|
||||
|
||||
$A_k= 1 + A_{k-1} + A_{k-2}$
|
||||
|
||||
we need a root 1, on one side a amallest possible tree of height $A_{k-1}$ then the other side must have height at least to $k-2$ to satisfy the rule, so we need at least $A_{k-2}$ more nodes.
|
||||
|
||||
The size if exponential in its height, and therefore its height is logarithmic in the size.
|
||||
|
||||
the operations are the same, but for each one we need to check and fix any excess imbalance along a single path from the affected leaf node up to the root.
|
||||
|
||||
for insertions, at most three rotations are rquired, for deletions the worst case is $O(lg\ n)$
|
||||
23
content/notes/balancing-binary-search-trees.md
Normal file
23
content/notes/balancing-binary-search-trees.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
title: "balancing-binary-search-trees"
|
||||
aliases: Balancing BST, balancing
|
||||
tags:
|
||||
- cosc201
|
||||
---
|
||||
|
||||
the height of a [BST](notes/binary-search-tree.md) is the length of its longest chain. Most operations are $O(n)$ where n is the height of the tree. In an Ideal situation each layer of the tree is full. The height of the tree is logarithmic to the number of nodes.
|
||||
|
||||
When a tree is being used only occainsonally, we can afford to simply rebalance is periodically. However when it is in constant use we cannot afford this cost
|
||||
|
||||
# Rotations
|
||||
|
||||
|
||||
sometimes two rotations are needed
|
||||
|
||||
## When to rotate and how to do them
|
||||
|
||||
basic idea is to modify the add and delete operations fo the BST to be somewhat self-balancing. This does not need to be perfect
|
||||
|
||||
We need a rule to decide when the tree is "balanced enough" and also strategies for fixing problems when the rule is violated.
|
||||
|
||||
We only need to fix the area local to the add or delete operations
|
||||
99
content/notes/containers.md
Normal file
99
content/notes/containers.md
Normal file
@ -0,0 +1,99 @@
|
||||
---
|
||||
title: "containers"
|
||||
aliases: Containers
|
||||
tags:
|
||||
- cosc202
|
||||
---
|
||||
|
||||
# What are (software) containers?
|
||||
|
||||
- Containers encapsulate a computing environment
|
||||
- Facilitates portable and reproducible use of software
|
||||
- Can wrap up application code and data, and much of OS
|
||||
- Containers are lightweight virtual machines
|
||||
- You need to boot them up, as for any OS
|
||||
- . . . but containers start up very quickly
|
||||
|
||||
# What containers do and don’t include
|
||||
- Containers are generally Linux (virtual) machines
|
||||
- Even when hosted on Windows, containers are usually Linux
|
||||
- Microsoft Windows containers do exist though
|
||||
- Containers include the OS user space
|
||||
- e.g., distributions: Ubuntu, Debian, Arch. . .
|
||||
- Containers do not include Linux kernel
|
||||
- ... because all containers share one instance of the Linux kernel
|
||||
- Containers can’t themselves include hardware device drivers
|
||||
|
||||
# Using containers
|
||||
- We won’t explore how containers are hosted
|
||||
- COSC349 explores how the lightweight virtualisation works
|
||||
- We focus on using others’ containers
|
||||
- Making containers usable involves:
|
||||
- Management tools to control containers
|
||||
- Means for interacting with the containerised software
|
||||
- Somewhere from which to get their starter material. . .
|
||||
|
||||
# Container registries
|
||||
- Containers’ start up from an image
|
||||
- Think of images as a hard disk template
|
||||
- Images efficiently overlay layers of files and folders
|
||||
- Container registries store and share images: e.g.,
|
||||
- Docker Hub is a popular container registry
|
||||
- GitHub Container Registry (public; launched 2020)
|
||||
- GitLab Container Registry (private)
|
||||
- All major cloud providers provide registries
|
||||
- You can run on-site, private registry too
|
||||
|
||||
# Example container interacting with files
|
||||
- Let’s build the containers lab website
|
||||
- Input: Markdown files
|
||||
- Output: HTML website
|
||||
- Can use this container within CI
|
||||
- Active container can rebuild ‘live’:
|
||||
- source files are watched for changes
|
||||
- changes trigger rebuilding target files
|
||||
- can reload browser to see changes rapidly
|
||||
- Note: this example is an optional part of containers lab
|
||||
- docker run −−rm −−mount \ type=bind , source=$ {PWD} , ta rge t=/ s r v / j e k y l l \ j e k y l l / j e k y l l : pages j e k y l l bu i ld
|
||||
|
||||
# Example container interacting over network
|
||||
- Lesson builder can host an internal web server
|
||||
- Point browser running on host computer to network URL
|
||||
- Thus test built website, not just opening HTML files within it
|
||||
- Container framework can share container’s network
|
||||
- Typically expose key network ports of container on host
|
||||
- Connections routed through to container
|
||||
- Usually connections limited to interactions with the host OS
|
||||
- . . . but containers can support internet-facing servers
|
||||
- docker run −−rm − i t −−mount \ type=bind , source=$ {PWD} , ta rge t=/ s r v / j e k y l l \ −p 1 2 7. 0. 0. 1: 4 0 0 0: 4 0 0 0 \ j e k y l l / j e k y l l : 3 j e k y l l se rve
|
||||
|
||||
# Inter-container interactions
|
||||
- Can build apps by composing multiple containers
|
||||
- Either or both of file/network-based sharing commonly used
|
||||
- Need to consider how to orchestrate containers
|
||||
- Container orchestration is a COSC349 topic
|
||||
- e.g., coordinating multi-container start up
|
||||
- Kubernetes is the de facto container orchestrator
|
||||
- Creates reliable, scalable services from containers
|
||||
- Supported on all major cloud providers
|
||||
|
||||
# FYI: example multi-container application
|
||||
- Example: say you need to chart time-series data
|
||||
- InfluxDB is a dedicated time-series database
|
||||
- Grafana is a dedicated web-based charting system
|
||||
- Both are large, complex software products
|
||||
- Containers allow using them together
|
||||
- . . . without needing to figure out how to install them
|
||||
- e.g., use Docker Compose tool; there are examples on GitHub
|
||||
- Managing more than a few containers?
|
||||
- Switch over to a container orchestration tool!
|
||||
|
||||
# Managing containerised applications
|
||||
- Containers can (do!) suffer security vulnerabilities
|
||||
- Thus, need management just like any other OS
|
||||
- Many services can notify you about security flaws
|
||||
- e.g., your dependencies may have been patched
|
||||
- Can easily upgrade containers to include security fixes
|
||||
- Upgrading live containers may break applications
|
||||
- Common: whole container-based app is rebuilt & relaunched
|
||||
- Container frameworks themselves also get hacked
|
||||
@ -16,4 +16,8 @@ links: [[notes/cosc-201]]
|
||||
- [[notes/mergesort]]
|
||||
- [[notes/quicksort]]
|
||||
- [divide-and-conquer](notes/divide-and-conquer.md)
|
||||
- [unite-and-conquer](notes/unite-and-conquer.md)
|
||||
- [unite-and-conquer](notes/unite-and-conquer.md)
|
||||
- [avl-trees](notes/avl-trees.md)
|
||||
- [red-black-trees](notes/red-black-trees.md)
|
||||
- [treaps](notes/treaps.md)
|
||||
- [balancing-binary-search-trees](notes/balancing-binary-search-trees.md)
|
||||
@ -14,4 +14,6 @@ links: [cosc-202](notes/cosc-202.md)
|
||||
- [11-continuous-integration-2](notes/11-continuous-integration-2.md)
|
||||
- [12-automation](notes/12-automation)
|
||||
- [13-code-librarires](notes/13-code-librarires.md)
|
||||
|
||||
*
|
||||
- [15-containers](notes/15-containers.md)
|
||||
- [16-compilers](notes/16-compilers.md)
|
||||
@ -18,5 +18,6 @@ links: [[notes/cosc-202]]
|
||||
- [[notes/documentation]]
|
||||
- [[notes/continuous-integration]]
|
||||
- [automation](notes/automation.md)
|
||||
- [containers](notes/containers.md)
|
||||
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ This is the theoretical basis for normalisation, and uniqueness property of PK (
|
||||
- product ID + order no --> quantity ordered
|
||||
|
||||
## 1.3 Anti examples
|
||||
- student ID + name --> birth date (ovekill, partial dependency)
|
||||
- student ID + name --> birth date (overkill, partial dependency)
|
||||
- home address --> student name
|
||||
- name --> birth date
|
||||
|
||||
|
||||
@ -15,4 +15,7 @@ links: [[notes/info-201]]
|
||||
- [11-class-diagrams](notes/11-class-diagrams.md)
|
||||
- [12-modelling-behaviour](notes/12-modelling-behaviour.md)
|
||||
- [13-UML-sequence-diagrams](notes/13-UML-sequence-diagrams.md)
|
||||
- [14-direct-manipulation-and-mental-models](notes/14-direct-manipulation-and-mental-models.md)
|
||||
-
|
||||
- [15-from-models-to-code-and-back](notes/15-from-models-to-code-and-back.md)
|
||||
- [16-reverse engineering](notes/16-reverse%20engineering.md)
|
||||
|
||||
|
||||
@ -32,3 +32,5 @@ links: [[notes/info-201]]
|
||||
- [redundancy-and-anomalies](notes/redundancy-and-anomalies.md)
|
||||
- [dependencies](notes/dependencies.md)
|
||||
- [normalisation](notes/normalisation.md)
|
||||
- [round-trip-engineering](notes/round-trip-engineering.md)
|
||||
- [uml-java-forward-engineering](notes/uml-java-forward-engineering.md)
|
||||
|
||||
@ -15,4 +15,5 @@ link: [[notes/info-203]]
|
||||
- [13-design-heuristics-4](notes/13-design-heuristics-4.md)
|
||||
- [14-direct-manipulation-and-mental-models](notes/14-direct-manipulation-and-mental-models.md)
|
||||
- [15-mental-models-representation-matters-distributing-cognition](notes/15-mental-models-representation-matters-distributing-cognition.md)
|
||||
- [16-distributing-cognition-and-visual-design-typography](notes/16-distributing-cognition-and-visual-design-typography.md)
|
||||
- [16-distributing-cognition-and-visual-design-typography](notes/16-distributing-cognition-and-visual-design-typography.md)
|
||||
- [17-grids-grouping-alignment-reading-and-navigation](notes/17-grids-grouping-alignment-reading-and-navigation.md)
|
||||
@ -25,4 +25,7 @@ links: [[notes/info-203]]
|
||||
- [interviewing](notes/interviewing.md)
|
||||
- [storyboards](notes/storyboards.md)
|
||||
- [personas-and-scenarios](notes/personas-and-scenarios.md)
|
||||
-
|
||||
- [mental-models](notes/mental-models.md)
|
||||
- [representation-and-distributing-cognition](notes/representation-and-distributing-cognition.md)
|
||||
- [visual-design](notes/visual-design.md)
|
||||
- [visual-design-typography](notes/visual-design-typography.md)
|
||||
29
content/notes/mental-models.md
Normal file
29
content/notes/mental-models.md
Normal file
@ -0,0 +1,29 @@
|
||||
---
|
||||
title: "mental-models"
|
||||
aliases: Mental Models
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
- mental models are created by experience, metaphors, and analogical reasoning
|
||||
- these models are developed further through interaction with the system
|
||||
- designers (wrongly) often expect the users model to be the same as theirs
|
||||
|
||||
A mental model mistach leads to:
|
||||
- slow performance
|
||||
- errors
|
||||
- frustration
|
||||
|
||||
[participant-observation](notes/participant-observation.md) appretiships (and other techniques such as [evaluating-designs](notes/evaluating-designs.md)) can uncover these mismatches.
|
||||
|
||||
## Slips vs mistakes
|
||||
|
||||
| Slip | Mistake |
|
||||
|:-----------|:----------------------------------|
|
||||
| accidental | on purpose (due to model mistach) |
|
||||
|
||||
|
||||
## How to create good mental models
|
||||
- [Direct Manipulation](notes/direct-manipulation-video.md)
|
||||
- leveraging real world metphors
|
||||
- this gives is a good idea of how each object works and how to control it
|
||||
@ -36,7 +36,7 @@ Find which of ai or bi is lesser (break ties is favour of a), and copy that valu
|
||||
Once ai or bi is out of range, copy the rest of the other array into the remainder of m
|
||||
|
||||
```java
|
||||
public static int[] merge (int[] a int[] b){
|
||||
public static int[] merge (int[] a, int[] b){
|
||||
int[] m = new int[a.length + b.length]
|
||||
int ai = 0, bi = 0, mi = 0;
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ tags:
|
||||
---
|
||||
|
||||
# 1 Personas
|
||||
THe goals of a personas is their expectation of an end condition
|
||||
The goals of a personas is their expectation of an end condition
|
||||
- not features, functions, taskss, activities
|
||||
|
||||
A tool to documnet who the users are.
|
||||
@ -14,8 +14,9 @@ A tool to documnet who the users are.
|
||||
|
||||
|
||||
a methodology to identofy and think about our users and how they use the software.
|
||||
we want to avoid not thinking about the users
|
||||
make sure memebers of development dont have different ideas of the users
|
||||
we want to:
|
||||
- avoid not thinking about the users
|
||||
- make sure members of development dont have different ideas of the users
|
||||
|
||||
### 1.1.1 Goals
|
||||
1. Experience goals
|
||||
@ -25,7 +26,6 @@ e.g., ⇒ dell users want function but apple users want "that fancy apple produc
|
||||
2. End goals
|
||||
their motivaations for performing the task / intentded outcome
|
||||
|
||||
|
||||
3. Life goals
|
||||
Why they want to accomplish end goals /long term desires/self-image
|
||||
|
||||
|
||||
33
content/notes/red-black-trees.md
Normal file
33
content/notes/red-black-trees.md
Normal file
@ -0,0 +1,33 @@
|
||||
---
|
||||
title: "red-black-trees"
|
||||
aliases: Red Black Trees
|
||||
tags:
|
||||
- cosc201
|
||||
- datastructure
|
||||
---
|
||||
|
||||
|
||||
|
||||
Red Black trees
|
||||
most used current one. Used in java treemap
|
||||
|
||||
each node is either red or black
|
||||
|
||||
the rules are:
|
||||
- the root node is black (optional)
|
||||
- all null nodes are _considered_ black (convention)
|
||||
- A red node may not have a red child
|
||||
- Every path from a node to a descendant null node contains the same number of black nodes
|
||||
|
||||
These guarantee that the longest path frm root to null (which could alternate red and black) is at most twice as long as the shortest path (which could be all black)
|
||||
|
||||
the tree is full up to half its height - growing at least as fast as $2^{h/2}$
|
||||
|
||||
the height is logarithmic in the size sinhce th tree must be complete to the depth of half the height
|
||||
|
||||
Operations that mnodify the tree require in the worst case $O(lg\ n)$ recolourings and (on average a constant number) and not more than three rotations
|
||||
|
||||
## Strategy
|
||||
- do an insertio and color the node red.
|
||||
- recolor and rotate nodes to fix violation
|
||||
- there are four scenarios
|
||||
44
content/notes/representation-and-distributing-cognition.md
Normal file
44
content/notes/representation-and-distributing-cognition.md
Normal file
@ -0,0 +1,44 @@
|
||||
---
|
||||
title: "representation-and-distributing-cognition"
|
||||
aliases: Representation and Distributing Cognition
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
use representation that does not require user to memorise things.
|
||||
|
||||
> "solving a problem simply means representing it so as to make the solution transparent" - Herbert Simon, The sciences of the Artificial
|
||||
|
||||
memory games make finding pairs hard by introducing rules. This often happens in computers interfaces needlessly difficult to use
|
||||
|
||||
depeding on how you represent a problem, you can make is easy or hard.
|
||||
|
||||
## Working memory
|
||||
|
||||
users have a working memory (2±2 limit). You shouldn't require users to remember anything that you could put on a screen.
|
||||
|
||||
If something takes a lot of time. You wil get distracted, and forget something.
|
||||
|
||||
|
||||
## Naturalness principle
|
||||
|
||||
- experiemental cognition is raised when the properties of the representation match the properties of the thing being represented
|
||||
-
|
||||
|
||||
# Dist cognition
|
||||
|
||||
when interfaces help people disribute cognition it can
|
||||
- exourage experimentsation
|
||||
- scaffold learning and reuce errors through reduncdancy
|
||||
- show (only) differences that matter
|
||||
- convert slow calculation into fast perception
|
||||
- support chunking, especially by experts
|
||||
- increase effieciency
|
||||
- facilitate collaboration
|
||||
|
||||
good representation shows only relevant information and enables:
|
||||
- comparison
|
||||
- exploration
|
||||
- problem solving
|
||||
|
||||
deep vs shallow interface
|
||||
16
content/notes/round-trip-engineering.md
Normal file
16
content/notes/round-trip-engineering.md
Normal file
@ -0,0 +1,16 @@
|
||||
---
|
||||
title: "round-trip-engineering"
|
||||
aliases: Round Trip Engineering
|
||||
tags:
|
||||
- info201
|
||||
---
|
||||
|
||||
This is the process of translating models into code, or vice versa. For example, ERDs to SQL, or UML to Java. The main idea is to keep the code and the diagrams sematically equivalent
|
||||
|
||||
Converting diagrams to code is more common than the opposite, but both do occur.
|
||||
|
||||
A [model driven architecture]() is when the code is completely derived from diagrams. This tends to be quite difficult. A much easier approach is only using foward engineering to generate skeleton code.
|
||||
|
||||
Foward engineering is easier with SQL and ERDs than other types as these don't consider behaviour, so the mapping is more simple than with UML and Java.
|
||||
|
||||
Although this idea sounds good, it is not practical. The main argument is that code is part of the design anyway - Code is just a detailed form of a model.
|
||||
18
content/notes/treaps.md
Normal file
18
content/notes/treaps.md
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
title: "treaps"
|
||||
aliases: Treaps
|
||||
tags:
|
||||
- cosc201
|
||||
- datastructure
|
||||
---
|
||||
|
||||
Treaps
|
||||
Link betwen heaps and trees that uses randomisation
|
||||
|
||||
I we are added items to a bst in random order then an unbalanced situation would be possible but highly unlikely.
|
||||
|
||||
a treap (portmanteau of tree and heap) is designed to achieve this even in the elements are not added in random order
|
||||
|
||||
when we add an element, we give it a random priority. Then after doing normal BST insertion we perform a series of rotations to fix the heap-ordering issues
|
||||
|
||||
the effect is that the elements look as if they were inserted in decending order of priority. SInce the priorities were randomly chosen, that means that at any time we see a BST which "thinks" that is elements were added in random ord
|
||||
116
content/notes/uml-java-forward-engineering.md
Normal file
116
content/notes/uml-java-forward-engineering.md
Normal file
@ -0,0 +1,116 @@
|
||||
---
|
||||
title: "uml-java-forward-engineering"
|
||||
aliases: UML to Java Foward Engineering
|
||||
tags:
|
||||
- info201
|
||||
---
|
||||
|
||||
similar to ERD to sql.
|
||||
|
||||
use case diagrams - more about system structure and features
|
||||
**class diagram - java class
|
||||
- doesn't have to be java
|
||||
- could be any oop language
|
||||
sequence, activity, state etc, may or may not be useful.
|
||||
some code can be automatically generated.
|
||||
|
||||
custom methods cannot be generated automatically. things like getters and setters can be generated automatically.
|
||||
|
||||
## Steps
|
||||
1. uml class -> java class (in its own file) (dont overdo it) (e.g., librarian)
|
||||
1. use conceptual vs implementation level diagrams
|
||||
2. assign data types to explicit class fields
|
||||
3. add fields implied by associations
|
||||
1. unidir ⇒ field in class at tail of -->
|
||||
2. bidir ⇒ field in class at both ends <-->
|
||||
3. multi = 1 ⇒ simple field (e.g., string)
|
||||
4. multi > 1 ⇒ appropraite collection type (e.g., arraylist, hashmap etc)
|
||||
4. field visibilty normally private (should match class diagram)
|
||||
5. add constructors if needed
|
||||
6. add public getter and setter methods (trivial, can be auto generated)
|
||||
7. add remaining public or private methods (includilng implemented interfaces)
|
||||
|
||||
## aside on visibilty
|
||||
|
||||
|
||||
## use case diagrams
|
||||
|
||||
each use case represents a feature. often items in a menu. sub cases can be sub menu items (extnd, include, require) (sometimes).
|
||||
|
||||
actors *can* correspond to domain classes.
|
||||
|
||||
one use case might require/use several classes. e.g., UI, processor, or data classes.
|
||||
|
||||
## other behavioural diagrams
|
||||
|
||||
**sequence:
|
||||
- could be used for looping and branching
|
||||
**activity:
|
||||
- low level in particular
|
||||
- can be used to generate some code
|
||||
- would require discipline in diagram conventions
|
||||
- by this point you are basically writing code in graphical form anyway
|
||||
- might as well just write the code anyway
|
||||
**state:
|
||||
- most useful/likely to be use for code
|
||||
- states machines are tedious
|
||||
- [finite-state-machine](notes/finite-state-machine.md)
|
||||
- often translate to some kind of lookup mechanism
|
||||
- fairly easy to generate correspoding code
|
||||
- boils down to some kind of index.
|
||||
- however these are not used very often
|
||||
- once this code is generated is hard to fix manually
|
||||
- better to just change the diagam and regenerate the code
|
||||
|
||||
|
||||
## subclasses
|
||||
[employe diagram example](https://i.imgur.com/EAiVEkt.png)
|
||||
[eployee code example](https://i.imgur.com/bighWWJ.png)
|
||||
[code continued](https://i.imgur.com/Hxcho66.png)
|
||||
|
||||
- this example is contrived
|
||||
|
||||
- salariedemployee and wagedemployee inherit all public and protected methods of employee (including getters and setters, not including constructors)
|
||||
- salariedEmpoyee and waged employee each have thier own computePay method
|
||||
|
||||
## Interfaces
|
||||
[diagram](https://i.imgur.com/pN660p0.png)
|
||||
[code](https://i.imgur.com/iDyoeSE.png)
|
||||
|
||||
- generally preffered to subclasses
|
||||
- both salaried and waged employees must implement the computePay method
|
||||
|
||||
# Domain class model vs ERD structure
|
||||
|
||||
- erd are about long term storage. data persistence
|
||||
- domain models are about application process, temporary storage.
|
||||
- database and class structures dont need to be the same
|
||||
- but you do need to be able to map between them
|
||||
|
||||
[domain class model vs erd structure](https://i.imgur.com/feN6a9W.png)
|
||||
|
||||
# Example: Library system
|
||||
|
||||
e.g.,
|
||||
[library example uml diagram](https://i.imgur.com/u4CNXOb.png)
|
||||
the five horizontal items could be meny items. there will be some kind of authorisation for senior librarians. we probably wouldn't make seniour and junior librarian as differnce classes. there is not really any benefit, doing this would be overkill. We should use a single librarian class with `type` field. this field can be used for authorisation. The apply fine use case is an optional sub task. It could be implemented in many ways: checkbox on return form, sub menu item, automatic. shelve item is a differnt, its more of a business process. only thing need in the code it the change the status of the item.
|
||||
|
||||
|
||||
|
||||
[code part 1 Loan class](https://i.imgur.com/6VoV54C.png)
|
||||
[code part 2 Loan class 2](https://i.imgur.com/Q8yptdE.png)
|
||||
[code part 2 Loan class 3](https://i.imgur.com/4Xst3ys.png)
|
||||
|
||||
|
||||
## Multiplicity
|
||||
|
||||
|
||||
mih multiplicity of - ⇒ can create instances of Loan withou providing any associated LoanItem instances
|
||||
|
||||
min multiplicity 1 ⇒ must provide associated Loan instand when creating a LoanItem instance
|
||||
1. create loan and loanItem then use LoanItem.setLoan()
|
||||
2. use a custom LoanItem constructor to pass Loan object
|
||||
|
||||
[multiplicity code ](https://i.imgur.com/RKa9NBy.png)
|
||||
|
||||
unidirectional association are preffered as here we need to link things birdirectionally. this example is contrived, in real life it would not be done this way.
|
||||
70
content/notes/visual-design-typography.md
Normal file
70
content/notes/visual-design-typography.md
Normal file
@ -0,0 +1,70 @@
|
||||
---
|
||||
title: "visual-design-typography"
|
||||
aliases: Typography
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
most common fonts
|
||||
- gill sans
|
||||
- helvetica
|
||||
- calibri
|
||||
- arial
|
||||
- times
|
||||
|
||||
three types of fonts
|
||||
- serif
|
||||
- sans serif
|
||||
- handwritten
|
||||
|
||||
point size
|
||||
|
||||
|
||||
leading depends on the font and the user setting but usually is 20% of the font
|
||||
|
||||
|
||||
x height depends on the font.
|
||||
- smaller x height adds "elegance"
|
||||
- larger x height isbettwe to low res displays
|
||||
|
||||
|
||||
ascenders and descender usually correlates with x height (small x-height > large ascenders and descenders)
|
||||
|
||||
|
||||
weight: usually regullar and bold, also light semibold, ultrabold
|
||||
|
||||
|
||||
sans serifs have less line width variation
|
||||
|
||||
|
||||
some fonts provide small caps and lowercase numbers
|
||||
|
||||
|
||||
|
||||
|
||||
- serif hypothesis
|
||||
- serif fonts are easier to read
|
||||
- preferable for long stretches of text because serifs provide anchors and guide the eye
|
||||
- not proven
|
||||
|
||||
more info on the top than the botton
|
||||
|
||||
|
||||
expectation plays an important role
|
||||
|
||||
|
||||
|
||||
|
||||
## which font to use?
|
||||
- depends on context
|
||||
- recoomentations
|
||||
- slides and posters sans serif
|
||||
- printed text serif
|
||||
- web sans serif
|
||||
- sans serif is better in lower resolutions
|
||||
- combinations: (header sans, text serif)
|
||||
- comic sans good for dyslexia
|
||||
- logos should catch the eye
|
||||
|
||||
|
||||
|
||||
24
content/notes/visual-design.md
Normal file
24
content/notes/visual-design.md
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "visual-design"
|
||||
aliases: Visual Design
|
||||
tags:
|
||||
- info203
|
||||
---
|
||||
|
||||
combine text and graphics. how to represent?
|
||||
|
||||
- whitespace for grouping
|
||||
- size contrasts for heiarchy
|
||||
- variable scale and weight
|
||||
- colors
|
||||
|
||||
|
||||
three goals
|
||||
- guide
|
||||
- pace
|
||||
- message
|
||||
|
||||
Three tools
|
||||
- typography
|
||||
- layout
|
||||
- colour
|
||||
@ -20,10 +20,10 @@ case 2:
|
||||
tR+="- [ ] 10:00 Info203 Lecture\n- [ ] 11:00 Cosc201 Lecture\n- [ ] 13:00 Info201 Lecture\n- [ ] 14:00 Cosc202 Lab"
|
||||
break;
|
||||
case 3:
|
||||
tR+="- [ ] 10:00 Info203 Lecture\n- [ ] 14:00 Info203 Tutorial\n- [ ] 16:00 Cosc201 Tutorial"
|
||||
tR+="- [ ] 10:00 Info203 Lecture\n- [ ] 16:00 Cosc201 Tutorial"
|
||||
break;
|
||||
case 4:
|
||||
tR+="- [ ] 11:00 Cosc202 Lecture\n- [ ] 12:00 Cosc201 Lab\n- [ ] 16:00 Info201 Lecture"
|
||||
tR+="- [ ] 11:00 Cosc202 Lecture\n- [ ] 12:00 Cosc201 Lab\n- [ ] 12:00 Info203 Tutorial\n- [ ] 16:00 Info201 Lecture"
|
||||
break;
|
||||
case 5:
|
||||
tR+="- [ ] 09:00 Cosc202 Lab\n- [ ] 11:00 Cosc201 Lecture\n- [ ] 12:00 Info201 Lab"
|
||||
@ -49,4 +49,4 @@ break;
|
||||
### info 201
|
||||
|
||||
- [cousework tiddlywiki](https://isgb.otago.ac.nz/infosci/INFO201/labs_release/raw/master/output/info201_labs.html#)
|
||||
- [Assignments tiddlywiki](https://isgb.otago.ac.nz/info201/shared/assignments_release/raw/master/output/INFO201_Assignments.html)
|
||||
- [Assignments tiddlywiki](https://open.spotify.com/album/23DJ3KNE5JXi61G31T2Kni?si=-zZEHXIxT2qOEN6_Ns5C5Ql)
|
||||
Loading…
Reference in New Issue
Block a user