Лучше добавить @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. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Увы приходится. Продакшен, деньги, вот это вот все.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
неLTS это именно беты. Там в каждой есть критические баги.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
А вот как обосновать хотя бы пару недель два раза в год для пересаживания на неLTS с учетом потенциальных багов в ней я не знаю.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
Лучше добавить
@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. Ну да, у бизнеса нет форматирования колонок, им норм:) Зато быстро работает, не ограничен размером сверху и временных файлов на диске не требует.
Так у них полноценная поддержка, а не расширенная :)
Альфа и бета подразумевают нестабильность. Это полноценные релизы.
Для Вас это слишком быстро, несколько новых языковых фич за несколько лет?
Спасибо за ответы.
Конечно, я не знаю конкретно вашей ситуации, но в моей (аутсорс, финтех) тоже есть продакшен, от которого зависит и финансовое положение и репутационное заказчика. Обновляемся каждый раз до свежего релиза уже 2+ года спустя примерно месяц после его выхода.
Можно примеры таких багов?
Единственный баг, который реально словили за всё время — описан в этой статье (сами с ним не разобрались, а просто на бою накинули ресурсов). При этом наверняка были какие-то тонкости, которые время от времени решали, но это было быстро и незаметно.
Поэтому я всё-таки склонен считать, что релизы это именно релизы. Для достаточной уверенности можно не использовать preview features (я использую), и подождать хотя бы первого Update.
Ваши "2 недели 2 раза в год" — как-то очень завышено. В среднем это от 1 часа до 1 дня. Иногда (12 -> 13 и 13 -> 14) уходило по 5 минут на Find & Replace. Как раз то, что даже можно не пропихивать бизнесу, а просто взять и сделать, потому что обсуждать дольше (естественно, речь про один среднего размера проект на единицы микросервисов, а не "целый банк").
Единственное, что меня реально пугало бы в любом отдельно взятом проекте — миграция с 8 на 9+.
Обоснований куча. Для меня это шанс обновляться маленькими шагами, а не огромным скопом. Плюс возможность иметь фишки раньше. Не надо относиться к неLTS как к бетам.
Really? O_o