-
-
semgrep
Lightweight static analysis for many languages. Find bug variants with patterns that look like source code.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Anki-Android
AnkiDroid: Anki flashcards on Android. Your secret trick to achieve superhuman information retention.
-
-
Tests are a good way to assert an invariant that you expect of your codebase, but as with all things, resolving the error can get a bit tricky/frustrating.
The canonical example in my mind is any kind of autofix-able linter, where there's some kind of patch (or more nuanced autofix) that the linter can generate on-the-spot for you. With a sh_test construct (or any other unit test), you generally find yourself printing out some command that the user can run to fix things, which in a sufficiently large codebase can get really frustrating.
(My company - https://trunk.io - is actually building a universal linter as part of our product offering, and we already have a system to write custom linters with varying levels of sophistication that can plug into both your IDE and CI system.)
The semgrep[1] tool seems like the logical next step, for when you've outgrown plain ol' grep.
[1] https://semgrep.dev/
Android's default linting already contains a "missing translation" lint rule which you can activate: "MissingTranslation"[0]
For Android specifically: Gradle and Android Studio both support a powerful linting framework (to the level that it can provide auto-fixes to the IDE). It's better to provide an in-editor to guide your contributors before it hits CI, (but obviously also run lint in CI as a backup):
Some examples of custom lint rules[1] and the default rules which Android Studio runs[2]:
[0] https://android.googlesource.com/platform/tools/base/+/32923...
[1] https://github.com/ankidroid/Anki-Android/tree/develop/lint-...
[2] https://github.com/ankidroid/Anki-Android/blob/master/lint-r...
In today's world of excellent CLI tools I don't think grep is a good choice, especially for checking irregular languages like XML. [0]
I use tools like `jq` [1] or `yq` [2] all the time for CI checks. One useful check, is we have a configuration file stored as several hundred lines of YAML. Its a nice thing to maintain a sorted order for that, so we have a git pre-commit hook that runs the following:
> yq eval --inplace '.my_key|= sort' my_file.yaml
Of course, a pre-commit hook or CI both work. There's pros and cons of both. For our team, the pre-commit hook is a low enough level of effort, and doesn't require a CI check for something that executes in milliseconds.
[0] https://stackoverflow.com/a/1732454
[1] https://github.com/stedolan/jq
[2] https://github.com/mikefarah/yq
In today's world of excellent CLI tools I don't think grep is a good choice, especially for checking irregular languages like XML. [0]
I use tools like `jq` [1] or `yq` [2] all the time for CI checks. One useful check, is we have a configuration file stored as several hundred lines of YAML. Its a nice thing to maintain a sorted order for that, so we have a git pre-commit hook that runs the following:
> yq eval --inplace '.my_key|= sort' my_file.yaml
Of course, a pre-commit hook or CI both work. There's pros and cons of both. For our team, the pre-commit hook is a low enough level of effort, and doesn't require a CI check for something that executes in milliseconds.
[0] https://stackoverflow.com/a/1732454
[1] https://github.com/stedolan/jq
[2] https://github.com/mikefarah/yq
