Огромное спасибо за такой ценный комментарий! Сразу полез проверять и половина написанного оказалась про мою же дыру, которую я не видел.
Про обратный обход parentUuid подтверждаю на своих данных: в текущем транскрипте 3665 записей с uuid, а цепочка от последней записи назад проходит только 1764 из них. Меньше половины файла, остальное — боковые ветки. Я почему-то считал, что читается всё подряд, и нигде это не проверял.
А вот дальше начинается неприятное лично для меня. У меня в .gitattributes транскрипты помечены merge=union — ровно чтобы при расхождении двух машин ничего не потерялось. Смоделировал ваш сценарий: общий корень, две машины продолжили сессию независимо, git склеил. Файл валиден, все записи на месте, ни одна не пропала. Только восстановление идёт от последней записи назад, и ветка первой машины в контекст не попадает вообще. Я проверял это кодовым словом в двух ветках — читается только одно из двух.
Хуже того, моя же защита от дублей сверяет копии по множеству uuid: если все записи одной копии есть в другой, копия считается безопасной для удаления. Достижимость по цепочке при этом не проверяется. То есть формально я ничего не теряю, а фактически могу оставить файл, из которого читается не то, что человек ожидает. Пойду чинить: проверять не только совпадение uuid, но и то, что цепочка от последней записи сходится.
И спасибо отдельно за метод с кодовым словом. У меня в проверках 24 теста, и все они подтверждают, что файл доехал и лежит по нужному пути — но ни один не подтверждает, что модель на другой стороне действительно видит содержание разговора. Разница до вашего комментария была для меня неочевидной, а вы правы: пустой контекст выглядит ровно как уверенный ответ.
Подскажите, а вы у себя эту ситуацию как-то решили? Интересно, к чему пришли: чинить цепочку при склейке (перевешивать parentUuid у одной из веток), выбирать одну ветку и вторую откладывать в сторону, или вообще отказаться от автоматического слияния и разруливать руками? Может, вы нашли вариант поизящнее.
Да, всё именно так. Это не кнопка для нажатия, а именно плашка для информативности, чтоб было понятно каким именно способом можно осуществить донат (не крипта, не какой-нибудь PayPal и т.п.).
Вы похоже не полностью уловили контекст. Даже в заголовке специально отметил, что это был не чистый Vibe-Coding, т.е. ИИ использовался не от начала разработки и до самого прода. Акцент был сделан на том, что да, ИИ активно применялся, но лишь в отдельных кейсах как помощь и ускорение рутинных моментов. Конкретно это приложение разрабатывал по большей части сам и по мере наличия свободного времени, по этому делал его потихоньку.
А на полном Vibe-кодинге, вообще толком не притрагиваясь к самому коду, да, я тоже за пару дней сделал другой обширный проект, который включил себя и фронтэнд с бэкендом и отдельно KMP проект на три таргета. И потом ещё неделю-две его дошлифовывал со всех сторон, и по логике, и по UI/IX... Но то уже совсем другая история.
В этой статье была речь не о спидране на вайб-кодинге.
Спасибо за замечание. Но не нужно сразу так категорично.) Это не артефакты ИИ оформления, это я готовил статью изначально сперва в MarkDown разметке. И не разобрался сразу как в здешний редактор это форматирование корректно перенести. Проверить и поправить не успел сразу, вы очень оперативно успели первее загялнуть в эту статью))
Вы правы: генерация кода добавляет дополнительные классы в проект. Логично предположить, что больше кода = больше размер APK. Но это только на первый взгляд. Сгенерированный код даггера — это статические классы (и очень компактные) с чёткими зависимостями. Инструменты минификации (R8 или ProGuard) могут легко удалить неиспользуемые части кода или оптимизировать их (например, инлайн-функции). Поэтому, хотя сгенерированный код увеличивает исходный байткод, итоговый APK оказывается меньше, чем при использовании Koin, где runtime-рефлексия требует больше ресурсов.
Koin же использует рефлексию в runtime, и его библиотека включает универсальную логику для поиска и создания зависимостей, что занимает больше места и хуже оптимизируется. Так что, несмотря на генерацию, Dagger/Hilt дают меньший APK за счёт отсутствия runtime-оверхеда.
Огромное спасибо за такой ценный комментарий! Сразу полез проверять и половина написанного оказалась про мою же дыру, которую я не видел.
Про обратный обход parentUuid подтверждаю на своих данных: в текущем транскрипте 3665 записей с uuid, а цепочка от последней записи назад проходит только 1764 из них. Меньше половины файла, остальное — боковые ветки. Я почему-то считал, что читается всё подряд, и нигде это не проверял.
А вот дальше начинается неприятное лично для меня. У меня в .gitattributes транскрипты помечены merge=union — ровно чтобы при расхождении двух машин ничего не потерялось. Смоделировал ваш сценарий: общий корень, две машины продолжили сессию независимо, git склеил. Файл валиден, все записи на месте, ни одна не пропала. Только восстановление идёт от последней записи назад, и ветка первой машины в контекст не попадает вообще. Я проверял это кодовым словом в двух ветках — читается только одно из двух.
Хуже того, моя же защита от дублей сверяет копии по множеству uuid: если все записи одной копии есть в другой, копия считается безопасной для удаления. Достижимость по цепочке при этом не проверяется. То есть формально я ничего не теряю, а фактически могу оставить файл, из которого читается не то, что человек ожидает. Пойду чинить: проверять не только совпадение uuid, но и то, что цепочка от последней записи сходится.
И спасибо отдельно за метод с кодовым словом. У меня в проверках 24 теста, и все они подтверждают, что файл доехал и лежит по нужному пути — но ни один не подтверждает, что модель на другой стороне действительно видит содержание разговора. Разница до вашего комментария была для меня неочевидной, а вы правы: пустой контекст выглядит ровно как уверенный ответ.
Подскажите, а вы у себя эту ситуацию как-то решили? Интересно, к чему пришли: чинить цепочку при склейке (перевешивать parentUuid у одной из веток), выбирать одну ветку и вторую откладывать в сторону, или вообще отказаться от автоматического слияния и разруливать руками? Может, вы нашли вариант поизящнее.
Да, всё именно так. Это не кнопка для нажатия, а именно плашка для информативности, чтоб было понятно каким именно способом можно осуществить донат (не крипта, не какой-нибудь PayPal и т.п.).
Вы похоже не полностью уловили контекст. Даже в заголовке специально отметил, что это был не чистый Vibe-Coding, т.е. ИИ использовался не от начала разработки и до самого прода. Акцент был сделан на том, что да, ИИ активно применялся, но лишь в отдельных кейсах как помощь и ускорение рутинных моментов. Конкретно это приложение разрабатывал по большей части сам и по мере наличия свободного времени, по этому делал его потихоньку.
А на полном Vibe-кодинге, вообще толком не притрагиваясь к самому коду, да, я тоже за пару дней сделал другой обширный проект, который включил себя и фронтэнд с бэкендом и отдельно KMP проект на три таргета. И потом ещё неделю-две его дошлифовывал со всех сторон, и по логике, и по UI/IX... Но то уже совсем другая история.
В этой статье была речь не о спидране на вайб-кодинге.
Спасибо за замечание. Но не нужно сразу так категорично.) Это не артефакты ИИ оформления, это я готовил статью изначально сперва в MarkDown разметке. И не разобрался сразу как в здешний редактор это форматирование корректно перенести. Проверить и поправить не успел сразу, вы очень оперативно успели первее загялнуть в эту статью))
Прошу прощения за неудобства.
Для поиска и анализа, а так же структурирования собранной информации, больше предпочитаю Grok :)
Вы правы: генерация кода добавляет дополнительные классы в проект. Логично предположить, что больше кода = больше размер APK. Но это только на первый взгляд. Сгенерированный код даггера — это статические классы (и очень компактные) с чёткими зависимостями. Инструменты минификации (R8 или ProGuard) могут легко удалить неиспользуемые части кода или оптимизировать их (например, инлайн-функции). Поэтому, хотя сгенерированный код увеличивает исходный байткод, итоговый APK оказывается меньше, чем при использовании Koin, где runtime-рефлексия требует больше ресурсов.
Koin же использует рефлексию в runtime, и его библиотека включает универсальную логику для поиска и создания зависимостей, что занимает больше места и хуже оптимизируется. Так что, несмотря на генерацию, Dagger/Hilt дают меньший APK за счёт отсутствия runtime-оверхеда.