+5 -5

content/post/common-test-for-elixir.md

reviewed

··· 103 103 104 104 Just check [this out](/common-test-example/simple/index.html). This is example report 105 105 generated by the Common Test. As you can see it contains a lot of information in 106 106 - quite readable format. Not only it contains informations about current run, but 106 106 + quite readable format. Not only it contains information about current run, but 107 107 all previous runs as well, which is really handy when tracking regressions. 108 108 109 109 - But can we store even more informations there? Yes, as CT includes simple 110 110 - logging facility it is completely possible to log your own informations during 111 111 - tests, for example, lets modify our test to log some informations: 109 109 + But can we store even more information there? Yes, as CT includes simple 110 110 + logging facility it is completely possible to log your own information during 111 111 + tests, for example, lets modify our test to log some information: 112 112 113 113 ```erlang 114 114 test_function_name(_Config) -> ··· 116 116 2 = 1 + 1. 117 117 ``` 118 118 119 119 - Now when we run tests again, then we will see more informations (even coloured) 119 119 + Now when we run tests again, then we will see more information (even coloured) 120 120 in [our test log](/common-test-example/log/ct_run.ct@NiunioBook.2019-07-16_11.03.21/common-test-example.log.logs/run.2019-07-16_11.03.22/example_suite.test_function_name.html): 121 121 122 122 

+1 -1

content/post/log-all-the-things.md

reviewed

··· 308 308 ) 309 309 ``` 310 310 311 311 - As we can see there, the report contains informations like: 311 311 + As we can see there, the report contains information like: 312 312 313 313 - `:label` - that describes type of the event 314 314 - `:report` - content of the "main" event

+2 -2

content/post/who-watches-watchmen-i.md

reviewed

··· 238 238 239 239 systemd supports the second approach via [`sd_notify`][sd_notify]. The approach 240 240 there is simple - we have `NOTIFY_SOCKET` environment variable that contain path 241 241 - to the Unix datagram socket, that we can use to send informations about state of 241 241 + to the Unix datagram socket, that we can use to send information about state of 242 242 our application. This socket accept set of different messages, but right now, 243 243 for our purposes, we will focus only on few of them: 244 244 245 245 - `READY=1` - marks our service as ready, aka it is ready to do its work (for 246 246 example accept incoming HTTP connections in our example). It need to be sent 247 247 - withing given timespan after start of the VM, otherwise the process will be 247 247 + within given timespan after start of the VM, otherwise the process will be 248 248 killed and possibly restarted 249 249 - `STATUS=name` - sets status of our application that can be checked via 250 250 `systemctl status hello.service`, this allows us to have better insight into