Статистически, для гарантированного развития алкогольной болезни печени мужчинам надо употреблять около 70 г чистого этанола в день в течение 8 лет, в то время как женщинам — всего 20 г. Это примерно 150 мл водки, либо 500 мл сухого вина или 1000 мл пива.
По ссылке написано прямо обратное
При злоупотреблении спиртными напитками в гепатотоксичных дозах далеко зашедшие стадии АБП (выраженный фиброз и цирроз печени) формируются лишь у 10 - 20% пациентов [2,3], что отражает влияние ряда других факторов (генетических, стиля приема алкоголя и т.д.) на прогрессирование поражения печени
Не собираясь ввязываться в дискуссию, не могу тем не менее не заметить, что вот это
По пунктам - на сегодняшний день я не видел в общем доступе ни одной современной адекватной литературы, популярного выступления, признания проблемы или просто полноценной и качественной лекции по следующим вопросам:
…Какая минимальная частота для сенсоров необходима? …Какие могут быть допуски погрешности определения дистанции?
и т.д. — аргумент примерно уровня «ваши ГМО-овощи недостаточно исследованы». А что, кто-то замерил, какая погрешность определения дистанции у кожаных мешков? Или кто-то посчитал, сколько ложно-позитивных препятствий видят человеки?
Беспилотный автомобиль не должен демонстрировать каких-то частот и допусков — беспилотный автомобиль должен водить лучше живого человека, причём в очень конкретных цифрах — количество аварий на километр пробега.
CRBT — несомненно, очень красивая концепция. У неё есть одна проблема — она к реальному миру лишь частично. В реальном мире нетранзитивные изменения всегда есть, в какую обёртку их ни заворачивай.
Приведу пример, опираясь на всю тот же кейс заказа кофе. Допустим, пользователь создал заказ на 200 мл капучино, а потом с двух разных устройств отредактировал его — на одном выставил 400 мл, на другом 500 мл.
Логика CRBT диктует нам, что для транзитивности этих изменений нужно представить их не как абсолюты, а как транзитивные изменения — +200 и +300 мл соответственно. И результат мержа двух операций тогда — 700 мл капучино. Но как бы здравый смысл подсказывает нам, что вот чего пользователь не хотел абсолютно точно, так это 700 мл капучино.
Мы даже можем дать ему интерфейс, в котором он не может выбрать цифру, а только жать кнопки +100 / -100, и формально мы тогда сможем применить CRBT-формат. Но в реальном мире ситуация не изменилась: пользователь абсолютно точно не хотел сделать «+100» — он хотел выставить объём, а наши транзитивные операции генерировал просто потому, что другой возможности ему не предоставили.
В частности, 2022-09-19 16:46:00 — валидная дата с т.з. RFC 3339, но невалидная с т.з. ISO8601. Запись 2022-09-19T16:46:00-00:00 валидна с т.з RFC, но невалидна с т.з. ISO
Там, где речь идёт о деньгах, обычно лучше передать с клиента ту цифру, которую клиент видел глазами (напрямую в виде значения, или закодированную в offer_id) и валидировать её на сервере. Потому что между этими двумя моментами (клиент видел цифру стоимости доставки — клиент подтвердил заказ) что-то могло измениться (закончилась скидка, увеличился сурж), и клиент будет неприятно удивлён.
Два пользователя изменили в оффлайне одно и то же поле одного и того же объекта (поправили описание товара, например). Как такой формат патчей поможет "перебазировать" изменения не потеряв изменения?
Никак. Чудес не присходит. Вопрос в том, как применить изменения, если пользователи патчили разные поля.
А если стоимость заказа меньше 9000, то в качестве delivery_fee и total клиент сможет указывать любое положительное число? Скажите же скорее адрес этого магазина - скуплю его за бесценок.
Так этот "конец транзакции" применяет её или отменяет?
В тексте не transaction, а transition. Если существует двусмысленность (любого из терминов), следует выбрать не-двусмысленный вариант (для обоих терминов).
Во-вторых, независимо от отсутствия / наличия единого стандарта, даты в интернете вы можете получить в каком угодно виде. См. вторую часть фразы — «Исключения возможны только там, где вы на 100% уверены, что в мире существует только один стандарт для этой сущности, и всё население земного шара о нём в курсе.»
И что хорошего в запросе данных некешируемым методом создания ресурса?
POST не является методом создания ресурса. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
В вопросе кэширования результатов «тяжёлых» вычислений нас интересует прежде всего серверный кэш, а не клиентский, правда же? Доступ к нему вполне можно и через POST организовать — вновь вопрос того, что мы считаем важным: индицировать семантику операции (вы запускаете сложный алгоритм) или сэкономить какие-то байты на клиентском кэшировании.
Наконец, результаты POST могут кэшироваться (хотя я лично не рекомендую это делать), см. тот же RFC.
Почему хорошо удалять заказ неидемпотентным методом создания ресурса?
POST не является методом создания ресурса. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
То, что метод может быть неидемпотентным не означает, что он обязан быть идемпотентным (как раз наоборот, далее в тексте предлагается все методы обязательно делать идемпотентными). POST здесь используется именно для того, чтобы соответствовать процитированной семантике HTTP-методов согласно RFC. `PUT /orders/{id}/cancellation` тоже допустим.
По ссылке написано прямо обратное
Всё как с кожаными водителями, ага. Те, говорят, вообще права покупают.
Не собираясь ввязываться в дискуссию, не могу тем не менее не заметить, что вот это
и т.д. — аргумент примерно уровня «ваши ГМО-овощи недостаточно исследованы». А что, кто-то замерил, какая погрешность определения дистанции у кожаных мешков? Или кто-то посчитал, сколько ложно-позитивных препятствий видят человеки?
Беспилотный автомобиль не должен демонстрировать каких-то частот и допусков — беспилотный автомобиль должен водить лучше живого человека, причём в очень конкретных цифрах — количество аварий на километр пробега.
Чем это отличается от обычного PATCH тогда, хочется поинтересоваться, и к чему весь этот разговор.
CRBT — несомненно, очень красивая концепция. У неё есть одна проблема — она к реальному миру лишь частично. В реальном мире нетранзитивные изменения всегда есть, в какую обёртку их ни заворачивай.
Приведу пример, опираясь на всю тот же кейс заказа кофе. Допустим, пользователь создал заказ на 200 мл капучино, а потом с двух разных устройств отредактировал его — на одном выставил 400 мл, на другом 500 мл.
Логика CRBT диктует нам, что для транзитивности этих изменений нужно представить их не как абсолюты, а как транзитивные изменения — +200 и +300 мл соответственно. И результат мержа двух операций тогда — 700 мл капучино. Но как бы здравый смысл подсказывает нам, что вот чего пользователь не хотел абсолютно точно, так это 700 мл капучино.
Мы даже можем дать ему интерфейс, в котором он не может выбрать цифру, а только жать кнопки +100 / -100, и формально мы тогда сможем применить CRBT-формат. Но в реальном мире ситуация не изменилась: пользователь абсолютно точно не хотел сделать «+100» — он хотел выставить объём, а наши транзитивные операции генерировал просто потому, что другой возможности ему не предоставили.
В частности,
2022-09-19 16:46:00— валидная дата с т.з. RFC 3339, но невалидная с т.з. ISO8601. Запись2022-09-19T16:46:00-00:00валидна с т.з RFC, но невалидна с т.з. ISOCRDT и представляют формат описания атомарных изменений, в точности как в тексте описано.
Может фиксируется, а может и нет. Оффер может содержать все параметры заказа, а может просто валидировать, что клиент их не поменял.
Нет.
Нет.
С трудом себе это представляю. Если я анимировал положение элемента, то отменить это действие как если б его не было уже не получится.
Там, где речь идёт о деньгах, обычно лучше передать с клиента ту цифру, которую клиент видел глазами (напрямую в виде значения, или закодированную в offer_id) и валидировать её на сервере. Потому что между этими двумя моментами (клиент видел цифру стоимости доставки — клиент подтвердил заказ) что-то могло измениться (закончилась скидка, увеличился сурж), и клиент будет неприятно удивлён.
Никак. Чудес не присходит. Вопрос в том, как применить изменения, если пользователи патчили разные поля.
Действительно, URL должен быть `PUT /v1/orders/drafts/{draft_id}/confirm`. Поправлю, спасибо.
Я не обсуждаю здесь детали технической имплементации.
Я не понял этого комментария.
В тексте не transaction, а transition. Если существует двусмысленность (любого из терминов), следует выбрать не-двусмысленный вариант (для обоих терминов).
Во-первых, это неправда. Есть ещё как минимум RFC 3339 https://www.rfc-editor.org/rfc/rfc3339 и RFC 7231 https://www.rfc-editor.org/rfc/rfc7231#section-7.1.1.1
Во-вторых, независимо от отсутствия / наличия единого стандарта, даты в интернете вы можете получить в каком угодно виде. См. вторую часть фразы — «Исключения возможны только там, где вы на 100% уверены, что в мире существует только один стандарт для этой сущности, и всё население земного шара о нём в курсе.»
POST не является методом создания ресурса. «The POST method requests
that the target resource process the representation enclosed in the
request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
В вопросе кэширования результатов «тяжёлых» вычислений нас интересует прежде всего серверный кэш, а не клиентский, правда же? Доступ к нему вполне можно и через POST организовать — вновь вопрос того, что мы считаем важным: индицировать семантику операции (вы запускаете сложный алгоритм) или сэкономить какие-то байты на клиентском кэшировании.
Наконец, результаты POST могут кэшироваться (хотя я лично не рекомендую это делать), см. тот же RFC.
Тот, который указан в теле запроса
POST не является методом создания ресурса. «The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics» — https://www.rfc-editor.org/rfc/rfc7231#page-25
То, что метод может быть неидемпотентным не означает, что он обязан быть идемпотентным (как раз наоборот, далее в тексте предлагается все методы обязательно делать идемпотентными). POST здесь используется именно для того, чтобы соответствовать процитированной семантике HTTP-методов согласно RFC. `PUT /orders/{id}/cancellation` тоже допустим.