auto update

content/notes/07-testing.md

@@ -0,0 +1,18 @@
+---
+title: "07-testing"
+tags: 
+- cosc202
+---
+
+# 07-testing
+
+- [[testing]]
+- [[test-driven-development]]
+- [[unit-testing]]
+
+- undnerstand that testing is useful for detecting bugs
+- contrast different types of testting
+- descrive the principle of test driven development
+- explain how unit tests ar developed
+- indicate how languages integreate unit test support
+- apppreiciate limitation of software testing

content/notes/08-debugging.md

@@ -0,0 +1,9 @@
+---
+title: "08-debugging"
+tags: 
+- cosc202
+---
+
+# 08-debugging
+
+[[debugging]]

content/notes/09-documentation.md

@@ -0,0 +1,9 @@
+---
+title: "09-documentation"
+tags: 
+- cosc202
+---
+
+# 09-documentation
+
+[[documentation]]

content/notes/10-continuous-integration-1.md

@@ -0,0 +1,16 @@
+---
+title: "10-continuous-integration-1"
+tags: 
+---
+
+# 10-continuous-integration-1
+
+[[continuous-integration]]
+
+1. explain the term continuous integration
+2. describe different purposes for CI
+3. indicate how CI jobs are usually triggered
+4. understand implications of CI running asynchronously
+5. Exlplain how to manage output from CI jobs
+6. describe role of stages and jobs within gitlab pipelines
+7. indicate how CI specifications are stored

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

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

content/notes/continuous-integration.md

@@ -6,4 +6,77 @@ tags:
 
 # continuous-integration
 
+## 1 What is it
+continuous --> is always happening
+integration --> connecting software components
 
+- in contrast to ad hoc, occasional integration:
+	- diverging component developmetnamy break integration
+	- repaiing software may be expensive
+
+- supports 'aglile' software dev
+	- like test driven development, help catch issues early
+
+- usually automated
+
+## 2 Purposes
+- checking code syntax
+	- e.g., have CI compile the code and report errors
+	- (local devs compilaer may be different from remote)
+- checking semantics of code
+- building docs
+	- e.g., auto run javadoc
+- running projects code tests
+	- auto run JUnit, and report fails
+
+## 3 Starting CI jobs
+- from version control
+	- e.g., every commit triggered CI jobs to run
+	- starts on a push to server
+- manually
+- on a schedule
+
+## 4 Runs asnychronously
+- dont require devs to wait for completion
+- common to run locally as well as on consistent standard environment
+
+- other timescales
+	 - local checks as you commit
+	 - checks as you type
+	 - checks as you save
+
+## 5 Output
+since CI is asynchronous, its feedback is also
+
+- e.g., 
+	- web badges showing status
+	- can send emails
+	- messaging platform
+		- e.g., slack, discord, teams
+		- webhooks etc
+
+git project websites usually provide logging interface,. They will watch scripts in virtual terminal and capture output from CI scripts
+
+## 6 Github piplines
+
+- a pipeline has multiple _stages_
+	- e.g., test, build, deploy
+
+- each stages has multiple _jobs_
+	- e.g., JUnit, custom tests, etc
+
+## 7 Yaml
+
+- most Ci frameworks use YAML for their configuration
+- structured text based formats
+- python-like format or ≈JSON
+
+## 8 configurationg from git repo
+
+- CI config often via file in git top-level directory
+- CI is version managed
+
+- Gitlab pipeline specs go into .gitlab-ci.yaml:
+	- shows command sequece to run for a jon, within a stage
+	- output from commands is stored for a subsequent viewing
+	- indicates what files 'artifacts' should be kept from jobs

content/notes/debugging.md

@@ -0,0 +1,70 @@
+---
+title: "debugging"
+tags: 
+- cosc202
+---
+
+# debugging
+
+removing technical faults
+isolaing and remove technical faults
+a human process
+- requires creativity/disipline/knowledge
+- deepr understanding of code
+
+debuggers are tools to help debugging
+
+## 1 common approaches
+temporarily add output of diagnostic info
+- "printf" debugging
+permanently include calls to logging system
+- route to terminal, log files etc
+
+## 2 debugging machine code
+- cpu runs code instruction by instruction
+	- thus debugger can intervene between instructions
+	- most cpus help debugger interrupt and resume programs
+- cpu reached current code via a sequence on callers
+	- called **stack trace** , aka back frame, stack frame etc
+- may reach point where it cannot continue
+	- e.g., integer division by zero, program execution must stop
+	- stack trace of stopped program can be analysed
+
+## 3 Imperative languages
+These are language that are executed in a step-wise, sequentail manner.
+
+- debug symbols
+	- e.g., method named, variable named
+- source code context
+	- line numbers
+	- variable name
+	- function method names
+
+## 4 doing debugging
+### 4.1 stepping skipping running
+- step into --> steps one statement and steps into function calls
+- step over --> a step that treats function calls as statement
+- step out --> return to the instruction after the function call you're in
+- continue  --> go back to running code continuously
+
+### 4.2 controlling debugger execution
+
+Can run normally --> debugger wil run when program crashes
+
+Set Breakpoint --> debugger will stop program when/if that line is reached
+- conditional breakpoints only suspend if a condition is true
+
+Watch point --> program is suspended when some data changes (e.g., variables)
+
+## 5 debugging non imperative languages
+
+e.g, spreadsheet (Dataflow programming)
+- no breakpoints
+- must step through _iterations of computations_
+
+e.g., Equation
+- break into smaller parts
+- try 'compile' it in multiple ways
+
+e.g., Data base query (declarative programming)
+- -reexpressign the query and comaring can be useful

content/notes/documentation.md

@@ -0,0 +1,68 @@
+---
+title: "documentation"
+tags: 
+- cosc202
+---
+
+# documentation
+
+## 1 Who, what where
+- Audience
+	- users
+	- other devs
+	- your team members
+	- anyone trying to understand you software
+	- your future self
+- Locations
+	- source code
+	- project repo
+	- emebedding in program
+	- hosted separately
+- User expectations
+	- evolving towards software that _facilitates experimentation_
+		- No help docs => everything is self-explanatory
+	- high usability
+	- users familar with many abstractions
+		- e.g., touchscreens, menus, links
+- API's
+	- for devs writing code to interact with your code
+	- typically coupled with docs
+	- entirely technical audience --> tool generated docs are okay
+	- not self explanatory
+	- used by devs unfamiliar with code base
+- Project Docs
+	- meaningful commit msgs
+	- extra mangement with e.g., github
+		- issue tracking
+		- ensures relevant material is cross linked where possible
+		- can easily refer to source code
+- Source code docs
+	- header comments
+		- software licencing
+		- support devs
+		- indicate code ownership
+	- in code comments on fields methods etc
+		- keep in sync with code changes
+	- descriptive variable/class/other names
+	
+## 2 Built in language support
+- basic
+	- syntax for code comments
+	- indicate that the compiler should ingnore
+	- also more advanced like python "doc strings"
+- Structured comments and docs
+	- machine parseable comments
+		- e.g., javadocs, perl plain old docs
+		- creates a doc website
+		- uses annotations e.g., @author, @returns, @param
+- Literate programming
+	- donald knuth suggestions (1984)
+		- source code should be primarily natural language documentation
+		- executable code snippetrs are included within the description
+		- tools are used to:
+			- tangle the code snippets
+			- weave out the documentation
+	- Modern implementations
+		- jupyter notebooks
+		- swift playgrounds
+		- r markdown

content/notes/test-driven-development.md

@@ -0,0 +1,17 @@
+---
+title: "test-driven-development"
+tags: 
+- cosc202
+---
+
+# test-driven-development
+
+tests are developed before the code
+
+are a spec of what the code should do
+
+first they fail ⇒ as you develop, they pass
+
++ quantifiable progress of code
+
+> tests are not always bug free

content/notes/testing.md

@@ -0,0 +1,28 @@
+---
+title: "testing"
+tags: 
+- cosc202
+---
+
+# testing
+
+- most software will contain bugs
+- bug severity if not always equivalent to bug priority
+- testing is seeking out bugs
+- some test types
+	- unit tests
+	- integration tests ⇒ check units work together
+	- end-to-end tests ⇒ check behaviour of whole program
+
+## 1 Limitations
+- testing every code path is impossible
+	- halting problem - cant fully analyse code using code
+	- proved by alan turing in 1936
+
+- good test design focuses on _key cases_ to pass and fail
+- not probe interaction between units
+	- this should be done by integration testing
+
+- testing may afffect behaviour of code
+	- testing framework may affect the order of esecution
+	- testing framework may change execution speed

content/notes/unit-testing.md

@@ -0,0 +1,89 @@
+---
+title: "unit-testing"
+tags: 
+- cosc202
+---
+
+# unit-testing
+
+- divide code into units ⇒ test those units
+
+- consider appropriate scale
+	- depends on type of code project as well as language
+	- object oriented: classes? methods?
+	- procedural: functions? modules?
+
+- test each unit independently
+	- frequently
+	- often after each commit/push
+	- can run tests if parallel
+	- may need to build environment in which tests run
+
+### 0.1 supports useful principles
+can support complementary work by team members
+early discovery of problems
+can help with documentation and specification
+- unit tests can be a form of executable specification
+- helps team members understand requirements
+
+### 0.2 Test environment
+consider code that interacts with a database
+- you cant let that code write to a real database
+- but you want to check that writes were performed
+
+common solution is to create a fake database
+- class that mocs database operations
+- can also test error handling by returning error codes
+
+mock up the database with a pretend model that returns fixed results to query
+- be careful not to mock up data base incorrectly
+
+can be a pre-recorded interaction
+
+### 0.3 Test life cycle
+- set up test environment
+- run test code
+- check results
+- aggregate results into test summary
+
+simple test: run method ⇒ check value
+tests may chack that code fails appropriately
+- crash when expected
+- exceptions are generated
+
+### 0.4 Language support
+language may have bilt in testing support
+- e.g., Go and Rust have command line tools to run tests
+
+External tools can often work well too
+- e.g., java code annotations can mark tests
+- java ignores most annotations, but testing tools (JUnit)  can use them
+- annotations are symbols that begin with @ in source code
+
+we want to distinguish between tests and normal code
+- also should support for sqapping in/out mocking code
+
+### 0.5 JUnit
+test classes have a particular filename pattern
+
+annotate test methods with @Test
+
+other annotations
+
+- @BeforeAll and @BeforeEach (and after)
+- @RepeatedTest
+
+JUnit 5 also supports dynamically generated tests
+
+### 0.6 TestNG
+
+based off JUnit and fixes some it it's problems
+
+- provides control over threading
+	- run tests in parallel
+	- also tests for parallelism bugs
+	- multithreaded code i hard to debug
+- data driven testing
+- also
+	- integration testing
+	- end to end testing