Ну нужен 1) redis 2) скрипты для старта sidekiq при загрузке сервера. Последние постоянно приходится писать вручную, что в общем немного каменный век с учётом того что по факту sidekiq уже давно часть стандартного комплекта Rails.
Спасибо, как ни странно простых решений действительно не хватает, а необходимость каждый раз вручную прописывать одни и те же скрипты слегка достаёт.
Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.
Ну я примерно понимаю за что вам предыдущий аккаунт забанили.
Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
Ну я это предложил именно как относительно простой в реализации способ расширять почти произвольным образом UI, возможности чего я так понимаю сейчас нет.
Ну то есть это концепция системы плагинов именно для фронтенд-части.
Ну вот гляньте мой комментарий к ветке ниже, не знаю насколько будет полезно в вашем конкретном случае, но в теории проблем с такой реализацией не вижу.
3. Много думаем над этим, но пока не очень понятно, как это сделать универсально.
В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.
Ну то есть модульность планируется всё-таки? Боюсь даже спрашивать когда и в каком объёме, чтобы не перевести снова разговор на вопрос о том насколько я увлечённый разработчик и сколько могу платить.
Ну то есть: я могу взять любой опенсурсный проект, форкнуть его и на его базе создать новый. В этом вся суть опенсурса. Но это не делает из любого опенсурсного проекта платформу для создания <нужное подставить>.
Но ещё раз, это чисто терминологическая претензия, никаких других вопросов у меня не осталось.
Нет, всё что я хотел выяснить я уже выяснил, в принципе можете дальше не объяснять, концепция понятна.
Можем разве что поспорить по формулировкам, хотя думаю большой пользы в этом нет. Но: если я могу создать новый продукт на базе вашего только путём форка и изменения его кода — то это не платформа, а классический опенсурсный продукт.
Слушайте, ну это несерьёзный ответ. Речь вообще не о том, полезно это или нет. Речь о том, что вы себя позиционируете как ПЛАТФОРМУ.
Из ваших ответов я понимаю, что речь идёт не о платформе, а просто об опенсурсном мессенджере. Что тоже неплохо и полезно и т.д., но просто совершенно другая по сути вещь. Не было бы слова «платформа» в заголовке темы, я бы и вопросы эти задавать не стал.
Ну headless js библиотека — это понятно, она в принципе и не так нужна если есть нормальный API.
Просто получается, что если нужна какая-то минимальная кастомная функциональность (не на уровне весь UI переписать, а буквально пару элементов добавить), есть всего два варианта:
1) переписывать существующий код и получить кучу проблем с обновлением и т.д.
2) вообще выкинуть существующий front-end код и писать его с нуля под себя
Как-то оба варианта выглядят немного странно.
Вот виджеты или компоненты или что-то такое — было бы хорошо. Или наоборот, гибкая система плагинов. То есть чтобы или 1) код актора можно было относительно безболезненно встроить в существующее окружение, или 2) наоборот, кастомную функциональность можно было дописать поверх существующего кода. Второй вариант выглядит лучше, т.к. предоставляет больше возможностей, но видимо сложнее в реализации.
Так это плохо: брать готовый код и переписывать под себя. Выйдет следующее обновление и начнёт конфликтовать с моим кастомным кодом. Это вроде очевидные вещи.
Лучше всего сделайте несколько готовых примеров использования.
Реквестирую вот такой: нужен мессенджер, интегрированный в некоторый абстрактный корпоративный портал.
Интегрирован — это в плане:
1. Использует уже существующие аккаунты
2. Содержит элементы UI этого портала, ну в простейшем случае — главное меню хотя бы
3. Скажем отображает какую-то кастомную информацию у контактов, вроде: должность, отдел, непосредственный руководитель
4. Ну и получает какие-то хуки, хотя вот этот пункт я в документации как раз нашёл
Если что-то из этого сейчас невозможно, планируется ли реализовывать?
Вот да. Люди, опишите пожалуйста подробно с самого начала: что это вообще, зачем, что умеет и как с ним работать.
На всякий случай: нет, сайт и документация на эти вопросы не отвечают.
А насколько это именно платформа? Пока я вижу скорее вполне конкретный готовый продукт, который, да, можно развернуть на своём сервере и т.д.
А насколько реально создать на этой основе свой проект БЕЗ переписывания собственно кода актора? Ну или скажем встроить в существующую ERP или что-то подобное, желательно не iframe-ом.
Использую в качестве байндера в связке с Backbone на своём проекте, что хочу сказать: библиотека довольно сырая и глючная, плюс действительно подзаброшенная (см. предыдущие комментарии — там всё верно). Ну то есть к использованию не рекомендую, если только проект не совсем элементарный.
Из однозначно хороших альтернатив — Ractive.js, умеет всё то же самое, только лучше, без лишних хаков и с меньшим количеством багов. Из недостатков — к сожалению, намного больший объём.
Самая-самая последняя статья о настройке сервера для Rails
Самая-самая последняя статья о настройке сервера для Rails
Что с воркерами? Типовой конфиг rails по сути давно уже включает в себя воркеры (не помню ни одного проекта за последние года три на котором их бы не было). При этом по сложности разворачивания в продакшне одна из самых нудных задач.
Я не представляю, какого черта я делаю
Actor Open Messaging Platform от разработчика Telegram
Такой поток неадеквата (на уровне неумения читать комментарии так как они написаны, а не как они вам привиделись) в ответ на вполне нейтральные (а вообще-то даже благожелательные изначально) по тону вопросы — это показатель того, что вам явно противопоказано общаться с аудиторией.
В общем я в этом сеансе публичной психотерапевтии дальше участвовать не готов, так что adieu, далее оставляю тему в ваше полное распоряжение.
Actor Open Messaging Platform от разработчика Telegram
Ну то есть это концепция системы плагинов именно для фронтенд-части.
Actor Open Messaging Platform от разработчика Telegram
Actor Open Messaging Platform от разработчика Telegram
В теории довольно просто, не знаю насколько это так в применении к вашему конкретному случаю (могут быть какие-то ограничения со стороны реакта или вашей конкретной имплементации и т.д.): перед отрисовкой любого из основных элементов (контакт, сообщение и т.д.) кидаете эвент на который может подписаться внешний обработчик. Эвент синхронный, содержит логическое представление объекта (aka модель) и его html или dom-структуру. Во внешнем обработчике я могу отловить эвент и поменять html/dom по своему усмотрению. После этого происходит собственно отрисовка уже изменённого (ну или неизменённого если никто не менял) объекта.
Actor Open Messaging Platform от разработчика Telegram
Actor Open Messaging Platform от разработчика Telegram
Но ещё раз, это чисто терминологическая претензия, никаких других вопросов у меня не осталось.
Actor Open Messaging Platform от разработчика Telegram
Можем разве что поспорить по формулировкам, хотя думаю большой пользы в этом нет. Но: если я могу создать новый продукт на базе вашего только путём форка и изменения его кода — то это не платформа, а классический опенсурсный продукт.
Actor Open Messaging Platform от разработчика Telegram
Или я уже что-то должен вам заплатить?
В общем довольно странно вы реагируете на вопросы, которые вытекают из ваших же размытых формулировок.
Actor Open Messaging Platform от разработчика Telegram
Из ваших ответов я понимаю, что речь идёт не о платформе, а просто об опенсурсном мессенджере. Что тоже неплохо и полезно и т.д., но просто совершенно другая по сути вещь. Не было бы слова «платформа» в заголовке темы, я бы и вопросы эти задавать не стал.
Actor Open Messaging Platform от разработчика Telegram
Просто получается, что если нужна какая-то минимальная кастомная функциональность (не на уровне весь UI переписать, а буквально пару элементов добавить), есть всего два варианта:
1) переписывать существующий код и получить кучу проблем с обновлением и т.д.
2) вообще выкинуть существующий front-end код и писать его с нуля под себя
Как-то оба варианта выглядят немного странно.
Вот виджеты или компоненты или что-то такое — было бы хорошо. Или наоборот, гибкая система плагинов. То есть чтобы или 1) код актора можно было относительно безболезненно встроить в существующее окружение, или 2) наоборот, кастомную функциональность можно было дописать поверх существующего кода. Второй вариант выглядит лучше, т.к. предоставляет больше возможностей, но видимо сложнее в реализации.
Actor Open Messaging Platform от разработчика Telegram
Actor Open Messaging Platform от разработчика Telegram
Реквестирую вот такой: нужен мессенджер, интегрированный в некоторый абстрактный корпоративный портал.
Интегрирован — это в плане:
1. Использует уже существующие аккаунты
2. Содержит элементы UI этого портала, ну в простейшем случае — главное меню хотя бы
3. Скажем отображает какую-то кастомную информацию у контактов, вроде: должность, отдел, непосредственный руководитель
4. Ну и получает какие-то хуки, хотя вот этот пункт я в документации как раз нашёл
Если что-то из этого сейчас невозможно, планируется ли реализовывать?
Actor Open Messaging Platform от разработчика Telegram
На всякий случай: нет, сайт и документация на эти вопросы не отвечают.
Actor Open Messaging Platform от разработчика Telegram
В документации написано Angular, кому верить?
actor.readme.io/docs/apps#section-web
Actor Open Messaging Platform от разработчика Telegram
А насколько реально создать на этой основе свой проект БЕЗ переписывания собственно кода актора? Ну или скажем встроить в существующую ERP или что-то подобное, желательно не iframe-ом.
Перевод документации RivetsJS
Из однозначно хороших альтернатив — Ractive.js, умеет всё то же самое, только лучше, без лишних хаков и с меньшим количеством багов. Из недостатков — к сожалению, намного больший объём.
SourceTalk (сервис для обсуждения исходных кодов): релиз