Я лежу с температурой, поэтому у меня есть свой взгляд на вселенную:
1) Я согласен, что она дискретна, и это конечный автомат, в котором все частицы это устойчивые структуры.
2) Я могу описать гравитацию. Это вычислительная мощность в какой-то области. Очевидно, что вселенная рассчитывается параллельно, но там, где больше материи (единичек) -- там подсчет сильнее "тормозит" и поэтому кажется, что время идёт медленнее.
3) Раз гравитация притягивает объекты, значит в алгоритм входит учёт скорости расчета соседних областей. Где медленнее (больше масса), туда просто сваливаются мелкие частицы.
4) Возможно, что в какой-то момент вселенная была заполнена каким-то паттерном. Может это были начальные условия, а может быть так случилось, что она им заполнялась по какой-то причине. Возможно, этот паттерн соответствует нестабильному состоянию, которое через какое-то время массово перешло в другое (не хочу говорить, что из одного места, а повсюду). Вот он наш Большой взрыв.
5) По мере эволюции от БВ а пространстве формировались те самые низкоуровневые устойчивые структуры, слеплялись, появлялись атомы. Но космос до сих пор наделён огромным количеством мусора, который может иногда собираться в что-то осмысленное. Вот вам эффект Казимира и тёмная энергия.
6) Трек структуры, которые формируют элементарные частицы, просто так сложилось, что условно стабильны на месте. Свет -- другая структура, которая двигается с максимальной скоростью, как глайдер. Точнее ассортимент структур под разные длины волн и Бог знает под что ещё.
Исключение должно идти в рамках контрактах, т.е. в API пакете. На моей практике, все такие случае были отловлены на этапе интеграционного тестирования на стенде тестирования.
Хорошо, если все, но теоретически ведь может какой-то неожиданный RuntimeException проскочить, или даже ... Error. Надеюсь, на клиентской стороне эта ситуация как-то обработается, а не бросит ClassNotFoundException.
В такой ситуации добавление grpc бессмысленна.
В такой, скорее, соглашусь. Если прижилось, значит удобно. Но очень часто бывает, когда пытаешься прикрутить что-то удобное самодельное в одном месте в другое место, возникают новые краевые кейсы, и оказывается, что решение ещё не дожато :)
А если на стороне клиента нет класса этого исключения?
В копилку к 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
Я лежу с температурой, поэтому у меня есть свой взгляд на вселенную:
1) Я согласен, что она дискретна, и это конечный автомат, в котором все частицы это устойчивые структуры.
2) Я могу описать гравитацию. Это вычислительная мощность в какой-то области. Очевидно, что вселенная рассчитывается параллельно, но там, где больше материи (единичек) -- там подсчет сильнее "тормозит" и поэтому кажется, что время идёт медленнее.
3) Раз гравитация притягивает объекты, значит в алгоритм входит учёт скорости расчета соседних областей. Где медленнее (больше масса), туда просто сваливаются мелкие частицы.
4) Возможно, что в какой-то момент вселенная была заполнена каким-то паттерном. Может это были начальные условия, а может быть так случилось, что она им заполнялась по какой-то причине. Возможно, этот паттерн соответствует нестабильному состоянию, которое через какое-то время массово перешло в другое (не хочу говорить, что из одного места, а повсюду). Вот он наш Большой взрыв.
5) По мере эволюции от БВ а пространстве формировались те самые низкоуровневые устойчивые структуры, слеплялись, появлялись атомы. Но космос до сих пор наделён огромным количеством мусора, который может иногда собираться в что-то осмысленное. Вот вам эффект Казимира и тёмная энергия.
6) Трек структуры, которые формируют элементарные частицы, просто так сложилось, что условно стабильны на месте. Свет -- другая структура, которая двигается с максимальной скоростью, как глайдер. Точнее ассортимент структур под разные длины волн и Бог знает под что ещё.
Хорошо, если все, но теоретически ведь может какой-то неожиданный RuntimeException проскочить, или даже ... Error. Надеюсь, на клиентской стороне эта ситуация как-то обработается, а не бросит ClassNotFoundException.
В такой, скорее, соглашусь. Если прижилось, значит удобно. Но очень часто бывает, когда пытаешься прикрутить что-то удобное самодельное в одном месте в другое место, возникают новые краевые кейсы, и оказывается, что решение ещё не дожато :)
В VK:
В телеге:
А если на стороне клиента нет класса этого исключения?
В копилку к 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