Compose — относительно молодая технология написания декларативного UI. Множество разработчиков даже не предполагают, что пишут неоптимальный код в такой критически важной части, и впоследствии это приводит к неожиданной низкой производительности и проседании метрик.

Наша команда Ozon Seller также столкнулась с этой проблемой. Мы решили собрать воедино все советы и наработки по написанию оптимизированного Compose-кода. Активное применение этих советов при оптимизации существующих экранов и написании новых существенно улучшило наши метрики: длительность лага по отношению к длительности скролла (hitch rate; чем меньше, тем лучше) экранов со списками упала в среднем с 15-19 % до 5-7 % (на 90-м перцентиле). Все эти советы и наработки мы описали в этой статье. Она будет полезна и начинающим, и опытным разработчикам, в ней подробно описаны оптимизации и механизмы Compose, а также рассказано про слабо задокументированных особенности и исправления ошибок, которые есть в других статьях. Давайте же начнём.

Android-разработчик red_mad_robot Серёжа Чумиков рассказывает о том, как сделать классную анимацию, не перегрузив смартфон, почему ей не нужна рекомпозиция и как её избежать.

Работаю я в бюрократизированной конторе с плохими процессами. Текучка тут достаточно большая. Люди приходят и уходят. Менеджмент на уровне дна. В какой-то момент в команду докинули нового разработчика (с неясными целями и задачами). Ну вроде парень умный, вроде что-то делает, вроде не просто так.

Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на совещаниях ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.

Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «‎а что так можно было?»‎. А я понял, что нельзя так просто взять и посмотреть статистику коммитов.

Введение

Я делала много вещей с компьютерами, но в моих знаниях всегда был пробел: что конкретно происходит при запуске программы на компьютере? Я думала об этом пробеле — у меня было много низкоуровневых знаний, но не было цельной картины. Программы действительно выполняются прямо в центральном процессоре (central processing unit, CPU)? Я использовала системные вызовы (syscalls), но как они работают? Чем они являются на самом деле? Как несколько программ выполняются одновременно?

Наконец, я сломалась и начала это выяснять. Мне пришлось перелопатить тонны ресурсов разного качества и иногда противоречащих друг другу. Несколько недель исследований и почти 40 страниц заметок спустя я решила, что гораздо лучше понимаю, как работают компьютеры от запуска до выполнения программы. Я бы убила за статью, в которой объясняется все, что я узнала, поэтому я решила написать эту статью.

И, как говорится, ты по-настоящему знаешь что-то, только если можешь объяснить это другому.

Более удобный формат статьи.

Android разработчики обожают DI. Куда ни посмотри, куча статей и выступлений про Dagger 2, Hilt или Koin, но очень мало про Kodein. Даже на Хабре всего пару неплохих статей, но и те от 2018 года. Но с тех пор Kodein бурно развивался, и вышло много мажорных версий, API значительно изменился.

Мы используем Kodein в приложении Drinkit и успели прочувствовать на себе плюсы и минусы этого инструмента. Я расскажу, как пользоваться Kodein, как у него дела со скоупами и многомодульностью.

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

От автора поста: ниже представлен Kotlin Code Style на 2 мая 2023 года. Конвенция постоянно меняется, но основные принципы уже заложены и неизменны. Перевод предоставлен без комментариев, как есть.

В личные на vc.ru мне пришел такой фидбэк.

Подробный рассказ о том, как я свой дом и сад сделал умными. С фото, техническими деталями, стоимостями и выводами на будущее.

Здравствуйте!

В этой статье речь пойдет про вариантность параметризованных типов в Котлин.

Цель данной статьи дать первичное понимание работы ковариантности и контрвариантности в Котлин. Здесь будет рассмотрено использование ключевых слов in и out в параметризованных типах.

Наткнулся на данную статью случайно, когда находился в очередном поиске ответа на вопрос "Как же так?!" в интернете. Автор данной статьи занимается мобильной разработкой, но тем не менее его наблюдения и выводы касательно владения кодом разительно перекликаются с моими:

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

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

Забавная ситуация: сайтов и сервисов, доступных только через VPN, все больше, но при этом многие российские компании закрывают доступ из-за границы. В результате приходится целыми днями теребить ползунки «вкл-выкл», что утомительно. Я расскажу, как с помощью магии маршрутов и WireGuard, решить эту проблему и сделать «умный» VPN, который не надо отключать.

Если ты пользуешься VPN, то и сам наверняка сталкиваешься с блокировками зарубежного трафика. К примеру, могут не открываться pochta.ru, leroymerlin.ru, rt.ru, avito.ru.

Получается мем.

Каждый с этим борется как может. Например, на устройствах Apple родными средствами можно настроить автоматизацию, которая будет запускать VPN, когда открываешь определенные приложения (например, Twitter), а когда выходишь из них — выключать обратно. Но это костыль, а хочется все сделать красиво, да еще и прокачать навык работы с сетью.

Поэтому мы сейчас попробуем «включать VPN чуть-чуть».

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

Периодически меня на начальном курсе просят дать "список всех-всех команд с кратким описанием что делает"... Ну прям "всех-всех". И ведь если искать в интернете "такие" справочники существуют - либо про "20-30 команд, но самых важных", либо с неточностями и устаревшей информацией. Так что предлагаю вашему вниманию свою версию такого "краткого" справочника (на 300, 515, 612, 716, 842, 1005, 1110 команд) с ссылками на wiki-описание и на cheat.sh-примеры наиболее важных команд.

Всем известный закон Мёрфи гласит: «Если что-то плохое может случиться, то оно обязательно произойдет». Согласитесь, не самая позитивная установка, особенно когда это касается работы. И тут мне стало любопытно, а есть ли такие законы, которые мне, как ИТ-специалисту, максимально помогут избежать «чего-то плохого». К своему удивлению, я их нашел, и даже не один. Потому делюсь с вами сегодня своими сакральными знаниями в блоге ЛАНИТ. 

Здесь собраны лучшие и самые полезные репозитории Github, которые будут служить вам долгое время.

Это продолжение нашего рассказа о внедрении Kotlin Multiplatform Mobile в QIWI. Если хотите узнать больше про технику, посмотреть на код, переходите в первую часть. В этой статье будет больше контекста про то, как мы принимали решение, готовили прототип и внедряли технологию в команды. Наш опыт может помочь вам “продать” KMM в вашей компании и вашим стейкхолдерам. Я расскажу о плюсах и сложностях, с которыми мы столкнулись на нашем пути.

Немного истории

В QIWI мы часто пробуем что-то новое в наших процессах и в разработке. За последние 5 лет мы создали несколько приложений с нуля, используя разнообразные подходы. Например, мы впервые попробовали кросс-платформу, когда делали приложение QIWI Инвестор. Мы использовали инструмент J2ObjC, чтобы конвертировать общий модуль с кодом на Java на Objective-c для iOS. Это решение было смелым, но не самым надежным. По ходу использования было много проблем, самые большие — с конвертацией кода сторонних библиотек. В итоге проект закрылся, как и этот эксперимент. Кросс-платформенный подход оказался рабочим, но мы отложили его в сторону пока не появился более надежный инструмент.

В 2018 году мы перешли от платформенных команд к кросс-функциональным. Это стало самым большим изменением в процессе разработки c внедрения скрама. “Совместное владение кодом” стало нашей новой ценностью. Границы между платформами начали размываться, мы стали внимательнее изучать код на других платформах, вместе принимали решения и делились лучшими практиками.

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