Я тоже за ним с интересом наблюдаю, и всё жду, что будет достигнута какая-то точка. Например, выход Spring Boot 3. А после этой точки интересна судьба микронавта, кваркуса и т.п.
Да, согласен, но я вижу некоторую нотку, которая мне не нравится. Автор хотел показать в статье как можно больше возможных проблем и их решений, и я его полностью понимаю, но суммарный тон получился "Смотрите, как много проблем вас ждёт при апдейте", что может в какой-то мере добавить страху другим разработчикам и остановить их от попыток апдейта.
Я думаю автор сам понимает, но нарочно выбрал такой путь, чтобы получилась статья.
Ведь на самом деле 2/3 этой части по то, как обновить Спринг Бут большим прыжком, с 2.3 на 2.5. А почему не 2.6? Автор опять собирается копить костыли для будущей статьи "как всё тяжело и он устал". И этот реверанс с ломбоком как будто сделан специально, чтобы увеличить материал. Я не обвиняю, скорее всего именно таких читателей у него будет много и статья найдет отклик.
Обновление Спринга и обновление джавы -- могут быть и скорее всего должны быть отдельными задачами. На нашем проекте я всегда обновляю Спринг до нового релиза, решая проблемы по мере их появления, а не откладывая, поэтому все обновления джав (проект был начат на 12) -- в общем-то были банальны, вплоть до "заменить одну циферку".
Лучше добавить @EqualsAndHashCode.Include на единственное корректное для этого поле — id, и над каждой сущностью дополнительно @EqualsAndHashCode(onlyExplicitlyIncluded=true).
Я тоже не стесняюсь использовать Lombok в проектах и JPA-сущностях по полной, но должен предупредить автора о наличии в коде проблем. У вас @Data на сущностях с двусторонними взаимоотношениями — там по умолчанию есть @ToString и будет Stack Overflow при попытке вывести сущность в лог. Да и hashCode и equals тоже будут на него напарываться.
Стол достаточно широкий и глубокий, может быть это из-за "рыбьего глаза" не так заметно (все мониторы 24"). К тому же я не очень люблю на столе держать какие-то лишние вещи, например стакан и йогурт это временное, типичное содержимое: клавиатура, мышь, тетрадка с ручкой на ней, мои руки. Стикеры на подставках.
Мне не нравится, что системник на полу собирает сильно больше пыли, плюс об него можно начать биться ногами.
Мне нравится работать с тремя мониторами. Пусть даже они не очень современные и где-то цвета не вытягивают до конца. И рамки есть, но я не располагаю окна так, чтобы они делились между мониторами. Пожалуй, попробую развернуть хотя бы левый, он уже на кронштейне и крутится :)
Благодарю! Когда-то очень давно слышал про него, а потом напрочь вылетело из головы.
Насколько я понял из беглого прочтения README, если запускать через Maven-плагин или через CLI, наверное ему всё равно нужен доступный docker daemon. Да, с моим подходом можно заменить docker cli на jib cli, например, в первом образе.
Возможно, в течении пары недель попробую собрать им и посмотреть на разницу в итоговом образе со сборкой моим Dockerfile-ом.
Пару лет пользовался Rainbow brackets, но в последней версии IDEA заметил, что он тормозит, постоянно нагрузка на CPU. Выключил, Идея [относительно] полетела.
Всё равно в светлой теме от него не сильно проку :(
Так это в таком примере простом размер commited такой, потому что поток ничего кроме записи в консоль не делает. В реальной жизни большая вложенность стека, в том числе куча проксей, и в методах может быть куча аллоцированных на стеке данных.
Я лично в своих проектах (джава 15, к слову) уменьшаю Xss до 512 кб, потому что уменьшать дальше страшновато. То, что commited != max это понятно и замечательно.
Была похожая задача, по запросу API отдавали .xlsx, формируемый POI. В какой-то момент данных стало в разы больше, решили поменять формат на .csv. Из БД streamAllBy...(), тоже с какими-то хинтами (mysql), апачевский csv writer пишет в цикле сразу в httpResponse-овый outputStream. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Я тоже за ним с интересом наблюдаю, и всё жду, что будет достигнута какая-то точка. Например, выход Spring Boot 3. А после этой точки интересна судьба микронавта, кваркуса и т.п.
Запуститься на более свежем LTS-рантайме (11, 17) — уже для многих подвиг.
Если ваш код + все зависимости работают нормально в таких условиях, то дальше поднять уровень своего исходного кода — уже вообще ни разу не проблема.
Да, согласен, но я вижу некоторую нотку, которая мне не нравится. Автор хотел показать в статье как можно больше возможных проблем и их решений, и я его полностью понимаю, но суммарный тон получился "Смотрите, как много проблем вас ждёт при апдейте", что может в какой-то мере добавить страху другим разработчикам и остановить их от попыток апдейта.
Я думаю автор сам понимает, но нарочно выбрал такой путь, чтобы получилась статья.
Ведь на самом деле 2/3 этой части по то, как обновить Спринг Бут большим прыжком, с 2.3 на 2.5. А почему не 2.6? Автор опять собирается копить костыли для будущей статьи "как всё тяжело и он устал". И этот реверанс с ломбоком как будто сделан специально, чтобы увеличить материал. Я не обвиняю, скорее всего именно таких читателей у него будет много и статья найдет отклик.
Обновление Спринга и обновление джавы -- могут быть и скорее всего должны быть отдельными задачами. На нашем проекте я всегда обновляю Спринг до нового релиза, решая проблемы по мере их появления, а не откладывая, поэтому все обновления джав (проект был начат на 12) -- в общем-то были банальны, вплоть до "заменить одну циферку".
Лучше добавить
@EqualsAndHashCode.Includeна единственное корректное для этого поле — id, и над каждой сущностью дополнительно@EqualsAndHashCode(onlyExplicitlyIncluded=true).Я тоже не стесняюсь использовать Lombok в проектах и JPA-сущностях по полной, но должен предупредить автора о наличии в коде проблем. У вас
@Dataна сущностях с двусторонними взаимоотношениями — там по умолчанию есть@ToStringи будет Stack Overflow при попытке вывести сущность в лог. Да и hashCode и equals тоже будут на него напарываться.Всё это описывает вот эта вполне себе "классическая" статья: https://thorben-janssen.com/lombok-hibernate-how-to-avoid-common-pitfalls/
Стол достаточно широкий и глубокий, может быть это из-за "рыбьего глаза" не так заметно (все мониторы 24"). К тому же я не очень люблю на столе держать какие-то лишние вещи, например стакан и йогурт это временное, типичное содержимое: клавиатура, мышь, тетрадка с ручкой на ней, мои руки. Стикеры на подставках.
Мне не нравится, что системник на полу собирает сильно больше пыли, плюс об него можно начать биться ногами.
Мне нравится работать с тремя мониторами. Пусть даже они не очень современные и где-то цвета не вытягивают до конца. И рамки есть, но я не располагаю окна так, чтобы они делились между мониторами. Пожалуй, попробую развернуть хотя бы левый, он уже на кронштейне и крутится :)
А вы генератор или какой-то свой другой код не планируете выкладывать в открытый доступ?
9/19 "за", так и знал, что я не плюсовик! :)
Мне кажется, с Java 8 стоило хотя бы начинать. Это старьё уже никому не интересно и сотни раз расписано.
У них слишком маленький рынок
Благодарю! Когда-то очень давно слышал про него, а потом напрочь вылетело из головы.
Насколько я понял из беглого прочтения README, если запускать через Maven-плагин или через CLI, наверное ему всё равно нужен доступный docker daemon. Да, с моим подходом можно заменить docker cli на jib cli, например, в первом образе.
Возможно, в течении пары недель попробую собрать им и посмотреть на разницу в итоговом образе со сборкой моим Dockerfile-ом.
Люди делятся на два типа :))
Хипстеры и луддиты. Не важно, разработчики они или сисадмины, или кто-то ещё :) По каждую из сторон баррикад есть и те, и те.
П.с. Хипстеры 4евер!
Пару лет пользовался Rainbow brackets, но в последней версии IDEA заметил, что он тормозит, постоянно нагрузка на CPU. Выключил, Идея [относительно] полетела.
Всё равно в светлой теме от него не сильно проку :(
Так это в таком примере простом размер commited такой, потому что поток ничего кроме записи в консоль не делает. В реальной жизни большая вложенность стека, в том числе куча проксей, и в методах может быть куча аллоцированных на стеке данных.
Я лично в своих проектах (джава 15, к слову) уменьшаю Xss до 512 кб, потому что уменьшать дальше страшновато. То, что commited != max это понятно и замечательно.
Какие-то странные у Вас потоки, по 16 кб. А стек по умолчанию на 1 мб/поток?
Была похожая задача, по запросу API отдавали .xlsx, формируемый POI. В какой-то момент данных стало в разы больше, решили поменять формат на .csv. Из БД streamAllBy...(), тоже с какими-то хинтами (mysql), апачевский csv writer пишет в цикле сразу в httpResponse-овый outputStream. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Так у них полноценная поддержка, а не расширенная :)
Альфа и бета подразумевают нестабильность. Это полноценные релизы.
Для Вас это слишком быстро, несколько новых языковых фич за несколько лет?