А почему использовали такой подход, а не подход Cadence/Temporal? Сценарии при этом получаются гораздо более удобные и понятные и не нужно думать лишний раз о компенсациях (которые вообще не очень обязательны в сагах и сильно усложняют использование, особенно если в компенсации случилась ошибка).
Не совсем корректно говорить, что в Kafka нет подтверждения доставки. Как раз гарантии доставки в Кафка есть, сообщение будет доставлено до consumer (если таковой вообще существует). Нет гарантии обработки, но их нет и в RabbitMQ и, насколько знаю, в NATS.
Возможно, стоило бы еще и сказать про реальную призводительность и надежность, где Kafka много лучше и RabbitMQ и NATS.
Гарантий доставки exactly once не существует. В Kafka так называется автоматическая дедупликация между producer и broker, но фактически consumer может читать данные много раз. В NATS, подозреваю, так же (так как exactly once физически нереализуемо в распределенных систем).
Ну и, насколько я понимаю, в таблице 3 млн. событий в секунду для NATS указано для режима без persistance, что делает эти числа бесполезными.
P.S. Текст выглядит как автоматический перевод. Если это так, то стоит указать оригинальный источник. Если нет, то стоит вычитать и поправить грамматические ошибки, их очень много.
Математика в ВУЗе (не всякая, не во всяком ВУЗе) кроме собственно "математики" очень сильно прокачивает умение работать со сложными формальными системами, с разными уровнями абстракции, с последовательным решением задач. И, как ни странно, именно эти навыки нужны при разработке от миддла и выше. Да, есть и другие способы научиться работать со сложными системами, но математика в хорошем ВУЗе - один из самых простых и быстрых способов. Так что математика - нужна. Но не сама математика, а то мышление, которое она тренирует.
Если бы на курсах преподавали опытные специалисты - то утверждение было бы правильным. Но большинство курсов нанимает себе преподавателей за цену стажеров, так что надеяться на какую-то осмысленную обратную связь не стоит. В лучшем случае это будет какой-то миддл, да и то не факт.
Ну, вообще прописывание технического дизайна - это работа как раз инженера-программиста. Если ей занимаются аналитики или лиды, то получается не очень (
Ну, если уж совсем занудствовать, то любой term подойдет внутри message, а так-то типизация сигналов очень даже есть (message/link/etc). Впрочем, системные сигналы можно и не считать
Набор матчингов в recieve - это как раз контракт процесса и определяет, какие сообщения он может получать. Отправлять другие сообщения - бесполезно. То, что типизация сообщений идет на pattern matching, а не на RTTI - не принципиально, все равно это про контракт и сообщения.
В эрланге у процессора дофига всякого (несколько очередей, например). Это точно несколько больше, что то, что обычно считают объектом.
Но это все, конечно, мелочи )
Ну и хотя акторные системы (среди которых далеко не только Эрланг) и являются примером ООП, но ООП не исчерпывается только акторами или только Эрлангом.
При этом, что забавно, Erlang не называет себя объектно-ориентированным. И "отправить любое сообщение" - это не значит, что сообщения не типизованы и нет контрактов. И в эрланге и в смолтолке типы есть, разница только во времени проверки - при компиляции или при исполнении.
Ну и заметим, что актор - обычно несколько больше чем объект.
А можешь пояснить, что именно "академично"? Все-таки и ТРИЗ и Щедровицкий - это не про содержание доклада, а про "внеклассное чтение", про источники вдохновения для решения конкретных проблем. Ну и у меня в голове сложно сочетается "академично", "Щедровицкий" и "по поверхности". Кажется, что какие-то из слов тут лишние.
Я, скорее, хотел показать, что автор статьей не совсем понял тот код, который комментирует. Иначе не сказал бы про O(n) для HashMap. Впрочем, статья изначально бесполезная.
Ну, это разница между статической типизацией или динамической, да. Там можно спорить, что лучше, но типы у сообщений все равно есть. И контракт объекта-получателя.
Так публикация статей без содержания - это и есть неконструктивное общение, так что причина указана верно. И как-то при такой реакции не возникает никакого желания указывать на ошибки, тем более каким-то странным "мы".
Сначала скажите, что в данной статье нового относительно примерно десятка прочих статей про скрам и канбан, которые опубликованы на хабре. Читали ли вы их вообще перед публикацией собственной? Если нет, то почему решили, что скажите что-то новое?
Данная статья не содержит никакой полезной или новой информации, зато содержит множество ошибок, написана без особого понимания как Скрама, так и Канбана, противоречит даже скрам-гайду. Более того, подобных сравнений и так очень много в интернете (и даже на хабре), причем гораздо более качественных. Т.е. проблема не в каких-то заблуждениях автора, а в полном безразличии к качеству предоставляемых материалов, потому и минус в карму.
А когда это получение значения из hashmap имеет сложность o(n)? Или что значит фраза " Вставка и получение элементов имеют имеют сложность O(1) или О(n), или O(logN)"?
Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
А почему использовали такой подход, а не подход Cadence/Temporal? Сценарии при этом получаются гораздо более удобные и понятные и не нужно думать лишний раз о компенсациях (которые вообще не очень обязательны в сагах и сильно усложняют использование, особенно если в компенсации случилась ошибка).
Не совсем корректно говорить, что в Kafka нет подтверждения доставки. Как раз гарантии доставки в Кафка есть, сообщение будет доставлено до consumer (если таковой вообще существует). Нет гарантии обработки, но их нет и в RabbitMQ и, насколько знаю, в NATS.
Возможно, стоило бы еще и сказать про реальную призводительность и надежность, где Kafka много лучше и RabbitMQ и NATS.
Гарантий доставки exactly once не существует. В Kafka так называется автоматическая дедупликация между producer и broker, но фактически consumer может читать данные много раз. В NATS, подозреваю, так же (так как exactly once физически нереализуемо в распределенных систем).
Ну и, насколько я понимаю, в таблице 3 млн. событий в секунду для NATS указано для режима без persistance, что делает эти числа бесполезными.
P.S. Текст выглядит как автоматический перевод. Если это так, то стоит указать оригинальный источник. Если нет, то стоит вычитать и поправить грамматические ошибки, их очень много.
Математика в ВУЗе (не всякая, не во всяком ВУЗе) кроме собственно "математики" очень сильно прокачивает умение работать со сложными формальными системами, с разными уровнями абстракции, с последовательным решением задач.
И, как ни странно, именно эти навыки нужны при разработке от миддла и выше. Да, есть и другие способы научиться работать со сложными системами, но математика в хорошем ВУЗе - один из самых простых и быстрых способов.
Так что математика - нужна. Но не сама математика, а то мышление, которое она тренирует.
Если бы на курсах преподавали опытные специалисты - то утверждение было бы правильным. Но большинство курсов нанимает себе преподавателей за цену стажеров, так что надеяться на какую-то осмысленную обратную связь не стоит. В лучшем случае это будет какой-то миддл, да и то не факт.
Ну, вообще прописывание технического дизайна - это работа как раз инженера-программиста. Если ей занимаются аналитики или лиды, то получается не очень (
Хм, это плохая задача, так как приучает к копипасте вместо нормальной разработки (воткнуть генерацию метрик прямо в фреймворк).
О, а что за история про самый копируемый код?
Ну, если уж совсем занудствовать,
то любой term подойдет внутри message, а так-то типизация сигналов очень даже есть (message/link/etc). Впрочем, системные сигналы можно и не считать
Набор матчингов в recieve - это как раз контракт процесса и определяет, какие сообщения он может получать. Отправлять другие сообщения - бесполезно.
То, что типизация сообщений идет на pattern matching, а не на RTTI - не принципиально, все равно это про контракт и сообщения.
В эрланге у процессора дофига всякого (несколько очередей, например). Это точно несколько больше, что то, что обычно считают объектом.
Но это все, конечно, мелочи )
Ну и хотя акторные системы (среди которых далеко не только Эрланг) и являются примером ООП, но ООП не исчерпывается только акторами или только Эрлангом.
При этом, что забавно, Erlang не называет себя объектно-ориентированным. И "отправить любое сообщение" - это не значит, что сообщения не типизованы и нет контрактов. И в эрланге и в смолтолке типы есть, разница только во времени проверки - при компиляции или при исполнении.
Ну и заметим, что актор - обычно несколько больше чем объект.
А можешь пояснить, что именно "академично"? Все-таки и ТРИЗ и Щедровицкий - это не про содержание доклада, а про "внеклассное чтение", про источники вдохновения для решения конкретных проблем.
Ну и у меня в голове сложно сочетается "академично", "Щедровицкий" и "по поверхности". Кажется, что какие-то из слов тут лишние.
Я, скорее, хотел показать, что автор статьей не совсем понял тот код, который комментирует. Иначе не сказал бы про O(n) для HashMap.
Впрочем, статья изначально бесполезная.
Ну, это разница между статической типизацией или динамической, да.
Там можно спорить, что лучше, но типы у сообщений все равно есть. И контракт объекта-получателя.
Так публикация статей без содержания - это и есть неконструктивное общение, так что причина указана верно. И как-то при такой реакции не возникает никакого желания указывать на ошибки, тем более каким-то странным "мы".
Сначала скажите, что в данной статье нового относительно примерно десятка прочих статей про скрам и канбан, которые опубликованы на хабре. Читали ли вы их вообще перед публикацией собственной? Если нет, то почему решили, что скажите что-то новое?
Это не совсем верное утверждение. Список в бакете не превышает 8 элементов, так что O(N) получить никак не получится.
Данная статья не содержит никакой полезной или новой информации, зато содержит множество ошибок, написана без особого понимания как Скрама, так и Канбана, противоречит даже скрам-гайду.
Более того, подобных сравнений и так очень много в интернете (и даже на хабре), причем гораздо более качественных. Т.е. проблема не в каких-то заблуждениях автора, а в полном безразличии к качеству предоставляемых материалов, потому и минус в карму.
А чем она хуже этой статьи?
А когда это получение значения из hashmap имеет сложность o(n)?
Или что значит фраза " Вставка и получение элементов имеют имеют сложность O(1) или О(n), или O(logN)"?
Вы описали скорее Канбан. К Скраму указанный подход не имеет никакого отношения (благодаря чему, скорее всего, и удалось получить пользу).
Не совсем понятно, каким образом формат противоречит гибкости? Ровно наоборот...
Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.