Новая эра личных баз знаний
14.01.2022
|
velkin |
Кто не успел, тот опоздал
— Почему вы опоздали на работу?
— Потому что поздно вышел из дома.
— А почему вы не вышли раньше?
— Уже поздно было выходить раньше.
Анекдот как раз про личную базу знаний. Говорят, что учиться никогда не поздно, но чем позже заведена личная база знаний, тем меньше пользы от учёбы.
Личные знания людей прежде всего хранятся и обрабатываются в головах в нейронной сети во вполне физическом виде, назову это внутренним носителем. Но в большинстве случаев этого недостаточно и нужна дополнительная запись на внешние носители.
Виды носителей знаний
1) Внутренний (мозг).
2) Внешний (книга, электроника).
Личная база знаний одного человека может стать внешним источником знаний других людей, наглядный пример книги или статьи. Однако подобный внешний источник не меняется или меняется в зависимости от других людей.
Это не позволяет изменить данные самостоятельно, а следовательно все выводы остаются лишь в сознании человека, то есть во внутреннем, а не внешнем носителе. Такая ситуация приводит к забыванию накопленных знаний и долгому и сложному последующему восстановлению с помощью чужих внешних носителей знаний.
Так же не даёт передавать собственные знания другим людям. И если последнее зачастую не имеет большого значения, то отсутствие записи на внешнем носителе уже переработанных личных знаний является огромной проблемой.
Решение же крайне простое, начать вести личную базу знаний.
Виды внешних носителей
Существует огромное количество внешних носителей, начиная от древних и заканчивая самыми современными. Но так ли они хороши как их малюют.
Бумажный носитель
Использование бумажных листов старый и довольно простой способ записи. До сих пор используется в обучающих учреждениях.
Внешние носители
1) Бумажная тетрадь.
2) Бумажный чертёж.
3) Бумажный блокнот.
Инструменты записи
1) Карандаш.
2) Ручка.
3) Кисть.
Вспомогательные инструменты
1) Линейка.
2) Угольник.
3) Транспортир.
Преимущества
1) Легко начать вести.
2) Нет ограничений по формату.
Недостатки
1) Сложно изменять написанное.
2) Большой физический объём и вес носителя.
3) Нет возможности полнотекстового поиска.
Компьютерный файл
Уже не новый, но постоянно совершенствуемый способ записи знаний. Современный носитель вмещающий огромную библиотеку книг может быть столь мал, что его можно случайно потерять.
Внешние носители
1) Компьютер (десктоп, ноутбук, сервер, смартфон).
2) Диски (флешки, ssd, hdd).
Разделение в данном случае было по носителю с обработчиком информации и без. Это подобно бумаге, даже если она и есть, без инструментов записи ничего не запишешь.
Преимущества
1) Позволяет сохранять огромные объёмы знаний.
2) Вес и объём носителя может быть предельно снижен.
3) Есть возможности полнотекстового поиска
Недостатки
1) Невозможно управлять информацией без обработчика.
2) Есть ограничения по форматам записи.
Форматы записи знаний
Форматы записи и носители знаний это не одно и тоже. Хотя в каждом виде носителя знаний записи происходят по-разному, формат это не только то, что записываешь, но и что потом видишь.
Оформленный текст
Весь текст я буду считать оформленным, начиная от простого и заканчивая сложными форматами в которые могут быть внедрены изображения, видео и звук.
Ключевая особенность текста это параграфы, списки, различный формат букв и многое другое. В минимально варианте оформление это просто отступы и перенос строк.
Чертёж
Чертёж в отличие от текста позволяет создать контуры реальных объектов в ином масштабе. Хотя текст так же может на нём присутствовать. В русском языке чертёж характеризуется ключевым словом черта, что обозначает основной используемый элемент, тогда как текст вторичен.
Ключевое различие между чертежом и текстом в видах мышления. Текст как правило состоит из символов собирающихся в слова, которые в свою очередь собираются в предложения, а те уже в параграфы, главы и книги. Но при этом невозможно произвести связь между текстом и образами реального мира, если не знать, что обозначают слова. Тогда как чертёж может наглядно представить некий предмет или даже действие без использования словесных обозначений.
Карта разума
В общем случае карты разума просто иначе нарисованные древовидные списки, но есть и более сложные варианты. Хотя кто-то считает карты разума революцией, но после изучения науки логики я бы сказал, что ничего нового этот способ не несёт, а многое упускает.
Карты разума можно считать частным случаем диаграмм и схем. Я выделил их отдельно потому, что некоторые действительно пытаются вести личную базу знаний подобным образом. Хотя на мой взгляд сосредотачиваться на таком формате не эффективно или наверно надо сказать это лучше, чем ничего, но хуже, чем что-то.
Диаграммы и схемы
Вопрос в том, что понимать под диаграммами. Обычно под этим принято понимать различные графики, круговые диаграммы и прочее. Но в некоторых случаях под этим понимают форматы схем, вроде ER-диаграммы, UML.
Числовые диаграммы
Схематические диаграммы
Неудачные решения
И вот вы наконец решились завести личную базу знаний. Давайте рассмотрим возможные проблемы, с которыми придётся столкнуться
Бумажная тетрадь
Тетрадь слишком маленькая для ведения чего-то серьёзного. А по мере роста бумажной массы станет сложнее что-то найти и упорядочить. Огромная проблема с хранением макулатуры. Так же невозможность взять все свои наработки с собой. Высокая сложность копирования, нужен сканер или фотокамера хотя бы в смартфоне.
Таким образом бумажные носители не слишком подходят для большой личной базы знаний. В каком-то роде это пережиток прошлого от которого пора отказаться. По крайне мере лично я не помню где и что я записывал, а поскольку лежит это тоже непонятно где, даже проследить историю не удастся. Да и выглядят ручные записи не очень хорошо или лучше сказать плохо.
Персональный информационный менеджер
Персональный информационный менеджер или ПИМ (англ. PIM) это подвид персонального органайзера только на компьютере. Это могут быть такие программы как Zim и прочие, список огромен.
Способы записи
На пимах в основном бывают два вида записи знаний.
1) Файлы в особом формате.
2) Записи в базе данных.
Проблемы с базами данных
С одной стороны в базе данных всё может храниться во дном месте. Но с другой стороны у баз данных есть неожиданные сюрпризы.
1) Такие как порча базы данных, а значит потеря всех данных.
2) Или по мере заполнения базы данных замедление работы вплоть до жутких тормозов.
Проблемы с файлами
С файлами тоже возникают проблемы.
1) Конечно же это поиск по файлам даже имея автоматическое индексирование.
2) С файлами часто нужен специализированный редактор, который может оказаться тормознутым.
С базами данных специализированный редактор тоже нужен, но там понятно для чего, то есть для работы с базой данных, а здесь нет.
Генератор документации
Другой случай это различные генераторы документации из других форматов. Как правило генерация происходит в html, хотя могут быть и другие форматы. Гораздо реже встречаются редакторы, которые позволяют просматривать набранное в реальном времени. К тому же скорее всего они тоже сначала генерируют html, а потом уже показывают содержимое.
К ним относятся языки разметки Markdown, AsciiDoc, тот же Doxygen и многие другие. Пользователи того же GitHub очень радуются "Markdown" не подозревая, что на русский это переводится как "Разметка дауна".
Но проблема как раз не в этом, а в крайней непродуманности иных языков разметок отличных от html. Вместо чего-то более простого, чем html получаем что-то странное и дублирующее существующий функционал. А потом ещё попытка превратить всё это в сайт превращается в генерацию html документации. Спрашивается зачем столько телодвижений, когда можно было сразу писать документацию в html.
Лучшие практики
И вот мы подходим к лучшим практиками известным мне на данный момент. По сути чуть ли не вся документация в GNU/Linux сделана по этому методу, но у меня есть несколько важных отличий. Более того, я пришёл к этой форме записи сначала перепробовав иные варианты и потом уже понял, что лишь повторил то, что и так давно существовало.
Предварительная подготовка
1) Создайте папку с личной базой знаний, можете назвать как угодно. Но давайте чисто для примера будем её звать "doc".
2) Внутри папки создайте файл.
index.html
3) В этой же папке создайте тематические файлы того, что вас интересует.
cpp.html
git.html
lua.html
qt5.html
4) Можно ещё создать файл стилей.
style.css
5) А так же файл иконки.
favicon.ico
А теперь вопросы.
Сколько занимает обычная книга в html формате?
Бывает по-разному, пусть будет 1 мегабайт. А ведь 1 мегабайт это довольно увесистый том, который и за один день не прочитаешь. Не говоря уже о том, что там может быть не художественная книга, а высококонцентрированная научная информация без балабольства.
Но даже если книга или серия книг занимает 10 мегабайт, это вовсе не станет такой уж большой проблемой для браузера, если не увлекаться ненормальной вёрсткой. Использование простейших html тегов без лишних вложений и атрибутов ключ к успеху.
Сколько книг вы сможете написать за всю жизнь?
Очевидно не так много. Да, можно взяться за разные темы. Писать микростатьи вроде этой, вместо того, чтобы написать книгу. Но даже если писать несколько книг в год за всю жизнь выйдет не много.
Десять или сто книг это ни о чём с точки зрения хранения их в одной папке. По моим опытам нужно накопить хотя бы десять тысяч файлов в одной папке, чтобы это хоть как-то мешало.
Быстро ли браузер отображает книгу в html формате?
Да, очень быстро. А на вопрос, почему тогда на сайтах одна книга поделена на маленькие странички ответ довольно прост. Сервер вынужден обслуживать множество клиентов. Клиент запросив информацию даже не факт, что будет её использовать, а вот обновлять страницу может сколько угодно.
Таким образом с локального диска наиболее приемлемый вариант чтение всей книги, потому что это попросту удобно, в том числе и поиск по тексту. А при обслуживании множества клиентов это не выгодно так как тратит лишние ресурсы сервера.
Основная идея
Главная идея состоит в том, чтобы разделить огромные пласты информации на темы в виде html страниц размером с книгу, а для перемещения по ним использовать индексную страницу index.html. Внутри страниц можно ориентироваться пользуясь обычным текстовым поиском.
Может кто-то скажет, да ты чёртов "гений", придумал самый обычный сайт, который не то, что школьник, детсадовец может написать. И это на самом деле хорошо, если с этим справится хотя бы школьник, ведь чем раньше начнёшь вести личную базу знаний, тем лучше.
А ещё нужно понимать, что браузеры вылизывают для сверх быстрой обработки html и css. Для какого ещё формата языка разметки будут такое делать. Обычно и не делают, плюс html можно открывать везде, на ноутбуке или смартфоне, и с любого места, с локального диска или того же личного сервера.
Отброшенные идеи
Складывать html страницы в разные папки
1) По ним слишком сложно перемещаться в файловой системе.
2) Пути ссылок получаются слишком сложными ("../../../").
Разбивать книжные html страницы на множество мелких статей
1) Нужно усложнять хранение в файловой системе или вместо 10 страниц написать 1000.
2) Нельзя просто взять и использовать текстовый поиск в редакторе по теме.
Детали реализации
index.html
1) В качестве отступов используется табуляция. Редактор kate мне её показывает, потому это удобно.
2) Заголовок может быть любым. В данном примере буду использовать слово "Документация".
3) Используется порезанный реальный пример оглавления. Хотя всё может измениться много раз.
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="utf-8">
<title>Документация</title>
<link rel="stylesheet" type="text/css" href="style.css">
<link rel="shortcut icon" type="image/ico" href="favicon.ico">
</head>
<body>
<h1>Документация</h1>
<h2>Программирование</h2>
<ul>
<li>
<h3>Языки</h3>
<ol>
<li>
Компилируемые
<ol>
<li><a id="toc-cpp" href="cpp.html">C++</a></li>
</ol>
</ol>
</li>
</ul>
</body>
</html>
cpp.html
1) По сути тоже самое, что и в предыдущем примере, только с заменой "Документация" на "Язык программирования C++".
2) Плюс обратная ссылка на ссылку на эту страницу в index.html.
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="utf-8">
<title>Язык программирования C++</title>
<link rel="stylesheet" type="text/css" href="style.css">
<link rel="shortcut icon" type="image/ico" href="favicon.ico">
</head>
<body>
<h1><a href="index.html#toc-cpp">Язык программирования C++</a></h1>
</body>
</html>
Что дальше
А дальше идут хитро сделанные оглавления, которые позволяют в пару кликов перемещаться по темам. Особое оформление изображений и прочее, прочее, прочее. Поскольку документации написано мало, и она ещё меняется, не буду приводить это в пример. Здесь главное заложенная мысль про то, что личную базу знаний можно создавать в виде сайта набранного вручную.
Эпилог
На этом пожалуй и закончим введение в личные базы знаний. И закончить я хочу с того же, с чего и начал. Кто не успел, тот опоздал. Лично я опоздал. Вопрос теперь в том нужно ли выходить на работу с опозданием или вообще не приходить. Ведь сотрудник, который опоздал ещё не так плох, как полный прогульщик.
14.01.2022 34 комментария |
В OneNote все леплю. Но заметил факт, пользуюсь потом этим крайне редко, иногда полистаю что там накопилось — "и зачем мне нужна была эта фигня!"
_>В OneNote все леплю. Но заметил факт, пользуюсь потом этим крайне редко, иногда полистаю что там накопилось — "и зачем мне нужна была эта фигня!"
Это потому, что ты роешь знания чайной ложкой, а основу хранишь в голове. А моя статья для тех, кто роет знания экскаватором. ПИМы же просто сдуваются при реально больших объёмах. Думаю если набрать запрос "OneNote тормозит", будет тоже самое, что и с другими ПИМами. Они все тормозят, кто-то больше, кто-то меньше, но исключений нет. Впрочем я уже описал их недостатки в статье.
Если цель себе поставить, то можно наверное и так сделать. Но зачем? Это же просто инструмент для помощи при достижении реальных, нужных целей.
>>А моя статья для тех, кто роет знания экскаватором. ПИМы же просто сдуваются при реально больших объёмах.
_>Если цель себе поставить, то можно наверное и так сделать. Но зачем? Это же просто инструмент для помощи при достижении реальных, нужных целей.
Я заметил такую вещь, что собственные заметки довольно полезны, они позволяют сэкономить время в будущем. Но у них есть фатальный недостаток, они не охватывают тему полностью. Соответственно не могут быть приоритетным источником знаний, когда нужно решить какую-то проблему.
В свою очередь это не даёт совершенствовать свои личные знания, ведь они в основном в голове. А достать их оттуда можно только ассоциативным сигналом, только вот откуда его взять. В итоге когда нужны какие-то знания приходится их искать в чужих внешних источниках.
Если личная база знаний не нужна, то здесь всё понятно, не нужна, так не нужна. Но проблема ПИМов в том, что пока они пустые, то работают довольно шустро, а на больших объёмах умирают. Причём Microsoft Word и LibreOffice Writer тоже не выдержат большой нагрузки.
Я знаю два разных решения, которые легко держат большие объёмы в одном документе. Это прежде всего редакторы простого текста plain text и отображения html в браузере. Причём если не писать лишнего и привыкнуть, то и html в редакторе плоского текста вполне читаем.
vsb>Да, уже давно хочу сделать себе сайт-вики (персональную) и туда лепить всякую всячину, которая бывает полезна или до которой долго докапываться. Пока оно в виде всяких постов на форумах/со/гистах, но когда надо — фиг вспомнишь. Штука реально полезная.
У меня никаких wiki нет, всё куда проще — система каталогов на диске компьютера, где лежат различные файлы — преимущественно текстовые. В них содержатся все записи. Всё рассортировано по различным тематикам.
Всё очень просто и надёжно. Уверен, если потребуется — я скриптами переведу всё в нужный иной формат. А пока и так работает. Самый кайф в том, что я уверен, что БД с записями однажды не испортится, как в каком-нибудь приснопамятном MS Outlook.
V>На этом пожалуй и закончим введение в личные базы знаний.
И дальше-то что?
V>Вопрос теперь в том нужно ли выходить на работу с опозданием или вообще не приходить. Ведь сотрудник, который опоздал ещё не так плох, как полный прогульщик.
Кто-то сказал "Zettelkasten"?
https://t.me/Zettelkasten_ru
AS>Кто-то сказал "Zettelkasten"?
AS>https://t.me/Zettelkasten_ru
У меня система основана на следующем.
1) Правило трёх кликов.
2) Строгий древовидный иерархический спуск вниз по ссылкам.
3) Постранично всего лишь два уровня иерархии.
Первый уровень страница индекса index.html.
Второй уровень ссылки на все остальные страницы.
4) При этом гарантировано, что на странице индекса существуют все ссылки на остальные страницы и встречаются они лишь один раз.
5) Так же гарантированно, что все страницы находятся в одной директории.
6) К третьему и последующим уровням относится оглавление страниц второго уровня.
7) Гарантировано, что в оглавлении страниц второго уровня нет ссылок на страницы второго уровня, то есть только внутренняя связь.
8) Из содержимого возможны кросс ссылки между страницами второго уровня, хотя я бы такое не слишком поощрял.
Один из как я считаю недостатков документации GNU/Linux.
1) Прыжки между статьями.
2) Непрослеживаемость нисходящей древовидной иерархии.
Дело в том, что в Zettelkasten используют бумагу. Связи, которые там устанавливают используя всякие изощрённые методы, мне же даются по умолчанию якорями и гиперссылками.
Так же и здесь, нисходящая древовидная иерархия должна быть основой. Все остальные кросс ссылки могут ссылаться на неё.
Собственно говоря я решаю проблемы, которых не было у Zettelkasten. Бумажная папка по мере набора листов не начинает тормозить при просмотре по очевидным причинам. И в тоже время у html нет проблемы кросс ссылок, которые для меня скорее вредны при их необдуманной установке.
Скорее удивительно, что тему Zettelkasten постоянно мусолят. В наше время есть интернет, который давно работает по схожему принципу. Только сейчас мы просто тыкаем на ссылки и всё.
И это как раз одна из причин почему я вообще написал подобную статью. Лично я долгое время не замечал это бревно в глазу, а всё потому, что читая html мне лезла реклама ПИМов, генераторов документации, генераторов сайтов и прочее.
V>2) Строгий древовидный иерархический спуск вниз по ссылкам.
Нафиг все строгости, да здравствует эволюция! Самый удобный подход самый правильный и должен выявится опытным путем.
Простые гипертекстовые ссылки позволяют организовать любую иерархию.
Пусть ты чуть больше времени потратишь на создание ссылок.
Но это лучше чем пытаться поменять всю архитектуру.
А когда уже наметятся устоявшиеся практики, например индексация записей по датам, их можно автоматизировать.
(В TexMacs можно скрипты, например выделил текст, нажал горячую клавишу, и ссылка на документ в целевом окне готова)
V>У меня система основана на следующем.
V>1) Правило трёх кликов.
V>2) Строгий древовидный иерархический спуск вниз по ссылкам.
V>3) Постранично всего лишь два уровня иерархии.
Попытался себе представить применение этого правила к классификации живого.
По какому принципу будем упихивать уровневую систему: домен, царство, тип, класс, отряд, семейство, род, вид, порода/форма — в три клика? И, главное, зачем?
(я ещё всякие надклассы и подвиды не вспомнил)
При желании можно и другие области знаний вспомнить, где такое не работает.
Я бы лучше опирался на правило типа "стараться держать на каждом уровне от 10 до 20 подуровней".
V>7) Гарантировано, что в оглавлении страниц второго уровня нет ссылок на страницы второго уровня, то есть только внутренняя связь.
А принципиальные кросс-ссылки почему не допускаются?
Можно же их просто выделить отдельно?
V>8) Из содержимого возможны кросс ссылки между страницами второго уровня, хотя я бы такое не слишком поощрял.
Если что-то принципиально не ложится в строгую иерархию?
V>Один из как я считаю недостатков документации GNU/Linux.
Которой из? Той, что пишется в texinfo? (предполагаю так)
V>1) Прыжки между статьями.
Зато она легко разбирается.
V>2) Непрослеживаемость нисходящей древовидной иерархии.
Обычно таки на каждой групповой странице рисуют элементы в её каталоге, и (в стандартном браузере) 'u' переходит на уровень вверх. Что ещё нужно?
V>Так же и здесь, нисходящая древовидная иерархия должна быть основой. Все остальные кросс ссылки могут ссылаться на неё.
Да. Но прочие ограничения у вас выглядят слишком жёсткими.
V>И это как раз одна из причин почему я вообще написал подобную статью. Лично я долгое время не замечал это бревно в глазу, а всё потому, что читая html мне лезла реклама ПИМов, генераторов документации, генераторов сайтов и прочее.
Ну чтобы получать такую рекламу, наверняка надо уже что-то подобное гуглить...
V>>7) Гарантировано, что в оглавлении страниц второго уровня нет ссылок на страницы второго уровня, то есть только внутренняя связь.
N>А принципиальные кросс-ссылки почему не допускаются?
N>Можно же их просто выделить отдельно?
Отдельно они могут быть в содержимом, но не в оглавлении-содержании. Тогда можно гарантировать спуск и обратный подъём по иерархии без пересечений. На вопрос почему так ответ очень простой, это имитация обычной книги, только в формате html.
Хочешь читай последовательно, хочешь прыгай по ссылкам. Но нужна гарантия, что ссылки именно из оглавления-содержания не отправят на другую страницу, то есть в параллельную книгу. В книгах включая электронные такого тоже нет, так что я тут ничего удивительного не придумал.
V>>8) Из содержимого возможны кросс ссылки между страницами второго уровня, хотя я бы такое не слишком поощрял.
N>Если что-то принципиально не ложится в строгую иерархию?
Здесь нужно понимать, что это не классификация объектов, а иерархия поиска. Иными словами если что-то не упорядочивается, то это можно и не упорядочивать, или упорядочить потом.
По сути составление оглавления-содержания, возможно объединённой версии для более быстрого перехода. А то в книгах часто пишут оглавление, потом содержание, но вот ссылки из оглавления на содержание не ставят. А ведь там ещё потом нужны ссылки из содержания на содержимое.
V>>2) Непрослеживаемость нисходящей древовидной иерархии.
N>Обычно таки на каждой групповой странице рисуют элементы в её каталоге, и (в стандартном браузере) 'u' переходит на уровень вверх. Что ещё нужно?
Нужен полный спуск и полный подъём, то есть на каждую ссылку вниз, противоположную ссылку вверх, но пока что это всё прикидка. Я сделал прототип, он отлично работает, но кто знает, что мне потом в голову придёт по мере заполнения личной базы знаний.
V> Ведь сотрудник, который опоздал ещё не так плох, как полный прогульщик.
Позанудствую. Иногда бюрократические процессы так устроены, что проще совсем прогулять, чем опоздать.
V>А ещё нужно понимать, что браузеры вылизывают для сверх быстрой обработки html и css.
Оптимизировать надо не под браузеры, а под собственное удобство. Минимизировать порог лени для записи чего-либо.
WYSIWYG-редакторы самое то.
С другой стороны, может возникунуть желание чего-то красиво оформить или формулу записать, как в Latex.
Я выбрал TexMacs в качестве такого редактора.
Правда мои потуги ведения базы знаний всеравно разбились о лень.
Надо чтобы ведение такой базы шло как часть повседневной деятельности. Серфишь в инете, попутно заполняешь базу знаний.
Пытался соорудить Wayland-композитор для этого дела, но опять же забил.
А потом придумали ещё раз формат DocBook, потому что HTML недостаточно XML-подобный.
Но это всё плохо, неправильно и нестабильно, поэтому документы должны быть в PDF/A,
и это закреплено нормативными правовыми актами РФ
(там где про отсылку издательствами обязательных экземпляров в электронном виде).
https://66.rkn.gov.ru/directions/p18759/p18815/
Цифровая грамотность она такая. Не каждый может просто взять и создать цифровой документ.
ЭФ>HTML придумали люди, не умеющие создавать man-ы на его языке разметки (troff/groff).
ЭФ>А потом придумали ещё раз формат DocBook, потому что HTML недостаточно XML-подобный.
ЭФ>Но это всё плохо, неправильно и нестабильно, поэтому документы должны быть в PDF/A
Я уже всё описал в статье в разделе "Генератор документации". Если потом или сразу понадобится сайт, то придётся генерировать html и придётся учитывать как это будет выглядеть именно в html. А выглядеть это будет плохо, так как использование html напрямую для получения html многократно эффективнее, чем генерировать этот самый html с потерями и невозможностью использовать весь потенциал.
"Генераторы документации" лично для меня давно пройденный этап, так как в них нет абсолютно никакого смысла.
ЭФ>и это закреплено нормативными правовыми актами РФ
Вообще не волнует. Моя личная база знаний, что хочу, то и делаю. Если я хочу сайт, то это будет сайт. А если я захочу документ, то его проще будет генерировать из html хоть в тот же pdf.
Одна из серьёзных проблем генераторов документации, что нельзя перемещаться сразу по всей теме. Вместо одного большого файла имеет место разбиение на множество файлов. Не то, чтобы генератор документации поощрял подобное, но там как правило есть возможность включения других файлов.
И это один из вопросов, почему в html нет включения содержимого других файлов. Казалось бы нет и нет, не предусмотрели. Но действительно ли не предусмотрели, или предусмотрели, что это не нужно и даже вредит.
Дело в том, что в статьях я не пишу предпосылки выводов, почему так, а не иначе. А серьёзные аргументы против других методов действительно есть, так как я пытался заводить личную базу знаний разными способами и все они не сработали.
Причины отказа от прочих языков разметки:
1) Тормознутый софт.
2) Требует изучения ещё одного синтаксиса.
3) Всё равно требует генерации в html.
4) Не позволяет использовать весь потенциал html.
5) Казалось бы полезные, но на самом деле вредные возможности.
И так далее и тому подобное.
Ну,
1) есть Server side includes
2) фреймы
3) можно джаваскриптом нашаманить
V>На этом пожалуй и закончим введение в личные базы знаний. И закончить я хочу с того же, с чего и начал. Кто не успел, тот опоздал. Лично я опоздал. Вопрос теперь в том нужно ли выходить на работу с опозданием или вообще не приходить. Ведь сотрудник, который опоздал ещё не так плох, как полный прогульщик.
На телефоне для этих целей юзаю стандартные заметки. Картинки/схемы рисую на айпаде стилусом, опять же в стандартных заметках. Если хочется, чтоб было доступно всегда и везде — облако к вашим услугам (хотя я не любитель).
Для заметок по техническим вещам пишу .md файлы и складирую в папку. Разметка там элементарная, поиск по имени файла/содержимому отлично справляется. Также эти файлы можно залить на гитхаб, если понадобится.
V>На этом пожалуй и закончим введение в личные базы знаний.
Ты не указал самые интересные способы хранения знаний.
1. Mind map! У меня в команде был архитектор, который их использовал всегда и везде, с компа и телефона. Там были всевозможные связи, к узлам цеплялись ссылки, статьи, картинки и т.д. По такой карте можно было очень быстро въехать в тему или разобраться в проекте. Но вести не просто, надо овладеть культурой.
2. Теги. В реальности знания и объекты не иерархичны, а связаны между собой весьма затейливым образом. Поэтому можно разработать систему тегов и ориентироваться по ним (в том числе по ним).
3. Аудио. Многие просто начитывают мысли в диктофон, записи каталогизируют, систематизируют, иногда расшифровывают. Уверен, что автоматическая расшифровка не за горами, также как и нормальный поиск по неструктурированным данным.
4. Автоматическая суммаризация, кластеризация, построение связей. Уже сейчас, работая со статьями в том же Гугл.Сколар можно пользоваться самой примитивной версией: смотреть, кто ссылается на статьи, на какие статьи ссылок больше, на какие они новее и т.п. Сделать что-то сложнее с современными NLP технологиями не выглядит сколько-нибудь сверхзадачей. Не сегодня-завтра решения появятся на рынке (уверен, что они и сейчас есть). Вполне можно будет автоматически парсить заметки/статьи/исходники, чтобы находить связи между ними.
N>Ты не указал самые интересные способы хранения знаний.
N>1. Mind map!
Указал, читай раздел "Карта разума". Те, которые основаны на базах данных, такие как Compendium_ со временем становятся слишком тормознутыми. Отчасти это происходит благодаря Java, отчасти из-за плохой оптимизации. Что касается FreeMind, MindMapper и других, то минус в разбиении на большое количество файлов, да и Dia превосходит их на голову не имея ненужных ограничений.
N>2. Теги. Поэтому можно разработать систему тегов и ориентироваться по ним (в том числе по ним).
Можно, да, у меня в планах давно уже такая программа. Но тут надо разрабатывать, а в html ничто не мешает использовать теги сразу за счёт якорей и гиперссылок.
N>3. Аудио. Многие просто начитывают мысли в диктофон, записи каталогизируют, систематизируют, иногда расшифровывают.
Я даже стримы вёл, это дохлый вариант. Слишком много лишнего, не подходит для личной базы знаний, которая должна напротив сжимать по максимуму информацию для её быстрейшего восстановления в мозгу.
N>4. Автоматическая суммаризация, кластеризация, построение связей. Вполне можно будет автоматически парсить заметки/статьи/исходники, чтобы находить связи между ними.
Это тоже одна из моих ошибок. Да, можно парсить, как раз парсер, лексер, токенизатор, я не раз рассказывал об этом. В чём ошибка, так всё просто, это мечта, что некая программа будет работать за тебя. Но нет, не будет, она может лишь помочь.
К тому же парсить будешь чужой мусор, а личная база знаний это считай совершенное личное ядро знаний. Совершенное оно не потому, что лучше нельзя, а потому что сам лучше до поры до времени не можешь.
Здесь самое главное, что я бы начал парсить сейчас, но нет нужного программного обеспечения. Чтобы его создать, нужно накопить знания в личной базе знаний. Попадаем в замкнутый круг.
Вот и выходит, что все способы были уже испробованы, из простых остался лишь ручной набор html.
N>>1. Mind map!
V>Указал, читай раздел "Карта разума".
Указал, но толком ничего не сказал. Потому что это действительно очень удобное представление именно что знаний, а не просто способ поиска информации.
Извини, что твоя "статья" просто замусорена ненужными деталями, которые не про знания совсем — карандаши, линейки, тетради, диски, файлы. Это не относится к знаниям, а к способу хранения данных. Данные != знания.
N>>2. Теги. Поэтому можно разработать систему тегов и ориентироваться по ним (в том числе по ним).
V>Можно, да, у меня в планах давно уже такая программа. Но тут надо разрабатывать, а в html ничто не мешает использовать теги сразу за счёт якорей и гиперссылок.
Это тоже мимо — путаешь способ связывания и способ представления. Теги — это то же самоё, что и рёбра в графе, которые позволяют связывать между собой разные темы, статьи, произведения.
N>>3. Аудио. Многие просто начитывают мысли в диктофон, записи каталогизируют, систематизируют, иногда расшифровывают.
V>Я даже стримы вёл, это дохлый вариант. Слишком много лишнего, не подходит для личной базы знаний, которая должна напротив сжимать по максимуму информацию для её быстрейшего восстановления в мозгу.
Стримы или нет — не важно. Что ты делал, чтобы аудио данные превращались в структурированные данные, по которым можно переходить, каталогизировать, искать?
N>>4. Автоматическая суммаризация, кластеризация, построение связей. Вполне можно будет автоматически парсить заметки/статьи/исходники, чтобы находить связи между ними.
V>Это тоже одна из моих ошибок. Да, можно парсить, как раз парсер, лексер, токенизатор, я не раз рассказывал об этом. В чём ошибка, так всё просто, это мечта, что некая программа будет работать за тебя. Но нет, не будет, она может лишь помочь.
V>К тому же парсить будешь чужой мусор, а личная база знаний это считай совершенное личное ядро знаний. Совершенное оно не потому, что лучше нельзя, а потому что сам лучше до поры до времени не можешь.
V>Здесь самое главное, что я бы начал парсить сейчас, но нет нужного программного обеспечения. Чтобы его создать, нужно накопить знания в личной базе знаний. Попадаем в замкнутый круг.
Парсер, лексер и токенизатор — это не для естественных языков, они же не понимают контекст. Инструмент суммаризации обучается на огромном массиве внешних данных, а потом применяется уже для твоих: будь то записки или прочитанные статьи.
V>Вот и выходит, что все способы были уже испробованы, из простых остался лишь ручной набор html.
Или не испробованы.
V>>Вот и выходит, что все способы были уже испробованы, из простых остался лишь ручной набор html.
N>Или не испробованы.
Испробованы, а статья это итоговый вывод. Просто мне не хотелось ругать каждый способ, иначе бы статья увеличилась на порядок, а время её написания растянулось на несколько дней.
Борьба с нарастающей сложностью это то, что не дают ни карты разума, ни схемы, ни чертежи. ПИМы же просто сливаются от переизбытка информации и это вина их разработчиков, но имеем то, что имеем.
Как писал kov_serg.
По сути сайты тоже прошли процесс эволюции. Почему сейчас весь интернет в html, ведь распространять знания можно было бы в ином формате. А потому, что очевидно другие способы не сработали.
Так же и с форматом распространения знаний. Бывают более эффективные форматы и менее эффективные. Почему в том же описании технических деталей победил формат документации.
Если карты разума так круты, то почему мы не видим книги заполненные ими сверху донизу. Карты разума, схемы и чертежи могут стать составными элементами документации, но не основой.
Опять же эта моя точка зрения, если у кого есть способ лучше, то нет проблем. Я лишь объяснил почему для меня это не сработало.
V>Если карты разума так круты, то почему мы не видим книги заполненные ими сверху донизу. Карты разума, схемы и чертежи могут стать составными элементами документации, но не основой.
Потому что в книги их не засунуть, для них необходимо хорошее специализированное ПО, оно платное. А также культура их ведения.
V>Опять же эта моя точка зрения, если у кого есть способ лучше, то нет проблем. Я лишь объяснил почему для меня это не сработало.
Для меня вообще странно звучит про html. Я также могу сказать: вся информация хранится в реляционных БД, а html генерируется автоматичски с требуемыми данными, полученными из этих БД. Но это опять же не знания, а данные и их представление. Про знания говорят в терминах онтологих, семантических связей, концептуальных схем. Вот mind map — это как раз про это.
N>Для меня вообще странно звучит про html. Я также могу сказать: вся информация хранится в реляционных БД, а html генерируется автоматически с требуемыми данными, полученными из этих БД.
Видишь ли, первый раздел статьи говорит о том, что знания хранятся и обрабатываются в первую очередь в мозгу, а всё остальное это лишь вспомогательные инструменты. Там даже есть условная картинка мозга и книги, чтобы было понятно отличие.
Возможно чтобы донести эту информацию для тех, кто над этим никогда не задумывался мне нужно написать книгу, где раз за разом мусолить одну и ту же мысль разными предложениями.
Как угодно калякай, хоть в тетради, хоть в html, хоть в базе данных, это прежде всего вспомогательный инструмент. Вопрос в том удобный ли или нет.
Думаешь разделить представление и данные это удобно. Но это лишь создаёт ненужную сложность, тормознутость, ограничение на структуры данных.
N>Про знания говорят в терминах онтологий, семантических связей, концептуальных схем. Вот mind map — это как раз про это.
Вот и попробуй записать код в картах разума. Я пробовал, получается плохо. Даже Dia не спасла, хотя она то как раз могла создавать гигантские схемы на одном листе.
V>Видишь ли, первый раздел статьи говорит о том, что знания хранятся и обрабатываются в первую очередь в мозгу, а всё остальное это лишь вспомогательные инструменты. Там даже есть условная картинка мозга и книги, чтобы было понятно отличие.
Видишь ли, люди, занимающиеся компьютерным зрением, имеют представление о том, как и что хранится и обрабатывается в мозге. Хотя бы потому, что концепция свёрточных нейронных сетей была придумана под вдохновлением от книги "Глаз. Мозг. Зрение". И они её читают, а также многое другое. LSTM, attention, современные архитектуры Transformer и т.д. вдохновляются принципами, которые черпаются из знаний о мозге (это следует хотя бы из их названий).
V>Возможно чтобы донести эту информацию для тех, кто над этим никогда не задумывался мне нужно написать книгу, где раз за разом мусолить одну и ту же мысль разными предложениями.
Чтобы донести эту информацию, для начала надо разобраться в теме, потому что в вузах её всё таки преподают и вводят определённую терминологию. Но ты не пользуешься этой терминологией, присваиваешь известным терминам совсем другие значения и явно путаешь данные, с носителями данных и со знаниями.
V>Как угодно калякай, хоть в тетради, хоть в html, хоть в базе данных, это прежде всего вспомогательный инструмент. Вопрос в том удобный ли или нет.
Удобный для чего? html — это не средство хранения знаний, потому что у него нет никаких для этого инструментов. И тетрадь, и база данных. Это всё может использоваться для хранения и представления данных. А что со знаниями? Можно почитать, что ты пишешь:
V>Для этого не нужно никакого нового программного обеспечения. Те же таблицы MSOffice или LibreOffice позволяют упорядочить что угодно
Так их достаточно или нет?
V>Думаешь разделить представление и данные это удобно. Но это лишь создаёт ненужную сложность, тормознутость, ограничение на структуры данных.
И это при этом не имеет никакого отношения к знаниям. А что ты скажешь про современные архитектуры NLP сетей? Они же хранят в себе и данные, и связи между ними. Это уже базы знаний?
N>>Про знания говорят в терминах онтологий, семантических связей, концептуальных схем. Вот mind map — это как раз про это.
V>Вот и попробуй записать код в картах разума.
Зачем?!! Ты точно человек, а не нейросеть?
V>Я пробовал, получается плохо.
Не верю, что пробовал. Или покажи пример.
V>Личные знания людей прежде всего хранятся и обрабатываются в головах в нейронной сети во вполне физическом виде, назову это внутренним носителем. Но в большинстве случаев этого недостаточно и нужна дополнительная запись на внешние носители.
Любые знания имеют смысл лишь при их повторном использовании.
Знания часто устаревают, становятся неактуальными. В целом база знаний требует поддержки, затрат в том числе на систематизацию. В то же время потеря информации тоже имеет свою цену. Ты можешь спокойно не тратить время на сохранение какой-то информации, и это будет выгодно. Важно научиться отбрасывать ненужное. Поиск инфы — тоже затраты, если затраты на сохранение или каталогизацию выше чем потом при поиске — зачем они нужны?
К чему пришел я. В жизни у тебя есть проекты большие и маленькие, есть регулярные процессы. Знания же идут рука об руку с документами и вещами — это всё продукт минипроектов.
1. Два способа хранения инфы/доков — вещественный в виде коробок/папок и виртуальный в виде папок на яндекс.диске + почта — во втором случае инфа всегда с тобой.
2. Не надо вкладывать излишние усилия в стандартизацию, систематизацию и каталогизацию — достаточно осмысленно называть файлы и папки/коробки — потом найдешь нужное.
Появился некий кейс — например, возврат налогов, просто делаешь папку "возврат налогов 2019" — набрасываешь туда всё, что использовалось в ходе этого минипроекта — сканы доков, декларацию, список нужных документов. Делал ремонт в квартире — аналогично "квартира ленинский", если какие-то проекты были — бросаешь туда, фоткаешь схемы электрики сохраняешь "электрика", если проектов не было, но нужно помнить нюансы — просто создаешь текстовый файл и бросаешь в папку. Платишь регулярно за какие-то вещи? Делаешь файл "как платить.txt" — и набрасываешь там нюансы, которые надо иметь под рукой — номера счетов, логины/пароли (подсказки к оным) и т.п.
Делал технический проект для себя, какую-нибудь хреновину с автоматизацией? Заводишь под него папку — точно так же набрасываешь туда всё — сохраненные полезные страницы из интернета, свои мысли или заметки в текстовиках, проги если нужны были или код и т.д. — потом найдешь, разберешься, если потребуется, главное опиши финальное решение и кратко инструкцию по использованию, чтобы разобраться при перерыве в использовании, при поломках или доработках.
Всякие доки, запасные ключи и проч. по авто — коробка с именем "авто" — понадобится что-то, найдешь там быстро.
Инструкции храни рядом с используемым девайсом — к котлу на стене рядом с котлом, к кухонной технике — рядом с ней в шкафах или полочках, к снегоходу — на полке в сарае, где хранятся причиндалы для его обслуживания, всё по оружию (доки/патроны/чехлы) — в сейфе для оружия, и т.д.
В общем — обеспечь сохранение и облегчи поиск, когда понадобится — трать на это как можно меньше усилий, но не меньше.
>Личная база знаний одного человека может стать внешним источником знаний других людей, наглядный пример книги или статьи.
Книги и статьи как раз и пишутся так, чтобы могли быть источником для других — именно на это (на возможность использовать не только самому) тратится дополнительное время/усилия, порой довольно большие. Т.е. надо все-же различать — знания личные или для использования окружающими.
Так вроде My tetra решила вопрос удобного сохранения/доступа базы знаний.