Прям коробит, когда люди навешивают к @Data AAC и NAC бездумно, типа мол пусть будет. @Data и так включает RAC, который в зависимости от наличия final на полях всё сделает в лучшем виде.
Но юзать @Data желательно ... только лишь нигде и никогда. Гораздо предпочтительнее иммутабельный аналог -- @Value, который нельзя повешать разве только на JPA сущности, но так и @Data в них тоже не выстреливает проблемами только в простых случаях.
Ну и да, Accessors, Builder/SuperBuilder, UtilityClass, SneakyThrows, lombok.config и много чего ещё -- вообще не упомянуто. Поэтому за статью минус.
Можно будет, я на самом деле для этого комментарий свой и оставил, чтобы по нему место найти =) Но вряд ли слишком быстро напишу, как минимум до конца месяца надо будет подождать. У меня прямо сейчас всё вот в таком только виде, а идея так же самая -- во всех комнатах отдельные независимые измерялки разложить.
Если попытаться обойтись без статьи, мне не жалко скинуть частично урезанный код, надо будет плату с esp8266 и датчик. Про калибровку SCD41 -- вроде как его достаточно очень редко выставлять в окошко, где условно "400 ppm или меньше", этого должно хватать. Предложу пока почитать даташит ) https://sensirion.com/media/documents/48C4B7FB/66E05452/CD_DS_SCD4x_Datasheet_D1.pdf
У меня вот такое сейчас решение доделывается: 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 супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
Прям коробит, когда люди навешивают к
@DataAAC и NAC бездумно, типа мол пусть будет.@Dataи так включает RAC, который в зависимости от наличия final на полях всё сделает в лучшем виде.Но юзать
@Dataжелательно ... только лишь нигде и никогда. Гораздо предпочтительнее иммутабельный аналог --@Value, который нельзя повешать разве только на JPA сущности, но так и@Dataв них тоже не выстреливает проблемами только в простых случаях.Ну и да, Accessors, Builder/SuperBuilder, UtilityClass, SneakyThrows, lombok.config и много чего ещё -- вообще не упомянуто. Поэтому за статью минус.
Зато оно читается легче многих других книг :)
Вот зачем вы хорошие дырки озвучиваете?)
Можно будет, я на самом деле для этого комментарий свой и оставил, чтобы по нему место найти =) Но вряд ли слишком быстро напишу, как минимум до конца месяца надо будет подождать. У меня прямо сейчас всё вот в таком только виде, а идея так же самая -- во всех комнатах отдельные независимые измерялки разложить.
Если попытаться обойтись без статьи, мне не жалко скинуть частично урезанный код, надо будет плату с esp8266 и датчик. Про калибровку SCD41 -- вроде как его достаточно очень редко выставлять в окошко, где условно "400 ppm или меньше", этого должно хватать. Предложу пока почитать даташит ) https://sensirion.com/media/documents/48C4B7FB/66E05452/CD_DS_SCD4x_Datasheet_D1.pdf
У меня вот такое сейчас решение доделывается: 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 супер, когда ты правишь баг. Сперва воспроизвёл, убедился, что это оно, а потом поправил прод код, и тест прошёл.
В остальных случаях скорее согласен с автором.