поддерживать спеку и соответствующий код - та еще задача, как вариант, если у вас spec first, писать спеку, затем писать код, по которому генерится спека и сверять их на соответствие друг другу.
до nestjs пользовался express-openapi, там в коде дополняешь объекты и по ним потом соответствующая swagger spec генерится, описание лежит рядом с кодом. удобно, как пример https://github.com/antirek/sonata/tree/master/api/manage
чисто имхо, вы выбрали весьма академический путь - вот основы, вот IDE, вот еще Office365 и т.д.
когда если я начну писать курс по workflow automation & rpa, то вначале будет пример "как отправлять каждый день маме емейл или смс о том, что с тобой все хорошо" или "все знают этого программера, который запускать варку кофе на кофеварке в соседнем крыле здания, и как раз к тому моменту, когда к ней подходил, кофе был готов" вот репо, где вы можете взять эти workflow для uipath. вот эта штука в workflow рассматривается в главе 1, эта штука - в главе 5. а теперь, когда у вас появились идеи, что автоматизировать, пройдемся последовательно по курсу )))
кстати, почему используете uipath? как-то сравнивали с другими коммерческими и open-source решениями?
т.е. монорепозиторий - не очень, а мультирепозиторий - это каеф? а можно привести пример на чем строится мультирепозиторий? это что-то типа conda? или это можно использовать на вашей платформе?
может вы видели или знаете html-ui фреймворк или компоненты в каком либо фреймворке на react или vue для создания чатов: сообщений, картинок с превью, проигрывания в сообщения видео и аудиозаписей?
например, использую quasar (фреймворкк на vue, quasar собирает мобильное приложение под android/ios), там есть простейшее chat message компонент. для текстового обмена сообщениями - вполне, но хочется мультимедиа. и поддержку в компоненте отображения reply сообщения
А есть проект по разделению записи разговора двух участников на две дорожки, чтобы каждый участник был на отдельной дорожке? просто аудиозапись, без видео
ездил тут к теще (живет в другом городе). теща: «хочу подарить тебе зонт на др. съезди в вайлдбери и выбери» приезжаю в пункт выдачи, выдают 5 зонтов — разные ручки, расцветки, все разворачиваю, смотрю, пробую раскрывать, выбираю 1, остальные возвращаю. у тещи спрашиваю «оплата после того как забрал заказ?» оказывается, нет. она все 5 оплатила, «ну а что такого» — говорит, — «они же за отмененные заказы вернут деньги, сто раз так уже делала»
если б заказывал просто один, я онлайн недели 2 выбирал бы ;)
у вас интересная гипотеза, будет интересно проследить за ее проверкой.
заметьте, что запрос на open-source CMS есть у бизнесов, которые реализуют сайты. собственно спрос на CMS — это снижение издержек на разработку сайтов. Среднестатистической веб-студии проще сделать индивидуальный дизайн для клиента и натянуть дизайн на стандартный wordpress + докастомизировать плагинами — т.е. как раз снижение издержек на производство сайтов.
отсюда есть вывод-цепочка: производитель — дилерская сеть — конечные клиенты
приводимые как примеры амоCRM и Битрикс — это производители, их партнерские сети — работают с клиентами и зарабатывают на клиентах, сами производители не работают с конечными клиентами. они предоставляют продукт, следят за его использованием, соблюдением ограничений на использование — через лимиты тарифов и вознаграждают партнеров.
даже упомянутые open-source cms: есть сообщество разработчиков — производитель, есть веб-студии — партнерская сеть, которая разрабатывает сайты и зарабатывает на клиентах, и конечно, есть конечный клиент, который говорит: «о, да мне надо сайт»
в общем, к чему это: пока у вас не будет плана как на вас кто-то постоянно будет зарабатывать, проект вероятно не взлетит в объеме и сроках. и если вы не будете знать как вы будете зарабатывать на тех кто зарабатывает на вас, то вероятно вам проект быстро надоест ))) правда при решении этих вопросов тема open-source может отойти на второй план
еще интересный вопрос: почему должны выбрать вашу CRM, а не amo, битрикс, аденту, медеск, мэлтор, креатио, регионсофт, ретейл и десяток еще уже имеющихся на рынке в разных нишах? и кто будет делать этот выбор?
работаю с разными интеграторами и разными CRM практически каждый день — поэтому сомнений в вашем проекте у меня много, но повторюсь, будет интересно посмотреть за реализацией вашей идеи
в статье не заметил ссылки на гитхаб, вы еще ничего не выкладывали?
и немного возражу tcapb1 по поводу «CRM должна быть массовой чтобы быть конкурентной»
необязательно. сейчас разные кейсы идут. есть класс микро-CRM, которые уже более смещены на ведение лидов — к примеру, интеграция только с whatsapp и инстаграм — лиды приходят из инсты, ведутся по воронке, коммуникации только по номеру мобильного — звонки+сообщения в whatsapp. хотя конечно, очертить границы, в рамках которых будет open source CRM, не пытаясь уйти в сервер универсальных приложений достаточно сложно ))
кстати, битрикс вполне себе open-source. т.е. можно скачать виртуальную машину, найти в ней нужные директории и посмотреть исходники.
возможно, облачная open-source crm? но опять же… «где деньги, Зин?»
интересное применение на отдельной области наработанных технологий: там вот и tarantool используется на сервере, и визуальный конструктор логики — так сказать low-code для докторов ))
и, конечно, хабр не для профессиональных докторов, поэтому здесь интереснее технологичность решения: было бы интересно отдельно видеть ui для конструктруирования блок-схем как отдельный проект, который можно встроить в другие продукты
в целом, по статье и по подходу — лютая академичность и совковость. Вы все инструменты переизобретаете на свои «не имеющие аналогов на западе».
хотя вполне вероятно все эти схемы Дракона близки к диаграммам UML. Где вы отчасти решили некоторые проблемы типа лейаута элементов.
свой формат drn — это sqlite с кодом внутри? зачем так?
прикольно, как можно 20 с лишним лет выезжать на визуализации Бейсика )))
А vosk сервер у вас как запущен? сами конфигурировали для использования русскоязычной модели?
для описания всех запущенных процессов можно использовать docker-compose.yml: ваш python-бот + монго + caldi
работа с определенным API сильно зависит от Google. Оболочка предоставляет всего лишь некоторые обходные возможности, не мейнстрим. ок, протестируем, по возможности ))
самое простое решение ?
А экспорта через API, например, у них нет? Можно было бы свое приложение сделать на каком-нибудь no-code конструкторе и там слушать.
и что с этим обещанием делать? подписываться на вас? за еще одним твитом? ё-маё, вы не готовились по теме ))
вообще, PoE узкая ниша. Доля PoE портов из продаваемых портов коммутаторов по вашим данным какая? Есть что для SOHO?
Вы знаете всю логику предстоящей системы и все переменные, которые будут использоваться в системе?
неистово плюсую @nestjs/swagger )))
поддерживать спеку и соответствующий код - та еще задача, как вариант, если у вас spec first, писать спеку, затем писать код, по которому генерится спека и сверять их на соответствие друг другу.
до nestjs пользовался express-openapi, там в коде дополняешь объекты и по ним потом соответствующая swagger spec генерится, описание лежит рядом с кодом. удобно, как пример https://github.com/antirek/sonata/tree/master/api/manage
поэтому и есть open source, и возможность запускать приложения на ОС от других разработчиков
тема интересная и актуальная ?
чисто имхо, вы выбрали весьма академический путь - вот основы, вот IDE, вот еще Office365 и т.д.
когдаесли я начну писать курс по workflow automation & rpa, то вначале будет пример "как отправлять каждый день маме емейл или смс о том, что с тобой все хорошо" или "все знают этого программера, который запускать варку кофе на кофеварке в соседнем крыле здания, и как раз к тому моменту, когда к ней подходил, кофе был готов" вот репо, где вы можете взять эти workflow для uipath. вот эта штука в workflow рассматривается в главе 1, эта штука - в главе 5. а теперь, когда у вас появились идеи, что автоматизировать, пройдемся последовательно по курсу )))кстати, почему используете uipath? как-то сравнивали с другими коммерческими и open-source решениями?
вроде слова правильные, а смысл не уловил ((
т.е. монорепозиторий - не очень, а мультирепозиторий - это каеф? а можно привести пример на чем строится мультирепозиторий? это что-то типа conda? или это можно использовать на вашей платформе?
может вы видели или знаете html-ui фреймворк или компоненты в каком либо фреймворке на react или vue для создания чатов: сообщений, картинок с превью, проигрывания в сообщения видео и аудиозаписей?
например, использую quasar (фреймворкк на vue, quasar собирает мобильное приложение под android/ios), там есть простейшее chat message компонент. для текстового обмена сообщениями - вполне, но хочется мультимедиа. и поддержку в компоненте отображения reply сообщения
Спасибо, почитал и погуглил. У гугла оказывается API есть https://cloud.google.com/speech-to-text/docs/multiple-voices называют такое разделение Speaker diarization
А есть проект по разделению записи разговора двух участников на две дорожки, чтобы каждый участник был на отдельной дорожке? просто аудиозапись, без видео
ездил тут к теще (живет в другом городе). теща: «хочу подарить тебе зонт на др. съезди в вайлдбери и выбери» приезжаю в пункт выдачи, выдают 5 зонтов — разные ручки, расцветки, все разворачиваю, смотрю, пробую раскрывать, выбираю 1, остальные возвращаю. у тещи спрашиваю «оплата после того как забрал заказ?» оказывается, нет. она все 5 оплатила, «ну а что такого» — говорит, — «они же за отмененные заказы вернут деньги, сто раз так уже делала»
если б заказывал просто один, я онлайн недели 2 выбирал бы ;)
заметьте, что запрос на open-source CMS есть у бизнесов, которые реализуют сайты. собственно спрос на CMS — это снижение издержек на разработку сайтов. Среднестатистической веб-студии проще сделать индивидуальный дизайн для клиента и натянуть дизайн на стандартный wordpress + докастомизировать плагинами — т.е. как раз снижение издержек на производство сайтов.
отсюда есть вывод-цепочка: производитель — дилерская сеть — конечные клиенты
приводимые как примеры амоCRM и Битрикс — это производители, их партнерские сети — работают с клиентами и зарабатывают на клиентах, сами производители не работают с конечными клиентами. они предоставляют продукт, следят за его использованием, соблюдением ограничений на использование — через лимиты тарифов и вознаграждают партнеров.
даже упомянутые open-source cms: есть сообщество разработчиков — производитель, есть веб-студии — партнерская сеть, которая разрабатывает сайты и зарабатывает на клиентах, и конечно, есть конечный клиент, который говорит: «о, да мне надо сайт»
в общем, к чему это: пока у вас не будет плана как на вас кто-то постоянно будет зарабатывать, проект вероятно не взлетит в объеме и сроках. и если вы не будете знать как вы будете зарабатывать на тех кто зарабатывает на вас, то вероятно вам проект быстро надоест ))) правда при решении этих вопросов тема open-source может отойти на второй план
еще интересный вопрос: почему должны выбрать вашу CRM, а не amo, битрикс, аденту, медеск, мэлтор, креатио, регионсофт, ретейл и десяток еще уже имеющихся на рынке в разных нишах? и кто будет делать этот выбор?
работаю с разными интеграторами и разными CRM практически каждый день — поэтому сомнений в вашем проекте у меня много, но повторюсь, будет интересно посмотреть за реализацией вашей идеи
в статье не заметил ссылки на гитхаб, вы еще ничего не выкладывали?
и немного возражу tcapb1 по поводу «CRM должна быть массовой чтобы быть конкурентной»
необязательно. сейчас разные кейсы идут. есть класс микро-CRM, которые уже более смещены на ведение лидов — к примеру, интеграция только с whatsapp и инстаграм — лиды приходят из инсты, ведутся по воронке, коммуникации только по номеру мобильного — звонки+сообщения в whatsapp. хотя конечно, очертить границы, в рамках которых будет open source CRM, не пытаясь уйти в сервер универсальных приложений достаточно сложно ))
кстати, битрикс вполне себе open-source. т.е. можно скачать виртуальную машину, найти в ней нужные директории и посмотреть исходники.
возможно, облачная open-source crm? но опять же… «где деньги, Зин?»
и, конечно, хабр не для профессиональных докторов, поэтому здесь интереснее технологичность решения: было бы интересно отдельно видеть ui для конструктруирования блок-схем как отдельный проект, который можно встроить в другие продукты
в целом, по статье и по подходу — лютая академичность и совковость. Вы все инструменты переизобретаете на свои «не имеющие аналогов на западе».
хотя вполне вероятно все эти схемы Дракона близки к диаграммам UML. Где вы отчасти решили некоторые проблемы типа лейаута элементов.
свой формат drn — это sqlite с кодом внутри? зачем так?
прикольно, как можно 20 с лишним лет выезжать на визуализации Бейсика )))
для описания всех запущенных процессов можно использовать docker-compose.yml: ваш python-бот + монго + caldi