added profiling to lab exercise

.gitignore

@@ -24,6 +24,7 @@ website.db
 *snap.png
 *diff.png
 *trace.json
+*.0x
 
 *.pptx
 *.mp4

03 Acceptance Testing.md

@@ -98,7 +98,7 @@ You have seen how to use Puppeteer to write a test to see that we can add a sing
 
 xxx
 
-### 1.3 Profiling
+## 2 Profiling
 
 When the tests were running we included two profiling tools:
 
@@ -127,9 +127,64 @@ An alternative is to use the network tab of the Chrome DevTools. Clicking on the
 
 There are many more settings you can experiment with to help understand the performance of your web server. Start by looking at [this tutorial](https://michaljanaszek.com/blog/test-website-performance-with-puppeteer).
 
-#### 1.3.1 Test Your Understanding
+### 2.1 Test Your Understanding
 
 xxx
 
-## 2 Gherkin
+### 2.2 Flame Graphs
 
+Another question often asked by software developers is how the software is consuming resources, what exactly is consuming how much, and how did this change since the last software version? These questions can be answered using software profilers, tools that help direct developers to optimize their code and operators to tune their environment. Flame graphs are generated from `perf` output.
+
+The output of profilers can be verbose, however, making it laborious to study and comprehend. The flame graph provides a new visualization for profiler output and can make for much faster comprehension, reducing the time for root cause analysis.
+
+Flame graphs are a way of visualizing CPU time spent in functions. They can help you pin down where you spend too much time doing synchronous operations. In this exercise we will use a package called [0x](https://www.npmjs.com/package/0x) which has already been added to the `devDependencies` in the todo project. You can start the profiler using the script alias in the package manifest or by running the command directly:
+
+```shell
+$ npm run profiler
+
+> todo@1.0.0 profiler /dynamic-websites/exercises/03_acceptance/todo
+> 0x -o index.js
+
+🔥  Profilinglistening on port 8080
+```
+
+You should now launch the app in the web browser and add and remove items from the list. This will capture the perf output in a directory ending in `.0x` with each run generating a new directory. Once you have made use of the todo list, press ctrl+c to quit.
+
+```shell
+🔥  Process exited, generating flamegraph
+🔥  Flamegraph generated in
+file://dynamic-websites/exercises/03_acceptance/todo/24526.0x/flamegraph.html
+```
+
+It will then try to open the specified html document in your default browser which will look something like this:
+
+![Flame graph](exercises/.images/flame_graph.png)
+
+Hovering over a box will reveal more information.
+
+1. Each box represents a function in the stack (a "stack frame").
+2. The y-axis shows stack depth (number of frames on the stack).
+    1. The top box shows the function that was on-CPU. Everything beneath that is ancestry.
+    2. . The function beneath a function is its parent, just like the stack traces shown earlier.
+3. The x-axis spans the sample population.
+    1. It does not show the passing of time from left to right, as most graphs do.
+    2. The left to right ordering has no meaning (it's sorted alphabetically to maximize frame merging).
+    3. The width of the box shows the total time it was on-CPU or part of an ancestry that was on-CPU (based on sample count).
+    4. Functions with wide boxes may consume more CPU per execution than those with narrow boxes, or, they may simply be called more often. The call count is not shown (or known via sampling).
+
+### 2.2.1 Test Your Understanding
+
+xxx
+
+## 3 Domain-Specific Languages
+
+Earlier in this lab you wrote a series of acceptance tests to ensure that your software (web application) met the user requirements. These tests were written in JavaScript using the Jest testing frameworks.
+
+### 3.1 Gherkin
+
+Gherkin is the format for cucumber specifications. It is a domain specific language which helps you to describe business behavior without the need to go into detail of implementation. This text acts as documentation and skeleton of your automated tests. Gherkin is based on TreeTop Grammar which exists in 37+ languages. Therefore you can write your gherkin in 37+ spoken languages.
+
+This script serves two primary purposes:
+
+1. Documents user scenarios
+2. Writing an automated test (BDD)

exercises/03_acceptance/todo/package.json

@@ -7,7 +7,8 @@
     "linter": "node_modules/.bin/eslint .",
     "test": "node_modules/.bin/jest --coverage --runInBand --detectOpenHandles",
     "watch": "node_modules/.bin/jest --coverage --watchAll",
-    "acceptance": "./test.sh"
+    "acceptance": "./test.sh",
+    "profiler": "./node_modules/.bin/0x -o index.js"
   },
   "author": "",
   "license": "ISC",
@@ -23,6 +24,7 @@
     "koa-views": "^6.2.1"
   },
   "devDependencies": {
+    "0x": "^4.9.1",
     "jest": "^24.9.0",
     "jest-image-snapshot": "^2.11.0",
     "jest-puppeteer": "^4.3.0",