Сообщение Re[45]: Идемпотентность POST - хорошая ли практика? от 07.10.2022 11:02
Изменено 07.10.2022 11:31 Pauel
Re[45]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>Очевидно — никакие. Дальше что?
·>Дальше работаем.
Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
P>>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
·>Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы?
Добавить правило в мониторинг это дело секунд.
> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?
О чем писать будешь, если тесты зелёные? Эй, ребята, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
P>>
ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?
·>Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.
Я уже несколько раз показал. А ты еще ни разу. У тебя какая то магия — changelog сделает всё сам за себя.
Варнинги появляются как обычно, это разновидность логирования, только рендерится и в респонс.
Итого — ты как решать будешь?
P>>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
·>Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.
Я пишу про мониторинг, а тебе мерещится "менеджер хидеры читает". Ты адекватен?
Как в твоем случае проблему обнаруживать будешь?
P>>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
·>Не дольше, чем искать для какой комбинации нужен варнинг.
Ты похоже не понял, что такое 2 в степени 100. Тестами ты гарантировано ничего такого не найдешь, т.к. прогон тестов закончится вместе с электричеством.
А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.
P>>Очевидно — никакие. Дальше что?
·>Дальше работаем.
Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
P>>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
·>Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы?
Добавить правило в мониторинг это дело секунд.
> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?
О чем писать будешь, если тесты зелёные? Эй, ребята, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
P>>
·>Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.
Я уже несколько раз показал. А ты еще ни разу. У тебя какая то магия — changelog сделает всё сам за себя.
Варнинги появляются как обычно, это разновидность логирования, только рендерится и в респонс.
Итого — ты как решать будешь?
P>>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
·>Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.
Я пишу про мониторинг, а тебе мерещится "менеджер хидеры читает". Ты адекватен?
Как в твоем случае проблему обнаруживать будешь?
P>>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
·>Не дольше, чем искать для какой комбинации нужен варнинг.
А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.
Re[45]: Идемпотентность POST - хорошая ли практика?
Здравствуйте, ·, Вы писали:
P>>Очевидно — никакие. Дальше что?
·>Дальше работаем.
Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
Ровно так же работают и логи, ассерты и многие вещи. Хидер нужен в том случае, что бы уведомить вызывающую сторону тем или иным способом. Например, если клиент предоставляешь свой собственный.
·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
P>>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
·>Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы?
Добавить правило в мониторинг это дело секунд. Все остальное — автоматически. В AWS это вообще мышом делается, накликал и будет анализировать логи/хидеры до скончания времён.
> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?
О чем писать будешь, если тесты зелёные? Эй, манагеры, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
P>>
ну написано в там — пофиксили уязвимость в парсере. твои тесты зелёные. Дальше что?
·>Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.
Я уже несколько раз показал. А ты еще ни разу. У тебя какая то магия — changelog сделает всё сам за себя.
Варнинги появляются как обычно, это разновидность ассертов/логирования, только рендерится и в респонс.
Итого — ты как решать будешь?
P>>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
·>Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.
Я пишу про мониторинг, а тебе мерещится "менеджер хидеры читает". Ты адекватен?
Как в твоем случае проблему обнаруживать будешь?
P>>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
·>Не дольше, чем искать для какой комбинации нужен варнинг.
Ты похоже не понял, что такое 2 в степени 100. Тестами ты гарантировано ничего такого не найдешь, т.к. прогон тестов закончится вместе с электричеством.
А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.
P>>Очевидно — никакие. Дальше что?
·>Дальше работаем.
Очевидно, ты проигнорировал проблему. А вот наличие варнингов можно словить мониторингом и зарепортать.
Ровно так же работают и логи, ассерты и многие вещи. Хидер нужен в том случае, что бы уведомить вызывающую сторону тем или иным способом. Например, если клиент предоставляешь свой собственный.
·>Это всё внутренняя кухня. Зачем это слать наружу, в каждом респонзе и засирать прод трафик-то? С учётом того, что консьюмеры это могут всё влёгкую игнорировать.
Внутренние консумеры не могут. А это бОльшая часть трафика. Внешние — тоже могут учитывать.
P>>"А так у нас сразу есть звоночек от мониторинга — на сервисах 0, 8, 124 варнинги, реквест-респонс прилагаются. дальше l2 разбирается, что откуда куда пришло, по трейсингу, и "
·>Ты обещал автоматически. Как автоматически появится такой мониторинг? И как ты убедишься, что этот мониторинг есть и выдаёт адекватные сигналы? Кто будет проверять эти сигналы?
Добавить правило в мониторинг это дело секунд. Все остальное — автоматически. В AWS это вообще мышом делается, накликал и будет анализировать логи/хидеры до скончания времён.
> Никакой автоматики я пока не вижу — всё придётся вручную сооружать, расставлять эти варнинги, майнтейнить, анализировать и... в итоге слать менеджерам письма, чтобы они на эти варнинги хоть как-то реагировали. Не проще ли сразу начать с писем?
О чем писать будешь, если тесты зелёные? Эй, манагеры, n*m зависимостей второго уровня чего то там поменяли, а вдруг у нас чтото не то?
P>>
·>Ты сценарий не с потолка бери, а начни с того, как тебе помогут варнинг-хедеры и каким образом они появятся _автоматически_ как ты обещаешь.
Я уже несколько раз показал. А ты еще ни разу. У тебя какая то магия — changelog сделает всё сам за себя.
Варнинги появляются как обычно, это разновидность ассертов/логирования, только рендерится и в респонс.
Итого — ты как решать будешь?
P>>С емейлами одна проблема — это в чистом виде человеческий фактора, например, потому что "устал, много писем, (не)прочитаю в понедельник"
P>>Я например регулярно сталкиваюсь с ситуацией , что какой либо менеджер не отвечает на письма. Думаешь если ему подкинуть еще сотню-другу емейлов, так он быстрее разгребется?
·>Ясно. Хедеры значит этот менеджер читает, а на емейлы сил уже не хватает.
Я пишу про мониторинг, а тебе мерещится "менеджер хидеры читает". Ты адекватен?
Как в твоем случае проблему обнаруживать будешь?
P>>Ну ок — реквест состоит из 100 переменных true-false, как долго будешь искать, какая же комбинация "та самая"?
·>Не дольше, чем искать для какой комбинации нужен варнинг.
А вот на проде, скажем, если поставишь Warning.assert(precondontion, 'unexpected input') то все значения будут проходит эту проверку, и все подозрительные будут зарепортаны.