Представлен открытый проект Send it, with PairDrop (веб-версия проекта) — AirDrop для всех. Это универсальный способ передачи файлов на ПК и мобильных устройствах в браузере между Windows, Linux, Android, iOS, macOS и другими ОС:
работает без скачиваний драйверов и утилит и дополнительного ПО;
просто открываем сайт на обоих устройствах в браузере и начинаем передачу;
если используете одну сеть Wi‑Fi — устройства сразу увидят друг друга;
если используете разные сети — нужно один раз ввести шестизначный код, создать пару устройств, и дальше устройства будут находить друг друга автоматом;
передача файлов идем напрямую между устройствами;
можно передавать большие объёмы данных без ограничений.
Перед каждым релизом прохожу по одному и тому же списку. Не потому что умный, а потому что каждый пункт там появился после того как я облажался.
Три вещи которые горели чаще всего.
Разные версии Android. На эмуляторе всё красиво. На реальном устройстве со старой версией что-то обязательно едет. Держу под рукой старый телефон с Android 10, туда ставлю перед каждым релизом.
Разрешения. Забываешь добавить в манифест, на новых версиях система спрашивает пользователя, пользователь жмёт «запретить» и половина функций молча перестаёт работать. Без каких-либо ошибок в логах.
ProGuard и минификация. Локально всё работает. В release сборке падает что-то что ты вообще не трогал. Потому что минификатор убрал класс который использовался через рефлексию.
Список не длинный но каждый раз спасает от как минимум одного стыдного бага в продакшене.
Что у вас в чеклисте перед релизом чего нет у большинства?
Открытый проект RepoStore для смартфонов на Android превращает GitHub в Google Play и помогает найти любые Android‑приложения среди репозиториев. С помощью RepoStore можно быстро найти и открыть APK‑файл — у него будут описание и даже рейтинг. Всё разделено по категориям.
К 2026 году слежка переехала из очевидных приложений в незаметные — фоновые сервисы и функции, у которых нет даже иконки на экране. Вы их не видите. Они видят вас.
Я сделал Sovereign — приложение, которое делит один Android на три изолированных пространства:
Гражданин — госуслуги, банки, маркетплейсы, MAX, Telegram. Человек — личное: Signal, крипто-кошельки, торрент-хабы. Суверен — зашифрованный анклав для самого ценного.
Без root. Без облака. Без подписки.
Что умеет: рентген слежки приложений (X-Ray), хранилище с пост-квантовым шифрованием, ИИ прямо в телефоне офлайн, скрытый сейф.
Честно: это цифровая гигиена, а не режим невидимки для спецслужб. Никаких пустых обещаний.
Sovereign — часть экосистемы соло-разработчика Vladislav Shter. Рядом: Egregor (уже в продаже) и скоро уникальный SovereignWeb3 Browser.
Как записать "круглое" видео в мессенджере "BITCORD".
Пишу крутой облачный мессенджер (мини-соцсеть) под пилотным названием BITCORD. Недавно для него реализовал новую функцию отправки видеосообщений в форме "круглого" видео. Теперь любой пользователь может отправить своему собеседнику модное селфи без каких-либо специальных настроек. Это круто и весело, дополняет общение личной эмоцией.
Чтобы отправить такое видео, достаточно открыть чат и выбрать в верхнем выпадающем меню пункт "Селфи видео". Далее откроется небольшое диалоговое окошко, где необходимо нажать и удерживать кнопку "Hold" - после этого начнется процесс записи видео с фронтальной камеры смартфона.
Длительность записи ограничена по времени, чтобы не перегружать смартфон ресурсоемким процессом. После истечения лимита или как только пользователь отпустит кнопку, видео отправится на бэкенд для дальнейшей обработки.
Особенности видеосообщений:
Лимит времени: Максимальная длительность одного ролика составляет 10 секунд.
Формат: Видео автоматически обрезается в форме круга и записывается на фронтальную камеру.
Воспроизведение: В чате такие ролики проигрываются один раз при нажатии "Play".
Способ 1
Бэкенд приводит видео к "квадратному" формату с соотношением сторон 1:1 и возвращает ссылку на него обратно в чат собеседникам.
Ниже пример выполнения преобразования видео в "квадратный" формат с помощью "ffmpeg":
Чтобы отобразить "квадратное" видео в виде круга на Java, я создаю шаблон (ViewOutlineProvider). Он принудительно задает графическому элементу (View) форму идеального круга фиксированного размера:
private static final ViewOutlineProvider CIRCLE_PROVIDER = new ViewOutlineProvider() {
@Override
public void getOutline(View view, Outline outline) {
int sizeInPx = (int) TypedValue.applyDimension(
TypedValue.COMPLEX_UNIT_DIP, 270, view.getResources().getDisplayMetrics()
);
outline.setOval(0, 0, sizeInPx, sizeInPx);
}
};
Затем в холдере применяю описанный выше шаблон к TextureView и ImageView:
В результате выполнения этого кода видео примет "круглый" вид.
Способ 2
Как показала практика, кодирование видео в "квадратный" формат на бэкенде невыгодно, так как оно занимает время и нагружает сервер. Без хорошей видеокарты, которая на бэкенде часто отсутствует, работать с видео накладно. Поэтому я пошел другим путём.
Так как камера смартфона снимает видео не в "квадратном" формате, я воспользовался матрицей преобразования, центрировал кадр и обрезал лишние стороны.
//фиксированный размер видео с камеры смартфона: 480x640
float scaleY = h / (w * 480 / 640);
Matrix matrix = new Matrix();
matrix.setScale(1.0f, scaleY, w / 2f, h / 2f);
CircleVideoViewHolder vch = (CircleVideoViewHolder) holder;
vch.texture.setTransform(matrix);
При таком подходе вся работа выполняется на стороне графического процессора (GPU) самого смартфона с максимальной скоростью. Это полностью избавляет от необходимости обрабатывать видео на бэкенде.
В результате получилась вот такая красота:
селфи видео в круглом формате
Итог:
Перенос графических вычислений на сторону клиента (в данном случае на GPU смартфона) позволил решить сразу две важные задачи. Во-первых, это полностью разгружает бэкенд-сервер от тяжелых операций перекодирования видео. Во-вторых, обеспечивает пользователя мгновенным откликом интерфейса и быстроту отправки сообщения, так как обработка кадра происходит "на лету" прямо во время записи.
Спасибо за вашу поддержку. Это придает стимул писать дальше.
Сравнение Claude Code Fable и Codex Open AI по ходу работы над одним и тем же проектом
Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Claude Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.
Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.
Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь модели что делать и она делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.
И кстати, получилось сравнить с Codex'ом от Open AI, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.
Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.
Claude Code Fable в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.
Единственное, что может я так натаскал Claude. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.
И напоследок обнаружил в Claude очень полезную функцию оценки загруженности контекстного окна.
Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.
Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.
Для этого в чате Claude Code, в поле ввода достаточно ввести слэш команду - /context
Прикрепляю скриншот как это выглядит вживую
И ещё такое впечатление, что Claude Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.
Так что, удачи всем с проектами на этой бурной трудовой неделе!))
Сквозное шифрование, или как Telegram и Bitcord защищают переписку.
Хочу написать небольшой пост о сквозном шифровании, или, если использовать технический термин, E2EE (End-to-End Encryption).
Сегодня эта технология широко применяется во многих мессенджерах. Я тоже реализовал E2EE в мессенджере Bitcord . Однако далеко не все понимают, как именно работает этот механизм, поэтому попробую объяснить простыми словами.
Поскольку я являюсь разработчиком и основателем собственного мессенджера, реализовать эту схему для меня не составило особого труда. Главный секрет заключается в понимании принципов работы криптографических алгоритмов, таких как AES и RSA. Хотя современные реализации E2EE обычно используют не RSA, а алгоритмы на эллиптических кривых (например, X25519), я не стал прибегать к усложнениям.
Алгоритм AES я использовал для непосредственного шифрования текстового сообщения, которое один пользователь отправляет другому. Для шифрования применяется секретный ключ (или пароль). Основная проблема такого подхода заключается в том, что этот ключ необходимо каким-то образом передать получателю. Если злоумышленник перехватит ключ, он сможет расшифровать сообщение.
Чтобы этого не произошло, я использовал ещё один алгоритм - RSA. Для его работы требуется пара криптографических ключей: публичный и приватный. Так как RSA не предназначен для шифрования больших объёмов данных, я его использовал для безопасной передачи того самого секретного ключа, который используется алгоритмом AES.
В результате схема выглядит так.
Сначала текст сообщения шифруется алгоритмом AES с использованием случайного секретного ключа. Затем этот ключ шифруется алгоритмом RSA с использованием публичного ключа получателя. Когда получатель отправляет ответ, он выполняет ту же самую операцию, но уже с публичным ключом аппонента.
Важно понимать, что публичный ключ предназначен только для шифрования. Расшифровать данные с его помощью невозможно. Для расшифровки существует только соответствующий ему приватный ключ.
Когда получатель открывает сообщение, его устройство сначала с помощью приватного ключа RSA расшифровывает секретный ключ AES, а затем уже этим ключом расшифровывает само сообщение.
В моём приложении это работает следующим образом. Публичные ключи пользователей хранятся на сервере. Когда пользователь отправляет сообщение, приложение запрашивает у сервера публичный ключ получателя, шифрует сообщение на устройстве пользователя и отправляет на сервер уже зашифрованные данные. Сервер выступает лишь в роли посредника и пересылает этот зашифрованный пакет получателю. Сам сервер приватные ключи не хранит.
При этом приватные ключи никогда не покидают устройство пользователя. Они хранятся в защищённом хранилище смартфона, и получить к ним доступ не может ни сервер, ни разработчик приложения, ни кто-либо ещё. Поэтому расшифровать переписку может только владелец соответствующего приватного ключа.
В этом и заключается смысл сквозного шифрования: сервер передаёт сообщения, но не имеет возможности их прочитать.
Именно поэтому было довольно забавно наблюдать, как спецслужбы требовали у Павла Дурова "ключи шифрования", чтобы получить доступ к переписке пользователей Telegram. Никаких универсальных ключей у него нет и быть не может - приватные ключи находятся только на устройствах самих пользователей.
Именно поэтому требование "передать ключи" технически лишено смысла. Передавать попросту нечего.
П.С.
Я - сетевой долгожитель и начинал свой путь еще в эпоху Фидонета (FidoNet). Эта сеть была по-настоящему децентрализованной: никаких общих серверов и никакого DNS. Все строилось просто: компьютер, модем и терминальная программа для связи. Часто в роли узла (ноды) выступал сервер в банке, где знакомый сисадмин выделял адреса. При этом подключиться можно было к любому другому участнику, даже к частному лицу. Вот это и была настоящая децентрализация! Думаю, учитывая растущее давление регуляторов на современный интернет, мы скоро снова вернемся к проверенным идеям старого доброго Фидо.
Прямая Web3-монетизация без посредников (Peer-to-Peer) для артистов на радио.
Буквально вчера закончил написание сервисного бота для коммерческих нужд в мессенджере "Concord". Основной целью проекта является автоматизация процессов публикации авторского материала на интернет-радио. Бот был создан как помощник для авторов аудиоконтента: музыкантов, продюсеров, подкастеров и т. п.
Задача была непростой. Нужно было объединить возможности мессенджера с его токеномикой и реализовать передачу медиаконтента (картинок, аудиофайлов, текстовых данных) на удаленный сервер в формате JSON. Для этого я написал серверную страницу на PHP, в которой реализовал весь необходимый API.
При передаче медиаданных пользователь запускает нужного бота и отправляет ему в личные сообщения весь необходимый материал. Отправка изображения артиста и аудиофайла выполняется напрямую, без каких-либо команд. Бот сам идентифицирует тип данных, полученных от пользователя, и записывает их в локальные файлы. Вот как я реализовал проверку принадлежности данных к типу файлов:
function isJpeg(string $data): bool
{
return substr($data,0,2) === "\xFF\xD8";
}
function isMp3(string $data): bool
{
if (substr($data,0,3)==="ID3") {
return true;
}
return isset($data[1])
&&
ord($data[0])===0xFF
&&
(ord($data[1]) & 0xE0)===0xE0;
}
После получения данных нужно сразу определить что именно пришло - команда или файл:
if (preg_match('/^\/(help|bio|title|tracks|done)\b/i', $data))
{
processCommand($db, $uuid, $data);
exit;
}
if (isBase64($data))
{
saveBinary($db, $uuid, $data);
exit;
}
reply("Unknown command, please use /help.", false);
Описание профиля артиста и названия его треков передаются в текстовом виде используя специальный набор команд:
/help - Show this help
/bio text - Update artist biography
/tracks - Show info of all tracks
/title text - Update current track title
/pay amount - Pay for service
/done - Finalize current track
Send JPG image to update artist image
Send MP3 audio to update current track
Используя бота, артист может отправлять свои материалы в ротацию на радио для продвижения своего творчества. Протокол взаимодействия с ботом довольно простой:
артист отправляет фото профиля
артист отправляет описание профиля
артист загружает трек
артист отправляет описание трека
артист выполняет оплату сервиса
артист финализирует трек
Пока трек не финализирован, артист может изменять любые данные. Финализация трека возможна только после выполнения всех вышеуказанных действий. После этого любые отправленные артистом данные активируют запись уже нового трека, и процесс повторяется. При этом данные профиля артиста можно изменять без ограничений.
МОНЕТИЗАЦИЯ
Отправка материала артистом требует платы за сервис. Когда артист подтверждает оплату, бот списывает с его кошелька требуемую сумму и зачисляет её на кошелек владельца радиосервиса. Это значительно упрощает обмен активами между плательщиком и получателем.
Таким образом, технология Web3 с использованием блокчейна позволяет оперативно выполнять оплату за предоставленный сервис без лишних трат и банковских процедур. При этом все транзакции становятся видны в блокчейне уже через несколько минут.
схема работы блокчейна
Следующим этапом разработки я планирую реализовать возможность начисления роялти каждому автору музыкального материала. Для этого потребуется создать публичную таблицу рейтинга на сайте радио, где слушатели смогут голосовать за понравившиеся треки, продвигая артиста на верх списка. Исходя из количества прослушиваний конкретного трека, можно будет рассчитать сумму роялти и автоматически выплачивать её на личный кошелек автора в мессенджере.
Таким образом, объединение двух разных сущностей, а именно интернет-радио с приложением для обмена сообщениями, является неким ноу-хау для оказания помощи в развитии молодых дарований. Лично для меня как для разработчика это отличный вызов и прекрасная возможность "пошевелить мозгами".
Если у вас появятся предложения, буду рад подискуссировать.
Новая настройка появилась в модели — значит, нужно добавить соответствующий UI‑компонент, настроить обработчики, связать все с системой хранения и не забыть ничего по пути.
Пока настроек немного, это не вызывает проблем. Но со временем поддержка такого экрана начинает занимать все больше времени.
Илья, iOS‑разработчик в Naumen, рассказывает, как пришел к подходу, при котором разработчику достаточно описать новое свойство, а интерфейс собирается автоматически.
Почему задача оказалась сложнее?
Все началось с настройки сжатия изображений перед отправкой на сервер. На первый взгляд задача выглядела вполне стандартной: подобрать параметры, проверить результат и убедиться, что все работает как нужно.
Но довольно быстро возник другой вопрос: как проверять изменения без постоянной пересборки приложения?
Для разработчика это не так критично, а вот для аналитиков на приемке и тестировщиков каждая новая проверка требовала участия разработчика. Тогда появилась идея вынести параметры в отдельный экран настроек.
Почему обычный экран настроек не решил проблему?
Сначала мы решили добавить переключатели, поля ввода и другие элементы интерфейса. Но появилась новая сложность: поддерживать такой экран вручную неудобно.
Чтобы добавить новую настройку, нужно было каждый раз:
добавлять свойство;
добавлять соответствующий UI‑компонент;
настраивать обработку;
связывать с хранилищем данных.
Я начал искать подход, при котором разработчику не нужно отдельно поддерживать интерфейс настроек. Хотелось, чтобы достаточно было просто описать новую настройку, а все остальное система делала сама.
В этот момент я вспомнил про Reflection. В Swift этот механизм ограничен и фактически работает как интроспекция, но даже этих возможностей оказалось достаточно для решения задачи.
Как сделать так, чтобы экран собирался автоматически?
В основе подхода лежит декларативный принцип: разработчик описывает свойства объекта настроек и добавляет к ним метаданные, например, название настройки или связи с другими параметрами.
Дальше система анализирует структуру объекта, определяет типы данных и автоматически подбирает нужные UI‑компоненты:
для булевых значений — переключатели;
для текста — поля ввода;
для чисел — поля с ограничением на числовой ввод.
Что изменилось после внедрения такого подхода?
Теперь для добавления новой настройки достаточно описать новое свойство и добавить необходимые метаданные. После этого настройка автоматически появляется в интерфейсе.
По моей оценке, трудозатраты на работу с настройками сократились примерно на 80–90%. Кроме того, уменьшилось количество дублирующего кода, а интерфейс стал более единообразным и предсказуемым для пользователей.
Как я научил свою читалку различать примечания и комментарии в «Войне и мире»
Я не профессиональный программист. Пишу Android-читалку MRead для себя и для тех, кому тоже надоели комбайны. Код закрытый, всё работает локально, без серверов и трекинга. Раздаю через RuStore, 4PDA и GitHub.
В версии 1.4.0 я наконец победил баг, который меня лично бесил как читателя. Расскажу именно про него, потому что задача оказалась интереснее, чем выглядела.
Проблема
Открываю «Войну и мир». В одном предложении сразу два маркера сноски: примечание (перевод французского) и научный комментарий. В разных изданиях они нумеруются независимо, поэтому в тексте легко встретить два маркера с одинаковой цифрой. Старая логика по тапу вытаскивала из текста ближайшую цифру и искала абзац, начинающийся с этого числа, по всем главам, и показывала первое совпадение. Итог: тап по «6» открывал не ту сноску, а тап по числу вроде «1805» вообще пытался найти несуществующую сноску.
Почему наивный подход не работает
Цифра это не идентификатор. Она повторяется и в каждой главе, и между разделами «Примечания» и «Комментарии». А вот в исходнике всё однозначно: каждый маркер это ссылка с уникальным адресом.
То есть книга всегда знает правильный ответ. Беда была в том, что мой парсер при импорте выбрасывал href и оставлял только видимый текст маркера.
Что я поменял
При разборе HTML сохраняю не только текст абзаца, но и ссылки-сноски с точной позицией маркера. Позицию считаю надёжно: оборачиваю маркер невидимыми символами из Private Use Area до очистки текста, а после очистки нахожу их и вычисляю смещение. Так цифры в обычном тексте (годы, числа) не путаются с маркерами.
Позиции храню в абсолютных координатах главы. Это важно, потому что мой пагинатор режет абзацы на куски по строкам. Абсолютные смещения переживают нарезку без отдельной возни в пагинаторе.
По тапу беру не цифру, а ссылку под пальцем, и резолвлю сноску по точному id из нужного файла. Для FB2 пришлось ещё и сохранить id секций сносок при конвертации в HTML, потому что примечания и комментарии лежат в отдельных главах.
Старый поиск по цифре оставил как запасной вариант для книг без нормальной разметки, но убрал срабатывание на голые числа.
Результат: тап по примечанию открывает перевод, тап по комментарию открывает комментарий, а год «1805» больше никого не трогает.
Контекст для тех, кому интересно
Рендер текста у меня не WebView, а нативный движок на Canvas с собственной пагинацией (Jetpack Compose, Kotlin). Это даёт контроль над переносами, выравниванием по ширине и стабильной привязкой цитат и закладок, но за каждую такую фичу приходится платить ручной работой вроде этой истории со сносками.
Что ещё в 1.4.0, кратко
• Полнотекстовый поиск по PDF (для PDF с текстовым слоем) • Озвучивание (TTS): голоса, скорость, таймер сна, автопереход, пауза с памятью места • Передача слова во внешний словарь и контекст предложения в экспорт Anki • Настраиваемые блоки настроек чтения, межабзацный интервал, Bold/Italic • Полки, фоновый импорт из папок, оценки и заметки, Material You
Андрей Врацкий начал строить рынок корпоративных мессенджеров в 2015 году, когда WhatsApp и Telegram только начинали проникать в рабочие чаты, а безопасники в компаниях делали вид, что все ок и деловая переписка — это личная ответственность сотрудника.
На создание продукта ушло четыре года. Когда eXpress вышел в 2019-м, то выяснилось: все уже так привыкли к Telegram и WhatsApp, что менять ничего не хотят.
Прошло семь лет. Сегодня иностранные мессенджеры заблокированы, отечественный* удален из App Store на неопределенный срок. На этом фоне спрос на eXpress вырос в четыре раза — и это пока Telegram все еще работает. Что будет, когда перестанет?
Хотя по мнению Врацкого, хороший продукт будет востребован вне зависимости от обстоятельств и критерий его успеха — это конкурентоспособность на мировом рынке.
Как я ускорил бэкапы в 20 раз и обошёл ловушку Jsoup: развитие самописной Android‑читалки MRead (v1.3.0)
Всем привет! Не так давно я рассказывал, как боль от перегруженных интерфейсов заставила меня открыть Android Studio и написать собственную читалку с кастомным движком рендеринга и точным выделением текста.
Статья получила теплый отклик и в комментариях набежало много отличных предложений. В этом посте я хочу поделиться техническими решениями, которые вошли в крупное обновление 1.3.0.
1. Бэкапы и боль от Storage Access Framework (SAF)
В приложении есть функция бэкапа: упаковка базы данных Room, настроек и распакованных HTML‑глав с картинками в один ZIP‑архив. Изначально я писал файлы напрямую в OutputStream, полученный через ContentResolver (SAF). Итог: библиотека на 500 МБ архивировалась около 5 минут. SAF проводит проверки безопасности для каждого записываемого чанка, что убивает I/O операции.
Решение: сборка архива переехала во внутренний кэш приложения. Туда пишем без ограничений SAF — буфером по 64 КБ и уровнем сжатия BEST_SPEED (картинки уже сжаты, гнать их через BEST_COMPRESSION бессмысленно). Когда ZIP готов целиком, он одним куском копируется в пользовательскую папку через SAF — вместо тысяч мелких защищённых записей получается одна
2. Material You: как получить правильные цвета обоев
При внедрении динамических тем (Android 12+) я столкнулся с тем, что стандартный вызов dynamicLightColorScheme().background на многих устройствах выдает просто унылый белый или бледно‑серый цвет, игнорируя сочные оттенки обоев.
Решение: Самые насыщенные цвета из системной палитры Monet хранятся в secondaryContainer и surface. Решение нашлось в самой палитре Monet: наиболее насыщенные цвета живут в secondaryContainer и surface, а не в background. Переориентировал маппинг цветов приложения на эти слоты и интерфейс действительно ожил. Теперь интерфейс действительно реагирует на смену обоев. Плюс привязал OnSharedPreferenceChangeListener, чтобы тема менялась мгновенно на всех экранах без перезапуска.
3. Странности парсинга FB2 и баги Jsoup
Иногда вместо обложки FB2 парсер ставил черно‑белую картинку из середины книги. FB2 хранит все изображения в тегах <binary> в конце файла в хаотичном порядке. Если тег <coverpage> отсутствует, старый алгоритм просто брал первую попавшуюся картинку из бинарной кучи.
Я переписал фоллбэк: теперь, если явной обложки нет, Jsoup ищет первый тег <image> прямо внутри <body> книги.
Попутно всплыло неочевидное поведение Jsoup: если атрибут отсутствует, attr() возвращает пустую строку, а не null — это задокументировано, но интуитивно ожидаешь null. Из‑за этого Элвис‑операторы (?:) молча проглатывали пустую строку вместо ухода в fallback. Написал строгую обертку takeIf { it.isNotEmpty() }, и теперь обложки извлекаются безошибочно.
4. Изолированный свайп яркости в Compose
Нужно было добавить регулировку яркости свайпом по левому краю экрана. Проблема: в режиме вертикального скролла (VerticalPager) свайпер страниц перехватывает вертикальные жесты на себя.
Решение: перехватывать жест на фазе Initial — до того, как пейджер успевает его обработать. Если касание началось в левых 15% ширины экрана, событие забирается себе и до пейджера не доходит.
Помимо этого в релизе 1.3.0:
Добавлен полноэкранный просмотрщик иллюстраций с pinch‑to‑zoom (на основе detectTransformGestures).
Написан собственный File Picker со сканированием вложенных папок и извлечением книг прямо из ZIP‑архивов на лету.
Добавлен поворот страниц для PDF с сохранением состояния в SharedPreferences.
Разделен UI верхнего меню: закладки теперь можно переименовывать, а тап по номеру страницы открывает быстрый переход.
Добавлен множественный выбор в библиотеке (массовое добавление на полки/удаление/скрытие).
😻 Обновление HalChat for Android: v1.0.2 (Vote or don't vote)
Что нового? 😌Теперь есть описание чатов. 🤖 Добавлено обновление данных чата. 😉 Добавлены метаданные файлов HD - мгновенное определение что за файл или какие размеры изображения. 😇 Доступны опросы/голосования в чатах.
Что исправлено? 🤓 Если получение или расшифровка пароля была прервана, то теперь он запросит заново, и пароль будет доступен в любом случае. 🫢 Теперь при получении пароля от чата, в списке чатов сообщения будут расшифроваться. 😎 Исправлена система файлов в чате, они будут отображаться всегда и в том числе изображения (исправлен баг).
Собеседование. Часть 3: Магия коллекций в Kotlin — от лямбд до скрытых аллокаций
В прошлых частях мы препарировали алгоритмы и заглянули под капот хэш-таблиц. Сегодня поговорим о том, за что разработчики так искренне любят Kotlin — о коллекциях.
На собеседованиях этот блок вопросов — мой любимый детектор. Он отлично показывает, умеет ли человек отличать красивый синтаксический сахар от суровой реальности JVM.
Уровень 1: Синтаксический сахар и интерфейсы
Я спрашиваю: «В чем фундаментальная разница между List и MutableList в Kotlin?» Ожидаемый ответ: Kotlin изящно разделил интерфейсы на читаемые (read-only) и изменяемые. У List просто нет методов add или remove. Это спасает нас от случайных мутаций состояния, особенно когда мы гоняем данные в реактивном UI.
Далее переходим к функциям-расширениям. Кандидат пишет классическую цепочку: users.filter { it.age > 18 }.map { it.name }
Выглядит чисто. Здесь же я подкидываю вопрос про reduce и fold. Оба метода сворачивают коллекцию, но если кандидат бездумно использует reduce, я с легкой улыбкой спрашиваю: «А что будет, если список окажется пустым?» Будет больно и UnsupportedOperationException. Поэтому fold с его стартовым значением — выбор тех, кто хочет спать спокойно.
Уровень 2: Срываем покровы компилятора
Когда кандидат уверенно жонглирует лямбдами, пора заглянуть под капот. Я задаю вопрос: «А что конкретно создается в памяти, когда ты вызываешь listOf(1, 2, 3) или mapOf(1 to "A")?»
Многие верят в уникальную магию Kotlin. Но продвинутый разработчик знает, что мы всё еще живем в мире JVM.
mapOf() под капотом вернет java.util.LinkedHashMap. Но! Контракт Map не гарантирует сохранение порядка. Если вам критически важен порядок вставки, не надейтесь на реализацию «под капотом» — пишите linkedMapOf() явно, иначе в один прекрасный день обновление языка сломает вам логику.
listOf(1, 2, 3) вернет не обычный java.util.ArrayList. Он вернет внутренний класс java.util.Arrays$ArrayList. И разница тут колоссальная. Это fixed-size обертка над массивом. Если любитель хардкора решит сделать (list as MutableList).add(4), он моментально получит краш в рантайме.
Далее вопрос на засыпку: «Если мы в цикле вызываем filter { ... }, не убиваем ли мы Garbage Collector созданием анонимных классов для лямбд?» Отличный кандидат вспомнит про модификатор inline. Компилятор физически вставляет тело функции в место вызова, поэтому аллокации объектов лямбд не происходит.
Уровень 3: Экспертный взгляд и ловушка Sequences
Вроде бы inline нас спас? И да, и нет. Тут начинается территория архитектуры и производительности. Я возвращаю кандидата к его коду: users.filter { it.age > 18 }.map { it.name }
«Модификатор inline спас нас от лямбд, — говорю я. — Но что будет, если в списке 100 000 юзеров? Что произойдет с памятью?»
Эксперт должен увидеть угрозу: каждая стандартная функция (filter, map) создает новую промежуточную коллекцию. Сначала создастся список из 50 000 взрослых юзеров, а потом еще один из 50 000 их имен. Это колоссальная аллокация памяти.
«Как этого избежать?» Ответ: использовать Sequences — users.asSequence().filter {...}.map {...}.toList(). Последовательности работают лениво, протаскивая каждый элемент по цепочке поштучно, без создания огромных временных списков.
Финальная ловушка. Я спрашиваю: «Значит ли это, что нужно использовать asSequence() вообще везде?» Истинный эксперт скажет: Нет. У Sequence есть свои скрытые налоги: создание объектов-оберток (TransformingSequence, FilteringSequence) и накладные расходы на виртуальные вызовы next()/hasNext() для каждого элемента. На коротких списках обычная цепочка filter/map отработает быстрее. Бенчмарки показывают, что Sequence начинает выигрывать только на объемах примерно от 1 000 элементов (в зависимости от тяжести цепочки). Не стоит заниматься преждевременной оптимизацией там, где она не нужна.
Резюме
Коллекции в Kotlin невероятно удобны. Но за синтаксический сахар всегда нужно платить. Важно видеть, как человек переходит от слепого восторга красивым кодом к прагматичному пониманию
У меня айфон с маленьким экраном. Предпочитаю компактные модели, чтобы умещались в любом кармане. Это доставляет и некоторые неудобства. Например, часть приложений плохо работают, элементы интерфейса перекрывают друг друга, и из-за этого некоторые функции становятся недоступны. Иногда с такой проблемой я сталкивался в приложении Яндекс.Такси.
В связи с тем, что с продукцией Apple в России в последнее время ситуация постоянно ухудшается, планирую перейти на Android. Нашел подходящую модель на Яндекс.Маркете смартфон Conquest F3 Plus. Одна проблема — в этой модели экран еще меньше, чем у меня сейчас. Значит, есть риск, что приложения, которые глючили на старом смартфоне, вообще не смогут работать на новом.
С данным вопросом я обратился в поддержку Яндекса. Я был уверен, что получу точный ответ, будет работать приложение Яндекс.Go на интересующем меня устройстве или не будет. Ведь что может быть проще? Любой разработчик может, даже если не знает точно, в эмуляторе задать указанное разрешение экрана и прогнать тесты.
Ответом поддержки я был, мягко говоря, ошарашен. Ниже привожу текст нашего диалога со скринами.
Здравствуйте! Будет ли работать ваше приложение на вот такой модели смартфона? https://market.yandex.ru/cc/9aPY2a Разрешение экрана 540x1200.
Данную информацию вы можете уточнить в магазине приложений, из которого вы хотите скачать наше приложение
Я хочу купить новый смартфон, но мне нужно знать, будут ли работать нужные приложения. Ваше приложение очень плохо работает на экране с разрешением 1344x750. Хоть и работает. Какое разрешение поддерживает yandex.go? Будет ли оно работать на экране 540x200?
Данную информацию уточнить не получится, подсказать смогут в магазине приложений
Что значит, не получится? Напишите разработчикам, и они вам скажут.
Пожалуйста, обратитесь в магазин приложений для уточнения минимальных системных требований для корректной работы приложения
Какой магазин?
Магазин приложений вашего устройства
Итак, поддержка Яндекс.Go не смогла ответить на вопрос о системных требованиях собственного приложения. Неожиданно. У меня нет ни малейших идей, как такое стало возможно.
В связи с этим я решил обратиться за помощью к товарищам по отрасли. Может, кто-нибудь из читателей Хабра пробовал ставить Яндекс.Go на Android 12 с разрешением экрана 540x1200. Нормально работает?
Восстановление аккаунта в эфемерном мессенджере, не ломая приватность? Легко!
RCQ это анонимный мессенджер: без телефона и почты, история только на устройстве, сервер хранит минимум. Цена такой модели: потерял телефон, и аккаунт (сам UIN, твоя личность в сети) потерян навсегда. Это отпугивало тех, кому нужен постоянный аккаунт. Мы добавили фразу восстановления и постарались не превратить приватный мессенджер в обычный облачный.
Сразу: Android-клиент теперь в проде, фраза в нём есть. Ссылка в конце.
Аккаунт это ключи
Логина и пароля нет. Аккаунт это пара ключей: X25519 (шифрование) и Ed25519 (подпись). UIN это просто ручка на сервере, привязанная к публичному ключу. Приватные ключи не покидают устройство. Отсюда: бэкап аккаунта это бэкап ключа, а восстановление это доказать серверу, что ключ у тебя.
Откуда фраза
При создании аккаунта генерируется случайный seed на 32 байта. Из него детерминированно выводятся оба ключа через HKDF-SHA256 с фиксированными info-строками:
Из одного seed всегда те же ключи, значит достаточно сохранить seed. Кодируем его в 24 слова по BIP39 (как в криптокошельках): 256 бит энтропии плюс 8 бит контрольной суммы, режется по 11 бит, словарь на 2048 слов. Контрольная сумма ловит опечатки.
Восстановление
На новом устройстве вводишь 24 слова:
Из слов получается seed, из seed те же ключи.
Клиент берёт у сервера одноразовый челлендж.
Подписывает его Ed25519-ключом, шлёт подпись.
Сервер проверяет подпись против публичного ключа и отдаёт UIN и токен.
Приватный ключ никуда не передаётся, пароль нигде не хранится. Это challenge-response: перехват челленджа бесполезен, он одноразовый.
Что возвращается
Возвращается личность: UIN, ключи, контакты, группы, ожидающие сообщения. НЕ возвращается локальная история переписки, она только на устройстве (зашифрованный бэкап истории это отдельная фича на будущее). Активные ratchet-сессии (forward secrecy) сбрасываются, собеседники видят смену ключа, как в Signal.
Почему это не ломает приватность
Тонкий момент, проговорим его подробно. Восстановимая фраза это постоянный секрет с полным доступом навсегда. Пока seed лежит только в зашифрованном хранилище приложения, удалил приложение не записав фразу, и всё стёрлось, эфемерность сохраняется. Как только выписал 24 слова, появляется вечная точка восстановления, это другая модель угроз.
Баланс такой: seed есть у каждого нового аккаунта, но воспользоваться им (записать фразу) это твой осознанный выбор, не навязанный. Плюс фразу прячем за подтверждением (+PIN), чтобы её не выгребли с разблокированного на минуту телефона.
Кросс-платформенно
Деривация и словарь одинаковы на Android и iOS. Мы прогнали обе реализации (CryptoKit и наш Android-стек) на одном seed и сравнили побайтово: одинаковые ключи, одинаковые слова. Фразу с Android можно ввести на iPhone и наоборот.
Границы
История чатов пока не восстанавливается.
Аккаунты, созданные до фичи, фразы не имеют (их ключи не из seed), для них будет экспорт сырого ключа (но для этого мы и в бете, так что на релизе такого не случится).
Это не мультидевайс: ввести фразу на втором телефоне можно, но это переезд, а не одновременная работа, ratchet-сессии разойдутся.
Код клиента открыт, Android в проде. Будем рады разбору, особенно по криптографии.
Собеседование. Часть 2: От структур данных до магии Load Factor и data class’ов
В прошлом выпуске мы выяснили, как простая задача на разворот массива вскрывает понимание вычислительной сложности. Сегодня мы поговорим о структурах данных и специфике языка программирования.
Мой второй любимый блок вопросов плавно перетекает от базовых коллекций к особенностям Kotlin и внутреннему устройству хэш-таблиц. Я оцениваю знания градационно: от того, что должен понимать начинающий специалист, до глубокого видения платформы.
Уровень 1: Начинающие специалисты и базовые структуры
Начинаем с разминки. Я прошу объяснить разницу между Array, ArrayList и LinkedList. Это фундамент, без которого сложно двигаться дальше. Если кандидат понимает структурную разницу, я спрашиваю про скорость доступа к произвольному элементу (Time Complexity):
Array (Массив): Непрерывный блок памяти фиксированного размера. Чтение по индексу происходит мгновенно, вычислительная сложность O(1).
ArrayList: Умная обёртка над массивом, умеющая динамически расширяться (путем копирования элементов в новый массив при переполнении). Доступ по индексу также O(1).
LinkedList (Связный список): Элементы разбросаны в памяти, каждый узел знает только о своем соседе. Чтобы найти нужный элемент, нужно последовательно пройти по цепочке. Скорость доступа — O(N).
Если специалист отвечает на это уверенно, значит, базовое понимание Computer Science заложено верно.
Уровень 2: Переход к Kotlin
Дальше я меняю плоскость и перехожу к синтаксису. Вопрос: «В чем разница между обычным class и data class в Kotlin?» Ожидаемый ответ на этом этапе: data class из коробки генерирует полезные методы, избавляя разработчика от написания бойлерплейта. Компилятор самостоятельно создает equals(), hashCode(), toString(), метод copy() и componentN() для деструктуризации.
Затем я прошу уточнить целевое использование. Кандидат должен пояснить, что data class нужен для хранения данных (например, моделей из сети) или состояния UI. Главная особенность в том, что объекты data class’ов сравниваются по содержимому (значениям полей), а не по ссылке в памяти.
Уровень 3: Углубленное понимание платформы А теперь самое интересное — мы сплетаем теорию структур данных и специфику Kotlin воедино.
Я спрашиваю: «Отлично, data class переопределяет метод hashCode(). А для чего именно он нужен? Как он используется под капотом?» Здесь требуется рассказать про принципы работы HashMap или HashSet: Метод hashCode() возвращает число, определяющее, в какую «корзину» (bucket) внутреннего массива попадет объект. Если хэши совпадают (коллизия), применяется метод equals(), чтобы найти точный объект внутри этой корзины.
И: «Что такое Load Factor в хэш-таблице? И что произойдет, если мы установим его слишком высоким (например, 0.95)?»
Правильный ответ: Load Factor (по умолчанию 0.75) — это метрика того, насколько может быть заполнена таблица до автоматического увеличения её размера (rehash). Если установить высокое значение, корзины переполнятся. Возникнет лавина коллизий. В результате хэш-таблица внутри одной корзины деградирует в LinkedList! Скорость доступа падает до линейной O(N) (или O(log N) для деревьев в новых версиях), лишая структуру её главного преимущества.
Резюме: Алгоритмы и структуры данных — это, по сути, сухая теория. Для меня как для интервьюера гораздо важнее то, как человек применяет её на практике.
В мобильной разработке нам гораздо реже приходится реализовывать сложные алгоритмы с нуля, чем ребятам на бэкенде. Но у нас своя специфика — жесткие ограничения по ресурсам устройства. Я не требую энциклопедических знаний. Я задаю простые, последовательные вопросы, чтобы понять: осознает ли человек, что неверно выбранная коллекция может привести к жесточайшим просадкам UI, фризам и неконтролируему расходу памяти.
Именно умение связать теоретическую алгоритмику с физическими ограничениями мобильного устройства показывает мне, насколько специалист действительно готов к реальной коммерческой разработке.
Собеседование. Часть 1: Как простая задача на разворот массива вскрывает понимание Computer Science
За свою карьеру я провел сотни технических собеседований на самые разные грейды — от джунов до системных архитекторов. И делал я это в разных локациях: в России, Европе и США. Процессы найма везде немного отличаются, но есть подходы, которые работают безотказно в любой точке земного шара.
Многие кандидаты боятся алгоритмических секций, ожидая зубодробительных задач с LeetCode. Но моя цель — не завалить, а понять инженерное мышление. Поэтому я часто начинаю с элементарной задачи: дан массив чисел, его нужно отзеркалить (перезаписать в обратном порядке).
Эта задача — идеальная «лесенка», раскрывающая реальный уровень инженера. Давайте пройдем по ней вместе.
Шаг 1: Уровень Джуниора. Просто сделай это
От джуна я жду умения перевести бизнес-требование в код. Самый очевидный способ решить задачу в лоб — создать второй массив и скопировать туда элементы с конца.
fun reverseArrayNaive(arr: IntArray): IntArray {
val result = IntArray(arr.size)
for (i in arr.indices) {
result[i] = arr[arr.size - 1 - i]
}
return result
}
Если код написан без ошибок с индексами — отлично. Если человек путается и не может подойти к задаче — для меня это красный флаг. Если код готов, я задаю первый вопрос: «Какова вычислительная сложность?». Ожидаемый ответ: сложность O(N) по времени, так как мы проходим массив один раз.
Шаг 2: Уровень Мидла. Экономим память
Переходим на следующий уровень. Я спрашиваю: «А что со сложностью по памяти?». Кандидат логично отвечает, что раз мы создаем массив того же размера, сложность — O(N).
Усложняем задачу: «Представь устройство с жестким лимитом ресурсов. Нам нельзя выделять память под второй массив. Как переписать алгоритм, чтобы сложность по памяти стала O(1)?»
Продвинутый разработчик сразу предложит in-place решение: менять элементы местами с начала и с конца.
fun reverseArrayInPlace(arr: IntArray) {
var left = 0
var right = arr.size - 1
while (left < right) {
val temp = arr[left]
arr[left] = arr[right]
arr[right] = temp
left++
right--
}
}
Шаг 3: Уровень Синьора. Психологическая ловушка
Если in-place вариант написан, я подкидываю вопрос с подвохом: «В первом варианте цикл делал N итераций. Во втором указатели встретились посередине, то есть цикл выполнился N/2 раз. Уменьшилась ли вычислительная сложность по времени?»
И тут многие радостно отвечают: «Да! Мы сократили операции в два раза, код стал быстрее!». И это ловушка.
Правильный ответ: Нет, сложность осталась O(N). Давайте посчитаем атомарные операции присваивания:
В наивном подходе мы делали 1 присваивание за итерацию. Цикл шел N раз. Итого: N операций.
В in-place подходе мы делаем swap. Это три операции (temp = a, a = b, b = temp). Цикл идет N/2 раз. Умножаем 3 на N/2 и получаем 1.5 × N операций!
С точки зрения процессора мы не сэкономили время, а совершили даже больше базовых действий. Мы просто обменяли такты на память. В нотации Big O константы отбрасываются, поэтому оба алгоритма линейные. Но синьор обязан видеть код насквозь, понимая его цену на уровне регистров.
За 10 минут с помощью одной задачи мы проверили:
Умение писать циклы (Джун).
Понимание Big O и расхода памяти (Мидл).
Понимание реальной цены оптимизаций (Синьор).
Это не спортивное программирование с хитрыми математическими трюками. Это проверка базовой инженерной гигиены.
Уже несколько лет мы поддерживаем VoiceOver на iOS — это был сложный и многоступенчатый путь к доступности приложения. После релиза мы увидели, что это реально работает, и людям с нарушением зрения стало проще пользоваться 2ГИС. В этом году мы решили, что пришло время для Android.
Под капотом — собственный мини-фреймворк
Дальше рассказывает ведущий разработчик Дмитрий Торопчин.
Когда начинаешь делать доступность под Android, кажется, что всё уже предусмотрено. Каждый View знает, как предоставить своё описание для служб доступности, как выполнять действия и какие события отправлять после их выполнения.
2ГИС устроен немного иначе: наш интерфейс написан на Qt Quick и с точки зрения Android это один пустой View. Никаких кнопок, списков и текстовых полей TalkBack «внутри» не видит. Сам Qt предоставляет кроссплатформенный API для работы со службами доступности из Qt Quick, но его платформенная интеграция для Android на данный момент поддерживает весьма ограниченный набор методов, которого категорически не хватает для разработки по-настоящему удобных и доступных приложений.
Поэтому мы решили написать свой мини-фреймворк для работы со службами доступности Android из Qt Quick. Основную архитектуру мы подсмотрели в Qt:
