Мы ищем инженера, который реализует и встроит в наш продукт редактор документов с одновременной работой команды. Суть проста на словах, но требует аккуратной инженерии: пусть хоть двое, хоть двадцать сотрудников откроют один файл разом и печатают в нём параллельно, при этом ничьи правки не должны исчезать или перетираться. Стоит одному коллеге дописать абзац — остальные видят его почти мгновенно, символ за символом, и каретка каждого из них не «прыгает», хотя окружающий текст постоянно перестраивается. Ожидаем цветные курсоры и выделения по каждому участнику, строку присутствия со списком тех, кто прямо сейчас открыл документ, и слой примечаний: выделил кусок, написал замечание, обсудил и пометил ветку как решённую.
Механизм объединения правок обязан быть бесконфликтным — рассчитываем на реализацию поверх CRDT либо операционных преобразований, а не на грубое правило «кто записал последним, тот и прав». Параллельные изменения от разных клиентов должны сходиться к идентичному результату на всех устройствах, какими бы ни были очередность прихода сообщений и сетевые задержки. Отдельно подчёркиваем автономный режим: если у человека пропал интернет, он продолжает набирать текст локально, а после возвращения в сеть его правки подтягиваются и сливаются сами, без окна ручного разрешения конфликтов и без утраченных нажатий. Нужна и развёрнутая история изменений: именованные точки сохранения, читабельная лента и откат либо сравнение с любой ранней редакцией.
Обмен данными строим на WebSocket с автоматическим восстановлением канала и управлением потоком, а решение должно выдерживать множество документов и множество активных редакторов, не упираясь в один перегруженный сервер. Относитесь к заказу как к боевому: ценим опрятные интерфейсы, покрытие тестами именно логики слияния и внятную документацию, чтобы дальше проект поддерживала наша собственная команда.
— Цветные курсоры, выделения и отметка присутствия для каждого участника
— Ядро слияния на CRDT/OT с доказанной сходимостью
— Автономная правка с автоматическим слиянием после возврата в сеть
— Примечания, ветки обсуждений и подробная история редакций
Механизм объединения правок обязан быть бесконфликтным — рассчитываем на реализацию поверх CRDT либо операционных преобразований, а не на грубое правило «кто записал последним, тот и прав». Параллельные изменения от разных клиентов должны сходиться к идентичному результату на всех устройствах, какими бы ни были очередность прихода сообщений и сетевые задержки. Отдельно подчёркиваем автономный режим: если у человека пропал интернет, он продолжает набирать текст локально, а после возвращения в сеть его правки подтягиваются и сливаются сами, без окна ручного разрешения конфликтов и без утраченных нажатий. Нужна и развёрнутая история изменений: именованные точки сохранения, читабельная лента и откат либо сравнение с любой ранней редакцией.
Обмен данными строим на WebSocket с автоматическим восстановлением канала и управлением потоком, а решение должно выдерживать множество документов и множество активных редакторов, не упираясь в один перегруженный сервер. Относитесь к заказу как к боевому: ценим опрятные интерфейсы, покрытие тестами именно логики слияния и внятную документацию, чтобы дальше проект поддерживала наша собственная команда.
— Цветные курсоры, выделения и отметка присутствия для каждого участника
— Ядро слияния на CRDT/OT с доказанной сходимостью
— Автономная правка с автоматическим слиянием после возврата в сеть
— Примечания, ветки обсуждений и подробная история редакций
