Wan-Derer

Тут говорят, что можно включить hot reload для Thymeleaf. Это позволит автоматически обновлять страницу при изменении шаблона без необходимости перезапуска сервера. Для этого нужно добавить следующие строки в файл application.properties:

spring.thymeleaf.cache=false
spring.thymeleaf.enabled=true

После этого, при изменении шаблона, он должен автоматически перезагружаться и отображаться на странице.

Если прямая видимость - без проблем можно до 500 Мбит до 11 км вытянуть используя диапазон 5 ГГц и спецоборудование, например Микротик. Всё утыкается в бюджет
Вопрос другой - а зачем?
Что мешает на роутере правильно QoS настроить? Тогда ничего лагать не будет - роутер сам будет приоритеты трафика разруливать
На компе, что торренты качает - с самом торренте ограничение на 50 Мбит поставь - хватит выше крыши
По секрету скажу, FullHD трансляция - это около 5 Мбит
4K При частоте 24 – 30 кадров в секунду – порядка 35 – 45 Мб/с.
4K При частоте 40 – 60 кадров, битрейт составляет 58 – 65 Мб/с.
У меня на работе полсотни человек сидит на 100Мбитном канале. Если верить Zabbix - средняя нагрузка Интернет канала - 22 Мбит в рабочее время с редкими скачками

Не претендую на правду. Просто несколько мыслей.

В чем минусы событийно ориентированного подхода?
Насколько я понимаю, Алан Кей (тот кто придумал термин Объекто-ориентированный) старался придерживаться именно этого подхода. т.е. кто-то отправляет сообщение, а объекты в системе на него реагируют, каждый по-своему.
По сути у нас есть message bus, в который добавляется сообщение, а объекты системы слушают этот самый message bus.

Мысль первая. Наследие.

Когда мы говорим о наследии Алана Кея - надо просто глянуть что он создал практически.
А создал он язык Smalltalk. Поэтому логично изучать минусы событийного подхода на
примере софта который написан с использованием Smalltalk. Кто из коллег в топике
знает примеры такого софта? Я - к сожалению не знаю.

По ссылкам википедии https://en.wikipedia.org/wiki/Smalltalk можно видеть в категории
influenced мы просто видим что Smalltalk
влиял на Java, Go, Swift. Но я здесь не согласен потому что мы не можем измерить глубину
этого влияния. Это все равно что сказать что Сталин влиял на Черчилля. Как влиял? На 10%?
Или более чем половину? Сложно. Насчет Java я тут сказал-бы что сомнительно. ООП? Может быть.
Акторы? Нет. В Java изначально нет акторов. Они существуют позже в виде фреймворков но
языком не поддерживаются.

По поводу MessageBus. Если брать технологию акторов которая используется в Erlang.
то там скорее не message bus а очереди сообщений между потоками-акторами.
Если про Smalltalk сказать нечего то про Erlang я могу сказать что на нем написаны
две единицы софта такие как RabbitMq (очень надежная и неубиваемая система MQ).
Может не супер-производительная. И CouchDb которая выделяется своей
устойчивостью ко всяким сетевым сбоям. Реклама говорит что Кауч работает
практически при мигающей сети, при обрывах и т.п. лучше чем аналогичый TCP-IP совт.

Мысль вторая. Что Кей говорил про ООП.

У меня есть цитатник. Я туда собираю некоторые слова на лытни. И иногда слова Кнута, Дейкстры
и прочих it-академиков. Вот из цитатника Кея:

I made up the term "object-oriented," and I can tell you
I did not have C++ in mind.

Что в этой прямой речи можно понять. Что господин Кей открещивается от современного ООП.
А фактически все современное ООП зеркалит то что есть в С++. Здесь вы можете со мной спорить
о первенстве (я не буду спорить я не знаю). Но абсолютно очевиден факт что мир пошел по пути
жесткой синхронщины в 80х. И пока все еще идет. Будут ли примитивные типы int/double обьектами
не суть важно. Тут важно что Кей постулирует среду в которой двигаются сообщения. Как сеть в миниатюре.
А классическое ООП С++ - лишает нас этой среды и заменяет ее вызовом метода. Никакого сообщения
в С++ нет и быть не может потому что сообщение НЕ существует в отрыве от основного потока который
инициировал вычисления. Умрет поток - развалится весь стек и параметры и все. В противоположность
в языке Erlang поток (процесс) приёмник может дохнуть много раз но стек сохраняет свою живучесть
просто повторяя вычисления заново. И здесь мне кажется и идет развилка путей.

И здесь как-раз мы может говорить о недостатках. Очевидно что у нас появляется лаг приемки-передачи
сообщения. У нас появляются мягкие гарантии времени обработки. И многое другое.

Интересно почему в 80х Алан Кей проигрывал. Я думаю что победил прагматизм. В те далекие 80-е
комьютеры были еще слабыми. Частота мерялась сотнями килогерц и мегагерцами. И в расчетах
каждый такт был важен. И красивые и академические языки такие как Lisp, Prolog, Smalltalk
просто проигрывали языку С в силу оверинжинеринга. А поскольку С++ был вначале действительно
ООП-надстройкой над С - то он предлагал и ООП-подход и скорость портабельного ассемблера.
И хотя я лично не люблю С++ (я считаю его перегруженным техническими долгами прошлого)
я признаю что бизнес выбирая С++ выбирал просто скорость вычислений. Академизм и красивые
доказательства правоты программ были тогда не нужны. Нужно чтоб банковское приложение
быстро считало кредиты и выдавало зарплаты и пенсии.

Сегодня, когда мы нежемся в сладкой неге мощных процессоров и даже (!) облаков - мы можем
себе позволить любого уровня парадигмы и абстракции. Цена 1 абстракции стала настолько дешево
стоить что нам дешевле в банках запускать Java/Net приложения и на ходу фиксить ошибки
чем долго разрабатывать на С++ и иметь неопредленнное поведение и тяжелый анализ
в случае падения. Даже такой уродец как Python взлетел как язык интеграции а не разработки.

Мысль третья. Нестандартные и асинхронные архитектуры реализованные в железе.

Недавно смотрел анонс нового процессора от Чака Мура (это тот самый Мур который создал закон имени себя).
Мне кажется это пример той самой асинхронной клетки о которой мечтал Алан Кей.

Мысль четвертая. На кого похож Алан Кей?

Не знаю как вам. :) А мне он уж очень напоминает Боливара Траска из Люди Икс Дни Минувшего будущего.

Мысль 5. Что делает Алан Кей на фото?

Бренчит на музыкальных инструментах. Наверное блюз. Блюз потерянных архитектур :)

Нагрузочным тестированием.

Для примера, предположим, что есть (сферический в вакууме) CRUD сервис ... Предположим, что точная оценка не требуется. Даже погрешность в несколько раз будет приемлемой.

Сервисов в вакууме не бывает, разный код и внешние зависимости будут влиять по-разному на использование ресурсов с разбегом в несколько порядков.

Например, для оценки latency существуют подобные таблицы

Путаете физику с лирикой. В приведённой вами таблице значения вырастают из физических и технических ограничений.

Не знаю откуда вы сформировали такой отчет.

С точки зрения современной ОС вы можете хранить много конфигураций JDK/JRE и перключаться между ними просто изменяя PATH/CLASSPATH. Это работает для Linux в основном. Для Windows мне это не удавалось. По крайней мере был еще один способ конфигурирования путей доступа к библиотекам который я на тот момент не знал. Возможно через реестр.

Чтобы удалить ненужный - нужно знать какие вам нужны. Я-бы оставил только 17 поскольку она LTS (Long Term Support) а все остальные бы удалил если нет других требований.

Из оставшихся двух версия corretto - разрабатывается и поставляется амазоном на его виртуалки. Поэтому если хостинг покупаете в амазоне то имеет смыл и ее использовать. Но я не вижу JDK это или JRE. Для процесса разработки софта (компилляции) нужна только JDK.

Вообще не должны мешать. Но и держать без необходимости кучу версий не стоит.
Джава живет себе спокойно в одной папке, а все, что в системе о ней известно - путь в path и переменная JAVA_HOME.

На маке лучший способ управлять Java SDK - использовать https://sdkman.io/

Зачем так много?

то есть по вашему лучше когда в проекте велосипеды, так еще они и постоянно повторяются, потому что названия разные и один разраб просто не знал что уже другой сделал простой метод в проекте. Плюс частенько реализация лучше и продуманее своей, нормальный человек не будет тратить много времени на велосипед. Требуется решать задачи бизнеса, а не думать как обрезать строку после определенного символа.
ИМХО в котлине эти методы скорее наделаны скорее показать преимущество котлина с их эксеншенами, в джаве с этим сложнее было.

Ну... сжатая картинка сохраняет стационоарными некоторые свойства. Например палитра. Цветовые кривые.
Если не сильно сжимать то и некоторые частотыне свойства сохраняются. Вот. Персептуальный хеш.
Это такое 8х8 черно белая матрица. Тоже идентичная для оригинала и для скейлинга. На habr.com была
хорошая статья про эти виды хешей.

Но честно я-бы такое вообще не делал. Больше
холивара чем практической пользы.

Чистая архитектура это не серебряная пуля, в чем профит то? Какие ваши проблемы она решит? Выглядит так, что вы устали работать с легаси говнищем и хотете на текущее место работы привнести новые технологии. Если это так, то это не работает. Поверьте, я проверял. Лучше смените проект.
Ради опыта напишите полезный пет проект, или опять же - смените место работы. Загнивание на работе с технологиями которые вам не нравятся это путь в выгорание. Опять же поверьте, я проверял.

Нет, оно того не стоит. Любая работа должна быть оплачена. Ибо сейчас напишешь за свой счет, а потом начальника скажет "о, отлично, молодец, можем теперь сэкономить на программистах и поддержке, у меня как раз знакомый ищет, ща его поставлю, а ты можешь быть свободен, заодно выпишу себе премию, во какой я молодец". Этот код решает задачи бизнеса. Если бизнес готов тратить на его поддержку и сопровождение деньги - то это проблемы этого бизнеса. Почему это наемный работник должен решать проблемы бизнеса за свой счет? Правильно сделать так: оформить все в виде какого-то документа с конкретными аргументами, цифрами, графиками и т.п. и выдать его начальству. Типа сейчас поддержка проекта стоит столько-то, приносит такие-то проблемы, переписать будет стоить столько-то, сопровождение нового будет столько-то, оно решает такие-то проблемы. И выдаете данный документ начальству. Можно даже в бумажном виде в нескольких экземплярах. А далее пусть у начальства голова болит.

Видимо, ваш long int - всего 32-битный. Понятно, что для 13! = 6.2е9 происходит переполнение. Попробуйте unsigned long long int