А если на стороне клиента нет класса этого исключения?
В копилку к Feign добавлю нынешние Declarative HTTP Client-ы спринга встроенные.
Точно ли изучение вместо gRPC более лёгкого, но местечкового, инструмента даст коллегам возможность расти в отрасли, они же не до конца жизни на этом проекте? (это просто наброс на то, что достаточно ли это взвешенное решение, или принято под давлением нехватки компетенций).
Но ведь нет. Есть панель 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. Те два вровень идут, я им по влажности верю :)
А если на стороне клиента нет класса этого исключения?
В копилку к Feign добавлю нынешние Declarative HTTP Client-ы спринга встроенные.
Точно ли изучение вместо gRPC более лёгкого, но местечкового, инструмента даст коллегам возможность расти в отрасли, они же не до конца жизни на этом проекте? (это просто наброс на то, что достаточно ли это взвешенное решение, или принято под давлением нехватки компетенций).
По такой логике можно открывать юрлица для совершения любых преступлений, и тогда ты не преступник, а сотрудник?)
Согласен, не 100% очевидность.
Статья и половина комментариев о том, что в 2025 его больше нет.
Кажется, выше нашли другие галочки, которые решают именно мою проблему :)
А вот это интересно, кажется то, что именно мне нужно было ) Спасибо за наводку!
Но ведь нет. Есть панель 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