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.

Also see PostGIS for Postgres systems: https://postgis.net/docs/.

https://openrailwaymap.app

OpenRailwayMap is a project focused on displaying everything railway related in the world, powered by OpenStreetMap data.

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.

Totally agree. And even the overhead of construction/destruction can be avoided in runtime for languages with inline types (e.g. https://kotlinlang.org/docs/inline-classes.html).

That is why I am happy that rich errors (https://xuanlocle.medium.com/kotlin-2-4-introduces-rich-erro...) are coming to Kotlin. This expresses the possible error states very well, while programming for the happy path and with some syntactic sugar for destucturing the errors.

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.

I built a fork of OpenrailwayMap (original at https://www.openrailwaymap.org, vector styles at https://openrailwaymap.fly.dev).

The style was built to match the look of the original raster tiles closely, although I added many more interactivity features in the vector variant.

Is is interesting from a style/tile design perspective that the performance tradeoffs choices become very different how and where the tiles are rendered. This is obvious, but it has effects on what is possible on the server / clients visually as well.

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.

How does it compare to the Java money API (https://jcp.org/en/jsr/detail?id=354) and the related Kotlin DSL in https://github.com/hiddewie/money-kotlin/?tab=readme-ov-file...?

Get you, your manager and the CEO in one room, and tell them the facts. Once those are on the table, discuss solutions. Otherwise nobody wins.

Yes, a grid system like H3 https://www.uber.com/en-NL/blog/h3/ is is closer to a circle in shape. One of the reasons for Uber to use H3 is bacause density maps look more natural in hexagonal shapes. It would be interesting to see the answer for H3 hexes.

The reason we can’t, and why `async`/`await` exist, is because of shortcomings (lack of support for stackful coroutines) in language runtimes

The JVM runtime has solved this problem neatly with virtual threads in my opinion. Run a web request in a virtual thread, and all blocking I/O is suddenly no longer blocking the OS thread, but yielding/suspending and giving and giving another virtual thread run time. And all that without language keywords that go viral through your program.

Why not? A branch is a pointer to a commit, so the commit built for staging can be the same binary that will be deployed to production, if the production branch is updated to point to the same commit as staging was pointing to. No rebuild necessary because it is the same commit.

The series Darkover from Marion Zimmer Bradley.

It's more science fiction than my normal pick of fantasy, but nice reads.

Never heard of this! I will definitely take a look if this can replace some handwritten bash curl-based test scripts to validate HTTP-level interactions. The combination of documentation and testing in a single text file looks promising.

We use Slite extensively at work. Works pretty well to quickly create/edit documents with a nice editor. When you type Markdown, the content automatically resolves the styling/headers/lists. Multiple persons editing a document at the same time is (of course) supported. And every document can be exported as Markdown or PDF.

Ruby syntax is the lightest there could be

Kotlin can have exactly the same code with lambdas, using either a receiver type, or a context receiver. And it's type safe.

    transaction {
      foo()
      bar()
    }

Train signals in the Netherlands also have red on the bottom. The reason is in case of snow falling on the light covers, the red light (most important signal, "stop") will never be blocked by snow.