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

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

Тебе уже много раз рассказали.

P>>Они нужны в момент, как и логи, во время запуска в тч на проде.
P>>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.
·>Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?!

Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант.
Условие ровно одно — проверяет свойства входа или результата. Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.

P>>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?
·>У той, которая прописана в precondition.

В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.

P>>Наоборот, именно это и важно.
·>Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер?

Надо же как то задетектить некорректный вызов. Есть простой вариант — deprecated вызов. Если все сходится к этому — это очень даже легко. Есть и более сложные, например, процессинг выдал варнинги, которых быть не должно, и в хидере x-варнинг будет ссылка на урл этих варнингов.

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

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

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

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

·>За счёт чего? Как выяснили выше, хедер добавляет 7 лишних шагов, приводя к тому же результату. Лишние шаги лишь добавляют к стоимости. Неясно на чём они экономят. В конце цепочки всё равно будет емейл разработчику-менеджеру.

Ты так и не рассказал, как будет без хидера

P>>Затем, что наши ассерты говорят о том, что у них чего то не то.
·>Пусть ваши ассерты хоть свежие анекдоты рассказывают. Так с какой целью вам нужно триггерить мониторинг на той стороне?

Что бы они приняли действия на своей стороне по исправлению проблемы.

P>>Ога, и так для тыщи консумеров.
·>Ты вначале расскажи, как ты будешь контролировать что делает мониторинг у тыщи консьюмеров.

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

P>>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.
·>Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка.

Забавно, что ты так и не показал, что будет в твоем случае. В основном эти 1-7 шагов благополучно работают.

P>>Что бы мониторинг на той стороне сработал.
·>Где гарантия, что он сработает? Где гарантия, что он не будет проигнорирован? Почему не подходят многие другие способы коммуникации?

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

·>Прикольно, оказывается в http есть хедер Warning. И, кто бы мог подумать, deprectated.

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

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

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

Тебе уже много раз рассказали.

P>>Они нужны в момент, как и логи, во время запуска в тч на проде.
P>>Например — выявить, если какаято из 2^100 комбинаций дала подозрительный результат.
·>Выявлять комбинации ассерты не могут в принципе. Ассерт может лишь выявить комбинацию, прописанную в precondition. Или у тебя в коде 2^100 ассертов?!

Могут, еще как. Это их основное предназначение. Сам же пишешь — выявить комбинацию прописаную в условии. Только не precondition, а postcondintion, и даже инвариант. И не сама комбинация прописывает, а её признаки. Условие ровно одно — свойства входа или результата. Например — контрольная сумма. Гыгы. Не сходится — с реквестом вероятно чтото не то. Логируем, выставляем варнинг и возвращаем респонс.

P>>Он проверяет свойство результата, например, или свойство входа. У какой из 2^100 комбинаций эти свойства будут нарушены?
·>У той, которая прописана в precondition.

В прекондишн прописано только условие. На этапе разработки ты эту комбинацию не знаешь.

P>>Наоборот, именно это и важно.
·>Важно для чего? Вопрос был — почему ассерт должен добавлять именно хедер?

Надо же как то задетектить некорректный вызов. Есть простой вариант — deprecated вызов. Если все сходится к этому — это очень даже легко. Есть и более сложные, например, процессинг выдал варнинги, которых быть не должно, и в хидере x-варнинг будет ссылка на урл этих варнингов.

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

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

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

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

·>За счёт чего? Как выяснили выше, хедер добавляет 7 лишних шагов, приводя к тому же результату. Лишние шаги лишь добавляют к стоимости. Неясно на чём они экономят. В конце цепочки всё равно будет емейл разработчику-менеджеру.

Ты так и не рассказал, как будет без хидера

P>>Затем, что наши ассерты говорят о том, что у них чего то не то.
·>Пусть ваши ассерты хоть свежие анекдоты рассказывают. Так с какой целью вам нужно триггерить мониторинг на той стороне?

Что бы они приняли действия на своей стороне по исправлению проблемы.

P>>Ога, и так для тыщи консумеров.
·>Ты вначале расскажи, как ты будешь контролировать что делает мониторинг у тыщи консьюмеров.

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

P>>В данном случае это скорее внешние консумеры. Коммуникация то отсутствует, разные подразделения, может оказаться так, что и доступа друг к другу не имеют вовсе. Т.е. разницы со внешними консумерами никакой. Пока менеджмент не договорится, должно быть решение.
·>Значит и их мониторинг вам неподконтролен. И какие-то из 1-7 шагов будут благополучно потеряны и забыты практически наверняка.

Забавно, что ты так и не показал, что будет в твоем случае. В основном эти 1-7 шагов благополучно работают, и именно потому, что легко автоматизируются и не требуют давать взятку менеджеру по security.

P>>Что бы мониторинг на той стороне сработал.
·>Где гарантия, что он сработает? Где гарантия, что он не будет проигнорирован? Почему не подходят многие другие способы коммуникации?

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

·>Прикольно, оказывается в http есть хедер Warning. И, кто бы мог подумать, deprectated.

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