Тестирование поиска по военно-исторической библиотеке

[iprst]

Здесь собираем обратную связь и собственные наблюдения о процессе тестирования поиска по военно-исторической библиотеке. Из собранных здесь наблюдений, замечаний и предложений можно формировать отдельные issue.

Данный комментарий можно использовать для сбора задач, например:

• [ ] Установить опытным путём наиболее оптимальную длину параграфов N;
• [x] Отключить сервис коротких ссылок на период тестирования;
• [ ] Автоматический метод определения дубликатов;
• [ ] Парсинг строк, начинающихся с тире и подобных не-буквенных символов;
• [ ] Парсинг строк, заканчивающихся двоеточием;
• [x] Добавить взаимные ссылки на военно-исторический поиск и обратно;

И так далее. Если предложение проходит проверку обсуждением, добавляем его в этот список и/или открываем issue.

[iprst]

1. Что если при склейке параграфа, в случае когда длина склеиваемых параграфов не превышает N, приводить результат к виду «один абзац» и удалять мягкие переносы? Таким образом списки и таблицы будут отображаться как сейчас с переносами, а абзацы будут собраны в один параграф.

2. Что можно сделать с дубликатами?

[audetv]

1. Что если при склейке параграфа, в случае когда длина склеиваемых параграфов не превышает N, приводить результат к виду «один абзац» и удалять мягкие переносы? Таким образом списки и таблицы будут отображаться как сейчас с переносами, а абзацы будут собраны в один параграф.

Идея интересная, надо посмотреть выдачу, поизучать. Как вариант — да, но, похоже, надо доработать условие, предлагаю еще добавить: если строка начинается с длинного тире —, то считать параграфом, фразы диалогов бывают довольно большими и могут выпасть за N. Например «Азовсталь» сразу первый параграф с диалогом, одна из фраз 437 символов. Возможно при изучении выдачи ещё условия будут замечены.

Еще: Строка заканчивается двоеточием.

По поводу N, его как-то надо определить. В начале можно просто интуитивно выбрать значение.

Понадобится доработка парсера, нужно будет все параграфы пропускать через второй фильтр, не только длинные, убирать открывающие и закрывающие div, или вообще эти <div></div> отключить в docx парсере, чтобы не ставил, т.к. во всех параграфах их надо вырезать. Как наберем необходимый функционал, в этой теме и issues, можно будет приступить к доработке парсера.

Что можно сделать с дубликатами?

Пока думаю, пытаюсь составить запрос, который бы выполнился и не упал, вместе с докером, который бы показал, только дублированные параграфы. Ищу «автоматическое» решение.

[audetv]

Подумал, пока смотрел «Хамовнические казармы» в одной из цитат есть стихотворение — четверостишие

И особист Суэтин — Неутомимый наш! — Ещё тогда приметил И взял на карандаш. -- Ведяев А.Ю. Ода контрразведке, 2021

Вот так, объединяя параграфы, мы нашли один из способов парсить стихи.

Посмотрел, что иногда диалоги начинаются с обычного тире, например, но в данном случае может попасть под условие N:

– Пойду отдохну немного, чайку хоть попью, согреюсь, – говорил Мальцев уходя забинтованным в медсанбат.

Делаем issue по пункту 1?

Что если при склейке параграфа, в случае когда длина склеиваемых параграфов не превышает N, приводить результат к виду «один абзац» и удалять мягкие переносы? Таким образом списки и таблицы будут отображаться как сейчас с переносами, а абзацы будут собраны в один параграф

Предполагаю, о замеченных условиях для объединения/разделения (тире, двоеточие и т.д.) можно писать отдельно и таких условий может набраться N-ое кол-во.

[iprst]

предлагаю еще добавить: если строка начинается с длинного тире —, то считать параграфом, фразы диалогов бывают довольно большими и могут выпасть за N.

Да, отлично. Условие по тире можно расширить до любого (почти любого) символа, не являющегося буквой [А-ЯA-Z], а вот цифры в начале нескольких строк подряд скорее всего говорят о нумерованном списке (например — оглавлении книги). То есть в идеальном случае это будет набор правил для начала строки и её длины.

Еще: Строка заканчивается двоеточием.

Верно. Далее будет идти список, или цитата, или ещё какая-то «неразрывная» часть текста. то есть :\n\r это некая сущность, после которой не может идти </p> или </div>. Хотя наверное будет какое-то количество ошибочных обработок, если после двоеточия шло изображение, которое удалено, но не имело собственной подписи.

Понадобится доработка парсера, нужно будет все параграфы пропускать через второй фильтр, не только длинные, убирать открывающие и закрывающие div, или вообще эти <div></div> отключить в docx парсере, чтобы не ставил, т.к. во всех параграфах их надо вырезать. Как наберем необходимый функционал, в этой теме и issues, можно будет приступить к доработке парсера.

Так точно. Для того и взята пара месяцев, не спешить с парсером, а погонять в нормальном режиме поисковик, ощутить на шкуре что и как, не спеша. Уже можно не спешить, пусть спокойно собирается ОС, пусть люди придут, начнут щупать, ругать или хвалить, сами пощупаем, поймём что к чему. Мы же как и остальные пока не пользовались, по сути. В качестве смены деятельности можно заняться геодезией )))

Пока думаю, пытаюсь составить запрос, который бы выполнился и не упал, вместе с докером, который бы показал, только дублированные параграфы. Ищу «автоматическое» решение.

Ага. Добавляем в список, потом из него сделаем issue.

[iprst]

По поводу N, его как-то надо определить. В начале можно просто интуитивно выбрать значение.

N скорее всего это про оптимальную длину параграфа, которая отмечена первым пунктом в «задачах». Есть проверяемое предположение, что максимум это N×2, а минимум это N/2. В принципе математически это следует из наклона графика длины параграфа, который говорит что левый хвост, то есть минимум, короче правого хвоста, то есть максимума. Физический смысл этого выражения в том, что параграфы склеиваются более эффективно и плотно, чем разделяются. Это логично: мелких обрезков изначально на несколько порядков больше, чем длинных портянок, этим и обеспечивается наклон. Думаю «двойной эн» и «половина эн» это вполне рабочая схема — таким образом вместо определения трёх чисел нужно задать всего одно.

Вот так, объединяя параграфы, мы нашли один из способов парсить стихи.

Совершенно верно. Собственно, когда вы про короткие параграфы описали вашу схему в прошлой теме, у меня зачесались руки закрыть тот старый issue, но мы однако не формализовали до конца условия по «стихам» и соответственно это не вполне «решение» — задача особо не поставлена, на уровне идеи. Нужно сформулировать и закрыть. Тут сейчас найден способ собирать строки в строфы, однако нет никакого условия по разделителям строф (четверостишия, или длинные 16 строк и тд) — возможно добавить это в условия парсеру, только как-то сформулировать логику.

Делаем issue по пункту 1?

Думаю пусть пока висит списком, лучше собрать идей, скорее всего начнутся пересечения и дополнения. Добавил идею в список в начальном комментарии.

Предполагаю, о замеченных условиях для объединения/разделения (тире, двоеточие и т.д.) можно писать отдельно и таких условий может набраться N-ое кол-во.

Да. Пока записал про «окончание двоеточием» и «начало не с буквы», но можно разбивать на отдельные пункты.

[iprst]

Есть сценарий использования поисковика, который у меня постоянно всплывает — копирование какого-то текста в браузере и поиск его в lib.svodd.ru

В хроме есть опция в меню ПКМ search google for …, есть и для других поисковых систем, а также существуют полезные надстройки для такого же поиска в википедии — выделил слово, ПКМ, пункт меню «искать там-то». Очень полезным может быть метод поиска выделенного в тексте на странице любого сайта в нашем поисковике — выделил, ПКМ → «поискать lib.svodd»

Идея на будущее.

[audetv]

Есть сценарий использования поисковика, который у меня постоянно всплывает — копирование какого-то текста в браузере и поиск его в lib.svodd.ru

Я сегодня не один раз, когда копировал какую либо фразу в поиск, думал, что нужна такая функция. И не только на десктопе и в мобильном. У меня была мысль подключить своё контекстное меню по правой кнопке мыши javascript, который изменяет стандартное поведение, но это будет работать только на наших сайтах, и может ломать привычные для пользователя сценарии, некоторые пользователи пользуются таким меню, и могут испытывать дискомфорт, ну, в общем есть минус.

А вот расширение в браузер может быть интереснее, так что почитаю как делать, в фоне задача будет. Я пока вообще ничего про это не знаю. Но это пока.

[iprst]

А вот расширение в браузер может быть интереснее, так что почитаю как делать, в фоне задача будет.

Да, именно браузерное расширение я имею в виду.

[audetv]

Отправил письмо со ссылкой, Внутри файл и этот же файл в архиве со списком параграфов, запрос из postgres: _SELECT_DISTINCT_text_book_name_count_count_FROM_db_pg_paragraph_paragraphs_doubles_202307242216.csv Список дублированных параграфов.7z

Так же получен из manticore список книг: Наименование книги, всего параграфов, кол-во уникальных параграфов в книге

Файл: Список книг с кол-вом уникальных параграфов.xlsx

Со списком параграфов не представляю как работать, смысла в нем далее видимо нет. Я сделал проверку, поискал в этом списке несколько книг, указанных в списке книг и сравнил количество параграфов, получил совпадения.

Например книга: Бабель И. Конармия, всего параграфов 19, уникальных 13, соответственно в списке дублированных параграфов (файл - архив) я нашел 6 записей - параграфов, данные совпали.

Кол-во книг, в которых содержатся дублированные параграфы — 2742 шт. Думаю, что с этим делать.

[audetv]

Думаю, что с этим делать.

Удалить дублированные параграфы из базы самое простое решение, но при каждом новой обработке docx файлов парсером, после обработки нужно будет проверять на дубли и удалять их снова из базы, как то это выглядит не рационально, поэтому думаю, что можно сделать.

[iprst]

Со списком параграфов не представляю как работать, смысла в нем далее видимо нет.

Можно его открыть в Sublime или PowerGREP или в подобных редакторах, работающих с regex, и найти подходящий перебиратель дубликатов, который автоматически заменит дубли. Я вчера пробовал делать это внутри docx архивов (полученных из html они самые подозрительные) посредством PowerGREP, в принципе работает, но после очень долгого подсчёта оставшегося времени (где-то час считал), он показал что осталось что-то типа 90 часов, и я выключил — вероятно формула не очень эффективная или docx слишком медленный. Внутри одного файла должно быть быстрее.

[iprst]

Кол-во книг, в которых содержатся дублированные параграфы — 2742 шт. Думаю, что с этим делать.

Попробовать сличить список «содержащие дубликаты» и файл html-to-docx — есть подозрение, что они совпадают на 100% в том списке 2784 файла, а у вас получилось 2742. Все дубликаты, которые мне попались вручную при использовании поисковика, кроме тех, у которых чуть разные названия книг которые я пропустил — это были именно дубли внутри одного файла, и это были файлы экспорта из html.

[iprst]

Если установим, что проблема возникает именно в файлах из списке html-to-docx, то просто зачистим сами файлы, пусть даже нерациональным методом на 90 часов обработки, пусть так, зато навсегда.

Если проблема шире, то будем смотреть откуда ещё она прилетает системно, пока не представляю.

[audetv]

Можно его открыть в Sublime или PowerGREP или в подобных редакторах, работающих с regex, и найти подходящий перебиратель дубликатов, который автоматически заменит дубли.

В размещенном файле, уже список дублированных параграфов и имя книги, там зафиксирован сам факт, что параграфы повторяются и текст повторяющегося параграфа. В этом файле нет смысла что-то менять, он похоже больше для ознакомления.

Если установим, что проблема возникает именно в файлах из списке html-to-docx, то просто зачистим сами файлы, пусть даже нерациональным методом на 90 часов обработки, пусть так, зато навсегда.

Если проблема шире, то будем смотреть откуда ещё она прилетает системно, пока не представляю.

Да, хорошо, для начала сравню списки. Потому как начал искать решение, нашел LHS, hash, minhash, simhash и прочее, проблема известная, имеет несколько реализаций, знакома гуглам , яндексам для удаления дублей html станиц и т.д. Например, адреса http://domain.loc и http://domain.loc?=utm разные, а страницу сервер отдает одну, в вебе такое сплошь и рядом. Это все можно спокойно изучать, т.к. сходу ничего не понятно, в том плане, чтобы сесть и написать программу, после прочтения.
Эти алгоритмы, наверное, больше имеет смысл применить, если поисковик будет заточен под сбор новостей и пр. web2.0 Но пока у нас книги, и если мы сможем решить и убрать в файлах дубли, это на данный момент проще. Поэтому пока сравню списки.

[iprst]

В размещенном файле, уже список дублированных параграфов и имя книги, там зафиксирован сам факт, что параграфы повторяются и текст повторяющегося параграфа. В этом файле нет смысла что-то менять, он похоже больше для ознакомления.

Понял. Я уже потом сообразил, что написал ерунду, но не стал удалять, логика в целом подходит для других объектов, которые можно ре-импортировать в базу.

начал искать решение, нашел LHS, hash, minhash, simhash и прочее, проблема известная

Так понятно что можно посчитать какие-то хэши в базе и таким образом зачистить дубликаты, но это выгодно на уровне той базы, которая работает с динамическими данными, а так как у нас набор статический, следует обрабатывать сам набор. Вы то же пишете далее.

Это все можно спокойно изучать, т.к. сходу ничего не понятно, в том плане, чтобы сесть и написать программу, после прочтения.

Существует вопрос актуальности такой задачи — ваше время это ресурс, и пока к нам никто из программистов не присодинился, приходится ваш ресурс учитывать в наиболее оптимальной мере, как это представляется.

[iprst]

Существует вопрос актуальности такой задачи — ваше время это ресурс, и пока к нам никто из программистов не присодинился, приходится ваш ресурс учитывать в наиболее оптимальной мере, как это представляется.

Пока мы даже не добрались до геодезии, а в поисковиках можно зависнуть надолго.

[audetv]

Существует вопрос актуальности такой задачи — ваше время это ресурс, и пока к нам никто из программистов не присодинился, приходится ваш ресурс учитывать в наиболее оптимальной мере, как это представляется.

Пока мы даже не добрались до геодезии, а в поисковиках можно зависнуть надолго.

Да, согласен, но похоже, нужна будет ваша помощь. Я уже не первый день думаю с чего начать, ещё с прошлой недели, я ни один раз прочитал файлы с описанием в геоматрице, но пока так и не смог найти ту ниточку, чтобы образно потянуть и распутать клубок в голове, для меня это еще не сложилось в мозаику, то какой должна быть программа. Ощущение, что близко и вот вот, но пока не сформировал мысль, да и короткие/длинные параграфы на той неделе плотно отвлекли, но итог — запустили библиотеку. И теперь надо начинать. Самое сложное для меня сейчас - это выбрать и с чего то начать. Продолжу далее в геоматрице.

[iprst]

Бот-комментатор, цитирующий относительно случайным образом 1-2 результата выдачи по запросу из «специальных слов», размеченных в системе и найденных в комментарии.

Кто-то пишет:

«текст текст текст текст текст текст РАБЫ текст текст текст текст САХАР текст текст текст текст текст текст ФРАНЦИЯ» — система ищет «рабы сахар франция» и получает 31 замечательный результат, из которого можно выбрать ответ.

Можно гарантировать, что это будет фурор.

Протестировать можно без бота, обработав любой комментарий таким образом, взяв из него 3-4 ключевых слова.

[audetv]

Бот-комментатор, цитирующий относительно случайным образом 1-2 результата выдачи по запросу из «специальных слов», размеченных в системе и найденных в комментарии.

Кто-то пишет:

«текст текст текст текст текст текст РАБЫ текст текст текст текст САХАР текст текст текст текст текст текст ФРАНЦИЯ» — система ищет «рабы сахар франция» и получает 31 замечательный результат, из которого можно выбрать ответ.

Можно гарантировать, что это будет фурор.

Протестировать можно без бота, обработав любой комментарий таким образом, взяв из него 3-4 ключевых слова.

Ага, получится генератор контента, кто-то назовет его ИИ, только в отличии от веб 2.0 совсем иного рода генратор, можно и в телегу выдавать результат, а можно на специальную страницу, на сайте. В установленные промежутки бот будет комментировать.

Но вот как определить эти 3-4 слова? Можно, например, закинуть все фразу комментария в запрос:

call keywords('текст текст текст текст текст текст РАБЫ текст текст текст текст САХАР текст текст текст текст текст текст ФРАНЦИЯ', 'common_library',1 as stats);

Получить статистику слов:

+------+----------------+------------+--------+--------+
| qpos | tokenized      | normalized | docs   | hits   |
+------+----------------+------------+--------+--------+
| 6    | текст          | текст      | 71982  | 94978  |
| 7    | рабы           | раб        | 24016  | 33096  |
| 12   | сахар          | сахар      | 27942  | 35483  |
| 19   | франция        | франц      | 227306 | 388834 |
+------+----------------+------------+--------+--------+

На этой статистики рассчитать tf и tf-idf

Получится типа такого: текст^19.897051781793 рабы^6.0719310125429 сахар^5.9205262044678 франция^3.8243913987858

Как-то на основании этих расчетов и плюс еще что-то: рандом, наличие терминов из концептуального словаря или специального другого словаря добавляли бы ранг слову , для решения по его выбору для запроса.

Пока все.

[iprst]

как определить эти 3-4 слова?

Есть таблица специального словаря, примерно того типа как вы показывали в примере с контент-якорями из «интересных слов». Мы тогда сошлись на том, что ребята изобрели словарь наших сущностей.

Далее к этой таблице прикручивается вторая таблица, например частот появления слов и расстояний между якорем и целевым словом. Можно найти и другие подобные критерии. Это уже ближе к ИИ, но не обязательно ИИ, это просто таблица.

Соответственно из всех доступных статистических методов включая эти считается некий ранг слова и к нему ищутся 2-3 спутника, вот и получается запрос. Он не всегда будет блестящим, но фурор точно будет.

На этой статистики рассчитать tf и tf-idf

Получится типа такого: текст^19.897051781793 рабы^6.0719310125429 сахар^5.9205262044678 франция^3.8243913987858

Как-то на основании этих расчетов и плюс еще что-то: рандом, наличие терминов из концептуального словаря или специального другого словаря добавляли бы ранг слову , для решения по его выбору для запроса.

Пока все.

Да. Это на будушее, и в котелок закинуть, чтобы варилось. У меня это представление появилось тоже не случайно — после вчерашнего разбора «обратного» решения задач при проверке, я понял что ситуация ещё шире. В данном случае у нас есть отличный поисковик с шикарными ответами…

НА НЕСУЩЕСТВУЮЩИЕ ЗАПРОСЫ

[iprst]

Может быть ум за разум зашёл, но зачем я написал что нужно отключить короткие ссылки (и оставить кнопку контекста) когда нужно было сделать наоборот?

Или нет?

Не соображу условий полностью. Но вроде коротким ссылкам всё равно какой длины параграфы и как они побиты — имеет значение только термины запроса. А вот контекст полностью зависит от того, как побиты параграфы и какие у них uuid.

[audetv]

Зашел, и у меня зашел разум, я когда отключал, думал только о параграфах, потом была мысль написать, а зачем мы ссылки отключили, но не написал, тестируем и прочее, хотя сегодня опять утром была мысль написать, давайте включим ссылки,

Мы как-то с вами обсуждали короткую ссылку на контекст, что она будет основным доказательством в баталиях, вот такие ссылки сейчас не надо создавать, но такого функционал еще и нет, я его не написал. Так что, мне кажется надо включать ссылки для поисковой строки и пользоваться, а то, судя по статистике, вечера народ без коротких ссылок даже ленится вбивать поисковые запросы в строку, переходят, смотрят, а вбить «галичина 22 июля» не все смогли. Чисто с управленческой точки надо включать ссылки. Включаем?

[iprst]

Мы как-то с вами обсуждали короткую ссылку на контекст, что она будет основным доказательством в баталиях, вот такие ссылки сейчас не надо создавать, но такого функционал еще и нет, я его не написал.

Ага, вот тут он у меня и зашёл — перепутал проектируемую идею с текущей реализацией и функционалом контекста. Сомнамбулизм!

Чисто с управленческой точки надо включать ссылки. Включаем?

Да, конечно включаем. Изначально зря отключены, имелся в виду контекст и короткая ссылка на него, а у нас этих сущностей пока нет и отключать нечего.

судя по статистике, вечера народ без коротких ссылок даже ленится вбивать поисковые запросы в строку, переходят, смотрят, а вбить «галичина 22 июля» не все смогли

)))))) Возможно не понятно, что в поисковую строку нужно что-то вбивать.

[audetv]

Готово, включил ссылки

[iprst]

Готово, включил ссылки

Сразу воспользовался. Игоревич в теме по делу дал предположение, хорошая ОС. Как раз про «галичину 22 июля».

[iprst]

Нужно будет разместить ссылку на военно-исторический поиск в меню сайта.

[audetv]

Нужно будет разместить ссылку на военно-исторический поиск в меню сайта.

Надо придумать сокращенное наименование в верхнее меню, может быть одно слово — «Поиск»
Еще варианты, но все не нравится, не знаю: ВИ Поиск - вообще не понятно, История Поиск, Исторический поиск. Может как то про хронологическому приоритету? Или просто так и написать: Поиск по военно-исторической библиотеке, пока так и напишу.

[iprst]

Надо придумать сокращенное наименование в верхнее меню, может быть одно слово — «Поиск» Еще варианты, но все не нравится, не знаю: ВИ Поиск - вообще не понятно, История Поиск, Исторический поиск. Может как то про хронологическому приоритету? Или просто так и написать: Поиск по военно-исторической библиотеке, пока так и напишу.

Текущий вариант действительно нормальный, но когда кончится место и нужно будет сокращать, можно попробовать заменить на «военная история».

[iprst]

Может быть в библиотеке прятать все меню наверху при прокрутке вниз, и отображать их только после прокрутки на 2-3 шага обратно? Сейчас прячутся крошки батона, но при наличии объёмного текста имеет смысл прятать и основное меню, и строку поиска. Мнения?

[iprst]

Что касается коротких ссылок на контекст.

Возможно при сбросе страницы контекста в короткую ссылку, в таблице сохранять текст страницы, пожатый каким-нибудь Bzip? Типа как docx жмёт и многие табличные фреймворки — в принципе экономия получается приблизительно в 3.5 раза, индексировать эти данные в мантикоре не требуется, поэтому трату ресурсов можно свести к минимуму. Но это зависит от популярности опции, с другой стороны, если такой метод начнёт жать ресурсы, всегда можно перевести хранимое в термины той схемы, которая к тому времени уже будет собрана для коротких ссылок контекста, например по id параграфов.

[iprst]

Если поискать 777, то на первой странице выдачи найдётся параграф по-видимому содержащий какие-то табличные теги, поскольку с этого момента все параграфы далее выглядят как узкие столбцы:

При этом страницы контекста для этих параграфов никаких проблем не показывают, текст нормально сформирован. Не понятно, откуда набегает ошибка, но попадается она не в первый раз.

[audetv]

Понятно, посмотрю, пока не знаю, что это, выглядит так, как будто верстка ломается.

[audetv]

Может быть в библиотеке прятать все меню наверху при прокрутке вниз, и отображать их только после прокрутки на 2-3 шага обратно? Сейчас прячутся крошки батона, но при наличии объёмного текста имеет смысл прятать и основное меню, и строку поиска. Мнения?

Пока вызвало отрицательную реакцию, осмыслил, похоже связано с тем, что я сходу не знаю как это решить нормально, т.е. эта вроде бы легкая задача тянет у меня в голове такие цепочки, что я под ними сгибаюсь, как думать начинаю.., Происходит выход на уровень javascript, на сторону клиента - пользователя, (это на самом деле и есть фронтенд, то что загружено у клиента (пользователя) в браузере), а эта сфера для меня хоть и не новая, но в ней я имею мало опыта и навыка, написания различных сложных плагинов. Обычно задачи звучат просто, а вырастают в недели работы над фичей с одной кнопкой. В js надо предусматривать кучу вариантов и особенностей работы с интерфейсом браузера, это как бы другая часть разработки, другой уровень абстракций, я обычно нахожусь где-то на стороне сервера, там в глубине ближе к БД, к железу и прыгать с уровня на уровень, бывает тяжело, точно затратно для мозга, вот и реакция.

Cтарюсь делать так, если есть что-то готовое, то лучше это взять и попробовать прикрутить, не факт что это будет быстро, но точно быстрее, чем самому изобретать. Вспоминаю, диаграмму график СВОДД, я не одну неделю погружался в эту библиотеку, чтобы ее нормально прикрутить сюда )

С реакцией разобрались) Вопрос, сейчас на десктопе, я так понимаю, хватает места для просмотра, я имею ввиду, что меню сверху и строка поиска не мешают просмотру контента?

В мобильном версии и на планшете, это меню в таком виде вообще не отображается, видна только плашка со звездой и кнопка меню, по нажатии которой уже и открывается меню сайта. Я пользуюсь, не 100% доволен, но особого неудобства не испытывал.

Details


Вот при просмотре в мобильном у меня иногда возникала мысль убрать верхнюю плашку со звездой и оставить только поисковую строку, но тут же сразу момент вылезает с кнопкой меню, это 3 точки горизонтальных, места они занимают, как кнопка настройки поиска, если это смещать влево, то сама строка поиска уже становиться меньше. Возможно надо тогда избавится от большой кнопки найти, и сделать ее, например тоже условно квадратной с изображением значка поиска — например, лупы. Или само меню переместить вниз к pagination, up/down, тогда наверху сформируется блок для поиска и управление поиском, в внизу сформировать, надо еще сделать блок, пролистывание, движение по листу и меню. (Этот вариант мне больше нравится).

И по хорошему сделать это надо так, чтобы в итоге меню и поиск нормально работали и выглядели и на деск топе и на мобилке, То решение, которое сейчас на сайте, я брал в bootstrap как шаблон для меню, и не изобретал своего модуля.

В общем это плавно приводит к тому, что надо переделать интерфейс программы. Вот возможно в эту сторону и надо нам будет посмотреть? Еще чуть далее, через пару - тройку сервисов будет понятно, что с этим делать, как располагать элементы, точнее, какие элементы интерфейса вообще получаются.

Начиналось то с: поиск, статистика, обсуждение, вопросы.

Кстати возможно (технически точно возможно, это быстро, и я умею) надо будет сгруппировать пункты ФКТ в один пункт меню. Чтобы он был выпадающим, как смена темы, и там открывались остальные пункты, не уверен пока в этом. Если меню будет внизу, то пока не понятно, как оно будет отображаться на декстопе, скорее всего такая же кнопка будет меню внизу где то, внизу блок навигации и меню.

И все это еще раз плавно выводит меня к тому, что я давно хочу сделать и видимо мы придем к этому рано или поздно и я сделаю. Надо написать фронтенд на js, на reactjs и вот тогда будет раздолье работать с интерфейсом, так уже гораздо проще подключать библиотеки и менять вид приложения. В reactjs у меня меньше опыта, но он есть, делать на Reactjs программу совсем с нуля, я бы не стал, так как долго буду делать выпуск, а вот если уже повторить то, что сделано и улучшить, самое то. И технически к этому почти все готово. Кроме авторизации, которую надо обсудить.

Еще мне кажется, что это будет правильнее с точки зрения создания приложения — библиотеки, которую можно установить на локальном компьютере, в которое пользователь может подключать свои БД или подключаться к нашей бд, или пользоваться облачной версией в веб и ничего не ставить.

Но все это время, а столько хочется сделать! Надо будет в итоге переписать бэкенд приложения и фронтенд, но мы уже скоро будем иметь рабочую версию, и надо не с нуля все писать. Вот такие мысли от такого простого предложения вылезают.

Пока не знаю, что с этим делать, дал ли ответ на вопросы, но мнение точно высказал) Пока не охота залеаать в интерфейс. Так то да я подумаю в свободном режиме, возможно придет решение или наткнусь на какое либо в процессе, и можно будет легко прикрутить ваш вариант. Позже попробую поиграть, как будет надо отвлечься. Но пока не хочется на это отвлекаться. В мыслях, что надо переделать интерфейс программы и frontend backend, и думаю к концу тестирования через месяц два выйдем у этому.

[audetv]

Возможно при сбросе страницы контекста в короткую ссылку, в таблице сохранять текст страницы, пожатый каким-нибудь Bzip? Типа как docx жмёт и многие табличные фреймворки — в принципе экономия получается приблизительно в 3.5 раза, индексировать эти данные в мантикоре не требуется, поэтому трату ресурсов можно свести к минимуму. Но это зависит от популярности опции, с другой стороны, если такой метод начнёт жать ресурсы, всегда можно перевести хранимое в термины той схемы, которая к тому времени уже будет собрана для коротких ссылок контекста, например по id параграфов.

Это если мы используем вариант страница контекста для всех поисков на отдельном поддомене, как отдельный сервис.

Как вариант да, но если в этом сервере будет сотни, тысячи или десятки тысяч ссылок, это все вообще не стоить того))

Если много ссылок, да. Но если сервис будет популярен, да это и без если наверное имеет смысл, то только что опубликованная ссылка на форуме чаше просматривается, чем старые ссылки. Тогда часть текстов можно складывать в cache, даже самый простой пример снизит нагрузку: дернули ссылку, сервер распаковал, создал страницу и положили в кэш, например, на 30 минут, потому как готовый текст выдать пользователю нужно меньше ресурсов, чем распаковать и создать страницу при каждом запросе. Вариант хороший, в копилку.

[audetv]

Может быть в библиотеке прятать все меню наверху при прокрутке вниз, и отображать их только после прокрутки на 2-3 шага обратно?

В итоге, я вижу так:

Наверху строка с поиском — блок с поиском без каких либо дополнительных меню, строку с поиском можно скрывать при прокрутке вниз, но предлагаю еще подумать над этим, ведь у нас основная цель это поиск, с другой стороны, получаемая лента под запросом, сама может быть как отдельная книга, и результаты этой книги надо почитать, а не просто прокрутить. Так что возможно не исключаю, что скрывать строку с поиском будет лучше. Можно вообще эту опцию в итоге вынести в настройки и пользователь сам решит скрывать панель с поиском или нет, хотя судя по коротким ссылкам пока пользователи в основном переходят по ссылке и потребляют, что им предлагают, сами не ищут в массе, так что и настройкой пользоваться не будут.

Внизу блок управления и кнопка меню, при нажатии открывается отдельная страница меню, или слой меню на деск топе, и там происходит работа с сайтом. Управления, переключение страниц, клавиши вверх вниз. Смесь читалки с сайтом? читалка получается))) Но хочется где-нибудь ставить звезду, пока не знаю где.

[iprst]

сходу не знаю как это решить нормально, т.е. эта вроде бы легкая задача тянет у меня в голове такие цепочки, что я под ними сгибаюсь, как думать начинаю..,

Это не срочная задача, а цель для обдумывания в принципе. Можно сформулировать её так — меню и строка поиска занимают место в таких сценариях, где это место будет полезнее отдать информации. Например как это сделано на странице контекста.

Вопрос, сейчас на десктопе, я так понимаю, хватает места для просмотра, я имею ввиду, что меню сверху и строка поиска не мешают просмотру контента?

В мобильном версии и на планшете, это меню в таком виде вообще не отображается, видна только плашка со звездой и кнопка меню, по нажатии которой уже и открывается меню сайта.

Тип устройства влияет только на процент экранного места, но не на суть фактора среды. По сути в режиме чтения меню отнимают полезную площадь экрана. Вопрос по сути в том, нужно ли чтобы это происходило, или нет. То, что с этим можно жить понятно.

избавится от большой кнопки найти, и сделать ее, например тоже условно квадратной с изображением значка поиска — например, лупы (…) само меню переместить вниз к pagination, up/down, тогда наверху сформируется блок для поиска и управление поиском, в внизу сформировать, надо еще сделать блок, пролистывание, движение по листу и меню

В мобильной версии так сделать будет логично.

В общем это плавно приводит к тому, что надо переделать интерфейс программы. Вот возможно в эту сторону и надо нам будет посмотреть? Еще чуть далее, через пару - тройку сервисов будет понятно, что с этим делать, как располагать элементы, точнее, какие элементы интерфейса вообще получаются.

Да. Сейчас просто собираем наблюдения. Ничего не делаем с ними, просто собираем и пусть они прорастают.

Кстати возможно (технически точно возможно, это быстро, и я умею) надо будет сгруппировать пункты ФКТ в один пункт меню.

Возможно убрать вообще пункты «поиск», «коб», «фкт», «военно-историческая библиотека» из меню, а сделать их опциями выбора в едином поисковике, типа «искать в…» или что-то подобное.

И все это еще раз плавно выводит меня к тому, что я давно хочу сделать и видимо мы придем к этому рано или поздно и я сделаю. Надо написать фронтенд на js, на reactjs и вот тогда будет раздолье работать с интерфейсом, так уже гораздо проще подключать библиотеки и менять вид приложения. В reactjs у меня меньше опыта, но он есть, делать на Reactjs программу совсем с нуля, я бы не стал, так как долго буду делать выпуск, а вот если уже повторить то, что сделано и улучшить, самое то. И технически к этому почти все готово.

Пока собираются наблюдения можно раздумывать над решениями. Всё это не критично на текущий момент. Возможно кто-то начнёт пользоваться и придёт сюда помогать с программированием.

[iprst]

если сервис будет популярен, да это и без если наверное имеет смысл, то только что опубликованная ссылка на форуме чаше просматривается, чем старые ссылки

Это логично, но кажется решается другая проблема, типа независимость наследования реальных коротких ссылок от факторов переезда и разработки — пока идёт время изменений, небольшая табличка с сохранённым текстом для выдачи в коротких ссылках на контекст не станет слишком большой за время изменений и нахождения устойчивой схемы работы сервиса. А когда схема будет оформлена и реализована, короткие ссылки уже будут формироваться согласно этой схеме, а сохранившиеся в переходной табличке данные можно будет распарсить в номера id соответствующих параграфов внутри этой сформированной системы. Типа сейчас храним текст параграфов А, Б, В, а потом окажется что это будут параграфы x1. x2. x3. x4. x5. x6. x7. x8. x9 и так далее. Не важно что их число и id могут измениться. По сути параграфы хранятся в переходной таблице только для того, чтобы потом безболезненно перейти от АБВ к х1-9.

[iprst]

Наверху строка с поиском — блок с поиском без каких либо дополнительных меню, строку с поиском можно скрывать при прокрутке вниз, но предлагаю еще подумать над этим, ведь у нас основная цель это поиск, с другой стороны, получаемая лента под запросом, сама может быть как отдельная книга, и результаты этой книги надо почитать, а не просто прокрутить.

Я тоже думаю что пункты меню, управляющие функционалом поисковика, имеет смысл из меню убрать, а вместо этого сделать их опциями поиска в той или иной форме. Таким образом само меню в итоге избавившись от «поиска» становится вопросами, обсуждением и статистикой. Статистику можно вообще убрать в иконку и сбросить в футер страницы, это вспомогательная функция. Таким образом остаётся только обсуждение на ФКТ и вопросы на ФКТ. Тут уже можно думать, какое место эти сущности занимают в структуре данных. Можно проецировать в будущее, и тд.

судя по коротким ссылкам пока пользователи в основном переходят по ссылке и потребляют, что им предлагают, сами не ищут в массе, так что и настройкой пользоваться не будут

Очень маленькая выборка — пока что прошло слишком мало времени. Произвол это штука, которая нарабатывается со временем, сначала должна набраться критическая масса «просто просмотров». Именно поэтому эту тему сейчас я рассматриваю чисто как сброс наблюдений, которые только потом будут собираться — пусть они сначала обработаются в бессознательном режиме, пронаблюдаются ещё, создастся стереотип узнавания. То есть сейчас здесь мы сбрасываем ПФУ-1 и ПФУ-2. Можно к дальнейшим пунктам пока даже не переходить. Пусть обработаются в режиме «количество переходит в качество». А вместо высокочастотных решений по поисковику можно заняться более глобальной схемой. Поисковик нормально работает, всё что нужно он делает, а после сбора ОС и наблюдений к нему будут добавлены улучшения.

[audetv]

Это логично, но кажется решается другая проблема, типа независимость наследования реальных коротких ссылок от факторов переезда и разработки — пока идёт время изменений, небольшая табличка с сохранённым текстом для выдачи в коротких ссылках на контекст не станет слишком большой за время изменений и нахождения устойчивой схемы работы сервиса. А когда схема будет оформлена и реализована, короткие ссылки уже будут формироваться согласно этой схеме, а сохранившиеся в переходной табличке данные можно будет распарсить в номера id соответствующих параграфов внутри этой сформированной системы. Типа сейчас храним текст параграфов А, Б, В, а потом окажется что это будут параграфы x1. x2. x3. x4. x5. x6. x7. x8. x9 и так далее. Не важно что их число и id могут измениться. По сути параграфы хранятся в переходной таблице только для того, чтобы потом безболезненно перейти от АБВ к х1-9.

Я сейчас вспоминаю, что ранее мы с вами обсуждали эту задачу и в ходе обсуждения были сформированы такие мысли,
я не процитирую, а по памяти, что вспомнил.

Делаем ссылку на контекст и контекст формируется обычным образом из текущих идентификаторов, из центрального uuid и соседних integer id.

В тот момент, когда необходимо переиндексировать БД какого-либо из поисков, можно запускать процедуру сохранения этих параграфов в БД контекста в виде сброса центрального параграфа (можно и полный текст сбрасывать, обсудить) или полного текста параграфов, для последующего восстановления, а в случае если автоматического восстановление не удастся (по каким то причинам), то эти параграфы могут далее храниться в виде содержания полного текста в базе данных сервиса контекста и оттуда в этом виде и отдаваться до завершения процедуры нахождения нужного параграфа в новой БД.

Я думаю, я переформулировал мысль и так не звучало, но мы с вами обсуждали что-то в этом направлении, надо будет найти это в обсуждении, почитаю ещё.

Далее если приложить уже продолжение сегодняшней мысли: текст можно хранить в сжатом виде для экономии ресурсов диска, но при установлении постоянного обращения к такому сжатому тексту, при возникновении проблем с производительностью, можно применить схему кэширования для популярных параграфов контекста.

[iprst]

когда необходимо переиндексировать БД какого-либо из поисков, можно запускать процедуру сохранения этих параграфов в БД контекста в виде сброса центрального параграфа (можно и полный текст сбрасывать, обсудить) или полного текста параграфов, для последующего восстановления, а в случае если автоматического восстановление не удастся (по каким то причинам), то эти параграфы могут далее храниться в виде содержания полного текста в базе данных сервиса контекста и оттуда в этом виде и отдаваться до завершения процедуры нахождения нужного параграфа в новой БД.

Да, собственно это продолжение или ответвление этой мысли и было — чтобы не изобретать механизм пересчёта идентификаторов между базами, можно хранить сам текст, а потом в новой базе поиском установить все идентификаторы этого текста. Чтобы текст не тянул место, можно хранить его в пожатом виде.

текст можно хранить в сжатом виде для экономии ресурсов диска, но при установлении постоянного обращения к такому сжатому тексту, при возникновении проблем с производительностью, можно применить схему кэширования для популярных параграфов контекста

А это уже продолжение этой мысли, всё так.

[audetv]

По поводу коротких ссылок для контекста, мы обсуждали и у меня сложилось некоторое непонимание.

Есть ли смысл делать для контекста отдельно короткие ссылки, я имею ввиду, повторять механизм коротких ссылок именно для поддомена quote? типа quote.svodd.ru\ShOrTlInK Т.е. продублировать сервис коротких ссылок? Мне кажется в этом нет смысла. Я пока не вижу, могу ошибаться.

Мы можем использовать обычные короткие ссылки svodd.ru\ShOrTlInK такие, как мы и подключили на прошлой неделе, и эта ссылка уже будет вести на страницу контекста, видаquote.svodd.ru\<uuid>

Т.е. страницы контекста будут иметь адрес quote.svodd.ru\b7d04f16-2fa7-11ee-be56-0242ac120002 Короткая ссылка: svodd.ru\ShOrTlInK Приводит на страницу: quote.svodd.ru\b7d04f16-2fa7-11ee-be56-0242ac120002

[iprst]

Есть ли смысл делать для контекста отдельно короткие ссылки, я имею ввиду, повторять механизм коротких ссылок именно для поддомена quote? типа quote.svodd.ru\ShOrTlInK Т.е. продублировать сервис коротких ссылок?

Нет, второй сервис коротких ссылок конечно не нужен. Нужен сервис цитирования, поддомен quote который пока только обсуждался, но нетронут в реальности, то есть сейчас у нас в большой библиотеке нельзя поделиться контекстом, ссылка сейчас это чисто заглушка для адресной строки. Когда система с uuid параграфами и их отбором будет готова, и ссылку можно будет генерировать правильным образом, сокращать её можно будет тем же сервисом сокращений, который у нас уже существует.

[iprst]

технически к этому почти все готово. Кроме авторизации, которую надо обсудить

На всякий:

МОСКВА, 31 июля. /ТАСС/. Президент РФ Владимир Путин подписал закон, который запрещает регистрацию на отечественных сайтах с помощью иностранной электронной почты. Документ опубликован на официальном портале правовой информации. Согласно закону, с 1 декабря на российских сайтах, предполагающих регистрацию и аутентификацию пользователя, нельзя будет зарегистрироваться через иностранную почту или аккаунты, подключенные через иностранные сервисы, например Google или Apple ID.

[iprst]

Из наблюдений за функционалом ВИБ.

Нужно реализовать метод помечания и сохранения в личном кабинете подходящих под тот или иной запрос параграфов, притом такой, который позволял бы организовывать избранные параграфы в группы, возможно персональное и/или публичное облако тегов, возможно группы в отметках или любой подобный метод. Пользовательский кейс можно собрать очень интересный — представьте, что вы искали какую-то информацию по обширной теме, и использовали несколько запросов, листали кучу страниц, и вот набралось 40-50 цитат. Их можно с помощью отметок объединить в ленту, и делиться ею с помощью коротких ссылок, или не делиться, а просто для своей работы иметь под рукой что-то вроде реферата из цитат. При этом можно ленту редактировать, пополнять новым и удалять неудачные записи. Да, можно конечно копировать текст цитаты и источник в отдельный документ, но тут функционал именно для упрощения этого отбора, чтобы не отвлекаться на технические паузы, вместо этого продолжать поиск и разметку. А результаты можно смотреть сразу в личном кабинете в соседнем окне браузера.

[audetv]

технически к этому почти все готово. Кроме авторизации, которую надо обсудить

На всякий:

МОСКВА, 31 июля. /ТАСС/. Президент РФ Владимир Путин подписал закон, который запрещает регистрацию на отечественных сайтах с помощью иностранной электронной почты. Документ опубликован на официальном портале правовой информации. Согласно закону, с 1 декабря на российских сайтах, предполагающих регистрацию и аутентификацию пользователя, нельзя будет зарегистрироваться через иностранную почту или аккаунты, подключенные через иностранные сервисы, например Google или Apple ID.

Ну вот, и немного в плюс понимания к будущей регистрации на наших сервисах. Чувствую тенденцию к ограничению в будущем собственных сервисов авторизации и аутентификации, или вообще эта деятельность в перечень лицензированной перейдет. Сделать свой сервис авторизации регистрации, с одной стороны просто, но возможно вскоре будет лучше и проще пользоваться сервисами гигантов ВК, Яндекс или Госуслуги и не заморачиваться контролем у себя. https://yandex.ru/dev/id/doc/ru/how-to https://dev.vk.com/ru/api/oauth-parameters https://partners.gosuslugi.ru/catalog/esia

Outh 2 Для пользователя — это просто, выглядит как войти с помощью учетной записи ВК, Яндекс, Госуслуг. И мне кажется это даже легче для пользователя, чем везде вводить свои данные регистрироваться, запоминать пароли))) Для владельца сайта в общем то тоже всё просто, он получает после регистрации данные пользователя, которые пользователь разрешил передать при регистрации сервису, email, tel имя и прочее. Но сама процедура авторизации и аутентификации проходит на серверах сервисов, владелец получает только сформированный токен от этих сервисов и подтверждение, что такой то пользователь это id такой то. Можно даже данные о пользователях не хранить, а хранить только их ИД и роль в системе. Т.е. для аутентификации достаточно того, что ид пользователя будет указан в токене и там же может быть указана роль пользователя, сам токен зашифрован и подписан чем-нибудь типа sha256 или другими алгоритмами. И тогда даже закон о перс данных не нарушить, даже если захотеть, так как хранение ИД пользователя и его роли в системе более чем обезличено, но этого ИД хватит для аутентификации. Управлять аудиторией твоего сайта также сможет владелец сервиса гиганта. За все надо платить.

Oauth2 схема давно распространена, особенно гугл авторизация. Она бесплатная, почти (вроде, до нескольких тысяч пользователей) и разработчиков на многих курсах и обучениях, книгах на нее подсаживают, просто пишешь пару строк кода и имеешь готовый модуль на сайте.

Будет и хороший бизнес. Нормальный закон. И в целом для такого шага есть веские причины, интересно посмотреть будет как скоро с крупных ресурсов начнут скулить различные псины.

И еще бы ВК - mail.ru побороли бы своих как бы бесконтрольно выпускаемых ботов… Посмотрим.

[iprst]

Будет и хороший бизнес. Нормальный закон. И в целом для такого шага есть веские причины, интересно посмотреть будет как скоро с крупных ресурсов начнут скулить различные псины.

Уже вовсю. На хабре например, с первых комментариев слёзки крокодильчиков «ай я не разобрался сложный закон», «ничего они тоже» и плюсики, плюсики. В общем всё по обычным рельсам Бронштейна. Про бизнес даже не подумалось ребятам, хотя это разумеется очевидное следствие — просто так чтоли крупные ТНК сделали «бесплатные*» сервисы авторизации.

Для пользователя — это просто, выглядит как войти с помощью учетной записи ВК, Яндекс, Госуслуг. И мне кажется это даже легче для пользователя, чем везде вводить свои данные регистрироваться, запоминать пароли)))

Конечно. Что хорошо, комментарии станут попроще, без интересной пены, когда интернет по паспорту )))

И еще бы ВК - mail.ru побороли бы своих как бы бесконтрольно выпускаемых ботов…

Постепенно по шагам решаются вопросы. Так что всё будет.

[iprst]

Наблюдения за опытом использования.

По текущией длине параграфа — её смело можно сократить в два раза. Сейчас слишком длинные параграфы. Недостающую информацию можно брать со страницы контекста.

По датам — в поиске отсутствует удобный механизм обработки дат. Если задать поиском «22 августа», то в любом режиме будет слишком много результатов. Но если попытаться уточнить результаты дополнительным словом в запросе, например «Япония», тогда нельзя будет выбрать режим «по соответствию фразе», поскольку поиск будет проводиться по фразе «22 августа Япония», что не является тем запросом, который вы ищете (с) — дата должна быть «склеена» по логике поиска точного соответствия фразе, а дополнительное слово должно искаться по логике «найти в результатах поиска по дате».

[audetv]

По текущией длине параграфа — её смело можно сократить в два раза. Сейчас слишком длинные параграфы. Недостающую информацию можно брать со страницы контекста.

Это мы можем сделать, у нас уже для этого реализован метод. Мне в начале, когда запустили, параграфы казались гигантскими, я ещё об этом писал, что надо привыкнуть, сейчас привык уже. Теперь некоторые параграфы в поиске коб, которые без сносок, кажутся маленькими… Но думаю да, можно сократить. Метод есть.

По датам — в поиске отсутствует удобный механизм обработки дат. Если задать поиском «22 августа», то в любом режиме будет слишком много результатов. Но если попытаться уточнить результаты дополнительным словом в запросе, например «Япония», тогда нельзя будет выбрать режим «по соответствию фразе», поскольку поиск будет проводиться по фразе «22 августа Япония», что не является тем запросом, который вы ищете (с) — дата должна быть «склеена» по логике поиска точного соответствия фразе, а дополнительное слово должно искаться по логике «найти в результатах поиска по дат

По датам, понятно, надо подумать, закинул в голову, так то эту логику надо еще реализовать т.к. этого в коробке мантикоры нет. Хотя может быть и есть, надо посмотреть в sql клиенте, с ним можно делать более сложные запросы, это по аналогии как я выкладывал сервис поиска похожих текстов tf/idf , там запросы в бд производятся через синтаксис sql и похоже можно делать разные сложные вещи). В общем буду думать, как это можно реализовать.

[iprst]

Хотя может быть и есть, надо посмотреть в sql клиенте, с ним можно делать более сложные запросы, это по аналогии как я выкладывал сервис поиска похожих текстов tf/idf , там запросы в бд производятся через синтаксис sql и похоже можно делать разные сложные вещи). В общем буду думать, как это можно реализовать.

Да, очень похоже на сложные запросы определённой формы. Пусть варится вопрос, это пока просто наблюдение получилось, несколько раз столкнулся и сформировался фактор среды.

[iprst]

А есть ли в мантикоре метод, который показывает статистику по всем размеченным словам в базе?