А откуда на 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 уже выглядит слишком долгим).
А для каких целей нужна оценка? Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано). Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Команда может быть исполнителем с предсказуемой производительностью только если: 1) структура команды не меняется 2) все сотрудники в команде являются одинаковыми по производительности 3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен. Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.
А откуда на 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 уже выглядит слишком долгим).
А для каких целей нужна оценка?
Если нужна оценка большой фичи, то там оценка вообще выглядит не как число, а как набор рисков и вероятностей, попытка свести к одному числу - бесполезно. При этом оценка в SP никак не коррелирует с реальной трудоемкостью задачи или временем на ее выполнение (так как ни к чему не привязано).
Ну а сходимость велосити - это про "самосбывающийся прогноз", к реальным оценкам и трудоемкости никакого отношения не имеет, просто решение подгоняется под готовый ответ, это популярное заблуждение.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Но меня забавляет настойчивость в использовании плохих методов менеджмента, даже их авторами уже признанными неудачными )
Команда может быть исполнителем с предсказуемой производительностью только если:
1) структура команды не меняется
2) все сотрудники в команде являются одинаковыми по производительности
3) входящие задачи имеют рутинный характер.
Увы, в реальности ни один из этих пунктов не соблюдается. Команда постоянно меняется (отпуска, смена мест работы, личный рост). Люди в команде тоже все разные и то, что один из них умеет делать плохо - другой делает хорошо и без планирования ресурсов внутри команды нельзя определить трудоемкость задачи. Входящие задачи тоже крайне редко настолько похожи друг на друга, что можно их оценивать одной линейкой.
Все это приводит к бесполезности и оценки в SP и в оценке velocity вообще.
Тот же Рон про велосити пишет "If I invented velocity, I'm sorry" ( https://twitter.com/RonJeffries/status/1488220234750246919)
Ну и, конечно, трудоемкость задачи (даже кривая в SP) никак не соотносится с временем доставки, так что нет никакой возможности на основе оценок SP хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.
Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен.
Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.