Риски оценки точности ТЗ это работа кодера, или ПМ-а?
У кодера спросили 'сколько?' 'он сказал - кодить? день-два'. Если разработчик не сказал, что день-два, это (только) кодить, то только по причине, что его о сроках спрашивают 10й раз на дню. Ну так накиньте все риски, тесты и тп.
Потому что люди, определившие эти сроки — некомпетентны.
А может, девелопер, который делает оценку, не только оптимистичную, сколько оценивает чисто кодинг? Добавьте всякое про уточнение ТЗ, зависимости, тестирование и деплой - получится то, что в реальности?
Сложность стори выставляется командой - сколько решают поинтов, столько и ставят, можно обсудить.
Если тикет/стори выполняется одним человеком - посчитайте поинты - и все вопрос решен. Если несколькими, тут сложнее, или пилить на substory, или как-то делить поинты.
Скрам мастер в том числе смотрит, чтобы команда не накручивала поинтов, по сравнению с дугой командой.
Вы же сами сказали - "знакомые-знакомых", по теории шести рукопожатий, цепочки получаются не очень длинные.
Очевидно, что нужны private-public ключи для формирования цепочек доверения, и обмена сообщениями вообще.
Пусть лайкают и сговариваются, достаточно одного в этой группе пометить, и для 'меня' все их усилия отфильтровываются. И другого, может быть фильтр настроен иначе.
Проблема ботов, и анонимности рейтингов, тоже решаема.
Да я написал, а потом кнопка: 'обновить комментарий, и ага.
Если кратко, децентрализованный - не требуется серверов вообще, кроме reverse прокси на пользователей. Сервера возможны, типа как трекеры, но не необходимы.
Это почти как федеративный, но федерация, на каждого пользователя.
Алгоритмом лайков из вашего примера, будет фильтрация на пользователе, и каждым может настраивать фильтры по доверенности источника. Соответственно иметь свой рейтинг (постов), фильтр и тп.
Вопрос: - что, написали 4 пункта. Вы их читали? Это почти про одно и то-же.
Репутация = отзывы = рейтинги, дальше что? как вы их собираетесь использовать?
Проверка = машобуч = анализ, это все постфактум. Предотвращение есть?
Механизмы поддержки разрешения споров, без сапорта?
Кстати, ебай теряет по 10М пользователей в год, ФБ не зарабатывает на посреднических услугах, но переполнен мошенниками, тоесть есть что улучшать - где анализ проблем, и способы решения?
Пока только хороший! но, нишевый продукт для закрытого рынка. Кстати, еще раз - некоторые брендовые вещи, лекарства, меха, итп нельзя перепродавать, в зависимости от местных законов.
Во второй части будет решение теоремы? Как минимум два решения частных случаев: разделение по времени (eventual consistency on read & strong on write) и разделение по данным (primary key dynamic virtual partitions)
Риски оценки точности ТЗ это работа кодера, или ПМ-а?
У кодера спросили 'сколько?' 'он сказал - кодить? день-два'. Если разработчик не сказал, что день-два, это (только) кодить, то только по причине, что его о сроках спрашивают 10й раз на дню. Ну так накиньте все риски, тесты и тп.
А может, девелопер, который делает оценку, не только оптимистичную, сколько оценивает чисто кодинг? Добавьте всякое про уточнение ТЗ, зависимости, тестирование и деплой - получится то, что в реальности?
"стартыйдобрый" аджайл:
Сложность стори выставляется командой - сколько решают поинтов, столько и ставят, можно обсудить.
Если тикет/стори выполняется одним человеком - посчитайте поинты - и все вопрос решен. Если несколькими, тут сложнее, или пилить на substory, или как-то делить поинты.
Скрам мастер в том числе смотрит, чтобы команда не накручивала поинтов, по сравнению с дугой командой.
"тестирование? какое тестирование?"
двусвязный список в стандарте: https://doc.rust-lang.org/std/collections/struct.LinkedList.html
указатель в два потока: Arc + Mutex или RwLock и тд
Код питона в принципе требует тестов.
Статьи про питон, код которого может попасть в прод, наверное должны начинаться и заканчиваться тестом.
Если не в прод - то пофиг, если какая-то строчка в куче ваших файлов не работает - компиляции-то нет.
Вы же сами сказали - "знакомые-знакомых", по теории шести рукопожатий, цепочки получаются не очень длинные.
Очевидно, что нужны private-public ключи для формирования цепочек доверения, и обмена сообщениями вообще.
Пусть лайкают и сговариваются, достаточно одного в этой группе пометить, и для 'меня' все их усилия отфильтровываются. И другого, может быть фильтр настроен иначе.
Проблема ботов, и анонимности рейтингов, тоже решаема.
Да я написал, а потом кнопка: 'обновить комментарий, и ага.
Если кратко, децентрализованный - не требуется серверов вообще, кроме reverse прокси на пользователей. Сервера возможны, типа как трекеры, но не необходимы.
Это почти как федеративный, но федерация, на каждого пользователя.
Алгоритмом лайков из вашего примера, будет фильтрация на пользователе, и каждым может настраивать фильтры по доверенности источника. Соответственно иметь свой рейтинг (постов), фильтр и тп.
алгоритм есть, имплементации нет
мартекплейсы работают по разному. Конкретно FB Мартекплейс, работает (когда не багует) так, что без слез не расскажешь! но альтернатив (пока) нету.
отзыв, он на покупку или услугу. школьник сделал миллион транзакций? нет, ну и зачем это писать?
только децентрализованная система отзывов может спасти этот мир
есть, обращайтесь
Был один, стало два.
Атжайл "продается", если не по манифесту. вы идею т.е. Манифест читали?
Если еще короче - самая основная основа (это частично упомянуто в разделе Демо, статьи): результат работы команды. т.н. Артефакты или деплой:
в Скраме происходит в конце спринта, т.е. "деплоим, то что готово на момент времяни",
в Канбане - в момент завершения пула фичей - "Деплоим, когда готово заданный список задачь"
Redis Cluster вроде горизонтально масштабируется, а внутренний - это думать надо как все сделать!
джунам пойдет, а по факту - бери, что попроще и не выдумывай.
На сколько внешний медленнее внутреннего? Никто не переживает, вот и берут, то попроще.
Спасибо за ответ, но все это есть в ФБ/Ебай.
Вопрос: - что, написали 4 пункта. Вы их читали? Это почти про одно и то-же.
Репутация = отзывы = рейтинги, дальше что? как вы их собираетесь использовать?
Проверка = машобуч = анализ, это все постфактум. Предотвращение есть?
Механизмы поддержки разрешения споров, без сапорта?
Кстати, ебай теряет по 10М пользователей в год, ФБ не зарабатывает на посреднических услугах, но переполнен мошенниками, тоесть есть что улучшать - где анализ проблем, и способы решения?
Пока только хороший! но, нишевый продукт для закрытого рынка. Кстати, еще раз - некоторые брендовые вещи, лекарства, меха, итп нельзя перепродавать, в зависимости от местных законов.
https://stripe.com/resources/more/marketplaces-vs-platforms#what-is-a-marketplace
Ни ФБ, ни ебай себя как Р2Р не определяют, это С2С.
Риски определены, но как вы их решаете по сравнению с ФБ/Ебай?
Во второй части будет решение теоремы? Как минимум два решения частных случаев: разделение по времени (eventual consistency on read & strong on write) и разделение по данным (primary key dynamic virtual partitions)
Ссылка на crate?