FIX все-таки для очень специфических задач используется. Для финансовых транзакций все несколько сложнее, есть куча разных протоколов, есть ISO 8583, есть ISO 20022, есть OpenBanking, но для реальных приложений они все избыточно универсальные, требуется их приземлять на конкретные кейсы. Но вообще для платежей обычно вместо ключей идемпотентности (описанных в статье) используются схема из двух шагов (авторизация и подтверждения), которые не сложнее в реализации, но дают и другие возможности.
На самом деле для решения задачи именно идемпотентность не нужна (и избыточно), достаточно безопасной повторяемости. И много неидемпотентных запросов являются вполне себе безопасно повторяемыми, например, getNextSequenceId. Но, конечно, тема безопасного повтора транзакций гораздо шире описанного в статье.
А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема. Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд. Другое дело, что скрам имеет смысл только для слабых команд, которые еще не умеют в автономность и самостоятельность.
Что такое "унарный REST"? В концепции REST ничего такого нет. Почитайте Филдинга. Или хотя бы Ричардсона. REST как концепция (т.е. REST level 2 и выше) предполагает работу с ресурсами с помощью стандартных операций, там нет никаких своих функций. Можно вообще сделать маппинг HTTP verbs прямо на SQL и сделать один хендлер на множество RESTовых ресурсов и это будет вполне корректно. В REST нет никаких функций.
Но да, часто любые вызовы по http называют REST, но это безграмотно и показывает, что автор не знает смысла используемых терминов.
Изначальный текст неплохой, но перевод местами очень кривой, еще и куча опечаток. Перевод лучше бы еще раз вычитать (или хотя бы один раз вычитать, а то есть ощущение, что переводили довольно плохим автопереводчиком, даже не ChatGPT4)
Не совсем. REST предполагает операции над ресурсами и первичны именно ресурсы, в RPC единицей является вызываемый метод. Так что все-таки это разные идеологии. Впрочем, автор статьи, конечно, ничего не знает ни о REST, ни о RPC.
Не надо описывать НФТ в виде user story. Тем более в user story обязательно должна быть мотивационная часть, иначе оно бесполезно. Все указанные в статье user story - таковыми не являются (
Ну, лучше вообще перед описанием ФТ провести EventStorming и сделать описание доменных моделей. То, что описано в статье - просто куча бесполезных строчек, никак не связано с описанием требований, увы.
Очень много сомнительных практик в этом шаблоне. Потеряна мотивация (а описание "зачем" - самое важное, что должен описывать аналитик), очень много техдизайна (плохо описанного) вместо требований, в описании НФТ нет вообще ни одного корректного пункта, нет ничего про UX (а задание на UX делается до задания для дизайнеров. Впрочем, задание для дизайна тоже предполагает бриф, про что не сказано ни слова). Надеюсь, ничего из этого шаблона реально в банке не используется.
Тут довольно мало про описание требований, разве что про User Story, да и то без мотивационной части (что делает их практически бесполезным). Описание API - это не требования, это техдизайн. Как и вообще все, что написано в главе "Бизнес-логика".
А зачем новичку, который даже OpenAPI не может освоить, пытаться описывать API? Проработка программных интерфейсов - сложная инженерная работа, без опыта работы хотя бы миддлом на бэке ее делать категорически не стоит (а по хорошему, это вообще должны писать инженеры, а не аналитики). И OpenAPI - это как раз про документацию, не про код.
Да, конечно, читал и конечно в оригинале. Нет, ресурс - это не запись в БД и не кортеж, это то, что может быть уникально идентифицировано. Иногда это несколько записей в БД (агрегат), иногда вообще не про БД, иногда это может быть отчетом (который не запись в БД, но вполне может идентифицироваться uri) или командой в процессе исполнения или много чем еще.
Мне не очень интересно рассматривать REST, он так же мало применим к реализации API (что, кстати, у Филдинга прямо написано), как и GQL. Тем более не интересно обсуждать какие-то фантазии на тему REST.
Советую все-таки почитать про REST, хотя бы диссертацию Филдинга, где вводится это понятие. И нет, REST никогда не отражение СУБД, он ни в коем случае не должен быть таковым. Ну и в реальности мало кто использует REST, чаще реально используется какой-то RPC с json-over-http, впрочем, это и правильно. Но там не будет никакого отражения СУБД )
FIX все-таки для очень специфических задач используется. Для финансовых транзакций все несколько сложнее, есть куча разных протоколов, есть ISO 8583, есть ISO 20022, есть OpenBanking, но для реальных приложений они все избыточно универсальные, требуется их приземлять на конкретные кейсы.
Но вообще для платежей обычно вместо ключей идемпотентности (описанных в статье) используются схема из двух шагов (авторизация и подтверждения), которые не сложнее в реализации, но дают и другие возможности.
На самом деле для решения задачи именно идемпотентность не нужна (и избыточно), достаточно безопасной повторяемости. И много неидемпотентных запросов являются вполне себе безопасно повторяемыми, например, getNextSequenceId.
Но, конечно, тема безопасного повтора транзакций гораздо шире описанного в статье.
Это скорее антиреклама )
У Huawei лучшие камеры при вменяемой цене. Я когда выбирал камерофон - долго смотрел на P60. Если бы был P70, то может и взял бы его, а не Oppo
Э, какой смысл сравнивать среднюю зарплату до налогов в США и медианную месячную после налогов в РФ?
А какой смысл на daily обсуждать проблемы, которые не могут быть решены командой? Если есть кто-то вне команды, кто может их решить - надо его и дергать, как появилась проблема.
Простой чат команды решает ту же задачу, но лучше и быстрее, для автономных команд. Другое дело, что скрам имеет смысл только для слабых команд, которые еще не умеют в автономность и самостоятельность.
Что такое "унарный REST"? В концепции REST ничего такого нет.
Почитайте Филдинга. Или хотя бы Ричардсона.
REST как концепция (т.е. REST level 2 и выше) предполагает работу с ресурсами с помощью стандартных операций, там нет никаких своих функций. Можно вообще сделать маппинг HTTP verbs прямо на SQL и сделать один хендлер на множество RESTовых ресурсов и это будет вполне корректно.
В REST нет никаких функций.
Но да, часто любые вызовы по http называют REST, но это безграмотно и показывает, что автор не знает смысла используемых терминов.
Изначальный текст неплохой, но перевод местами очень кривой, еще и куча опечаток.
Перевод лучше бы еще раз вычитать (или хотя бы один раз вычитать, а то есть ощущение, что переводили довольно плохим автопереводчиком, даже не ChatGPT4)
А какие еще варианты кроме скрама рассматривали?
И что именно внедрили - скрам или скрамбат?
Не совсем. REST предполагает операции над ресурсами и первичны именно ресурсы, в RPC единицей является вызываемый метод. Так что все-таки это разные идеологии. Впрочем, автор статьи, конечно, ничего не знает ни о REST, ни о RPC.
Не надо описывать НФТ в виде user story.
Тем более в user story обязательно должна быть мотивационная часть, иначе оно бесполезно. Все указанные в статье user story - таковыми не являются (
Ну, лучше вообще перед описанием ФТ провести EventStorming и сделать описание доменных моделей. То, что описано в статье - просто куча бесполезных строчек, никак не связано с описанием требований, увы.
Очень много сомнительных практик в этом шаблоне.
Потеряна мотивация (а описание "зачем" - самое важное, что должен описывать аналитик), очень много техдизайна (плохо описанного) вместо требований, в описании НФТ нет вообще ни одного корректного пункта, нет ничего про UX (а задание на UX делается до задания для дизайнеров. Впрочем, задание для дизайна тоже предполагает бриф, про что не сказано ни слова).
Надеюсь, ничего из этого шаблона реально в банке не используется.
Тут довольно мало про описание требований, разве что про User Story, да и то без мотивационной части (что делает их практически бесполезным).
Описание API - это не требования, это техдизайн. Как и вообще все, что написано в главе "Бизнес-логика".
А зачем новичку, который даже OpenAPI не может освоить, пытаться описывать API? Проработка программных интерфейсов - сложная инженерная работа, без опыта работы хотя бы миддлом на бэке ее делать категорически не стоит (а по хорошему, это вообще должны писать инженеры, а не аналитики).
И OpenAPI - это как раз про документацию, не про код.
По ссылке нет ни одного реального кейса.
Да, конечно, читал и конечно в оригинале.
Нет, ресурс - это не запись в БД и не кортеж, это то, что может быть уникально идентифицировано. Иногда это несколько записей в БД (агрегат), иногда вообще не про БД, иногда это может быть отчетом (который не запись в БД, но вполне может идентифицироваться uri) или командой в процессе исполнения или много чем еще.
Мне не очень интересно рассматривать REST, он так же мало применим к реализации API (что, кстати, у Филдинга прямо написано), как и GQL. Тем более не интересно обсуждать какие-то фантазии на тему REST.
Э, это что за реальный кейс, когда нужно грузить мегабайт вместо килобайта? Можешь привести реальный пример?
Не смог там найти никаких реальных проблем.
Советую все-таки почитать про REST, хотя бы диссертацию Филдинга, где вводится это понятие.
И нет, REST никогда не отражение СУБД, он ни в коем случае не должен быть таковым.
Ну и в реальности мало кто использует REST, чаще реально используется какой-то RPC с json-over-http, впрочем, это и правильно. Но там не будет никакого отражения СУБД )