hiddew

For large applications, having the implementation (or multiple implementations) of certain functionality decoupled from the code using it, improves maintainability and configurability of the application. That is where inversion of control helps. And then manually writing the instatiation, scoping, dependency ordering and cleanup code to manage all of that is not useful to write yourself. Any dependency injection framework will work, although Spring is well used and has many integrations.

> Autowiring is against the principles of a typesafe programming language

Constructor autowiring is the application of the inversion of control and dependency injection pattern. If there was no autowiring, you could autowire the components together just the same with normal code calling constructors in the correct order. Spring just finds the components and does the construction for you.

> How long before car ownership is replaced with autonomous vehicle car pools?

That is very much a future I look forward to living in. Not requiring to own a car but sharing it efficiently with folks in the neighborhood, would save quite some parking space for unused vehicles in front of homes, and centralize maintenance to the companies operating the vehicle fleet.

> For stuff like security keys you should typically add them as build args, not as content in the image.

Do not use build arguments for anything secret. The values are committed into the image layers.

Hurl is underappreciated for writing nice and maintainable HTTP-level test suites. Thanks for the tool!

"fixed it with an algorithmic change, reducing backup times exponentially"

If the backup times were O(n^2), are they now O(n^2 / 2^n)? I would guess not.

I think for "untyped" files with records, using the ASCII file, (group) and record separators (hex 1C, 1D and 1E) work nicely. The only constraint is that the content cannot contain these characters, but I found that that is generally no problem in practice. Also the file is less human readable with a simple text editor.

For other use cases I would use newline separated JSON. Is has most of the benefits as written in the article, except the uncompressed file size.

You can use GC defaults, but tuning can provide valuable throughput or latency improvements for the application if you tune the GC parameters according to the workload. Especially latency sensitive applications may benefit from generational ZGC in modern JVMs.

> there would no clean way to edit/remove/reorder downstream commits

Yes, but I consider commits immutable so reordering or editing commits is not a thing that would happen. New commits are appended (either upstream or downstream), and any conflicting changes then of course have to be merged from upstream into downstream.

The post considers rebasing the fork. It seems easier to do only merges. You can merge specific upstream commits, or the entire upstream branch. That way you only need to merge in the changes, and not resolve the same conflicts for each downstream commit, every time the upstream is changed.