Obsidian. Путь от простой структуры к сложной и обратно. Часть 1

Так же для проектов есть 3 отдельных маркера (одна большая буква для каждого из трёх проектов)

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

Получилось примерно так...

С таким подходом вам лучше в Logseq переехать. В нём вы больше удовольствия и пользы получите. К тому же там будет всё органичнее выглядеть:

Logseq

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

[[P1-Добавить авторизацию через Google]]... Но со временем пришёл к тому, что как таковая история задач мне абсолютно не важна... Сперва я пытался использовать проекты для любой маломальской активности...

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

Планирование иерархическое: есть план на квартал -> формируем задачи на месяц -> на основе их формируем каждую неделю -> формируем день

Отличный подход. На сколько я помню, в этой статье были не самые плохие попытки реализовать подобное.

Obsidian. Путь от простой структуры к сложной и обратно. Часть 1

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

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

Для начала стоит отметить, что всё агрегирующее стоит перенести на canvas. Теперь что именно можно там агрегировать...

"Три цели на день". Вариант будет строиться от того, что у вас есть пул задач, из которого вы выбираете те задачи, которые будете делать завтра.

Пул задач можно формировать из всех периодических заметок:

```dataviewjs
dv.taskList(dv.pages('"periodic"').file.tasks
 .where(t => !t.completed))
```

Отмечать же задачи можно с помощью тега (например, #next). Агрегирование таких задач можно сделать вот так:

```dataviewjs
dv.taskList(dv.pages('"periodic"').file.tasks
 .where(t => t.text.includes("#next"))
 .where(t => !t.completed))
```

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

Получается, что вы не тратите время на придумывание "целей на день". Вы скорее просто по ходу своей работы накидываете задачи в периодических заметках, а потом выбираете из всех незавершённых, что будете делать завтра.

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

"Заметки, созданные сегодня". Можно переместить также на canvas или вообще убрать, ибо толку от знания даты создания заметки почти нет.

Все метрики стоит отмечать в метаданных и собирать их также на canvas.

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

Hidden text

```dataviewjs
const p = dv
  .pages('"periodic/daily"')
  .where((p) => p.file.name != dv.current().file.name)
  .sort((p) => p.file.name, 'desc')
  .forEach((p) => {
    //dv.header(2, p.file.name);
    const cache = this.app.metadataCache.getCache(p.file.path); 
    if (cache) {
      const headings = cache.headings;
      if (headings) {
        dv.header(2, p.file.name);
        const filteredHeadings = headings
          .slice(0)
          .filter((h) => h.level <= 4)
          .map((h) => {
            let indent = " ".repeat(h.level - 1);
            let linkyHeading =
              "[[" + p.file.name + "#" + h.heading + "|" + h.heading + "]]";

            return indent + "- " + linkyHeading;
          })
          .join("\n");

        dv.el("div", filteredHeadings);
      }
    }
  });
```

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

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

"Выполненные задачи". С ними, наверное, всё окей. Разве, что стоит обозначить их через callout.

Штуки с "project_1_tracker", "Что сделал по проекту", "Цели на неделю по сферам" я совсем не понял. Типа, если есть полноценные проекты, которые относятся к конкретным сферам, то как бы в них (проектах) и нужно задачи ставить и выполнять. Если хочется из проектов собрать задачи, то это можно опять же сделать на canvas.

В итоге шаблон дневной заметки может иметь, например, вот такой вид:

<% "---" %>
metric_1: 0
metric_2: 0
...
reviewed: false
<% "---" %>

Т.е. просто метаданные и всё. Вся же суммирующая работа будет происходит на canvas. Это по сути значит, что сложность будет подконтрольно наращиваться только в одном месте, а не размазываться по всем периодическим заметкам. Ну, и как бы добавлять, менять и убирать метаданные намного проще, чем модифицировать (усложнять) шаблоны и переприменять их к заметкам.

Система статусов для проектов в Obsidian

Думаю, что такой ответ вас удовлетворит)

Порядок такой. В рамках базы знаний обычно концентрируюсь на одном проекте и делаю его пока делается. Фоном могут висеть несколько параллельных проектов. Пяток другой запланирован. Десятки же проектов крутятся в моей системе по управлению делами и в прочих (т.е. не моих персональных) системах.

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

Система статусов для проектов в Obsidian

А сколько у вас одновременно активных проектов?

Ответ на этот вопрос может крайне быстро устареть.

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

Но как я могу начинать проект сверху при написании первой заметки, если о проекте пока и мыслей нет, а есть только первый кусочек информации?

Могу предложить вам прочитать ещё раз длинный алгоритм. В нём в принципе есть ответ на ваш вопрос (а именно в первых его трёх частях – "Написание небольшого количества первых заметок", "Постепенное формирование списка источников и заметок", "Создание из полученных заметок связанных кластеров").

Система статусов для проектов в Obsidian

Ну вы, в целом, просто переназвали классические GTDшные статусы

Нуууу... Я даже не знаю... Может только, если прям насильно рядом поставить мою систему статусов и GTDшную и прям с упорством провести соответствие, то тогда да – переназвал.

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

пример

Код запроса взят из документации tasks:

```dataviewjs
function callout(text, type) {
    const allText = `> [!${type}]-\n` + text;
    const lines = allText.split('\n');
    return lines.join('\n> ') + '\n'
}

const query = `
not done
path includes ${dv.current().file.path}
group by heading
`;

dv.paragraph(callout('```tasks\n' + query + '\n```', 'todo'));
```

кто-то может сотню заметок свалить в кучу и помнить каждую

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

кто-то не уснет, пока не разложит заметки по тегам, папкам, приоритетам и цветам

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

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

называть извращенцами любителей Цеттеля

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

Система статусов для проектов в Obsidian

А как же "краткость - сестра таланта"?

Краткости можно добиться драфтами.

фокусироваться при написании нужно на сути документа/статьи

Всё как бы так. Статусы же нужны, чтобы процесс работы стал немного более упорядоченным, а возвращение к проекту менее болезненным.

И, да, всё что можно удалить из финального документа не вредя сути - безжалостно выкидывать или сокращать.

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

Мне лично хватает в мелких/средних документах вставлять в середину фразы "TODO что-то", а в больших вести отдельный раздел "TODO" со списком задач, которые необходимо сделать для завершения написания документа.

В статье так и делается. Только происходит это в среде Obsidian и с помощью задач, которые написаны в синтаксисе Markdown.

Система статусов для проектов в Obsidian

Да, всё так)

Отслеживание ради анализа гипотез

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

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

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

Отслеживание ради анализа гипотез

Интересно было бы узнать о результатах применения через пару месяцев.

Есть "маленькая" проблема – дневник является довольно личной штукой. Так что, вероятно, ни мне, ни кому-то ещё не захочется показывать полноценный результат комбинации метрики и дневника.

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

анализировать десятки метрик

Десятки – это слишком много. На вас же, я предполагаю, не работает целый отдел аналитиков, который бы анализировал вдоль и поперёк вашу деятельность)

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

Obsidian: Мой опыт с LYT/Ideaverse и его русификация

Салют)

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

Довольно лаконично и точно выразился юзер TobiasArtur на Reddit, что система Ника двусмысленная, имеет мало каких-то actionable элементов и вообще лучше посмотреть видео от Bryan Jenks.

Я не хотел бы совсем в край обесценивать LYT и Ideaverse, но лично я за все разы и все попытки вникнуть в системы Ника Майло терпел "поражения". Сначала мне казалось, что всё слишком сложно. Потом, меня пугала мысль, что все накрученные структуры будет трудоёмко поддерживать и что без помощи Ника мне совсем не справиться. Потом я как-то смирился и решил, что украду идеи МОС-заметкок и на этом успокоюсь. Теперь же, когда я весьма и весьма, как мне кажется, неплохо поднаторел в Obsidian и в системах мышления, мне кажется, что хранилище Ника Майло – это просто очень хорошо упакованный маркетинговый продукт, который даёт иллюзию творчества и творческого развития, но и то только, если купите курс у его автора (а иначе ничего не взлетит и не поедет).

Может, кстати, интересно кому-то будет почитать другие комментарии об Ideaverse. Ну, или потыкать куда более простое, понятное и минималистичное демо-хранилище.

Но вообще, спасибо за статейку. Хоть я тут лишь позвомущался, надеюсь, что вы напишете что-нибудь ещё про Obsidian) У вас хорошо выходит и возможно у вас получится обогатить каким-то своим и интересным видением ту же самую систему Ника Майло.

Мелкие ментальные приёмы в Obsidian (термины)

Салют)

Необязательно. Можете и что-то своё делать, хех.

Мелкие ментальные приёмы в Obsidian (термины)

Парочка технических подробностей из статьи. А то как бы сказал, что так делаю, но как сделать также не объяснил.

Скрытия yaml-блока

Для скрытия yaml-блока можно использовать вот этот сниппет:

hide-yaml.css

.is-live-preview .cm-line:has(.cm-hmd-frontmatter) { display: none; }

Далее нужен плагин Snippet Commands, который добавит в палитру команд возможность включать/отключать сниппеты. Ну, и можете соответственно на какой-то хоткей навесить скрытие yaml-блока.

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

Сдвиг текста или картинки с помощью callout-блока

Довольно жестоко предлагать каждому поставить тему Shimmering focus. Но, увы, из этой темы callout-блок sidenote фиг достанешь. Однако из ITS Theme можно достать аналогичный callout-блок. Так можно вообще весь файл S - Callouts.css утащить в виде сниппета в свой Obsidian и получить довольно много других и интересных callouts.

Сдвиг, в данном случае, будет делаться с помощью aside

aside

Сдвинуть вправо

> [!aside|show-title right] Архитектура
> ![[иллюстрация многоуровневого компьютера|250]]

результат

Мелкие ментальные приёмы в Obsidian (термины)

Про полную структуру заметок

Вообще говоря, плоховато понимаю о чём вы спрашиваете. Поэтому отвечу как смогу.

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

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

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

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

сразу делать свою структуру по разбираемой теме

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

как строить полную структуру заметок по теме

Могу предложить такую логику. Сначала ведётся работа с каким-то одним источником – формируются атомные заметки, ссылки на которые выносятся в заметку-источник. Потом идёт такая же работа с другим источником, потом с третьим, четвёртым и т.д. Как только наберётся много источников и вместе с этим огромная куча заметок по ним, то можно начать делать понемногу ту самую полную структуру заметок. Как это сделать? Ну, один из вариантов такой. Вы создаёте иерархическую заметку или мета-заметку с определённой категорией по определённой теме, которую вы хотите структурировать. Далее вы можете, например, слева открыть мета-заметку или иерархию, а справа библиотеку источников. Справа ищете и открываете источники. Из них выглядываете нужные заметки и копируете ссылки на них в левую часть.

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

В общем всё как в алгоритме в этом комментарии.

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

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

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

Spaced repetition

Всё так. Сначала мы зарабатываем какое-то понимание. Потом делаем так, чтобы это понимание на забылось. Как один из вариантов этого добиться – использовать интервальное повторение.

Развитие техники Помодоро

4 часа в день - это невероятно низкая эффективность.

4 часа – это чистый интеллектуальный труд, на который можно рассчитывать ежедневно. Очень сильно сомневаюсь, что у вас кол-во таковых часов кратно отличается.

Основная работа идет как раз во время перерыва.

Основная работа идет во время работы.

...основная задача - это погружение в состояние потока.

Основная задача работы – это реализация поставленных целей и как следствие получение результатов, а не состояние потока.

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

А тут какая-то дрочка на таймеры

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

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

Ну, и да... Вы название статьи то прочитали? Оно как бы про помидорки. Помидорки – это про таймеры. Если у вас есть в арсенале какие-то иные измеримые методы балансировки работы и отдыха, то лучше расскажите о них, а не отпускайте поверхностные фразы, которые едва ли тянут на какие-то полезные замечания.

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

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

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

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

Начнём с pdf-файла. Итак он нужен для следующего

• чтобы надёжным образом сохранить материал первоисточника

  • это нужно для того, чтобы мочь продолжить чтение с места на котором остановились

  • также это нужно, чтобы просто мочь прочитать какой-то материал, если вдруг к нему пропадёт доступ в интернете

  • ещё это нужно, если вдруг появятся какие-то сомнения в сделанных заметках

    • т.е. чтобы можно было ещё раз проверить, например, какую-то фактическую или справочную информацию

• чтобы была возможность проаннотировать текст

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

  • иначе можно сказать, что выделения в тексте нужны для того, чтобы обозначить наиболее ценные в нём мысли

Теперь заметка-источник. Она нужна для следующего

• чтобы агрегировать в себе служебную информацию о самом источнике

  • в основном это нужно, чтобы вы потом этот источник смогли найти в своей базе знаний (например, для того, чтобы продолжить его исследовать или продолжить формирование заметок, или непосредственно использовать мысли из него по назначению)

• чтобы агрегировать в себе полезную информацию, которую вы добыли из источника

  • это могут быть какие-то полезные идеи, иллюстрации, код, схемы, формулы и прочее

  • всё названное выше может быть превращено в атомные заметки и отправлено в какое-то иное место в системе (например, в какие-то определённые проекты)

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

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

Теперь немного про ваши улучшения.

Я вас поддержу в этой мысли

сам текст статьи в обсидиан не очень то и нужен

Так что строчка "%articleContent%" в шаблоне лишняя. Поэтому лучше, наверное, поискать какие-то иные альтернативы (костыли) для сохранения интернет статей в pdf-формате. Я не шибко сильно узнавал возможности по тому как это можно сделать эффективно, поэтому что-то лучше того, что упомянул в позапрошлом комменте не смогу посоветовать.

Но в общем с ReaditLater у вас хорошая идея. Этот плагин можно, кстати, на button повесить.

button

```button
name ? article
type command
action ReadItLater: Save clipboard
```

Развитие техники Помодоро

Не принимайте на личный счёт, но мне почему-то ваш комментарий напомнил книгу "Bullshit Jobs".

Но вообще, на сколько можно судить, то, например, типичные клерки эффективно работают примерно 3 часа из 8. Так что технически, чтобы получать только денежки и ничего больше, то можно тратить всего 3 часа в день. Единственное, что правда не классно, так это растягивать эти 3 часа на весь день. Я клоню к тому, что вроде бы как ваша стратегия "10 минут поработал, потом отдых и заново" это и предполагает (т.е. предполагает скучную работу, растянутую на весь день, которая делается не шибко ясно для чего). Получается своего рода неэффективная неэффективность, хах.

Развитие техники Помодоро

В основном пользуюсь Super Productivity и мне его более или чем хватает. Однако также пытаюсь распробовать Toggl в Todoist (есть даже интересный материал по этой теме).

Развитие техники Помодоро

Звучит как помидорки с 30-минутными рабочими циклами.

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

По дефолтному приложению для работы с пдф, а что это за приложение?

Не знаю какое у вас приложение по дефолту. Если Windows, то может быть Foxit reader. Если macOS, то видимо встроенная читалка.