Kotlin *

Когда я стал решать задачу получения сообщений из Telegram для последующего анализа, понял — не хватает простого и понятного введения во взаимодействие с Telegram в роли клиента, а не бота. Официальная документация Telegram отличается от привычной мне документации в мире Java и Rust как по подаче, так и по качеству. Большинство статьей по запросу "how to load chats from telegram" отсылают к высокоуровневым библиотекам на Python.

Главная цель статьи дать основу для разработки приложений на Telegram на среднем уровне абстракции TDLib и взаимодействие с Telegram c помощью посылки и получения сообщения MTProto. В этой статье я постарался раскрыть как надо читать документацию мессенджера, какие существуют способы взаимодействия с платформой и по каким принципам спроектировано API. Во многих местах я не буду давать детальное описание всех параметров, предоставив вместо этого ссылку на документацию. Задача статьи — дать фундамент для разработки своих сценариев. Несмотря на использование Kotlin, информация из статьи будет полезна для любого языка программирования.

Детально раскрыты следующие сценарии взаимодействия: вход в Telegram зарегистрированным пользователем; получение списка чатов и их типизация (каналы, формы и т. п.); получение сообщений из чата.

Мне 18 лет, и последние несколько месяцев я разрабатываю Xipher — мессенджер, который пишу с нуля на C++ (бэкенд) и Kotlin (Android). В какой-то момент я захотел добавить фичу, которой нет ни в одном популярном мессенджере: режим, в котором переписку невозможно подделать — ни участникам, ни мне как владельцу сервера, — и это можно проверить независимо, без доступа к серверу.

Так появился Xipher Provable Chat. В этой статье разберу, как именно это реализовано, какие решения я принял и с какими проблемами столкнулся.

Мне нужен был простой инструмент: список задач, учёт расходов и таймер для фокусировки. Казалось бы — чего проще?

Но вот реальность...

В одном и том же null часто прячут разные смыслы: “нет значения”, “неизвестно”, “неинициализировано”. Потом это всплывает в NPE и в кривой логике исполнения.

В Ceylon эту проблему решают через типовую систему, через Union типы. Подробнее, в переводе от Spring АйО.

Соблюдение определённой структуры пакетов или архитектуры крайне важно. Особенно в Java, где для корректной работы некоторые элементы должны быть public или действительно доступны за пределами своего пакета.

В новом переводе от команды Spring АйО рассмотрим библиотеку с открытым исходным кодом ArchUnit, которая помогает в тех случаях, когда одного компилятора недостаточно.

Привет, Хабр! На связи Дима Мандельштам, мобильный разработчик в core‑команде Яндекс 360, и Лёша Карпенко, руководитель команды дизайн‑системы. Дизайн — часть повседневной работы наших команд, и он не живёт отдельно. Поэтому сегодня в статье мы вместе поговорим о том, как мы собирали компонент List‑item.

Мобильные разработчики в этой статье найдут метод, с которым можно достичь баланса между гибкостью кода и простотой поддержки. Мы расскажем, как применили data‑driven‑подход к рефакторингу UI: написали анализатор AST для поиска реальных паттернов использования и вывели математическую метрику сложности API. А ещё расскажем о том, как аргументировать и провести масштабную переработку legacy‑кода, не останавливая продуктовую разработку.

Продуктовым дизайнерам будет интересен альтернативный взгляд на проектирование List‑item в дизайн‑системе. Мы разберём, как собирать List‑item — как универсальный компонент с максимальной гибкостью или как набор семантических шаблонов под конкретные сценарии.

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

Records, pattern matching и sealed-типы сделали Java куда более «функциональной» — читать вложенные данные стало легко и красиво. Но как только вам нужно изменить что-то глубоко внутри неизменяемой структуры, начинается боль: каскад пересоздания records, копирование полей, десятки строк ради одного изменения.

В новом переводе от команды Spring АйО рассмотрим, почему у современной Java всё ещё есть пробел в истории неизменяемости — и как оптики закрывают его. Если pattern matching — это про элегантное чтение, то оптики дают то, чего так не хватает, — композиционную запись: определили путь один раз и дальше меняете вложенные поля одной строкой, без ручной реконструкции и без циклов.

В прошлой серии мы научились вытаскивать из машины данные. Мы знаем скорость, обороты двигателя и даже какая дверь открыта. Руки чешутся вывести всё это на огромный экран в 4K, добавить анимаций, графиков и запустить YouTube на фоне, да?

Не спешите.

Если вы сделаете это, ваше приложение никогда не попадет в стор. А если вы работаете на OEM (автопроизводителя) и протащите это в прод — вас, возможно, проклянут водители, въехавшие в столб, пока разглядывали ваш красивый график расхода топлива.

Сегодня говорим о Driver Distraction — главной боли и главной фишке разработки под авто. О том, как сделать интерфейс, который не убивает.

Android-приложение может быть написано аккуратно и архитектурно выверено, но это не гарантирует быстрый запуск и стабильную работу в проде. Значительная часть задержек рождается на уровне ART: загрузка классов, интерпретация dex-кода, JIT-компиляция «горячих» методов и постоянный сброс прогрева после обновлений.

В статье разберём, как Baseline Profiles позволяют управлять install-time оптимизациями, что именно они меняют в жизненном цикле приложения и почему в реальных кейсах это даёт измеримый прирост производительности.

Привет, Хабр!

Вот мы уже полтора месяца в новом году, пора бы встретиться и обсудить насущные вопросы, что думаете?

Это мы приглашаем вас на наш первый в 2026 году Java Rock Stars Meetup. Надеемся, вы соскучились по нам и нашим митапам так же сильно, как и мы по вам!

Регистрация открыта, но количество мест ограничено.

Для кого статья: для собеседующих в первую очередь, и для кандидатов.
О чём статья: о задачах, разработанных мною для технических интервью бэкенд-разработчиков уровня middle и выше.
Об авторе: лид стрима в облачном провайдере, набирал большую часть команды в 2024-2025, пришлось скорректировать процесс проведения интервью.

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

Record-классы удобны, пока класс = «состояние, всё состояние и ничего кроме». Любое отклонение (API канонического конутруктора не равно внутреннему представлению, нужно наследование) ломает «автогенерацию» и паттерн-деструктурирование (destructuring).

В новом переводе от команды Spring АйО статьи Brian`а Goetz`а, архитектора Java Language, предлагается следующий шаг в направлении data-oriented programming in Java: классы-носители и интерфейсы-носители (они же Carrier classes & interfaces). Концептуально, carrier классы родились из record-ов путем ослабления части их ограничений.

Комментарий от Михаила Поливаха: Друзья, помните, пожалуйста, что данная статья по сути является суммированием обсуждения Carrier классов из JDK Project Amber Mailing List. Я это к тому, что пока непонятно, в какой версии языка carrier классы появятся, и появятся ли они в том виде, в котором представлены в статье. Статью стоит рассматривать как пищу для размышления.

В новом переводе от команды Spring АйО рассмотрим, как можно ускорить Java-приложения без переписываний: в свежих JDK появились Ahead-of-Time оптимизации кэша, которые выносят «дорогие» этапы загрузки/линковки классов (и даже частично профилирование методов) из рантайма в заранее подготовленный артефакт.

Рассмотрим как устроен AOT-кэш в JDK 24–26, какие есть workflow (3 шага vs 2 шага/в один прогон), где прячутся подводные камни вроде удвоения требований по памяти при -XX:AOTCacheOutput, и какие практики обучения помогут реально сократить время старта и быстрее выйти на пик производительности.

Меня зовут Вячеслав, и я — «процессуальный хирург».
Сейчас адвокат. Из них 20 лет я провел по ту сторону баррикад — работал следователем, помощником прокурора и прокурором.

Моя работа в суде — не красивые речи, а поиск багов. Я берусь за дела, где система дала сбой: следствие допустило ошибку, суд закрыл глаза. Я провожу аудит материалов, нахожу фатальное нарушение (баг в процедуре) и «ломаю» приговор. Я не работаю ради процесса — я либо вижу техническую возможность отмены, либо честно говорю клиенту: «Тут WontFix».

Год назад я понял, что мне нужен инструмент, который работает так же бескомпромиссно, как я сам. Мне нужен был цифровой ассистент...

Всем привет! Сегодня я расскажу, как мы переводили наши Java-команды на новые рельсы.

Проблема:

В прошлом год стало ясно, что покупать лицензии Intellij IDEA проблематично. Предложения с ресурсов вроде «Авито»выглядели сомнительно и небезопасно. И российский рынок разработки очень плотно занялся переездом на свои решения, заказчики требовали использовать сертифицированное по местным реалиям ПО и все такое прочее. О переезде на новую среду не говорил разве что кто-то совсем уж ленивый.

С чего мы начали:

Изучив заново рынок, мы (я и другие лиды, которым на плечи легла эта ноша) стали анализировать доступные решения. Пишем мы чаще всего, используя Spring Framework и технологии около него, хотя иногда и вынуждены адаптироваться к конкретным пожеланиям заказчика и рекомендуемым им технологиям. Но фокус-группа акцентировала внимание вокруг Spring.

Давайте представим типичную ситуацию для разработчика: вы делаете фичу, код проходит ревью, тесты «зеленые». На первый взгляд все хорошо, вы отправляете её в релиз. А потом на проде обнаруживается визуальный баг: текст наехал на текст, цвет оказался не тот, отступ съехал. Бывало такое?

В чем проблема – ведь тесты были пройдены успешно? Дело в том, что юнит-тесты проверяют только логику. Им все равно на то, как выглядит экран.

А screenshot-тесты нужно писать вручную в большом количестве. В классическом подходе мы прописываем каждый тест, но что если у вас 50 экранов по 5 состояний на каждый? Так как же быть, если не хочется писать 250 тестов вручную, а проверку сделать нужно?

В этой статье я расскажу какие инструменты для вызова нативного кода существуют для
Kotlin Multiplatform, и как я сделал собственный Gradle-плагин для генерации биндингов к C/C++ под JVM, Android, Native и JS.

Хаотичные события в Android (навигация, тосты, запросы) часто превращаются в источник багов и нечитаемого кода. В этой статье вы узнаете, как использовать sealed-интерфейсы Kotlin для создания полной, типобезопасной модели экрана, где состояния и события управляются отдельно и предсказуемо. Вы научитесь превращать одноразовые побочные эффекты в строго контролируемый поток команд, получите compile-time гарантии, избавитесь от багов с поворотом экрана и сможете легко тестировать любые события UI. Рассмотренный подход не только защищает от ошибок, но и кардинально упрощает масштабирование логики. Вы сможете добавлять новые события без риска сломать существующую функциональность, а ваш UI-слой станет чистым и декларативным. При этом всё, что нужно для внедрения - это понимание базовых принципов Flow и ViewModel.

Если вы разрабатываете на Kotlin, то наверняка сталкивались с генерацией кода: аннотации, которые необычным образом создают за вас кучу шаблонного кода.

Dagger/Hilt генерирует DI‑классы, Room генерирует DAO и сущности, Moshi генерирует JSON и т.д. Это экономит тонны времени. Но долгие годы для Kotlin‑проектов приходилось использовать KAPT — Kotlin Annotation Processing, прослойку для совместимости с Java‑аннотациями.

KAPT работал, но имел свои минусы. Он генерирует Java‑стабы из Kotlin‑кода и прогоняет стандартный Java Annotation Processor. Эта махинация замедляет компиляцию: сначала компилятор Kotlin должен переварить ваши исходники в промежуточные Java‑классы, потом снова всё это компилировать. Плюс, KAPT порой криво понимал Kotlin фичи, потому что мыслил категориями Java.

И вот появился Kotlin Symbol Processing (KSP). Это библиотека, которая позволяет писать процессоры напрямую для Kotlin. Обещают до 2х ускорения сборки по сравнению с KAPT, полную поддержку всех фич языка и мультиплатформенность.

Всем привет! На связи команда Explyt Spring. Недавно у нас вышел очередной релиз, который включает поддержку MCP Server plugin. Мы добавили “тулы”, облегчающие работу со Spring проектами для LLM. Ранее у нас уже была статья, в которой мы рассказывали об интеграции с Explyt AI плагином. Это были простые промпты для генерации: DTO, Entity, SQL скриптов и прочего. Несмотря на свою простоту, они добавляли в промпт необходимую информацию для выполнения конкретного действия: необходимый файл, тип БД - который подключен к проекту, библиотека для работы с Entity - javax или jakarta и прочее. Теперь пришло время добавить полноценные агентские Spring "тулы" для LLM, чтобы более точно понимать контекст Spring приложения.