Это понятно, но там довольно мало сообщений идет относительно основного бизнеса. Не сотни тысяч в секунду ) Ну, конечно, если в кафку летят ежесекундные треки по всем курьерам, то там вполне получится десяток тысяч rps, но даже это - не миллионы )
Ну, можно, конечно, каждое движение мышкой отправлять в kafka, но это довольно странная идея, там проще (и правильнее) отправлять сразу пачку данных по сессии. Т.е. вряд ли именно эти данные дают такое количество сообщений.
Хм. Меньше сотни платежей в секунду - это данные из квартального отчета Озона за первый квартал 2023 года (там 180млн. платежей за квартал указано, что примерно 50 в секунду) 1.5 миллиона сообщений - из приведенного в данной статье графика. Понятно, что не только платежи приводят к трафику - но все равно интересно, откуда такой объем сообщений в кафке. Я бы сказал, порядка на три-четыре больше ожидаемого.
А откуда на apigw сотня тысяч rps? Или каждая страница превращается в сотни rps?
Да и это про чтение же, а чтение не должно приводить к сообщениям в кафке? А действий - ещё на порядки меньше. Т.е. все равно не понятно, как сотня (даже меньше) покупок в секунду приводит к к полутора миллионам новых сообщений в кафке в секунду.
А откуда в Ozon появляется такое количество сообщений? Насколько я понимаю, нагрузка на сайте там единицы тысяч rps, да и то на чтение и в пике. Откуда появляются миллионы сообщений в кафке?
Если у вас нужно давление для борьбы с прокрастинацией - то у вас в компании более существенные проблемы, нежели процессные и нужно всерьез работать над культурой и наймом. Или, лучше, поменять компанию. Если в компании KPI на разработчиков на число задач - то в компании очень большие проблемы с вменяемостью менеджмента, так что, опять-таки, лучше менять компанию.
Какое отношение "рецензируемость" имеет к "научности"? Какая из этих статей научная (т.е. про результаты, полученные с использованием научной методологии)? Фальсифицируемые, с корректными экспериментами и т.п.
1) Нет, и оценки и прогнозы - не являются скаляром. Оценки вообще без указания вероятности (даже по одному ресурсу) не имеют значения, так как не понятно, это оценки вообще чего. Про это много у тех же ДиМарко/Листера написано в "Вальсируя с медведями". 2) То, что она обычная - не делает ее хоть сколько-то полезной и практичной. И нет, Дельфи - не научный метод. Хотя и используется в экспертной среде. И нет, он никак не связан с планинг-покером (так как вообще предполагает строго противоположные подходы). 3) А где указано? При том, что и майки и даже SP - это именно про оценку рисков (а не чего-то еще). Но, почему-то, про это не сказали 4) Для обзорной статьи в ней очень плохо со структурой, нет никаких обоснований, очень мало хоть сколько-то полезного контента, нет ни одной работающей методики. Это примерно как обозревать разные школы астрологии в статье про найм.
Но в списке литературы нет ни одной научной работы. Есть какие-то разнообразные спекуляции на тему оценок, некоторые могут быть интересными. Но научного - нет ничего.
1) Оценка (любая) как скаляр (а не вектор или, лучше распределение вероятностей). Все методы, предполагающие аддитивность подобных оценок (или возможность их сравнивать) можно сразу отправлять в топку. 2) Покер-планирование. 3) Отсутствие учета рисков при планировании (хотя это единственно полезное вообще в оценках и в планировании) 4) Применение методов статистики на недостаточной базе (с понятными результатами). Тут и про прогноз и про контроль управляемости - все эти подходы на небольшой базе бесполезны.
Для презентаций в PowerPoint есть killer feature - "режим докладчика" с комментариями и указкой. Увы, для pdf такой возможности нет, что делает использование Elsie гораздо менее удобным. Если бы был экспорт в pptx с возможностью добавления и управления комментариями, то было бы гораздо интереснее.
Самой специализации лет 20 минимум только в РФ, в мире и все 40 лет будет, так как роль (и позиция) возникает довольно быстро в любой компании, занимающейся внедрением сложных продуктов. Автор просто довольно плохо разбирается в этой теме.
Ну, так или иначе все равно нужна группировка разных функций, иначе "найти" нужное (тем более обеспечивать автоматический intellisense и прочие фишки) будет сложно. Классы+методы нужны, кроме прочего, и как метод структурирования кода - и тут никаких вариантов не предлагается, просто "группировка функций в неймспейсах" - недостаточная замена. А как только начнется группировка, то выяснится, что функции работы с, например, постами нужны вместе, вместе с необходимыми dataclass, и в неймспейсе вида Post, что приведет к модульному коду в духе старого Pascal, из которого Java и выросла. Ну, длинный путь чтобы дойти до ООП. Но для небольших проектов - да, вполне нормальный подход. Если еще и с ООА сочетать.
Не совсем понятно, а где тут отказ от ООП? Если у микросервиса есть персистанс - то он уже является объектом с точки зрения ООП (в изначальном смысле, объект - как стейт+список обрабатываемых событий, где стейт - это персистанс, а события - это entrypoints). Вот если от предлагаемой структуры микросервиса переходить к стилю Pipes&Filters - можно говорить об отказе от ОПП. Да и в предложенной структуре кода вместо класса просто используется namespace как объединение данных и методов, особой разницы (кроме сложностей в использовании) нет. Так что в чем смысл предложенного метода - не совсем понятно.
Я вот тоже задаюсь тем же вопросом. Или ошибка в тексте и там указаны ns (но тогда маловато) или использованы какие-то очень странные конфигурации, не связанные с реальной жизнью (где ответ от кэша больше 5ms уже выглядит слишком долгим).
Это понятно, но там довольно мало сообщений идет относительно основного бизнеса. Не сотни тысяч в секунду )
Ну, конечно, если в кафку летят ежесекундные треки по всем курьерам, то там вполне получится десяток тысяч rps, но даже это - не миллионы )
Ну, можно, конечно, каждое движение мышкой отправлять в kafka, но это довольно странная идея, там проще (и правильнее) отправлять сразу пачку данных по сессии. Т.е. вряд ли именно эти данные дают такое количество сообщений.
Хм. Меньше сотни платежей в секунду - это данные из квартального отчета Озона за первый квартал 2023 года (там 180млн. платежей за квартал указано, что примерно 50 в секунду)
1.5 миллиона сообщений - из приведенного в данной статье графика.
Понятно, что не только платежи приводят к трафику - но все равно интересно, откуда такой объем сообщений в кафке. Я бы сказал, порядка на три-четыре больше ожидаемого.
А откуда на apigw сотня тысяч rps? Или каждая страница превращается в сотни rps?
Да и это про чтение же, а чтение не должно приводить к сообщениям в кафке?
А действий - ещё на порядки меньше.
Т.е. все равно не понятно, как сотня (даже меньше) покупок в секунду приводит к к полутора миллионам новых сообщений в кафке в секунду.
А откуда в Ozon появляется такое количество сообщений?
Насколько я понимаю, нагрузка на сайте там единицы тысяч rps, да и то на чтение и в пике. Откуда появляются миллионы сообщений в кафке?
Вот да. Вроде бы вполне скромные НФТ, интересна только рассылка писем, все остальное совсем небольшое.
Если у вас нужно давление для борьбы с прокрастинацией - то у вас в компании более существенные проблемы, нежели процессные и нужно всерьез работать над культурой и наймом. Или, лучше, поменять компанию.
Если в компании KPI на разработчиков на число задач - то в компании очень большие проблемы с вменяемостью менеджмента, так что, опять-таки, лучше менять компанию.
Какое отношение "рецензируемость" имеет к "научности"? Какая из этих статей научная (т.е. про результаты, полученные с использованием научной методологии)? Фальсифицируемые, с корректными экспериментами и т.п.
Да, это очень удобный способ уйти от обсуждения проблем по существу.
1) Нет, и оценки и прогнозы - не являются скаляром. Оценки вообще без указания вероятности (даже по одному ресурсу) не имеют значения, так как не понятно, это оценки вообще чего. Про это много у тех же ДиМарко/Листера написано в "Вальсируя с медведями".
2) То, что она обычная - не делает ее хоть сколько-то полезной и практичной. И нет, Дельфи - не научный метод. Хотя и используется в экспертной среде. И нет, он никак не связан с планинг-покером (так как вообще предполагает строго противоположные подходы).
3) А где указано? При том, что и майки и даже SP - это именно про оценку рисков (а не чего-то еще). Но, почему-то, про это не сказали
4) Для обзорной статьи в ней очень плохо со структурой, нет никаких обоснований, очень мало хоть сколько-то полезного контента, нет ни одной работающей методики. Это примерно как обозревать разные школы астрологии в статье про найм.
Но в списке литературы нет ни одной научной работы. Есть какие-то разнообразные спекуляции на тему оценок, некоторые могут быть интересными. Но научного - нет ничего.
А где там научная информация-то?
1) Оценка (любая) как скаляр (а не вектор или, лучше распределение вероятностей). Все методы, предполагающие аддитивность подобных оценок (или возможность их сравнивать) можно сразу отправлять в топку.
2) Покер-планирование.
3) Отсутствие учета рисков при планировании (хотя это единственно полезное вообще в оценках и в планировании)
4) Применение методов статистики на недостаточной базе (с понятными результатами). Тут и про прогноз и про контроль управляемости - все эти подходы на небольшой базе бесполезны.
Хороший сборник антипаттернов в управлении. Кажется, собраны все возможные ошибки при работе с оценками.
Ну, не настолько забытое.
Насколько помню, в MSX для тригонометрических функций как раз использовались таблицы с интерполяцией.
Для презентаций в PowerPoint есть killer feature - "режим докладчика" с комментариями и указкой. Увы, для pdf такой возможности нет, что делает использование Elsie гораздо менее удобным. Если бы был экспорт в pptx с возможностью добавления и управления комментариями, то было бы гораздо интереснее.
Самой специализации лет 20 минимум только в РФ, в мире и все 40 лет будет, так как роль (и позиция) возникает довольно быстро в любой компании, занимающейся внедрением сложных продуктов. Автор просто довольно плохо разбирается в этой теме.
Ну, так или иначе все равно нужна группировка разных функций, иначе "найти" нужное (тем более обеспечивать автоматический intellisense и прочие фишки) будет сложно.
Классы+методы нужны, кроме прочего, и как метод структурирования кода - и тут никаких вариантов не предлагается, просто "группировка функций в неймспейсах" - недостаточная замена.
А как только начнется группировка, то выяснится, что функции работы с, например, постами нужны вместе, вместе с необходимыми dataclass, и в неймспейсе вида Post, что приведет к модульному коду в духе старого Pascal, из которого Java и выросла. Ну, длинный путь чтобы дойти до ООП.
Но для небольших проектов - да, вполне нормальный подход. Если еще и с ООА сочетать.
Не совсем понятно, а где тут отказ от ООП? Если у микросервиса есть персистанс - то он уже является объектом с точки зрения ООП (в изначальном смысле, объект - как стейт+список обрабатываемых событий, где стейт - это персистанс, а события - это entrypoints). Вот если от предлагаемой структуры микросервиса переходить к стилю Pipes&Filters - можно говорить об отказе от ОПП.
Да и в предложенной структуре кода вместо класса просто используется namespace как объединение данных и методов, особой разницы (кроме сложностей в использовании) нет.
Так что в чем смысл предложенного метода - не совсем понятно.
Я вот тоже задаюсь тем же вопросом.
Или ошибка в тексте и там указаны ns (но тогда маловато) или использованы какие-то очень странные конфигурации, не связанные с реальной жизнью (где ответ от кэша больше 5ms уже выглядит слишком долгим).