mge410 / lyceum

Учебный проект яндекс интенсива: Веб-разработка на Django

lyceum

Запуск проекта

Первый шаг одинаковый, дальше разные для OC Windows/Linux
1 Клонируем себе репозиторий:
git clone https://github.com/mge410/lyceum.git
и переходим в папку с проектом
cd lyceum

P.S в тестовой базе уже есть пользователь администратор, если вы используйте
проект для ознакомления - можете воспользоваться им и пропустить 5-й пункт.
Логин: admin
Пароль: admin

Windows:	Linux:
2 Заводим виртуальное окружение и активируем его: python -m venv venv .\venv\Scripts\activate	2 Заводим виртуальное окружение и активируем его: python3 -m venv venv source venv/bin/activate
3 Обновляем pip и качаем туда все что есть в requirements.txt: python -m pip install --upgrade pip pip install -r .\requirements\requirements.txt	3 Обновляем pip и качаем туда все что есть в requirements.txt: pip install -U pip или python3 -m pip install --upgrade pip pip install -r requirements/requirements.txt
4 Загружаем миграции для базы данных и наполняем их тестовыми данными python .\lyceum\manage.py migrate python .\lyceum\manage.py loaddata data.json	4 Загружаем миграции для базы данных и наполняем их тестовыми данными python lyceum/manage.py migrate python lyceum/manage.py loaddata data.json
5 Cоздаём пользователя администратора для доступа в админку python .\lyceum\manage.py createsuperuser	5 Cоздаём пользователя администратора для доступа в админку python lyceum/manage.py createsuperuser
6 Запускаем проект: python .\lyceum\manage.py runserver	6 Запускаем проект: python3 lyceum/manage.py runserver

Настройка проекта
В репозитории есть пример файла с настройками проекта example_config.env копируем его файл с названием .env внутри проекта в папку lyceum
Для Windows
cp example_config.env .\lyceum\.env
Для linux
cp -r example_config.env /lyceum/.env
После чего его можно настроить под себя

---

Установка зависимостей
cd requirements

Основные зависимости:
python -m pip install --upgrade pip
pip install -r requirements.txt

Зависимости для разработки
pip install -r requirements_dev.txt

Зависимости для тестирования
pip install -r requirements_test.txt

Схема Базы Данных в проекте

Схема Базы Данных Обратной связи в проекте

lyceum's Issues

Оптимизировать использование verbose_name (и verbose_name_plural)

С маленькой буквы. Обрати внимание на упоминание о конвенции наименования verbose_name

И да, на будущее не забывай, что если verbose_name на первом месте — оно указывается просто в кавычках, а для полей ForeignKey, ManyToManyField и OneToOneField это будет не на первом месте и с именованием параметра
Просто почему-то часто с ростом проекта становится неединообразно, поэтому упоминаю

А ещё будет красиво указывать параметры создаваемого поля не где-то одно на строке, где-то два, а единообразно. Например, по одному на строку. И примерно в одном порядке. Помогает быстрее сориентироваться
Сторонний пример:

Это к желанию в AbstractModel всё уместить в одну строку
Также стоит уточнить отдельные verbose_name. Например: у абстракной модели в name. У товара, катогории и т.п. разве "имя"? Наверное, "название" всё же
Ну или "слаг" как штуку известную тоже часто просто так и пропиывают в вербозе

Вынести валидаторы в корректный модуль

def perfect_validate() не место в core.models
Корректно: отдельный файл в приложении catalog

(При разрастании и разбиении на разные модули, — как и некоторые другие вещи, — может перерасти в директорию, но нам пока это точно не нужно)

Починить линтер Шрёдингера

      - name: flake8 Lint
        uses: py-actions/flake8@v2
        with:
          flake8-version: "5.0.4"
          max-line-length: "88"

[flake8]
exclude = .git,__pycache__,.env,venv/,*/migrations/
ignore = W503
max-line-length = 79
per-file-ignores = manage.py:Q000
import-order-style = google

Хмм, чувствую, что что-то не так
Интересно, где

Разобраться с зависимостями

Попробовать установить их из requirements_test.txt

Заодно отсортировать зависимости по алфавиту

На лишнее содержимое файлы с зависимостями дальше проверяй сам, его там быть не должно

Об импортах

В админке увидел from catalog import models, вроде неединообразно же получается

Кстати, если вспомнить, Данила считает (и упоминал на первых лекциях), что относительные импорты допустимы, но в "серой зоне"
Давай тогда вообще попробуем от них уйти?

Тесты чайникового эндпоинта можно разделить

Проверка неоднородная, поэтому будет логичнее разделить тесты на
def test_coffee_endpoint_status()
def test_coffee_endpoint_text()
Да, запросим эндпоинт два раза, но здесь это оправданно

Можно сделать проверки чуть лучше, использовав HTTPStatus

from http import HTTPStatus

а потом будет что-то такое:

    def test_homepage_endpoint(self):
        response = Client().get('/')
        self.assertEqual(response.status_code, HTTPStatus.OK)

Ну и все эти сообщения, до которых мало кто додумался

И семантично, и избавляемся от т.н. магических чисел

Оптимизировать количество файлов

Не нужно закидывать неиспользуемые файлы
Нам вполне достаточно bootstrap.min.css и bootstrap.min.js (и раскидать их по папкам css и js)

Доработать ридми

Базовый текст есть, но надо расширить

Например, для винды и линуксов всяких так-то команды разные
Где-то, например, нужно будет source venv/bin/activate, а где-то .\venv\Scripts\activate
Всякие python/python3 опять же. Ну или pip/pip3 (ладно, здесь ещё можно на soft links скидку сделать)

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

виртульное окружение
ативируем его

И такие вещи стоит подправить заодно

Больше тестов богу тестов!

Тот момент, когда можно залезть чуть в проверку допника ещё на этапе проверки основного задания

Проверок эндпоинтов для приложения catalog мало
Для основной проверки и проверки регулярки (которую посмотрю в рамках допника) можно продублировать один и тот же набор проверяемых случаев
Давай проверим 0, 1, 01, 010, 10, 100, отрицательный ноль, отрицательное число, десятичную дробь, смесь из цифр и букв (когда цифры вначале, в середине, в конце, по краям), строки с некоторыми спецсимволами (типа $, %, ^..., но не теми, что для параметризации урла используются или для установки якоря)

На перспективу сдачи допников подумать, что можно улучшить в тестах

Почитать про сабтест в свободное время:
https://www.caktusgroup.com/blog/2017/05/29/subtests-are-best/
https://docs.python.org/3/library/unittest.html#distinguishing-test-iterations-using-subtests

Или про @parameterized можно

Тестируем на корректное, тестируем на некорректное. Группируем, оптимизируем
Возможно, останется тлоько что-то типа набора

def test_catalog_endpoint()
def test_catalog_item_endpoint()
def test_catalog_item_positive_integer_endpoint()

По ERD

Лучше поместить изображение в сам ридми, не стоит сильно доверять стабильности даже стабильных сервисов

id типа ing? Очепятка

Таблица catalog_tag — вроде, более логично

name и slug всё же немного корректнее обозвать varchar (с неким ограничением в скобках), а text — text.

Но вообще на варианты указания типов данных (text,varchar/char, int/bigint/smallint,..) и ограничения типов про конкретным БД при этом сейчас не обращаю внимания, важнее смысл. Остальное подтянется, к тому же зависит от типа БД. Те же bigint/smallint джанга сама додумывает, куда использовать (можешь посмотреть через sqlmigrate).
Например, для веса, вроде smallint будет (но это навскидку, здесь могу ошибаться)

Меню с переходом на страницы недонастроено

Отключать все ссылки на страницу, если мы на ней находимся

Если мы находимся на странице "Главная", крайне желательно ссылку на неё в меню делать неактивной
Аналогично с другими пунктами: чтобы выглядели неотключёнными, как сейчас, но их нажатие не приводило к перезагрузке страницы
Обработку активных пунктов, если правильно помню, можно делать как через with и классы bootstrap, так и через использование django-active-link (для интереса посмотри) — приму любой вариант.

Почему сказал "все ссылки"? На главной странице ссылкой на неё саму будет и логотип, и пункт в меню навигации

На карточку товара по ссылкам не попасть

Нет ссылок на карточку товара из карточек в каталоге

Кстати
Нажми на странице Каталога в карточке товара "Тут будут списки товаров =)" и посмотри на результат
Такого быть не должно

Приложения не зарегистрированы

Отмечу, что свои приложения желательно в сеттингс, если они не переопределяют стандартное поведение, указывать в конце списка (см. https://developer.mozilla.org/ru/docs/Learn/Server-side/Django/skeleton_website и указание на последовательность загрузки здесь: https://docs.djangoproject.com/en/3.2/ref/settings/#std-setting-INSTALLED_APPS)

(Заодно, не выходя из файла настроек, стоит проверить, всего ли хватает, если настройку DEBUG мы установим в False и откроем проект)

Оптимизировать использование related_name

Начиная с Item, где это вообще можно переместить в default_related_name в Meta.

Так-то related_name у нас для красоты обращения к связанным моделям используется, чтобы потом обратиться к товарам категории, например, не через category.item_set, а через более человечное category.items (что и при выборе ему названия стоит учитывать, перепроверь у себя везде)
https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.ForeignKey.related_name
https://docs.djangoproject.com/en/3.2/ref/models/options/#default-related-name

Улучшить размещение тестов

Начнем с того, что они достаточно разрослись, чтобы их разбить на отдельные модули (там, где в файле больше пары-тройки разноответственных функций - точно)
Создаём вместо такого растолстевшего tests.py папку tests в соответствующем приложении и там располагаем всякие test_models.py, tests_urls.py, tests_views.py и подобные им (почитай, какие имена файлов отлавливает Django unittest, чтобы в них искать тесты для запуска)

Доработать .gitignore

На лекции рассказывали, как его сразу стоит завести, ещё при создании репо
Там будет много интересного

Плюс, его ещё можно дополнить, чтобы не замусоривать репо служебными файлами IDE-шек, системными файлами и т.п.
Например, создать новый блок и вписать туда как эту самую .idea/ (для PyCharm), так и .vscode/ (для... VS Code)
А если развить тему шире, ещё можно вспомнить про маковский .DS_Store и т.п.
Но для начала и этих дополнений - к тому гитигнору, что создаёт гитхаб, - будет достаточно

Улучшить тесты

Достаточно будет и одного класса, какого-нибудь ModelsTests
А уже в общем классе можно и setUp(), где мы бы создали тестовые категорию и тег, и tearDown(), где мы бы убирали мусор (Item, Tag, Category) и заодно обращались к родительскому tearDown()
А дальше test_item_validator(), test_item_negative_validator() и т.п.

Трижды test_create_items_to_text() — наименование нелогично (возможно, просто забыл переименовать)
Как и соотношение названий test_unable_create_to_slug() и test_create_items_to_text() (в тестировании категорий и тегов)

Проработать help_text

Он сейчас есть, но не везде. Помним про единообразие

Атрибут help_text используется как для для отображения текста в админке, так и может быть использован для дальнейшего вывода на страницу через ModelForm

Сюда можно более подробное описание, чем verbose_name, или информацию об ограничениях поля (например, для name какого-нибудь просто указать 'Максимум 150 символов', аналогично для slug)
Или, для Item.text: 'Описание должно содержать слова "превосходно" или "роскошно"'
И т.д.

В отличие от verbose_name, help_text не автокапитализирует первую букву, а ещё не экранирован он html-тегов (но это так, для информации)

Можно чуть дооптимизировать CI/CD

Версию python-version можно оставить только одну

(В остальном файл должен, наоборот, расшириться, если будешь делать второй допник, он же Задача № 3)

Доработать ридми

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

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

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

Приложение core появилось, а verbose_name у него нет

Стоит использовать именование в файлах адресов приложений

Посмотри, что можно улучшить в urls, используя name и app_name (для пространств имен), и прочитай, почему (https://docs.djangoproject.com/en/4.1/topics/http/urls/#id7).

Для сведения: о лишних файлах

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

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

Разобраться с лишними валидаторами

slug = models.CharField(
    <...>
    validators=[validators.validate_slug],
    <...>
)

Например, смотрим сюда и анализируем:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#slugfield
https://docs.djangoproject.com/en/3.2/ref/validators/#validate-slug

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

С этим ещё связано тестирование и что вместо статуса 200 нам может прилететь 301
А за самим таким поведением стоит вот эта причина: https://docs.djangoproject.com/en/4.1/misc/design-philosophies/#definitive-urls
В перспективе на таком можно запутаться

На досуге: почитать о trailing slash'ах

Вопрос всплывал в чатике, поэтому предлагаю подумать, нужно или не нужно корректировать урл для чайника, например
С тебя кратко мысли (можно и после мягкого дедлайна)

Один из урлов для ознакомления
https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash

Исправить html

Код здесь в заданиях не самый сложный, и стоит его сделать валидным

Подскажу один из вариантов поиска ошибок:
Запускаешь сервер Django, открываешь в браузере свой сайт, все основные страницы отдельно. Для каждой открываешь исходный код (обычно Ctrl+U)
Заходишь на https://validator.w3.org/ и выбираешь Validate by Direct Input (удобнее добавить ссылку https://validator.w3.org/#validate_by_input или https://validator.w3.org/nu/#textarea в закладки)
Для каждой страницы копируешь туда код и нажимаешь Check
Вывалится ряд ошибок, которые надо исправить. Красные Error и жёлтые Warning — в обязательном порядке. Зелёные Info — это уже не прям ошибки, но тоже желательно исправить
Для каждого недостатка в коде будет указано, где он встретился, что стоит сделать и в чём может быть проблема, если всё оставить, как есть

Другой вариант — использование специальных аддонов

Немного доработать тесты

[1, HTTPStatus.OK],

и подобное
Придерживаемся консистентности и помним, что у нас всё, типа, строки

Плюс снова смотри на #25
Проверок недостаточно!

Кстати, круто, что в терминале будет видно, на каких значениях тесты упадут

Доработать модели с учётом признака уникальности

Смотрим, например, на name у абстрактной модели
Как насчёт добавить unique?)

Чуть докрутить разделённые зависимости

В requirements_test.txt указан просто flake8, что допустимо, но там же ещё mccabe с ним идёт, pycodestyle, pyflakes, да и плагины вот-вот появятся (смотрим следующее задание), лучше всё и сразу с версиями
И, если правильно вижу, из dev пропал tomli, который ставится вместе с black

Уточнить title страниц

Сейчас он один и тот же везде

Заголовок страниц оптимальнее оформить через {% block title %} и переопределять в шаблонах

Модельки можно было оптимизировать ещё больше

Даниле достаточно, что slug повторяется, но мне нет)

Например, в сторону

class Category(PublishedWithNameBaseModel, SluggedBaseModel):
    ...

Или вообще в такую

class Category(NamedBaseModel, PublishedBaseModel, SluggedBaseModel):
    ...

Если заморачиваться
В последнем случае плюс: более гибкое управление моделями. Относительно минус: залезаем в принцип APO (Avoid Premature Optimization), но здесь нам оба вариант подходят
В решении Данилы, которое он упоминал в вашем чатике, я видел, что slug он и так повторяющимся пропустил бы, но здесь я бы предложил какой-то из своих вариантов

Кстати, базовые модельки ещё помогут с этим куском, который можно вынести (он повторяется трижды, Карл!):

def __str__(self) -> str:
    return self.name[:15]

А вот потом уже переопределять, при необходимости

Но там ещё надо учесть уже человеческую логику за пределами ТЗ, где имена могут совпадать (тот же Item, типа "булочка с корицей"), например, а где не могут (тот же Tag, типа "сладкое"). Там выбираем основный вариант, и его уже при необходимости переопределяем в самих моделях
Прям всё кардинально переформатировать не так уж и обязательно, но это тот самый принцип DRY

Проверить валидатор

Два слова, которые в ТЗ, должны проходить. В том числе, если соседствуют/слеплены со знаками препинания, например: "Роскошно!", "Супер (роскошно)" или "превосходно,роскошно" (без пробелов) должны проходить. А "нероскошно" или мешанина букв типа "роскошно111", "роскошноGGG", "йлцорудыфвпревосходнойцуйцлур" (это же не отдельно взятые слова "роскошно" и "превосходно") — нет

Единообразить ответы вью-функций

Где-то возвращаешь просто фразу в кавычках
Где-то элемент <body>
Где-то <div>

А в item_detail(), кстати, будет логично отдавать, на страницу какого элемента мы заходим
F-строка в помощь

Ещё о типах полей

Твой SmallIntegerField увидел, круто, что нашёл
А теперь заодно посмотри на PositiveSmallIntegerField :)
Ноооо
Джанго в этом месте на своей волне
Попробуй создать что-то за пределами диапазона (не буду говорить, в каком из направлений)
Если у тебя после этого возникнет один закономерный вопросы, можешь проследовать в IDE по её исходникам и посмотреть, как она относится к этому и паре других типов

Возможно, тебе не понадобятся в модельке всякие такие вещи, как .MaxValueValidator (ну и .MinValueValidator тоже можно за компанию)
Хотя, кто знает

Уточнить название класса абстрактной модели

AbstractModel ни о чём не говорит, когда смотрю на это название из другого модуля
Корректный нейминг — наше всё

is_published + name => PublishedWithNameBaseModel или что-то такое

Улучшить проверку стиля кода

Помнишь, я упоминал плагины? И про примерно оптимальную установку флейка с плагинами для базовых вещей?
pip install flake8 pep8-naming flake8-broken-line flake8-return flake8-isort flake8-quotes

Она не будет работать должным образом, если конфиг будет пропускать ошибки

По хорошему, в настройки флейка (файлик типа .flake8) стоит прописать пропускаемые директории (типа __pycache__, .git, */migrations/, venv/) и тотально заигнорить предупреждение W503 (и только)
Ну ещё можно per-file-ignores = manage.py:Q000

Всё остальное устраняем. И недостатки тоже

И конфиг бэка донастраиваем

Тогда проблема с длинами строк в сеттингс будет спокойно так решаться:

AUTH_PASSWORD_VALIDATORS = [
    {
        'NAME': (
            'django.contrib.auth.password_validation'
            '.UserAttributeSimilarityValidator'
        ),
    },

(как ты, видимо, и пытался)

Посмотри результат проверки после донастройки флейка, короче :)

Доработать момент с переменными окружения

В .env стоит поместить SECRET_KEY, DEBUG и ALLOWED_HOSTS. Данные в сеттингс забирать оттуда

При этом не надо заставлять пользователя с нуля создавать что-то, без чего проект не заработает
Предварительно намекну: допустим, я решил установить проект с нуля. При этом, например, пока DEBUG не задан и если проект не знает, где это значение искать, строчка DEBUG = os.getenv("DEBUG") вернёт False. А это автоматически приведет к ошибке, что не прописаны ALLOWED_HOSTS. И всё накрылось в итоге

В идеале всегда должен быть спокойный запуск runserver как с .env-файлом, как с переменными в настройках проекта на гитхабе, так и если вообще если нет ни того, ни другого (проверить!!!). Просто от этого может зависеть debug-режим это или нет (а в перспективе и к другим параметрам может быть привязка, например, к тем же базам данных).

Как вариант, удобно зайти в доку какого-то модуля и взять оттуда что-то аккуратное типа этого:

import environ

env = environ.Env(
    # Set casting, default value
    DEBUG=(bool, True),
    SECRET_KEY=(str, 'dummy-key'),
    ALLOWED_HOSTS=(list, ['*']),
    <...>
)

BASE_DIR = Path(__file__).resolve().parent.parent

environ.Env.read_env(BASE_DIR / '.env')

DEBUG = env('DEBUG')

<...>

Ознакомься с конструкциями для settings.py типа SECRET_KEY = os.environ.get('SECRET_KEY', 'any-other-dummy-key') и DEBUG = os.environ.get('DEBUG', True), про os.getenv, про load_dotenv, что для этого импортировать и как использовать. Такого дополнения будет достаточно. Дополнительно почитай про варианты хранения переменных окружения и как их прятать (в т.ч. про обработку случаев хранения этих переменных в настройках проекта в гитхабе).
Выше есть подвох: строки из .env читаются как строки. Для булевых это надо обработать дополнительно или выбрать из указанных нужную умную функцию, которая сама всё сделает, а то какая-нибудь строка пойдёт как тру

Думаю, будет неплохим заданием проверить это на практике. Да и в принципе всё целиком
Во-первых, здесь немного, так что даже ручное тестирование сойдёт :)
Во-вторых, само понимание реакции джанги на настройку DEBUG будет полезно

Запустил без .env, когда в сеттингс дебаг=тру
Запустил без .env, когда в сеттингс дебаг=фолс
Запустил с .env, когда там дебаг=тру и когда дебаг=фолс, при этом противоположно значению дебаг в сеттингс
Запустил с .env, когда там дебаг это число/строка (помним про особенности их приведения к булевым и подставляем варианты), при этом противоположно значению дебаг в сеттингс

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

Заодно чтобы было понимание, когда начинает требоваться ALLOWED_HOSTS (они тоже читаются из энва как строка, сплитятся обычно по запятой без пробела)

Но и это не всё

Вот разместили мы что-то в .env
А как он должен выглядеть? Давай поместим пример этого файла в репо и назовём как-то типа example_config.env
Предложим команду, как его можно использовать (cp example_config.env .env), чтобы пользователь для простого теста нашего проекта не создавал ничего вручную, и упомянем, что при необходимости содержимое .env можно настроить под себя

Доп1: Переписать валидатор

Давай внимательно посмотрим на фрагмент кода, который Данила поместил в задание:

text = models.TextField(
        ...
        validators=[
             ValidateMustContain('превосходно', 'роскошно')
        ],
        ...
    )

ValidateMustContain

Какой намёк ты в этом видишь?
Возможно, "валидатор в функциональном стиле" не означает именно функцию?

Про аннотацию типов и возвращаемых значений

Подвижки в сторону аннотации типов и возвращаемых значений - круто
Но если делать, то делать прям полностью
А -> None в паре мест - ну, такое
Пока можно убрать, хотя я и так хотел упомянуть о них немного позже)

Доработать мидлварь

Почему-то из ?12Список.элементов раз,два:три!(четыре) у меня не получилось ?12косипС.вотнемелэ зар,авд:ирт!(ерытеч)

Чтобы не усложнять def __call__(), можно часть кода вынести в функцию (@classmethod в помощь)

Уточнить темплейты

Аккуратнее с пробелами в таких конструкциях: src="{% static 'layuots/img/cat-logo.svg'%}" (после static лишний)
Сам проверь все места

{% load static %} указываем в самом начале файла, это такая глобальная конструкция
Исключение можно сделать для базового шаблона с доктайпом (для соблюдения стандарта), но всё равно в первых строчках

<form target="_blank" novalidate="true"
    action="https://spondonit.us12.list-manage.com/subscribe/post?u=1462626880ade1ac87bd9c93a&amp;id=92a4423d01"
    method="get" class="form-inline">

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

И везде приведи отступы в порядок, желательно к 2 пробелам (посмотри, сколько уровней вложенности), и поддерживай в этом порядке

Аналогичным образом стоит относиться к оформлению всех тегов и конструкций, чтобы всё в одном стиле

У тебя должен быть план, и ты его должен придерживаться

Отсортировать урлы

Давай расставим урлы по алфавиту ('', эбаут, каталог)
А ещё вернём ссылку на админку и поставим её в конец этого списка

Восстановить порядок в INSTALLED_APPS

Основные приложения джанги — в начале
Потом сторонние
Потом твои

Можно отделить пустыми строками (ну или строками с комментом, объясняющим, что дальше такая-то категория приложений - сторонние, твои)

В рамках каждой категории всё сортируем по алфавиту

Улучшить работу с иконками

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

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

...
├ static-dev/
| ├ css/
| ├ favicon/      // ещё эту директорию внутрь img допустимо (несмотря на xml и webmanifest)
| ├ img/          // вообще для изображений, использованных для сайта
│ │ └ logo/       // для логотипа и его версий
│ └ js
...

Почему это находится в папке с неизвестным мне названием layuots (именно так написано), мне незвестно

Проверь, возможно всплывут баги

У тебя всё корректно с запуском python manage.py makemigrations?
А с загрузкой фикстур и их кодировкой?

Возможно, с ними что-то не то

Админка для Item не соответствует примеру в ТЗ

Сабж (даже визуально если оценивать)

Кстати:

@admin.register(models.Item)
class CatalogAdmin(admin.ModelAdmin):

Почему CatalogAdmin, а не ItemAdmin? Нелогично

Core

Апп Core -> core (https://peps.python.org/pep-0008/#package-and-module-names)
Потом переделывать, возможно, будет тяжелее

Про мидлварь в сеттингс

Дефолтное значение переменной окружения для реверса слов стоит поставить в False в сеттингс

Ну и из энва мы так-то всё в строках тянем, есть ли нужда там REVERSE_MIDDLEWARE и DEBUG преобразовывать дополнительно?

Уточнить тесты мидлвари

Тесты неполные, настройка в них тестируется as is
А надо нормально проверить оба варианта состояния

Почитай про @django.test.override_settings
Пример использования есть здесь: https://docs.djangoproject.com/en/3.2/topics/testing/tools/#django.test.override_settings

По сути, мы можем нагенерировать по сколько-то запросов к эндпоинту в цикле и проверить вхождение в этот список как исходной, так и изменённой фразы
Ну, её разве что закодировать надо будет