Андрей Леонов

Создать management комманду, которая получает выборку из ещё не запосченых постов, которые уже пора запостить и постит их.
Раз в 1/5/10 (как хочешь) минут вызывать эту команду cron'ом (или celery beat)

Нет одинаково эффективного пути для всех и каждого.

Я учился на конкретных задачах. Обучение практически всегда начиналось с состояния хочу сделать вот это (четко осознаваемый конечный результат), но вообще понятия не имею как это делать, и даже с какой стороны подойти и за что хвататься...

Тут главное - настолько сильно хотеть достичь результата, чтобы любые препятствия только добавляли азарта. Чтобы ночами спать не мог и думал о задаче. Это ключевой момент обучения. Все остальное - декорации, способы, инструменты...

Второй этап - осознание, что слона целиком заглотить невозможно в принципе, придется делить на части, т.е. декомпозиция. Причем задачу делить нужно неоднократно, до тех пор, пока решение конкретного участка задачи не начнет укладываться в пару страниц кода - модуль.

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

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

На первых порах, тестирование будет занимать до 99% времени и сил. Заодно подтягивается синтаксис используемых языков (вообще не важно каких), вырабатывается внимательность, концентрация, тренируется память и пр.

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

С этим не рождаются, это выкристаллизовывается за сотни и тысячи часов жесткого баттхерта от неспособности найти, где ты забыл поставить запятую... Когда код из 10 строк прочитан сотни раз вдоль, поперек и наискосок...

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

Обрати внимание, самое главное качество во всем этом многабукафф - упорство на грани фантастики. Любой, кто не дойдет до конца, не треснет себя по лбу в соты раз с воплем, так вот же она где, эта запятая, пропущена - сломается в самый неподходящий момент на боевом проекте...

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

Ах да, обложись справочниками по любому инструменту и научись быстро вникать и подхватывать необходимый минимум. Обычно достаточно на 20% владеть инструментом, чтобы решать 80% задач.

В любом случае я за критерий истины держу платежеспособный спрос.

from collections import Counter
x = open('Война и мир.txt', encoding='utf8').read()
c = Counter(x.split())  # Сплит нужен, чтобы вышел список слов, иначе посчитаем частотность символов
c.most_common()

Я бы завёл модель Invite с текстовым полем для хранения уникального идентификатора инвайта, ForeignKey на группу и, если надо, ForeignKey на User, которому инвайт предназначается. А также сделал бы view для ввода идентификатора инвайта. При правильном вводе идентификатора, пользователь добавляется в группу, а инвайт или удаляется или метится как использованный.

Только CBV.
Каждый метод имеет свой смысл, не всё вперемешку.
Можно юзать миксины.
Можно наследоваться.

Не будет ли плохим тоном, если в одном views будут и классы, и функции?

Я сразу отправляю переделывать.

Чтобы добавить N элементов в контекст, нужно написать N+2 строки. Это всего на 1 больше, чем у вьюхи-функции:

def get_context_data(self, **kwargs):
    kwargs['your_additional'] = 'context_here'
    return super().get_context_data(**kwargs)

В большинстве случаев используются Generic Views или миксины вроде FormMixin. Очень редко я наследуюсь только от View.

Snachala nado opredelit related_name dlya Vospitately.vospet_crushek

class Vospitately(models.Model):
    fio = models.CharField(max_length=40)
    dolshnost = models.CharField(max_length=80, default='Должность..')
    image = models.ImageField()
    vospet_crushek = models.ForeignKey(Cruski', related_name='vospitately')
    def __str__(self):
        return self.fio

Potom vo view mogno tak sdelat

def kruzhki(request):
    q = Cruski.objects.all()
    return render(request,'krushki.html',{'kruzki':q})

I nakonec v shablone pishem chto to po tipu takogo

{% block kruzhki %}
{% for krug in kruzki %}
<p><b>{{ krug.name }}</b></p>
{% for vospet in krug.vospitately.all %}
<p> {{ vospet.fio }}</p>
{% endfor %}
<p>{{ krug.description }}</p>
<p>{{ krug.price }}</p>
{% endfor %}

Vot i vse. Takim obrazom u nas vivoditsya krugki i vospitately kotorie v nis sostoyat.

Kstati vam bi opredelitsya stoit kak pisat "кружки":
- Cruski
- vospet_crushek
- kruzhki
- kruzki
- krushki.html

Мде… в modelform надо объекты передавать (либо есть — instance ведь)
Собственно надо было чтоб города фильтровались по стране. И всего лишь написать:

class UserProfileForm(ModelForm):
  
  def __init__(self, *args, **kwargs):
   
    super(UserProfileForm, self).__init__(*args, **kwargs)
    try:
      country_id = self.instance.country.id    
      self.fields['city'].queryset = City.objects.filter(country=country_id)
    except:
      pass
              
  class Meta:
    model = UserProfile
    exclude = ('deleted', 'deletion_date', 'blocked_until', 'activation_key', 'blocked_times', 'test_fails',)

* This source code was highlighted with Source Code Highlighter.