Pull to refresh
34
0

User

Send message

А откуда на 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 хоть как-то вычислять время готовности к дедлайну, это тоже заблуждение.

Есть куча сценариев, где данные все-таки нужно запрашивать (ответ нужен синхронно, объем чужих данных очень большой, другой сервис не умеет в стриминг изменений, нет ресурсов для хранения чужих данных, нельзя получать данные не под запрос) и в этом случае запрос все-таки нужен.
Да и получение потока чужих данных дает довольно сильную логическую связность, большую чем синхронный запрос.

Information

Rating
Does not participate
Works in
Registered
Activity