Есть и исключения. Когда кто-то пришел на платку, иделально закрыл пару семестров, перевелся на бесплатку, после чего с успехом дошел до конца.
К чему это я.
В пареллельной вселенной можно было бы сделать некий гибрид между платным-бесплатным образованием.
Достойно работаешь в вузе - учись бесплатно Недотягиваешь - доплачивай Явно косячишь - гони бабки
А не вот это вот всё.
В свое время особенно на платных целивиков интересно было смотреть. Это прямо как платник в кубе, с которым никто и ничего не может сделать без последствий для кафедры.
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 корректную расстановку хидеров; это нужно проверить.
Есть и исключения. Когда кто-то пришел на платку, иделально закрыл пару семестров, перевелся на бесплатку, после чего с успехом дошел до конца.
К чему это я.
В пареллельной вселенной можно было бы сделать некий гибрид между платным-бесплатным образованием.
Достойно работаешь в вузе - учись бесплатно
Недотягиваешь - доплачивай
Явно косячишь - гони бабки
А не вот это вот всё.
В свое время особенно на платных целивиков интересно было смотреть. Это прямо как платник в кубе, с которым никто и ничего не может сделать без последствий для кафедры.
Платные места подорожают, ясно-понятно.
В 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 у него неплох, но и со спецификациями жить тоже можно, хотя бы поддержка есть.