Comments 10
Гляньте лучше мою статью, где нет нейрослопа.
Последние воспоминания о легендарном нин-жине и его волшебной палочке $mol сподвигают меня предложить термин нинжин-слоп
Что касается предложенной статьи, то, честно говоря, она больше похожа на схоластику или на абзац из какой-нибудь заметки парторга по марксизму-ленинизму, много терминов и воды из пустого в порожнее на мааалую горстку сути
Я заглянул в ваше статью. Похоже вы себя несколько переоценили.
Взять хотя бы ваши термины: параллелизм/распределенность/ децентрализация
Я бы начал с C. A. R. Hoare — “Communicating Sequential Processes” (CACM, 1978). где и терминология получше и статья сама по себе
спасибо!
Немножко радикальное решение, но стратегически лучше всего, ИМХО, дедокументизация. Другое дело, что юзеры могут не понять такой экстрим… хотя, на практике, юзеры обычно хорошо понимают правильные вещи. Например, если им показать ШП, то они быстро вкуривают и нормализацию, и справочники и прочий РСУБДшный аппарат.
Возьмём такой вид документа, как платёжное поручение. Можно купить… скажем так, известное программное обеспечение для обработки платёжных поручений… и получить vendor lock-in. Можно вести документацию в виде пачки файлов в редакторе электронных таблиц в универсальном формате, и получить описанные в статье проблемы при коллективном редактировании. А можно разбить документ с платёжкой на 1) строку в таблице и 2) общий шаблон оформления в универсальном формате электронных таблиц, которые связываются через совпадение задаваемых юзером имени колонки в таблице и имени ячейки в шаблоне оформления в момент создания отчёта по запросу. Отчёт принципиально read-only, служит только для печати, для отправки по почте и т.п. операций. Заливка нового файла шаблона предохраняется от конфликтов check-out'ом/check-in'ом (это редкая операция, и для неё это нормально, вдобавок после check-out'а связанная таблица в базе морозится от записей). И всё, мы только что решили все проблемы с конфликтами оформления! Ну а правку строк любой SQL-сервер умеет разруливать, эту логику можно вывести юзеру без изменений. Изменение структуры таблицы (добавление колонок, переименование для синхронизации с файлом шаблона) можно защищать теми же check-out'ом/check-in'ом. Как и перезаливка шаблона, это ведь редкая операция для привилегированных юзеров.
Теперь возьмём другой юз-кейс: описание систем. Оно же — «проектная документация». Например, хелп к программе. Так вот, эти описания, по-моему, все давно уже делают в wiki-подобных движках (часто доводилось видеть Confluence, например). Идея та же. Если мы избавляемся от документов как большого вордоподобного файла с оформлением, у нас получается набор маленьких кусочков (разделов, которые в wiki выглядят как == Header 2 ==). Юзеры их пилят отдельно друг от друга → никаких конфликтов. А если вдруг начнут пилить один и тот же раздел — последний из юзеров получает сообщение об ошибке и оба идут ножками ругаться к кулеру. Если надо сгенерировать классический .doc, то это вновь генерация readonly-отчёта. Долгих оффлайнов при таком подходе тоже быть не может, и это понятно юзерам изначально (в чём и прелесть). В крайнем случае, человек в месячной командировке в места без Интернета может взять Блокнот и писать в нём маркдауном большие простыни, а потом, вернувшись, откроет свой текстовой файл, откроет приложение (например, сайт в браузере) и начнёт переносить туда текст кусок за куском, вставляя их в нужные места. Вставляя в нужные места, он будет ходить от раздела к разделу, нажимать «Отредактировать раздел», и все конфликты, в т.ч. структуры, увидит сразу. Нет неоправданных ожиданий — нет боли, а это главное.
Если пользователи совсем ультраконсервативные, и в разметку через MD/wiki-синтаксис их не заставишь, хорошо себя на практике показал тотальный guarding каждого файла check-out'ом/check-in'ом. Так было сделано в Microsoft Office, который изначально использовал ШП как collaborative-сервер (но потом Microsoft это сломал). Юзеры быстро понимали, какая это боль — гигантский файл, который хотят отредактировать одновременно 100 человек, и начинали САМИ разбивать его на кучу вордовских файлов, а файлы вставлять друг в друга через OLE. То есть, получали примерно то же, что и wiki, но с WYSIWYG'ом.
Интересный подход, даже сказал бы философский. Хотя с частью идей согласен, по некоторым моментам поспорю.
Первое. Идея «если два человека редактируют один раздел — пусть идут ругаться к кулеру» на практике плохо масштабируется. В больших командах это может породить постоянные блокировки и ожидание. Если бы guarding был достаточен, альтернативы бы не развились.
Второе. Хранить наработки отдельными кусочками хорошо для структурированных данных, документации всякие, технические задания, описания и т.п. Но это совсем плохо переносится на обычные пользовательские документы. Людям удобнее работать с цельным файлом, потому что это бережет нервы от разбрасывания внимания по тысяче вкладок, как хорошо бы они не были структурированы. Промотать две страницы вверх проще и не влечет расходов на удержание контекста по сравнению с поиском markdown-файла.
А пользователь не надо видеть что он работает со 100 отдельными документами а не одним большим.
Тут все вроде как программеры и наверное про git/ fossil слышали. Важна не про GitHub а про родной git.
У каждого «своя» версия документов и в общем случае достаточно согласованная.
Более того она обычно и множится без проблем. Бывают моменты когда надо конфликты разрешать, но если как в вашем примере: один пользователь удаляет из таблицы графу с данными за февраль а другой добавляет данные за март- то нет алгоритма, который скажет какой отчёт правильный.
Автоматическое слияние изменений все только запутает.
Поэтому правильно показать конфликт и дать пользователям решить.
Проблема в том что все «офисные» пакеты держат пользователей за дураков и пытаются «сложность» спрятать - а это невозможно.
Давайте рассмотрим сценарий:
Пользователи А,Б,С редактируют документ. Допустим правят стиль или расставляют знаки препинания.
У вас 3 версии документа, которые надо слить.
Внимание вопрос: какая версия правильная?
….
Неправильный ответ - правильная версия у начальника. А кто из них начальник -выяснить в рамках поставленной задачи нельзя.
Идея «если два человека редактируют один раздел — пусть идут ругаться к кулеру» на практике плохо масштабируется.
Вы видели «Википедию» или, хотя бы, «Луркоморье» в дни его былой популярности? Страница с обсуждением горячей статьи или спецстраница типа «ВУ» редактировалась сотнями леммингов одновременно, и благодаря тому, что каждый диалог был вынесен в отдельный раздел, это все прекрасно фунциклировало. Да, иногда ваша реплика не записывалась, и вам надо было скопировать её в буфер и обновить страницу (при этом вы видели, если кто-то уже написал то, что вы хотели сказать, и у вас появлялся шанс отредактировать свой ответ), но в большинстве случаев всё просто работало. А теперь для сравнения сделайте обсуждение в виде WYSIWYG-документа типа вордового (где разметка хранится BLOB'ами), и посмотрите, какой из этих двух вариантов на практике масштабируется хорошо, а какой — плохо.
Что касается «ругани у кулера»: кулер тогда заменял IRC, где можно было в случае необходимости обсудить конфликты правок. Надобность в этом, кстати говоря, возникла крайне редко. Обычно заранее обсуждали, кто что собирается писать.
разбрасывания внимания по тысяче вкладок … Промотать две страницы вверх проще и не влечет расходов на удержание контекста по сравнению с поиском markdown-файла.
Вы точно видели «Википедию»? Там вообще нет разбивки на проматываемые страницы, потому, что нормальные люди уже отказались от бумажного документооборота. А значит и проматываемые страницы, как элементы разбивки, устарели. Я, как бы, написал выше, что да, есть ультраконсервативные юзеры, они могут не принимать новизну и хотеть, чтобы всегда всё было как раньше, и что с этим делать, я тоже написал.
Объём контента, равный двум страницам А4 (да хоть бы и двадцати двум), не надо раскидывать по тысяче вкладок, это могут быть разделы одной статьи. А пихать контент, который потребовалось бы раскидывать по тысяче вкладок, в один вордовский файл — очень, очень плохая идея. Опять же, я выше рассказал, что юзеры в дикой природе так НЕ делали. Они так не делали сами, без менторов, без сисадминов, без ограничений софта. Они просто уставали от конфликтов, дробили документ на много файлов и вставляли их друг в друга на манер матрёшки при помощи OLE. Я много где сталкивался с документооборотом, сам его автоматизировал, и рассказываю о том, что видел своими глазами.
Я очень далёк от реализаций совместного редактирования документов, но мне доводилось решать много задач про гонки и совместный доступ к данным.
После прочтения текста выше, у меня создалось впечатление, что вы решаете «академическую задачу в вакууме», вместо того, чтобы заставить пользователей привыкнуть к нескольким почти незаметным неудобствам ради их же блага.
Взять хотя бы пример с Борей, Машей и жирным текстом. Какова вероятность, что Маша изменяет стили начертания сло́ва в том фрагменте, который редактирует Боря? Может быть, если Маша и Боря постоянно толкаются локтями при редактировании документа — что-то не так с процессами организации работы?
Задачу совместного редактирования одного документа с нескольких терминалов в своё время решали (и решили) создатели VIM: два режима, просмотр и редактирование, основной — просмотр.
Какие реальные проблемы принесет решение «разбить документ на „узлы“ (параграфы, например), сделать переход в режим редактирования узла по факту первого изменения, выход — по факту отсутствия ввода в течение, например, 10 секунд, и разрешить только одно активное редактирование»? Да, Боря раз в год увидит серый текст с подсказкой: «Маша тут копошится». И что? Разве Боря не будет сам рад оттого, что вместо игры в царя горы — он просто подождет, а потом будет работать с уже обработанным Машей куском?
Нет интернета, а когда появился — есть конфликты? — Ну отдайте вы просто эти конфликты пользователю в удобном интерфейсе, как git это делает, не нужно пытаться прыгнуть выше головы, пользователи же сами спасибо скажут.
В общем, мне кажется, что вы решаете интересные инженерные задачи, которые имеют гораздо более тривиальные, неинтересные, но ожидаемые пользователями, — решения.
Что больнее OT или CRDT в совместном редактировании? И почему до сих пор нет идеала?