Как вы думаете, какие характеристики сильнее влияют на скорость сборки вашего проекта: частота CPU или частота оперативной памяти? Количество ядер CPU или количество оперативной памяти? Влияет ли скорость постоянной памяти на скорость сборки? Однажды у меня в голове возникли такие вопросы, и я решил найти на них ответы. Лучший способ для этого — провести тесты. Поэтому представляю вам их результаты и попытаюсь их объяснить в меру своих знаний. Если хотите узнать, что больше всего влияет на скорость сборки, ну или, может быть, хотите обновить компьютер для сборки, но не знаете, во что лучше вложится, то добро пожаловать в статью.

Поговорим сегодня про context receivers — фиче Kotlin, про которую я узнал давно, но смог найти применение лишь пару месяцев назад. Расскажу о том, что такое context receivers, где их можно использовать, и, конечно же, про «успешный успех» — минус 60% самописного DI в OzonID SDK. Но обо всём по порядку.

> С 10 апреля 2024, 3 месяца спустя,
> данная статья заблокирована РКН на территории РФ,
> но доступна с IP других стран, а также через веб-архив.

На фоне прошлогоднего обострения цензуры в РФ, статьи автора MiraclePTR стали глотком свободы для многих русскоязычных айтишников. Я же хочу приоткрыть дверь к свободной информации чуть шире и пригласить «не‑технарей» («чайников»), желающих поднять личный прокси‑сервер для обхода цензуры, но дезориентированных обилием информации или остановленных непонятной технической ошибкой.

В этой статье я описал универсальное решение, которое обеспечивает прозрачный доступ к международному интернету в обход цензуры, использует передовые технологии маскировки трафика, не зависит от воли одной корпорации и главное — имеет избыточный «запас прочности» от воздействия цензоров.

Статья рассчитана на «чайников», не знакомых с предметной областью. Однако и люди «в теме» могут найти нечто полезное (например, чуть более простую настройку проксирования через CloudFlare без необходимости поднимать nginx на VPS).

Если у вас ещё нет личного прокси для обхода цензуры — это знак.

Думаю, каждый из нас периодически сталкивается с непонятными микрофризами при взаимодействии с, казалось бы, простым UI…

Просто скролишь список, и тут — бац! Лагнуло! Сегодня я бы хотел разобрать одну из множества причин такого поведения — работу с ресурсами. Мы разберёмся, в каких случаях работа с ресурсами может стать проблемой. Почему это происходит и как лучше всего от этого избавится.

Тема многомодульности уже давно витает в среде Android-разработчков. За много лет проб и ошибок, выработались определённые подходы к разбиению приложения на модули. В целом о принципах разбиения на модули есть хорошая статья Андрея Берюхова: https://habr.com/ru/company/kaspersky/blog/520766/

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

Всем салют!

Хочу рассказать вам историю о том, как я начинал с уровня — «не могу решить даже 1 easy задачу из 10» до уровня — «могу решить каждую вторую medium задачу» и прошел несколько coding сессий в таких компаниях как Meta, Booking, Careem, Avito...

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

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

Учитывая что некоторые из разработчиков не имеют опыта работы в лидовской позиции или имеют минимальный опыт, я решил организовать серию мастер-классов для начинающих тимлидов.

Фидбэк от команды оказался позитивным, поэтому я решил поделиться знаниями и с сообществом.

В этом посте я начну с самых основ - поделюсь как я выстраиваю коммуникацию с каждым отдельным участником команды. Если пост получит хороший отклик - постараюсь раскрыть и другие темы.

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

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

Возможно вы думаете обработка таких исключений происходит как обычно в Kotlin/Java коде. К сожалению, при использовании вложенных корутин, все может работать не так как ожидается.

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

«Корутины - это легковесные потоки», сколько раз вы слышали эту формулировку? Она что-нибудь вам говорит? Скорее всего не очень много. Если вы хотите узнать больше о том, как на самом деле корутины выполняются в рантайме Android, как они связаны с потоками, а также о проблемах параллелизма, которые неизбежны при использовании потоковой модели языка программирования Java, то эта статья для вас.

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

Эта статья пригодится тем, кто не имеет хоть какой‑то системы по управлению делами, но которому она нужна, так как, например, стало тяжело справляться лишь только за счёт своей памяти или каких‑то мелких чек‑листов на обрывках салфеток. Статья предполагает, что вы будете читать и делать всё в ней написанное. Иначе говоря, статья является практически пошаговой инструкцией, т. е. в ней не будет каких‑то уж совсем незаурядных методов или взглядов.

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

Будет нелишним, если вы прочитаете мою прошлую статью про основные принципы систем, которые помогают достигать поставленных целей.

В этой статье будет показано как можно начать организовывать свою базу знаний в Obsidian, отталкиваясь от источников. В статье будет разобрано то, какие стоит использовать папки и теги; как создать свою первую точку входа в систему. Также будет уделено внимание способу ведения журнала (дневника). Статья будет предполагать, что вы не против автоматизации процессов в своей базе знаний, поэтому все источники будут шаблонизированы и впоследствии собраны в свои отдельные библиотеки с помощью dataview. Завершится статья подробным примером (алгоритмом) рабочего процесса.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.