Заметки

Возможно, вы понимаете как писать хороший код, как придерживаться хорошего дизайна. Но структурировать эти знания не получается. Книга Джона Оустерхаута A philosophy of software design может помочь исправить это.

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

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

О чем книга

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

Он выделяет 2 пути борьбы со сложностью:

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

Далее я буду использовать термин Модуль. Модулем может быть класс, функция, внешнее API и т.д. В том же значении этот термин использует автор книги.

Что такое сложность

Чтобы бороться со сложностью, нужно хорошо прояснить для себя, а что же это такое.
Симптомы сложности:

1. Небольшие правки в функциональности требуют изменений кода во многих местах.
2. Большая когнитивная сложность. Разработчику приходится изучить большое количество информации и держать многое в памяти, чтобы понять, как работает код.
3. Не очевидно, что необходимо менять в коде, чтобы изменить функционал.

Главные причины сложности:

1. Большое количество зависимостей
2. Неочевидные вещи в коде:
   
   • Общие названия переменных
   • несколько целей у переменных
   • плохая документация
   • неочевидные зависимости (или утечка зависимостей)

Ещё важно отметить, что сложность имеет свойство накапливаться. Мы не замечаем, как сложность кода повышается. Когда мы откладываем рефакторинг кода или не заботимся о его дизайне, незаметно для себя можем прийти в такое состояние, когда код ужасно сложный и очень тяжело добавить новые фичи.

По этой причине автор выделяет 2 подхода программирования, он называет их:

• тактическое
• стратегическое

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

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

Стратегическое программирование мы ищем лучшее решение, рассматривая несколько вариантов. Оно состоит из двух условий:

1. проактивности мы учитываем изменения и потребности в будущем и думаем о документации и понятности кода.
2. реактивности исправляем очевидные проблемы в старом коде, а не только пишем новый.

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

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

Автор предлагает тратить 20% своего времени на исправление старого кода, иначе сложность будет копиться, его понимание будет занимать много времени.

Модули должны быть глубокими

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

Поэтому, чем проще интерфейс у используемых модулей, тем проще с ними работать. Чем больше методов, аргументов и нюансов использования имеет модуль, тем сложнее его интерфейс.

Интерфейс может быть:

1. Формальный это сигнатура, публичные методы, свойства класса и т.д.
2. Неформальный комментарии к модулю, нюансы работы.

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

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

Если ваш модуль очень маленький, то скорее всего интерфейс этого модуля больше, чем его функционал.

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

Утечка информации

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

• Интерфейс
• Через back-door. Знания не описанные в интерфейсе, например, когда о формате файла знают несколько классов, хотя для она важна только для одного. Такая утечка гораздо хуже утечки через интерфейс.
  При обнаружении утечки, следует ответить на вопрос Как изменить модули, чтобы знание влияло только на 1 класс?. Возможно модули стоит объединить в один или вынести информацию наружу и обернуть её в более высокоуровневый модуль.

Временная декомпозиция

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

Общецелевые модули

Это модули с заделом на будущее, с возможностью использовать где-то ещё.

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

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

Вопросы, которые помогут создать общецелевой интерфейс:

1. Какой самый простой интерфейс покроет все мои нужды?
2. В скольких ситуациях этот метод будет использован? Если только в одной, то скорее всего вы делаете интерфейс неправильно.
3. Насколько легко использовать интерфейс в данный момент?

Разные слои, разные абстракции

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

Какие проблемы на разных слоях абстракции могут возникать:

• Прокинутые методы когда результат выполнения метода просто прокидывается на более высокий уровень, без каких либо обработок. Такой случай, как правило, только усложняет код. Проблема здесь в том, что ответственности разных классов пересекаются.
  Исключением являются методы диспетчеры, которые отвечают за выбор нужного метода для вызова.
  Также, декораторы используют проброшенные методы. Поэтому их стоит использовать осторожно и только в крайнем случае.
• Прокинутые переменные когда переменные прокидываются вглубь к более низкоуровневым классам без обработок. В такой ситуации возникают следующие проблемы:
  создается зависимость и никак не используется в промежуточных слоях
  требуется изменения множества методов и заставляет усложнить интерфейс каждого.
  Лучшее решения для такой ситуации это использовать DI контейнер. Это не идеальное решение, оно может привести к неочевидным зависимостям, поэтому его следует использовать осторожно. Для того чтобы избежать многих проблем, переменные в контейнере можно делать неизменяемыми (immutable).

Старайтесь не перекладывать ответственность на верхний уровень

Не перекладываете ответственность на пользователей данного модуля насколько это возможно. Решайте как можно больше проблем внутри. (Пользователь это не только человек, но и высокоуровневый модуль, который использует модуль).
Например, мы можем дать возможность настроить параметры модуля снаружи. Но может оказаться такая ситуация, когда параметры окажутся несовместимы, и эту проблему придется решать пользователю. Сначала стоит подумать, возможно ли определить эти параметры автоматически внутри.
Модуль должен выполнять свои обязанности до конца. В конце разработки модуля следует сделать дополнительные усилия и подумать, есть ли возможность скрыть лишние знания от пользователя.

Разделить или объединить

Для улучшения дизайна кода, часто, необходимо либо разделить модуль на несколько, либо наоборот объединить с другим. Чтобы понять, стоит ли объединять, рассмотрим признаки для объединения:

1. Модули обращаются к общей информации.
2. Используются совместно. Один нельзя использовать без другого.
3. Решают общую задачу.
4. Тяжело понять одну часть кода без другой.
5. Если после объединения интерфейс упростится.

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

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

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

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

Работа с исключениями

Здесь под исключением понимаются не только exception которые выкидываются в коде. Это любые ситуации, которые вызывают необычное поведение системы. Когда что-то происходит не так, как задумывалось.

Исключения добавляют сложность в интерфейсе потому что:

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

Исключение это тоже часть интерфейса. Чем больше исключений у интерфейса, тем он сложнее.

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

Способы скрыть исключение:

1. Игнорировать исключение. Принять его за нормальное поведение.
2. Обработать внутри модуля, не выбрасывая его внаружу.
3. Обработать множество исключений в одном обработчике, прокидывая через несколько уровней вверх и обработав в одном месте.
4. Просто прервать программу с ошибкой, когда обрабатывать её бесполезно.

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

Проектируй дважды

Не стоит реализовывать первую пришедшую идею. Стоит рассмотреть несколько вариантов. Это позволит сэкономить время на переписывании кода.

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

Стоит подумать о том:

• какой из них проще
• является ли вариант более переиспользуемым
• будет ли реализация более производительной

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

Рассмотрение вариантов не должно отнимать много времени, в среднем 1-2 часа. Чем более важный и крупным модуль мы хотим разрабатывать, тем больше времени на обдумывание мы можем потратить.

Зачем писать комментарии

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

1. Хороший код самодокументируемый. Этот подход ошибочный, потому что:
   
   • В коде нельзя дать высокоуровневое описание того, что делает метод или причину того, или иного решения в реализации.
   • Если пытаться упростить реализацию для легкого понимания, то придется разбивать модуль так, что это может усложнить его интерфейс.
   • Если пользователь читает всю реализацию, то ему приходится читать не только важную информацию, но и не важную, из-за чего теряется смысл в абстракции.
   • Некоторые нюансы передаваемых аргументов и свойств нельзя описать в коде.
2. Нет времени писать комментарии. Отсутствие комментариев вынудит потратить дополнительное время на понимание кода в будущем, из-за чего оно будет потрачено в ещё большем объеме.
3. Комментарии устаревают и вводят в заблуждение. На самом деле поддержка правильно написанных комментариев не занимает много времени. Это потребуется только если происходят большие изменения в коде.

Главная идея в написании комментариев записать важные мысли разработчика, которые нельзя описать в коде. Это позволит избежать ошибок, на которые попадется разработчик после него. Будут понятны намерения автора. Также это понизит когнитивную сложность.

Как писать комментарии

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

Я просто перечислю ряд важных советов которые дает автор.

Хороший прием использовать другие слова в комментарии чем в коде.

Описывая переменные, думайте существительными, а не глаголами.

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

Цель комментариев в реализации дать понимание, что делает код (не как он это делает). Они нужны только для больших и сложных реализаций. Для простой реализации комментарий не нужен. Если разработчик поймет, что делает код, ему будет гораздо легче понять сам код.
Также бывает так, что общая логика размазана по нескольким модулям, например отправка и получение http запроса. Комментировать это трудно, поскольку дублировать комментарии нежелательно.

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

Комментарии лучше писать вначале

Какие выгоды это дает:

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

Именование переменных

Именование это одна из форм документирования.
Правильное именование позволяет:

• легче находить ошибки
• уменьшает сложность
• уменьшает необходимость в комментариях

Имя должно быть:

• Не слишком общим, например count. Если трудно подобрать полноценное имя, то это признак того, что вы делаете что-то не так. Возможно переменная имеет слишком много назначений. Лучше разбить её на несколько.
• Консистентным, т.е. такое имя должно использоваться в других местах с таким же назначением, и не использоваться другое имя для такого же назначения.

Консистентность кода

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

• наименованиях
• стиле кода
• интерфейсе
• в паттернах (например MVC улучшает консистентность)

Консистентность дает:

• Быстрое понимание того как работает код, если вы уже знакомы с похожими местами.
• Уменьшает ошибки. Если похожие места сделаны по разному, то разработчику легче ошибиться, подумав, что здесь также.

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

• Документации
• Линтеров и других инструментов, не позволяющих пушить код, не соответствующий принятым стандартам.
• При изменении кода смотреть, как сделано сейчас.

Старайтесь не менять существующие договоренности, ценность от консистентности может быть выше, чем улучшения, которые предлагается ввести. Перед вводом неконсистентности дайте ответ на 2 вопроса:

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

Если ответ на любой вопрос да, то тогда можно нарушить консистентность.

Тренды в разработке ПО

Наследование в ООП

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

Agile

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

Unit тесты

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

TDD

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

Паттерны

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

Геттеры и сеттеры

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

Заключение от меня

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

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

Zettelkasten крутой метод хранения идей и знаний сейчас на слуху, дошел и до Хабра. Я веду такой в Notion уже год, потому что Notion лучше всех воплощает три главных принципа Zettelkasten: взаимосвязанность, категоризацию, актуальность. Метод улучшил качество моего обучения и исследований, и без него как-то уже не так.

Я почитал русскоязычные и англоязычные ресурсы и не нашел ни нормального шаблона для Notion, ни объяснения как реализовать главные преимущества метода Zettelkasten. Под катом и то, и другое.

Дисклеймер: ни Notion, ни автор метода мне за статью не платили.

Что такое этот ваш Цеттелькастен?

Это метод хранения и систематизации идей, знаний, источников и чего душе угодно. Zettelkasten социолога Никласа Лумана помог ему написать более 70 книг и 400 статей, при том что вел он Zettelkasten на бумаге, а писал не детективы, а книги и работы по социологии. Обязательно прочитайте перевод на Хабре о преимуществах метода.


Так выглядели карточки самого Никласа. Взято из блога Eugene Yan

Мой Zettelkasten выглядит как на картинке в начале статьи, но внешность обманчива Zettelkasten может выглядеть как угодно, и в этом его преимущество. Для этого поста я взял донором мои весенние заметки по Java, поэтому не удивляйтесь специфичности скринов.

Для меня, Zettelkasten базируется на трех главных принципах.

Взаимосвязанность

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

Категоризация и иерархия

Взаимосвязанность обеспечивает то, что все заметки в Zettelkasten связаны. И не только по признаку темы, категории или по тэгам, но и между собой, в иерархии и без нее. Я веду длинные цепочки по мере чтения книги и сортирую данные по темам. Например, вот мои заметки по дженерикам в Java.

Актуальность

Так как вам придется проставлять ассоциации, категории и тэги, Zettelkasten стимулирует вспоминать взаимосвязанные между собой вещи. По моему опыту, это и есть тот момент, когда рождаются новые идеи, а еще и тренируется память.

Еще в Zettelkasten легко искать ответы на вопросы, особенно если его откармливали годами, и теперь он толстый и мудрый.

Мои цели и опыт

Я завел Zettelkasten чтобы учить программирование эффективнее: вести конспекты так, чтобы было легко находить снова и не приходилось перегугливать свои вопросы. Со временем я осознал мощь метода и стал использовать его для всего: своей книги, случайных идей, исследований по работе.

Смешивание помогло: тут же нашлись связи между разными дисциплинами и темами, а еще я я перестал забывать, почему же LinkedHasList был столь важен для меня два месяца назад (чтобы реализовать порядок ходов в настольной игре). Из идей ничего больше не теряется, а значит не приходится изобретать их заново. Это экономит ресурсы мозга, а так как мозг потребляет много калорий, то можно сэкономить и на еде. Полезно в эти темные дни.

Как завести Zettelkasten в Notion?

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

База данных основа основ

Это сердце Zettelkasten и основа всех преимуществ Notion: без неё можно также реализовать метод в Блокноте. Создается она просто: (1) создается пустая страница, а затем (2) выбирается тип базы данных.

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

Настройка атрибутов карточек

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

Минимальным набором для полной реализации Zettelkasten являются:

1. Тэги: неограниченное количество тематических меток. Когда будете вводить тэг, Notion предложит существующие или сразу создаст новый, поэтому даже с телефона удобно их добавлять.
   
   
   
   
   Не нужно пытаться продумать сразу все тэги. Просто добавляйте по мере пользования, и пытайтесь добавлять только такие, которые будете переиспользовать. Я пытался создать себе набор тэгов на старте, и в итоге пришлось удалять неиспользуемые.
2. Категории: основная тематическая принадлежность заметки. Я выявил на деле, что хотя тэговая, мелкая тема может повторяться (например, math), большинство заметок принадлежат к категорической, большой теме (например, Java). Иногда заметка может менять категорию, например повышаться из Идей в Посты.
   
   
   
   
   
3. Связи. Для этого нужно выбрать продвинутый атрибут Relation (1), выбрать ваш Zettekasten из списка баз данных, а затем выбрать вариант Create a new property: Sync both ways (2). Таким образом, взаимосвязанные карточки будут автоматически генерировать ссылки друг на друга.
   
   
   
   
   
   
   
   

На этом создание закончено и надо работать

Да, Zettelkasten уже готов к бою. Но история только начинается.

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

Например, у меня появился атрибут URL, потому что я пользовался клиппером Notion для сохранения целых статей прямо в Zettelkasten и хотел хранить ссылки на источники. Полезно при работе с академическими журналами по подписке, если вы почему-то не научный пират.

По мере наполнения Zettelkasten, его мощь и полезность будут расти. Для меня первый момент X настал спустя две недели, когда вместо перегугливания процесса создания файла в Java я нашел его в Цеттеле. А второй когда я конспектировал Троцкого и сумел связать его идеи автономной революционности масс с карнавалом Бахтина. Теперь открытия и находки происходят каждый день.

Особенности и преимущества Zettelkasten в Notion

Тут и начинается самая важная часть поста. Оказалось, что даже секундные тормоза забивают гвозди в гроб моей любви к заметкам, и пришлось оптимизировать работу с Zettelkasten. Поэтому эта история об эффективном использовании Notion и убыстрении процесса.

Как пользоваться связями карточек?

Каждый раз, когда вы добавляете одну карточку к другой, в поле Related можно вводить нужный термин, например Boolean. Notion сразу подыщет их в вашем Zettelkasten. А можно выбрать руками.


Потом детей отдельной идеи можно увидеть в авто-генерированном аттрибуте карточки.

Это работает в обе стороны: можно кликнуть на авто-аттрибут и сделать карточку ребенком вручную.

Как создавать виды на записи?

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

Вид Zettelkasten можно создать с помощью переключателя вида сверху (1). Я пользуюсь, в основном, галереями (это вид карточек) и списками.


Можно иметь несколько видов одного типа: вид это не только стиль выкладки, но и видимые атрибуты, фильтры, сортировка и все ваши настройки. Через меню Properties (2) в виде Галерея можно:

• Настроить порядок показа атрибутов (например, показывать имя карточки внизу)
• Изменить размер и что будет показываться на превью.
• Включать и выключать отображение атрибутов

Как создавать каталоги?

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

В Notion есть блок Связанная база данных (Linked database), которая создаёт проекцию данных из основной базы на отдельную страницу. Связанную базу данных можно создать на отдельной странице и выбрать для неё свои виды. Она будет синхронизироваться с главной, и наоборот.


Теперь следите за руками:

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

Получилась архикарточка, прямо как у автора метода Лумана. Для них у меня отдельная категория. Вот, например, мой каталог на тему объектно-ориентированного программирования и полиморфизма.


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

Как ускорить ввод данных в больших базах?

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

Я создал отдельную страницу для ввода, вставил в неё связанную базу и отфильтровал её так, чтобы показывались только добавленные сегодня карточки. Она загружается мгновенно с телефона и ПК.


Для пущей скорости я создал для неё ярлык в Chrome и закрепил на панели задач. Для этого надо через настройки Chrome выбрать More tools Create Shortcut. Не забудьте проставить Open as window в диалоговом окне.

Как искать данные?

Это большой провал Notion, но если кликать по кнопке Search вверху самого Zettelkasten, то искать он будет по заголовкам и никак иначе. Чтобы искать по тексту и вложениям как в начале статьи, нужно пользоваться Quick Find, который вызывается по Ctrl/Cmd + P.

Как использовать шаблоны ввода?

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


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

Как создавать резервные копии?

Автор метода вел свой Zettelkasten десятилетиями, и недавно в коментариях я увидел, что Notion слишком скоротечен и ненадежен для такого метода. Мне тоже страшно что Notion вдруг закроется, и потому я регулярно выгружаю данные и отправляю в облако. При экспорте Notion присылает копию на имейл; так получается следовать правилу 3-2-1 без особых усилий.


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

Выводы, шаблоны и ресурсы

Zettelkasten развивает зависимость. Когда не можешь записать идею или узнанный факт прямо тут и сейчас, осознание его ненасытности и щедрости вызывает острую боль. А лень скормить Цеттелю что-либо пробуждает вину. Поборники метода не врут: появляется желание читать ранее тягостные книги и мануалы с целью накормить своего заметочного демона, чтобы тот переварил гранит науки в мягкую кашу.

Я верю, что лучший Zettelkasten построен своими руками. Ни один из шаблонов Notion, которые я видел не пригодился сам по себе. Поэтому я и написал статью вместо размещения очередного шаблона на Реддите.

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

В своём шаблоне я использовал бесплатные иконки для Notion от NuttsLab, мне они нравятся.

Недавно открыл для себя Godot engine, опенсурсный игровой движок. Делюсь некоторыми приёмами и заметками, в основном из области 3д, кода или общих моментов.


У Godot в целом репутация скорее 2д движка, которое проработано довольно хорошо, но и не так давно появившиеся 3д возможности позволяют делать трёхмерные игры. Особенно если вы в состоянии оптимизировать какие-то вещи самостоятельно, не делаете слишком уж тяжёлую и комплексную игру, а также вас устраивают текущие варианты рендера. Ну или можете ждать будущих оптимизаций и появления vulkan.

Из коробки в движке есть некоторая физика, в том числе джоинты и колёсный транспорт. Нет встроенного редактора terrain, но можно воспользоваться плагином, импортировать из специализированных программ или просто как меш из 3д пакета. В последнем случае ради производительности придётся самостоятельно резать ландшафт на фрагменты-чанки, и скорее всего делать им отдельные меши под коллизии. Что касается мешей под форму коллизии ландшафта чтобы не было визуальных нестыковок, нужно триангулировать модель во время экспорта из 3д пакета. Например, один из простейших способов это сделать в Blender экспортировать меш в формате collada (.dae), там по дефолту стоит галочка triangulate.

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


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

Что касается языков, то если не рассматривать низкоуровневый способ, то наиболее ходовые варианты это скриптовые языки GDScript и C#, а также визуальный скриптинг для чего-то простого. GDScript лучше интегрирован в движок, имеет больше примеров, не требует запуска внешней среды, а в плане общей структуры тут будет происходить всё то же, что в варианте C# объявление переменных, вызов функции инициализации, цикл процессов, цикл физических процессов и так далее. Так что выбор GDScript в качестве основного скриптового языка разработки имеет смысл. Пересаживаясь на C# получим разве что большую аккуратность и подробность записи, теряя в лаконичности, но усиливая разборчивость и контроль над ситуацией фигурные скобочки вместо использования табуляции, отметки конца строки, более формальную типизацию.
Что касается глобальных переменных, то для их использования что в GDScript, что в C# потребуется добавить в параметрах проекта глобальный скрипт/скрипты в автозагрузку, к переменным которого можно будет обращаться глобально.
Также в Godot действует ограничение -на каждом объекте не может быть больше одного скрипта. Но этот момент можно обойти, например, повесив второй скрипт на дочерний объект.

Сигналы

Для обмена данными между узлами в Godot можно также воспользоваться иерарией, ведь объекты крепятся друг к другу, как ветки к дереву. Правда у этого подхода свои подводные камни, ведь в нашей игре иерархия может быть динамически изменяемой. К тому же обращение к иерархии в пределах одной сцены это одно, а вот когда у тебя сцена внутри сцены внутри сцены, то с этим возникают некоторые сложности, хотя бы даже чисто в понимании происходящего.
Один из способов со всем этим управляться и не слишком привязываться именно к конкретной текущей иерархии это сигналы. Какое-то количество общих сигналов уже предустановлено можно заглянуть в панель сигналов объекта, чтобы прикрепить строку с обработкой получения одного из них в скрипт того же объекта или другого объекта со скриптом, в пределах сцены. Если же нужно сделать свой собственный сигнал, то делается это так:


Заводим сигнал

Излучаем его в том же скрипте при нажатии кнопки или других условиях

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


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

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


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

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

CGS-объекты

Один из полезных 3д инструментов в Godot примитивы constructive solid geometry. Проще говоря это объекты, поддерживающие булевы операции пересечение, исключение, объединение. Кроме набора примитивов есть универсальный CGS Mesh, в качестве формы для которого можно установить уже произвольный меш.



Пустышка CGS Combiner потребуется для использования в иерархии, чтобы управлять приоритетом применения операций, если в этом есть необходимость при сборе какой-то сложной конструкции.

Основное применение CGS удобство и простота прототипирования статики уровня и каких-то его элементов. По факту можно сделать меш в 3д пакете, и повторить в нём те же самые результирующие формы, разве что этим надо будет заниматься вне игрового редактора.

Следующее применение статических CGS имитация разрушаемости и повреждений. для этого требуется расставить CGS примитивы в режиме исключения, как дыры, огрызки и вмятины, а затем временно скрыть, включая видимость в нужный момент. Ограничение тут в том, что повреждать мы можем только поверхность CGS объекта, к тому же повреждение должно быть изначально прикреплено к нему как дочернее либо крепиться через код, как потомок. Зато такой вариант по гибкости настройки уже значительно выигрывает по сравнению с заготовленным в 3д-пакете разрушаемым объектом.




Далее у нас идут CGS движущиеся. Через код, либо записанную анимацию. В целом через этот способ можно реализовывать какие-то эффекты, но очень желательно чтобы подобные анимации не крутились на сцене в цикле. Несколько анимированных CGS могут заметно посадить производительность, к тому же в Godot оптимизирует не все вещи, и если вы не вырубите анимированные CGS самостоятельно, то они будут продолжать расходовать производительность вне видимости камеры.
Тем не менее эффекты анимированных CGS уже сложно заменить решениями 3д пакета, поэтому вы можете быть заинтересованы именно в их использовании (по крайней мере, если не собираетесь рисовать продвинутое 3д через код). Главное найти им правильное применение, лучше всего их использовать точечно, в определённых местах, включая анимацию по триггеру. Как эффект открытия прохода или прочий разовый спецэффект. Естественно, чем проще форма CGS объектов тем лучше. А основную вычислительную нагрузку они оказывают именно в процессе соприкосновения в движении, притом нет особой разницы, какой именно объект двигать относительно другого.


На видео есть момент где машинка падает сквозь дыру в мосту, когда анимированная CGS-капсула проходит через CGS Mesh с моделькой моста.