|
|
|
July 3rd, 2019
 | 05:26 pm - Когда требуется больше времени
В 2013 году я "завершил" интеграционную часть своего исследования в области языков программирования и моделирования. 8 месяцев (при 6 планировавшихся) переосмысления и интеграции знаний, которые десятилетиями накапливались человечеством и годами собирались мной, когда-то как хобби, а затем и целенаправленно. Цель была: вывести набор решений для создания языка программирования следующего поколения и перейти к созданию прототипа.
Предпосылки к успешности данной затеи:
1. Более 30 лет появления новых знаний со времён тех идей, на которых базируется сегодняшнее поколение, а также более полная доступность (благодаря интернету) архивных материалов.
2. Моё желание воспользоваться всем этим опытом прошлого. Как, опять же, показывает история: создатели языков чаще концентрируются на создании "better X with Y", игнорируя большую часть опыта за пределами своей привычной ниши, чем и обуславливается "топтание на месте", а местами и деградация в этой области. Видеть целое это возможность цельно решать существующие проблемы, а не создавать локальные нишевые заплатки.
В чём была ценность лично для меня, помимо научного интереса:
Необходимо было нейтрализовать сложность разработки-сопровождения для других планируемых проектов, включая представляющие коммерческий интерес. Уже тогда я понимал, обилие моментов "долго, дорого, возможны форс-мажоры" снижает шансы каждого из них. Так пусть вместо цепочки лотерей будет одна лотерея - разработка технологии, языка.
И тогда, в 2013, когда необходимая информация была выведена, я приступил к созданию прототипа компилятора. Началось бодро. Но что-то пошло не так. Я обнаружил, что пишу очередной гибридный язык, как Scala, Nemerle или сегодняшние Kotlin и Swift, но с уклоном в расширяемость. И что пишу очередной "компромисный" компилятор, где прибитые гвоздями фичи выглядят логично с точки зрения основного языка, но снижают потенциал развития. В то же время, накопленные за годы знания продолжали работать, приводя к удобным новым решениям, которые прекрасно подходили в виде EDSL-библиотечки на "допишу позже", но противоречили сложившимся дизайнам и коду прототипа уже сейчас.
Так проявилась моя ошибка. Недостаточно просто создать платформу, обеспечивающую бесшовные переходы между воплощениями "успешных идей прошлого" в виде EDSL. Интеграция старых идей порождает новые, лучше. Так разработка приостанавливается. Пишется следующий прототип, но в процессе требования опять меняются. Становится ясно, что разработка преждевременна.
С тех пор прошло 6 лет, из которых многие сотни часов были затрачены на новое исследование. Не совмещение старых успешных подходов в одном языке, а синтез новых, заменяющих как старые, так и "белые пятна" между ними. Более того, полученные таким образом дизайны также сменялись множество раз. Как и дизайн компилятора, который поначалу никак не дотягивал до желаемой системы обработки независимых правил.
Прошлым летом дизайны ещё раз изменились кардинально, но с тех пор скорее дополнялись. Модель компиляции в части совмещения независимых правил и решения противоречий OWA и CWA (open world assumption и closed world assumption) выглядит оптимально. Время действовать.
На этой неделе я начал работать над прототипом нового компилятора. С обновлёнными силами и навыками.
Планировалость одно исследование на 6 месяцев. Получилось другое на 6 лет. 6M6Y. В чём-то как 3D2Y в One Piece.
|
January 20th, 2019
| 03:25 am - Чтение 2018
Из читавшейся в прошлом году художественной литературы мне больше запомнились не конкретные тайтлы, а новый жанр - литрпг (LitRPG). Там же просто кладезь идей игрового дизайна и интерфейса, причём, промоделированных в контексте сюжета и баланса. Какие-то можно воплощать, другие "тут автор попутал, это работать не будет", но тоже создают хороший контекст для размышлений о более подходящих решениях. Но это моя профдеформация. А кому-то просто интересно читать про игроков (так же, как смотрятся прохождения игр на youtube).
В прочитанной же публицистике особенно зацепили две книги:
1. Yuval Noah Harari "Homo Deus: A Brief History of Tomorrow" (Юваль Ной Харари "Homo Deus: Краткая история завтрашнего дня"). Футурология - жанр на грани между фантастикой и реальностью, требующий от автора как хорошего понимания "здесь и сейчас", так и достаточного полёта фантазии в вариативности "завтра" (не повторения чего-то вроде "на дискету поместится библиотека"). Так что достойных книг в нём почти нет. Эта - редчайшее приятное исключение, хотя и менее крута, чем "Сумма технологии" Лема.
2. Jordan Ellenberg "How Not to Be Wrong: The Power of Mathematical Thinking" (Джордан Элленберг "Как не ошибаться. Сила математического мышления"). Несмотря на название, книгу с которым в магазине сразу поставят в раздел "популяризация науки", данное произведение не имеет ничего общего с работами клоунов вроде Гладуэлла. Это крепкая прикладная литература, в которой примеры и случаи из реального мира представлены не для удивления читателя, а в качестве моделей для применения математического аппарата, и историй его развития. Книга, способная не только наделить обычного человека знакомством с определёнными разделами математики и логики, но и улучшить связь математика с реальностью.
|
October 22nd, 2018
| 06:06 pm - Немного эволюции в визуальщине
И так, шёл 2018 год, и после пары десятилетий рассмотрения различных визуальных средств (наряду с прочими языками программирования и моделирования), я с удивлением наткнулся на решение, которое на голову выше _любых_ визуальных языков, созданных в метафоре "соединить порты".
Antimony CAD. Это практически неизвестный широкой публике хобби-продукт под Linux/macOs, но в сети можно найти пару демонстрационных видео:
https://vimeo.com/125111378
https://www.youtube.com/watch?v=uigjofZ_3HM
И так, ключевые преимущества:
1. Входные и выходные порты в одной колонке.
2. Входные порты также являются и выходными, в большинстве случаев.
Пункт [1] просто улучшает читаемость. Что же даёт [2]? При использовании визуальных средств "с портами", как правило, ваши намерения и спецификации могут быть воплощены лишь с потерями. Вы не можете заявить "Node1.N = что-то" и "Node2.N = Node1.N". Вам придётся вводить сторонние общие ноды с "ёжиками" связей. И это не только ухудшает читаемость схемы, но и отдаляет имплементацию от спецификации. В Antimony же эта проблема решена.
В общем, подход не идеальный, но это огромный шаг вперёд. Впрочем, которому как минимум три года, так что если вам уже встречалось это или другие интересные решения в нишевых продуктах - маякните в комментариях.
|
October 18th, 2018
| 01:21 am - Селфи, безопасность и децентрализация репутаций
Предыстория: Придумал я как-то раз способ использования парных и групповых селфи для идентификации людей как не-ботов при подписании сертификатов, а также как дополнительный фактор при подписании иных документов. Обсудил в общих чертах с одним товарищем, имеющим выход на приличных инвесторов, тот сказал "замечательно, готовь план разработки продукта, сейчас всё будет", некоторое время (по его словам) "вёл переговоры с инвесторами по перспективным проекта", а потом тихо слился. Ок, проехали-забыли.
Но сама идея хороша. Это дешёвая децентрализованная безопасность, а не просто "хипстерская фишка". И я решил доработать свои заметки до статьи и выпустить в информационное пространство. В этом больше смысла, чем в том чтобы питчить эту идею в закрытом режиме. Возможно я когда-нибудь займусь реализацией. Возможно это будет кто-то ещё. Возможно кто-то вдохновится и придумает решения лучше. Не знаю. А пока читайте.
Слабым звеном любой рекомендательной или репутационной системы являются посторонние акторы. В первую очередь боты, как цифровые, так и биологические, готовые поставить лайк, отзыв или "кандидат от народа!" за мелкий прайс. Во вторую - люди, не обладающие необходимыми компетенциями. Это может быть как технически безграмотный Вася, искренне верящий, что его сосед Петя великий программист, так как почистил компьютер Васи от вирусов, так и ценитель классики, минусующий современное искусство только за то, что оно "не такое".
Исключение ботов является задачей любого честного скоринга. С прочими посторонними людьми чуть хитрее. Чьё мнение важно для меня в какой-то ситуации? Зависит и от моих личных приоритетов, и от специфики ситуации. Это требует как персонификации скоринга под использование конкретным человеком, так и включения в систему оценок людьми других людей как экспертов в какой-либо области. Да, пока один настоящий эксперт подтверждает квалификацию другого, где-то рядом происходит классическое "За что же, не боясь греха, Кукушка хвалит Петуха? За то, что хвалит он Кукушку". Однако, такие оценки концентрируются в острова связей, и имея априорное знание о некоторых экспертах можно отличить соответствующие острова экспертов от островов "кукушек".
В любой своей цифровой активности человек может быть представлен сертификатом с открытым ключём. Для децентрализованного подтверждения такого сертификата (да, ключ "nn nn ..." принадлежит такому-то Иванову Ивану Ивановичу) существует Web of Trust. А экспертные оценки могут быть подписаны уже подтверждёнными ключами. Уже сейчас это можно делать. Но достаточно ли надёжно? Нет. Web of Trust создавалась для определённой гик-тусовки, не для массового использования. Если подписанный сертификат не только используется для сетевого общения, а хоть где-то может быть учтён как отдельный голос и повлиять на скоринг, то среда сертификатов будет наводнена ботами, подписывающими друг друга. Для избежания этого требуются дополнительные меры.
1. Акты подписи сертификатов (а также тех описаний или оценок, которые требуют личного взаимодействия) должны включать в себя совместные селфи участников. Никаких "это настоящий нигерийский принц, мы с ним друзья по переписке". Если вы утверждаете, что знаете данного человека как Джона Смита, и подписываете, что ему принадлежит определённый открытый ключ - сделайте совместное фото на свой смартфон и включите в подписываемый акт. Это требование не исключает возможность кражи закрытого ключа подписанта, но значительно усложняет его использование для подписи сертификатов армии ботов, а также облегчает обнаружение и исключение поддельных результатов из системы. Кроме того, совместные селфи это не обязательно два человека, какие-то виды утверждений могут подтверждаться селфи с тремя и более персонами.
2. В ряде случаев требуется подпись самой возможности подписи. Высокий процент подписей ботов (цифровых или биологических) под какой-либо информацией может влиять на оценку её достоверности. Разрешу ли я посторонним людям подписку своего сертификата? Нет. Акт должен содержать подписи всех участников. Кроме того, возможно предоставление разрешений вида "я доверяю обладателю такого-то ключа подписать такую-то информацию обо мне в ближайшие полчаса".
3. Для исключения операций "задним числом" (а также сохранения возможности доверять подписям в старых документах, если достоверно известно, что ключ был украден и применён злоумышленниками не ранее определённой даты) можно использовать блокчейн. Здесь тоже есть своя специфика. Если консенсус базируется на proof of work или proof of stake, то организаторы премайна и (что хуже) "мошенники с электростанцией" получают серьёзные преимущества в контроле над системой и могут нарушить децентрализацию. Более устойчивым может быть вариант, опирающийся на индивидуальное доверие участников сети к неким ключевым нодам. Ведь даже в случае раскола сети вполне можно одновременно пользоваться двумя образовавшимися ветками (с разными критериями скоринга), или просто проигнорировать одну из них как ботоводческую.
Создают ли эти усовершенствования, в частности, использования фотографий, новые риски безопасности? Нет. Но подвержены старым рискам, сопровождающим любого пользователя социальных сетей. Информация о ваших связях, встречах и прочей активности становится доступна широкому кругу акторов с не самыми благими намерениями. Если в каких-то аспектах жизни это не устраивает - следует использовать там другие ключи и самоидентификации.
Выше описаны отнюдь не все варианты взаимодействия. Их намного больше. Подписантом или пользователем персонифицированного скоринга может быть не только человек, но и организация. Объектом оценки или комментирования - что угодно, например, ресторан. А отзыв на этот ресторан может включать хипстерские фотографии еды, групповое селфи и подписи сразу четырёх человек, которые вместе зашли туда поужинать. Почему бы нет. Во многих нишах у репутаций уже есть как активные создатели, так и многочисленные потребители.
|
October 10th, 2018
| 03:44 pm - Comment to 'Инженеры, хватит бегать от ответственности' by tonsky
Мне кажется, что корректно идентифицируя проблему ты ошибаешься при идентификации причин. Программисты не стали менее мотивированы. Халтурщики - да, напрягаются меньше, потому что "формочки" с ошибками в девяностые падали громко, а повебень на JS тихо и незаметно для пользователя (до какого-то момента), но это тоже не является определяющим фактором.
Прикладное ПО - "лимонный" рынок по Акерлофу. Планку качества на таком рынке повышают акторы с нерыночной мотивацией. Однако, более сложные производственные цепочки (а они содержат и такие внешние артефакты как веб-браузеры, например) нивелируют вклад мотивации индивида. А именно разрастание производственных цепочек в разработке ПО мы и наблюдали в минувшие десятилетия.
Данную проблему тоже можно решать. Но сверхмотивированность индивида в цепочке даст не сверхрезультат, а выгорание.
View the entire thread this comment is a part of
|
October 9th, 2018
| 03:21 pm - Чтение и личные записи
Есть у меня пара лайфхаков для работы с информацией, весьма эволюционировавших в прошлом году.
1. Когда мне интересны обновления какого-либо блога, портала или канала на youtube, то всё отправляется в Inoreader. В отличие от решений, которыми пользовался ранее (тоже фид ридеры, но дополнениями к браузеру), здесь удобнее интерфейс и всё автоматически работает на сервере. Появились обновления культурно-развлекательного плана? Посмотрю через недельку под настроения. Новая и интересная статья у кого-то пишущего раз в полгода? Не пропадёт.
Важный момент: никогда не использовать подписки на сайтах, если вместо этого можно подписаться в своём ридере на фид сайта. Ридер показывает обновления как есть, а подписки внутри youtube, например, могут чудить, когда неестественный интеллект гугла ставит свои ошибочные предположения выше явных указаний пользователя. Да и тратить время на дополнительную проверку "а ещё что там на youtube" точно не стоит.
2. Я веду личные записи. До прошлого года для этого использовалась старая (более удобная) версия приложения Evernote, но на новой операционке она даже не запустилась. Об этой истории уже упоминалось в https://justy-tylor.livejournal.com/251595.html и https://justy-tylor.livejournal.com/251769.html
Размышляя о замене я вспомнил, как вёл свои самые первые заметки (ещё в девяностые). В программе Dos Navigator была фишка SmartPad, которая по шорткату открывающала текстовый файл с заметками, ставила курсор в конец и добавляла туда строчку с текущей датой и временем. И я решил попробовать, как пойдёт такой подход сейчас. Накидал небольшой плагин к Sublime Text, который по Ctrl+' отправляет курсор в конец открытого файла и добавляет туда отбивку с датой/временем, позволяя сразу выразить мысли, чувства или справочную информацию для чего-либо.
Для записей это оказалось лучше тех решений, которые я пробовал использовать в этом веке. А если нужна какая-либо информация, которую я записал раньше - просто использую полнотекстовый поиск в файле, и это быстрее, чем искать в заметках и последовательно отсматривать те, где найдено. Плюс все возможности текстового редактора.
Эффект, которого я не ожидал: качество заметок тоже повысилось. Когда не отвлекаешься на "как эту заметку назвать" или "в какой раздел потом переместить из unsorted", то можешь просто писать как есть, не теряя того, что не вписывается в старые правила. В личном не может быть ограничений и форматов. Да, желательно, чтобы сегодняшние заметки были понятны мне самому завтра, но они могут навсегда оставаться непонятными для кого-либо ещё, и это правильно. Преобразовать что-то личное в читаемый текст для других - отдельный труд. Должна быть понятна цель и аудитория.
Моя цель для этого текста - поделиться решениями. Не представить их как всеобще лучшие или единственно правильные. Люди разные, кому как.
|
October 3rd, 2018
| 11:11 pm - История повторяется
В начале двухтысячных я больше переписывался в FIDO. В отличие от многочисленных интернет-форумов того времени, там было всё сразу, и эхоконференции разной тематики, и локалки для своих, в наиболее удобном для чтения/общения виде. Даже к моей первой работе в игровой компании привела цепочка, начавшаяся с общения в одной из эх с её техническим директором.
Время шло, фидо уходило в прошлое вместе с модемом, и адекватной замены этому формату так и не появилось. Но появился livejournal, и друзья постепенно начали переходить туда. И это тоже было интересно, хотя иначе. Сообщества как эхи, но вместо локалок свой журнал - ты пишешь, друзья читают, появляются незнакомые люди, становятся знакомыми, и вот уже прогулки по Питеру/Москве, и так далее.
Снова изменения. Вебдваноль уходит в тень социальных сетей. Появляется вконтактик, и какое-то варьирующееся разделение. В livejournal идут лонгриды и общение по делу. На вк - фотографии, поздравления, и там вообще получается какой-то "список контактов", вместо старинной почты. А ещё там объявления о событиях, расписания танцевальных классов, расписания тренировок...
А потом ещё и facebook, потому что люди, с которыми общаешься выезжая на международные события, обычно есть там, но не в вк. И linkedin, потому что в нём обсуждение черновиков стандарта, с которым связана работа. Но в целом они запредельно неудобны, и годятся только для связи с теми, кто не представлен где-то ещё.
Но всё меняется. И сейчас основное цифровое общение это чаты. Технически на разных платформах, но снова (как в FIDO) есть и "локалки", и возможность обсудить профессиональные вопросы с людьми не слишком далёкими по inferential distance, и всякое для тела и души.
И... Это не отменяет чтения других источников, возможности опубликовать лонгрид, который по формату больше подходит сюда, или выложить в вк пару фото с поездки. Но, внезапно, оказывается более эффективно и гармонично.
|
September 24th, 2018
| 03:55 pm - Почему приложения такие медленные
В одном чатике сейчас обсуждаем http://tonsky.me/blog/disenchantment/ и почему пользовательский интерфейс в современных приложениях так тормозит, хотя на в 100 раз менее мощных компьютерах просто летал. Прозвучали разные мнения, про раздутость фреймворков, про неумение разработчиков пользоваться многозадачностью, etc. Это разумеется да. Но в первую очередь криворукость порождает проблемы сталкиваясь с несколько другими аспектами создания UI. Цитирую своё сообщение из чатика.
---
Треды нужны, чтобы UI в одном треде, а рендеринг и задачи вроде "загрузить документ" в других. Отдельно взятый UI на треды не бьётся (хотя самих UI может быть несколько: "UI приложения", "UI документа", etc), но это и не нужно, там нечему тормозить вообще. Проблемы добавляются кривыми руками:
1. Неправильная последовательность апдейтов, приводящая к тормозам вроде "обновлять сцену N раз по добавлению каждого элемента". Такие ошибки совершают при использовании любых фреймворков, будь то десктоп, веб или мобайл.
2. Невидимый мусор в сцене на 100500 экранов вверх/вниз. В десктопных фреймворках для избежания этого делают виртуальные контролы, а в вебе не заморачиваются и добавляют пейджинг или всё более тормозящую "бесконечную прокрутку" поверх привычного хуяк-хуяк (исключение - некоторые редакторы кода).
3. CSS селекторы сложнее чем "div.myitem:hover div.myitemtext" или любые лишние (из CSS reset или CSS фреймворков). Изначально эта проблема была только в вебе. Но сейчас, учитывая "приложения в браузере" на мобилках и Electron на десктопах, уже не только.
|
August 30th, 2018
| 03:22 am - Основы понимания дизайна языков
За последние 20 лет я исследовал сотни языков программирования и описания данных. Включая не только хоть как-то известные, что применяются сейчас или доступны в исторических материалах, но и множество DSL, которые (обычно без какой-либо документации) встречались в софте, играх или продуктах демосцены.
Поначалу на заинтересованные вопросы "а как разобраться в языках программирования?" я давал какие-то ссылки или собственные архивы документов. Но объёмы росли, мои оценки некоторых материалов из архивов со временем существенно менялись, и там наблюдались дыры, ибо незачем сохранять "привычное" (с чем сталкиваешься по работе, например) или откровенно вторичные решения. Однако, "привычное" при этом сугубо индивидуально, так что другому человеку мои архивы уже не подходят. В общем, оставалось только устало ответить "читай всё".
Но сейчас, в недавних разговорах, я всё же подобрал хороший рецепт. Последовательность такая:
1. Изучить материалы HOPL ( https://en.wikipedia.org/wiki/History_of_Programming_Languages ).
2. Исследовать языки из свежего Top 20 TIOBE ( https://www.tiobe.com/tiobe-index/ ). Update: Коллега в чатике верно подметил, что картину сегодняшнего дня лучше отражают данные Stack Overflow, так что вместо TIOBE можно брать их ( https://insights.stackoverflow.com/survey/2017#technology ).
Разумеется, там есть лишнее. И нет ряда языков более актуальных, как в исторической перспективе, так и сейчас. Но это не важно. Важно начать с какой-то точки, и далее личный интерес обеспечит дальнейшее развитие.
В этом смысле показательны материалы HOPL. Если при прочтении у вас возникнет ощущение "сложно, но интересно" - продолжайте. Если же это будет ощущение отторжения - ок, стоп, значит не ваша тема. Вообще, или на данном этапе жизни.
Если что: можно не разбираться в языках программирования, не понимать их как явление, но при этом быть успешным "программистом на знакомых языках и готовых фреймворках". Это не плохо и не хорошо. Разные ситуации требуют разных навыков и интересов.
|
March 26th, 2018
| 11:30 pm - Идентификация 4D-документов через криптохэши
Сейчас обнаружил, что с прошлого года так и не опубликовал пост на тему идентификаций 4D-документов. Собирался доформулировать некоторые аспекты использования таких идентификаций в языках запросов, но там как-то само фоном дошло, и это явно материал не для одного поста.
Предыстория.
Вышел тогда летом у  vitus_wagner пост с отсылкой к старой теме чеширнета (децентрализованная соцсеть), а у меня тогда мысли витали в близких направлениях (пересылка произвольных документов между личными и корпоративными системами менеджмента данных, с автоматическим встраиванием на корректную позицию, проверками целостности, etc), так что в поисках вдохновения я решил перечитать уже порядком подзабытое из https://vitus-wagner.livejournal.com/tag/cheshirenet
В чеширнете также предполагались некие типы документов и возможность публикации обновлённых версий существующих документов. Но меня смутил предлагаемый способ идентификации самих документов - на основе псевдослучайных UUID (GUID) из RFC 4122. Ещё обдумать не успел, а подсознание уже указывает: "грабли здесь, грабли".
Ведь можно взять любую отдельно взятую систему (или несколько), и заменить там сообщение с важной новостью от Пети на собщение с котофоточками от Васи, без какого-либо изменения UUID. А дальше - выяснение "что же там было на самом деле", поиск консенсуса, и прочие действия, которых можно избежать. И вот как.
Идентификация 4D-сущностей через криптохэши.
Для начала уточним терминологию. Статичный (неизменяемый) документ или отдельно взятое состояние изменяемого документа легко идентифицируются криптохэшем от данных (и иногда - от дополняющих их метаданных). Это используется во множестве современных технологий: системы контроля версий, документориентированные СУБД, magnet-ссылки и прочее. Такие неизменяемые документы или состояния/версии документов это 3D-документы, они не зависят от времени.
В свою очередь, есть 4D-документы, редактируемые. Их содержимое может быть изменено или заменено в разные моменты времени (причём, разным образом в разных возможных мирах, но не будем сейчас углубляться в эту тему). 4D - потому что появляется время как измерение (более подробно про 4D можно прочитать в BORO или ISO 15926). Соответственно 4D-документ имеет свою отдельную идентификацию, а его содержимое представлено множеством 3D-документов (версий), в зависимости от времени и других условий.
Например, обыденными идентификаторами для 4D-документов являются пути в файловое системе и HTTP/HTTPS-ссылки. Но для них необходима централизация для обеспечения уникальности, в первом случае осуществляемая операционной системой, а во втором процедурами DNS. Или альтернатива - те самые псевдослучайные UUID (GUID).
Но есть и другой способ. Если первая версия 4D-документа создаётся именно как версия (для чего достаточно, например, наличия даты и криптографической подписи), то сам 4D-документ можно идентифицировать под криптохэшу первой версии.
Пример: вы написали новую статью и запускаете её в сеть (с датой и подписью). SHA-256 от 3D-документа первой версии будет "NNN...". Затем вы обнаружили несколько опечаток и публикуете вторую версию статьи. В метаданные этой и всех следующих версий также добавляется запись "document_id:sha256:NNN...". Дата, подпись.
Чем это лучше использования псевдослучайных значений? Если идентификация 4D-документа делается по криптохэшу первой версии, то можно проверить:
1. Что некий предлагаемый 3D-документ является первой версией обсуждаемого (так как совпадёт криптохэш).
2. Что некая предлагаемая новая версия документа содержит ту же подпись, что и первая версия документа - для этого достаточно одновременно предоставить первую версию, с нужным криптохэшем.
Чуть отвлечённо.
Вообще, имеет смысл и гибридная идентификация документов, 4D и 3D одновременно. Ситуация: автор написал статью, затем обновил, вы оставили комментарий об оставшихся неточностях, автор обновил ещё раз, и теперь ваш комментарий не соответствует содержимому статьи и выглядит странно. Этого можно избежать, если документ с комментарием содержит как идентификацию 4D-документа статьи, так и идентификацию 3D-документа той версии, на которую вы отвечали: "in_reply_to(document_id:sha256:NNN1..., version_id:sha256:NNN3...)".
В общем, используйте. Возможно вам пригодится. Возможно мне пригодится.
|
|
|
