Если бы на курсах преподавали опытные специалисты - то утверждение было бы правильным. Но большинство курсов нанимает себе преподавателей за цену стажеров, так что надеяться на какую-то осмысленную обратную связь не стоит. В лучшем случае это будет какой-то миддл, да и то не факт.
Ну, вообще прописывание технического дизайна - это работа как раз инженера-программиста. Если ей занимаются аналитики или лиды, то получается не очень (
Ну, если уж совсем занудствовать, то любой term подойдет внутри message, а так-то типизация сигналов очень даже есть (message/link/etc). Впрочем, системные сигналы можно и не считать
Набор матчингов в recieve - это как раз контракт процесса и определяет, какие сообщения он может получать. Отправлять другие сообщения - бесполезно. То, что типизация сообщений идет на pattern matching, а не на RTTI - не принципиально, все равно это про контракт и сообщения.
В эрланге у процессора дофига всякого (несколько очередей, например). Это точно несколько больше, что то, что обычно считают объектом.
Но это все, конечно, мелочи )
Ну и хотя акторные системы (среди которых далеко не только Эрланг) и являются примером ООП, но ООП не исчерпывается только акторами или только Эрлангом.
При этом, что забавно, Erlang не называет себя объектно-ориентированным. И "отправить любое сообщение" - это не значит, что сообщения не типизованы и нет контрактов. И в эрланге и в смолтолке типы есть, разница только во времени проверки - при компиляции или при исполнении.
Ну и заметим, что актор - обычно несколько больше чем объект.
А можешь пояснить, что именно "академично"? Все-таки и ТРИЗ и Щедровицкий - это не про содержание доклада, а про "внеклассное чтение", про источники вдохновения для решения конкретных проблем. Ну и у меня в голове сложно сочетается "академично", "Щедровицкий" и "по поверхности". Кажется, что какие-то из слов тут лишние.
Я, скорее, хотел показать, что автор статьей не совсем понял тот код, который комментирует. Иначе не сказал бы про O(n) для HashMap. Впрочем, статья изначально бесполезная.
Ну, это разница между статической типизацией или динамической, да. Там можно спорить, что лучше, но типы у сообщений все равно есть. И контракт объекта-получателя.
Так публикация статей без содержания - это и есть неконструктивное общение, так что причина указана верно. И как-то при такой реакции не возникает никакого желания указывать на ошибки, тем более каким-то странным "мы".
Сначала скажите, что в данной статье нового относительно примерно десятка прочих статей про скрам и канбан, которые опубликованы на хабре. Читали ли вы их вообще перед публикацией собственной? Если нет, то почему решили, что скажите что-то новое?
Данная статья не содержит никакой полезной или новой информации, зато содержит множество ошибок, написана без особого понимания как Скрама, так и Канбана, противоречит даже скрам-гайду. Более того, подобных сравнений и так очень много в интернете (и даже на хабре), причем гораздо более качественных. Т.е. проблема не в каких-то заблуждениях автора, а в полном безразличии к качеству предоставляемых материалов, потому и минус в карму.
А когда это получение значения из hashmap имеет сложность o(n)? Или что значит фраза " Вставка и получение элементов имеют имеют сложность O(1) или О(n), или O(logN)"?
Хм, похоже, вы просто не понимаете, что такое POS. Он не отправляет никакой информации об оплате. Процесс оплаты вообще происходит довольно далеко от POS. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
Pos терминал имеет дело с конкретным форматом записи на карте (чип), поддерживает сложный протокол для работы с этим чипом (ISO 8583, загрузка ключей, работа с сеансами и так далее). И без этой жесткой логики, описывающей сообщения как от эквайера к POS, так и взаимодействие POS и карты - никакие платежи по карте невозможны. При этом весь обмен от банковской карты и до банка-эмитента жестко описаны документацией в несколько тысяч страниц. И, в рамках ООП, карта, POS, софт эквайера, софт эмитента, софт ПС - как раз объекты, обменивающиеся сообщениями. При этом форматы (типы) сообщений жестко описаны, а вот сама логика - да, может быть очень гибкой. Собственно, в этом и есть смысл ООП 2. Кажется, вы не понимаете не только принципы работы POSов, но и ООП и процессы передачи сообщений. Благо уж по ООП много литературы и там описано и что такое сообщение и что такое объект. Собственно, о том, что вы не очень разбираетесь в ООП - уже написало довольно много человек.
В теории - да, в Redis Cluster есть шардинг. Но в реальном использовании там все не так просто и масштабирование нужно делать очень аккуратно, при этом еще и справляясь с кучей ограничений кластера. Внутренний на хазелкасте - масштабируется примерно так же, чуть сложнее для программиста, чуть проще для админа, разница не принципиальна.
Но, в любом случае, горизонтальное масштабирование не зависит от того, внутренний или внешний кэш.
Медианный latency внутреннего кэша примерно на два-четыре десятичных порядка меньше, чем доступ через сеть, хотя реальные значения зависят от множества параметров (как ни странно, нигде не увидел актуальных данных по latency доступа к современной серверной памяти и сетевых задержек внутри современного ДЦ). На надо помнить, что для сети какой-нибудь 99.99 персентиль будет много выше медианы и может легко доходить до десятков ms, а время доступа к локальной памяти гораздо меньше подвержено флуктуациям.
Нет никакой произвольности на POS-терминале. Там есть очень жесткий протокол, все возможные обработки которого (для VISA/MC/etc) жестко описаны. Нет возможности в POSе использовать вместо банковской карты - какую-то другую (например, телефонную). В реальном мире (и в проектировании) как раз сообщения, которые может обработать объект - всегда жестко специфицированы. И ООП - как раз про это.
Если бы на курсах преподавали опытные специалисты - то утверждение было бы правильным. Но большинство курсов нанимает себе преподавателей за цену стажеров, так что надеяться на какую-то осмысленную обратную связь не стоит. В лучшем случае это будет какой-то миддл, да и то не факт.
Ну, вообще прописывание технического дизайна - это работа как раз инженера-программиста. Если ей занимаются аналитики или лиды, то получается не очень (
Хм, это плохая задача, так как приучает к копипасте вместо нормальной разработки (воткнуть генерацию метрик прямо в фреймворк).
О, а что за история про самый копируемый код?
Ну, если уж совсем занудствовать,
то любой 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. Лучше не использовать примеры из областей, в которых не разбираетесь.
Я не очень понимаю, откуда взялось противопоставление "сообщений" и "формата". Сообщения - всегда в каком-то конкретном протоколе, в конкретном формате и содержат конкретную семантику. И ООП, в том числе, и об этом. И как раз про это и пишут основатели ООП.
Pos терминал имеет дело с конкретным форматом записи на карте (чип), поддерживает сложный протокол для работы с этим чипом (ISO 8583, загрузка ключей, работа с сеансами и так далее). И без этой жесткой логики, описывающей сообщения как от эквайера к POS, так и взаимодействие POS и карты - никакие платежи по карте невозможны. При этом весь обмен от банковской карты и до банка-эмитента жестко описаны документацией в несколько тысяч страниц.
И, в рамках ООП, карта, POS, софт эквайера, софт эмитента, софт ПС - как раз объекты, обменивающиеся сообщениями. При этом форматы (типы) сообщений жестко описаны, а вот сама логика - да, может быть очень гибкой. Собственно, в этом и есть смысл ООП
2. Кажется, вы не понимаете не только принципы работы POSов, но и ООП и процессы передачи сообщений. Благо уж по ООП много литературы и там описано и что такое сообщение и что такое объект.
Собственно, о том, что вы не очень разбираетесь в ООП - уже написало довольно много человек.
В теории - да, в Redis Cluster есть шардинг. Но в реальном использовании там все не так просто и масштабирование нужно делать очень аккуратно, при этом еще и справляясь с кучей ограничений кластера. Внутренний на хазелкасте - масштабируется примерно так же, чуть сложнее для программиста, чуть проще для админа, разница не принципиальна.
Но, в любом случае, горизонтальное масштабирование не зависит от того, внутренний или внешний кэш.
Медианный latency внутреннего кэша примерно на два-четыре десятичных порядка меньше, чем доступ через сеть, хотя реальные значения зависят от множества параметров (как ни странно, нигде не увидел актуальных данных по latency доступа к современной серверной памяти и сетевых задержек внутри современного ДЦ).
На надо помнить, что для сети какой-нибудь 99.99 персентиль будет много выше медианы и может легко доходить до десятков ms, а время доступа к локальной памяти гораздо меньше подвержено флуктуациям.
Нет никакой произвольности на POS-терминале. Там есть очень жесткий протокол, все возможные обработки которого (для VISA/MC/etc) жестко описаны. Нет возможности в POSе использовать вместо банковской карты - какую-то другую (например, телефонную).
В реальном мире (и в проектировании) как раз сообщения, которые может обработать объект - всегда жестко специфицированы. И ООП - как раз про это.