gui-thunks VS spotless

It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation.

But the implementations are rarely extracted out for general purpose usage and rarely have a rich API.

I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a sequence of actions on arbitrary objects with an epoll style API.

One of my ideas is GUI thunking. The idea that every interaction with the GUI raises a new type that can be interacted with, to queue up behaviours on the GUI. This is essentially Future<> that are typed and the system reacts to the new type based on what you did.

It's a bit like terraform plan and apply, but applied to general purpose GUIs.

For example, you can click download file, then queue up installation and then using the application, ALL BEFORE it is installed. Because the actual computation is separate from the type information that was queued up.

Imagine using AWS Console to set up an entire infrastructure and wire everything together but not actually execute anything until the very end when you click "Run".

https://github.com/samsquire/gui-thunks

I spend everyday thinking of what my computer could be doing.

Most of the time the CPU is waiting for IO - memory, network, SSD, disk and not doing any work.

You might like my idea called GUI Thunking.

https://github.com/samsquire/gui-thunks

Spotless is an open-source, multi-language, customizable code formatter for projects. It comes with a Maven Plugin that can be customized as needed.

Some code formatters such as Spotless (https://github.com/diffplug/spotless/tree/main/plugin-gradle...) allow you to format code only in files that have changes against some designated branch such as `master`. So, you check out your feature branch, make changes, do some commits, and run spotless. Only the files which have some changes between your workspace and the master branch will be formatted. This allows you to gradually format the project as and when files would be changed anyways.

As a Top-Level Apache open source project, ShardingSphere has 400 contributors as of today. Since most developers do not have the same coding style, it is not easy to standardize the project’s overall code format in a GitHub open collaboration model. To solve this issue, ShardingSphere uses Spotless to unify code formatting.

But please just use an code formatter like spotless. Or better yet set it as a pre commit hook. You will thank yourself later, and so will all of your coworkers.

I use Spotless but it’s not as opiniotated as Prettier or Black

I use Spotless and it works quite well, but there are many other options. Also good IDEs can reformat your code.