doit

static-analysis/README.org

@@ -0,0 +1,101 @@
+#+TITLE: Program Analysis
+#+Author: Adam Mohammed
+
+
+* Program Analysis tools
+
+Generally program analysis tools come in two forms, static and
+dynamic. Each has tradeoffs that we need to understand, especially
+when we start to build these tools.
+
+It's important to understand what each analysis tool is good for,
+knowing what it's strong at detecting, as well as knowing what they
+are not good for and where they struggle.
+
+** Examples of Static Analysis
+RuboCop
+Gofmt
+Rufo
+*** Good
+- Detecting syntax errors
+- Detecting simple semantic errors
+- Detecting style violations
+- Detecting code convention violations
+
+*** Bad
+- Prone to false positives and false negatives
+- Requires access to source code, including libraries
+- Does not account for runtime environment
+
+
+** Examples of Dynamic Analysis
+Profilers
+- ruby-prof
+
+Memory leak detection
+- Valgrind
+
+Data Races
+- Go race detector
+
+
+
+
+*** Good
+- Detect bugs that only can occur at runtime
+- Capable of measuring things inlfuenced by factors outside of source code
+  - e.g. Network latency, External errors, etc
+- Generally less false positives and false negatives because error
+  cases must occur to be detected
+
+*** Bad
+- Requires actually violating edge cases to report them
+- Often incurs performance penalty to instrument live code
+- True positives can be missed for code paths that are not exercised often.
+
+
+** Problem we're actually facing
+
+- Monolith is large and old
+- OAS is used as the source of truth to generate clients and documentation that customers rely on
+- Monolith and OAS don't agree most of the time
+
+
+** Solutions we're trying
+
+https://github.com/equinixmetal/api-spec-inspector - form of SA
+
+
+** Back to basics
+
+How do programming languages do their job?
+
+Source code -> interpreted -> output
+
+If you're in a compiled languages
+
+source code -> compiled -> executable -> output
+
+
+We treat "interpreters" and "compilers" as black boxes for the most part.
+
+Let's pull back the curtains on these things though:
+
+** How does code get interpreted?
+
+1. Show ruby-parse
+
+2. Talk about AST
+
+** Utilizing the AST
+
+ex 01-03_
+
+** Problem areas for test parsing
+
+ex 04 vrf params
+
+
+** Rubocop Examples
+
+https://github.com/rubocop/rubocop/blob/02c32b4cf3801f9cf4cca4b3f1f4288aaee2ad5c/lib/rubocop/cop/lint/useless_setter_call.rb