Сергей Нижний Новгород

1) Запускаешь PyCharm
2) Начинаешь делать проект
3.1) Появляются какие-то вопросы по конкретным местам - читаешь, спрашиваешь, двигаешься дальше (переделывать какие-то места в первом проекте - не страшно).
3.2) Понимаешь, что не тянешь - идешь в другую сферу. Тоже вполне вариант.

---

Выбор у тебя особо не большой. Пока вопрос звучит так: "А что быстрее камаз или белаз".

Такое ощущение, что какой-то недогуру вывалил часть своего курса по Django и люди вообще без опыта программирования и понимания, что такое Django, побежали запускать проекты на Djnago (уже 5 вопрос за 2 недели такого типа)..

1) Открываем вот этот ролик - https://www.youtube.com/watch?v=IZqBTPmxoew. Смотрим его, повторяем все за автором, понимаем, что и как работает визуально, и что за что отвечает.

2) Открываем документацию и постепенно расширяем проект.

Библиотека Django...
Файл manage.py компилироваться (причем, что питон интерпритируемый язык, а не компириуемый)...

Нужно понимать, что Django - это кастом, и тут далеко не все так просто.

1) Пишутся ли руты на медиа-картинки в базу?
2) Каким способом выводятся картинки в шаблон?
3) Это VPS или Шаред Хостинг?

1) Стандартный механизм Django не подтягивает данные без рефреша страницы.
2) Я писал схему, когда я сохранял текущую страницу юзера в переменную, при логине (в случае успеха - пересылал в json ответ) - делал принудительный рефрешь страницы на ту страницу, что до этого сохранил.
3) После чего, получал авторизационного юзера и все нужные мне поля.

1) Через админку и апач - никак. Все ручками из консоли по хардкору.
2) Вот моя старая инструкция, как я поднимал Django (она скорее всего уже неактуальная, и в ней есть проблемы с безопасностью, но чтобы ты понимал, что к чему). - https://habr.com/ru/post/277653/
3) На Digital Ocean есть неплохие туториалы, как ставить все.

Ещё вопрос. Похоже придется выбирать между gunucorn и wsgi. Что лучше подойдет в данном случае. Есть маленький опыт с wsgi.

Без разницы, в свое время на конференции относительно хайлоада, ребята из mail.ru говорили, что вообще не чувствуют разницу и используют то, что было исторически у них (у них и первый и второй на проде есть)

1) Что вам кроме теории мешает запустить реальный проект на Django? Я в свое время после самостоятельного изучения Python за 4 месяца собрал веб-портал на Django и захостил его (с админкой, формами, сложными запросами, фронтом и прочими прелестями). Да, конечно, на собеседованиях мне говорили, что мой портал сделан "не очень" и прочее, но уже предлагали позиции джунов за 40-45к.

2) Вас же 99,9% контор на этапе рассмотрения вакансии завернут, с формулировкой "какой-то дегенерат, который готов работать за 0. Нахер он нужен, еще каким-то больным на голову окажется".

А если более конкретно. Когда человеку платят деньги, контора понимает, что человек будет стараться, человек боится потерять работу, деньги и прочее. А когда человек работает за 0, он условно может дропнуть базу проекта, собрать вещи и уйти в даль (ведь ему ничего тут не платят, он ничего не боится потерять, а значит может творить любую дичь).

3) Т.е. в любом случае надо искать позицию джуна за какие-то более менее адекватные деньги.

1) Документация была на 70% для function-like стиля кодирования, а не через классы. (Но сейчас, вроде уже догнали). Но надо признать дока очень крутая.

2) Внезапно оказалось, что нет нормального способа сформировать PDF документ из HTML страницы (Для php/java/.net есть либы, что это делают в один клик, а вот на django предлагалось фигачить вручную канвас).

3) Для деплоя django предлагается два варианта, и везде спорят какой из них лучше со всякими бенчами и прочее. По итогу оказалось, что вообще без разницы (разница мизерная). Уточнял у ребят из mail.ru на их конференции.

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

5) Python + django => буржуйский стек (у нас php занимает его нишу в большинстве случаев), поэтому готовься к тому, что все русскоязычные видосы будут с украинским акцентом, а какие-то видосы по Django Rest Framework и прочее - исключительно на английском.

6) Админка Django очень крутая для каких-то простых crud и односвязанных моделей, но что-то более сложное уже сделать не получится, и надо писать свою админку.

settings.py проверь, что добавил в список app свою app

С формы приходит файл изображения
Обрабатываешь его любой нативной питоновской либой для сжатия изображения
Сохраняешь сорс
Дальше кидаешь сорс в easy thumbnails для кропа.

P.s. Решение с JS до отправки не предлагать - слез с easy thumbnails на js и нативную питонячую либу (размечаю фотки по точкам).

Используй методы модели - туда можно пробросить данные из других моделей.

Привет

1) На Django/Python в общем-то не принято создавать интернет-магазины. Этот стек хорошо подходит для стартапов, где нужно что-то быстро крутить, и для больших гигантов, где за счет особенностей языка идет экономия на человеко-часах.

Поэтому разумно взять php (для маленького-среднего магазина), и java (для тяжелого, ну тут уже сами люди понимают требования).

2) Если все же нужно написать на Django магазин, то после вот этого видео ты поймешь как работает Django. Дальше уже документация и большая задача по написанию того, что уже давно сделано для платформ на php (https://www.youtube.com/watch?v=IZqBTPmxoew)

3) Django-oscar - только лишняя зависимость и дополнительные проблемы с освоением, при минимальном числе плюшек.

Все банально.

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

Модель тега:

class Tag(models.Model):
    name = models.CharField(max_length=25, default=1)

    class Meta:
        verbose_name = 'Тег'
        verbose_name_plural = 'Теги'

    def __str__(self):
        return self.name

Вывод many_to_many в шаблон через django теги

Поле тег

class Article(models.Model):
    ...
    article_tags = models.ManyToManyField(Tag, related_name='tags_for_article')
    ...

Вьюшка

 articlitem = Article.objects.all()

Шаблон

{% for tag in  articlitem.article_tags.all %}
    <p class="articles_tags">{{ tag.name }}</p>
{% endfor %}

____

Вытаскиваем статьи по тегам во вьшке (в данном случае если тег, совпадает с тем, что имеет статья-глава):

additional = Article.objects.filter(article_tags__in=articlitem.article_tags.all()).

Привет:

1) Добавляешь в модель поле хранения изображения, например ImageField:

avatar = models.ImageField(upload_to='', blank=True, null=True, help_text="Идеальный размер 150 на 150 пикселей",)

2) Если формы автоматически создаются из модели, то это поле уже появилось, если формы руками собираешь, то получаешь что-то по типу в файле forms.py:

class Profile_Form(forms.Form):
    avatar = forms.ImageField(label='Загрузить Аватар', required=False)
    myself = forms.CharField(....)
    myoffer = forms.CharField(...)

3) Прописываешь в settings.py локацию хранения файла, например:

MEDIA_ROOT = os.path.join(BASE_DIR, 'media')
MEDIA_URL = '/media/'

4) Добавляешь в саму html-форму обозначение, что ты с неё можешь брать мультимедиа-файлы:

<form action="/update_profile{{ useritem.id }}" method="post" enctype="multipart/form-data">

5) Добавляешь граб изображения в обработчеке формы.

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

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

Поставил вот так, вроде заработало.

location /static/ {
            root /home/bakotiinii/lieman;
			access_log off;
			expires 15d; 
        }

        location  /media/ {
            root /home/bakotiinii/lieman/;
			access_log off;
			expires 15d;
        }

Это допустимый вариант?