Миграция с Notion на Obsidian

С 9 сентября Notion пока-пока ❌
Эх, а хорошо дружили. Я к нему прям прикипел. Построил себе приличную базу знаний с задачами, проектами, библиотекой и прочей писаниной. Теперь надо переезжать. И все знаки указали переезжать на Obsidian.

В Obsidian есть все для миграции. Экспортируем воркспейс Notion и импортируем его в Obsidian. С одной стороны, все выглядит просто. Особенно если в воркспейсе не было сложных структур. С другой стороны, есть особенности. Поговорим о них.

1️⃣ Obsidian культивирует немного другую структурную концепцию: файлы с тегами против табличной организации в Notion. Главная проблема - жёсткие свойства-теги (tags). На tags завязано много функциональности Obsidian. Но в Notion у меня свойства-теги были под другими именами. С помощью поиска/замены VSCode я эти свойства переименовал и всё встало на свои места.

2️⃣ Obsidian в отличие от Notion не поддерживает теги с пробелами. Пришлось также с помощью поиска/замены VSCode дописать в тегах нижние подчеркивания вместо пробелов.

3️⃣ Kanban-доски я организовал через плагин Projects. Получается очень похоже на Notion. Этот же плагин может формировать списки, таблицы и календари. Всё интерактивное, поддерживается фильтрация.

4️⃣ Там, где нужно сформировать из файлов простую таблицу с фильтрацией по тегам и свойствам, подойдет плагин Dataview. С помощью языка запросов можно создавать разные представления.

5️⃣ Календарь и уведомления событий в Obsidian я организовал с интеграцией Google-календаря через соответствующий плагин. Это личное предпочтение, я Google-календарём пользовался и до этого. К тому же к событиям календаря можно привязывать заметки Obsidian.

6️⃣ Синхронизацию между устройствами сделал через Яндекс-диск. Для этого хранилище Obsidian размещается в локальной папке Яндекс-диска, а клиент диска синхронизирует его с облаком. На остальных устройствах делается то же самое. На ПК работает отлично. На мобильном похуже.

В общем, переехать реально 👍
За несколько вечеров мне удалось привести в относительно рабочее состояние базу из более чем 2-х тысяч элементов. Буду осваивать Obsidian дальше, по ключевым моментам отпишусь.

Кто-нибудь уже работает с Obsidian? Посоветуете что-то?

Troubleshooting

Траблшутингом мы занимаемся каждый день. Баг такой, баг сякой. Мы либо исправляем баг, либо создаем его 🐞👋 (не специально, конечно). Но в наших интересах сводить наши проблемы к минимуму.

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

1. Не пессимизируйте преждевременно. Что бы вы тут не подумали, это значит "делайте сразу хорошо". Простой пример: если нужно использовать число 42, то определите его именованной константой, а не оставляйте болтаться "голым". Для любой технологии сообщество предлагает лучшие практики, безопасные подходы и прочие гайд-лайны. Время от времени посматривайте в подобные руководства, официальные или нет, и вы не заметите как начнете применять эти подходы автоматически.

2. Работайте с предупреждениями компилятора (или что у вас там). В пределе их не должно быть совсем. Игнорируя предупреждения, мы... См. пункт 1... Правильно, пессимизируем.

3. Используйте статические анализаторы. Это отличное усиление компилятора (или что у вас там). Множество проверок, в том числе проверок безопасности, поможет выявить косяки на раннем этапе.

Когда проблема зарегистрирована, но ее решение не очевидно, мы можем прибегать к пунктам 2 и 3. Проверьте, что включен максимальный уровень проверок компилятора (или что у вас там), а также ещё раз прогоните проблемные исходники через анализаторы. Есть шанс, что источник проблемы будет найден ✅

Кто знает, какие еще есть способы предупреждать проблемы?

#Troubleshooting

Что может быть дороже бага в требованиях?

⌛

Правильно, баг в постановке цели!

Идем по пути от “так себе” вчера к “немного лучше” сегодня.

Авторский образовательный контент по неустанной борьбе с так себе программистом.

Даже рубрики есть:

#КнижнаяПолка 📚
О книгах. Полезно мне - полезно вам 😉

#ЖизньДругих 👀
Об интересных решениях в открытых проектах.

#Словарь 📕
О сложной и запутанной терминологии в формате конфликта.

Когда захотелось ну очень тёмную тему 🌘

Отсюда

Troubleshooting. Метод деления пополам

Продолжаю серию постов по траблшутингу. Сегодня поговорим про локализацию проблемы методом деления пополам.

Метод деления пополам используется, например, в электротехнике ⚡️ для поиска обрыва в цепи. Для этого участок цепи визуально разбивается пополам и каждая половина проверяется на предмет наличия тока. Та половина, в которой тока нет, считается содержащей обрыв. Она в свою очередь снова разбивается пополам и половинки снова проверяются. Так продолжается до тех пор, пока мы не придём к проблемному месту.
А мы придём к нему в общем случае быстрее, чем если бы последовательно проверяли цепь по маленьким "кусочкам".

Вот такой итерационный метод можно использовать и при отладке программ.

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

1️⃣ Для начала выбираем большой участок программы от ее старта до места проявления ошибки. Мы уверены, что в начале выполнения программы наши данные корректные.

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

3️⃣ Продолжаем пункт 2 до тех пор, пока не "спустимся" к источнику проблемы.

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

Для этого нужно знать коммит, на котором проблемы еще не было, и коммит, на котором проблема была обнаружена. Тогда путем деления истории коммитов пополам можно быстро найти коммит, который занёс в код ошибку. В git, например, этот метод реализуется командой git bisect. Почитайте, если ещё не слышали.

#Troubleshooting