Здравствуйте, sergey2b, Вы писали:
S>я когда то писал систему хранения и обработки не структурированной информации
S>правда кроме fuzzy search в дальнейшей карьере использовано не было
У меня всё гораздо проще. По сути моим способом может воспользоваться школьник или домохозяйка. И он относится не только к программированию, хотя создавался в расчёте именно на него.
S>проблема просто закрыть вкладку в том что есть шанс что через неделю понадобиться информация с нее и найти ее снова может занять пару часов
S>пока мне кажется скриншот страницы и сохраненный с нее текст может помочь в ее поиски
В принципе я могу кратко описать мой способ создания личной базы знаний, хотя как уже писал выше он на стадии испытания и не до конца продуман.
Для начала у меня есть папка archive, всё с маленькой буквы. Она общая как для Windows, так и для Deiban. Внутри лежат различные папки.
archive
anime
audiobooks
books
develop
distros
games
images
lessons
modeling
movies
music
photo
podcast
serials
tvshows
virtualbox
Это далеко не весь список, просто дан для общего понимания. Я даже не могу гарантировать, что папки останутся в таком виде. Каждая из них обозначает дело, которым я хочу в данным момент заниматься. И каждая из них имеет определённую структуру для упрощения хранения и доступа.
Первое к чему я пришёл при хранении файлов это отказ от иерархии и вместо этого использование линейного списка.
archive
anime
Аватар короля [720p, ADStudio]
[AniDub]_The_King's_Avatar_[720p]_[ADStudio]
[AniDub]_The_King's_Avatar_[01]_[720p_x264_Aac]_[ADStudio]
[AniDub]_The_King's_Avatar_[..]_[720p_x264_Aac]_[ADStudio]
[AniDub]_The_King's_Avatar_[12]_[720p_x264_Aac]_[ADStudio]
[AniDub]_The_King's_Avatar_[720p]_[ADStudio].torrent
..
Ярость Бахамута - невинная душа [720p, ADStudio]
[AniDub]_Shingeki_no_Bahamut_-_Virgin_Soul_[720p]_[ADStudio]
[AniDub]_Shingeki_no_Bahamut_-_Virgin_Soul_[01]_[720p_x264_Aac]_[ADStudio]
[AniDub]_Shingeki_no_Bahamut_-_Virgin_Soul_[юю]_[720p_x264_Aac]_[ADStudio]
[AniDub]_Shingeki_no_Bahamut_-_Virgin_Soul_[24]_[720p_x264_Aac]_[ADStudio]
[AniDub]_Shingeki_no_Bahamut_-_Virgin_Soul_[720p]_[ADStudio].torrent
Есть русское название, а внутри торрент файл и папка с таким же названием в которой лежат закачки. Это помогает легко восстановить закачки в случае переноса торрент клиента. Примерно так всё и организовано.
Что касается папки
distros, это папка с дистрибутивами для различных платформ. Не обязательно программы или её код разных версий, так же сейвы, настройки, локализации и прочее.
archive
distros
7zip
alfresco
battlenet
codesys
deadoralive5lr
filelight
foxitreader
geany
hwmonitor
inkscape
kodi
lua
obs
qbittorrent
rendermonkey
rufus
trine
virtualbox
windjview
Дистрибутивов многократно больше, это я просто привёл для примера часть из них. Что касается папки
develop, то это папка использует git для синхронизации с другими моими компьютерами и относится она к некой неопределённой разработке. Вот внутри неё я сейчас и пытаюсь сформировать личную базу знаний.
1) Мне не требуется, чтобы кто-то ещё имел доступ к ней, следовательно не нужен механизм слияния.
2) Для документирования использую LibreOffice Writer с нативным форматом *.odt. Это к вопросу о том, что кто-то пытается этой программой открывать файлы *.doc, что по сути является импортом/экспортом, а потом обзывает программу кривой.
А дальше начинается уличная магия. Если смотреть на
develop прямо сейчас, то в ней важны следующие папки.
archive
develop
documents
examples
projects
Персональная база знаний находится в
documents, хотя всё может измениться в любой момент. Внутри я планирую хранить документы, что-то вроде:
archive
develop
documents
books
cpplanguagese.odt
designpatternsgof.odt
patternsofenterprise.odt
programminginlua.odt
umldistilled.odt
distros
qt487.odt
articles.odt
distros.odt
planning.odt
programming.odt
science.odt
Для тех кто не заметил, помимо тематического линейного списка именам файлов и папок идут с маленькой буквы без любых разделителей. Так же обращаю внимание на то, что папка
books и
distros повторяют название из папки
archive, где на самом деле лежат книги и дистрибутивы.
И самое главное начинается с оформления документов.
1) Первый постулат любой текст должен отображаться моноширным шрифтом одного и того же размера. У меня это пока
Courier 10 Pitch 8 pt. LibreOffice Writer использует стили.
2) Второй постулат отступы и интервалы в стилях нужно поставить на 0. Это отступ перед, после текста, первая строка, интервал перед и после абзаца.
Иными словами текст должен выглядеть точь в точь как в обычном текстовом редакторе. Делается два указателя, первый на глубину 1 или 2 заголовка, не больше из-за
правила трёх кликов. Второй полный, то есть до 10 подзаголовков. Хотя в реальности понятия всегда должны стоять на одном уровне. Если это третий уровень, тогда каждое понятие должно принадлежать Заголовку 3.
Для оформления использую знак # повторяющийся ровно 72 раза по
rfc2223. Тем не менее текст, который будет вставлен из других источников не должен переносится вручную, вместо этого используется режим просмотра
Вид > Веб-страница, а масштаб увеличивается до размера области просмотра строки состоящей из #.
Всё это выглядит примерно так:
Заглавие
Содержание
Категория
Категория
Категория
Категория
Категория
Категория
Оглавление
Категория
Категория
Понятие
Подпонятие
Понятие
Подпонятие
Категория
Понятие
Понятие
Категория
Категория
Понятие
Понятие
Категория
Понятие
Понятие
########################################################################
Категория
########################################################################
########################################################################
Категория
########################################################################
Заголовки категорий и понятий используют градиентную заливку фона и белый цвет шрифта, а фон всего документа чёрный. Тогда как в указателе у меня пока что просто цветные буквы с чёрным фоном.
Стили можно перенести с помощью команды:
1)
Файл > Шаблоны > Сохранить как шаблон,
2) а потом импортировать
Стили > Загрузить стили и пометить галочки
Текст, Врезки, Страницы, Нумерация, Перезаписать.
Причём первый шаг не обязателен, так как стили можно импортировать из другого документа. Нужно оформлять документ заранее известными стилями.
Есть разные виды стилей, пока что важно запомнить:
1) Стили абзаца
2) Стили символа
Стили абзаца:
1)
Блочная цитата используется для обозначения чужого текста, цвет жёлтый.
2)
Основной текст для того, что написал сам, цвет бирюзовый.
3) И, конечно, всё наследуется от
Базового текста, так что в первую очередь можно изменить его.
Напоминаю, что везде убраны отступы и интервалы, шрифты одинакового размера и различается лишь цветом.
Стили символа (используются исключительно внутри абзаца, но не на весь абзац):
1)
Интернет ссылка и
Посещённая гиперссылка, цвет небесно-голубой
2)
Выделение и
Выделение жирным, сменить на жирное и подчёркивание, одна или две линии.
И так далее.
Вся прелесть стилей, что их оформление можно изменить потом и скопировать во все документы, и те в свою очередь автоматически изменятся.
Быстро ставить заголовки: Ctrl+1, Ctrl+2, Ctrl+3, Ctrl+4...
Быстро добавить ссылку: Ctrl+K, Ctrl+V, Enter
(обязательно убрать галочку
Сервис > Автозамена > При вводе)
И ссылку нужно добавлять именно в таком виде, в котором она есть.
########################################################################
Программирование
########################################################################
https://ru.wikipedia.org/wiki/Программирование
Где строка:
1) # имеет стиль абзаца
Основной текст
2) "Программирование" имеет стиль абзаца
Заголовок ..
3)
https://ru.wikipedia.org/wiki/Программирование это гиперссылка где адрес и текст совпадают
Содержание и оглавление строятся автоматически при их обновлении. Изначально создаются командой
Вставка > Оглавления и указатели > Оглавление, указатель и библиография.
А что касается как делать заголовки, то хочу испытать вот эти идеи —
7 правил написания технической документации мирового класса.
Пока что вывел для себя, что иллюстрации нужно отделять заголовками и создавать с помощью ascii-графики.
Статьи [стиль абзаца "заглавие"]
Содержание [стиль абзаца "заголовок оглавления"]
Программирование [стиль абзаца "указатель оглавление 1"]
Документирование [стиль абзаца "указатель оглавление 2"]
Оглавление [стиль абзаца "заголовок оглавления"]
Программирование [стиль абзаца "указатель оглавление 1"]
Документирование [стиль абзаца "указатель оглавление 2"]
7 правил написания технической документации мирового класса [стиль абзаца "указатель оглавление 3"]
Ноутбук с установленной Debian 9 [иллюстрация] [стиль абзаца "указатель оглавление 4"]
########################################################################
Программирование [стиль абзаца "заголовок 1"]
########################################################################
########################################################################
Документирование [стиль абзаца "заголовок 2"]
########################################################################
########################################################################
7 правил написания технической документации мирового класса [стиль абзаца "заголовок 3"]
########################################################################
[стиль абзаца блочная цитата]
https://habr.com/ru/post/303760/
########################################################################
Ноутбук с установленной Debian 9 [иллюстрация] [стиль абзаца "заголовок 4"]
########################################################################
[стиль абзаца основной текст]
._________________.
|.---------------.|
||Debian 9 ||
|| ||
|| ||
|| ||
|| ||
||_______________||
/.-.-.-.-.-.-.-.-.\
/.-.-.-.-.-.-.-.-.-.\
/.-.-.-.-.-.-.-.-.-.-.\
/______/__________\___o_\
\_______________________/
А ещё статья
Как вы управляете своей базой знаний? Какие инструменты для этого используете?:
Я всегда читаю нехудожественную литературу с карандашом и самоклеющиемися закладками отмечая важные предложения и абзацы вертикальной линией на полях, а закладками отмечаю страницы, на которых по моему мнению "самый сок". Через месяц после прочтения я пролистываю книгу читая отмеченные отрывки- это очень эффективный метод запоминания и применения техник из книг.
Стиль абзаца
Блочная цитата, а выделение внутри абзаца для пометок это стиль символа
Выделение или
Выделение жирным, что будет обозначать лишь одинарное подчёркивание с жирными или двойное подчёркивание с жирным.
Я вообще думаю над тем, чтобы всегда отделять чужой текст не только стилем абзацев
Блочная цитата, но и заголовком. Тоже самое касается отделение иллюстраций от моих комментариев пусть даже у них один стиль абзаца
Основной текст.
В реальности это выглядит вот так:
Ещё в LibreOffice Writer есть такая фича
Правка > Режим выбора > Блочная область (Alt+Shift+F8). У меня уже давно сомнения по поводу того, что текст это строчка, а не графическое 2D изображение. Отсюда и стремление к моноширному шрифту.
Списки, таблицы и прочее возможно гораздо целесообразнее набирать вручную.
1) Список просто текст
2) И его номер в виде простого текста
Таблица не имеет формата, это ascii-графика,
которая вводится быстрее, чем псевдографика.
+------------------------------------------------------+
|типы C++ |
+-------------+--------+-------------------------------+
|название |тип |категория |
+-------------+--------+------------+--+---------------+
|логические |bool | | | |
|символьные |char |интегральные| | |
|целые |int |(целые) | | |
+-------------+--------+------------+ |фундаментальные|
|вещественные |double |арифметические |(встроенные) |
+-------------+--------+---------------+ |
|отсутствующие|void | |
+-------------+--------+-------------------------------+
|указательные |тип* | |
|массивы |тип[] |построенные поверх типов |
|ссылочные |тип& | |
+-------------+--------+-------------------------------+
|перечислимые |enum | |
|структуры |struct |определяемые пользователем |
|классы |class | |
+-------------+--------+-------------------------------+
Синтаксическая подсветка кода с одной стороны хороша, но отражает ли она всю суть, или лучше воспользоваться блочной областью.
Ещё вспомнилось про вставку статей с веб-страниц. В принципе можно вставлять в документ даже сразу с форматированием, жирным текстом, гиперссылками. Хотя конечная цель сделать документ читаемым даже после сохранения его в *.txt, вот почему ссылки у меня идут прямо адресом в названии, всё же будет присутствовать какая-то удобочитаемость, если они выделены другим цветом в документе *.odt.
Проблема ведь не только в поиске статей, которые читал ранее, для закладок можно использовать тот же документ articles.odt.
Более полный список необходимого:
1) Найти статьи, которые читал ранее
2) Обработать эти статьи чтобы они отражали собственные мысли
2.1) подчеркнуть важное в блочной цитате,
2.2) написать конспект основным текстом,
2.3) напечатать иллюстрации ascii-графикой,
2.4) разделить это всё подзаголовками.
3) Желательно хранить всю статью у себя для повторного анализа
Если описание дистрибутива qt487 не влезает в distros.odt, то можно поместить его в /distros/qt487.odt оставив в distros.odt лишь краткую информацию, а все просты утилиты вроде cd, chmod, rm и прочее полностью описать в distros.odt. По умолчанию человек помнит, что надо зайти в distros.odt, заходит туда и видит полное описание программы или что надо искать полный документ в папке
distros.
Или папка
examples, что если хранить все понятия из программирования так же линейно, а внутри размещать примеры на разных языках, но с таким расчётом, что это всего лишь дубликаты из документации. Или тот же линейный список проектов. По поводу документа планирования, то это и вовсе отдельная тема для разговора. Я пока пытаюсь испытать трекер построенных на учёте времени по часам, а не просто некой задачи, причём построенный на всё том же принципе заголовков LibreOffice Writer.
Дата.........Использованное время
[xxxx.xx.xx] зел жёл ора кра фио чёр
[xxxx.xx.xx] 1 2 3 4 * * * * * * заголовок 2
1) Задача 1 заголовок 3
2) Задача 2 заголовок 3
3) Задача 3 заголовок 3
4) Задача 3 заголовок 3
*) Прокрастинация заголовок 3
[xxxx.xx.xx] 1 2 заголовок 2
1) Задача 1 заголовок 3
2) Задача 2 заголовок 3
А откуда берутся такие мысли? Чисто теоретически можно построить некую экспертную систему, которая будет делать это лучше, я даже знаю какую. Но практически очевидно, что ничего построено в ближайшее время не будет. Во многих статьях про финансы неоднократно упоминалось, что сложные системы и вовсе ставятся лишь когда возможности офисного пакета, в частности редактора текста и таблиц, полностью исчерпаны.
Но поскольку это всё же программирование, документация должна быть совместима с форматом плоского текста в кодировке utf-8 и при преобразовании так же читаться из текстовой консоли. Возможно нужно дополнительно сделать жёсткий перенос слов до 72 символов, а код в отличие от остального текста сразу переносить вручную, но это уже детали.
Ладно, мысль я вроде донёс, тем более это всё равно пока лишь опытный образец.
Не возникает такой проблемы. Если в окне браузера больше 10 табов, закрываю окно браузера. Если надо найти информацию снова, значит ищу информацию снова.
А так вроде есть в фаерфоксе аддон Tree Style Tabs. Любители тысяч открытых табов вроде как им пользуются. Можешь глянуть.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
а какой стратегией вы пользуйтесь для сохранения bookmarks и что делайте с открытыми tabs
какой manager bookmarks вы используйте
вопрос возник тк у меня каждые пару месяцев оказываеться 500+ открытых tabs и с этим надо то то делать
просто закрыть не вариант тк потом иногда надо найти информацию снова
Здравствуйте, gyraboo, Вы писали:
G>Сейчас просто понял, что ценность информации обычно преувеличена — всегда в инете можно найти ту или иную инфу. Если инфа устарела и пропала из инета — значит она неактуальна и тебе она скорее всего тоже больше не нужна.
Вопрос ещё и в том, для чего искать информацию, а так же форма мышления, которую обретает этот самый поиск.
Я могу создать заголовки вида:
1) Создание web-приложения.
или
2) Как создать web-приложение?
А так же:
1) Отличие полей структур данных и свойств.
или
2) Чем отличаются поля структур данных и свойств?
В статье
7 правил написания технической документации мирового класса, правило номер 2
Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
По сути есть вопрос и есть ответ. Вопрос должен стоять чётко, а ответ должен давать прямые указания на решение проблемы.
Казалось бы какая разница между:
1) Отличие полей структур данных и свойств.
2) Чем отличаются поля структур данных и свойств?
а если так
3) Почему отличаются поля структур данных и свойств?
3) Когда отличаются поля структур данных и свойств?
И всё в таком роде. Первый вариант не ставит чётко вопрос, а значит не будет и чёткого ответа. На основании вопроса задаются другие вопросы.
1) Где использовать поля структур данных, а где свойства?
Под свойствами я подразумеваю особую языковую конструкцию или фундаментальный шаблон проектирования.
Программирование это наука о создании инструкций исполнителю.
Исполнителем не обязательно должен быть компьютер, это может быть тот же человек. Так что инструкции, которые пишутся в собственной базе знаний это в каком-то роде инструкции для исполнения, программы.
Програ́мма (от греч. προ — пред, греч. γράμμα — запись) — термин, в переводе означающий «предписание», то есть заданную последовательность действий.
Проблема сторонних статей в том, что эти инструкции написаны не для себя лично. Это своего рода
коробочное программное обеспечение, тогда как желательно иметь заказное.
Коробочный программный продукт — это программное обеспечение, предназначенное для неопределённого круга покупателей и поставляемое на условиях «как есть», со стандартными для всех покупателей функциями, в отличие от заказного программного продукта, само появление которого обусловлено требованием конкретного заказчика, и в отличие от проектного программного продукта, продажа которого может, по требованию заказчика, сопровождаться проектной доработкой или разработкой функций, дополняющих стандартные (базовые) возможности.
И понятно, что ценность подобной коробочной информации ниже, чем если бы это была заказная информация, которая когда-то была оптимизирована для решения проблем заказчика. Программы (предписания) пишут для того, чтобы они решали проблемы. Чем лучше они решают проблемы, тем выше их ценность в глазах пользователя.
Поиск по коробочным статьям решает проблему поиска по этим статьям, но решает ли он какие-то другие задачи, то для чего эта информация искалась. Вероятно, что не полностью, так как сами коробочные статьи могут не давать полной информации, или требовать время на их переработку в заказное решение.
