776166

Варианов два: на фронте и на бэке.
На фронте надо jsкриптить. На бэке можно сделать вьюху, в которую при изменении будет аякситься форма или целиком перезагружать страницу, перерасчитывая форму и возвращать её обратно.

0) Программировать.
1) Программирование = практика. Нужно писать код, решать задачи. Желательно, какие-то реальные.
2) Не столько читать, сколько программировать.
3) Определиться с языком, вернее, с отраслью. На C# не пишут сайты, на PHP не делают десктопные приложения, на objective-c не пишут демонов. На Pascal вообще не надо ничего писать.
4) Программировать.
5) Возраст сложный. Внимание концентрируется плохо. Порог вхождения в первый язык может быть и небольшим (что вряд ли), но проблема в диссонансе между ожиданиями и реальностью. Начать хорошо программить или программить вообще сразу не получится. Придётся себя заставлять. Придётся ощущать себя дураком, который ничего не может понять. Это больно, не все могут сразу въехать. Это — нормально. Терпение и труд. Не всё сразу. Главное — не бросать и что-то обязательно получится. Или наоборот, вы поймёте, что ну совсем не ваше. Это тоже нормально.
6) Желателен наставник. Желателен постановщик задач для решения. Для учащихся неплохой вариант с курсами. Там хоть какая-то программа есть, которую надо выполнять. Так проще учиться, когда тебя пинают, чем когда ты половину энергии тратишь не на учёбу, а на самопинание.
6) У Вас сейчас задача не стать хорошим программистом, а стать программистом вообще. Это труд. Трудиться тяжело.
7) Программировать.
8) Лучше сразу уходить на linux и начинать изучать всю современную it-экосистему. Это тоже важно и нужно. На практике. Больше практики.
9) По возможности, максимально скоро идти работать программистом — получать опыт.
10 ) Программировать.

И лично от себя. Не надо PHP для сайтов, если будет такая возможность, возьмите сразу Python.

UPD: Не могу не прокомментировать зложелателей. Какие же вы моральные уроды. Конченные мрази. Не надо обращать внимание на это мудачьё.

Ну как бы это разные вещи.
Если вам в процессе создания объекта нужна новая категория, то вы сначала добавляете её, потом обновляете форму объекта и едете дальше.
Технически это можно сделать по-разному. Например, после создания категории перееаяксить поле с категориями. Или перезагрузить форму целиком, но там свои ньюансы.
Как костыль можно добавить поля с новыми категориями прямо в форму создания объекта и при сабмите обрабатывать. Но я бы не стал так делать.

Это сложно. :(
По-хорошему, вам надо бы использовать DRF, но он к чертям взрывает мозги неподготовленным. Там очень много всего и слишком большая вариативность. Но можно и ручками это сделать, но там дофига тонкостей. Например, авторизация, которая тоже взорвёт вам мозг, если делать её руками. API по-сути, это просто определённые запросы к серверу, на которые он даёт даёт ответы. Обычно в JSON или частями кода (это удобно для форм). С другой стороны, освоение DRF обязательно. Всё равно придётся. Чем раньше, тем лучше.
Вторая проблема — необходимость изучать какие-то фреймворки для фротнтенда, хотя, по-началу можно и ручками с jQuery поковыряться.

В можете реализовать задачу примерно таким образом: Берёте любую страницу и по частям переносите её функционал с рендера сервером, на рендер из данных на клиенте. Запрашиваете у севрера по API данные, он их вам отдаёт, вы их рендерите JS. Будет трудно. Я сочувствую.
Если ваши модели хорошие, то вам не составит большого труда прикрутить более-менее полноценное API.
Но вообще, задача довольно сложная. Там и проектировать надо и API реализовывать.

Мнэээ…
1) Если не подписывались, значит это СПАМ и надо жаловаться. Чтобы бота банили к егерям.
2) Если подписывались, значит должен быть интерфейс отписки.
3) Если интерфейса отписки нет, писать владельцу бота, чтобы отключил вас и/или прикрутил отписку. Лучше, конечно, «и», потому что отсутствие возможности отписки —моветон и попахивает СПАМом.

Подключать статику надо только через {% static "[путь до файла]" %}

Судя по вашим комментариям в обсуждении, у вас или плохо проект спланирован в плане статики, или вы её неправильно подключаете. Относительные пути с ../ лучше вообще не использовать.

Скорее всего, правильный путь должен быть таким: /static/posts/js/jquery-3.3.1.min.js да?

В указанном случае поправьте фам сервис (/etc/init.d/memcached), но это очень плохой вариант. Вернее, не очень хороший. Можно свой персональный memcached поднять на другом порту со своими настройками, оставив дефолтный, как есть.

Опционально:
/var/run/ не очень предназначена для хранения данных (https://ru.wikipedia.org/wiki/FHS). Ваши данные надо класть в /tmp/memcached или даже в /run/shm/memcached

Django
[+] Не PHP
[+] Хорошо масштабируется
[+] Тонна батареек
[+] Удобно девелопить и весело деплоить
[+] Дружит с кешами для нагрузок
[+] Всегда найдёте разработчика

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

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