cholindo

I made a parking simulator a long time ago. To make it realistic, you have to take into account that each wheel turns at a different angle. Both turning wheels need to turn at an angle that meets in the same point of a line that comes out of the back wheels. And, at low speed and acceleration, there is no drifting. To determine how the car moves, since all the wheels point to the same intersection point, just do angular movement of the car pivoting on that point, making angle * radious of the center of the drive wheels match the speed of the car. Wheel differential compensates for choosing the center of the wheels.

It looks great already, so I would say:

- A package manager. This will help the project grow and mature.

- I didn't find how to call JS functions and vice versa. Should I wrap js code into web components and do interop through props and events, or is there another approach?

I guess that you can do fingerprinting with any cached content, but the insane persistency of favicon's cache makes this much more concerning.

I wouldn't follow this approach because if you run `. .env;` you .env gets evaluated as a bash script, not as a configuration file. This means that you can get runtime errors in the .env file, and nobody wants that.

Sometimes waiting for the address is not enough. For example, you might want to wait for a specific API enpoint to return 200 OK, or you might want to wait for database migrations to get applied. Is `is_ready` aiming to cover those cases in the future?

`process-compose` is a "scheduler and orchestrator". `is_ready` only checks for services to be ready so it seems great when you want to start the services by other means and wait for them to be avialabe (for example, services started in another node of a cluster).

+1

A bit off topic, but this is why I started using KDE over gnome. I liked to use middle mouse button for drag-move/resize but in gnome it required editing the source code and recompiling.

good to know, thanks

> Time Zones often have a "friendly name" in the format Continent/City|Island

Continent/City are not friendly names, they are political boundaries that gice more precision. For example, CET covers many countries that might decide to stop applying DST at different points in time. If you store CET in your database you won't know if you need to apply CEST or not. This is why you always need the Continent/City form if you want to be future proof (and past proof)

k3s is a super easy way of deploying kubernetes in a linux machine.