Kotlin *

Открытый проект RepoStore для смартфонов на Android превращает GitHub в Google Play и помогает найти любые Android‑приложения среди репозиториев. С помощью RepoStore можно быстро найти и открыть APK‑файл — у него будут описание и даже рейтинг. Всё разделено по категориям.

Почему ИИ-агент для кода промахивается мимо нужного метода

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

Агент, который ищет код текстом, физически не отличает OrderService.validate от UserDto.validate: для него это просто совпадение символов «validate». Агент, который спрашивает у IDE «кто на самом деле вызывает этот метод», получает точный ответ, потому что IDE знает типы, разрешённые ссылки и видимость каждого символа. Разница между этими двумя подходами не абстрактная, она измеряется в конкретных цифрах.

Точка отсчёта: почему grep и RAG промахиваются

Кодовый агент ищет по проекту двумя способами: grep/ripgrep по содержимому файлов и векторный поиск по эмбеддингам кусков кода. На маленьком проекте оба варианта работают сносно. На enterprise-репозитории на миллионы строк с десятками модулей поведение ломается одинаково: запрос «найди использования метода validate» возвращает тысячу с лишним совпадений, из которых подавляющее большинство - другие методы с тем же именем в других классах. Векторный поиск находит куски кода, которые «похожи по смыслу», но это может быть валидация в совершенно другом домене.

Что показали цифры на 27 задачах

Мы сравнили три версии агента на 27 задачах вида «найди все места, где используется метод X» из реальных тикетов трёх внутренних репозиториев на Java и Kotlin: агент на ripgrep, агент на ripgrep с векторным RAG и агент на PSI-индексе IntelliJ (find_usages, find_declaration, class_hierarchy вместо текстового поиска).

Precision показывает, сколько из найденного агентом оказалось реальными использованиями метода, а не случайным совпадением имён. Recall показывает, сколько из всех реальных использований в коде агент вообще нашёл, ничего не пропустив.

У ripgrep recall высокий (0,82): текстовый поиск почти никогда не пропускает совпадения по имени. Но precision низкий (0,41): больше половины найденного - чужие методы с тем же именем, и их приходится разбирать вручную. У PSI-индекса высоки обе величины (0,96 и 0,93): агент находит почти все нужные места и почти не приносит лишнего. F1 сводит обе величины в одно число, и у ripgrep он проседает именно из-за мусора в выдаче, хотя нужные места он и находит.

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

Точный поиск не отменяет проверку

Даже когда агент точно нашёл все места, где используется метод, и внёс правку во все, это не гарантирует, что правка корректна: точный поиск решает только задачу «найти нужные места», а не «проверить, что код после правки работает». Поэтому прежде чем объявить об успехе, агент должен прогнать компилятор и тесты: тест зелёный, ошибок компиляции нет, покрытие не просело. Пока в выводе компилятора или тестового прогона есть хоть одна ошибка, агент обязан либо исправить её, либо сообщить о проблеме, а не писать об успехе.

Но точный поиск снимает с агента часть ручной работы: не нужно самому перепроверять по всему проекту, все ли использования метода он нашёл - эту проверку берёт на себя IDE, как это устроено в Veai, а оставшуюся часть верификации - компилятор и тесты.

Подробности - в отдельной статье в ближайшее время

Как я научил свою читалку различать примечания и комментарии в «Войне и мире»

Я не профессиональный программист. Пишу Android-читалку MRead для себя и для тех, кому тоже надоели комбайны. Код закрытый, всё работает локально, без серверов и трекинга. Раздаю через RuStore, 4PDA и GitHub.

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

Проблема

Открываю «Войну и мир». В одном предложении сразу два маркера сноски: примечание (перевод французского) и научный комментарий. В разных изданиях они нумеруются независимо, поэтому в тексте легко встретить два маркера с одинаковой цифрой. Старая логика по тапу вытаскивала из текста ближайшую цифру и искала абзац, начинающийся с этого числа, по всем главам, и показывала первое совпадение. Итог: тап по «6» открывал не ту сноску, а тап по числу вроде «1805» вообще пытался найти несуществующую сноску.

Почему наивный подход не работает

Цифра это не идентификатор. Она повторяется и в каждой главе, и между разделами «Примечания» и «Комментарии». А вот в исходнике всё однозначно: каждый маркер это ссылка с уникальным адресом.

EPUB: ¹ FB2: [6] и {4}

То есть книга всегда знает правильный ответ. Беда была в том, что мой парсер при импорте выбрасывал href и оставлял только видимый текст маркера.

Что я поменял

1. При разборе HTML сохраняю не только текст абзаца, но и ссылки-сноски с точной позицией маркера. Позицию считаю надёжно: оборачиваю маркер невидимыми символами из Private Use Area до очистки текста, а после очистки нахожу их и вычисляю смещение. Так цифры в обычном тексте (годы, числа) не путаются с маркерами.

2. Позиции храню в абсолютных координатах главы. Это важно, потому что мой пагинатор режет абзацы на куски по строкам. Абсолютные смещения переживают нарезку без отдельной возни в пагинаторе.

3. По тапу беру не цифру, а ссылку под пальцем, и резолвлю сноску по точному id из нужного файла. Для FB2 пришлось ещё и сохранить id секций сносок при конвертации в HTML, потому что примечания и комментарии лежат в отдельных главах.

4. Старый поиск по цифре оставил как запасной вариант для книг без нормальной разметки, но убрал срабатывание на голые числа.

Результат: тап по примечанию открывает перевод, тап по комментарию открывает комментарий, а год «1805» больше никого не трогает.

Контекст для тех, кому интересно

Рендер текста у меня не WebView, а нативный движок на Canvas с собственной пагинацией (Jetpack Compose, Kotlin). Это даёт контроль над переносами, выравниванием по ширине и стабильной привязкой цитат и закладок, но за каждую такую фичу приходится платить ручной работой вроде этой истории со сносками.

Что ещё в 1.4.0, кратко

• Полнотекстовый поиск по PDF (для PDF с текстовым слоем)
• Озвучивание (TTS): голоса, скорость, таймер сна, автопереход, пауза с памятью места
• Передача слова во внешний словарь и контекст предложения в экспорт Anki
• Настраиваемые блоки настроек чтения, межабзацный интервал, Bold/Italic
• Полки, фоновый импорт из папок, оценки и заметки, Material You

Ссылки

• RuStore

• GitHub

• 4PDA

Если у вас была книга FB2, переоткройте её, чтобы заработали точные сноски (HTML генерится при импорте). EPUB подхватит сам.

Буду рад замечаниям по подходу. Если делали резолв сносок иначе, расскажите как, мне правда интересно.

Риски ИИ- генерируемого кода - качество, производительность, “УСПЕВАЮ ЛИ Я ЗА ТЕМПОМ” 

ИИ генерирует код быстрее, чем мы успеваем ловить его реальные проблемы.
В JPA/Hibernate это особенно больно: код компилируется, тесты зелёные — а внутри N+1 и лишние запросы. Veai проверяет такие гипотезы на фактах проекта прямо в IDE: семантические usages, реальные прогоны тестов, coverage, debugger, доступ к исходникам Hibernate.

Не “этот код, возможно, тормозит”, а проверка через запуск. Скорость растёт — контроль над качеством остаётся. Большой разбор продукта сделан в статье

От падающего теста до правки: как General ведёт задачу в любимой IDE

Когда разработчик открывает AI-чат в IDE, он не думает категориями режимов. Он не формулирует задачу как «сначала Plan, потом Code, затем Test и Review» — он пишет проще:

Почини тест

И только по ходу становится понятно, что это за задача: иногда хватит поправить одну строку, иногда — пройти по нескольким модулям, разобраться в зависимости, изменить production-код и обновить тесты. Заранее это знать нельзя — и не нужно.

Под этот сценарий в Veai сделан режим General: вы описываете цель обычными словами, а агент сам выбирает маршрут — проход по коду, планирование, тесты, ревью, отладка или подключение субагентов. Специализированные режимы (Ask, Code, Test, Plan, Review, Debug) остаются для случаев, когда вы хотите управлять процессом явно.

Почему ручной выбор режима мешает

Реальная задача редко укладывается в один режим. «Исправить падающий тест» — это сразу несколько подзадач: понять причину, решить, где ошибка (в тесте, production-коде, моках, данных или окружении), внести правку и запустить проверку. Если режим нужно выбрать заранее, новый разработчик начинает не с решения проблемы, а с изучения классификации агентов. General убирает этот выбор из начала задачи.

Что происходит по шагам

На запрос «в сервисе оплаты падает тест, найди причину и почини» General в простом случае ведёт задачу сам:

1. находит и запускает тест через IDE run configuration — в том же окружении, что и разработчик (SDK, профиль, переменные, модули), а не в собранном из терминала, которое может отличаться;

2. читает стектрейс, открывает связанный production-код, при необходимости смотрит usages, warnings и inspections;

3. вносит минимальную правку и перезапускает проверку: тест прошёл или упал — это факт из IDE, а не предположение модели.

Если стектрейса не хватает, агент опирается на отладчик (breakpoints, значения переменных, call tree), а если стектрейс уводит в библиотеку — открывает её код или декомпилированный класс через IDE, а не угадывает API по памяти модели.

Когда подключаются субагенты

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

Полностью исключить ошибки модели нельзя. Но General опирается не только на LLM, grep и RAG, а на JetBrains IDE как на источник проверяемых фактов: run configurations, SDK и classpath, структуру кода, usages и inspections, coverage, код зависимостей и ошибки компиляции так, как их видит IDE. Отсюда меньше галлюцинаций API и ситуаций «у агента прошло, а в IDE или CI падает».

Разницу можно измерить. 

Мы прогнали 8 enterprise-задач на Java/Spring через четыре агента на одной модели — Cursor, Claude Code, JetBrains Junie и Veai:

Контроль остаётся у разработчика

Даже когда агент ведёт задачу автономно, последнее слово за человеком: разработчик смотрит diff в окне Agent Changes и решает, что принять. Перед этим General может сам прогнать несколько субагентов-ревьюеров по своим изменениям и устранить критические проблемы ещё до того, как покажет результат человеку, — авторевью встроено в маршрут, а не остаётся отдельным ручным шагом. Идея не в том, чтобы убрать review, а в том, чтобы убрать лишнюю ручную маршрутизацию до него.

Установить Veai 5.12

Обратная связь — support@veai.ru и чат с командой.

Вайб-кодинг на корпоративном контроле: как превращать хаос генерации в инженерную дисциплину

Приглашаем вас на совместный вебинар ITFB Group и компании Veai, посвящённый практике контролируемого применения ИИ в разработке.

Когда: 24 июня, 11:00
Где: онлайн

Ключевой вопрос: как использовать скорость вайб-кодинга, но при этом не допустить падения качества, потери управляемости и рисков безопасности?

О продукте

Veai — первый российский ИИ-агент, сочетающий высокую скорость генерации кода с жёстким контролем на основе формальных методов. На вебинаре мы на реальных примерах покажем, чем Veai отличается от Cursor, Copilot и других доступных на рынке решений.

Программа вебинара

— Практическая демонстрация: работа агента на реальном коде — от постановки задачи до готового результата.

— Сравнительный анализ: объективная оценка сильных и слабых сторон популярных ИИ-ассистентов.

— Метрики и экономика: данные по экономии часов, ROI, доле принятого сгенерированного кода и росту тестового покрытия (до 80% с использованием символьного исполнения и data-flow анализа).

— Работа с некомпилируемым кодом: агент автоматически выявляет и исправляет ошибки компиляции и предупреждения IDE, используя нативные инструменты без дополнительных вызовов.

— Безопасность и архитектура: варианты развертывания (on‑premise, self‑hosting, VPC, SaaS), механизмы контроля доступа и встроенный SAST-движок, проверяющий каждую генерацию.

Спикеры

— Константин Волков, менеджер по техническим решениям Veai.
— Наталья Романова, директор по развитию ITFB Group.

Формат — открытая дискуссия. Вы сможете задать любые вопросы, включая самые сложные и нестандартные.

Кому будет полезно: ИТ-директорам, руководителям разработки, архитекторам и всем, кто внедряет или планирует внедрять ИИ-инструменты в корпоративную среду.

👉 Зарегистрироваться

JEP 524 в JDK 26 — второй preview PEM API

Наконец-то работа с PEM в Java становится похожа на API, а не на набор ручного парсинга, Base64 и странных телодвижений.

Справка: PEM или Privacy-Enhanced Mail - это текстовый контейнер для криптографических данных. Проще говоря – это способ хранить или передавать ключ, сертификат или другой crypto-объект не в бинарном виде, а в текстовом.

Раньше с PEM работали так:

String pem = "-----BEGIN PUBLIC KEY-----\n"
        + Base64.getMimeEncoder(64, "\n".getBytes())
                .encodeToString(publicKey.getEncoded())
        + "\n-----END PUBLIC KEY-----";

А в обратную сторону, но уже с ручной нормализацией PEM, Base64-декодированием и KeyFactory:

String normalized = pem
        .replace("-----BEGIN PUBLIC KEY-----", "")
        .replace("-----END PUBLIC KEY-----", "")
        .replaceAll("\\s", "");

byte[] der = Base64.getDecoder().decode(normalized);

PublicKey key = KeyFactory.getInstance("EC")
        .generatePublic(new X509EncodedKeySpec(der));

По факту PEM в Java долгое время был не отдельным API, а набором низкоуровневых шагов, которые разработчик собирал руками.

А теперь это выглядит так:

var encoder = PEMEncoder.of();
String pem = encoder.encodeToString(keyPair);

var decoder = PEMDecoder.of();
KeyPair decoded = decoder.decode(pem, KeyPair.class);

То есть ключевую пару можно закодировать в PEM и декодировать обратно буквально в несколько строк.

Во втором preview:

• PEMRecord переименовали в PEM

• добавили decode()

• расширили поддержку KeyPair и PKCS8EncodedKeySpec

• упростили шифрование через EncryptedPrivateKeyInfo

А так, как все это дело еще в preview, не забываем использовать --enable-preview.

❓ Минус еще один кусок криптографической копипасты из Java-кода. PEM в Java постепенно перестает быть унылым?

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Открытый проект WebToApp позволяет превратить сайт в полноценное Android‑приложение прямо на саартфоне без ПК, Android Studio или знаний кодинга. Можно сделать приложение из обычного HTML‑сайта, React, Vue или Next.js. Также можно добавить иконку, включить блокировку рекламы и защиту приватности, тёмную тему, медиа‑инструменты и даже собственные скрипты.

Для Android вышло приложение‑брандмауэр ShizuWall, которое делает смартфон безопаснее:

• умеет полностью отключать доступ к интернету для выбранных приложений;

• допускает к сети только избранные приложение;

• запрещает фоновую интернет‑активность нежелательных приложений;

• при этом никаких VPN‑туннелей и Root‑прав не требуется — всё работает из коробки;

• бесплатно приложение на Kotlin доступно на GitHub, есть версия и в Google Play.

⚠️ Java продолжает готовиться к удалению finalize()

В рамках JDK 27 у ThreadPoolExecutor-а, очень популярного API в Java, будет удалён метод finalize(). Несмотря на то, что в силу dynamic dispatch вызов метода finalize() всё равно будет транслирован в Object, данное изменение не source level compatible.

А все потому, что у Object.finalize() сигнатура содержит throws Throwable, в то время как ThreadPoolExecutor.finalize() — нет. Пока метод был в ThreadPoolExecutor, компилятору было ок. Как только его удалят, вызов super.finalize() начнет резолвиться в Object.finalize(), и тогда прилетит “unreported exception Throwable”.

Комментарий от Михаила Поливаха:

Вот это кстати довольно редкий пример того, что имзенение может быть binary level compatible, но не source level compatible.

Например:

class MyPool extends ThreadPoolExecutor {

  @Override
  protected void finalize() {
    super.finalize(); // JDK 27: теперь это Object.finalize() throws Throwable
  }
}

Как избежать?

• поискать и удалить любые finalize() / super.finalize() (и вообще любые авто-cleanup через финализацию)

• управлять жизненным циклом executor’ов явно: shutdown()/awaitTermination() или просто close() в try-with-resources (да, ExecutorService — AutoCloseable)

Spring АйО рекомендует не использовать finalize() в целом, но если подобного рода хук нужен, то лучше использовать Java Cleaner API. С его помощью нельзя "случайно" воскресить объект, сломать integrity объекта или т.п.

Ждем JDK 27 🫠

Присоединяйтесь к русскоязычному сообществу разработчиков на Spring Boot в телеграм — Spring АйО, чтобы быть в курсе последних новостей из мира разработки на Spring Boot и всего, что с ним связано.

Автоимпорт при копировании кода — штука настолько приятная и удобная, что без неё уже невозможно представить работу в IDE. 

Мы пошли дальше и вслед за умным импортом во время набора кода сделали автоматическую инжекцию бинов при копировании кода!

Теперь при копировании кода Amplicode автоматически добавляет нужную инжекцию бинов. С учётом контекста, @Primary, @Qualifier, дженериков, @Bean-методов, Java и Kotlin — без ручной возни после вставки.

Будет доступно всем пользователям Amplicode, без подписки.

При написании интеграционных тестов для Spring Boot приложения часто возникает проблема, что разработчики бездумно добавляют аннотации @MockBean, @SpyBean, @DirtiesContext или переопределяют прямо в тестовом классе различные property. Всё это приводит к изменению Spring Context, невозможности использовать закэшированный контекст и следовательно созданию нового. Часто создание нового контекста это длительная операция.

Существуют инструменты по отслеживанию этих процессов. Самым простым способом увидеть количество контекстов и количество попаданий в кэш является добавление логирования либо через свойство logging.level.org.springframework.test.context.cache=DEBUG либо настройкой вашего логгера.

Один известный автор статей про тестирование на Java / Spring Boot, Philip Riecks (со товарищи), создал инструмент с открытым исходным кодом Spring Test Profiler при помощи которого можно получить html отчёт о поднимаемых контекстах во время тестов, о количестве и типе бинов в этих контекстах. На Хабре есть перевод его статьи в сообществе Spring АйО.

У нас на проекте стал вопрос, как нам показать разработчикам, что их тест порождает новый Спринг Контекст. Мы решили считать контексты в тестах и при превышении ожидаемого количества падать. Это "руинит" сборку и CI/CD пайплайн.
Для этого мы добавили реализацию интерфейса ContextCustomizer

class LimitingSpringContextCustomizer implements ContextCustomizer {

    private static final AtomicInteger CONTEXT_COUNTER = new AtomicInteger();
    private static final int EXPECTED_SPRING_TEST_CONTEXT_COUNT = 16;

    @Override
    public void customizeContext(ConfigurableApplicationContext context, MergedContextConfiguration mergedConfig) {
        int numberOfContexts = CONTEXT_COUNTER.incrementAndGet();
        log.info("Number of Spring Test Contexts: {}/{}", numberOfContexts, EXPECTED_SPRING_TEST_CONTEXT_COUNT);
        Assert.state(numberOfContexts <= EXPECTED_SPRING_TEST_CONTEXT_COUNT,
                () -> "Number of test contexts exceeds configured maximum: " + EXPECTED_SPRING_TEST_CONTEXT_COUNT);
    }

    @Override
    public boolean equals(Object obj) {
        return (obj != null) && (getClass() == obj.getClass());
    }

    @Override
    public int hashCode() {
        return getClass().hashCode();
    }
}

Здесь, согласно документации интерфейса ContextCustomizer необходимо корректно переопределить методы equals и hashCode.

WARNING: implementations must implement correct equals and hashCode methods since customizers form part of the MergedContextConfiguration which is used as a cache key.

Далее добавляем фабрику.

class LimitingSpringContextCustomizerFactory implements ContextCustomizerFactory {

    @Override
    public ContextCustomizer createContextCustomizer(Class<?> testClass,
                                                     List<ContextConfigurationAttributes> configAttributes) {
        return new LimitingSpringContextCustomizer();
    }
}

Затем регистрируем эту фабрику при помощи spring.factories чтобы она применялась ко всем тестам.
Для этого создаём в тестовых ресурсах файл по пути src/test/resources/META-INF/spring.factories со следующим содержимым

org.springframework.test.context.ContextCustomizerFactory=\  
com.mycompany.app.support.spring.LimitingSpringContextCustomizerFactory

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

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

Kotlin и Hyperskill: как я искал курс и что получил в итоге.

Когда я решил изучать Kotlin, ожидал, что найти хороший курс будет просто: язык популярный, используется в Android и бэкенде, вокруг много материалов. Искал менторов и упирался в людей которые знаю java и вроде как используют в работе Kotlin. Это одновременно пугало и заинтересовывало, я решил поступить как мне казалось правильным, найти готовый курс  — особенно если хочется не “смотреть видео”, а именно учиться через практику и задачи.

Я перепробовал разные форматы обучения (платные и бесплатные), поэтому в этот раз подход был простой: найти платформу, где есть структурированная программа и много практики. В итоге я добрался до Hyperskill (hyperskill.org). Это не реклама — просто личный опыт, кому-то он может сэкономить время.

Как я пришёл к ресурсу.

Изначально искал курсы по Kotlin на привычных площадках. На Stepik в тот момент не нашёл того, что мне подходило по структуре (возможно, сейчас ситуация лучше). Видео-курсы на крупных “известных сайтах” сознательно не рассматривал: мне удобнее формат “прочитал → сделал → получил проверку”.

Дальше — обычный путь через поисковик и сравнение нескольких платформ. Из того, что выглядело цельно и практично, больше всего зацепил Hyperskill. Отдельно сыграло роль то, что платформа связана с JetBra…. (то есть ребята явно понимают, как устроена экосистема вокруг Kotlin и IDE).После регистрации быстро становится понятно: платформа активно ведёт к подписке.Раньше в сети встречались статьи про возможность оформить бесплатную подписку на полгода, но это устаревшая информация — сейчас такой опции нет (по крайней мере, в том виде, в каком её описывают старые гайды).

При этом у Hyperskill есть бесплатный режим, и я проходил курс именно так.

Что я проходил: Introduction to Kotlin.

На платформе несколько треков по Kotlin, я начал с Introduction to Kotlin. По ощущениям, это “введение с практикой”:

• около 9 учебных проектов

• порядка 60–70 тем

• внутри тем — задачи/тренажёры с автоматической проверкой

В целом структура понравилась: материал подаётся дозировано, и почти сразу закрепляется практикой. Похожая на Степик.

Система “кристаллов” и лимиты.

Самая спорная часть бесплатного режима — ограничения на попытки.

У Hyperskill есть внутренняя валюта (“кристаллы”): ошибаешься в заданиях — кристаллы списываются. Когда кристаллы заканчиваются, обучение может блокироваться на 12–24 часа. Да, кристаллы можно зарабатывать активностью и выполнением некоторых задач, но при активном обучении и регулярных ошибках (что нормально) этого может не хватать.

Подписка проблему снимает, но именно этот момент сильнее всего влияет на комфорт обучения в бесплатном режиме.

Проекты: что внутри и зачем это полезно.

Сильная сторона Hyperskill — проекты. Они не выглядят как “игрушки ради галочки”, а позволяют постепенно потрогать основные конструкции языка.

Из того, что запомнилось:

• “Сапёр”

• “Крестики-нолики”

• “Чат-бот”

• “Кофемашина”

Например, в проекте “кофемашина” уже нормально используются циклы, классы и базовые элементы ООП. В таком формате проще понять, “зачем оно нужно”, чем на изолированных задачках.

Минус: часть проектов закрыта платной подпиской, и это немного обидно — именно проекты дают максимальную пользу и ощущение прогресса.

Проверка решений: не всегда понятно, почему “не принято”

Ещё один недостаток — качество обратной связи в тестах. Иногда тесты “падают” так, что ты видишь только факт ошибки, но не понимаешь причину: что именно ожидалось, на каком кейсе сломалось, где расхождение.Часть проектов проверяется через IntelliJ IDEA, и здесь иногда всплывают технические нюансы: несовпадение версий, необходимость обновить IDE или компилятор, странные падения на конкретном проекте.

Хороший момент: поддержка отвечает. По моему опыту, вопросы не игнорируют, и проблемы реально разбирают.

Итоги:

• бесплатный режим может раздражать лимитами на ошибки (кристаллы и блокировки)

• часть контента (включая проекты) закрыта подпиской

• обратная связь тестов местами недостаточно информативная

  Если готовы, то вперед!

Здравствуйте, уважаемые читатели. Обращаем ваше внимание, что в блоге SSP-Soft вышел детальный обзор нашей новой книги о технологии Jetpack Compose для Android. Jetpack Compose (в книге разобрана версия 1.6) - это передовой инструментарий для Kotlin-разработчиков, предназначенный для проектирования и модернизации пользовательских интерфейсов, рассчитанных именно на работу с мобильными устройствами. В книге также рассмотрены основы языка Kotlin для Android и работа с Android Studio. Заказывайте книгу у нас на сайте и читайте с удовольствием!

P.S. Эта книга - одна из наших лучших находок в области англоязычного самиздата, однако нас в целом интересует тема разработки на Kotlin. Если у вас есть гитхаб с черновиками, либо вы прямо сейчас готовите рукопись - не стесняйтесь написать об этом Валентину Холмогорову @Holmogorov, Олегу Сивченко @OlegSivchenkoили просто в личные сообщения в этом блоге.

Спасибо вам за ваш интерес и Сергею Березину @sergbeза вышеупомянутую рецензию.

Дело не в том как ты проходишь собеседование

Дело в том хочет человек тебя нанять или нет

Т.е. проходишь ты дальше или нет основывается не на твоих желаниях и знаниях, а на желаниях и знаниях собеседующего

Так что не парься, будь счастлив 😁

Воспринимай собеседования не как путь именно к этой работе, а как путь к чему-то вообще :)

В любом случае этот шаг делает тебя на шаг ближе к цели

Если ты не прошел собес, то выбор простой: сражайся с этим или наслаждайся этим, и даже если сражаешься, то насладись сражением 😁

P.S. И так во всём..

В продолжение темы серверного HTML рендеринга на Kotlin.

Если вы не читали статью, кратко напомню о чём речь: я написал небольшой можно сказать фреймворк для генерации HTML на стороне сервера на Kotlin. И поддержку строготипизированных routes для удобного создания ендпоинтов, ссылок на них и форм. Теперь Spring Views можно создавать на Kotlin и по крайней мере в моих проектах (а один из них очень большой - сотни отдельных страниц и десятки виджетов) это дало мне огромное удобство, уверенность, безопасность, рефакторо-пригодность, простое версионирование и переиспользование кода, например, теперь я точно не сделаю опечатку в URI или имени параметра и не смогу передать неверный тип данных на endpoint.

Одна из проблем которые до недавнего времени была в связи с использованием данного фреймворка - это CSS-стили. Приходилось либо инлайнить стили непосредственно для HTML элемента, либо мейнтейнить огромный (или несколько поменьше) CSS файл без возможности внятно следить за старыми более неиспользуемыми классами и селекторами. Кто создавал большие CSS файлы знает о чём я говорю - со временем количество классов накапливается и вычистить их не задев чего-то всё ещё нужного очень сложно. Вот так приходилось работать с CSS стилями раньше:

DIV("css-class-name") {...}
// или
DIV {
  style("color: red;")
  +"Hello World"
}

В принципе жить можно, но хотелось чего-нибудь:

• что-то на подобии Styled-Components из ReactJS, но так же на Kotlin

• по возможности поддержку JVM hot-reload в режиме отладки

• как следствие кода на Kotlin - иметь возможность всегда отслеживать зависимости и удалять более неиспользующиеся CSS-правила.

Долго думал как это получше сделать, и пока что первая версия получила вот такой синтаксис:

@Component // Spring @Component
object MyCssClass : CssClass({
  style = "color: black;"
  hover = """
    color: red;
    text-decoration: underline;
  """
})

...

A(MyCssClass) {
  href(SomeUsefulRoute(param = 1))
  +"Click me"
}

То есть объявляем object который будет нести информацию о CSS свойствах элемента. И далее просто используем его в тех же местах где раньше можно было указать css-class-name. CssClass поддерживает массу "псевдоклассов" типа hover, active, firstOfType, before, after и так далее, так же можно добавлять media брейкпоинты и всякие другие штуки. Вот более насыщенный пример:

@Component
object Container : CssClass({
    style = "padding: 25px;"
    hover = "background: #eee;"

    add(">a", "color: green;")
    add(">a:hover", "text-decoration: underline;")

    media("max-width: 991px") {
        style = "padding: 10px;"
    }
})

Вы наверняка заметили двойные скобочки ({...}) - в конструктор я передаю функцию-инициализатор стилей. Это нужно для того, чтобы в дебаг режиме JVM можно было на лету менять свойства CSS класса без перезапуска приложения: код который генерирует сам css-файл может быть запущен в режиме dev-mode, когда на каждый запрос файла будут выполнены все функции-инициализаторы ещё раз и файл будет собран заново.

Если по какой-то причине вам не нравится object - можно просто объявить class и использовать его:

@Component
class Container : CssClass({...})
...
DIV(Container::class) { ... }

Теперь в проекте порядок с CSS стилями - нет давно умерших, всегда можно найти точки использования, стили лежат рядом с виджетами и т.п.

Смотрите исходники тут. Фидбэк приветствуется, всем хорошего дня.

🎲 Retrofit 3.0 — что изменилось?

Вышел Retrofit 3.0. А точнее в один день вышло 2 версии — Retrofit 3.0 и 2.12

Библиотека важная, поэтому попробовал разобраться, что изменилось

Самое интересное случилось в 2.12 — добавили стриминговую сериализацию из Kotlin/Java-классов в Json/Protobuf

Зачем это нужно было?

➡ чтобы большие классы не сериализовывались целиком перед отправкой запроса, а начинали это делать во время передачи данных на бэк

Это позволит чутка снизить нагрузку на процессор и оперативку, если

• передаете объемные данные в теле запроса (1 мегабайт+)

• где-то вызываете Retrofit.Call.enqueue() с главного потока — стриминг перенесет сериализацию с главного UI-потока в бэкграунд

Чтобы изменения заработали, нужно создавать конвертер с помощью функции withStreaming()

MoshiConverterFactory.create(moshi).withStreaming() // пример

В Retrofit 3.0 просто апнули версию OkHttp (3.14.9 -> 4.12.0). И немного поправили внутреннего кода, пару строк для совместимости с 4.12.0

Так что если обновите версию Retrofit, у вас транзитивно апнется OkHttp — будьте внимательны, берегите себя и своих тестировщиков

Из хороших новостей — Retrofit 3.0 формальный мажор, то есть бинарно совместим с предыдущими версиями (по словам разработчиков). Мажорное версию апнули для хайпа, чтобы подчеркнуть обновление OkHttp

Пруфы:

• compare 3.0 with previous (https://github.com/square/retrofit/compare/2.12.0...3.0.0#diff-ee4546957dd484579c54b92114186cb4b3181a8906d98fbf94fbc526bf755943)(там много ченжей, но 90% из них — это обновление их website с документацией)

• compare 2.12 with previous (https://github.com/square/retrofit/compare/2.11.0...2.12.0) (тут можно посмотреть, за счет чего сериализация стала асинхронной)

остальные посты про Android публикую в https://t.me/dolgo_polo_dev

Основа Kotlin K2 компилятора — это FIR‑дерево (Frontend Intermediate Representation).

Вкратце: FIR — это AST (абстрактное синтаксическое дерево), обогащённое семантической (смысловой) информацией. Оказывается, что у этой основополагающей технологии есть своя небольшая документация: fir‑basics.md и в той части, где написано про контракты указано (в моём вольном переводе), что:

Компилятор разрешает использовать контракты в свойствах, функциях и конструкторах классов

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

А где находится то самое ограничение на использование контрактов вне функций описал Android‑разработчик Виталий Перятин в новой статье о Kotlin Contracts, где он поделился любопытными моментами, которые удалось накопать самостоятельно, потому что как парсится список эффектов, как работает новый Contracts API изнутри, и почему, чёрт возьми, на уровне компилятора можно использовать контракты не только на уровне функций, в доках не пишут.

Как ускорить Android-разработку и избавиться от мучительно долгих запусков эмуляторов ради простого теста? 

Ответ — Robolectric — мощный инструмент для UI‑тестирования Android‑кода без эмулятора. 

Позволяет запускать юнит-тесты Android-приложений прямо в JVM, без эмуляторов и физических устройств. Экономия на каждом тестовом прогоне, обратная связь почти мгновенная.

В Android‑комьюнити у Robolectric неоднозначная репутация из‑за трудностей совместимости с другими библиотеками. Но…его почти бесценные возможности пробудили любопытство и желание копнуть глубже и осмыслить этот инструмент. 

Так и родилась статья «Мечтают ли андроиды о Robolectric? Разбираем фреймворк по косточкам» от Павла Нестеренко, нашего Android-разработчика.

Если вы устали ждать, пока эмулятор запустится, и хотите гонять юнит-тесты за секунды прямо в JVM, то рекомендуем статью к прочтению!