К 2026 году слежка переехала из очевидных приложений в незаметные — фоновые сервисы и функции, у которых нет даже иконки на экране. Вы их не видите. Они видят вас.
Я сделал Sovereign — приложение, которое делит один Android на три изолированных пространства:
Гражданин — госуслуги, банки, маркетплейсы, MAX, Telegram. Человек — личное: Signal, крипто-кошельки, торрент-хабы. Суверен — зашифрованный анклав для самого ценного.
Без root. Без облака. Без подписки.
Что умеет: рентген слежки приложений (X-Ray), хранилище с пост-квантовым шифрованием, ИИ прямо в телефоне офлайн, скрытый сейф.
Честно: это цифровая гигиена, а не режим невидимки для спецслужб. Никаких пустых обещаний.
Sovereign — часть экосистемы соло-разработчика Vladislav Shter. Рядом: Egregor (уже в продаже) и скоро уникальный SovereignWeb3 Browser.
Сравнение Code Fable и Codex по ходу работы над одним и тем же проектом
Вчера, 1-го июля, программисты и активисты начали бурную трудовую неделю. А именно: вернулась модель Fable 5 и она будет доступна в вольном режиме до (или по) 7 июля. Так что есть 7 дней, чтобы сделать буст своим проектам.
Я тоже не избежал этой участи и вот уже почти целый день делаю polishing своему текущему проекту мобильного приложения.
Что сказать про впечатления? - Ощущение вот того самого вайб кодинга, о котором говорил Карпаты. Говоришь ему что делать и он делает. Технических ошибок просто нет, от слова совсем. Есть ошибки архитектурные, но не существенные, исправляются одной-двумя итерациями.
И кстати, получилось сравнить с Codex'ом, который решил попробовать на старте этого же проекта. Результат сравнения такой: Codex очень сильно подтянулся в работе с кодом, иногда даже кажется, что нет различий.
Но вот вокруг кода хуже: болтливые они оба, но у Codex больше какой-то разболтанности, разбрасывания в стороны. Особенно это видно на написании документации, пишет незначительные детали, теряет главное. И слабее держит инструкции.
Code в этом отношении гораздо чётче действует. Более жёстко держит инструкции, больше памяти, что характерно, помнит предыдущий и даже предыдущие чаты. Меньше разбрасывания на второстепенные детали, чётче фокус. Даже чек-лист у него выглядит проще, чётче и понятнее, чем у Codex.
Единственное, что может я так натаскал Code. С другой стороны, не использую MCP, RAG, даже скилы и хуки. Зашил все в память, их там три: общая пользовательская, описание проекта и правила работы.
И напоследок обнаружил в Code очень полезную функцию оценки загруженности контекстного окна.
Может она уже давно там была, о ней вроде писали, но что-то казалось, что это в CLI. А теперь оказывается её можно использовать и в декстопной версии. Думаю и другим пользователям это тоже пригодится.
Обычно смотришь, если чат начинает тормозить, значит пора. Или спросишь саму модель, но она обычно отвечает, что если на глаз, то загружена на 75%, но лучше начать новый чат. А теперь можно точно увидеть процент загруженности. Более того, можно даже увидеть чем именно загружено контекстное окно.
Для этого в чате Code, в поле ввода достаточно ввести слэш команду - /context
Прикрепляю скриншот как это выглядит вживую
И ещё такое впечатление, что Fable стал жечь меньше токенов за счёт какого-то более делового, но все ещё дружелюбного стиля общения.
Так что, удачи всем с проектами на этой бурной трудовой неделе!))
Сравнение 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. Все строилось просто: компьютер, модем и терминальная программа для связи. Часто в роли узла (ноды) выступал сервер в банке, где знакомый сисадмин выделял адреса. При этом подключиться можно было к любому другому участнику, даже к частному лицу. Вот это и была настоящая децентрализация! Думаю, учитывая растущее давление регуляторов на современный интернет, мы скоро снова вернемся к проверенным идеям старого доброго Фидо.
Как я научил свою читалку различать примечания и комментарии в «Войне и мире»
Я не профессиональный программист. Пишу 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
Как я ускорил бэкапы в 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 верхнего меню: закладки теперь можно переименовывать, а тап по номеру страницы открывает быстрый переход.
Добавлен множественный выбор в библиотеке (массовое добавление на полки/удаление/скрытие).
Дал большое интервью изданию Tazabek (деловое медиа Кыргызстана, входит в группу АКИpress) — про то, как мы с командой, начав с мобильного оператора, за пять лет собрали полноценную экосистему «Мой О!»: 3,5 млн клиентов и 10+ млн загрузок при населении страны около 7 млн.
Поговорили о том, что обычно остаётся за кадром историй успеха:
Почему телеком-финтех редкая история масштабного успеха не зависимо от географии, ведь стратегии и технологии у всех примерно одинаковые, но экосистемы получились не всех.
Какое архитектурное решение мы приняли на старте и ни разу не пожалели – про «сквозные», но не единые буквально данные, идентификацию и клиентский опыт.
Как устроенбаланс между скоростью и регулятором, и почему регуляторная песочница Национального банка — история не только про нас, но и про всю страну.
Трансграничные коридоры с Kaspi и Uzum — первые прямые финтех-коридоры в Центральной Азии.
Куда всё движется дальше: AI в каждом домене – от скоринга и антифрода до регуляторики.
И главный вывод, к которому мы пришли за эти годы: люди важнее технологий. Все провалившиеся проекты имели лучшие в мире технологии. Не хватило людей, которые собрали бы из этого работающую экосистему под конкретную страну.
А пока вопрос к вам: какие локальные финтех- или экосистемные проекты в ЦА и СНГ вы видели вблизи — и на чём они споткнулись? Интересны конкретные кейсы.
У меня айфон с маленьким экраном. Предпочитаю компактные модели, чтобы умещались в любом кармане. Это доставляет и некоторые неудобства. Например, часть приложений плохо работают, элементы интерфейса перекрывают друг друга, и из-за этого некоторые функции становятся недоступны. Иногда с такой проблемой я сталкивался в приложении Яндекс.Такси.
В связи с тем, что с продукцией 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 в проде. Будем рады разбору, особенно по криптографии.
4 июня собираемся с мобильными разработчиками в атмосфере любимых фэнтези и настольных ролевых игр — на Alfa Mobile D&D party. Впереди приключение для истинных авантюристов: объединяйтесь в отряды и открывайте секреты башни.
Друиды поделятся мудростью:
С техническим лидером Android-разработки Виталием Перятиным обсудим, что на самом деле под капотом у MCP. Спойлер: всё просто
С ведущим iOS-разработчиком Петросом Тепояном погрузимся в мир ИИ-разработки и приключений, или Туда и обратно
Завершим игру вечеринкой. Советуем подумать над образом своего персонажа: за 3 лучших подарим подарки!
Где: в секретном баре в Москве. Локацию пришлём с соколом в письме.
Честно, вся эта история с рейтингами в Яндекс.Такси сначала выглядела как что-то лишнее. Ну правда: ты заказываешь такси, платишь деньги - какие ещё "звёздочки" сверху?
Но потом как-то перестаёшь об этом думать и начинаешь замечать другое. Поездки стали более ровными. Не идеальными, нет - но без резких провалов. Реже попадаются ситуации, когда водитель откровенно игнорирует маршрут или ведёт себя так, будто ему всё равно.
Был момент: новый для меня район, сложная развязка, навигатор там сам иногда путается. Думаю, сейчас начнётся классическое "куда ехать-то?". Но нет - водитель как то смог сориентироваться, доехал по маршруту, без лишней суеты, без лишних кругов и нервов, и как же я хочу, что бы это было не исключение, а обычный сценарий,пока вроде все к этому и ведет.
Да, система оценок не стерильная. Кто-то может занизить балл по настроению, кто-то наоборот поставить пятёрку на автомате. Но в среднем это создаёт фон, где и водители, и пассажиры ведут себя чуть внимательнее. Не из страха, а потому что есть понятная обратная связь.
В итоге получается не какая-то игра в рейтинги, а просто дополнительный механизм, который держит сервис в тонусе. Не панацея, но и точно не та проблема, из которой стоит делать драму
Старый код усложняет рефакторинг, тесты в команде запускаются по‑разному, баги не воспроизводятся на хорошем Wi‑Fi, а после обновления инструментов локальная сборка начинает расходиться с CI — по отдельности все это мелочи, но именно они постепенно начинают тормозить разработку.
Ринат, iOS‑разработчик Naumen, рассказал об инструментах, которые помогают ему решать такие задачи и упрощать повседневную работу.
Periphery: поиск мертвого кода в Swift‑проектах
Со временем в любом проекте появляется код, который уже не используется: старые методы и фичи, забытые extensions и helpers. Все это усложняет навигацию и мешает быстро понять архитектуру проекта.
Periphery помогает находить такие места и наводить порядок перед изменениями в кодовой базе.
Как использую
Запускаю Periphery перед рефакторингом — например, когда нужно обновить модуль профиля с сотнями файлов.
periphery scan
После сканирования инструмент показывает классы, методы, свойства, enum cases, imports и другие элементы. Так проще понять, что действительно участвует в работе приложения.
Что важно знать: результаты всегда нужно проверять вручную. Инструмент может не учитывать динамические вызовы, reflection, Objective-C runtime, storyboard-ссылки или код, который используется через строки.
Network Link Conditioner: тестирование слабой сети
Во время разработки приложение чаще всего тестируется в почти идеальных условиях. Но у пользователей все может работать иначе.
Network Link Conditioner — инструмент от Apple, который помогает эмулировать разные сетевые условия. Например, индикатор загрузки крутится бесконечно, повторная попытка не срабатывает, время ожидания слишком короткое, а пользователь не получает понятного сообщения об ошибке.
Как использую
Обычно проверяю сценарии авторизации, оплаты, загрузки медиа и офлайн‑режимы. Для этого включаю профиль вроде плохого 3G, высокой задержки или потери пакетов и смотрю, как приложение ведет себя в нестабильной сети.
Что важно знать: проверять стоит не только низкую скорость интернета, но и нестабильность сети. А еще важно не забывать выключать Conditioner после проверки :)
just: короткие команды вместо длинных инструкций
В iOS‑проектах быстро накапливаются команды, которые приходится запускать постоянно: тесты, форматирование, генерация ресурсов. Со временем это превращается либо в огромный онбординг‑документ, либо в постоянный поиск нужной команды в документации.
just собирает основные сценарии работы в одном месте и запускает их через короткие понятные команды. В итоге justfile становится чем‑то вроде живой документации проекта.
Как использую
Чтобы каждый раз не вспоминать синтаксис, храню основные сценарии работы в justfile.
После этого вместо длинных команд достаточно написать:
just test
just format
just clean
Что важно знать: just не заменяет CI, Makefile или build system. Это скорее удобный слой для повседневных команд. Поэтому лучше держать justfile простым и не превращать его в большой набор скриптов.
Mint: фиксация версий CLI-инструментов на Swift
Когда у разработчиков разные версии линтеров, форматтеров и других CLI‑инструментов, могут появиться расхождения. Mint помогает зафиксировать набор инструментов внутри проекта и сделать локальный запуск ближе к CI, чтобы у всей команды был одинаковый результат.
Как использую
Вместо глобальной установки SwiftLint, SwiftFormat, XcodeGen или других CLI‑инструментов можно хранить версии в Mintfile и запускать их одинаково у всех разработчиков.
mint run realm/SwiftLint
mint run nicklockwood/SwiftFormat
Что важно знать: Mint полезен именно для Swift CLI-пакетов. Для Ruby-gems, Node.js-инструментов или системных утилит понадобятся другие менеджеры. Также важно кэшировать установленные бинарные файлы в CI, иначе сборки могут тратить лишнее время на установку инструментов.
Ситуация с сервисами, которые вроде как не запрещены в России, но замедлены, породила новые опасности для информационной безопасности. Так как блог мы ведём в первую очередь для наших пользователей, то напомним о «граблях» в приложениях, вроде как облегчающих жизнь.
Telegram — тот редкий случай, когда компания раскрывает код клиентской части, что позволяет сторонним разработчикам делать «форки» — версии, которые работают с основным сервисом, но могут иметь дополнительные функции. Одним из таких приложений стала «Телега», которая обещала спокойную работу с замедленным Telegram. Вот только первое же расследование показало, что трафик она отправляет на сторонние серверы, а возможно, ещё и читает сообщения (в норме этого не должно быть). Скоро сервис Павла Дурова опомнился и стал помечать аккаунты, которые используют сторонние клиентские приложения. А потом магазины приложений удалили «Телегу» как потенциально опасную.
Финал истории? Нет, во-первых, «Телега» по-прежнему рекламируется в выдаче как безопасный мессенджер — не все же читают новости по кибербезопасности. Наверняка у вас стоят расширения к браузеру, которые облегчают жизнь. Но в любой момент добросовестный разработчик может продать их, и неизвестно, кто получит доступ к вашим данным.
Любое приложение может быть небезопасным. И проверки в магазине приложений не всегда выявят бэкдоры, через которые хакеры получат доступ к нему. Но ещё хуже с приложениями, которые вы скачиваете напрямую из интернета. Каждый раз стоит помнить, что механизмы защиты любой ОС имеют свои пределы.
Приложения крупных производителей тоже могут иметь уязвимости: Apple в марте 2025 года предупредила о критической уязвимости в своей хвалёной iOS. Но, в отличие от мелких производителей, большие компании имеют возможность анализировать новое ПО, искать в нём уязвимости и предлагать патчи для их устранения.
Так что помните, что безопасность не обеспечена по умолчанию: стоит внимательно относиться к используемым сервисам и читать наш канал, чтобы узнавать о самых серьёзных опасностях (и самых больших возможностях) мира технологий.
Раньше при подключении CarPlay пользователи видели в приложении 2ГИС на телефоне «заглушку» — почти пустой экран. И наш iOS‑разработчик Ваня задумался: «Почему бы не добавить полезности?»
Идея родилась на внутреннем хакатоне. Он решил не переносить интерфейс целиком, а разделить роли между устройствами. Телефон — для действий. CarPlay — для результата.
Собрал прототип, а затем команда подхватила инициативу. И это одна из самых быстрых задач, которая дошла до релиза.
Все действия выполняются на телефоне и сразу отображаются на экране в машине. Без переходов, без ожидания и без разрыва между устройствами
Это интересно, потому что:
новый сценарий для автомобилистов: теперь можно взаимодействовать с приложением на телефоне, пока навигация идёт в CarPlay;
красивый обход архитектурного ограничения;
инженерная инициатива, которая с хакатона дошла до прода.
«Перформанс без головной боли: Системная оптимизация фронтенда в большой команде» (Мирзоев Руслан, Premier.one)
Доклад основан на реальном опыте команды из 24 разработчиков, столкнувшихся с критическими показателями LCP. Мы разберем комплексный подход к ускорению продукта: от «фундамента» (анализ бандла, Tree Shaking и борьба с циклическими зависимостями) до продвинутых стратегий рендеринга, таких как ISR и оптимизация внутренних запросов при SSR (перевод на internal hosts).
Вы получите набор готовых рецептов по работе с ассетами (SVG, шрифты, сжатие) и узнаете, как выстроить культуру производительности с помощью Performance Budgets, чтобы предотвратить регрессии в будущем
Разберёмся, почему веб-копмоненты не прижились, что нужно сделать, чтобы это исправить, и есть ли им место в современной фронтенд-разработке.
«LLM в продакшене: от идеи до внедрения за неделю» (Артем Шкуренко, Х5 Tech)
Интеграция языковых моделей в существующие продукты не требует масштабных изменений архитектуры. Покажу практические паттерны — от прямой интеграции через API до выделенных сервисов, которые позволяют запускать AI-функциональность за считанные дни.
В докладе — реальные кейсы: интеллектуальные таблицы, ассистенты и аналитика, а также разбор ключевых вызовов — контроль качества, предсказуемость результатов и стабильность работы.
«Вторая жизнь инженерных практик: как ИИ делает сложные подходы наконец-то удобными» (Вадим Царегородцев, Frontend Guild Lead в островке)
За последние годы индустрия накопила множество инженерных практик: ADR, Clean Architecture, TDD, архитектурные границы, строгие правила зависимостей.
Многие из них отличные на уровне идей, но на практике часто оказываются слишком дорогими и трудоёмкими: требуют много документации, boilerplate-кода и ручного контроля правил.
Появление LLM меняет эту ситуацию.
Интересно, что ИИ не столько создаёт новые подходы, сколько делает жизнеспособными старые идеи, которые раньше было сложно применять из-за высокой стоимости их поддержки.
В докладе я покажу несколько реальных примеров из production-разработки, где привычные инженерные практики получили вторую жизнь благодаря ИИ.
У вас самый крутой уникальный продукт или сервис на рынке, вы знаете наверняка, что он делает и как им пользоваться. А понятен ли он вашему клиенту? Надо написать документацию, но как? Давайте разберёмся, чтобы потом не было больно.
«Секретная жизнь фотографий в Клубе Тайных Покупателей X5» (Артур Басак, Х5 Tech)
Поговорим о подходе Web-First в мобильных приложениях. В частности о том, как работать с файлами, про удобство и ограничения Workbox, нюансы оффлайн-режима и о какие подводные камни можно споткнуться.
Инженерная культура и переход на «бигтех-рельсы»
Круглый стол с экспертами:Глеб Михеев, Роман Троицкий(состав уточняется…)
Может многие и не задавались вопросом, но я думаю это интересная тема, которую можно прояснить.
Допустим, мы пилим какой-нибудь интересный сервис. Ну вот написали мы бэкенд, а как пользователь будет с ним взаимодействовать? По моему мнению сейчас есть несколько основных вариантов: веб-приложение, мобильное прилижение и телеграм-бот. Конечно, если есть много лишних рук, можно написать всё и сразу, но это не мой варик.
В моём случае каждая строчка кода дорога. Работаю я в одиночку.
Сейчас я разрабатываю сервис по изучению иностранных слов и на основе моего опыта хочу сделать некое сравнение этих подходов.
Телеграм-бот
Вообще начал я user-side телеграм-ботом. Поначалу это, конечно, может, и казалось достаточным, но всё-таки для какого-либо функционала простого телеграм-бота не хватает.
Да и ещё в добавок в Russian Federation начали блокировать тг, поэтому пользоваться им приходится с костылями, а бот перестал стабильно работать.
Вывод: тг-бот - для простого функционала, но довольно нестабилен и ограничен функционал
Хотя, есть mini-app, но в их подробности я не вдавался.
Веб-приложение
Следующий очень популярный вариант - веб-приложение. Этот вариант намного более гибок. Но по моему мнению всё же не максимально стабилен, так как его работа зависит от состояния браузера. Но у этого варианта есть огромное преимущество: он работает на всех устройствах, на которых можно открыть веб-сайт. Это, так сказать, униварсальный вариант.
Но есть проблема. Допустим, человек пользуется чем-то на постоянной основе и хочет максимально быструю и адаптированную работу. Он будет постоянно заходить в браузер и копаться во вкладках? Или лучше тогда выбрать мобильное приложение?
Мобильное приложение
Наверное самый сложный и трудозатратный, но по моему мнению в нынешнее время самый перспективный вариант. Да, по сравнению с веб-собратом работать оно будет не везде, а только на мобилке, при том на определённой (IOS или Android).
Но при этом мобильное приложение даёт реализовать максимально удобное и оптимизированное управление, потому что почти всё можно настроить под свой продукт.
Небольшая сводка
Для чего бот: для простого функционала. Можно использовать как небольшое дополнение к какой-либо инфраструктуре. Этот подход наименее трудозатратен.
Для чего веб-приложения: для продуктов, где нужна кроссплатформенность и довольно широкая кастомизация. Подход не сильно трудозатратный.
Для чего мобильные приложения: для продуктов где важна максимальная быстрота и удобство и наилучшии возможности кастомизации. По моему мнению наиболее подходит для каких-то интересных и уникальных сервисов. Это самый трудозатратный подход из перечисленный, но в некоторых случаях он более чем себя оправдывает.
Что кому разрабатывать в первую очередь зависит от самого проекта, универсального варианта здесь нет по моему мнению.
PS: интересно узнать чужое мнение, так как возможно здесь много субъективщины.
Выпустили мобильное приложение для Интернетометра от Яндекса
Команда Yandex Infrastructure разработала приложение под iOS и Android для бесплатного сервиса Интернетометр. Как и в веб‑версии сервиса в приложении можно замерять скорость скачивания, скорость загрузки и время задержки интернет‑соединения в миллисекундах.
В приложении доступны светлая и тёмная темы
Сбор информации организован с использованием сети CDN‑серверов Яндекса: для большей точности сервис опрашивает не один, а сразу несколько ближайших серверов. Ежемесячно Интернетометром пользуются 5,5 миллионов человек — в среднем они запускают 18 миллионов измерений.
Сервис предоставляет ключевую информацию о подключении: IP‑адрес, версию браузера, разрешение экрана и так далее. В будущем в приложении будет доступен расширенный режим измерений: он будет особенно полезен для технических специалистов, которые настраивают интернет‑соединение. Также у провайдеров проводной и беспроводной связи появится личный кабинет, где они смогут отслеживать замеры в зоне своего покрытия.
5 бесплатных уроков марта для мобильных разработчиков
12 марта 20:00 >>Профессиональные модульные тесты в Android: как тесты улучшают код Открытый вебинар курса «Android-разработчик. Продвинутый уровень» Урок о том, как писать в Android осмысленные модульные тесты для ViewModel, репозиториев и бизнес-логики, чтобы они не маскировали проблемы, а реально улучшали архитектуру и поддержку кода. Записаться на урок
18 марта 20:00 >> Пишем простой проигрыватель на SwiftUI Открытый вебинар курса «IOS-разработчик» Соберете на SwiftUI простой медиапроигрыватель с интерактивным интерфейсом, освоите работу с локальными аудио- и видеофайлами в iOS и наметите путь к интеграции внешних сервисов. Записаться на урок
19 марта 20:00 >> Современная архитектура приложения и внедрение зависимостей Открытый вебинар курса «Android-разработчик. Продвинутый уровень» Разберемся, как выстроить Android-приложение на основе чистой архитектуры, связать слои через MVVM и настроить внедрение зависимостей с помощью Koin без лишней магии. Записаться на урок
23 марта 20:00 >> Навигация Pro-уровня в SwiftUI: как строить масштабируемые iOS-приложения без хаоса в переходах Открытый вебинар курса «IOS-разработчик. Продвинутый уровень» Как в SwiftUI проектировать навигацию без архитектурного хаоса: отделять переходы от интерфейса, управлять deep link и модальными экранами, строить масштабируемую структуру приложения. Записаться на урок
25 марта 20:00 >> Как писать Flutter-код так, чтобы ИИ правильно его дописывал Открытый вебинар курса «Flutter-разработчик» Поймете, почему искусственный интеллект ошибается при генерации Flutter-кода, и освоите приёмы, которые улучшат подсказки, повысят читаемость проекта и ускорят дальнейшую разработку. Записаться на урок
Еще больше бесплатных уроков от преподавателей курсов по всем ИТ-направлениям можно посмотреть в календаре мероприятий.
Долгие годы его выбирали либо фанаты дисциплины, либо команды на сверхкритичных проектах — слишком дорого. Писать тесты до кода медленно, поддерживать тестовый контур сложно, поэтому большинство команд жили по схеме: сначала код, потом «когда-нибудь допишем тесты». Но AI резко меняет экономику разработки: юнит-тесты генерируются за минуты, E2E собираются из user flow, интеграционные тесты склеиваются по контрактам. И появляется эффект, который разработчики любят больше всего — код становится не страшно менять.
Но есть важный нюанс. AI действительно отлично ускоряет тесты после разработки, но не спасает плохую архитектуру. Если система спроектирована криво — вы просто быстрее автоматизируете хаос. Поэтому всё чаще возвращаемся к идее тестов как инструмента проектирования. TDD перестаёт быть «религией» и становится способом делать контракты проще, зависимости чище, а систему — слабосвязанной.
И да, AI ускоряет не всех. Он усиливает системных людей и вскрывает хаос. Если требования мутные, архитектура плавает, а процессы держатся на чате — AI лишь ускорит производство багов.
Я — Мария Лещинская, руковожу тестированием в Surf. Мы много экспериментируем с AI в разработке, тестировании и процессах — и регулярно делимся инсайтами из практики.
Если вам интересно, как меняется разработка прямо сейчас — подписывайтесь и читайте больше материалов от экспертов Surf на нашем Телеграм-канале «Директорат Surf обсуждает». Впереди ещё много практических наблюдений и кейсов с реальными результатами. Ничего не скрываем — рассказываем как есть.
Найм больше не работает как раньше: тренды 2025–2026 и новая роль HR-tech в бизнесе
В 2025–2026 рынок найма — уже новая норма: дефицит кадров становится структурным.
📉 В РФ не хватает около 4,8 млн специалистов, при этом 62% компаний всё равно планируют рост численности, а 24% работников за год сменили работодателя (в отдельных отраслях треть и больше держатся на месте меньше года).
С другой стороны — оптимизация внутренних процессов. Это ощущается особенно жёстко: по данным hh.ru, 63% компаний в 2024 сокращали или планировали сокращение ФОТ. Получается: ресурсов меньше, цена ошибки выше, запрос на автоматизацию растёт.
💸 Дальше включается экономика, которую обычно недооценивают:
21% сотрудников уходят ещё до конца испытательного срока
Ещё 15% — сразу после него
Замена одного сотрудника обходится бизнесу в 1,5–2 годовых зарплаты
Среднее время выхода на продуктивность — 65 дней, для технических ролей — до 90
⚙️ В такой реальности HR-цифровизация перестаёт быть просто дополнительной фишкой или бонусом при найме. Она становится частью операционного контура: либо вы сокращаете потери системно, либо платите за них постоянно.
Часть компаний в РФ уже давно смотрят в сторону HR-приложений:
🤖 AI в HR перестаёт быть экспериментом: 43% компаний в РФ уже используют AI в HR (против 26% в 2024), а 78% enterprise-компаний применяют AI в рекрутинге.
🔄 Фокус смещается на self-service (справки, отпуск, расчётные листки) — до 80% типовых запросов можно вынести из HR-ручного режима.
📊 Окупаемость понятна: в среднем точка окупаемости HR-приложения — на 9-й месяц, к 18-му ROI может доходить до ~340%.
📎 Мы собрали эти и другие данные в исследование, где зафиксировали ключевые тренды HR-tech 2025–2026, разобрали, как компании подходят к мобильным HR-продуктам, и какие решения дают эффект на практике.
🎁 Отдельный бонус: сделали кликабельный прототип почти готового HR-приложения — не концепт, а рабочий флоу, который можно показать своим HRD.
Исследование в открытом доступе, оно бесплатно и экономит 2–3 месяца аналитики и обсуждений на старте, если вы думаете о запуске или перезапуске HR-продукта 👇
