В том случае, если на поле присутствует тень от крыши стадиона, а остальная часть ярко залита солнцем, один и тот же комплект формы может выглядеть по-разному.
Для неравномерного освещения нужно получить два набора векторов — из солнечной и теневой части поля.
Попробуйте сначала перевести в HSL. Подозреваю, что цвет (H) не сильно изменится от солнца. Точнее, он, конечно, изменится, но в ожидаемую сторону - в желтую на солнечной стороне.
На трассировку требований нет запроса. На выявление есть, но неявно. Чаще к аналитику приходит задача от PO в виде "вот я написал, что надо, со смежниками Васей и Валей договорился, скажи срок, когда напишешь требования". Правда, кто такие бесфамильные Вася и Валя, какое они имеют отношение к задаче, и в чем состоят договорённости - остаётся неизвестным.
Мне кажется, потребителю сервиса надо знать, что регистрация клиента прошла или нет, а не то, отправил ли сервис что-то куда-то. Потому что если сервис регистрации упал с ошибкой, то потребитель попробует повторить регистрацию, но в этот раз у него не получится, так как клиент уже зарегистрирован, просто потребитель не в курсе.
То есть сервис должен падать только при невозможности выполнения его основной функции - регистрации, а все сопутствующие действия либо проводить без прокидывания exception наверх, либо, если это важно, откатывая регистрацию. Тогда у потребителя будет четкое понимание: выполнилось успешно - значит регистрация прошла; exception - значит регистрации не случилось.
А еще registerClient упадет, если упали на маппинге или не удалось достучаться до Кафки, хотя сама регистрация клиента была успешно выполнена. Впрочем, это тема уже для другой статьи.
Это вы рассматриваете вариант, когда уволится аналитик, который с требованиями работал. А интервьюируемые - уже не аналитики.
Если уволится лидер компетенции - в моменте ничего не изменится. На продолжительном сроке, возможно, аналитики из ведомой им группы аналитиков несколько притормозят в своем профессиональном развитии, но это если (а) лидер реально им помогал развиваться и (б) качество аналитиков в данной корп. среде имеет значение.
Если уволится Solution Architector - в моменте ничего не изменится. Могут приниматься архитектурные решения без него, теми же аналитиками, например. На продолжительном сроке эти решения могут оказаться технологическим тормозом для развития бизнеса. А могут и не оказаться.
Если уволится Product Owner - появится новый, которого аналитики введут в курс дела.
Сначала в команде нас было двое — я и продакт. Вместе с ростом команды развивались и мои ранги: команда расширилась до 120 человек, а я стала мидлом, потом сеньором, и, через некоторое, мне предложили роль лида
Полагаю, что аналитиков среди 120 человек команды будет не менее 10 процентов.
Также полагаю, что этим 12 аналитикам уже некуда расти в карьерном смысле, т.к. должность лида компетенции уже занята и освобождаться не собирается.
Впечатление "поехавшего кукухой деда на таблетках" нехило так создается, когда дед предлагает решения, которые молодежь еще не понимает, а деду кажется тривиальным. Приходится деду ограничивать свою инициативность.
При наличии на планете атмосферы ракетные двигатели используются только на начальной стадии спуска — для перехода с космической орбиты (траектории) на траекторию спуска, до входа в атмосферу
В руках я держал чек, выписанный Чарли. Сумма в нем позволила бы отдохнуть пару недель в Майами с подружкой, но я знал, что очень скоро на моем пороге вновь появится Чарли.
• У 21 присутствовало оконченное высшее образование — 56.8% • У 20 присутствовала информация в разделе "Обо мне" — 54.1% • У 14 присутствовало сопроводительное письмо — 37.8%• У 7 присутствовала информация в разделе "Портфолио" — 18.9%
Стоп, а где в ваших требованиях портфолио, вышка и обо мне?
Ну ладно, "Обо мне" можно считать требованием по дефолту, но портфолио и вышка для HR?
Любой вариант с применением индекса, что по департаменту, что по департаменту с зарплатой, получился примерно на порядок быстрее без оного. Что наводит на мысль, что применение индекса куда эффективнее, чем выбор "правильного" решения. Тем более, что "одноразовые" выборки в реальной жизни имеют тенденцию становиться дашбордами и регулярными отчетами.
Попробуйте сначала перевести в HSL. Подозреваю, что цвет (H) не сильно изменится от солнца. Точнее, он, конечно, изменится, но в ожидаемую сторону - в желтую на солнечной стороне.
На трассировку требований нет запроса. На выявление есть, но неявно. Чаще к аналитику приходит задача от PO в виде "вот я написал, что надо, со смежниками Васей и Валей договорился, скажи срок, когда напишешь требования". Правда, кто такие бесфамильные Вася и Валя, какое они имеют отношение к задаче, и в чем состоят договорённости - остаётся неизвестным.
Как не каждый разработчик стремится стать инженером, так не каждый аналитик стремится стать продукт овнером.
Мне кажется, потребителю сервиса надо знать, что регистрация клиента прошла или нет, а не то, отправил ли сервис что-то куда-то. Потому что если сервис регистрации упал с ошибкой, то потребитель попробует повторить регистрацию, но в этот раз у него не получится, так как клиент уже зарегистрирован, просто потребитель не в курсе.
То есть сервис должен падать только при невозможности выполнения его основной функции - регистрации, а все сопутствующие действия либо проводить без прокидывания exception наверх, либо, если это важно, откатывая регистрацию. Тогда у потребителя будет четкое понимание: выполнилось успешно - значит регистрация прошла; exception - значит регистрации не случилось.
А еще registerClient упадет, если упали на маппинге или не удалось достучаться до Кафки, хотя сама регистрация клиента была успешно выполнена. Впрочем, это тема уже для другой статьи.
Это вы рассматриваете вариант, когда уволится аналитик, который с требованиями работал. А интервьюируемые - уже не аналитики.
Если уволится лидер компетенции - в моменте ничего не изменится. На продолжительном сроке, возможно, аналитики из ведомой им группы аналитиков несколько притормозят в своем профессиональном развитии, но это если (а) лидер реально им помогал развиваться и (б) качество аналитиков в данной корп. среде имеет значение.
Если уволится Solution Architector - в моменте ничего не изменится. Могут приниматься архитектурные решения без него, теми же аналитиками, например. На продолжительном сроке эти решения могут оказаться технологическим тормозом для развития бизнеса. А могут и не оказаться.
Если уволится Product Owner - появится новый, которого аналитики введут в курс дела.
Во-первых, вы путаете карьеру специалиста и карьеру руководителя. Углубление знаний и навыков не делает из специалиста руководителя.
Во-вторых, только этот вариант и остаётся.
Короче, вся статья посвящена систематической ошибке выжившего и потому не стоит затраченного на нее времени.
Полагаю, что аналитиков среди 120 человек команды будет не менее 10 процентов.
Также полагаю, что этим 12 аналитикам уже некуда расти в карьерном смысле, т.к. должность лида компетенции уже занята и освобождаться не собирается.
Если у вашей команды или отдела проблема, то есть лайфхак - не проводить встречи 1-1
Впечатление "поехавшего кукухой деда на таблетках" нехило так создается, когда дед предлагает решения, которые молодежь еще не понимает, а деду кажется тривиальным. Приходится деду ограничивать свою инициативность.
Вопрос другой обсуждался - знаете ли Вы, что для спуска с орбиты спутники дают тормозной импульс. Оказалось, что не знаете.
Больше я к вам вопросов не имею.
Специально для вас
В руках я держал чек, выписанный Чарли. Сумма в нем позволила бы отдохнуть пару недель в Майами с подружкой, но я знал, что очень скоро на моем пороге вновь появится Чарли.
Важным для вакансии инженера, не для вакансии HR
Стоп, а где в ваших требованиях портфолио, вышка и обо мне?
Ну ладно, "Обо мне" можно считать требованием по дефолту, но портфолио и вышка для HR?
Qt Creator 14.0.0 for Windows 64-bit (335 MB) (info)
Qt Creator 14.0.0 for Linux 64-bit (219 MB) (info)
Qt Creator 14.0.0 for Linux ARM 64-bit (207 MB) (info)
Qt Creator 14.0.0 for macOS (227 MB) (info)
Не лишний раз упомянуть автора библиотеки pymorphy2 от @kmike
"В скрытую HR" - то есть пересылаем приглашение на встречу HR, ставя его адрес в скрытую копию, чтобы сотрудник не понял, что щас его увольнять будут.
Любой вариант с применением индекса, что по департаменту, что по департаменту с зарплатой, получился примерно на порядок быстрее без оного. Что наводит на мысль, что применение индекса куда эффективнее, чем выбор "правильного" решения. Тем более, что "одноразовые" выборки в реальной жизни имеют тенденцию становиться дашбордами и регулярными отчетами.
С заднего end-а, вестимо