У меня вот такое сейчас решение доделывается: wemos d1 mini pro (плата с esp8266) + scd41 (якобы Sensirion, всё с Алика), подключенный по i2c. Данные в брокер, оттуда другая приложенька в Prometheus перегоняет, ну и Графана, классика. Статью тоже уже начал накидывать :)
Датчик очень чувствительный, можно в дверях в его сторону по диагонали комнаты дыхнуть, и почувствует. Но – я выставил ему корректную высоту над уровнем моря, плюс ambient pressure на основе данных от bme280. Так он стал показывать корректно температуру (в рамках 1 градуса вместе с ds18b20, am2320 и bme280), а вот влажность всё равно на 15% выше, чем и bme280, и am2320. Те два вровень идут, я им по влажности верю :)
На своих проектах тоже пришёл к выводу, что огромной пользы от юнит-тестов нет и получить не выйдет, как покрытие не повышай. Плюс лично я против того, чтобы, когда вносятся нефункциональные изменения в боевой код (рефакторинг), требовалось изменять тесты. Потому что тест должен защитить боевой код от потенциальных проблем при рефакторинге, а изменяя его — ты защищаешь этот самый баг ) И, к слову, даже наличие проблем в непроверенных краевых вызовах какого-то метода может спокойно быть нивелировано реальной невозможностью этот код таким образом вызвать (в рамках ввода пользователя).
Теперь у нас развёрнутая пирамида тестирования — больше всего кейсов у QA, backend-разработчики пишут преимущественно тесты по веткам пользовательский сценариев процессов (как хотите называйте, e2e / интеграционные), а юнитами покрываются только изолированные кирпичики. А TDD очень хорошо заходит, когда реально от QA или с боя прилетает баг — сперва тестом воспроизводится, затем фиксится.
31 августа пройдет первая JVM-конференция от T-Банка в офисе компании Space. Будут доклады по Java- и Scala-стекам, обсуждение общих инженерных практик, много нетворкинга и активностей.
Я был бы очень рад, если бы главное меню показывалось по однократному нажатию ALT, как меню в большинстве прог в Винде. Но тут почему-то `Alt + \`, который ещё и не работает чаще всего ...
Но утверждение, что “ты должен всегда сначала писать тест, прежде чем писать код для продакшена, потому что в противном случае ты не соблюдаешь TDD” — это то, с чем я не согласен.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
Но утверждение, что “ты должен всегда сначала писать тест, прежде чем писать код для продакшена, потому что в противном случае ты не соблюдаешь TDD” — это то, с чем я не согласен.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
Я понял вашу мысль. Я согласен с тем, чем больше всего протестировано комплексно, тем лучше. Но при этом в ряде моментов я остался при своём, мы видимо на разных языках говорим, у каждого своё понимание ситуации и людей, которые в ней оказались, так что давайте остановимся =)
Хорошим тоном в таких процессах являются "чистые" сборки, не зависимые даже от историчности запусков не говоря уже о особенностях внешней среды
Полностью согласен.
А одинаковость настроек не требуется, т.к. они определяются внешними по отношению к артефакту/контейнеру параметрами
Согласен, конечно, 12factor app никто не отменял =) Приложение отдельно, конфигурация отдельно.
Но вообще, обычно, тестовая среда максимально вариативна для лучшего выявления проблем, а стейдж - максимально приближен к продуктиву, иногда делается прямо на основе него.
Смотрите, я триггерю на то, что в статье описывается развёртывание инстанса GitLab локально, и на то, что вы написали "отлаживать пайплайны". Всё это звучит так, будто это туториал по размножению инстансов гитлабов на своей машине, на тестовом стенде, на продовом стенде. Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?
У меня вот такое сейчас решение доделывается: wemos d1 mini pro (плата с esp8266) + scd41 (якобы Sensirion, всё с Алика), подключенный по i2c. Данные в брокер, оттуда другая приложенька в Prometheus перегоняет, ну и Графана, классика. Статью тоже уже начал накидывать :)
Датчик очень чувствительный, можно в дверях в его сторону по диагонали комнаты дыхнуть, и почувствует. Но – я выставил ему корректную высоту над уровнем моря, плюс ambient pressure на основе данных от bme280. Так он стал показывать корректно температуру (в рамках 1 градуса вместе с ds18b20, am2320 и bme280), а вот влажность всё равно на 15% выше, чем и bme280, и am2320. Те два вровень идут, я им по влажности верю :)
Если работал на ЭЛТ-экранах, любой современный кажется ОКъ :) меня реально устраивают любые мониторы, лишь бы диаметр был 22"-24", и штуки три )
Если захотите переписать бизнес-логику на C++, сперва ознакомьтесь с этим: https://pikabu.ru/story/3p_11314661
Мы тоже осенью перешли с 2.7.18 на 3.3.4. Какие-то проблемы пересекались, какие-то свои поймали :) Ушло примерно 1.5 месяца одного разработчика.
Чем больше проект, ИМХО, тем чаще нужно делать более минорные обновления, иначе очень быстро они накапливаются в непреодолимый ком.
В Java 24 ... или В 24-м году в Java 24 ... ? :)
Поддерживаю вопрос, ведь только каждый 4й должен быть LTS...
UseCase это хорошая реализация, а сервис с 100 ответственностями — не очень хорошая :)
Мне понравилось, как это на телефоне выглядит. Согласен :)
На своих проектах тоже пришёл к выводу, что огромной пользы от юнит-тестов нет и получить не выйдет, как покрытие не повышай. Плюс лично я против того, чтобы, когда вносятся нефункциональные изменения в боевой код (рефакторинг), требовалось изменять тесты. Потому что тест должен защитить боевой код от потенциальных проблем при рефакторинге, а изменяя его — ты защищаешь этот самый баг ) И, к слову, даже наличие проблем в непроверенных краевых вызовах какого-то метода может спокойно быть нивелировано реальной невозможностью этот код таким образом вызвать (в рамках ввода пользователя).
Теперь у нас развёрнутая пирамида тестирования — больше всего кейсов у QA, backend-разработчики пишут преимущественно тесты по веткам пользовательский сценариев процессов (как хотите называйте, e2e / интеграционные), а юнитами покрываются только изолированные кирпичики. А TDD очень хорошо заходит, когда реально от QA или с боя прилетает баг — сперва тестом воспроизводится, затем фиксится.
Но тут ещё 5 атмосфер держат, так что глубина уже сильно больше.
А онлайн или запись не планируется?
Да нормально, только делать поменьше вложений, разбивая на отдельные методы :)
Ну или мапстракт :)
Я был бы очень рад, если бы главное меню показывалось по однократному нажатию ALT, как меню в большинстве прог в Винде. Но тут почему-то `Alt + \`, который ещё и не работает чаще всего ...
А я думал, что в статье напишите "Вешайте TxMode.NEVER на все клиенты к внешним системам" :)
Тоже своего рода защита пула коннектов от исчерпания из-за медленных зависимостей...
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.
Но ведь оно верное, не написав тест вперёд, ты не следуешь TDD :)
Имхо, TDD супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.
Использую этот шаблон, он действительно местами очень классно применим, спасибо, что популяризируете :)
Я понял вашу мысль. Я согласен с тем, чем больше всего протестировано комплексно, тем лучше. Но при этом в ряде моментов я остался при своём, мы видимо на разных языках говорим, у каждого своё понимание ситуации и людей, которые в ней оказались, так что давайте остановимся =)
Полностью согласен.
Согласен, конечно, 12factor app никто не отменял =) Приложение отдельно, конфигурация отдельно.
Смотрите, я триггерю на то, что в статье описывается развёртывание инстанса GitLab локально, и на то, что вы написали "отлаживать пайплайны". Всё это звучит так, будто это туториал по размножению инстансов гитлабов на своей машине, на тестовом стенде, на продовом стенде. Причём локально только для того, чтобы посмотреть, как запустился и отработал пайплайн — то есть фактически протестировать сам .gitlab-ci.yaml. Я здесь прав или ошибаюсь?