Но ведь нет. Есть панель Git -- и в ней логично (и удобно!) видеть и локальные изменения, изменения по другим коммитам, в соседних вкладках. Вот как это выглядит:
Если мы переключаемся на немодальный коммит, правки просто не видны, их нет, вторая открытая панель съедает место, вместо Project:
Это совершенно другой опыт работы с рабочими файлами.
Мне лично не интересен сам процесс коммита, пусть он будет реализован как угодно, но во время работы (а не фиксации) я хочу видеть правки в измененных файлах, и раньше это была вкладка на панельке Git называющаяся Local changes, а теперь её тут нет, и это, имхо, ломает саму концепцию панельки Git -- работу с файлами.
Увы, но регулярно используя EAP-ы, в коем-то веке пришлось откатываться из-за неудобства на предыдущую версию :(((
Ну короче опять пришли к тому, что есть твой реальный опыт и качества, и есть то, за сколько ты себя продал. И чем сильнее вглядываться в корреляцию, тем она оказывается меньше.
Скорее да, чем нет, но личное предпочтение у меня — DTO в апишке удобнее всё-таки описывать @Value + @Builder , а уже внутри модельки или кортежи рекордами описывать. Когда на поля хочешь накинуть тонну аннотаций, класс выглядит красивше :)
Прям коробит, когда люди навешивают к @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. Те два вровень идут, я им по влажности верю :)
А вот это интересно, кажется то, что именно мне нужно было ) Спасибо за наводку!
Но ведь нет. Есть панель Git -- и в ней логично (и удобно!) видеть и локальные изменения, изменения по другим коммитам, в соседних вкладках. Вот как это выглядит:
Если мы переключаемся на немодальный коммит, правки просто не видны, их нет, вторая открытая панель съедает место, вместо Project:
Это совершенно другой опыт работы с рабочими файлами.
Мне лично не интересен сам процесс коммита, пусть он будет реализован как угодно, но во время работы (а не фиксации) я хочу видеть правки в измененных файлах, и раньше это была вкладка на панельке Git называющаяся Local changes, а теперь её тут нет, и это, имхо, ломает саму концепцию панельки Git -- работу с файлами.
Увы, но регулярно используя EAP-ы, в коем-то веке пришлось откатываться из-за неудобства на предыдущую версию :(((
Да, мне пофиг на коммит, но отсутствие локальных правок в окне Git прям больное фейлище :(
Ну короче опять пришли к тому, что есть твой реальный опыт и качества, и есть то, за сколько ты себя продал. И чем сильнее вглядываться в корреляцию, тем она оказывается меньше.
Значит, возможно, окружение в этой компании просто не способствует нужному росту...
С другой стороны, мы же не ожидаем, что все станут сеньорами, какое-то подобие пирамиды в грейдах должно сохраняться :)
Скорее да, чем нет, но личное предпочтение у меня — DTO в апишке удобнее всё-таки описывать
@Value+@Builder, а уже внутри модельки или кортежи рекордами описывать. Когда на поля хочешь накинуть тонну аннотаций, класс выглядит красивше :)Субъективное, очевидно.
Блин, написал комментарий, проскроллил выше, чтобы поставить "минус", а я там как будто уже ткнул статье "плюс" ... wtf? Рука соскользнула? 😂
Прям коробит, когда люди навешивают к
@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 ответственностями — не очень хорошая :)