Главный момент в Ломбоке, с которым стоит быть осторожнее - equals и hashcode для entity. Тут надо действительно быть аккуратным.
Все остальное в статье абсолютная вкусовщина, которая подана как откровение.
При этом похоже автор не понял, что ломбок - это сокращение генерируемого бойлерплейта (тех же конструкторов, геттеров, сеттеров, тустрингов и прочего). Если у вас другой подход (с иной логикой, которая подразумевает умные объекты, инкапсулирующие свое поведение) - ломбок не про это.
В целом спасибо, но если честно - ожидалось, что поделитесь, тем, какие кастомные стартеры с каким функционалом оказались полезны при разработке в общей инфраструктуре. А оказалось - статья по созданию стартера. Что в целом тоже неплохо, но не то что ожидалось...
Эти истории про багатоны всегда вызывают вопросы...
Вот вы 'отпросили' тестеров на 2 дня из команд, а что стало со спринтами потом (если у вас скрам)? Тестерам потом пришлось лихорадочно тестировать задачи, которыми бы они могли заниматься эти 2 дня?
Честно говоря это все выглядит даже печальнее чем просто багатоны - похоже на то, что люди просто сидели и тупо перенабивали правила в код автотестов
Ну и 'мы команда' обычно всплывает когда надо сидеть и фигачить как не в себя, вместо того чтобы нормально запланировать нагрузку и все такое... Как говорится, 'геройство одних - это следствие раздолбайства других'...
Но я как раз от цифр статьи отталкивался - выигрыш на 5 операциях map при листе в 100 - примерно 30к нс, проигрыш от 1 sort - те же 30к нс. Плюс-минус тоже самое. Хотя флаттен и плюс конечно сильно дольше...
Спасибо, очень познавательно! Но возник вопрос, по цифрам похоже даже тяжёлые преобразования (flatten/sort) не так и плохи, если не применять их в коротких цепочках. Либо нет? Я имею в виду, что сиквенс предлагается применять, если цепочка длинная, и в ней тяжёлое преобразование скорее всего будет одним шагом из многих, и рост от его применения возможно будет нивелирован выигрышем на других шагах. Безусловно это никак не оспаривает того, что хорошо, что оно будет исправлено...
Ну то есть заказчикам было ок? Если так - что-то сомнительно, что просто фикс багов так уж мотивирует команды, особенно если это именно просто фикс, и он не совмещён хотя бы с рефакторингом...
Некоторые задачи сразу удалили, поскольку они потеряли актуальность, другие были не воспроизводимы, и так далее.
Получается до багатона всем было плевать, что именно попадает в бэклог и никто его никогда не пересматривал?
Мы договорились, что на багатон у нас есть два дня: в понедельник и вторник фиксим баги, в среду утром подводим итоги и награждаем победителей.
Двухдневный спринт - 26 багов... Возникает вопрос, если они настолько мелкие - почему они не фиксились раньше... Либо недостаток тестирования по итогу, либо завышенные оценки на груминге...
За статью спасибо - интересно посмотреть, где как выстроены процессы.
Нормальный подход для отсеивания совсем никаких спецов. Правда если вопросы такие как на скрине - сколько ошибок в xml - то вопрос, что проверяется и стоит ли экономия времени HR потери реальных миддлов. В конце концов есть IDE, которые этот функционал выполняют...
Но больше интересно - этот тест только миддлам даётся или и выше - тоже?
Спасибо за статью. В очередной раз убедился, что для обычных сервисов смысла в нейтиве никакого.
Запуск 4 секунды против 1, с одной стороны выглядит существенным (допустим 10 батчей в кубе - это 40 секунд против 10. Но если у вас сервис сам стартует секунд 15 хотя бы - это разница 150 секунд против 180. При этом сборка простенького образа в 12 минут - это усложнение разработки...
7% экономии памяти - даже на голом приложении не шокируют. А что будет на реальных нагрузках с хипом реального сервиса - вопрос открытый. Там это может быть разница в 50 мб на фоне гига-двух.
Имхо, нишевое решение для сервисов с большим количеством инстансов и простой логикой, где важно быстро стартануть, принять небольшое количество запросов и также быстро умереть...
Конечно, можно решать и на старой библиотеке, но в новых версиях добавлено очень много методов в стандартную библиотеку. Эти новые методы позволяют написать в 1 строчке то, для чего в старой либе нужно 2-3 и более строк. Но проблема ещё в том, что время введения функций ведь мало кто помнит, а в результате - ошибки компиляции и переписывание (да, со временем запомнится, но в целом это бесполезная информация). В результате - просто писать не очень приятно и уж лучше пайтон/джава...
Опять сравнение по памяти на примере hello world. Может стоит учесть, что в указанное приложение входит куча поддерживающего кода, который по сути fixed cost? В целом какая разница, сколько 'весит' jvm и спринг, если у сервиса например будет хип на 1.5 Гб, а с метаспейсом и прочим - под 2? Или время старта приложения - 3.5 секунды против 1. Да какая разница, если при старте сервис будет что-то из базы качать для инициализации - собирать внутренние кэши или ещё что.
Понятно, что это может быть важно, но сравнивать все же лучше на боевой нагрузке. Либо если нужен супербыстрый старт - использовать другие подходы (но может и действительно не джаву). Просто везде одно и то же - пишем hello world, добавляем в него все стартеры спринга, а потом удивляемся, почему так...
А почему вы демонстрируете свое превосходство над спрингом на таком примере? Может быть лучше сравнить ваш подход на реальном приложении? Там, где эксепшнхендлеры, логгинг, сбор метрик, трейсы и прочее? Ведь так и про spring-core можно сказать, что от его контекста и DI никакой пользы нет, и привести пример приложения с 5 классами...
Чем не устроил банальный хибер и спринг jpa?
Главный момент в Ломбоке, с которым стоит быть осторожнее - equals и hashcode для entity. Тут надо действительно быть аккуратным.
Все остальное в статье абсолютная вкусовщина, которая подана как откровение.
При этом похоже автор не понял, что ломбок - это сокращение генерируемого бойлерплейта (тех же конструкторов, геттеров, сеттеров, тустрингов и прочего). Если у вас другой подход (с иной логикой, которая подразумевает умные объекты, инкапсулирующие свое поведение) - ломбок не про это.
В своей части он прекрасен.
В целом спасибо, но если честно - ожидалось, что поделитесь, тем, какие кастомные стартеры с каким функционалом оказались полезны при разработке в общей инфраструктуре. А оказалось - статья по созданию стартера. Что в целом тоже неплохо, но не то что ожидалось...
Эти истории про багатоны всегда вызывают вопросы...
Вот вы 'отпросили' тестеров на 2 дня из команд, а что стало со спринтами потом (если у вас скрам)? Тестерам потом пришлось лихорадочно тестировать задачи, которыми бы они могли заниматься эти 2 дня?
Честно говоря это все выглядит даже печальнее чем просто багатоны - похоже на то, что люди просто сидели и тупо перенабивали правила в код автотестов
Ну и 'мы команда' обычно всплывает когда надо сидеть и фигачить как не в себя, вместо того чтобы нормально запланировать нагрузку и все такое... Как говорится, 'геройство одних - это следствие раздолбайства других'...
Вы действительно считаете, что нейтив-код в 10 раз быстрее в реальном приложении, а не в синтетических тестах?
Будет ли в 10 раз быстрее работать ваше приложение?
Запросы в БД
Запросы в иные сервисы
Странно, не очень понимаю, зачем системному аналитику знать, как конкретно пишутся заголовки запроса, или как на питоне написать гет...
В каком случае он может применить эти данные? Неужели реально это спрашивают на собесах аналитиков?
Да, все так, скорее всего в большинстве случаев 3-4 шага...
Но я как раз от цифр статьи отталкивался - выигрыш на 5 операциях map при листе в 100 - примерно 30к нс, проигрыш от 1 sort - те же 30к нс. Плюс-минус тоже самое. Хотя флаттен и плюс конечно сильно дольше...
Спасибо, очень познавательно! Но возник вопрос, по цифрам похоже даже тяжёлые преобразования (flatten/sort) не так и плохи, если не применять их в коротких цепочках. Либо нет? Я имею в виду, что сиквенс предлагается применять, если цепочка длинная, и в ней тяжёлое преобразование скорее всего будет одним шагом из многих, и рост от его применения возможно будет нивелирован выигрышем на других шагах. Безусловно это никак не оспаривает того, что хорошо, что оно будет исправлено...
Ну то есть заказчикам было ок? Если так - что-то сомнительно, что просто фикс багов так уж мотивирует команды, особенно если это именно просто фикс, и он не совмещён хотя бы с рефакторингом...
Получается до багатона всем было плевать, что именно попадает в бэклог и никто его никогда не пересматривал?
Двухдневный спринт - 26 багов... Возникает вопрос, если они настолько мелкие - почему они не фиксились раньше... Либо недостаток тестирования по итогу, либо завышенные оценки на груминге...
За статью спасибо - интересно посмотреть, где как выстроены процессы.
Нормальный подход для отсеивания совсем никаких спецов. Правда если вопросы такие как на скрине - сколько ошибок в xml - то вопрос, что проверяется и стоит ли экономия времени HR потери реальных миддлов. В конце концов есть IDE, которые этот функционал выполняют...
Но больше интересно - этот тест только миддлам даётся или и выше - тоже?
Спасибо за статью. В очередной раз убедился, что для обычных сервисов смысла в нейтиве никакого.
Запуск 4 секунды против 1, с одной стороны выглядит существенным (допустим 10 батчей в кубе - это 40 секунд против 10. Но если у вас сервис сам стартует секунд 15 хотя бы - это разница 150 секунд против 180. При этом сборка простенького образа в 12 минут - это усложнение разработки...
7% экономии памяти - даже на голом приложении не шокируют. А что будет на реальных нагрузках с хипом реального сервиса - вопрос открытый. Там это может быть разница в 50 мб на фоне гига-двух.
Имхо, нишевое решение для сервисов с большим количеством инстансов и простой логикой, где важно быстро стартануть, принять небольшое количество запросов и также быстро умереть...
За статью спасибо, понравилась.
Конечно, можно решать и на старой библиотеке, но в новых версиях добавлено очень много методов в стандартную библиотеку. Эти новые методы позволяют написать в 1 строчке то, для чего в старой либе нужно 2-3 и более строк. Но проблема ещё в том, что время введения функций ведь мало кто помнит, а в результате - ошибки компиляции и переписывание (да, со временем запомнится, но в целом это бесполезная информация). В результате - просто писать не очень приятно и уж лучше пайтон/джава...
Опять сравнение по памяти на примере hello world. Может стоит учесть, что в указанное приложение входит куча поддерживающего кода, который по сути fixed cost? В целом какая разница, сколько 'весит' jvm и спринг, если у сервиса например будет хип на 1.5 Гб, а с метаспейсом и прочим - под 2? Или время старта приложения - 3.5 секунды против 1. Да какая разница, если при старте сервис будет что-то из базы качать для инициализации - собирать внутренние кэши или ещё что.
Понятно, что это может быть важно, но сравнивать все же лучше на боевой нагрузке. Либо если нужен супербыстрый старт - использовать другие подходы (но может и действительно не джаву). Просто везде одно и то же - пишем hello world, добавляем в него все стартеры спринга, а потом удивляемся, почему так...
А почему вы демонстрируете свое превосходство над спрингом на таком примере? Может быть лучше сравнить ваш подход на реальном приложении? Там, где эксепшнхендлеры, логгинг, сбор метрик, трейсы и прочее? Ведь так и про spring-core можно сказать, что от его контекста и DI никакой пользы нет, и привести пример приложения с 5 классами...