Обсидиан программа

Вызываете команду, вставляете ссылку на видео и радуетесь жизни.

Часть 2. Управление знаниями в Obsidian. Базовый рабочий процесс. Журнал. Источники и их библиотеки. Пример

В этой статье будет показано как можно начать организовывать свою базу знаний в Obsidian, отталкиваясь от источников. В статье будет разобрано то, какие стоит использовать папки и теги; как создать свою первую точку входа в систему. Также будет уделено внимание способу ведения журнала (дневника). Статья будет предполагать, что вы не против автоматизации процессов в своей базе знаний, поэтому все источники будут шаблонизированы и впоследствии собраны в свои отдельные библиотеки с помощью dataview. Завершится статья подробным примером (алгоритмом) рабочего процесса.

Структура статьи (оглавление)

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

Bad title

The requested page title is invalid. It may be empty, contain unsupported characters, or include a non-local or incorrectly linked interwiki prefix. You may be able to locate the desired page by searching for its name (with the interwiki prefix, if any) in the search box.

Possible causes are:

  • an attempt to load a URL such as https://en.wikipedia.org/wiki/| (the | character is unsupported);
  • an attempt to load a URL pointing to a «non-local» interwiki page (usually those not run by the Wikimedia Foundation). For example, the URL https://en.wikipedia.org/wiki/meatball:WikiPedia will give this error, because the «meatball:» interwiki prefix is not marked as local in the interwiki table. Certain interwiki prefixes are marked as local in the table. For example, the URL https://en.wikipedia.org/wiki/meta:Main_Page can be used to load meta:Main_Page. All interlanguage prefixes are marked as local, and thus URLs such as https://en.wikipedia.org/wiki/fr:Accueil will work as expected. However, non-local interwiki pages can still be accessed by interwiki linking or by entering them in the search box. For example [[meatball:WikiPedia]] can be used on a page, like this: meatball:WikiPedia.

Retrieved from «https://en.wikipedia.org/wiki/Special:Badtitle»

  • Privacy policy
  • About Wikipedia
  • Disclaimers
  • Contact Wikipedia
  • Code of Conduct
  • Developers
  • Statistics
  • Cookie statement
  • Mobile view

Как синхронизировать Obsidian

Obsidian хранит все файлы в текстовом формате в папке на жестком диске. Так их легче отслеживать, но не стоит забывать делать бэкапы и синхронизировать их. Впрочем, для Obsidian можно применять любой инструмент, который способен синхронизировать файлы и папки: Google Drive, iCloud, Dropbox, Microsoft, OneDrive.

Читайте по теме:

Впрочем, если синхронизировать цифровые заметки со смартфоном или планшетом, облачное хранилище может запретить Obsidian доступ к файлам. Чтобы обойти проблему, используйте бесплатную программу Syncthing (доступна на Windows, Linux, Android и macOS).

1 Этап. Планировать задачи на ежедневной основе

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

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

Daily Template:

### Три цели на день 1. [ ] 2. [ ] 3. [ ] ##### Задачи-пятиминутки 1. [ ] --- ### Обзор дня ### Ключевые метрики --- Сфера 1: --- Сфера 2: --- Сфера 3: --- ### Заметки, созданные сегодня ```dataview LIST WHERE file.cday = this.file.day SORT file.name asc 

Weekly Template:

> > --- #### Результаты недели ___ #### ✔Выполненные задачи ```dataview TASK FROM "Periodic/Daily" WHERE completed WHERE file.cday >= date("___") - dur(6 day) AND file.cday 

Вместо прочерком вставляется дата окончания недели. Templater и JS скрипты я для себя еще не открыл на тот момент. Единственное, что было у меня на вооружении - классический DataView. На нём вся аналитика и строится по итогу.

Супер простая структура. Судя по истории git работал я с ней пару месяцев. Однако в ходе просмотра результатов выяснилось, что довольно сложно отслеживать какие-то рутинные повторяющиеся дела, такие как спорт, чтение и т. д. На поле выходят метрики!

2 Этап. Отслеживаем рутинные дела и свежие идеи

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

Такой вариант структуры существенно упрощает отслеживание целевых метрик и анализ недели. Использовал её где-то месяц.

Daily Template:

--- metric_1: 0 metric_2: 0 --- ### Три цели на день 1. [ ] 2. [ ] 3. [ ] ##### Задачи-пятиминутки 1. [ ] --- ### Обзор дня ##### Какие идеи/мысли меня посетили? idea:: . 

Weekly Template:

> > --- #### Результаты недели ___ #### ✔Выполненные задачи ```dataview TASK FROM "Periodic/Daily" WHERE completed WHERE file.cday >= date("___") - dur(6 day) AND file.cday = date("___") - dur(6 day) AND date(file.link) = date("___") - dur(6 day) AND file.cday 

Так же идеи складировались в отдельный файл. Скрипт тот же, что и в Weekly Template, только без дат. Для реализованных идей придумал довольно простое решение - оборачивать их в ~~ . Тогда они будут перечёркнутыми в любых DataView списках. Просто и без геморроя

Итог

Если вы смогли осилить прочтение этой статьи, то вы однозначно красавчик или красавица. Однако, дочитав её до конца, вы лишь только сделали небольшой, но довольно значимый шаг. Из этой статьи вам ещё предстоит вынести пользу для себя.

Как я говорил в самом начале, в статье нет ничего толком про Obsidian. Надеюсь, что теперь вы понимаете почему это так – есть довольно много вещей, которые важны вне какой-то определенной заметочной программы, но которые будут очень сильно определять процесс работы. Вы можете всё это назвать бессмысленной философией, околофилософией или уж совсем грубо – переливанием из пустого в порожнее. Однако задумайтесь. Не стоит же отрицать того, что высокий уровень избирательности, а также высокий уровень осознанности при работе с различными источниками, сильно важнее, чем целиком вся программа, в которой мы будем делать по ходу дела заметки. Obsidian – это просто инструмент. У него нет целей, устремлений, идеалов, принципов и прочего подобного.

В следующей части я покажу как можно использовать конкретно Obsidian для ведения базы знаний. Начну я с самых простых, но крайне важных вещей. Однако не с самых базовых: к таковым относится синтаксис Markdown, установка программы и её интерфейс. Всё это изучите сами. Также рекомендую взять какую-нибудь давно запланированную книгу (желательно полезного толка). И по её первой главе сделать конспект, который впоследствии нужно разбить на атомные (независимые) заметки и связать их между собой с помощью ссылок. Это нужно для того, чтобы у вас появился нормальный, ценный материал на котором вы будете экспериментировать.

На этом пока что всё.

Задать вопрос или как-то расширить эту статью своим комментарием вы также можете в telegram-канале.

Если статья принесла вам пользу и вы в ответ хотите выразить свою благодарность в материальном виде, то можете сделать это вот тут или с помощью кнопки "Задонатить" (смотрите ниже).

Послесловие

Дальнейший текст можно назвать "Финальный аккорд невпопад". Там не будет ничего полезного или чего-то в продолжение этой статьи. Скорее это будет лирическим завершением цикла статей "Управление знаниями в Obsidian".

Если вы прочитали все статьи из цикла, то вам возможно покажется интересным или забавным следующее рассуждение.

Давайте вспомним в общих чертах какими были эти статьи:

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

      Теперь давайте представим, что всё таки есть в мире разделение на гуманитариев и технарей.

      Гляньте вот на такой условный график.

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

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

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

      Теперь про гуманитария. Когда он читает первую статью, то она для него наоборот легка. Это происходит в силу того, что гуманитарий уже имеет довольно обильное количество идей в своей голове о том как мыслить, как вырабатывать ориентиры и прочее. У гуманитария уже проработана его иерархия ценностей, которая позволяет достаточно эффективно отфильтровывать шелуху и фокусироваться на чем-то действительно значимом. Гуманитарий и так имеет неплохие представления о том как обрабатывать идеи или как их генерировать, поэтому первая статья для него принесёт не очень много пользы. Вторая же статья гуманитария начнет "запаковывать" в узкие рамки конкретной техники. Это значит, что гуманитарию придется преодолевать себя (значит расти), ему придётся прям стараться, чтобы принять конкретную, замкнутую, неестественную ходу его мыслей логику. Ему придется разбираться в конкретных подробностях вместо того, чтобы и дальше пытаться думать широко, всеобъемлюще (т.е. так как он и привык). Последняя статья его совсем накроет и он будет изнывать от чрезмерной узости и технической сложности. Однако польза будет велика, ибо он в большей или меньше степени, но освоит иной способ мышления и действий, причем такой, который будет закреплен за каким-то более надежным инструментом, чем просто его мозг.

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

      Из абстрактного сравнения гуманитариев и технарей возникает вот такой вопрос. А как же всё таки для мира лучше: когда мир наполнен взаимодополняющими людьми или когда люди пытаются в себе уровнять, сбалансировать условно гуманитарное и технарское?

      Можно порассуждать так: