Введение

Это вторая статья из серии статей про создание бота на основе discord.py. В этой части рассмотрим форматирование в discord, конфиги и немного про git, а к коду перейдём в следующей.

В данной части

  1. Форматирование

  2. Конфиги

  3. Git

Форматирование

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

Для начала форматирование текста, всего существует 4 стиля:

Форматирование текста

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

Спойлеры

  • Спойлер 1 - Как задать спойлер

  • Спойлер 2 - Открытый спойлер

  • Спойлер 3 - Ещё не открытый спойлер

Следующее - это цитаты. Они немного похоже на embed(могут отправлять только боты).

Есть однострочные и многострочные цитаты. Для их использования нужно поставить знак > или >>>. (Сначала что вводим, затем результат)

Цитаты

Обратите внимание, что между > и текстом обязательно должен быть пробел!

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

Блоки кода

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

Подсветка синтаксиса

Иногда это можно использовать для "раскраски" какой-либо информации. Например, если использовать в качестве языка diff, то можно красиво показывать список изменений.

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

Иногда возникает потребность использовать, например * как символ, а не как средство форматирования, и тут к нам приходит старое доброе экранирование. Оно работает, как и во всех языках программирования путём добавления "\"(Обратного слэша) перед зарезервированным символом.

Например, вот так. (В блоке, форматирование текста не работает)

Экранирование

А теперь переходим к тому, о чём многие не знают.

Ввод (текст)

Результат

<https://www.example>

Выводится ссылка без прикреплённого вложения.

<@80351110224678912>

Упоминание пользователя. Цифры(18) - ID пользователя.

<#103735883630395392>

Упоминание канала. Цифры(18) - ID канала.

<@&165511591545143296>

Упоминание роли. Цифры(18) - ID роли.

<:mmLol:216154654256398347>

Вставка статичного эмодзи (имя и ID эмодзи).

<a:mmLol:216154654256398347>

Вставка подвижного эмодзи (имя и ID эмодзи).

<t:1618953630>

Временная отметка. Цифры - количество секунд с 1 янв. (четверг) 1970 года, 3:00.

<t:1618953630:STYLE>

Временная отметка, но со стилем. STYLE - стиль отображения, является символом (список примеров в таблице ниже), по умолчанию f.

И сами стили для последней строчки.

STYLE

Результат

Пример синтаксиса

t

0:20

<t:1618953630:t>

T

0:20:30

<t:1618953630:T>

d

21.04.2021

<t:1618953630:d>

D

21 апреля 2021 г.

<t:1618953630:D>

f *

21 апреля 2021 г., 0:20

<t:1618953630:f>

F

среда, 21 апреля 2021 г., 0:20

<t:1618953630:F>

R

7 месяцев назад

<t:1618953630:R>

Таблицы взяты отсюда.

Конфиги

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

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

Пример "боевого" конфига

Git

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

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

  1. Для начала конечно же нужно удалить конфиг файл из git-а. (в примере config.py)

  2. Скопируйте файл и добавьте в название копии .example (config.py.example)

  3. Удалите все "приватные" данные, такие как токены, ID приложения и тд.

  4. Если файлы не добавляются автоматически, добавьте новый файл в git.

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

Git Branch

И немного про организацию веток системы контроля версий. Мы с моей командой используем модель ветвления feature branches, её суть заключается в том, что каждая новая функция должна разрабатываться в отдельной ветке. Ветки функций создаются не на основе master, a на основе develop(dev). Когда работа над новой функцией завершена, она вливается назад в develop(dev). Новый код не должен отправляться напрямую в master.

Модель ветвления

Это ещё не всё

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

Следующие части