Прочитал комменты выше. Люди, вы хоть пробовали использовать этот продукт, прежде чем ругать его?
За один вечер встроил предыдущую версию Tesseract в личного бота-секретаря, теперь отправляемые боту картинки сохраняются вместе с рассказанным текстом - красота.
Ваше увлечение системой Zettelkasten и использованием Obsidian действительно вдохновляет, и вы уже сделали значительные шаги в организации своих знаний. Однако, как и в любой методологии, есть аспекты, которые могут быть не до конца раскрыты или поняты.
Гибкость и адаптация: Вы упомянули, что адаптировали метод Zettelkasten под свои нужды, что является важным шагом. Однако, стоит помнить, что чрезмерная адаптация может привести к потере ключевых преимуществ метода, таких как модульность и возможность легкого поиска связей между идеями. Возможно, стоит пересмотреть, какие элементы оригинальной системы можно сохранить для улучшения связности.
Качество против количества: Вы гордитесь тем, что у вас более 1000 заметок, но важно помнить, что качество заметок и их взаимосвязи зачастую важнее их количества. Попробуйте сосредоточиться на создании более глубоких и содержательных связей между заметками, что может привести к более значимым инсайтам.
Критическое мышление и анализ: Ваша статья в основном фокусируется на технических аспектах использования Zettelkasten и Obsidian. Однако, стоит уделить внимание развитию критического мышления и аналитических навыков, которые помогут вам не только собирать информацию, но и оценивать её значимость и применимость в различных контекстах.
Заблуждения о "втором мозге": Хотя Zettelkasten действительно может помочь в организации знаний, важно не переоценивать его возможности. Система не заменит критическое мышление и личный опыт, которые необходимы для глубокого понимания и творчества.
Эмоциональная составляющая: Ведение заметок — это не только технический процесс, но и эмоциональный. Попробуйте интегрировать в свои заметки элементы, которые вдохновляют и мотивируют вас, будь то цитаты, личные размышления или визуальные элементы.
Ваш путь с Zettelkasten — это замечательное начало, и я уверен, что с учетом этих аспектов вы сможете еще больше углубить свои знания и улучшить свою систему. Удачи вам в этом увлекательном путешествии!
Предположим, у нас есть объект, который может быть либо человеком с именем и возрастом, либо автомобилем с маркой и моделью. Мы можем использовать anyOf, чтобы разрешить объекту быть либо человеком, либо автомобилем, либо даже содержать атрибуты обоих, если это необходимо.
В этом примере объект будет валидным, если он является либо человеком (с именем и возрастом), либо автомобилем (с маркой и моделью), либо даже если он содержит все четыре атрибута.
oneOf:
Теперь рассмотрим тот же сценарий, но с использованием oneOf. Здесь объект должен быть либо человеком, либо автомобилем, но не может быть обоими одновременно.
В этом случае объект будет валидным, если он является либо человеком, либо автомобилем, но не может содержать атрибуты обоих. Если объект содержит атрибуты и человека, и автомобиля, он не будет соответствовать oneOf, так как это нарушает условие соответствия только одной из схем.
Таким образом, anyOf позволяет объекту соответствовать нескольким схемам одновременно, тогда как oneOf требует, чтобы объект соответствовал только одной из указанных схем.
В спецификации OpenAPI схемы сущностей описываются в формате JSON Schema. По крайней мере, на первый взгляд так. Соответственно, если проектируете REST API, то автоматически пользуетесь JSON Schema.
Сборка стационарника, сегодня, оправдана только в случае игр и серьезного, тяжёлого софта.
Ну как "только".... Ради экономии ещё можно. Я вот года 4 назад собрал десктоп на базе старого 16-поточного Xeon с 32ГБ чисто посмотреть, что это такое. До сих пор работает. Пару лет назад, когда начал эксперименты с "ИИ", добавил GPU - опять же, старую - RTX 1080Ti.
Так и работаю на этом "десктопе". Производительность на высоте, редко удаётся нагрузить на 100%. Соотношение цена/качество - невероятное. Единственное, чего иногда не хватает - это USB 3.0. Но цена и производительность оправдывают этот недостаток.
Спасибо за обзор инструментов и описание практики их использования!
Добавлю, что для обработки аудио/видео хорош ffmpeg, а как локальный редактор Markdown вместе с mermaid.js, plantuml и прекрасным редактором ужасных Markdown-таблиц - Obsidian.
Требование - это первоисточник. US с мокапами - это вариант реализации требований, т.е. уже следующий шаг. Пропустить этап разработки требований и сразу перейти к User Story - соблазнительно, но когда через N времени возникнет вопрос "какую проблему решали этой историей", ответа можно и не найти.
Некоторые работают с коучами, которые отвечают на подобные вопросы. Другим помогают книги, в которых автор подробно описывает пошаговый план. Ещё есть группы развития (кайдзен-группы), где люди советуются в узком кругу. Есть большие сообщества, в которых люди "растут" и помогают расти другим. Наверняка есть и другие варианты. "У желания тысяча возможностей" (с). А ещё "Учитель приходит, когда ученик готов" (c) ?
Либо можно использовать любой удобный бесплатный вариант бесплатной синхронизации файлов. Один из самых популярных - Syncthing. В русскоязычном телеграм-чате по Obsidian уже по сто раз все варианты обсудили.
Прочитал комменты выше. Люди, вы хоть пробовали использовать этот продукт, прежде чем ругать его?
За один вечер встроил предыдущую версию Tesseract в личного бота-секретаря, теперь отправляемые боту картинки сохраняются вместе с рассказанным текстом - красота.
Ваше увлечение системой Zettelkasten и использованием Obsidian действительно вдохновляет, и вы уже сделали значительные шаги в организации своих знаний. Однако, как и в любой методологии, есть аспекты, которые могут быть не до конца раскрыты или поняты.
Гибкость и адаптация: Вы упомянули, что адаптировали метод Zettelkasten под свои нужды, что является важным шагом. Однако, стоит помнить, что чрезмерная адаптация может привести к потере ключевых преимуществ метода, таких как модульность и возможность легкого поиска связей между идеями. Возможно, стоит пересмотреть, какие элементы оригинальной системы можно сохранить для улучшения связности.
Качество против количества: Вы гордитесь тем, что у вас более 1000 заметок, но важно помнить, что качество заметок и их взаимосвязи зачастую важнее их количества. Попробуйте сосредоточиться на создании более глубоких и содержательных связей между заметками, что может привести к более значимым инсайтам.
Критическое мышление и анализ: Ваша статья в основном фокусируется на технических аспектах использования Zettelkasten и Obsidian. Однако, стоит уделить внимание развитию критического мышления и аналитических навыков, которые помогут вам не только собирать информацию, но и оценивать её значимость и применимость в различных контекстах.
Заблуждения о "втором мозге": Хотя Zettelkasten действительно может помочь в организации знаний, важно не переоценивать его возможности. Система не заменит критическое мышление и личный опыт, которые необходимы для глубокого понимания и творчества.
Эмоциональная составляющая: Ведение заметок — это не только технический процесс, но и эмоциональный. Попробуйте интегрировать в свои заметки элементы, которые вдохновляют и мотивируют вас, будь то цитаты, личные размышления или визуальные элементы.
Ваш путь с Zettelkasten — это замечательное начало, и я уверен, что с учетом этих аспектов вы сможете еще больше углубить свои знания и улучшить свою систему. Удачи вам в этом увлекательном путешествии!
anyOf:Предположим, у нас есть объект, который может быть либо человеком с именем и возрастом, либо автомобилем с маркой и моделью. Мы можем использовать
anyOf, чтобы разрешить объекту быть либо человеком, либо автомобилем, либо даже содержать атрибуты обоих, если это необходимо.В этом примере объект будет валидным, если он является либо человеком (с именем и возрастом), либо автомобилем (с маркой и моделью), либо даже если он содержит все четыре атрибута.
oneOf:Теперь рассмотрим тот же сценарий, но с использованием
oneOf. Здесь объект должен быть либо человеком, либо автомобилем, но не может быть обоими одновременно.В этом случае объект будет валидным, если он является либо человеком, либо автомобилем, но не может содержать атрибуты обоих. Если объект содержит атрибуты и человека, и автомобиля, он не будет соответствовать
oneOf, так как это нарушает условие соответствия только одной из схем.Таким образом,
anyOfпозволяет объекту соответствовать нескольким схемам одновременно, тогда какoneOfтребует, чтобы объект соответствовал только одной из указанных схем.В спецификации OpenAPI схемы сущностей описываются в формате JSON Schema. По крайней мере, на первый взгляд так. Соответственно, если проектируете REST API, то автоматически пользуетесь JSON Schema.
Тоже в одной компании сделал базу знаний на Mediawiki + Semantic Mediawiki. Норм решение, но по современным меркам UX так себе
Ну как "только".... Ради экономии ещё можно.
Я вот года 4 назад собрал десктоп на базе старого 16-поточного Xeon с 32ГБ чисто посмотреть, что это такое. До сих пор работает.
Пару лет назад, когда начал эксперименты с "ИИ", добавил GPU - опять же, старую - RTX 1080Ti.
Так и работаю на этом "десктопе". Производительность на высоте, редко удаётся нагрузить на 100%. Соотношение цена/качество - невероятное. Единственное, чего иногда не хватает - это USB 3.0. Но цена и производительность оправдывают этот недостаток.
Ой, ну недели уже не проходит, чтобы кто-нибудь не рассказал нам (снова) про Обсидиан :-D
Спасибо за привлечение внимания к нему!
Вот русскоязычное сообщество Obsidian: https://t.me/obsidian_z
Спасибо за обзор инструментов и описание практики их использования!
Добавлю, что для обработки аудио/видео хорош ffmpeg, а как локальный редактор Markdown вместе с mermaid.js, plantuml и прекрасным редактором ужасных Markdown-таблиц - Obsidian.
Как в остальных подобных статьях - шкаф с заметками Лумана пнули, граф Обсидиана показали, несколько других заметочников назвали - зачот!
Спасибо за привлечение внимания к теме! 😀
Генерации простыни на Markdown из спецификации OpenAPI:
npx widdershins specification.yml -o specification.md --expandBody --omitBody --code --summaryЕсли нужен HTML, то потом:
pandoc specification.md -o specification.htmlПредварительно нужно установить npm с widdershins:
npm install -g widdershinsи pandoc:и pandoc
А Swagger UI не можете показать? Кмк там интерфейс поудобнее будет, чем "таблица".
Из спеки OpenAPI можно сделать таблицу. А вот обратно - фиг.
Требование - это первоисточник. US с мокапами - это вариант реализации требований, т.е. уже следующий шаг.
Пропустить этап разработки требований и сразу перейти к User Story - соблазнительно, но когда через N времени возникнет вопрос "какую проблему решали этой историей", ответа можно и не найти.
Спасибо, отличная статья!
Добавить ещё команды return и autoactivate, и будет совсем красиво
Ну вообще-то есть рецепты и методики.
Просто к этому нужно быть готовым, и нужно делать (а не просто знать, что делать). Тогда получается.
Некоторые работают с коучами, которые отвечают на подобные вопросы.
Другим помогают книги, в которых автор подробно описывает пошаговый план.
Ещё есть группы развития (кайдзен-группы), где люди советуются в узком кругу.
Есть большие сообщества, в которых люди "растут" и помогают расти другим.
Наверняка есть и другие варианты.
"У желания тысяча возможностей" (с). А ещё "Учитель приходит, когда ученик готов" (c)
?
Спасибо за статью!
До таблиц с примерами было понятно. Примеры непонятные.
Где упоминание Stepmania? Без неё тема раскрыта не до конца
Есть встроенная платная синхронизация.
Либо можно использовать любой удобный бесплатный вариант бесплатной синхронизации файлов. Один из самых популярных - Syncthing. В русскоязычном телеграм-чате по Obsidian уже по сто раз все варианты обсудили.
Спасибо за то, что подняли актуальную тему!
Иной раз в самом деле непонятно, кто что должен делать, потому что написано, что все как будет делается само.
Хорошо, если отдельно описано, кто что делает. Но часто нет, и пригодится играть в угадайку,