Pull to refresh
-1
0
Андрей Урванцев @endymion

Пользователь

Send message

Лично мое мнение о стат. анализаторах кода(пользую парочку на яве): подключил, есть-пить не просит, ложных срабатываний не очень много — пусть живет.


Имхо, большинство негативных отзывов приходят от людей, которыми анализаторами никогда не пользовались.

2) и 3) это особые случаи и обычно вставляется комментарий который выключит проверку анализатора в этом месте. Добро пожаловать в 21 век.

Ошибся. Должно быть "ENTRYPOINT ["sh", "-c", "exec java ...."


Бесполезного процесса при этом не создается.


Хотя если честно я distroless java использую от google, там проблемы с этим вообще нет.

ENTRYPOINT ["java","-jar","target/microservices-gateway-1.0.0.jar"]

Не очень удачный способ запуска, если хочется передать хоть какие-то переменные окружения, лучше


ENTRYPOINT ["sh", "-c", "java -jar target/microservices-gateway-1.0.0.jar"]

Далее, сборка приложения производит "мусор", который вам не нужен для запуска. Опять же инструменты вроде maven и сами исходники не нужны. Смотреть в сторону multi-stage builds.


Я понимаю, что "это-ж для начинающих". Но потом подобное кочует из проекта в проект.

Все это здорово, но я опять повторю вопрос: с практической точки зрения зачем оно нужно?

Не поверю пока не увижу. Если я поменяю API, то клиент тупо упадет.

Сколько лет я читаю про HateUs — до сих пор не видел ни одного логичного объяснения зачем оно нужно с чисто практической точки зрения.


Очень много воды про "слабосвязанные компоненты" и прочую чепуху. Но, пардон, rest client — это не человек. Ему не нужно эмпирически выяcнять куда кликнуть, чтобы получить результат.

Вот ни разу не спорное. json per line формат широко распространен и супер-удобен при централизации логов. Настроить логирование в json в том-же spring-boot — дело двух минут:


build.gradle.kts:


configurations {
    all {
        exclude("org.springframework.boot", "spring-boot-starter-logging")
    }
}

dependencies {
  implementation("org.springframework.boot:spring-boot-starter-log4j2")
}

log4j2-spring.xml:


<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT" follow="true">
            <JsonLayout compact="true" eventEol="true" properties="false" stacktraceAsString="true">
                <!-- Zipkin
                <KeyValuePair key="trace" value="$${ctx:X-B3-TraceId:-}"/>
                <KeyValuePair key="span" value="$${ctx:X-B3-SpanId:-}"/>
                <KeyValuePair key="parent" value="$${ctx:X-B3-ParentSpanId:-}"/>
                <KeyValuePair key="exportable" value="$${ctx:X-Span-Export:-}"/>
                -->
            </JsonLayout>
        </Console>
    </Appenders>
    <Loggers>

        <Logger name="io.micrometer" level="warn"/>
        <Logger name="org.apache.kafka" level="warn"/>
        <Logger name="org.hibernate.validator" level="warn"/>
        <Logger name="org.springframework" level="warn"/>

        <Root level="info">
            <AppenderRef ref="Console"/>
        </Root>
    </Loggers>
</Configuration>
решать свои проблемы

vasyapivo и пишет, что нужны не языки ради языков, а языки, которые решают определенные проблемы.
Полностью согласен. Пример из практики — было два компонента системы со сложной логикой, где общение между ними организовали с помощью websockets, но в процессе тестирования в реальной среде выявились проблемы. Websockets заменили на rest API.

Интеграционные тесты переписывать не пришлось вообще. Чему я был рад до безумия.

Я вообще придерживаюсь мнения, что знаменитую пирамидку с тестами надо перевернуть — интеграционные тесты должны покрывать большую часть функционала, а юнить тесты писать только там где они нужны(на сложную логику или алгоритмы).
Все-таки переводить «Notebooks» как ноутбук — не есть хорошо.
Запись на флэшки запрещена

Так надо просто запретить воровать информацию и проблема будет решена.
Я честно говоря в теме как свинья в апельсинах поэтому дисклэймер — могу спросить глупость.

Вопрос раз — можно ли этот фреймворк сравнить с wav2letter? Он вроде совсем не упоминается здесь.

Вопрос два — по поводу тестирования фреймворков. Мой небольшой опыт показывает, что распознование сильно зависит от конкретной модели. Т.е. кастомная модель натасканная на определенный словарь может показать лучший результат, чем модель широкого профиля. Это как-то учитывалось при тестировании?
Сильно зависит от команды, я знаю примеры в Klarna и Kindred, когда команды сложились удачно.

Плюс так как у них больше ресурсов они имеют возможность подбирать персонал более тщательно. Но в конечном итоге — все лотерея. Или повезет с людьми или нет.
Хороший лид — это всегда залог успеха.

Проблема европейских(хотя я только по Стокгольму сужу) команд — человека практически нельзя уволить, если проморгали испытательный срок. Плюс обычно подобные «товарищи» как в статье не стремятся менять работу, если их и на текущем место все устраивает.

Т.е. если в коллективе есть подобная «черная овца», то его постоянно будут пытаться развивать, обучать и прочее. Уволить его вряд ли уволят. И вполне возможно из-за него уйдет несколько хороших сотрудников.

У меня сейчас подобная ситуация, но я уходу больше из-за непрофессионального менеджмента как среднего так и «топ». Такие вещи вообще никак не исправить.
Лень читать все комментарии, но могу объяснить почему такой **здец происходит. Я так понимаю, что fainalex в Стокгольме обитает? Сейчас на рынке разработчиков жуткий вакуум. Такие компании как Spotify, Klarna, Unibet(kindred) и куча других всасывают все что есть.
Другие же компании зачастую счастливы тому что остается.

Плюс корпоративная культура другая — уволить человека практически невозможно(если он employee, а не консультант).

Плюс менталитет другой.
Ещё как принято. У нас в текущей конторе из которой я ухожу несколько человек «gick i vägg».
Как работник другой шведской компании говорю — после нескольких лет жизни здесь начинаешь даже повседневные слова подменять англицизмами, а профессиональные термины тем более.
В корне неверно насчет синтаксического сахара и анонимов — там используется invoke dynamic.
1

Information

Rating
Does not participate
Location
Stockholm, Stockholms Län, Швеция
Date of birth
Registered
Activity