ИИ картинки должны умереть

Если делаешь какой-то контент: статью, пост, выступление или видео и хочешь добавить иллюстраций, сделанных ИИ – остановись! Хватить множить эту блевотную пересатурированную дрянь. Лучше найти на shutterstock стоковых картинок с ватермарками, это хотя бы постиронично будет смотреться.

Какие проблемы с ИИ артами (особенно если их генерить в UX-friendly решениях типа Dall-e):

Отсутствие воспроизводимости: очень тяжело заставить генерировать иллюстрации в едином стиле. Это ломает консистентность. Мозг очень хорош в распознавании образов и паттернов и сгенерированные нейросетями изображения его нагружают. Я прям чувствую эффект неузнавания на каждом новом слайде с ии-персонажами. Даже если они очень похожи друг на друга, всё равно какие-то пропорции отличаются. И это прям бесит

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

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

В целом если расчехлить миджорни от нескольких проблем можно избавиться.

Но стоит ли это затраченных усилий?

Given the opportunity, players will optimize the fun out of a game
Это знаменитая цитата Сида Мейера, гейм-дизайнера серии игр Civilization. Я в последнее время начинаю с тревогой задумываться о том, что эта цитата описывает ту жвачную дистопию в которую мы так весело и вприпрыжку несёмся.

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

Теперь чтобы насладиться альбомом любимой группы не нужно искать её диск или кассету. Даже расчехлять торренты не надо – открываешь приложение и стримишь. И вообще не нужно иметь даже любимую группу – алгоритм, зная твои вкусы, подберёт тебе песни под любое настроение или занятие. Тебе больше не нужно ничего делать, не нужно никак взаимодействовать ни с чем настоящим. Нужно лишь нажать одну кнопку "играть мою волну" – и всё. Не важно даже, слушаешь ли ты, что играет.

Кульминацией этого технологического рывка в светлое будущее стала всемирная одержимость генеративным AI. Даже если опустить протесты иллюстраторов, сценаристов и музыкантов, счесть их за ретроградов, нужно быть очень большим оптимистом, чтобы пополнить ряды AI-беливеров. Ведь конечная миссия в итоге – заменить человека. Любого. Каждого из нас. Фильм Суррогаты оставлял хотя бы надежду на то что андроидами будут управлять настоящие люди.

В мае этого года Apple выпустили рекламу своего нового iPad. В ней огромный пресс давил целую кучу музыкальных инструментов, печатных машинок, художественных принадлежностей. Высокоскоростная камера смаковала это со всех ракурсов в киношном слоу-мо. После этого варварского акта на месте преступления остался только iPad. Уверен, выйди эта реклама в начале 10-ых на пике романтизации технологий – она была бы хитом. Но в 2024 эта реклама вызвала негодование пользователей. Причём больше всего негодовали именно представители целевой аудитории – музыканты, художники, авторы текстов.

Я читаю множество историй о том, как люди удаляются из социальных сетей, хвастаются цифровым детоксом, покупают винил, отключают ебучие уведомления и всё чаще сбегают куда-то от смартфона – устройства, призванного сделать доступ ко всей информации мира простым и удобным. Даже *слишком* удобным. Я тоже унёс зарядку с прикроватной тумбочки в дальнюю комнату и учусь засыпать и просыпаться без этого сверхудобного куска металла, который стал ощущаться каким-то чужим.

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

Лучшие инженерные практики гугла #23:
счетных форм бывает только две: "один" и "много". Остальные пускай страдают

Как же я кайфую от того, что в мои рабочие обязанности входит ещё и деврел. Вот завтра будет стрим, приходите послушать и понабрасывать
https://www.tgoop.com/vertis_mobile/107

А мы в эфире!

На следующей неделе стартует погружение очередной Подлодки!

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

Поэтому я собрался рассказать про опыт создания сервиса автоматизации – маленького сервиса на Kotlin, который помогает нам связывать все инструменты вроде трекера, CI/CD, мессенджера, TMS и других для автоматизации процессов.

А ещё я давно думал как встряхнуть формат онлайн-доклада, ведь это мой чуть ли не 10й по счёту доклад на подлодке. И подготовил для вас отрисованные от руки слайды и много интерактива.

Я и так собирался этим похвастаться, а тут мне дали промик на 500 рублей скидки, хватайте: android_crew_12_c6e5HH

Посмотрел анонс Gradle 9 от команды градла чтобы вам не пришлось
В Q1 2025 (спасибо что не в Q5) нас ждёт:

Апдейт кор библиотек (а главное – встроенного котлин тулчейна до 2.0). Тут чистый кайф, скриптики на втором котлине кайфово пишутся. Надеюсь только не всплывёт несовместимостей со старыми плагинами (всплывёт, конечно же).

Provider API теперь в стейбле! А главное, они придумали миграцию для плагинов на уровне байткода при подключении. Посмотрим, не взорвутся ли какие-то плагины.

В сообщение об ошибке добавят секцию с траблшутингом и ссылочкой на доки. Не знаю, остановит ли это рядового разработчика от бездумного прожимания комбо gradle clean + invalidate cache and restart ide + rm -r ~/.gradle/caches + жалоба билд инженеру. Но если получится – классно. Я считаю, что фича не заживёт если они не откроют API разработчикам плагинов чтобы они туда свой траблшутинг вставляли.

Ну и конечно же 90% презы посвящено прописной истине, что, чтобы с gradle не было проблем – занесите им денег и купите develocity по много$/девелопер/мес. И тогда сразу и кеши заработают и тесты заавойдятся и будет сэкономлено 100500 тысяч часов разработчиков, ага.

Android разработчики ликуют – в Kotlin2 можно писать чуть-чуть меньше кода чтобы объявлять любимый "паттерн".

А я не понимаю, зачем вообще так париться? У вас что, в команде LLM-ки? Почему обязательно наружу ни в коем случае нельзя отдать мутабельную лайвдату? Как-то ведь в команде договорились код разделять на View и ViewModel? Почему вдруг не писать ничего в проперти ViewModel стало таким сложным правилом, которое нужно системой типов ограничивать?

Сегодня решил впервые обратиться к Copilot Chat чтобы разгрести проблему с переездом проекта с AGP 8.2.х на свежую (больше всего интересует 8.5.х из-за testFixtures). Там какая-то непонятка с тем что протобуф корявый и из-за этого компиляция ресурсов не работает.

Естественно эта штука на весь мой промт с описанием моей проблемы выдала самую базированную фразу в андроид разработке "а вы пробовали gradle clean, --rerun-tasks, invalidate and restart и ~/.gradle/caches почистить?". Я, естественно, от такого взбесился – мол, ты че, пёс, я девелопер продуктивити инжинёр!

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

Зато билд инженеры могут спать спокойно – гредл настраивать это вам не по картинке хml генерировать.

Наконец-то вышел эпизод подкаста мобилок Яндекс Вертикалей со мной в роли ведущего!

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

Забавно – не смотря на большой опыт публичных выступлений онлайн и вживую – всякий раз когда речь идёт про запись я тушуюсь как в первый раз. Не верите? Навалил вам закулисного кринжа, наслаждайтесь.

А отмонтированный выпуск смотрите здесь:
https://www.tgoop.com/vertis_mobile/124

Цирк со слонами
Тут мне надо было обновить в рабочем проекте android gradle plugin с версии 8.2 на 8.5+ (очень уж хотелось testFixtures). Посмотрел на release notes всех промежуточных версий и вроде всё должно было бы быть ок. Но это же gradle, а пост называется цирк со слонами, поэтому естественно всё пошло совсем не так.

Развалилась таска compileLibraryResources. Причём начиная сразу с версии agp 8.3.0. И как назло, именно в 8.3.0 было что-то сделано с шринкером ресурсов. Это меня сбило с пути и я день потратил на дебажинг шринкера, но это ни к чему не привело.

На следующий день я посмотрел на ошибку внимательнее. Стектрейс был длинный, но я же знаю что надо на root cause смотреть, а там вот такая шляпа

Caused by: java.lang.UnsupportedOperationException: This is supposed to be overridden by subclasses.
  at com.google.protobuf.GeneratedMessageV3.getUnknownFields(GeneratedMessageV3.java:302)
  at com.android.aapt.Resources$SourcePosition.getSerializedSize(Resources.java:582)

Думаю: ну учудили, в аапте бага что ли? Конечно же не могло там быть никакой баги, потому что уже пару минорных версий вышло с тех пор. Тогда конечно же подозрения пали на runtime classpath грэдла. В рабочем проекте есть немножко include build-ов и проблемы с конфликтами класспасов не редкость.

Начал дебажить при помощи ./gradlew :buildEnvironment. Там нужный аапт нужной версии, всё в порядке. Подкладываю старый аапт чтобы убедиться что это действительно не новая багуля в agp. Ничего не меняется.

Тогда я сделал отчаянный шаг – я сделал exclude аапта из всех упоминаний agp. В :buildEnvironment стало пусто. Никакого протобафа. И на моё удивление – ничего не изменилось, хотя должно было упасть с NoClassDefFoundError. И тут я понял, что слонёнок пиздит.

Обнаружить из какого jarника вылезает зависимость очень просто. Добавляем этот код в градл

println("LOLKEK: ${com.google.protobuf.GeneratedMessageV3::class.java.getResource("GeneratedMessageV3.class").path}")

И угадайте, кто виновник?

LOLKEK: file:/Users/themishkun/.gradle/caches/modules-2/files-2.1/xyz.mishkun.lobzik/lobzik/0.6.0/539de1b1b99da08ccd8570a539e7fca736d2f75/lobzik-0.6.0.jar!/com/google/protobuf/GeneratedMessageV3.class

Как говорится, главная задач сыщика – в процессе расследования не выйти на самого себя.

Оказывается я забыл включить релокейт пакетов shadow плагином в лобзике (а это, как вы помните, мой плагин для планирования модуляризации проектов). Он использует потрясающий gephi toolkit под капотом, а там внутри джарника чего только не вшито. А как известно – кто первый плагин применил того и classpath.

Чтобы пост был образовательный, посоветую хороший гайд по класспасам от создателя dependency-analysis-plugin: Build, compile, run: A crash course in classpaths - DEV Community

Опубликовал версию 1.3.0 своего плагина для leader key биндингов в intellij.
Для тех кто не в курсе – это самый удобный вид шорткатов – когда достаточно нажать один шорткат, называемый лидером и дальше введёные клавиши позволяют быстро навигироваться по меню.

Т.к. я с самого выпуска плагина 3 года назад (ого как время быстро летит) ничего не обновлял, накопилась прям пачка ишшью, которые я всю предыдущую неделю чинил.
- поддержаны F1-F12 клавиши
- поддержаны спецсимволы, вводимые с шифтом (типа >, <, ?, :, ")
- экшн который повторит предыдущую команду
- возможность забиндить несколько экшонов на одну клавишу
- отдельные конфиги под отдельные IDE
- красивости навёл с monospace шрифтом

Ну а самое главное – всё покрыл тестами, чтобы новые фичи было удобнее разрабатывать по TDD. Очень много провозился с UI тестами, потому что по ним у JB нет ни примеров ни доки нормальной, ещё и миллион вариантов как эти тесты организовать. Но я вроде воспользовался-таки самым последним и модным решением через Starter. Думаю теперь про это написать отдельный пост, чтобы знания распространялись дальше.

Конец месяца, время обзора на книжку Хорикова "Принципы юнит-тестирования".

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

Определение юнит-теста так вообще нужно вырезать
и повесить в рамочку в офисе на видном месте.

Подход что интеграционные тесты - все, что не юниты тоже спасает от душных споров ни о чём.

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

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

Вот и здесь Хориков очень много пинает книжку Growing OOS, Guided by Tests и лондонскую школу.

Мне та книга очень зашла и я не мог понять хейта. Но посмотрев ещё мнения автора в его блоге я понял причину. Я абсолютно проморгал засилие моков и взял себе только потрясающий top-down подход к TDD, которого и
придерживаюсь до сих пор. Индустрия же, наборот, впитала только моки и проигнорировала TDD. По факту из-за этой книги многие тысячи тестов вида mock Kukarek verify KoKoko. Поэтому хочу добавить дисклеймер к своему отзыву про GOOSGbT: почитайте главу про моки в книжке Хорикова.

Вот такие дела, ребята! Посоветуйте чо по продакт менеджменту разработчику почитать.

Нашел темницу в которой пытают андроид разработчиков с 2017 года