Введение
Это вторая статья из серии статей про создание бота на основе discord.py. В этой части рассмотрим форматирование в discord, конфиги и немного про git, а к коду перейдём в следующей.
В данной части
Форматирование
Конфиги
Git
Форматирование
Начнём мы с темы, не на прямую связанную с ботами, но при разработке она будет очень полезной.
Для начала форматирование текста, всего существует 4 стиля:
Так же, текст или изображения можно отправить как спойлер, это значит, что его содержание будет скрыто до нажатия на него. Для того чтобы текст стал спойлером, нужно поставить || слева и справа от текста.
Спойлер 1 - Как задать спойлер
Спойлер 2 - Открытый спойлер
Спойлер 3 - Ещё не открытый спойлер
Следующее - это цитаты. Они немного похоже на embed(могут отправлять только боты).
Есть однострочные и многострочные цитаты. Для их использования нужно поставить знак > или >>>. (Сначала что вводим, затем результат)
Обратите внимание, что между > и текстом обязательно должен быть пробел!
Текст в блоках, если вы используете дискорд для коммуникации команды разработчиков, то наверняка знаете о том, что можно создавать блоки текста. Так же, как и цитаты, они могут быть однострочными и многострочными.
Но у многострочного блока кода есть одна очень полезная фишка, он может подсвечивать синтаксис языка. Для этого после "открытия" блока, без пробела, написать язык и перенести строку(Если поставить пробел или не перенести строку, это будет обычный текст).
Иногда это можно использовать для "раскраски" какой-либо информации. Например, если использовать в качестве языка diff, то можно красиво показывать список изменений.
Полный список поддерживаемых языков можно посмотреть тут.
Иногда возникает потребность использовать, например * как символ, а не как средство форматирования, и тут к нам приходит старое доброе экранирование. Оно работает, как и во всех языках программирования путём добавления "\"(Обратного слэша) перед зарезервированным символом.
Например, вот так. (В блоке, форматирование текста не работает)
А теперь переходим к тому, о чём многие не знают.
Ввод (текст) |
Результат |
|---|---|
Выводится ссылка без прикреплённого вложения. |
|
<@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
Важно сказать про контроль версий. Если у вас личный проект, который будет храниться в приватном репозитории, то наличие в нём токена, не так страшно. (но всё равно не желательно)
Если же вы работаете в команде или проект публичный, вы можете использовать этот способ.
Для начала конечно же нужно удалить конфиг файл из git-а. (в примере config.py)
Скопируйте файл и добавьте в название копии .example (config.py.example)
Удалите все "приватные" данные, такие как токены, ID приложения и тд.
Если файлы не добавляются автоматически, добавьте новый файл в git.
Другие разработчики, при получении новой версии копируют константы из примера и указывают свои тестовые токены. Есть и другие способы, но именно этим пользуемся мы с командой.
Git Branch
И немного про организацию веток системы контроля версий. Мы с моей командой используем модель ветвления feature branches, её суть заключается в том, что каждая новая функция должна разрабатываться в отдельной ветке. Ветки функций создаются не на основе master, a на основе develop(dev). Когда работа над новой функцией завершена, она вливается назад в develop(dev). Новый код не должен отправляться напрямую в master.
Это ещё не всё
Если есть ещё темы, которые можно было бы можно рассказать в этой статье, пишите в комментарии, с радостью распишу.
Следующие части
Часть 2 (Текущая)