В таком случае вёрстку контента можно обернуть в контейнер с поддержкой скролла (на случай, когда контент полностью не помещается на экране) + добавить в тулбар возможность обработать жест скролла. То есть чтобы можно было за тулбар потянуть и схлопнуть заголовок.
Привет! Кажется, вопрос больше про визуальный дизайн UI, а не про технологию его реализации (Compose/View).
для собственно содержимого старницы место-то остаётся на экране, например, в ландшафтном режиме
Как увидеть весь текст длинной надписи в портретном режиме, когда не помещается полностью?
Переход от большого заголовка к маленькому при скролле как раз создает компромисс между видимостью контента экрана и заголовка. При открытии экрана пользователь сначала видит большой расхлопнутый заголовок, где текст не обрезается и всегда помещается полностью: тулбар в таком состоянии у нас растягивается по высоте всего текста заголовка (в ландшафтном тоже все видно будет). Когда пользователь начинает скроллить, заголовок схлопывается в компактный вариант, уступая максимальное место контенту, на котором пользователь может сфокусироваться без отвлечения на верхнюю часть экрана.
Когда-то считали самописным Gradle-плагином в связке с https://github.com/cdsap/Talaiot, чтобы учитывать фактическое время сборки тасок, но сейчас эта фича есть в Gradle Build Scan (https://scans.gradle.com/). В build scan есть Timeline сборки и в поиске по нему можно поставить галочку "On critical path", чтобы подсветить участвующие в критическом пути таски. При этом для оценки критического пути важно запускать сборку с флагом --no-cache, чтобы исключить влияние кэша.
К сожалению, это не единственный случай. К нашей прошлой статье про единую сборку оставлял комментарий разработчик из Huawei с описанием рисков. Сначала мы надеялись с таким не столкнуться, но, столкнувшись, решили устранить риски наверняка :)
Разделение сборок кажется единственной гарантией не столкнуться с аналогичной историей в дальнейшем.
Да, не все захотят раскрывать свои продуктовые планы :) Но задачи в рамках техдолга или то, что уже на пользователях, обычно в меньшем секрете. Можно сформулировать вопрос из статьи не как "что у вас сейчас в бэклоге", а "расскажите, как работали над одной из недавних задач". Потенциальный выхлоп: на конкретном примере ознакомиться с процессами и получить зацепки для дополнительных вопросов.
В качестве общего фундамента для ИПР у нас два ингредиента:
1. Описание ролей в виде ожиданий и зон ответственности. Например, инженер технической и продуктовой команды это разные роли. Роли в отличие от грейдов это качественная, а не количественная характеристика.
2. Общая модель компетенций из конкретных навыков, где для каждого навыка описаны уровни экспертизы (тут как раз количественная оценка). Примеры навыков: проведение ресерчей или владение фреймворком X.
Сперва мы выбираем роль, а затем смотрим, какие навыки актуальны в ее рамках. Грейд определяется по совокупной оценке этих навыков.
Так как ИПР это индивидуальный план развития, то со временем появляются и уникальные роли, которые представляют из себя модификации базовых ролей для конкретного человека. Например, роль продуктового разработчика, который также активно участвует в развитии платформенной дизайн-системы.
Привет! Вероятно, вы чувствуете себя достаточно уверенно на собеседованиях, но есть люди с меньшим опытом, которые могут теряться и иметь другие представления об очевидном. Основной тезис статьи в том, что соискатель тоже собеседует работодателя. Есть соискатели, которые об этом, к сожалению, забывают.
Все "очевидные" вопросы здесь собраны на основе того, что у нас спрашивают соискатели, но их задают далеко не все. Когда у нас об этом не спрашивают, мы все равно рассказываем ответы на них, чтобы сложить у соискателя полную картину того, как мы работаем. Это помогает обеим сторонам понять, насколько они матчатся друг с другом.
Привет! Описанное в статье применимо и к обработке аннотаций при компиляции Java-кода (начиная с Gradle 4.7). Kotlin упоминается лишь в связи с тем, что до Kotlin 1.3.30 не было поддержки инкрементальной обработки аннотаций на уровне kapt. С джавовым apt такой проблемы нет.
В таком случае вёрстку контента можно обернуть в контейнер с поддержкой скролла (на случай, когда контент полностью не помещается на экране) + добавить в тулбар возможность обработать жест скролла. То есть чтобы можно было за тулбар потянуть и схлопнуть заголовок.
Привет! Кажется, вопрос больше про визуальный дизайн UI, а не про технологию его реализации (Compose/View).
Переход от большого заголовка к маленькому при скролле как раз создает компромисс между видимостью контента экрана и заголовка. При открытии экрана пользователь сначала видит большой расхлопнутый заголовок, где текст не обрезается и всегда помещается полностью: тулбар в таком состоянии у нас растягивается по высоте всего текста заголовка (в ландшафтном тоже все видно будет). Когда пользователь начинает скроллить, заголовок схлопывается в компактный вариант, уступая максимальное место контенту, на котором пользователь может сфокусироваться без отвлечения на верхнюю часть экрана.
Когда-то считали самописным Gradle-плагином в связке с https://github.com/cdsap/Talaiot, чтобы учитывать фактическое время сборки тасок, но сейчас эта фича есть в Gradle Build Scan (https://scans.gradle.com/). В build scan есть Timeline сборки и в поиске по нему можно поставить галочку "On critical path", чтобы подсветить участвующие в критическом пути таски. При этом для оценки критического пути важно запускать сборку с флагом --no-cache, чтобы исключить влияние кэша.
К сожалению, это не единственный случай. К нашей прошлой статье про единую сборку оставлял комментарий разработчик из Huawei с описанием рисков. Сначала мы надеялись с таким не столкнуться, но, столкнувшись, решили устранить риски наверняка :)
Разделение сборок кажется единственной гарантией не столкнуться с аналогичной историей в дальнейшем.
Да, не все захотят раскрывать свои продуктовые планы :)
Но задачи в рамках техдолга или то, что уже на пользователях, обычно в меньшем секрете. Можно сформулировать вопрос из статьи не как "что у вас сейчас в бэклоге", а "расскажите, как работали над одной из недавних задач". Потенциальный выхлоп: на конкретном примере ознакомиться с процессами и получить зацепки для дополнительных вопросов.
В качестве общего фундамента для ИПР у нас два ингредиента:
1. Описание ролей в виде ожиданий и зон ответственности. Например, инженер технической и продуктовой команды это разные роли. Роли в отличие от грейдов это качественная, а не количественная характеристика.
2. Общая модель компетенций из конкретных навыков, где для каждого навыка описаны уровни экспертизы (тут как раз количественная оценка). Примеры навыков: проведение ресерчей или владение фреймворком X.
Сперва мы выбираем роль, а затем смотрим, какие навыки актуальны в ее рамках. Грейд определяется по совокупной оценке этих навыков.
Так как ИПР это индивидуальный план развития, то со временем появляются и уникальные роли, которые представляют из себя модификации базовых ролей для конкретного человека. Например, роль продуктового разработчика, который также активно участвует в развитии платформенной дизайн-системы.
Отличные советы, спасибо!
Привет! Вероятно, вы чувствуете себя достаточно уверенно на собеседованиях, но есть люди с меньшим опытом, которые могут теряться и иметь другие представления об очевидном. Основной тезис статьи в том, что соискатель тоже собеседует работодателя. Есть соискатели, которые об этом, к сожалению, забывают.
Все "очевидные" вопросы здесь собраны на основе того, что у нас спрашивают соискатели, но их задают далеко не все. Когда у нас об этом не спрашивают, мы все равно рассказываем ответы на них, чтобы сложить у соискателя полную картину того, как мы работаем. Это помогает обеим сторонам понять, насколько они матчатся друг с другом.