А потом не забывать дергать flush между вызовами hibernate и нативом, потому что первый сам решает, когда отправить в бд запрос, а вы на эти изменения уже рассчитываете в той же транзакции. Получаются неприятные костыли.
Если вы заняты важным для бизнеса делом, то никакие "обязательные" созвоны вам не страшны. Фича приносит большие деньги, у Вас есть репутация в конторе, можно игнорировать почти любые звонки. Пара сообщений в мессенжере, почему не придете, ставите коллег перед фактом. В адекватном коллективе никто и слова не скажет. Все всё поймут. Если вы реально нужны для какого-то обсуждения, то далеко не всем, можно грамотно переиграть календарь. Эти созвоны формальность как для продукт оунеров, так и для подконтрольных сотрудников. Лишь бы цели держали.
В остальных случаях товарищ выше хорошо написал про кардио, жаль в воде не работает )
Знакомая проблема. Особенно в крупных компаниях с тысячами микросервисов. Архитекторы тоже люди и за ADR нужно следить, это нужно читать, реализовывать. Попробуй на сотни-тысячи разрабов промасштабируй. Появляются дополнительные роли у сотрудников, появляются обязанности по трекингу, это болото всех душит. Пройдись по проектам, зайди в вики, зайди в 10 чатов, создай пару сотен задач, боль...
В одной из таких компаний на выслеживание и трекинг техдолга уходило такое неприличное количество времени, что в один момент запилил свой продукт на базе техрадара для автоматического контроля большого пласта техдолга. Хорошо, когда рутину на себя берет робот, а ты дальше делаешь свое дело. Это как CI, только с другого ракурса.
Есть и исключения. Когда кто-то пришел на платку, иделально закрыл пару семестров, перевелся на бесплатку, после чего с успехом дошел до конца.
К чему это я.
В пареллельной вселенной можно было бы сделать некий гибрид между платным-бесплатным образованием.
Достойно работаешь в вузе - учись бесплатно Недотягиваешь - доплачивай Явно косячишь - гони бабки
А не вот это вот всё.
В свое время особенно на платных целивиков интересно было смотреть. Это прямо как платник в кубе, с которым никто и ничего не может сделать без последствий для кафедры.
2) Недавно вышел Tomcat с поддержкой виртуальных потоков. Пробовали ли вы использовать его для ускорения обработки?
В 2025 году именно про это и интересно людям знать. Команды на низком старте ждут миграции с реактора на Virtual Threads, а хабр на reactor переезжает)
Зачем было столько времени уделять описанию явно устаревшего и забаганного инструмента? Попробуйте начать чтение и уронить брокер)
Предложенные серверные админки - не альтернативы, а а must have в каждой компании, если не рассматривать платный conductor или консоль от redpanda. Вот про них у нужно было писать в статье. Про разницу в настройки прав для юзеров, acl для кафки, про плюсы/минусы серфинга топиков. А как отработает просмотр, если закинуть в топик сообщение мегабайт на 10 (кейс 1 на миллион, но и такое бывает). Можно было много всего написать.
После таких статей появляются айтишники, которые впервые слышат о том, что кроме curl (хорошо, если и про него знают) бывает еще что-то. Автор мог бы хотя бы из уважения к индустрии про такое legacy не писать, либо поругать и не советовать пользоваться.
Чрезмерная приверженность регламентам и правилам рождается, как правило, в результате чей-то чрезмерной приверженности их нарушать.
На производстве (it в своем роде и есть производство) важен прагматизм, это не сфера обслуживания. Чем быстрее тебе укажут на ошибку, тем эффективнее пойдут процессы. И пусть хоть как это доносят, лишь бы сработало. Прямые личные оскорбления, конечно, не в счет, а с остальным можно жить.
1. Как минимум, здесь отсутствует типобезопасность.
2. Замечание не на тему того, кто чей клон, а откуда этот файл берется. Его генерирует определенный annotation processor. Кому нужно делать rebuild проекта ради какой-то подсветки? Вся эта каша нужна в библиотеках и стартерах. Или в 2018 кто-то еще зашивает конфиги в поставку?
3. Это нужно не для инжекта бизнес логики в конфиг! А для создания сложных библиотечных конфигураций, завязанных на стандартных интерфейсах из jsl или кастомной абстракции. В примере из статьи присутствует явное нарушение single responsibility principle. ConfigurationProperties нужно использовать либо в автоконфигурации, либо в сервисе, которому эти конфиги нужны (второе решение — так себе). Код из примера можно понять таким образом (а ведь он именно и написан в таком стиле), что надо все бины прятать в конфиги и через конфиги получать к бинам доступ. А потом кто-то жалуется на невозможность зарезолвить циклические зависимости и тратит по неделе на фикс простейшего бага.
2. Еще не хватает объяснения, откуда появляется файл additional-spring-configuration-metadata.json и как он связан с spring-boot-configuration-processor.
3. Статьи на хабре читает много новичков; и инжект сервисов в properties, вы шутите?
И какой смысл использовать всю эту кашу с метаданными вне стартеров?
QueryDsl в spring-data-jpa имеет статус deprecated.
Репа для интеграции со spring не обновлялась уже полтора года.
Выходит, что использовать можно только на свой страх и риск, и вероятно через костыли.
API у него неплох, но и со спецификациями жить тоже можно, хотя бы поддержка есть.
Content-type указывать необязательно, достаточно передать какой-нибудь отличный от базовых типов объект, например ...body(fromObject(myDto)). По факту на выходе автоматом получится json. А вот берет ли на себя webflux корректную расстановку хидеров; это нужно проверить.
А потом не забывать дергать flush между вызовами hibernate и нативом, потому что первый сам решает, когда отправить в бд запрос, а вы на эти изменения уже рассчитываете в той же транзакции. Получаются неприятные костыли.
Если вы заняты важным для бизнеса делом, то никакие "обязательные" созвоны вам не страшны. Фича приносит большие деньги, у Вас есть репутация в конторе, можно игнорировать почти любые звонки. Пара сообщений в мессенжере, почему не придете, ставите коллег перед фактом. В адекватном коллективе никто и слова не скажет. Все всё поймут. Если вы реально нужны для какого-то обсуждения, то далеко не всем, можно грамотно переиграть календарь. Эти созвоны формальность как для продукт оунеров, так и для подконтрольных сотрудников. Лишь бы цели держали.
В остальных случаях товарищ выше хорошо написал про кардио, жаль в воде не работает )
Заказ принят
Знакомая проблема. Особенно в крупных компаниях с тысячами микросервисов. Архитекторы тоже люди и за ADR нужно следить, это нужно читать, реализовывать. Попробуй на сотни-тысячи разрабов промасштабируй. Появляются дополнительные роли у сотрудников, появляются обязанности по трекингу, это болото всех душит. Пройдись по проектам, зайди в вики, зайди в 10 чатов, создай пару сотен задач, боль...
В одной из таких компаний на выслеживание и трекинг техдолга уходило такое неприличное количество времени, что в один момент запилил свой продукт на базе техрадара для автоматического контроля большого пласта техдолга. Хорошо, когда рутину на себя берет робот, а ты дальше делаешь свое дело. Это как CI, только с другого ракурса.
Есть и исключения. Когда кто-то пришел на платку, иделально закрыл пару семестров, перевелся на бесплатку, после чего с успехом дошел до конца.
К чему это я.
В пареллельной вселенной можно было бы сделать некий гибрид между платным-бесплатным образованием.
Достойно работаешь в вузе - учись бесплатно
Недотягиваешь - доплачивай
Явно косячишь - гони бабки
А не вот это вот всё.
В свое время особенно на платных целивиков интересно было смотреть. Это прямо как платник в кубе, с которым никто и ничего не может сделать без последствий для кафедры.
Платные места подорожают, ясно-понятно.
В 2025 году именно про это и интересно людям знать. Команды на низком старте ждут миграции с реактора на Virtual Threads, а хабр на reactor переезжает)
Зачем было столько времени уделять описанию явно устаревшего и забаганного инструмента? Попробуйте начать чтение и уронить брокер)
Предложенные серверные админки - не альтернативы, а а must have в каждой компании, если не рассматривать платный conductor или консоль от redpanda. Вот про них у нужно было писать в статье. Про разницу в настройки прав для юзеров, acl для кафки, про плюсы/минусы серфинга топиков. А как отработает просмотр, если закинуть в топик сообщение мегабайт на 10 (кейс 1 на миллион, но и такое бывает). Можно было много всего написать.
После таких статей появляются айтишники, которые впервые слышат о том, что кроме curl (хорошо, если и про него знают) бывает еще что-то. Автор мог бы хотя бы из уважения к индустрии про такое legacy не писать, либо поругать и не советовать пользоваться.
Чрезмерная приверженность регламентам и правилам рождается, как правило, в результате чей-то чрезмерной приверженности их нарушать.
На производстве (it в своем роде и есть производство) важен прагматизм, это не сфера обслуживания. Чем быстрее тебе укажут на ошибку, тем эффективнее пойдут процессы. И пусть хоть как это доносят, лишь бы сработало. Прямые личные оскорбления, конечно, не в счет, а с остальным можно жить.
Ну маты и маты. В другом пункте и в тему.
Автор не ханжа, спасибо ему за это.
Процессы до этого не успевали дорасти. Сейчас уже активно используется в одном из топ.
Пост выше был в поддержку второго абзаца. Это как пример того, что без нативных запросов можно наворотить гораздо большее зло.
Все так. Интересно посмотреть, как одними только средствами jpa будут доставать записи по внутренним полям jsonb
2. Замечание не на тему того, кто чей клон, а откуда этот файл берется. Его генерирует определенный annotation processor. Кому нужно делать rebuild проекта ради какой-то подсветки? Вся эта каша нужна в библиотеках и стартерах. Или в 2018 кто-то еще зашивает конфиги в поставку?
3. Это нужно не для инжекта бизнес логики в конфиг! А для создания сложных библиотечных конфигураций, завязанных на стандартных интерфейсах из jsl или кастомной абстракции. В примере из статьи присутствует явное нарушение single responsibility principle.
ConfigurationPropertiesнужно использовать либо в автоконфигурации, либо в сервисе, которому эти конфиги нужны (второе решение — так себе). Код из примера можно понять таким образом (а ведь он именно и написан в таком стиле), что надо все бины прятать в конфиги и через конфиги получать к бинам доступ. А потом кто-то жалуется на невозможность зарезолвить циклические зависимости и тратит по неделе на фикс простейшего бага.2. Еще не хватает объяснения, откуда появляется файл
additional-spring-configuration-metadata.jsonи как он связан сspring-boot-configuration-processor.3. Статьи на хабре читает много новичков; и инжект сервисов в properties, вы шутите?
И какой смысл использовать всю эту кашу с метаданными вне стартеров?
А что будет, если конструктор добавить, уж лучше и не проверять)))
Репа для интеграции со spring не обновлялась уже полтора года.
Выходит, что использовать можно только на свой страх и риск, и вероятно через костыли.
API у него неплох, но и со спецификациями жить тоже можно, хотя бы поддержка есть.