GitHub/quartz
1
0
Fork 2
mirror of https://github.com/jackyzha0/quartz.git synced 2025-12-23 21:04:07 -06:00
Code Issues Actions Packages Projects Releases Wiki Activity

auto update

Browse Source
This commit is contained in:
Jet Hughes 2022-04-06 23:47:24 +12:00
parent f635f570ca
commit 5b9d712738
17 changed files with 609 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
content/notes/anti-govt-protest-china.md Normal file
View File

@ -0,0 +1,12 @@
---
title: "anti-govt-protest-china"
tags:
- cosc202
---
# anti-govt-protest-china
China used facial recognition to identofy protesters
these protesters used masks and toppled lamposts to thwart this infrastructure

84
content/notes/branch.md Normal file
View File

@ -0,0 +1,84 @@
---
title: "branch"
tags:
- cosc202
---
# branch
Split current dev path into two to work on e.g., a bug or a feature
## 1 Overview
- allows users to work independently
- development continues independently along each branch
- can easily switch between branches
- can push a branch without affecting others
- branches can be merged back into the original
- always at least one main branch (usually master, main, trunk)
## 2 Default branch
- used to be called master
- now called main
## 3 Methodologies
### 3.1 Working on the main branch
- focuses on not creating branches
- over time long branches become difficult to merge
- smaller, self-contained changes are encouraged
- focus on main code objective, avoiding side-experiments
- sometimes this is not possible
- complex bugs or features need branches
- pair programming
- e.g., vs code allows multiple developers to work on the same code at the same time.
### 3.2 Working off the main branch
- branches can be shared with teams
- still isolated commits from the main branch
- more commits can be added to a branch _after_ it has been merged
### 3.3 Feature branching
- all new features are developed in a separate branch
- merging to the branch "adds" that feature
- after a feature is added, it call still be added to using the same branch
### 3.4 Gitflow
- viewed as ovecomplicated
- a set of shell scripts helps it be used
- highly structured
- e.g.,
- main branch -> branch has commit for release versions
- develop branch -> branch is where development occurs
- feature branch -> branches branch off development branch
- release branch -> branch polishes for release
- hotfix -> branches of main branch thence into develop
## 4 continuous integration
[[continuous-integration]]
- [CI vs feature branch](https://www.youtube.com/watch?v=v4lijkq6Myfc)
- [Cl vs feature branch](https://www.youtube.com/watch?v=IXQEi1O5!OI)
## 5 Topic/feature branch
- created for a specific purpose .e.g, bug/feature
- can pull from remote without marge conflicts (should be only one person working on branch)
- the more short-lived branches are the less likely there are to be merge conflicts with main
## 6 Persistent branch
- long term branch that exists for the lifetime of the project
- e.g.,
- release branches
- release v1, start on v2
- security flaw in v1, needs to be fixed
- v2 not finished yet
- create branch at last v1 commit and fix there
- also fix in v2 (if applicable)
- v1 branch will last until v2 is released
- specialsed versions of code base
- e.g., to support specific platforms or hardware
- e.g., to support feaures for a specific customer
- features for this specilised version on go on that branch
- keeps specialised code out of main codebase

25
content/notes/consoles-terminals-shells.md Normal file
View File

@ -0,0 +1,25 @@
---
title: "consoles-terminals-shells"
tags:
- cosc202
---
# consoles-terminals-shells
- console -> io device which is part of a computer (physical terminal)
- console is the device: -> terminal is program inside that device
- terminal -> text input output environment (can be remote)
- windows terminal
- [[shell]] -> program which the terminal/console sends input to which sends command to the OS
- [[unix-shell]]
- powershell
- cmd
- bash, fish, zsh, ksh, sh, tsch
#### 0.1.1 BREIF HISTORY
1. At first only main console
2. Then multiple terminals which allowed mulitple people to use one computer
3. Graphics support
4. Console + terminal merged
5. Virtual terminals -> no need for direct hardware control -> replaced by OS

9
content/notes/continuous-integration.md Normal file
View File

@ -0,0 +1,9 @@
---
title: "continuous-integration"
tags:
- cosc202
---
# continuous-integration

4
content/notes/cosc-201.md
View File

@ -16,5 +16,5 @@ tags:
## 2 Assignments
- [[assignment-02]]
- [[assignment-01]]
- [[assignment-01]]
- [[assignment-02]]

6
content/notes/cosc-202-lectures.md
View File

@ -7,4 +7,8 @@ tags:
# Cosc 202 Lectures
- [[]]
- [[07-testing]]
- [[08-debugging]]
- [[09-documentation]]
- [[10-continuous-integration-1]]
- [[11-continuous-integration-2]]

6
content/notes/cosc-202-outline.md
View File

@ -7,4 +7,8 @@ tags:
# cosc-202-outline
- [[consoles-terminals-shells]]
- [[git]]
- [[ethics-in-cs]]
- [[integrated-development-environments]]
- [[branch]]

2
content/notes/cosc-202.md
View File

@ -11,8 +11,8 @@ tags:
## 1 Course Outlines
- [[cosc-202-outline]]
- [[cosc-202-lectures]]
- [[cosc-202-outline]]
## 2 Assignments

61
content/notes/ethics-in-cs.md Normal file
View File

@ -0,0 +1,61 @@
---
title: "ethics-in-cs"
tags:
- cosc202
---
# ethics-in-cs
## 1 Case studies
1. [[facial-recognition-in-US-riots-2021-01-06]]
2. [[anti-govt-protest-china]]
3. [[how-is-safe-enough-for-autonomous-vehicles]]
### 1.1 Differences 1 vs 2
Govt vs vigilante
my judgements contain additionl context
e.g., pro-democratic vs anti
world contains vast differences
how systems of laws work
extent of civil liberties afforded to individuals
### 1.2 Discussion
When developing a technology you dont know what is could be used for
## 2 Ethical handling of data
- Data moves very quickly due to computerised systems
- privacy act 2020
- its unethical to ignore potential security problems
- df
## 3 Ethical handling of bias and errors, e.g., in AI
- large datasets oftenb incdlude bias and errors
- to AI trained on these datasets with also be biased
- e.g., facial recognition trining overrepresenting white males
- ML algorithgms are often opqaue
- its not possible to understand how decisions are reached
- makes asessing suitability of AI for a use case difficult
- explainable AI
- attacks e.g., 'trapdoors' within ML training data
## 4 False or misleading claims
- pressure to release can lead to false claims
- are features fully tested
- need to assess risks of bias
- e.g., AWS uptime information
- rumoured that service status colour is n management decision
-
## 5 Your responsibility
- dont stay silent
## 6 Professional reponsibilities
- comp science per se lacks profressional standards
- there are some prefessional bodies which encoede responsibilities
- ACM coc
- IEEE coc
- neither are specific to NZ
- Within NZ must consider treaty obligations

14
content/notes/facial-recognition-in-US-riots-2021-01-06.md Normal file
View File

@ -0,0 +1,14 @@
---
title: "facial-recognition-in-US-riots-2021-01-06"
tags:
- cosc202
---
# facial-recognition-in-US-riots-2021-01-06
capital riots occured on 2021-01-06
there was video from the riots which contained faces
- facial recognition acquired a pic of each person
- faces were uploaded to a website

48
content/notes/git-cheat-sheet.md Normal file
View File

@ -0,0 +1,48 @@
---
title: "git-cheat-sheet"
tags:
- cheatsheet
---
# Git Cheat Sheet
## 1 Commands
- Clone -> create local copy of remote repo
- Commit -> save changes to local repo
- Packages logically related collection of changes and save the permanently is repos history
- Each commit should address single well defined task
- Commits should be small and regular
- Should contain a brief, informative, message
- one line -> <50 (commit needing more than this are likely too large)
- multi line -> <72
- well defined, shared terminology
- consider what other devs need to know
- Stash -> temporarily store uncommited changes
- Push -> Upload changes from local repo to remote
- Pull -> Download and merge changes from remote repo into local repo (fetch + merge)
- Merge -> Merge changes from one brach into another
- merge when:
- pulling changes from remote into your repo
- merging from branch into main codebase
- Can merge any branch into any other branch
- good idea to regularly rebase specialised persistent branches to keep them in sync with the more general main codebase
- rebase topic branches before merging into main
- helps to deal with merge conflicts
- only branch is broken if you mess up
- can test for breakage before merging to main
- Merging is usually automatic
- sometimes merge algorithm can't resolve conflicting changes to the same code
- e.g., two devs change the same method at the same time
- conflict must then be manually resolved
- All VCS will check that your repo is up to date before pushing, and force you to push if not
- Tag -> name a particular commit e.g., for a release
## 2 Terms
- Head -> most recent commit on Current branch
- [[branch]] -> Split current dev path into two to work on e.g., a bug or a feature
- Repository -> Where the codebase/file are stored
- Contains meta-data about the previous vesions etc
- Merge commit -> commits which are derived from multiple parent commits
- Git tag -> e.g., v 1.0
- cannot be move by commits
- record metadata

123
content/notes/git.md Normal file
View File

@ -0,0 +1,123 @@
---
title: "git"
tags:
- cosc202
---
# git
- Git is a tool to track changes to sets of file
- It is the most commonly used [[version-control-system]]
## 1 Team git protocols
you can develop a team protocol for Git use
e.g.,
- agree to commit often
- know what branches are being used and why
- consider pair programming / live sharing
- try not to touch lots of files without signalling why
- agree who's going to edit files that maight not auto merge
## 2 web based repo access control
- owner of repo chooses who can push to project
- maintainer -> cant remove data
- developer -> cant manage team
- reporter -> cant change codebase
- guest -> can view
### 2.1 open source collaboration
you want contributions from everyone
but you dont want to manage user-level control
-> pull/merge requests
unknown users can fork then add a feature/bug then do a merge request which can be reviewed
## 3 git repos
[[notes/git-cheat-sheet|Repositories]] maintain code history
can be conceptualised as a graph
```mermaid
graph RL
A[HEAD]-->1[MASTER]-->B((ab348b))-->C((hf33h3))
C-->D((3hh39h))
C-.Merge.->E((n3383b))
3[Branch]-->E
D-->H((kfj383))
E-->G((gj4jf4))
G-->H
H-->I((fjfj39))
I-->2[Inital Commit]
```
```mermaid
gitGraph:
checkout master
commit
commit
branch newbranch
checkout newbranch
commit
commit
checkout master
commit
merge newbranch
commit
commit
```
![[Pasted image 20220306103955.png|300]]
- nodes are commits -> immutable snapshots of the tracked files
- edges record how nodes emerged over time
- arrows can be read as "is derived from"
git is a [[notes/version-control-system#4 3 Distributed Centralised]]
- every team members has their own local copy of the repo
- git repos are often syned with a server: github, gitlab,etc
## 4 levels of complexity/Abstraction
```mermaid
graph TD
w(github gitlab from web browser)-->b(graphical ide's e.g., vscode)-->c(command line git)-->d(low level git plumbing commands)-->e(direct manipulation of records within repo's .git directory)
```
## 5 Limitations/pain points
- not designed for broad usability
- bottom up design stems from its implementaion,
- rather than top down design from user interface
- thus, command naming and syntax can be unintuitive
- git is not suited to handling large data files
- git scans whole files to generate hash codes
- can use git lfs (large file support) to get around this
- flexibility of git can lead to high cognitive load
- e.g., many ways to get others' commits to your repo
- binary files e.g., JPEG images are treated as whole
- no differencing, no content merging
- some text files may not have stable line structure
- e.g., XML data can be reordered wihout changing so:
- git can auto merge when this is destructive
- git may get confused and force you to merge
- e.g., node package-lock.json
- you can turn of auto-merge if you are working with files that may be problematic
## 6 advantages
- git repos' data structures are well designed
- clear in structure yet flexible and efficient
- few dependencies
- widely available
- free and open source
- community support around use of git is great
- eforts to get researches to use version control;
- github helped open source software flourish by making it easy for citizens to contribute to projects

17
content/notes/how-is-safe-enough-for-autonomous-vehicles.md Normal file
View File

@ -0,0 +1,17 @@
---
title: "how-is-safe-enough-for-autonomous-vehicles"
tags:
- cosc202
---
# how-is-safe-enough-for-autonomous-vehicles
- How safe is safe enough?
- its impossible to be perfect
- discalimer about driving assistant in teslas
Not driving youself massively reduces reaction time
Allow user to set ethical bias of their vehicles AI
![](https://i.imgur.com/eY5CeL6.png)

80
content/notes/integrated-development-environments.md Normal file
View File

@ -0,0 +1,80 @@
---
title: "integrated-development-environments"
tags:
- cosc202
---
# integrated-development-environments
## 1 Source code editors
- editor applications to help software development
- provide features that help editing code
- auto indent, bracket matching, syntax hl, auto completion, rapid navigation
- run/test code
## 2 Integrated dev env
- allow you to remain within one application when carrying out software development work
- can edit source files
- can compile source files
- can run debugger
- integrates version management
- some attach tools to running applications
### 2.1 LSP - syntax highlighting
- allows IDE's to communicate with a "language enging"
- ides dont need
- shift from syntac to semantics
- e.g.,
- vs code chck file on opening
- lsp reports type mismatches
- rich editor functionality
- autocompletion with appropriate context
- information displayed on mouse hover
- jumping to definitions on mouse hover
- safe refactoring -> better than blind search and replace
- diagnosticso -> e.g., display results of unit tests within editor
### 2.2 Navigation
- within files
- bracket matching
- block folding
- multi file
- multiple files at the same time
- rapidly jump between files
- search across all files
- collaboration e.g., live sharing
### 2.3 Modern IDEs
- microsoft
- vscode -> free open source, highly popular
- visual studio -> integrates mobile and cloud development
- java enivronments
- eclipse - early leader in java, supports other languages
- netbeans -> also includes web dev tooling
- jetbrains -> IntelliJ IDEA, pycharm, phpstorm
- google's android studio -> official android IDE
- apple's Xcode -> free, macOS/iOS focus
## 3 Early programming
- dedicated machines
- punched card programmer: separate machine from computer than reads cards
- punched cards recore code and or data in binary
- grid of positions, each representing a binary digit (bit)
- each position in punches out, or not
- analgogue electronic devices where you phsyicall wire things up
- gaining interest now for use in machine learning
### 3.1 Bootstrapping
- already built tools can be used to builder better tools for building better tools etc.
- e.g., first assembler was made in maching code. But after that they could use the assember to make a better assembler
### 3.2 Early dev environments
- command line based
- text based terminals
- command shell is the running application
- Can use terminal to drive interactive languages
- can edit, store software code
- can compile cose and run resulting executables
- it is still practical to do software development this way
- vim etc

13
content/notes/shell.md Normal file
View File

@ -0,0 +1,13 @@
---
title: "shell"
tags:
- cosc202
---
# shell
- start and stop OS processes
- used to control OS
- connect output of one OS process to input of another process -> this is the idea of Unix pipes
- manage environment variables: pass params to programs
- parse and evaluate command line instructions from user

28
content/notes/unix-shell.md Normal file
View File

@ -0,0 +1,28 @@
---
title: "unix-shell"
tags:
- cosc202
---
# unix-shell
- most common command shell (macOS, linux, android, ios)
- bash is another common shell
- windows shells:
- cmd.exe (legacy)
- powershell (more powerful than bash)
- many ways to run bash
## 1 Unix shell good/bad
- good
- embodies unix principle: separation of concerns
- minimal -> shell just manages interaction of other small tools
- highly programmable; supports complex automation
- bad
- has quirkiness that can trip everyone up
- tradeoffs
- Shell can be perfect to some tasks; terrible for others
- extremely powerful however also difficult to learn to use
shells are in cosc202 as lowest-level, common means for controlling computers during software development

82
content/notes/version-control-system.md Normal file
View File

@ -0,0 +1,82 @@
---
title: "version-control-system"
tags:
- info201
---
# version-control-system
VCSs (version control systems) Are systems to keep track of changes to a set of files
E.g., [[git]]
## 1 Goals
- allow collaboration
- track changes
- restoring previous versions
- finding out origins of issues
- backups
- not restrict workflow
## 2 Terms
[[notes/git-cheat-sheet]]
## 3 Discipline
- Pull/Push Regularly
- Use topic/features branches to keep main clean
- Dont use -f
## 4 Types
### 4.1 Centralised VCS
- Data is stored in one single central location
- Access is remote
- Checkout can block other devs
```mermaid
graph TD
subgraph Centralised Repo
Boris-. commit .->R((Repository))-- checkout -->Boris
R-- checkout -->Doris-. commmit .->R
R-- checkout -->Dennis-. commmit .->R
end
```
### 4.2 Distributed VCS
![](https://i.imgur.com/IVXAaFF.png)
- Data is stored on every access point
- Good
- more robust -> each dev has a backup
- Don't need internet
- Bad
- Hard to keep track of "main" files
### 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
- Passwords and other credentials among other things
- Data should be stored as encrypted blobs
- [BlackBox](https://github.com/StackExchange/blackbox)
## 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
- Create a fork of a project
- Make Changes
- Pull request to merge fork back into project
- Admins of project can acccept modify or reject pull request
## 7 software dev needs file wrangling
many copies of a project's source code files needed:
- facilitating different developers private code experiments
- working on fixing bugs in code
- developing new features
- reviewing code changes
- managing releases of sofware products
- using [[git]]