@
Убедиться, что установлены все зависимости:
pip install -r requirements.txtЗапуск локального сервера:
python manage.py runserverСоздание администратора:
python manage.py createsuperuser --email admin@mail.ru --skip-checks(дальше потребуется ввести для него пароль)
Markdown — мощный простой человекочитаемый формат текстовой разметки (этот файл написан именно в нём), который легко переводится в любой другой текст (например, есть утилита-шверцарский нож конвертации pandoc, переводит любой текстовый формат в любой (от fb2 до LaTex) ). Нам здесь нужно во многих местах давать возможность делать выделения, ссылки и так далее — я очень не хотел изобретать велосипед, и захотел его здесь использовать. Важно отображать математику — для нее мы используем mathjax — к сожалению, он слегка отличается от классического latex, но позволяет генерировать картинки прямо у пользователя на компьютере, а не хранить их на сервере/обращаться к "левым" сайтам.
В папке extra/courses есть самописный скрипт (bat, но он должен также работать на linux, так как он не использует никаких windows-команд — правда, подразумевает, что в path лежат pandoc и python), который может сконвертировать html с math-блоками в нужный нам markdown. В первую очередь — перевести материалы Евгения Евгениевича (алгебра). Кроме "засасывания" в pandoc он делает небольшие замены математики, чтобы получить mathjax, близкий к исходному tex. Он неидеален, над ним еще повозиться надо, но достаточно хорош.
Регистрация у нас лежит в отдельном приложении — accounts/. Регистрацию очень важно случайно не испортить во время разработки, и логика там не связана с основным сайтом.
Основной код сайта лежит в main/.
В django логика состоит из следующих основных компонент, каждая из которых лежит в отдельном файле/папке:
Основное:
models). Удобная оболочка вокруг данных, "ядро", вокруг которого строится внутренняя логика. Модель состоит из полей, каждое из которых хранит какой-то кусочек данных этой модели. Например, есть модель пользователя, у него есть имя, фамилия, адрес почты, фотография (может быть пустой)… По этой модели создаются пользователи, каждый из которых хранит эти поля в базе данных. Связи с другими моделями — тоже поля, например, курс хранит в себе ссылки на все его записи и тп. О том, как описываются модели, нужно читать документацию Django.views). Функции (на самом деле можно реализовывать и сложные структуры, но нам это пока не очень нужно было), которые по запросу пользователя и дополнительной информации умеют возвращать вид страницы. "Внешняя часть" логики. Они используют templates, подставляя в них нужные данные — удобные django-шаблоны для генерации страниц.forms). То, что позволяет собирать информацию от пользователей, будь это фотография для профиля, кнопка для закрытия объявления, или регистрация. Формы в чем-то очень похожи на модели, и даже могут быть для удобства напрямую к ним привязаны, создавая указанную модель по введенным полям, как только пользователь нажимает кнопку Зарегестрироваться/Отправить/Создать.static). Здесь лежат "материалы", такие как css-стили, или скрипты для mathjax. Эти файлы затем вызваются из templates и подгружаются на страницу. Здесь нельзя хранить пользовательские штуки/что-то динамичное.templatetags — здесь можно объявить пользовательские функции, которые используются в templates. Например, в templates не было такой простой штуки, как преобразование объекта в строку, но с помощью этого его можно использовать.__init__.py в каждой папке (модуле). Обязательный файл, в который нужно импортировать из файлов папки элементы, которые будут использоваться "вне" этого модуля. Без него модуль бессмысленен (ничего не дает).migrations — файлы для обновления базы данных, их не надо пытаться изучать, их генерирует сам django."Мелкое":
admin.py — здесь нужно регистрировать модели, если хотите, чтобы администратор мог их видеть и чинить (очень полезно для отладки).urls.py — здесь нужно регистрировать и привязывать ко views все url, по которым пользователи смогут переходить на разные страницы вашего сайта.tests.py — увы, у нас тестов не было — 0% покрытия кода… По-хорошему нужно их создать, они могут очень полезны для рефакторинга (переписывания кода) и преждевременной ловли ошибок, но в django с этим достаточно туго — всё-таки в первую очередь у нас внешнее взаимодействие, внутренней логики не так много. Будет круто, если их кто-то все-таки напишет.Мы также используем папку other, чтобы хранить прочую логику (например, сейчас в ней лежит файл markdown.py, с помощью которого можно генерировать html-код элементов из markdown).
Папки:
templates — здесь лежат html-шаблоны страниц, в которые с помощью views "подставляются" нужные данные.media — здесь лежат загруженные пользовательские файлы (например, фото профиля).tasks — основные настройки сайта.Файлы:
requirements.txt — список всех зависимостей (нужно в первую очередь для сервера, стоит поддерживать в актуальном состоянии и обновлять по возможности библиотеки с помощью pip freeze).db.sqlite3 — локальная база данных.gitignore — файлы и папки, которые не будут коммититься. Нужно добавлять туда, если появляется что-то тяжелое/просто лишнее, что явно не нужно хранить в репозитории, например, файлы пользователей.app.yaml, .gcloudignore, deployer.py, cloud_sql_proxy — серверные штуки, их лучше не трогать (Лень, ПА, поправьте меня, если я не прав).manage.py — django-файл, с помощью которого можно управлять проектом.Со временем появляется больше данных (новые параметры пользователи, новые записи и так далее). Все эти данные хранятся в отдельной базе, и, чтобы все работало и запускалось, после каждого изменения в структуре хранимых данных нужно эти изменения применить к базе:
python manage.py makemigrations…создаст питоновские файлы с инструкциями, какие поля добавлять, а
python manage.py migrate…попробует применить эти изменения к базе.
Иногда это делается автоматически, но очень часто случаются осложнения, например — если вы создали пользователю обязательное поле "номер телефона", но у вас в базе уже есть десять пользователей. Django не знает, откуда для них достать телефоны, и попросит значения по умолчанию (если не указано default в модели номера телефона).
Иногда начинают сыпаться конфликты, их нужно пытаться решать по обстоятельствам. Часто это просто ошибки в коде, нужно изучать и исправлять. Если возникли непонятные конфликты, которые никак не получается починить, можно попробовать удалить все файлы из main/migrations и сгенерировать их заново:
python manage.py makemigrations mainИ применить их через migrate.
Средство для крайнего случая, которое почти гарантированно сработает — удалить/очистить базу (локально — файл db.sqllite, удаленно мы такое еще не пробовали), удалить миграции, как описано выше, и сгенерировать всю базу данных заново. ВАЖНО: при этом теряются все данные, это недопустимо, если этим пользуются реальные люди (только для локальных/если сервер пустой). Перед удалением настоятельно рекомендуется закоммитить/stash-ить базу, чтобы избежать потери важных данных.
На сервере мы еще ни разу не применяли миграции, так что могут возникнуть неочевидные осложнения.
<Это должны написать Лёня/Павел Андреевич, я без понятия, как и что там происходит>
merge для миграций, но она крайне неудобная.В БД есть пользователи:
Студент 1:
email: user@mail.ru password: hardpassword
Студент 2:
email: reciever@mail.ru password: hardpassword
Администратор:
email: admin@mail.ru password: 123
Администратор для удаленного сервера:
email: superuser@mail.ru password: 123456