Структуру хранения заметок PARA - Project, Areas, Resources, Archives. Она регламентирует верхний уровень и принцип классификации заметок/материалов (по Actionability).
Жизненный цикл заметок в хранилище CODE - Capture, Organize, Distill, Express.
Capture - всё в один инбокс
Organize - растаскивание инбокса по структуре
Distill - вычленение существенного, развитие мыслей
Express - адаптация материалов для целевой аудитории и публикация
Т.е. это про заметковедение (см. книгу Зонке Аренса "Как делать полезные заметки"), а не просто документооборот. У автора поста это в конце тоже отмечено как ценность, которую несёт репозиторий.
P.S. Хотел поделиться своим опытом на эту тему, но не буду оттягивать внимание читателей с поста автора :)
Как будто читаю мои наблюдения от вайб-кодинга, если бы я их задокументировал ;-)
В самом деле, если делаешь что-то новое, чего нет в паттернах обучающих данных, или просто по новой логике, чуждой LLM (поменял местами X и Y), то начинается лютая дичь, с которой сложно справляться. По крайней мере, раньше так было.
опыт общения с WD, QNAP подсказывал, что Synology и Terramaster примерно такая-же проприетарщина, работающая по правилу "как заплачено, так и ... работает".
У меня есть опыт только с Synology. Стоит дорого, работает хорошо. Так что не могу не согласиться 😁
Единственное требование: в пайплайне должна использоваться модель GigaChat Lite. Ваша цель: сделать так, чтобы память помогала давать семантически верные короткие ответы.
Просто форма маркетинга вместе с брейнсорсингом, ничего личного.
Как раз хотел добавить, что у PlantUML помимо описанных в статье прекрасных типов диаграмм есть довольно приятный на вид mindmap: https://plantuml.com/ru/mindmap-diagram
С небольшой стилизацией выглядит вообще волшебно. И писать просто - как многоуровневый список.
А так - диаграммы классов, последовательности и активности - самый топ.
Когда схемы большие, начинается шаманство с размещением элементов для повышения удобочитаемости, но это отдельная история.
Спасибо за объяснение и примеры, но в моей картине мира это выглядит по-другому.
RUG (Repeat Until Good) — это принцип, который говорит: улучшай код итеративно, пока он не станет достаточно хорошим для поставленных целей. Как прогрессивный JPEG.
То есть, наговнякай, чтобы работало хоть как-то, а потом доводи но нужного уровня хорошести.
Одновременно измененные MD через Obsidian git нормально мёрджатся, а вот если одновременно изменить canvas, тогда чуда не произойдет, и придется исправлять конфликт вручную. Это единственный недостаток командной работы над требованиями в Obsidian с синхронизацией через git, в остальном работает шикарно.
Вот тут подробнее про:
Структуру хранения заметок PARA - Project, Areas, Resources, Archives. Она регламентирует верхний уровень и принцип классификации заметок/материалов (по Actionability).
Жизненный цикл заметок в хранилище CODE - Capture, Organize, Distill, Express.
Capture - всё в один инбокс
Organize - растаскивание инбокса по структуре
Distill - вычленение существенного, развитие мыслей
Express - адаптация материалов для целевой аудитории и публикация
Т.е. это про заметковедение (см. книгу Зонке Аренса "Как делать полезные заметки"), а не просто документооборот. У автора поста это в конце тоже отмечено как ценность, которую несёт репозиторий.
P.S. Хотел поделиться своим опытом на эту тему, но не буду оттягивать внимание читателей с поста автора :)
Спасибо за описание, интересная система.
Напоминает заметочник на базе Markdown-файлов со структурой типа PARA и определённым процессом разбора инбокса.
Я пользуюсь Obsidian.md для подобного.
Как будто читаю мои наблюдения от вайб-кодинга, если бы я их задокументировал ;-)
В самом деле, если делаешь что-то новое, чего нет в паттернах обучающих данных, или просто по новой логике, чуждой LLM (поменял местами X и Y), то начинается лютая дичь, с которой сложно справляться. По крайней мере, раньше так было.
опыт общения с WD, QNAP подсказывал, что Synology и Terramaster примерно такая-же проприетарщина, работающая по правилу "как заплачено, так и ... работает".
У меня есть опыт только с Synology. Стоит дорого, работает хорошо. Так что не могу не согласиться 😁
Вечно актуальная тема. На днях перечитывал статью Дорофеева про это
Горячо поддерживаю всё написанное!
Но, как мне кажется, эти правила применяют не только ИТ-лиды, но и все люди, ценящие своё и чужое время и рационально его расходующие.
Просто форма маркетинга вместе с брейнсорсингом, ничего личного.
Спасибо!
Инструкции по созданию бота через botfather уже несколько утомили, но в общем статья полезная: увидел, как временно ограничивать пользователя.
Это, наверно, вопрос к комиссии и к процессу поддержки статуса «правильного» производителя
Во всем согласен с автором, только встречи не отклоняю. Поэтому на собственно работу остаётся часов 10 в неделю
И правда 😁
Есть же аналитики, лучше через них
Как раз хотел добавить, что у PlantUML помимо описанных в статье прекрасных типов диаграмм есть довольно приятный на вид mindmap: https://plantuml.com/ru/mindmap-diagram
С небольшой стилизацией выглядит вообще волшебно. И писать просто - как многоуровневый список.
А так - диаграммы классов, последовательности и активности - самый топ.
Когда схемы большие, начинается шаманство с размещением элементов для повышения удобочитаемости, но это отдельная история.
В прошлом году выступал на Flowconf с темой AsyncAPI: https://m.vk.com/video-214741188_456239297
Поздравляю, вы изобрели заметки и рабочий журнал! 🎉🎉🎉
Да. Но из вашего объяснения в посте это следует очень неявно.
Причина кмк в неправильном переводе расшифровки термина на русский язык.
Until перевели как while, хотя это противоположности.
Спасибо за объяснение и примеры, но в моей картине мира это выглядит по-другому.
RUG (Repeat Until Good) — это принцип, который говорит: улучшай код итеративно, пока он не станет достаточно хорошим для поставленных целей. Как прогрессивный JPEG.
То есть, наговнякай, чтобы работало хоть как-то, а потом доводи но нужного уровня хорошести.
В моей реализации по ссылке в первом комменте идентификаторы требований семантические - от общего к частному через точку.
Это даёт дополнительные возможности поиска и связи требований, ну и в принципе удобно.
P.S. MD - это Markdown, как верно отметили выше. Прошу прощения, что непонятно высказался. Думал, что в контексте Obsidian будет понятно.
Грамотное управление требованиями - залог хорошего продукта.
Я тоже делал систему управления требованиями для команды аналитиков, и тоже в Obsidian 😀
https://github.com/dimonier/Obsidian-Requirements-Management
Одновременно измененные MD через Obsidian git нормально мёрджатся, а вот если одновременно изменить canvas, тогда чуда не произойдет, и придется исправлять конфликт вручную. Это единственный недостаток командной работы над требованиями в Obsidian с синхронизацией через git, в остальном работает шикарно.
Спасибо, получилось установить из dist.
Переводит прекрасно :)
Как бы ещё сделать кнопку для перевода страницы целиком (а не только выделенного элемента)?
Так уж и все? Я не юзаю. Автор, видимо, тоже.