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

P>>·>Ассерты тут вообще непричём. Я пытаюсь разобраться зачем нужен этот хедер. Но ты всё время куда-то в сторону уводишь разговор.
P>>Тебе уже много раз рассказали.
·>Рассказано текущее положение дел у вас, а не обоснование чем такое решение лучше, чем альтернативы.

Ты альтернативу так и не показал, кроме "у нас есть рассылки" Рассылки сами все проблемы порешают?

P>>Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата.
·>Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.

Ну вот. А где здесь та самая комбинация и как её узнать на момент тестирования?

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

Теоретически. А вот практически этот вариант не всегда реализуем, т.к. всегда будут какие нибудь варнинги.

P>>В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.
·>Если ты эту комбинацию не знаешь, ты не сможешь написать Warning.assert(precondontion, 'unexpected input').

Минутка ликбеза:
Вот у нас есть код, сумма — это что бы условие задачи упростить, синтетический пример — говорю заранее, т.к. ты щас начнешь придираться к словам.

function sum(a, b) {
  // код этой функции для тебя не виден, включи изображение
  // то есть, тот самый чОрный ящик
  if(a == randomInt(1000000000)) return 100; // симулируем баг с нестабильным поведением
  if(b == randomInt(1000000000)) return 200; // симулируем баг с нестабильным поведением

  return a + b;     
}

assert выдаст в лог, что посткондишн не сходится, и напечает тебе и а, и b.
Например assert(() => a+b == result, a, b);

А теперь твой ход — покажи, как ты подобную багу будешь искать тестами.

·>Перечитай вопрос внимательно. Почему именно хедер? Например, пусть ваш мониторинг аггрится на ERROR в логах и шлёт емейлы кому положено, напрямую. Зачем эти промежуточные слои через rest, чужой мониторинг, чужой L2 и т.п.?

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

P>>Например, потому что это самый простой и дешевый способ разграничить ответственность. Вкомитал вызов согласно этому АПИ — теперь отвечай сам за корректность запросов.
·>Некорректные запросы надо просто реджектить. Давай другой пример.

Пример тебе не нравится — это уже твои проблемы.

P>>Ага, в ответ на "escalate" прибегает архитектор, и говорит "делай хидер с варнингом, мне так приказали сверху, теперь всё апи будет таким."
·>Т.е. у вас так принято, культ карго. Так бы сразу и сказал.

Рашение административных проблем как правило занимает много времени, бывает даже годы, пока выработается и стабилизируется конкретный процесс.
А решение нужно прямо сейчас.

P>>Ты так и не рассказал, как будет без хидера
·>Сказал. После 0го шага идёт сразу 8й.

Это детские отписки. Поскольку ты закладываешься на емейл, слишком велик шанс что прочитают с запозданием. И на этот случай у тебя решения как не было, так и нет.

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

Ты, похоже, не читаешь. Емейл слишком ненадежный канал. При условии, что люди относятся к обязанностям добросовестно, емейл не дает никаких гарантий — срочная работа на выезде, воркшоп, командировка, отпуск, итд итд. Упс — прочитали, но неделю спустя. Еще момент — человек просто устал и пропустил тот самый емейл.
А вот на звоночек в мониторинге реагируют очень быстро, и L2 суппорт в состоянии купировать большинство проблем.

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

Ты усиленно игнорируешь всё, что я пишу про емейлы. Какой в этом смысл?

·>Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.

Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?

·>Если они могут обеспечить, что ихние менеджеры не игнорируют емейлы от L2, то они смогут обеспечить, чтобы ихние менеджеры не игнорировали емейлы от вас. А если нет, то и хедеры не помогут. Вывод — хедер — лишняя сущность.

А почему ты решил, что коммуникация L2 и менеджеров идет по емейлам? Я вроде пишу почти что противоположное.

P>>Зато при траблшутниге, если их L2 суппорт придет ко мне, мне достаточно кидануть им одну ссылку, что бы они были в курсе, как починить.
·>Придёт так же в октябре. В чём разница-то?

При траблшутинге они заинтересованы решать всё быстро тк они несут убыток, и все вопросы решаются буквально голосом. Соответственно, мне не надо напоминать "а видели ли вы емейлы от нас полгода назад?"
Вместо этого "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию"
И дальше они справляются без меня. Моя цель в том и состоит, что бы предоставлять инструмент решения проблем, а не влазить в каждое из решений.
Искать, где чьи логи, это одна из проблем. Проще отфутболить тому, на чьей стороне косяк, пость он видит проблему в своих логах и своем мониторинге.
Тогда ихние L2 смогут разобраться самостоятельно, и будут эскалировать не абы куда, а именно тем людям кто в данный момент может лучше разрулить.

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

Тебе не нужно — ну не отправляй. Разве я тебя заставляю?

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

P>>·>Ассерты тут вообще непричём. Я пытаюсь разобраться зачем нужен этот хедер. Но ты всё время куда-то в сторону уводишь разговор.
P>>Тебе уже много раз рассказали.
·>Рассказано текущее положение дел у вас, а не обоснование чем такое решение лучше, чем альтернативы.

Ты альтернативу так и не показал, кроме "у нас есть рассылки" Рассылки сами все проблемы порешают?

P>>Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата.
·>Под precondition я имею в виду идентификатор из твоего кода: Warning.assert(precondontion, 'unexpected input'). Тебя опять куда-то унесло в оффтопик.

Ну вот. А где здесь та самая комбинация и как её узнать на момент тестирования?

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

Теоретически. А вот практически этот вариант не всегда реализуем, т.к. всегда будут какие нибудь варнинги.

P>>В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.
·>Если ты эту комбинацию не знаешь, ты не сможешь написать Warning.assert(precondontion, 'unexpected input').

Минутка ликбеза:
Вот у нас есть код, сумма — это что бы условие задачи упростить, синтетический пример — говорю заранее, т.к. ты щас начнешь придираться к словам.

function sum(a, b) {
  // код этой функции для тебя не виден, включи воображение
  // то есть, тот самый чОрный ящик
  if(a == randomInt(1000000000)) return 100; // симулируем баг с нестабильным поведением
  if(b == randomInt(1000000000)) return 200; // симулируем баг с нестабильным поведением

  return a + b;     
}

assert выдаст в лог, что посткондишн не сходится, и напечает тебе и а, и b.
Например assert(() => a+b == result, a, b);

А теперь твой ход — покажи, как ты подобную багу будешь искать тестами.

·>Перечитай вопрос внимательно. Почему именно хедер? Например, пусть ваш мониторинг аггрится на ERROR в логах и шлёт емейлы кому положено, напрямую. Зачем эти промежуточные слои через rest, чужой мониторинг, чужой L2 и т.п.?

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

P>>Например, потому что это самый простой и дешевый способ разграничить ответственность. Вкомитал вызов согласно этому АПИ — теперь отвечай сам за корректность запросов.
·>Некорректные запросы надо просто реджектить. Давай другой пример.

Пример тебе не нравится — это уже твои проблемы.

P>>Ага, в ответ на "escalate" прибегает архитектор, и говорит "делай хидер с варнингом, мне так приказали сверху, теперь всё апи будет таким."
·>Т.е. у вас так принято, культ карго. Так бы сразу и сказал.

Рашение административных проблем как правило занимает много времени, бывает даже годы, пока выработается и стабилизируется конкретный процесс.
А решение нужно прямо сейчас.

P>>Ты так и не рассказал, как будет без хидера
·>Сказал. После 0го шага идёт сразу 8й.

Это детские отписки. Поскольку ты закладываешься на емейл, слишком велик шанс что прочитают с запозданием. И на этот случай у тебя решения как не было, так и нет.

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

Ты, похоже, не читаешь. Емейл слишком ненадежный канал. При условии, что люди относятся к обязанностям добросовестно, емейл не дает никаких гарантий — срочная работа на выезде, воркшоп, командировка, отпуск, итд итд. Упс — прочитали, но неделю спустя. Еще момент — человек просто устал и пропустил тот самый емейл.
А вот на звоночек в мониторинге реагируют очень быстро, и L2 суппорт в состоянии купировать большинство проблем.

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

Ты усиленно игнорируешь всё, что я пишу про емейлы. Какой в этом смысл?

·>Да тоже самое. Оптимум — после 0го шага сразу 8й. Ну или 7й, может быть. Шаги 1-6 не нужны вообще.

Ну вот был воркшоп, чтение емейлов перенесли на завтра. Упс. Что делать?

·>Если они могут обеспечить, что ихние менеджеры не игнорируют емейлы от L2, то они смогут обеспечить, чтобы ихние менеджеры не игнорировали емейлы от вас. А если нет, то и хедеры не помогут. Вывод — хедер — лишняя сущность.

А почему ты решил, что коммуникация L2 и менеджеров идет по емейлам? Я вроде пишу почти что противоположное.

P>>Зато при траблшутниге, если их L2 суппорт придет ко мне, мне достаточно кидануть им одну ссылку, что бы они были в курсе, как починить.
·>Придёт так же в октябре. В чём разница-то?

При траблшутинге они заинтересованы решать всё быстро тк они несут убыток, и все вопросы решаются буквально голосом. Соответственно, мне не надо напоминать "а видели ли вы емейлы от нас полгода назад?"
Вместо этого "давайте глянем ваши логи... Видите — варнинг такой, следовательно, вам надо обновить вашу конфигурацию"
И дальше они справляются без меня. Моя цель в том и состоит, что бы предоставлять инструмент решения проблем, а не влазить в каждое из решений.
Искать, где чьи логи, это одна из проблем. Проще отфутболить тому, на чьей стороне косяк, пость он видит проблему в своих логах и своем мониторинге.
Тогда ихние L2 смогут разобраться самостоятельно, и будут эскалировать не абы куда, а именно тем людям кто в данный момент может лучше разрулить.

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

Тебе не нужно — ну не отправляй. Разве я тебя заставляю?