ну, не знаю, мне недавно статью завернули в черновики. И она действительно написана с помощью ИИ. Но... на основе моих диалогов в чатах, репозитория на гитхабе, т.е. статья вполне отражала мой личный опыт, но тратить время на переписывание под хабр я не захотел
хорошая статья с пунктами, что можно вытащить из транскрипта с помощь LLM. оставил ссылку под своей статьей о том, как на домашнем компе собрать простую систему речевой аналитики https://habr.com/ru/articles/1078350/
прикольно. а) в последнее время для таких онлайн-тулов делаю webapp - удобно, что всегда типа установлено. примерhttps://antirek.github.io/markdown-viewer/ - webapp, source https://github.com/antirek/markdown-viewer б) возможно, стоит хранить в localStorage с какой-то упрощенной защитой аля пинкод 4 знака. т.к. если это утилита для повседневного использования, то хотелось бы быстро логиниться к какому-то хранилищу
да, важна, схема БД. но та, что реально лежит в проекте, а не нарисованная в документации. потому как, оп, разрабы их меняют по мере необходимости, и если у них там своя команда, и они отдельно принимают решения по архитектуре своего проекта, то ты по факту начинаешь сверять что у вас отличается. у меня в деплое как раз содержится инфо о связях с БД, чтобы понимать сколько там чего используется из железа.
ок, мне тоже "хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью", и я ее все это хочу доставать прямо из кода. чтобы документация не догоняла. у меня такое получилось ))
вот примерно шапка моего "пульта" связи кода с железом (ниже не буду показывать, много конкретики) т.е. от репозитория мы получаем артефакты (пакеты, images) и деплоим их на контуры. при этом меня не интересует что конкретные разрабы в конкретных репозиториях пишут, рисуют и реализуют (схемы БД, openapi specs). главное,чтобы потом в деплое были указаны все связи (какие БД, какие внешние сервисы). все сущности, все связи указаны в json. к этому json и другим данным имеет доступ агент, с которым можно проговорить детали, агент в описаниях обязательно рисует схемы в mermaid - очень понятно, подробно.
прикольно, меня хватило только на такое
https://antirek.github.io/f19-lite/
круто и симпатично. у нас свой такой же комбайн, но гораздо менее интерфейсно проработанный
кстати, была цель создать красивый интерфейс - и ни одного скрина в статье )) покажите, заценим
круто! утащил статью к себе в группу https://t.me/chottodev по разработке чатов, делаю не на matrix
круто!
ну, не знаю, мне недавно статью завернули в черновики. И она действительно написана с помощью ИИ. Но... на основе моих диалогов в чатах, репозитория на гитхабе, т.е. статья вполне отражала мой личный опыт, но тратить время на переписывание под хабр я не захотел
в gigaam нет диаризации, вот пример как можно делать диаризацию https://github.com/antirek/calls-pipeline
для Codex нужен vpn?
хорошая статья с пунктами, что можно вытащить из транскрипта с помощь LLM. оставил ссылку под своей статьей о том, как на домашнем компе собрать простую систему речевой аналитики https://habr.com/ru/articles/1078350/
у мну 2 миллиарда за месяц, и это на аккаунте без автономных агентов еще
статья помогла собрать флоу https://github.com/antirek/calls-pipeline
прикольно. а) в последнее время для таких онлайн-тулов делаю webapp - удобно, что всегда типа установлено. примерhttps://antirek.github.io/markdown-viewer/ - webapp, source https://github.com/antirek/markdown-viewer б) возможно, стоит хранить в localStorage с какой-то упрощенной защитой аля пинкод 4 знака. т.к. если это утилита для повседневного использования, то хотелось бы быстро логиниться к какому-то хранилищу
жду такую
зачем приложение? может просто веб-страничку?
круто, пробовали распознавать звонки? с диаризацией справляется?
для кого и webapp годится https://antirek.github.io/markdown-viewer/ только просмотр файлов
сохраню здесь, чтобы было, как варианты примеров
используют дату, а потом change в эту дату, такой semver+
да, важна, схема БД. но та, что реально лежит в проекте, а не нарисованная в документации. потому как, оп, разрабы их меняют по мере необходимости, и если у них там своя команда, и они отдельно принимают решения по архитектуре своего проекта, то ты по факту начинаешь сверять что у вас отличается. у меня в деплое как раз содержится инфо о связях с БД, чтобы понимать сколько там чего используется из железа.
ок, мне тоже "хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью", и я ее все это хочу доставать прямо из кода. чтобы документация не догоняла. у меня такое получилось ))
https://youtu.be/OIlGahMszDI Chatto: ADR/FDR/architecture
вот примерно шапка моего "пульта" связи кода с железом (ниже не буду показывать, много конкретики) т.е. от репозитория мы получаем артефакты (пакеты, images) и деплоим их на контуры. при этом меня не интересует что конкретные разрабы в конкретных репозиториях пишут, рисуют и реализуют (схемы БД, openapi specs). главное,чтобы потом в деплое были указаны все связи (какие БД, какие внешние сервисы). все сущности, все связи указаны в json. к этому json и другим данным имеет доступ агент, с которым можно проговорить детали, агент в описаниях обязательно рисует схемы в mermaid - очень понятно, подробно.