А потом с этими данными надо работать дальше - показать юзеру в удобном виде, с кучей доп. данных, скорее всего из других баз. Сделать выгрузку во всякие эксельки...
А это разве не "выгрузить данные в нужном формате из одной системы и загрузить в другую"?
Интересно, что никто не написал, что надо уметь разбираться в новых доменах. В конце-концов, деньги платят не за то, насколько элегантные запросы можешь составить, или насколько у тебя чистый код, а за решение бизнес-задач.
Это, скорее, проблемы собеседований. Меня однажды на собеседовании про джаву спросили вопрос о том, как себя ведет такой-то код на экзотичной легаси-архитектуре (какой-то HP пятнадцатилетней давности).
Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
Single responsibility он про reason to change, в данном случае не ходить и говорить, а про то, как он ходит и говорит. Условно, если в классе Robot мы формируем команды, то способ их передачи конкретным железкам должен быть вынесен в отдельный класс.
Тут хороший пример SRP в секции про Dependency Inversion: UserService не знает, в какие конкретно колонки кладутся отдельные поля, может, там вообще документная база, или просто в текстовый файл пишется.
Тимлид должен проводить 1:1 с членами команды, если каждому давать по часу раз в пару недель + еще час на подготовку, то у вас все рабочее время уйдет исключительно на это.
Вряд ли, в джаве многие вещи пытаются сделать правильно с математической точки зрения, в то время как в Котлине подход более прагматический. Бреслав как-то рассказывал, что в джаве дженерики у методов идут перед названием метода (Collections.<String>emptyList()), потому что это правильно, а в Котлине они идут после, потому что это естественее (listOf<String>()) .
После того, как я получил сертификацию AWS Developer Associate, стал очень подозрительно смотреть на тех, кто им гордится. Невероятно бесполезная бумажка.
Что скрам-мастера, что эджайл-коучи - все могут сказать, что команда не следовала их рекомендациям, и поэтому провалилась, или что достигла успеха именно благодаря их "вкладу".
А как вы оцениваете какие-то исследовательские задачи? Там весь смысл, что ты не знаешь, насколько оно сложно.
Плюс, проект проекту рознь, где-то хорошо спроектировали и можно легко накинуть новый функционал, где-то на первый взгляд так же, но после начала работы начинаешь тонуть.
А это разве не "выгрузить данные в нужном формате из одной системы и загрузить в другую"?
Интересно, что никто не написал, что надо уметь разбираться в новых доменах. В конце-концов, деньги платят не за то, насколько элегантные запросы можешь составить, или насколько у тебя чистый код, а за решение бизнес-задач.
Диалект как раз не важен, если ORM используется. А знать надо, возможно, чтобы уметь индексы правильно накидывать?
Плюс, первая "проблема" json является проблемой xml: в json есть разница между числами и строками, а в xml как раз-таки нет.
Это, скорее, проблемы собеседований. Меня однажды на собеседовании про джаву спросили вопрос о том, как себя ведет такой-то код на экзотичной легаси-архитектуре (какой-то HP пятнадцатилетней давности).
Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 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/
Т.е. время на изучение проекта вы не оцениваете и не биллите?
А как вы оцениваете какие-то исследовательские задачи? Там весь смысл, что ты не знаешь, насколько оно сложно.
Плюс, проект проекту рознь, где-то хорошо спроектировали и можно легко накинуть новый функционал, где-то на первый взгляд так же, но после начала работы начинаешь тонуть.