в какой-то момент осознали, что не замечать сколько инцидентов у нас возникает из-за Hazelcast, дальше невозможно
Какие инцеденты-то? Вся статья выглядит, как воспевание редиски со ссылками на сторонние ресурсы, которые тоже что-то там себе отранжировали воспользовавшись личной линейкой. Мне, как читателю, хотелось бы хотя бы в общих чертах понять от чего именно вы бежали, какие задачи решали, и почему этого не получилось сделать на хазеле, а вместо этого я читаю какой редис прекрасный и замечательный.
На небольших коллекциях такое распараллеливание только замедляет процесс. В докладах Шипилёва звучала цифра в 10_000 элементов коллекции — после нее распараллеливание стрима может дать положительный эффект. А может и не дать, надо бенчить.
я не могу вспомнить ни одной компании, в которой бюджет был бы неограничен в принципе
А где тут хоть слово про "неограниченный в принципе бюджет"? Речь про несопоставимость бюджетов на удержание, и бюджетов на найм. А если эти бюджеты не сопоставимы, значит стоимость сотрудника внутри компании будет повышаться медленнее, чем если он зайдет "снаружи", и об эту нехитрую истину жизни ломаются все ваши показатели вовлеченности и прочие игрушечные метрики.
Вовлеченность, лояльность, проценты, бла-бла-бла… А повышение зарплаты на действительно ощутимую величину только через смену работы — потому что бюджет на найм есть, а бюджета на удержание нет.
От фреймворка зависит, что он будет делать с потоком, в котором произошел блокирующий вызов — современные фреймворки способны понять, что поток простаивает, и отдать его под соседнюю задачу. Вот-вот зарелизится Project Loom, который это все завозит в джаву из коробки, а в котлине примерно тоже самое делают корутины.
И вы по-прежнему просто прочитали строчку с диска. Вы не валидировали ее, вы не привели ее к нужному виду, вы не доставили ее до места применения, вы не научились ее обновлять на лету, вы ее даже не объединили в группу с другими свойствами того же вида. Вы просто прочитали строчку с диска, да еще завязавшись на конкретный файл свойств.
Ваш вариант просто загрузил свойство. Спринг со всеми его наворотами позволяет валидировать, возвращать дефолты, если свойство не найдено, и еще много чего, вплоть до измененя свойства в рантайме, при чем по сети. Эти "невероятно сложные" (нет) возможности стоят того, что бы их освоить, как мне кажется.
Кажется тут смешали воедино две проблемы — исполнение периодических заданий, и сохранение стэйта заданий в распределенной среде. Первая часть замечательно решается средствами Спринга, вторая решается в полном отрыве от первой части, и диапазон возможных решений тут от использования всяких БД, включая Redis, и до IMDG, например Hazelcast. Последний позволит держать распределенный стейт вообще парой строчек.
Впрочем, похоже, современному программисту очень тяжело понять эту идею даже с примерами эквивалентного, но читабельного синтаксиса под носом — нет времени думать, надо менять код, если условия изменились.
Ну, да, дело, конечно, в современных программистах, хотя мысль о том, что если при решении проблемы воспользовался регулярками, то у тебя теперь две проблемы, возникла уж точно не сегодня, и даже не вчера, и возникла у тех самых не современных программистов, на знаниях которых и выросли современные.
Особенно хорошо специальный код обновлять, когда оказывается, что формат данных надо немного поменять.
Вообще-то это работа программиста — писать код, и менять его, если условия изменились. И менять структурированный и документированный код, который написан специально, что бы хорошо делать конкретную работу гораздо проще и приятнее, чем универсальное заклинание на регэкспах.
Я не настоящий сварщик, но у кафки есть механизм квот, Kafka Quotas, или как-то так. Квоты позволяют контролировать несколько ресурсов, и, если склероз не изменяет, то запросы чтения и записи среди них.
Комментарии то работают, то нет — в зависимости от отображения? Да, зрелый продукт, что и говорить.
Какие инцеденты-то? Вся статья выглядит, как воспевание редиски со ссылками на сторонние ресурсы, которые тоже что-то там себе отранжировали воспользовавшись личной линейкой. Мне, как читателю, хотелось бы хотя бы в общих чертах понять от чего именно вы бежали, какие задачи решали, и почему этого не получилось сделать на хазеле, а вместо этого я читаю какой редис прекрасный и замечательный.
Круто, конечно, но не актуально — JB решили, что наши деньги для них не достаточно хороши, и продавать все это великолепие нам отказывается. А жаль =(
На небольших коллекциях такое распараллеливание только замедляет процесс. В докладах Шипилёва звучала цифра в 10_000 элементов коллекции — после нее распараллеливание стрима может дать положительный эффект. А может и не дать, надо бенчить.
А где тут хоть слово про "неограниченный в принципе бюджет"? Речь про несопоставимость бюджетов на удержание, и бюджетов на найм. А если эти бюджеты не сопоставимы, значит стоимость сотрудника внутри компании будет повышаться медленнее, чем если он зайдет "снаружи", и об эту нехитрую истину жизни ломаются все ваши показатели вовлеченности и прочие игрушечные метрики.
Вовлеченность, лояльность, проценты, бла-бла-бла… А повышение зарплаты на действительно ощутимую величину только через смену работы — потому что бюджет на найм есть, а бюджета на удержание нет.
От фреймворка зависит, что он будет делать с потоком, в котором произошел блокирующий вызов — современные фреймворки способны понять, что поток простаивает, и отдать его под соседнюю задачу. Вот-вот зарелизится Project Loom, который это все завозит в джаву из коробки, а в котлине примерно тоже самое делают корутины.
Прекратите уже домонстрировать невежество, даже неловко становится. К тому же
по строчкам короче.
И вы по-прежнему просто прочитали строчку с диска. Вы не валидировали ее, вы не привели ее к нужному виду, вы не доставили ее до места применения, вы не научились ее обновлять на лету, вы ее даже не объединили в группу с другими свойствами того же вида. Вы просто прочитали строчку с диска, да еще завязавшись на конкретный файл свойств.
Ваш вариант просто загрузил свойство. Спринг со всеми его наворотами позволяет валидировать, возвращать дефолты, если свойство не найдено, и еще много чего, вплоть до измененя свойства в рантайме, при чем по сети. Эти "невероятно сложные" (нет) возможности стоят того, что бы их освоить, как мне кажется.
Это еще что! Вот "спурт" вместо общепринятого "спринта" — вот где мякотка-то!
Не получится, если хотим api-first подход.
Более того, в java уже можно потрогать project loom, и с ним код сильно упростится и распрямится.
Кажется тут смешали воедино две проблемы — исполнение периодических заданий, и сохранение стэйта заданий в распределенной среде. Первая часть замечательно решается средствами Спринга, вторая решается в полном отрыве от первой части, и диапазон возможных решений тут от использования всяких БД, включая Redis, и до IMDG, например Hazelcast. Последний позволит держать распределенный стейт вообще парой строчек.
Ого, сколько снобизма.
Ну, да, дело, конечно, в современных программистах, хотя мысль о том, что если при решении проблемы воспользовался регулярками, то у тебя теперь две проблемы, возникла уж точно не сегодня, и даже не вчера, и возникла у тех самых не современных программистов, на знаниях которых и выросли современные.
Вообще-то это работа программиста — писать код, и менять его, если условия изменились. И менять структурированный и документированный код, который написан специально, что бы хорошо делать конкретную работу гораздо проще и приятнее, чем универсальное заклинание на регэкспах.
Я не настоящий сварщик, но у кафки есть механизм квот, Kafka Quotas, или как-то так. Квоты позволяют контролировать несколько ресурсов, и, если склероз не изменяет, то запросы чтения и записи среди них.
Очередная статья пересказывающая 5-6 первых страниц примерно любой книги по Kafka. Да еще и с ошибками.
Еще virtual threads в 21 версии зафиналят вроде как.
.