Ask HN: What are some tools / libraries you built yourself?

It was not originally open sourced; it was a commercial product for some time.

I wasn't satisfied with what already existed at the time (and neither were our customers) because most regular expression libraries are not focused on performance (using backtracking), streaming (again, backtracking) across multiple inputs - e.g. packets - without holding on to old data - and handling lots of regular expressions at scale.

re2 came along while we were still doing a commercial project but had zero impact on our sales, as it didn't handle streaming (weirdly, imo, as it could have) but it also didn't scale very well to large numbers of patterns.

I also designed simdjson (https://github.com/simdjson/simdjson), although others (chiefly Daniel Lemire and John Keiser) now do all the real work. It's still my design under the hood (although the "On Demand" stuff is significantly new and different). I built the first prototypes of simdjson because Daniel trolled me with a paper from Microsoft and I was bored.

[1]: https://github.com/kevin-hanselman/dud

[2]: https://dvc.org/

Makes any macOS .dylib or executable portable.

It (recursively) makes local copies of all the dynamic libraries on which you depend, and rewrites all load commands to prefer the local copy.

This lets you safely distribute your software to another computer (rather than discovering it only works on your computer because of your brew installs).

https://gist.github.com/Birch-san/e84cfa3b93ffa104af2bd9a047...

Explanation, diagrams: https://birchlabs.co.uk/blog/alex/juicysfplugin/synth/cpp/20...

> Other validation tools are either focused on:

> - binding to user input forms,

> - recreating or supplementing ActiveRecord validations, or

> - supplying user-friendly error messages instead of programmatic error codes

>

> This is a design gap I'm interested in filling, as it fits my mental model for many validation cases, and is especially suitable for APIs in a way other Ruby validation libraries are not.

>

>The aim, then, is for Validryad to be a validation library that supplies programmatically useful validation errors, while performing some minimal coercion and alteration of the data as useful.

>

> The library draws on the existing dry-validation library for design inspiration, while making some concretely different decisions:

>

> - Error messages are programmatic, not user-based

> - Validation is not tailored towards hashes alone, but suited for any combination of values, including hashes and arrays

It's extremely basic, but I'm using it for current work and it does the job I need it to do. It was a simple enough tool that I figured it might be useful to push as its own library. Looking at recent discussion, it probably better fits the 'parse, don't validate' mentality, under which case it's something of a misnomer.