Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
Single responsibility он про reason to change, в данном случае не ходить и говорить, а про то, как он ходит и говорит. Условно, если в классе Robot мы формируем команды, то способ их передачи конкретным железкам должен быть вынесен в отдельный класс.
Тут хороший пример SRP в секции про Dependency Inversion: UserService не знает, в какие конкретно колонки кладутся отдельные поля, может, там вообще документная база, или просто в текстовый файл пишется.
Тимлид должен проводить 1:1 с членами команды, если каждому давать по часу раз в пару недель + еще час на подготовку, то у вас все рабочее время уйдет исключительно на это.
Вряд ли, в джаве многие вещи пытаются сделать правильно с математической точки зрения, в то время как в Котлине подход более прагматический. Бреслав как-то рассказывал, что в джаве дженерики у методов идут перед названием метода (Collections.<String>emptyList()), потому что это правильно, а в Котлине они идут после, потому что это естественее (listOf<String>()) .
После того, как я получил сертификацию AWS Developer Associate, стал очень подозрительно смотреть на тех, кто им гордится. Невероятно бесполезная бумажка.
Что скрам-мастера, что эджайл-коучи - все могут сказать, что команда не следовала их рекомендациям, и поэтому провалилась, или что достигла успеха именно благодаря их "вкладу".
А как вы оцениваете какие-то исследовательские задачи? Там весь смысл, что ты не знаешь, насколько оно сложно.
Плюс, проект проекту рознь, где-то хорошо спроектировали и можно легко накинуть новый функционал, где-то на первый взгляд так же, но после начала работы начинаешь тонуть.
Тут в основном про бизнес-логику, чтобы очередь не застряла. Если ошибка протокольная, то в DLQ как раз отправить будет непросто, потому что непонятно, что именно отправлять.
С буферами тоже большая проблема, в джавовой библиотеки буфер по умолчанию на 32 мегабайта и туда легко могут войти десятки тысяч одинаковых записей, если продолжать ретраить.
Проблема с JPA в том, что он может внезапно накинуть 2-3 запроса сверху, в зависимости от графа сущностей. Там, где кажется, что должен быть один запрос, легко может быть пять.
Есть неплохая библиотека, чтобы защититься от такого, она позволяет убедиться, что такой-то запрос выполняет 2 селекта, а не 10 https://github.com/quick-perf/quickperf
Кокроач изо всех сил пытается выглядеть обычной RDBMS, но на деле не является такой. В итоге на какой-нибудь очень простой запрос в специальных условиях задержка улетает в небо.
Ну и отсутствие привычного READ_COMMITTED ломает многие привычные паттерны проектирования.
Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
Так как измерить-то?
Подарки тоже часто подлежат налогообложению, прям много передать детям тоже не получится.
По идее, их и сервер-то не очень знает, обычно пин-блок напрямую в HSM обрабатывается.
Single responsibility он про reason to change, в данном случае не ходить и говорить, а про то, как он ходит и говорит. Условно, если в классе Robot мы формируем команды, то способ их передачи конкретным железкам должен быть вынесен в отдельный класс.
Тут хороший пример SRP в секции про Dependency Inversion: UserService не знает, в какие конкретно колонки кладутся отдельные поля, может, там вообще документная база, или просто в текстовый файл пишется.
"Исторически" - это уже более 15 лет назад, когда Qt добавил опцию LGPL в список лицензий. Давно уже никаких проблем нет.
Кто такой "координатор"?
Тимлид должен проводить 1:1 с членами команды, если каждому давать по часу раз в пару недель + еще час на подготовку, то у вас все рабочее время уйдет исключительно на это.
Ну, или вы просто не проводите 1:1.
Вряд ли, в джаве многие вещи пытаются сделать правильно с математической точки зрения, в то время как в Котлине подход более прагматический. Бреслав как-то рассказывал, что в джаве дженерики у методов идут перед названием метода (
Collections.<String>emptyList()), потому что это правильно, а в Котлине они идут после, потому что это естественее (listOf<String>()) .После того, как я получил сертификацию AWS Developer Associate, стал очень подозрительно смотреть на тех, кто им гордится. Невероятно бесполезная бумажка.
В Германии с какого-то момента диплом стал обязателен.
Тут много вопросов, на самом деле. К примеру, что за scheduler вы используете? Или Чему равен PARALLELISM?
Стандартные реактивные шедулеры используют внутри пул ExecutorService с одним тредом, чтобы как раз избежать переключения контекста.
Плюс, в реакторе есть ForkJoinPoolScheduler.
Что скрам-мастера, что эджайл-коучи - все могут сказать, что команда не следовала их рекомендациям, и поэтому провалилась, или что достигла успеха именно благодаря их "вкладу".
Ну, т.е. вместо решения проблемы с таймаутом, они просто начали вручную выкидывать дубликаты.
Или можно было попробовать идемпотентные продюсеры https://www.linkedin.com/pulse/kafka-idempotent-producer-rob-golder/
Т.е. время на изучение проекта вы не оцениваете и не биллите?
А как вы оцениваете какие-то исследовательские задачи? Там весь смысл, что ты не знаешь, насколько оно сложно.
Плюс, проект проекту рознь, где-то хорошо спроектировали и можно легко накинуть новый функционал, где-то на первый взгляд так же, но после начала работы начинаешь тонуть.
Я уверен, что для нужных сотрудников можно будет найти уважительную причину для исключения из правила.
Почему бы просто не использовать UUID и генерировать его прямо на клиенте? Или, если хочется последовательные id, то можно и ULID.
Тут в основном про бизнес-логику, чтобы очередь не застряла. Если ошибка протокольная, то в DLQ как раз отправить будет непросто, потому что непонятно, что именно отправлять.
С буферами тоже большая проблема, в джавовой библиотеки буфер по умолчанию на 32 мегабайта и туда легко могут войти десятки тысяч одинаковых записей, если продолжать ретраить.
Проблема с JPA в том, что он может внезапно накинуть 2-3 запроса сверху, в зависимости от графа сущностей. Там, где кажется, что должен быть один запрос, легко может быть пять.
Есть неплохая библиотека, чтобы защититься от такого, она позволяет убедиться, что такой-то запрос выполняет 2 селекта, а не 10 https://github.com/quick-perf/quickperf
Кокроач изо всех сил пытается выглядеть обычной RDBMS, но на деле не является такой. В итоге на какой-нибудь очень простой запрос в специальных условиях задержка улетает в небо.
Ну и отсутствие привычного READ_COMMITTED ломает многие привычные паттерны проектирования.