Поняли, да? Мало попросить показывать превью. Надо еще уточнить, кому именно показывать.

Себе он показывал, умник...

Эксперимент с ИИ-разработкой

Кто не знает, моя специализация - desktop. В основном на C++/Qt. Хотя пробую разное.

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

Я давно хотел сделать desktop-приложение на TypeScript. Новый для меня стек, но концепция известна, так как теми же VS Code и Obsidian я пользуюсь каждый день. Они написаны на TypeScript, и они работают.

Поэтому в августе, как только завершился курс, я начал экспериментальную разработку desktop-приложения в связке Rust / TypeScript. 

Это не поделка "в стол", а персональный софт для учёта финансов (доходы, расходы, банковские и фондовые инструменты). Навязчивая идея, на реализацию которой никогда не было ресурсов. Проще вести табличку в Excel.

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

Спустя месяц есть результаты и есть выводы. Ставьте 👍, а я в следующих постах все расскажу.

Почему, собственно, это эксперимент?

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

Итак, цели эксперимента.

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

2. Перевести учёт финансов из Excel в новое приложение. С моим количеством данных таблички уже не удобны. Получится ли создать приложение без особых усилий?

3. Оценить потенциал агентной разработки для чего-то большего, чем простой MVP. Стоит ли вообще рассматривать ответственную коммерческую разработку на этих принципах?

4. Оценить потенциал агентной разработки в незнакомом стеке. Что будет с продуктом в долгосроке при условии, что я не владею его стеком?

Это не исчерпывающий список, но общее направление передаёт точно. Я никогда так не работал, нужен опыт.

👇👇👇

И что же получилось после месяца работы.

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

2. Уйти от Excel получилось практически полностью и очень быстро. Кто бы сомневался. Остались графики и кое-какие мелочи. Это 100% будет сделано. Считаю цель достигнутой.

3. С полноценной разработкой ИИ-агентами пока не понятно. Есть ощущение, что все возможно при аккуратных процессах. Знаний в сети уже много, можно перенимать.

4. Да, сделать поделку в незнакомом стеке реально. Особенно если есть сильный инженерный бэкграунд. Это будет работать, это будет выполнять задачу пользователя. Но уверенности в поделке мало. Непривычно не знать, что у тебя там внутри. На длинной дистанции это ещё предстоит оценить.

В общем, вроде бы все работает, но на эти "вроде бы" пальцев рук не хватит. В сети транслируют разный опыт: от катастрофы до пушка-гонки. А раз так, то большой шанс оказаться где-то посередине.

Буду разбираться и вам рассказывать. Скоро покажу скриншоты с программой.

Не знаю, как у вас, но меня отладка багов безумно утомляет. Скучно. Если не поймал с нескольких заходов, то все, поплыл. Прямо в рабочем кресле 😴😅

Сколько раз нужно нажать на стрелочку рядом с «Заметки», чтобы раскрыть спойлер и увидеть список заметок по видеоконференции?

Ответ: бесконечно много.

Потому что это не спойлер, а кнопка сворачивания боковой панели. Жмак, и панель закрылась вбок. Я несколько раз попался. А заметок там нет и не было. Но почему-то очень хотелось, чтобы были 🤭

Все таки боковые панели обычно сворачиваются немного по-другому. Хороший пример - сворачивание в десктопе Telegram.

—

С натяжкой, но кейс становится 14 частью рубрики «Путаница в интерфейсах».

- Чем отличается сеньор от джуна?
- Взглядом... Взглядом на проблему.

Нужен ли в репозитории файл AUTHORS?

AUTHORS - это файл, где по именам перечислены все разработчики, когда-либо коммитившие в репозиторий. Например, файл AUTHORS есть у cppcheck.

Хорошая идея взять и перечислить всех контрибьюторов проекта. Всем весело и приятно. Это раз. А два: проще сделать копирайт в лицензии проекта. Мол, авторы - это все люди из файла и все права принадлежат им.

И все бы ничего, когда у проекта десяток авторов. А если больше? У того же cppcheck четыре с лишним сотни имен в списке. Хотя проект небольшой.

Иду смотреть другие проекты и обнаруживаю интересную вещь. У крупных репозиториев nodejs и golang файл AUTHORS когда-то был, но сейчас его нет. То есть вели-вели, а потом отказались.

Почему?

Копаю глубже и нахожу: в обоих случаях авторы просто задолбались поддерживать AUTHORS в актуальном состоянии.

В nodejs удалили файл на три с лишним тысячи авторов, а в golang - на полторы тысячи. Теперь в этих проектах история git стала единственным авторитетным источником списка (пример go).

С юридической точки зрения получается даже меньше вопросов. Файл AUTHORS, как правило, забывают обновлять, а история git, напротив, автоматически все фиксирует. На странице проекта в GitHub есть удобные инструменты для просмотра контрибьюторов: информация всегда актуальна.

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

Что думаете по этому поводу?
Как контрибьютор, хотели бы вы оказаться в файле AUTHORS или записи в истории git вам достаточно?

Компьютер - детская мечта! Я так хотел компьютер.

Теперь компьютер ждет на работе, компьютер не отпускает дома, компьютер лежит в кармане, компьютер висит на запястье, компьютер приглядывает за рулём, компьютер варит кофе, компьютер пылесосит, компьютер включает свет и откликается на "Алиса". Даже мой телевизор теперь тоже компьютер.

Бойтесь своих желаний - они имеют свойство сбываться.

SDD: когда агент спас

Наверное, всем знакома ситуация, когда начал что-то кодить, а через какое-то время осознал, что двигался немного не туда. Ну или не немного 🤭
При рефакторинге вообще милое дело вляпаться в блокер на полпути. Всегда бесило до чёртиков.

И винить обычно некого. Сам проморгал, сам вляпался, сам выкручиваешься.

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

Это уже большой плюс. Но может быть ещё лучше. Ниже живой пример.

Один из своих проектов я с самого начала веду в парадигме SDD (Spec Driven Development): сначала спеки, потом код.
Во время проработки одной из фич случился примерно такой диалог:

Я: Хочу сделать турбо-мега-фичу

ИИ: Эта фича противоречит правилу 2 из спеки А003

Я: Ты что-то не понял. Там работает вот так и вот так. Все ложится нормально.

ИИ: (долго думает)

ИИ: Я посмотрел код. Он соответствует спеке А003. Если ты решишь делать фичу, то придется менять правило 2 и переделывать это и это (перечисляет половину проекта)

Я: (уже не смешно, смотрю внимательнее и осознаю)

Я: А, точно, я забыл про это. Тогда сделаем по-другому...

Понимаете? Уже по спеке агент понял, что фича тяжело ложится. А я не понял: забыл, не уточнил, поспешил. Так ещё и не поверил сначала 😄

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

А вы создавали что-нибудь через SDD?

Начиная с какой-то версии Windows, вместо пароля можно использовать пин-код. Ввел последовательность цифр и система пустила.

Я какое-то время привыкал к тому, что ввод пин-кода не требует нажатия Enter в конце. Система сразу входит. Я же упорно продолжал нажимать Enter, пока не отвык окончательно.

Зато теперь, когда по воле случая меня заносит на Windows 7, я ввожу пароль и... жду чуда, тупо глядя в монитор 😁

Игнор коммитов в git blame

Одна из причин, почему на некоторых проектах не спешат использовать автоформаттеры кода, - это нежелание испортить историю git. И git blame в частности.

Все понимают, что при первом применении автоформаттер зацепит много строк и git blame перестанет быть информативным. Весь вывод заполнит коммит с форматированием.

Но git умеет этим управлять. Наряду с тем, как мы можем исключать файлы из отслеживания через .gitignore, мы также можем исключать ревизии из git blame через .git-blame-ignore-revs.

.git-blame-ignore-revs - это обычный файл со списком хэшей коммитов, которые не будут учитываться в выводе git blame.

Контент файла может быть примерно таким:

# First formatting with Prettier 
dd8978eab778ac2d0cf49a616c61938ac9174267

Лучше сопроводить хэш коммита комментарием, чтобы потом не вспоминать, откуда это и зачем.

При этом просто создать файл недостаточно. Надо добавить его в конфиг:

git config blame.ignoreRevsFile .git-blame-ignore-revs

Удобная функция.

Если вы давно хотели включить автоформаттер, но не хотели осложнять себе анализ git blame, самое время вернуться к теме и попробовать.

Кстати, кто-то уже пробовал .git-blame-ignore-revs?

🔥 - Да
👍 - Нет, но теперь попробую
🤔 - Нет и не буду