Hacker News: kxc42

New comment by kxc42 in "Software Architecture Guide (2019)"

kxc42 — Sun, 14 Jun 2026 09:34:08 +0000

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

New comment by kxc42 in "The Notetaking Cold War (2020)"

kxc42 — Sat, 26 Aug 2023 01:41:48 +0000

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.

New comment by kxc42 in "We're wasting money by only supporting gzip for raw DNA files"

kxc42 — Mon, 09 Jan 2023 18:43:49 +0000

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.

New comment by kxc42 in "We're wasting money by only supporting gzip for raw DNA files"

kxc42 — Mon, 09 Jan 2023 18:29:42 +0000

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-...

New comment by kxc42 in "Goodbye, data science"

kxc42 — Tue, 29 Nov 2022 22:40:45 +0000

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...

New comment by kxc42 in "Why Domain Driven Design?"

kxc42 — Fri, 25 Nov 2022 11:39:29 +0000

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

New comment by kxc42 in "Why Lisp?"

kxc42 — Fri, 04 Nov 2022 17:42:02 +0000

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).

New comment by kxc42 in "Why Lisp?"

kxc42 — Fri, 04 Nov 2022 11:37:01 +0000

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/

New comment by kxc42 in "Sorry everybody, I failed with you"

kxc42 — Sat, 12 Jun 2021 10:07:56 +0000

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/

New comment by kxc42 in "Technical documentation that just works"

kxc42 — Thu, 27 May 2021 22:20:55 +0000

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/