Классный доклад про работу с легаси и частые ошибки модернизации. Начинается с жизы, когда решили модернизироваться, надо еще “чуть-чуть потерпеть”, а в итоге заглохли на полпути и одновременно работают две системы параллельно.

TLDR:

Чтобы модернизироваться правильно:

1. нужно обеспечить нормальное обучение всех причастных (vs “отправить 2 инженеров на курсики”);
2. должны быть четкие зоны ответственности и возможность принимать решения (и не делать временных костылей, пока ожидаете информацию/чужое решение);
3. если решили модернизироваться, то идите до конца, без всяких “вот очень важная фича, отложим эту затею чуток”; к устранению техдолга надо подходить как к долговременным вложениям, а не хотелкам инженеров;
4. надо найти способы бороться с возросшей когнитивной сложностью (потому что мало того, что надо учиться новому, еще надо про старое не забывать и про их взаимодействие между собой)

И при всем при этом надо не забывать о том, что главное — это люди:)

Если ИИ-агент — это гиперактивный, но тупой джун, то и работать с ним надо соответствующим образом:

• Жестко декомпозировать ТЗ до микрозадач — ИИ пофиг, что он “разучится мыслить” и не будет “видеть полной картины” (он и так толком это не умеет).
• Разбить проект на модули, которые помещаются в контекст — скорее всего, это будут микросервисы в отдельных репозиториях (и пофиг, что это не самое адеватное решение).
• Снизить когнитивную нагрузку в коде (чтобы вам ее добавил ИИ, кек).
• Использовать тупой язык (т.е., не Haskell), в котором мало лишних токенов (т.е. не Java), меньше “лишних” выборов, и вообще все квадратно-гнездовое — например, Go. Кто-то так себе инфраструктуру для управления облаком навайбил.
• Все ревьюить и тестить.

Кажется, что при всем этом написание непосредственно кода инкрементального улучшения — малая доля потраченного времени.

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

Аналогично работает и с точки зрения пользователя: если интерфейс/API сложные/непонятные, и чуть что, надо RTFM, то и у чат-ботов будут трудности с использованием вашего ПО. Лучшие продукты — это те, которые в которых сложные задачи решаются просто.

Занятный доклад про подход к управлению продуктам. По сути, это ода метрикам и data-driven подходу.

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

Фичи надо жестко A/B-тестить, обложиться алертами, разработка фичи — это контролируемый эксперимент. Протестили 100500 вариантов, если что-то не поменяло метрику — то код в помойку, остальные — на доработку. Надо регулярно думать не что добавить, а что не приносит ценности, и безжалостно удалять. Пользователи врут, надо смотреть на реальное поведение, а не на то, что говорят.

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

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

Оригинальный способ использовать GPT: засквоттить имена пакетов, которые чат-бот нагаллюционировал. Привет экосистеме JS с left-pad :)

На днях обновил IntelliJ до последней версии. Уже приготовился настраивать классический интерфейс вместо нового, чтобы было “как раньше”, это уже почти стало привычкой: “опять иконки перерисовали и сделали все неудобно”.

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

Киллер-фичей для меня стала возможность засунуть кнопки для действий на верхнюю панель — более чем уверен, что и раньше можно было что-то подобное делать, но сейчас явно стало проще. Туда сразу попали и Diff, New Scratch File и Zoom, которые раньше через Shift+Shift находил. Плагин для запоминания горячих клавиш идет прямиком в помойку. Без багов, правда, не обошлось, что делать.

Ну а еще приятно, что в этом релизе есть маленький PR от меня.

В дикой природе миллион советов про то, как правильно спрашивать “ИИ”, чтобы получать правильные результаты. Если кто вдруг забыл, то GPT — это чат-бот на стероидах для генерации правдоподобного текста, а не интерфейс к энциклопедическим знаниям. Очень частый рецепт: определите роль, задайте цель, укажите ограничения и желаемый формат вывода. Иногда к этому добавляют “расскажите об аудитории”.

Честно говоря, запоминать правила для промтов — уныло. Да еще и меняются они периодически. “Ты ж AGI”, давай уже мне ответ без вот этих всех реверансов, железяка! И вообще, я аж две кнопки нажал — погугли и подумай!

Но если хочется повайбить, то простая мнемоника для запоминания (придумал не я, если что) — представить себя режиссером, который говорит актеру, что ему надо делать. А актер пусть там сымпровизирует чего, пипл схавает.

Занятный документ, который описывает способ голосования в Apache Software Foundation. Выглядит местами переусложненно, но, возможно это следствие процесса его эволюции (похожим образом эволюционируют описания командных процессов в документации, если они есть конечно). Да и вроде как красивые модели человеческих процессов редко применимы в реальности.

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

Разумеется, процесс в целом имеет смысл только в “плоских” организациях — если вы не можете договориться, но есть лицо, принимающее решение — пусть у него и болит голова. С другой стороны, если культура такая, что не все готовы настроиться на прагматичный лад и принять консенсусное решение вместо миллиона раундов обсуждений, то вряд ли использование какой-то схемы голосования сильно поможет.

Понадобилось мне упростить себе ввод, да еще и экзотическим способом — хочу быть владычицей морскою, которая может на русской раскладке писать ј, ћ, џ, ђ и прочие славянизмы.

Разумеется, вспомнил про Compose Key — не зря блог веду, получается! :). Сначала попробовал найти готовые комбинации — все стандартные комбинации можно посмотреть в файлах локали(ей):

cat /usr/share/X11/locale/en_US.UTF-8/Compose | grep č

И если для латиницы все в порядке, то ћ не будет ни в латинской раскладке, ни в русской. Придется делать самостоятельно.

Для этого нужно создать ~/.XCompose и добавить туда сначала include "%L", чтобы работало все стандартное, а потом свои правила, например

<Multi_key> <Cyrillic_CHE> : "Ћ" U040B

Тут <Multi_key> — это собственно Compose Key, <Cyrillic_CHE> — заглавная Ч, а U040B — код для Ћ. Чтобы узнать обозначение для Ч, можно использовать xev | grep keycode. А чтобы узнать код для символа (и заодно найти его) — есть встроенное приложение Character Map, можно воспользоваться онлайн-таблицами вроде этой или чуть более прикольными штуками, которые распознают рукописные символы.

Увы, чтобы протестировать все это безобразие, придется разлогиниться и залогиниться снова, какого-то более простого способа я не нашел.

Но в итоге все получилось, я доволен.

В продолжение доклада про чистое ядро и грязную оболочку — годный доклад про то, как собственно это чистое ядро моделировать и полноценно использовать систему типов для хорошего DDD. Тоже в целом базовая база. Даже если реализовать все рассказанное на уровне псевдонимов типов — уже будет неплохо. Еще у автора есть хорошая серия постов про то, как использовать типы для бизнес-логики.

Как известно, в Java есть три варианта аннотаций по RetentionPolicy:

• Compile — видны только компилятору, полезны для преобразования кода.
• Runtime — видны и при исполнении, можно сделать что-то рефлексией, например, создать класс из JSON.
• Class — записаны в байткоде, но не видны через рефлексию, могут из пользоваться инструментацией или в плагинах (чтобы делать что-то при их загрузке).

А теперь минутка извращений! Несмотря на то, что через рефлексию не видны аннотации с уровнем Class, если очень-очень надо, то можно… перепрочитать класс через что-то вроде

clazz.getResourceAsStream(clazz.simpleName + ".class")

и запихать это в ClassReader из ASM с переопределенным visitAnnotation. К счастью, в прод этот код не попал, но пики надо держать острыми.