kxc42

For python projects I created pytest-archon[1], initially for humans, but now I'm using it for agents, too.

[1]: https://github.com/jwbargsten/pytest-archon

I just don't get the need to figure out a system that represents the true way of taking notes. Everybody is different: different in skills, needs and working styles. Some want a diary, others a 2nd brain. It doesn't matter which system you pick, the result will be: it fits somewhere between 50% and 90%.

To take clothes as analogy: when you buy a shirt off-the-shelf, you can (usually) choose between XXS to XXL. Let's assume you want to wear the shirt for the rest of your life, wouldn't the natural conclusion be: a tailor-made shirt?

The real solution is to take one note taking system as starting point and adapt it to your needs. There is no shortcut, it will take a while till you've figured out what your needs are and how you can adapt the system you chose.

That can be a challenge, but you can also build an "artificial" reference genome. You just use it for compression, not for any real analyses. This would allow you to still use alignment-based compression.

But I agree with you: it really depends on the type of the data.

I'm not sure why gzip still pops up for FASTQ data, as it is quite easy to bin the quality scores, align it against a reference genome and compress it as e.g. CRAM [1,2].

With 8 bins, the variant calling accuraccy seems to be preserved, while drastically reducing the file size.

[1]: https://en.wikipedia.org/wiki/CRAM_%28file_format%29

[2]: https://lh3.github.io/2020/05/25/format-quality-binning-and-...

That answer somehow reminds me of an article in logicmag: An Interview with an Anonymous Data Scientist [1].

[1]: https://logicmag.io/intelligence/interview-with-an-anonymous...

Funny coincidence: just one week ago I and a colleague of mine started with "pytest-arch" [1], a pytest plugin to test for architectural constraints. On purpose we kept it very simple. It is already usable and works well, at least for our use cases.

You can use it to check e.g. if your domain model is importing stuff that it should not import.

We are planning to publish it soon on pypi.

[1]: https://github.com/jwbargsten/pytest-arch

Difficult to say, as I did not measure anything. From the code I've written I get the "feeling" that it is more compact compared to plain lua, reducing (my) cognitive load.

Fennel transpiles to lua, it doesn't give more capabilities, I would say. The concept of productivity (and capability) is anyway confounded by so many factors, making the choice of programming language negligible (unless you pick one of the extremes, such as Brainfuck, of course).

In terms of practical application, I saw (e.g. leap[1]) and enjoyed using fennel[2] for writing neovim plugins.

[1]: https://github.com/ggandor/leap.nvim [2]: https://fennel-lang.org/

I was surprised that nobody mentioned the Collective Code Construction Contract of zeromq/Pieter Hintjens [1]. It tries to minimise the friction created by maintaining & contributing to open source projects.

It is not perfect of course, but at least it is a good start. Especially the "value-" & opinion-based discussions can be reduced considerably.

[1]: https://rfc.zeromq.org/spec/42/

Basically you have three approaches to tackle code samples in markdown files:

1. run the code with some kind of plugin as part of your doc pipeline

2. generate documentation from your code

3. take some kind of hybrid approach

I went for 3., annotate snippet "areas" in the source code of a project (mainly in tests) and extract the snippets to a folder, e.g. into the mkdocs folder. I commit them to the (docs) repo. If the project changes, usually I fix the tests and update the snippets in mkdocs. This way I can be sure that the code in the documentation is actually working and people can copy&paste it. To scratch my own itch, I (surprise, surprise) created a script and even packaged it[1].

[1]: https://pypi.org/project/snex/