Автоматическая конфигурация интерфейсов в зависимости от характера работы пользователя — задача ой какая непростая, но, кажется, посильная. Сегодня я расскажу, с чего наша Android-команда начала разработку персонализированного интерфейса, какие данные мы получили в ходе экспериментов, какие выводы сделали и как эти знания повлияли на дальнейшее развитие всего продукта. Если пропустили предисловие, то вот первая часть — о преимуществах и недостатках идеи.

Недавно я принял решение развернуть в офисе на рабочем компьютере Hackintosh. Все получилось. Единственное, что мне не нравилось это отсутствие медиа клавиш на офисной клавиатуре. Ими я привык управлять музыкой, в том числе на сервисе Yandex.Music. Данная статья посвящена тому, как я исправил ситуацию.

Вероятно, в любой команде рано или поздно возникает вопрос создания и утверждения стандартов кодирования. На первый взгляд, задача вполне тривиальная. Но лишь в том случае, когда решается на раннем этапе развития проекта. Тогда разработчикам необходимо лишь выбрать и применить один из популярных стандартов, и чаще всего этот выбор за них делает фреймворк, который они используют.

В нашем случае всё не так просто. Проект, над которым мы работаем, начал свою жизнь ещё до того, как различным стандартам и описаниям лучших практик в среде разработки стали уделять большое внимание. В том числе, задолго до появления столь популярных ныне PSR стандартов для PHP. По этим причинам задача стандартизации кода не ставилась на более ранних этапах, а теперь – предстала нашей команде в качестве вызова.

В этой публикации мы расскажем о том, как пришли к пониманию необходимости единого code style, и выработали методы его постепенного внедрения в масштабный проект. Этот опыт может быть интересен тем, кто пока не использует стандартизацию, но уже ощущает в этом потребность.