Далее, сборка приложения производит "мусор", который вам не нужен для запуска. Опять же инструменты вроде maven и сами исходники не нужны. Смотреть в сторону multi-stage builds.
Я понимаю, что "это-ж для начинающих". Но потом подобное кочует из проекта в проект.
Сколько лет я читаю про HateUs — до сих пор не видел ни одного логичного объяснения зачем оно нужно с чисто практической точки зрения.
Очень много воды про "слабосвязанные компоненты" и прочую чепуху. Но, пардон, rest client — это не человек. Ему не нужно эмпирически выяcнять куда кликнуть, чтобы получить результат.
Вот ни разу не спорное. json per line формат широко распространен и супер-удобен при централизации логов. Настроить логирование в json в том-же spring-boot — дело двух минут:
Полностью согласен. Пример из практики — было два компонента системы со сложной логикой, где общение между ними организовали с помощью websockets, но в процессе тестирования в реальной среде выявились проблемы. Websockets заменили на rest API.
Интеграционные тесты переписывать не пришлось вообще. Чему я был рад до безумия.
Я вообще придерживаюсь мнения, что знаменитую пирамидку с тестами надо перевернуть — интеграционные тесты должны покрывать большую часть функционала, а юнить тесты писать только там где они нужны(на сложную логику или алгоритмы).
Я честно говоря в теме как свинья в апельсинах поэтому дисклэймер — могу спросить глупость.
Вопрос раз — можно ли этот фреймворк сравнить с wav2letter? Он вроде совсем не упоминается здесь.
Вопрос два — по поводу тестирования фреймворков. Мой небольшой опыт показывает, что распознование сильно зависит от конкретной модели. Т.е. кастомная модель натасканная на определенный словарь может показать лучший результат, чем модель широкого профиля. Это как-то учитывалось при тестировании?
Сильно зависит от команды, я знаю примеры в Klarna и Kindred, когда команды сложились удачно.
Плюс так как у них больше ресурсов они имеют возможность подбирать персонал более тщательно. Но в конечном итоге — все лотерея. Или повезет с людьми или нет.
Проблема европейских(хотя я только по Стокгольму сужу) команд — человека практически нельзя уволить, если проморгали испытательный срок. Плюс обычно подобные «товарищи» как в статье не стремятся менять работу, если их и на текущем место все устраивает.
Т.е. если в коллективе есть подобная «черная овца», то его постоянно будут пытаться развивать, обучать и прочее. Уволить его вряд ли уволят. И вполне возможно из-за него уйдет несколько хороших сотрудников.
У меня сейчас подобная ситуация, но я уходу больше из-за непрофессионального менеджмента как среднего так и «топ». Такие вещи вообще никак не исправить.
Лень читать все комментарии, но могу объяснить почему такой **здец происходит. Я так понимаю, что fainalex в Стокгольме обитает? Сейчас на рынке разработчиков жуткий вакуум. Такие компании как Spotify, Klarna, Unibet(kindred) и куча других всасывают все что есть.
Другие же компании зачастую счастливы тому что остается.
Плюс корпоративная культура другая — уволить человека практически невозможно(если он employee, а не консультант).
Как работник другой шведской компании говорю — после нескольких лет жизни здесь начинаешь даже повседневные слова подменять англицизмами, а профессиональные термины тем более.
Лично мое мнение о стат. анализаторах кода(пользую парочку на яве): подключил, есть-пить не просит, ложных срабатываний не очень много — пусть живет.
Имхо, большинство негативных отзывов приходят от людей, которыми анализаторами никогда не пользовались.
2) и 3) это особые случаи и обычно вставляется комментарий который выключит проверку анализатора в этом месте. Добро пожаловать в 21 век.
Ошибся. Должно быть "ENTRYPOINT ["sh", "-c", "exec java ...."
Бесполезного процесса при этом не создается.
Хотя если честно я distroless java использую от google, там проблемы с этим вообще нет.
Не очень удачный способ запуска, если хочется передать хоть какие-то переменные окружения, лучше
Далее, сборка приложения производит "мусор", который вам не нужен для запуска. Опять же инструменты вроде maven и сами исходники не нужны. Смотреть в сторону multi-stage builds.
Я понимаю, что "это-ж для начинающих". Но потом подобное кочует из проекта в проект.
Все это здорово, но я опять повторю вопрос: с практической точки зрения зачем оно нужно?
Не поверю пока не увижу. Если я поменяю API, то клиент тупо упадет.
Сколько лет я читаю про HateUs — до сих пор не видел ни одного логичного объяснения зачем оно нужно с чисто практической точки зрения.
Очень много воды про "слабосвязанные компоненты" и прочую чепуху. Но, пардон, rest client — это не человек. Ему не нужно эмпирически выяcнять куда кликнуть, чтобы получить результат.
Вот ни разу не спорное. json per line формат широко распространен и супер-удобен при централизации логов. Настроить логирование в json в том-же spring-boot — дело двух минут:
build.gradle.kts:
log4j2-spring.xml:
vasyapivo и пишет, что нужны не языки ради языков, а языки, которые решают определенные проблемы.
Интеграционные тесты переписывать не пришлось вообще. Чему я был рад до безумия.
Я вообще придерживаюсь мнения, что знаменитую пирамидку с тестами надо перевернуть — интеграционные тесты должны покрывать большую часть функционала, а юнить тесты писать только там где они нужны(на сложную логику или алгоритмы).
Так надо просто запретить воровать информацию и проблема будет решена.
Вопрос раз — можно ли этот фреймворк сравнить с wav2letter? Он вроде совсем не упоминается здесь.
Вопрос два — по поводу тестирования фреймворков. Мой небольшой опыт показывает, что распознование сильно зависит от конкретной модели. Т.е. кастомная модель натасканная на определенный словарь может показать лучший результат, чем модель широкого профиля. Это как-то учитывалось при тестировании?
Плюс так как у них больше ресурсов они имеют возможность подбирать персонал более тщательно. Но в конечном итоге — все лотерея. Или повезет с людьми или нет.
Проблема европейских(хотя я только по Стокгольму сужу) команд — человека практически нельзя уволить, если проморгали испытательный срок. Плюс обычно подобные «товарищи» как в статье не стремятся менять работу, если их и на текущем место все устраивает.
Т.е. если в коллективе есть подобная «черная овца», то его постоянно будут пытаться развивать, обучать и прочее. Уволить его вряд ли уволят. И вполне возможно из-за него уйдет несколько хороших сотрудников.
У меня сейчас подобная ситуация, но я уходу больше из-за непрофессионального менеджмента как среднего так и «топ». Такие вещи вообще никак не исправить.
Другие же компании зачастую счастливы тому что остается.
Плюс корпоративная культура другая — уволить человека практически невозможно(если он employee, а не консультант).
Плюс менталитет другой.