diff options
| author | Paul Buetow <paul@buetow.org> | 2022-03-06 10:39:04 +0000 |
|---|---|---|
| committer | Paul Buetow <paul@buetow.org> | 2022-03-06 10:39:04 +0000 |
| commit | 230214cc402742a2ef61c5539ce8226e2394529b (patch) | |
| tree | c88c9ef595ae0c9f35b235d6cb1bebd015ab9788 /gemfeed | |
| parent | b26ae58c59e96f42ae42b5bc65c821827f53a4e1 (diff) | |
more on this
Diffstat (limited to 'gemfeed')
| -rw-r--r-- | gemfeed/2022-03-05-the-release-of-dtail-4.0.0.gmi | 151 | ||||
| -rw-r--r-- | gemfeed/atom.xml | 39 |
2 files changed, 184 insertions, 6 deletions
diff --git a/gemfeed/2022-03-05-the-release-of-dtail-4.0.0.gmi b/gemfeed/2022-03-05-the-release-of-dtail-4.0.0.gmi index 82006d51..88c82736 100644 --- a/gemfeed/2022-03-05-the-release-of-dtail-4.0.0.gmi +++ b/gemfeed/2022-03-05-the-release-of-dtail-4.0.0.gmi @@ -18,20 +18,165 @@ DTail (a distributed tail program) is a DevOps tool for engineers programmed in ### Integration testing suite -DTail comes already with some unit tests, but what's new is a full integration testing suite which covers all common use cases. +DTail comes already with some unit tests, but what's new is a full integration testing suite which covers all common use cases of all the commands (dtail, dcat, dgrep, dmap) with a server backend and also in serverless mode. +How are the tests implemented? All integration tests are simply unit tests in the ./integrationtests folder. They must be explicitly activated with: + +``` +% export DTAIL_INTEGRATION_TEST_RUN_MODE=yes +``` + +Once done, just run: + +``` +% go clean -testcache +% go test -race -v ./integrationtests +``` => ./2022-03-05-the-release-of-dtail-4.0.0/testing.gif ### Improved code -SonarQube/BlackDuck + refactorings to reduce code complexity. +Not that the code quality of DTail has been bad (I have been using Go vet and Go lint for previous releases and will keep using these), but this time I had new tools (such as SonarQube and BlackDuck) in my arsenal to: + +* Reduce the complexity of a couple of functions (splitting code up into several smaller functions) +* Avoid repeating code (this version of DTail doesn't use Go generics yet, though). + +Other than that, a lot of other code has been refactored as I saw fit. ### Rewritten logging +DTail is a special case when it comes to logging. There are logs processed by DTail, there are logs produced by the DTail server itself and there are logs produced by one of the DTail clients themselves. Furthermore, there are different log levels too: + +``` +// Available log levels. +const ( + None level = iota + Fatal level = iota + Error level = iota + Warn level = iota + Info level = iota + Default level = iota + Verbose level = iota + Debug level = iota + Devel level = iota + Trace level = iota + All level = iota +) +``` + +There is no ready Go off-shelf logging library which suited me and the logging code in DTail 3 was just one big source code file with global variables. For DTail 4, logging has been completely rewritten now (package "internal/io/dlog"). + +DTail also supports multiple log outputs (e.g. to file or to stdout). More are now easily pluggable with the new logging package. + +The log level now can be specified with the "-logLevel" command line argument. + ### Configurable terminal color codes -plus new default +One of the main complaints of previous releases were the terminal colors used. They made the output difficult to read, so that some users just disabled colors. + +I toke it by heart and also completely rewrote the color handling. The example "dtail.json" configuration file represents the default color codes used and it is now free to the user to customize them: + +``` +{ + "Client": { + "TermColorsEnable": true, + "TermColors": { + "Remote": { + "DelimiterAttr": "Dim", + "DelimiterBg": "Blue", + "DelimiterFg": "Cyan", + "RemoteAttr": "Dim", + "RemoteBg": "Blue", + "RemoteFg": "White", + "CountAttr": "Dim", + "CountBg": "Blue", + "CountFg": "White", + "HostnameAttr": "Bold", + "HostnameBg": "Blue", + "HostnameFg": "White", + "IDAttr": "Dim", + "IDBg": "Blue", + "IDFg": "White", + "StatsOkAttr": "None", + "StatsOkBg": "Green", + "StatsOkFg": "Black", + "StatsWarnAttr": "None", + "StatsWarnBg": "Red", + "StatsWarnFg": "White", + "TextAttr": "None", + "TextBg": "Black", + "TextFg": "White" + }, + "Client": { + "DelimiterAttr": "Dim", + "DelimiterBg": "Yellow", + "DelimiterFg": "Black", + "ClientAttr": "Dim", + "ClientBg": "Yellow", + "ClientFg": "Black", + "HostnameAttr": "Dim", + "HostnameBg": "Yellow", + "HostnameFg": "Black", + "TextAttr": "None", + "TextBg": "Black", + "TextFg": "White" + }, + "Server": { + "DelimiterAttr": "AttrDim", + "DelimiterBg": "BgCyan", + "DelimiterFg": "FgBlack", + "ServerAttr": "AttrDim", + "ServerBg": "BgCyan", + "ServerFg": "FgBlack", + "HostnameAttr": "AttrBold", + "HostnameBg": "BgCyan", + "HostnameFg": "FgBlack", + "TextAttr": "AttrNone", + "TextBg": "BgBlack", + "TextFg": "FgWhite" + }, + "Common": { + "SeverityErrorAttr": "AttrBold", + "SeverityErrorBg": "BgRed", + "SeverityErrorFg": "FgWhite", + "SeverityFatalAttr": "AttrBold", + "SeverityFatalBg": "BgMagenta", + "SeverityFatalFg": "FgWhite", + "SeverityWarnAttr": "AttrBold", + "SeverityWarnBg": "BgBlack", + "SeverityWarnFg": "FgWhite" + }, + "MaprTable": { + "DataAttr": "AttrNone", + "DataBg": "BgBlue", + "DataFg": "FgWhite", + "DelimiterAttr": "AttrDim", + "DelimiterBg": "BgBlue", + "DelimiterFg": "FgWhite", + "HeaderAttr": "AttrBold", + "HeaderBg": "BgBlue", + "HeaderFg": "FgWhite", + "HeaderDelimiterAttr": "AttrDim", + "HeaderDelimiterBg": "BgBlue", + "HeaderDelimiterFg": "FgWhite", + "HeaderSortKeyAttr": "AttrUnderline", + "HeaderGroupKeyAttr": "AttrReverse", + "RawQueryAttr": "AttrDim", + "RawQueryBg": "BgBlack", + "RawQueryFg": "FgCyan" + } + } + }, + ... +} +``` + +When you do so, make sure that you check your "dtail.json" against the JSON schema file. This is to ensure that you don't configure an invalid color accidentally (requires "jsonschema" to be installed on your computer): + +``` +jsonschema -i dtail.json schemas/dtail.schema.json +``` ### Improved documentation diff --git a/gemfeed/atom.xml b/gemfeed/atom.xml index 9090b506..a92c1833 100644 --- a/gemfeed/atom.xml +++ b/gemfeed/atom.xml @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="utf-8"?> <feed xmlns="http://www.w3.org/2005/Atom"> - <updated>2022-03-04T09:42:21+00:00</updated> + <updated>2022-03-06T10:28:37+00:00</updated> <title>foo.zone feed</title> <subtitle>To be in the .zone!</subtitle> <link href="gemini://foo.zone/gemfeed/atom.xml" rel="self" /> @@ -28,11 +28,44 @@ <a href="https://foo.zone/gemfeed/2022-03-05-the-release-of-dtail-4.0.0/dtail.gif"><img src="https://foo.zone/gemfeed/2022-03-05-the-release-of-dtail-4.0.0/dtail.gif" /></a><br /> <h2>What's new in 4.0.0?</h2> <h3>Integration testing suite</h3> -<p>DTail comes already with some unit tests, but what's new is a full integration testing suite which covers all common use cases. </p> +<p>DTail comes already with some unit tests, but what's new is a full integration testing suite which covers all common use cases of all the commands (dtail, dcat, dgrep, dmap) with a server backend and also in serverless mode.</p> +<p>How are the tests implemented? All integration tests are simply unit tests in the ./integrationtests folder. They must be explicitly activated with:</p> +<pre> +% export DTAIL_INTEGRATION_TEST_RUN_MODE=yes +</pre> +<p>Once done, just run:</p> +<pre> +% go clean -testcache +% go test -race -v ./integrationtests +</pre> <a href="https://foo.zone/gemfeed/2022-03-05-the-release-of-dtail-4.0.0/testing.gif"><img src="https://foo.zone/gemfeed/2022-03-05-the-release-of-dtail-4.0.0/testing.gif" /></a><br /> <h3>Improved code</h3> -<p>SonarQube/BlackDuck + refactorings to reduce code complexity.</p> +<p>Not that the code quality of DTail has been bad, but I had new tools (such as SonarQube and BlackDuck) available to:</p> +<ul> +<li>Reduce the complexity of a couple of functions (splitting code up into several smaller functions)</li> +<li>Avoid repeating code (this version of DTail doesn't use Go generics yet, though).</li> +</ul> +<p>Other than that, a lot of other code has been refactored as I saw fit.</p> <h3>Rewritten logging</h3> +<p>DTail is a special case when it comes to logging. There are logs processed by DTail, there are logs produced by the DTail server itself and there are logs procudes by one of the DTail clients themselves. Furthermore, there are different log levels too: </p> +<pre> +// Available log levels. +const ( + None level = iota + Fatal level = iota + Error level = iota + Warn level = iota + Info level = iota + Default level = iota + Verbose level = iota + Debug level = iota + Devel level = iota + Trace level = iota + All level = iota +) +</pre> +<p>There is no ready Go off-shelf logging library which suited me and the logging code in DTail 3 was just one big source code file with global variables. For DTail 4, logging has been completely rewritten now (package "internal/io/dlog"). </p> +<p>DTail also supports multiple log outputs (e.g. to file or to stdout). More are now easily pluggable with the new logging package.</p> <h3>Configurable terminal color codes</h3> <p>plus new default</p> <h3>Improved documentation</h3> |
