Вот эта часть немного расширяет данную статью. Может кому-то из студентов это также пригодится.

Ладно, может это чисто мой специфический мозг неправильно воспринимает эти слова, но...

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

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

Для меня (и наверное для многих обсидианцев) мета - это не, мета-анализ, а мета-данные в начале заметки.

Зашёл сейчас в Discord Obsidian, вбил "meta note". В основном это сочетание используют для заметок, которые что-то обобщают. Для метаданных так и пишут metadata.

Это глупо. Что именно вы хотите найти? Что значит "заметка"?

Это была демонстрация того, что ctrl+o это не всегда хорошее решение.

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

Эту мысль я совсем не понял.

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

Вы немного не в тех категориях существуете. Есть понятие "sentence mining" (link, link).

Или мне надо на ежегодной основе интервальное-повторение всех слов делать?

Ежегодное? Чтобы через 100 лет язык выучить?)

Я бы вообще конспект от руки вёл.

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

И я это утверждаю даже при условии, что, наверное, сейчас в своём Obsidian смогу найти штук 40-60 исследований, что от руки писать эффективнее для памяти и понимания и что вообще все эти ноутбуки и доступ в сеть вредят обучению. Есть в этом даже своеобразная ирония.

Но зачем? Я практик, а не теоретик.

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

Если взять какого-нибудь рандомного инженера-физика из Intel и спросить его про какие-нибудь полупроводниковые законы, то с вероятностью 1.00 этот инженер вывалит из себя километры теории. И это на фоне того, что Intel – это не библиотека и не ВУЗ.

Но зачем?

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

В качестве доказательства вот вам мастер-класс. Я за 20 секунд создам вам простую, но эффективную систему. Засекайте:

Создаете два тега: #contact/personal, #contact/routine. Под персональными контактами делаете заметки с людьми, которых лично знаете и как-то с ними взаимодействуете. В рутину записываете самых лучших сантехников в вашем городе. Масштабируемость тоже предусмотрена. #contact/work. Под этим тегом у вас будут все деловые контакты. Для linux команд создайте заметку linux и в неё добавьте все вам нужные команды. Больше и не надо – документацию, если что почитаете.

Не влияет, потому что в отображении я и не вижу иерархии. Я вижу сортировку блоков.

Таак...

Health – это категория. Sleep и physical являются частью health. Sleep и physical отображаются раньше. Это происходит из той мысли, что узкий контекст зачастую информативнее. (По аналогии, например, с адресом чего-либо – чем больше в адресе информации, тем выше вероятность, что мы поймем, где объект находится).

Ну вот пример из music. В альбоме блоки идут: Production, Creator, Song. Если мы заменем порядок на Creator, Production, Song - визуально не будет никакой разницы.

Эммм... Вы читаете структуру сверху вниз. Если поменять местами Production и Creator, то вы сначала увидите Creator потом Production. В смысле визуально не будет никакой разницы? А это не разница? Или что вы вообще под визуальной разницей имеете в виду? Типа, когда у вас при перемене чего-то всё как новогодняя ёлка начинает светиться?

Вообще я же написал, что сами по себе иерархии между собой неупорядоченны. Есть только способ отобразить их порядок отображения на панели (этот порядок можно задать, например, на основе кругов, которые я в начале статьи написал). Под неупорядоченностью я имею в виду, что если вы где-то используете лишние или неправильные метаданные, то Breadcrumbs вам нигде за это по рукам не даст. В Obsidian есть, по-моему, всего один плагин (metadata menu), который позволяет задавать строгую систему для метаданных. И логичнее эти два плагина было бы использовать в комбинации – задаёте элементы (типы заметок), задаёте для них конкретные метаданные, по метаданным задаёте иерархии.

Тогда почему и не назвать это "Направление", или "Отрасаль", или "Предметная область". Слово категория - слишком абстрактное.

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

Так почему не назвать это источником?

Потому что #source/.... А ещё вы критикуете слова, а не их значение.

Я вместо production мог употребить слово арт-студия, киностудия, игровая студия, журнал, платформа, лейбл, организация, компания, паблишер. Суть бы от этого не изменилась.

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

В общем production потому что это наиболее общее слово.

Meta

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

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

Если выбирать, кхм, популярные слова, то category – это был бы класс или рубрика. Meta - предметная рубрика или ключевые слова. Production менялось бы в зависимости от контекста. Creator превратился в более жесткое "автор" или более общее держатель (потому что тот, кто является создателем/хранителем обычно являет держателем "документа"... но даже это неточно, ибо держателем может быть и какая-то более крупная структура).

Короче... Я ввёл понятие и определение, чтобы вы их вместе прочитали, а не по отдельности.

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

А их не надо упорядочивать. Тот же пример с сантехником - просто жмёшь Ctrl+O и пишеш "сантехник". Опять таки, эти быстрые факты должны быть полезные и потенциально нужные в будущем.

Я сейчас написал слово "заметка" и получил 682 выдачи.

Видимо не всегда ваша логика работает хорошо.

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

Отличный пример. Английский я учу с детства.

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

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

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

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

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

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

Для понимания системы, необходимо сначало прочитать и понять понятия.

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

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

Понятий 5, а это для мозга много.

А как же правило 7 плюс-минус 2?

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

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

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

Но вообще... А какая иерархичность для вас очевидна?

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

Забавно, но это не влияет на отображение.

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

В смысле не играет? Вы сами списки то прочитали?

Я использую Obsidian для хранения каких-то бытовых фактов (например номер и название фирмы хорошего сантехника), хранения часто используемых, но длинных команд для ubuntu, написания статей.

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

Если это было действительно значимое, оно отпечатывалось в голове, если не значимое, то и материал вероятно был бесполезен.

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

Не уверен, что она простая, но система такая

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

---

Я, наверное, объясню как бы я решил проблему с "длинными командами для ubuntu". Так вы вероятно поймете на сколько у нас разные подходы.

Я бы сначала прошёл курс по bash, потом нашёл бы и прочитал одну книгу по этой же теме. Далее я открыл бы Github и написал "Awesome bash". Добавил бы эту страницу как источник в Obsidian. Протыкал бы все ссылки на ней. Какие-то ресурсы я бы законспектировал в рамках "Awesome bash", а какие-то сделал бы отдельными источниками. Наиболее полезные вещи атомизировал и вынес бы в саму "Awesome bash" или в соответствующие источники.

Потом я бы создал иерархическую заметку и дал бы ей категорию "linux". В неё я бы стянул все атомные заметки с командами, которые нашёл в рамках курса, книги и "Awesome bash".

В итоге Breadcrumbs мне показал бы вот такую картину:

Breadcrumbs

Куда бы попала та самая длинная команда? Ну, с таким подходом она бы осталась просто в истории терминала, в которой я бы искал через fzf. Если бы я забыл, что делают отдельные части команды, то открыл бы Obsidian и посмотрел, что я написал по отдельным командам (заметку нашёл бы через поиск по названию, либо зашёл бы в "bash commands"). Если длинная команда была часто переиспользуемой и при этом уж совсем витиеватой, то я добавил бы её как заметку сначала в "bash commands". Потом, если появились бы другие более подходящие структуры, то переместил бы команду в неё.

Ну и сразу разовью пример дальше. Положим, что теперь мы будем решать какие-то проблемы безопасности. Логика будет такая же, но прошлые ресурсы по "bash" я теперь помечу одноименной метой.

Ресурсы по безопасности теперь вот так упорядочатся.

Breadcrumbs

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

Вот этот цикл из 3 статей мне показался более крутым и полезным: тут даже почти ни с чем спорить не хочется

Рад, что вам понравилось.

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

кроме того, что лайнер все же не синоним для текстовыделителя или хайлайтера, а отдельный вид канцелярии для проведения линий, он же линер

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

С "линерами" вы правы, но "лайнеры" благозвучнее, хах)

Салют)

Вы, конечно, немного промахнулись статьёй, но ничего страшного)

пусть ваша методика для меня и не совсем приемлема

Был бы рад, если вы расписали свою методику.

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

Согласен.

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

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

Согласен)

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

Ну, как бы ещё есть документация плагина и ютюб. Вам, видимо, просто любопытства не хватило.

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

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

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

Даже не смотря, на простые примеры типа музыки, кино и книг, всё равно сложно заходит.

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

Так-то всё, что я показал, можно раскидать на пару другую dataview-запросов. Если вы знаете как строить dataview-запросы, то понять отображение Breadcrumbs будет весьма просто.

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

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

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

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

Logseq

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

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

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

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

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

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

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

Для начала стоит отметить, что всё агрегирующее стоит перенести на 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.

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

```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. Это по сути значит, что сложность будет подконтрольно наращиваться только в одном месте, а не размазываться по всем периодическим заметкам. Ну, и как бы добавлять, менять и убирать метаданные намного проще, чем модифицировать (усложнять) шаблоны и переприменять их к заметкам.

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

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

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

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

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

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

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

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

Ну вы, в целом, просто переназвали классические 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'));
```

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да, всё так)

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

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

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

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

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

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

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

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

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

Салют)

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

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

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

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

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

Салют)

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

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

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

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

.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]]