Ask HN: What are you working on? (June 2026)

I'm working on my fun educational site that teaches about the central dogma: https://dnamyname.com

and I'm also working on a tool to allow runners to easily share their running gear kits with others https://grwm.run

This looks great. I've had a quick look through the docs and can't see anything about bikes under transport, or, under housing, anything relating to modes of tenure that aren't private rentals (e.g. Vienna-style social housing, housing co-operatives, or private ownership). Would be lovely to play around with those variables.

Also, for finance, is there a particular reason why the finance sector calculations look quite simple (on the face of it, at least)? They seem only to be a percentage lift based on aura, rather than anything resembling any number of complex sectoral dynamics, from full rentier-financial domination to prudent support of industry/services.

Two open-source things, mostly:

1. Kinetic Merge - it's a CLI tool for merging in Git repositories. What it gives over and above the core Git merge is the ability to merge through the motion of code from one location to another. Yes, Git can track file-renames and merge through them, but it doesn't follow code moving around inside a file, or a file being split into two or more pieces, or a new file accumulating code that used to live in several files. Essentially, the sort of thing you get with a lot of refactorings or automated code tidy-ups.

I've been at this since 2023; it was a long-standing itch I had to scratch since back in the early 2010s, finally got some time to work on it. Now in its 57th release, GitHub tells me!

It's written in Scala and packaged up as a standalone executable - needs a JVM >= 17 to run it on Linux / Windows / OSX.

(https://github.com/sageserpent-open/kineticMerge)

2. Americium - this is a mixed Java / Scala framework for folk who want to write property-based or generally parameterised tests, but: a) want the failing tests to shrink automatically without writing custom shrinkage logic and b) don't want to have the test structure and expectations DSL dictated to them by the framework.

Its job is to serve up test data into your flavour of Java or Scala test, look for an exception from the test and get shrinking. The rest is up to you.

There is a separately shipped artifact that plugs into JUnit5 / JUnit6 for a tighter integration, including test replay via IntelliJ or Visual Studio or whatnot, but that's an optional extra.

I've worked on this since 2020, now hitting its 52nd release. I use it for my other projects, and I know of a couple of corporate teams that use it because I evangelised it to them, but ironically, I'm only just getting round to using it for the problem that motivated me to write it in the first place.

(https://github.com/sageserpent-open/americium)

Google Docs for Markdown, real-time collaborative Markdown editor.

https://markdownsync.com

I started writing a software triangle rasterizer. Not sure exactly why, but I just felt like doing it.

Like many software rasterizer projects I used Fabian Giesen's software rasterizer blog series [0] as the baseline.

For solid color triangles with depth testing my 10+ year old laptop achieve ~3.2 Gpixels/s fill rate, which is above 80% of the available memory bandwidth (~26 GiB/s at 64 bits per pixel), using memset as the baseline comparison.

I used Rust and std::simd. The code can be compiled for SSE2, NEON, AVX2 or AVX512 by changing compiler parameters. The inner loop uses 16-wide vectors (512 bits) although my computer only has 8-wide AVX2, but the compiler deals with that. I used generics so I can change vector width easily and have multiple vector widths in the same binary for benchmarking. 16-wide is about 10-20% faster than 8-wide. I was excited to see that AVX masked store instructions get used even though I did not explicitly write masked stores in the code. I spent a lot of time reading the disassembly of the generated code and it's very tight.

The performance falls off a cliff (170 Mpixels/s) once I introduce a "shader" in the inner loop because it is not SIMD friendly (one pixel at a time, not 16 pixels). But that is fine, I am intending to use this with visibility buffer style rendering (store integer triangle id's in color buffer) and/or software occlusion culling (depth buffer only). Neither technique need anything more than solid colors and z-buffer.

[0] https://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlu...