Здравствуйте, ·, Вы писали:

P>>·>Они решают проблемы как минимум не хуже, чем хедеры. А по некоторым параметрам — значительно лучше.
P>>Ты так и не показал весь цикл решения проблем. Собственно, ты только повторяешь мантру "лучше иначе", "емейлы решают все проблемы"
·>Показал на основе твоих показаний. Я подытожил, что в твоём цикле 8 шагов. Я объяснил, что большинство из этих шагов просто лишние, их можно просто выбросить.

Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.

P>>А я её и не знаю на момент добавления такого кода. В этом и цель — сделать так, что бы
·>Что же твой код делает? Монетку подбрасывает?

Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.

P>> в логах появилась нужная мне инфа в тех случаях, которые недоступны в тестах.
·>Вот именно. Если ты плохо понимаешь поведение твоего кода, то добавляешь _логи_, чтобы их потом анализировать и изучать поведение _твоего_ кода. И это твоя проблема и забота.

Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.

> Зачем это передавать куда-то по хедерам наружу?

Затем, что во время процессинга возникли варнинги и вызывающей стороне хорошо бы быть в курсе дел.

P>>Не надо вилять — покажи как ты будешь ту самую комбинацию искать тестами. Ты же утверждаешь, что де все известно на момент написания кода. Вот и покажи это.
·>Ты вначале покажи как ты будешь искать "ту самую" комбинацию хедерами.

Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.

P>>ты в очередной раз увиливаешь. assert это про варнинги, в т.ч. Сработал ассерт — можно/нужно рендерить варнинг.
·>if(!precondition) LOGGER.warn("Hm... Please check that!!"); это ассерт или лог?

Ассерт это это if + log.

P>>И это не гарантирует нахождение ошибки, всего лишь повышает вероятность обнаружения.
·>А что _гарантирует_ нахождение ошибки? Неужели хедер?!

Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.

P>>Ассерт это далеко не всегда фатальное исключение. Иногда это просто странный кейс.
·>По крайней мере в c++/java/c#/python — всегда. Даже не припомню где это не так.

Ты извини, но это снова про твой кругозор.

·>Может быть "плохой" и совокупность нескольких запросов, и, даже, отсутствия неких нужных запросов. В какие хедеры пихать такие варнинги совсем неясно.

Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет

P>>Ну да — городить огород. "слежение за анонсами" как правило трудно применить к конкретному коду — разработчики уже заняты чем то другим, а может и уволились,
·>Т.е. то что вы пишете корявые анонсы гарантирует, что вы сделаете идеальные хедеры. Так что-ли?

Цитирую себя:
"разработчики уже заняты чем то другим, а может и уволились"
Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.

P>>а команда эксплуатации не имеет глубоких знаний по внутренностям продукта.
·>Ага. Увидела команда эксплуатации "X-Warning: unexpected input" хедер и так всё сразу ясно стало.

Ну вот в компиляторе ты часто видишь подобные варнинги?

P>>Мы пока так и не узнали, какую альтернативу ты предлагаешь, кроме как спамить емейлами.
·>Не спамить хедерами.

Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд

P>>Административные проблемы как были, так и остались. Зато хидер работает всегда, вне зависимости, читаешь ты емейлы или нет.
·>Емейлы тоже работают всегда, вне зависимости читаешь ты их или нет.

В том то и дело, что емейлы работают только если
1 если их читают все кому нужно
2 вовремя
3 и после чтения емейла точно известны последствия конкретно в твоем продукте

Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.

P>>Как ты узнаешь, что мелкое изменение на твоей стороне будет супер-критичным для 1й из 100 команд?
·>По нашим логам/мониторингу/етс. Это наша обязанность делать impact analysis.

Правильно понимаю, для этого вы анализируете код всех 100...1000 консумеров доступа к которому у вас нет?
Ну вот консумер ждет единственную страницу, а вы ему кидаете только первую страницу. Раньше то была одна, но теперь вы взяли другой квери-процессор и результатов стало больше.
Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?

P>>Даже если они увидели — они то не в курсе, на что ваш фикс вообще повлиять может.
·>Наша обязанность. Если мы "пропустили", то это наш факап и наш мониторинг должен сработать и мы должны фиксить срочно.

Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?

P>>Ты адекватен? Я же тебе сказал, что это на раз прикручивается к мониторингу. Ты уже ударился в юродствование. Какой в этом смысл?
·>Непонятно в чём заслуга хедеров-то? Чем с технической т.з. мониторинг хедеров отличается от мониторинга логов или даже емейлов?

Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
Если у нас нет такого поля в пейлоаде, что чаще всего и будет, то единственный вариант для хттп это хидер.

·>Это закон природы такой что-ли? Можно разные адреса заводить, можно тикеты в джире. В конце концов мониторинг может технически и по smpt ходить и на дашборд варнинги выкидывать.

Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?

P>>А вот то, что происходит прямо сейчас всегда будет намного актуальнее.
·>Если что-то происходит в проде, то это уже эпик фейл.

ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.

P>>В той или иной степени эта проблема есть у большинства корпораций. Она административной природы и решить её одномоментно не выйдет. А раз так, то все завязаные на емейлы методы будут регулярно давать сбой.
·>Да, об этом я и говорю. Проблема административная, и техническими средствами не решается. Хедер — техническое средство.

Успокойся — все административные проблемы так или иначе решаются техническими средствами. Например, ты скажешь использовать рассылку. Упс — рассылка это техническое средство.
Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
Скажет, что чрез транспорт реквеста — будет решаться через хидеры.

И вот у решения с хидерами есть куча преимуществ перед емейлом — а именно, человеческий фактор исключается почти полностью. Остаётся только кейс злонамеренного игнорирования.

P>>Мониторинг никогда никуда не переносится, за ним следят 24/7
·>А что мешает следить за емейлами 24/7? Более того, следить за системой мониторинга надо квалифицированных спецов сажать. А за аутлук можно хоть школьника посадить.

Я ж тебе пример привел — продуктовую команду разогнали, и остался только L2, который один на все сервисы. Ну прочитали они, что какой то компонент пофиксал баг в парсере адреса. Дальше что, как им понять, на какие из 100...1000 проектов на проде это повлияет?

·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.

Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.

·>Я не забыл, это ты запутался с своей софистике. Речь была "решать всё быстро тк они несут убыток". Несут убыток — это значит проблема в проде, что-то отвалилось. Или у вас ваш варнинг-хедер платный?

Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.

·>Я имею в виду логи на нашей стороне. К логам консьюмера часто доступа нет вообще, никакого. И как им что-то указать в их логах — я даже не представляю.

Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет

> Где они, в каком формате, кто имеет доступ? Да хз! Они вообще их могут сломать или потерять. А нам пофиг, у нас свои логи есть и мы им всё можем на блюдечке с каёмочкий показать и цветами нужные места разукрасить.

Твои логи никто не отменял, и changelog никто не отменял.

·>Впрочем, опять не аргумент. Ничто не мешает емейл-рассылку или джиру или ещё чего сделать внутренним стандартом. В чём преимущество хедера-то?

Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены. Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет

Здравствуйте, ·, Вы писали:

P>>·>Они решают проблемы как минимум не хуже, чем хедеры. А по некоторым параметрам — значительно лучше.
P>>Ты так и не показал весь цикл решения проблем. Собственно, ты только повторяешь мантру "лучше иначе", "емейлы решают все проблемы"
·>Показал на основе твоих показаний. Я подытожил, что в твоём цикле 8 шагов. Я объяснил, что большинство из этих шагов просто лишние, их можно просто выбросить.

Ты заменил их на емейлы, которые ненадежны по своей природе. То есть, надо ждать регулярных фейлов.

P>>А я её и не знаю на момент добавления такого кода. В этом и цель — сделать так, что бы
·>Что же твой код делает? Монетку подбрасывает?

Это уже не важно. Главное, что ассерты и тесты это немного разные классы задач, которые всего лишь пересекаются.

P>> в логах появилась нужная мне инфа в тех случаях, которые недоступны в тестах.
·>Вот именно. Если ты плохо понимаешь поведение твоего кода, то добавляешь _логи_, чтобы их потом анализировать и изучать поведение _твоего_ кода. И это твоя проблема и забота.

Неверно. Речь о проблемах во входных данных. Ровно как с компилятором — подкидываешь ему код, а он кидает тебе результат + варнинги.
Варнинги это информация о качестве результата, нужна вызывающей стороне в первую очередь.

> Зачем это передавать куда-то по хедерам наружу?

Затем, что во время процессинга возникли варнинги и вызывающей стороне хорошо бы быть в курсе дел.

P>>Не надо вилять — покажи как ты будешь ту самую комбинацию искать тестами. Ты же утверждаешь, что де все известно на момент написания кода. Вот и покажи это.
·>Ты вначале покажи как ты будешь искать "ту самую" комбинацию хедерами.

Не стоит валять дурака — здесь была речь о том, что ты не в курсе ассертов. И я показал как это искать ассертами.

P>>ты в очередной раз увиливаешь. assert это про варнинги, в т.ч. Сработал ассерт — можно/нужно рендерить варнинг.
·>if(!precondition) LOGGER.warn("Hm... Please check that!!"); это ассерт или лог?

Ассерт это это if + log.

P>>И это не гарантирует нахождение ошибки, всего лишь повышает вероятность обнаружения.
·>А что _гарантирует_ нахождение ошибки? Неужели хедер?!

Ассерты при правильном применении детектят определенные классы проблем, которые не обнаруживаются тестами.

P>>Ассерт это далеко не всегда фатальное исключение. Иногда это просто странный кейс.
·>По крайней мере в c++/java/c#/python — всегда. Даже не припомню где это не так.

Ты извини, но это снова про твой кругозор.

·>Может быть "плохой" и совокупность нескольких запросов, и, даже, отсутствия неких нужных запросов. В какие хедеры пихать такие варнинги совсем неясно.

Да тебе похоже ясно только как емейлы слать, которые не то читают, не то нет

P>>Ну да — городить огород. "слежение за анонсами" как правило трудно применить к конкретному коду — разработчики уже заняты чем то другим, а может и уволились,
·>Т.е. то что вы пишете корявые анонсы гарантирует, что вы сделаете идеальные хедеры. Так что-ли?

Цитирую себя:
"разработчики уже заняты чем то другим, а может и уволились"
Т.е. все ложится на команду эксплуатации. Им что, следить за всеми анонсами всех сервисов? Эдак придется штат раз в десять раздуть.

P>>а команда эксплуатации не имеет глубоких знаний по внутренностям продукта.
·>Ага. Увидела команда эксплуатации "X-Warning: unexpected input" хедер и так всё сразу ясно стало.

Ну вот в компиляторе ты часто видишь подобные варнинги?

P>>Мы пока так и не узнали, какую альтернативу ты предлагаешь, кроме как спамить емейлами.
·>Не спамить хедерами.

Не ясно, что конкретно ты предлагаешь, какой флоу и что делать, если емейл опоздал, затерялся, итд

P>>Административные проблемы как были, так и остались. Зато хидер работает всегда, вне зависимости, читаешь ты емейлы или нет.
·>Емейлы тоже работают всегда, вне зависимости читаешь ты их или нет.

В том то и дело, что емейлы работают только если
1 если их читают все кому нужно
2 вовремя
3 и после чтения емейла точно известны последствия конкретно в твоем продукте

Если п1 еще можно как то гарантировать, то 2 случается не так уж часто, а 3 это вообще какая то магия.

P>>Как ты узнаешь, что мелкое изменение на твоей стороне будет супер-критичным для 1й из 100 команд?
·>По нашим логам/мониторингу/етс. Это наша обязанность делать impact analysis.

Правильно понимаю, для этого вы анализируете код всех 100...1000 консумеров доступа к которому у вас нет?
Ну вот консумер ждет единственную страницу, а вы ему кидаете только первую страницу. Раньше то была одна, но теперь вы взяли другой квери-процессор и результатов стало больше.
Каким образом анализируя ваши логи/мониторинг вы узнаете, что у него случится denial of service ?

P>>Даже если они увидели — они то не в курсе, на что ваш фикс вообще повлиять может.
·>Наша обязанность. Если мы "пропустили", то это наш факап и наш мониторинг должен сработать и мы должны фиксить срочно.

Что фиксить? Проблема на вызывающей стороне, у них ожидания не соответствуют вашему апи. Начнешь перепиливать апи, что бы угодить всем?

P>>Ты адекватен? Я же тебе сказал, что это на раз прикручивается к мониторингу. Ты уже ударился в юродствование. Какой в этом смысл?
·>Непонятно в чём заслуга хедеров-то? Чем с технической т.з. мониторинг хедеров отличается от мониторинга логов или даже емейлов?

Технически — ничем. Главное, что бы ихний мониторинг сработал. Варнинг — это дополнительная фича АПИ, когда мы передаем информацию о качестве результата.
Если у нас нет такого поля в пейлоаде, что чаще всего и будет, то единственный вариант для хттп это хидер.

·>Это закон природы такой что-ли? Можно разные адреса заводить, можно тикеты в джире. В конце концов мониторинг может технически и по smpt ходить и на дашборд варнинги выкидывать.

Предлагаешь на миллион запросов создавать миллион тикетов в джыре? Или писать AI который будет фильтровать, тот ли это баг или не тот?

P>>А вот то, что происходит прямо сейчас всегда будет намного актуальнее.
·>Если что-то происходит в проде, то это уже эпик фейл.

ну да, ты то без багов пишешь, я помню — у тебя баги на прод не попадают.

P>>В той или иной степени эта проблема есть у большинства корпораций. Она административной природы и решить её одномоментно не выйдет. А раз так, то все завязаные на емейлы методы будут регулярно давать сбой.
·>Да, об этом я и говорю. Проблема административная, и техническими средствами не решается. Хедер — техническое средство.

Успокойся — все административные проблемы так или иначе решаются техническими средствами. Например, ты скажешь использовать рассылку. Упс — рассылка это техническое средство.
Единственное, что делает менеджмент, это принятие решений, как именно будет решаться та, или иная проблема. Скажет решать емейлами — будет решаться емейлами.
Скажет, что чрез транспорт реквеста — будет решаться через хидеры.

И вот у решения с хидерами есть куча преимуществ перед емейлом — а именно, человеческий фактор исключается почти полностью. Остаётся только кейс злонамеренного игнорирования.

P>>Мониторинг никогда никуда не переносится, за ним следят 24/7
·>А что мешает следить за емейлами 24/7? Более того, следить за системой мониторинга надо квалифицированных спецов сажать. А за аутлук можно хоть школьника посадить.

Я ж тебе пример привел — продуктовую команду разогнали, и остался только L2, который один на все сервисы. Ну прочитали они, что какой то компонент пофиксал баг в парсере адреса. Дальше что, как им понять, на какие из 100...1000 проектов на проде это повлияет?

·>Технически емейл от хедера в данном отличается лишь протоколом, smtp vs http. У хедеров ровно те же административные проблемы.

Не только. хедер лежит вместе с респонзом, request-id и прочими вещами, не надо никаких приседаний, что бы начать инвестигейт.

·>Я не забыл, это ты запутался с своей софистике. Речь была "решать всё быстро тк они несут убыток". Несут убыток — это значит проблема в проде, что-то отвалилось. Или у вас ваш варнинг-хедер платный?

Проблема на их части продакшна, что очевидно. Вот и нужно максимально быстро сигнализировать именно на той части.

·>Я имею в виду логи на нашей стороне. К логам консьюмера часто доступа нет вообще, никакого. И как им что-то указать в их логах — я даже не представляю.

Вот-вот. Ты то хвастался, что impact analysis делаешь, а однако никаких средств у тебя на то нет

> Где они, в каком формате, кто имеет доступ? Да хз! Они вообще их могут сломать или потерять. А нам пофиг, у нас свои логи есть и мы им всё можем на блюдечке с каёмочкий показать и цветами нужные места разукрасить.

Твои логи никто не отменял, и changelog никто не отменял.

·>Впрочем, опять не аргумент. Ничто не мешает емейл-рассылку или джиру или ещё чего сделать внутренним стандартом. В чём преимущество хедера-то?

Емейл как стандарт работает плохо — майлбоксы у ключевых людей как правило переполнены. Джира получше, только создавать тикет надо не в твоей джире, а на той стороне, куда у тебя доступа нет