Александр Нестеров

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

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

Я спросил сайт, получил json.
skip
Мне надо прочитать файл с помощью функции jsob.loads(),

Так ты же уже получил json, зачем тебе читать какой-то файл? бери поле из json, это же структура, а не единичное значение

Репозитории на Github, Gitlab

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

Получилось ли выучить иностранный язык, просто зазубрив слова? Или выяснилось что и слова надо запомнить и практиковаться много раз, чтобы как-то начало получаться?

Алгебру - достаточно ли просто зазубрить что такое + - * / %, чтобы решать все задачи, или приходится на практике решать кучу задач, чтобы научиться это делать быстро?

Программирование НИЧЕМ не отливается от любых других направлений. Нужно и зубрить теорию и заниматься практикой, нельзя делать что-то одно. И высчитывать процент - это зачем? каждый человек немного уникален, у каждого процент будет свой.

Для этого нужно написать срипт, который будет запускаться на сервере, и будет сам запускать .EXE, после чего сгенерированный файл выдавать в STDOUT.

P.S. Каков вопрос - таков и ответ. Нет подробностей - тогда и ответ без подробностей.

Вижу тег wp, а значит:
https://developer.wordpress.org/rest-api/
https://github.com/wp-graphql/wp-graphql
WP как админка, а front как сайт. Дешево, с душком, но простые задачи решает.

Здравствуйте, изучаю веб-разработку не так давно, но уже слышал про CMS

Предположу, что с такими знаниями будет тяжело тянуть отдельно wp и отдельно front.

И насколько вообще важная штука CMS, и как частно нужно будет с ней работать?

Зависит от требований заказчика, от 0 до 146%.

Вариант А: Если на сайте есть функция "рандомное видео", научиться делать запрос к ней.
Вариант Б: Стырить Соскрапить с сайта список всех интересующих видео, выбрать рандомное из этого списка. Список можно обновлять время от времени.

Тут какая то порнография с отступами, методами и их параметрами.

def process_shot(user_id):
    global cur, con
    return True
    return False
success_rate = get_upgraded_success_rate(user_id)

Это вот вообще как? Зачем? Метод то закончился, откуда user_id возьмется

Вы не смогли перевести текст ошибки?

что-то по лучше, чем MySQL

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

Все хорошо у MySQL с ресурсами.
У вас сейчас нет соцсети с миллионами юзеров, поэтому вам не нужна никакая навороченная сверхпроизводительная архитектура и бигдата.
Когда упретесь в производительность вы сперва подкрутите настройки того-же мускула, потом распараллелите, потом часть данных вынесете в какой-нибудь редис, и только когда и этого будет мало, вот тогда вы задумаетесь о смене основной БД.
К этому времени вы уже будете иметь представления какие у вас посты, сколько их, где у вас в архитектуре узкие места, и будете неплохо представлять какие есть альтернативы.
Альтернативы конечно и сейчас есть, но они вам не нужны в данный момент - больше мороки с ними, чем пользы. Ну выберете вы сейчас метро, например, будете инвестировать скиллы и время в рельсы, а в тоге окажется что вам нужно не метро и не самоствалы, а больше подошли бы нефтеналивные танкеры. Вы заранее не можете предсказать что и как у вас будет устроено.

Целиком в БД сохраняют с тегами HTML, или Объектом JSON

Начать можете с подхода "храним в том виде в котором пришло с клиента, перед показом чистим".
Это позволит на лету подправлять тот функционал что перед показом, и заплатите вы за это только некоторым количеством процессорной нагрузки.
Когда он окончательно утвердится, можно перейти на "чистим пред сохраннением в БД", что сэкономит ту самую нагрузку (очистка ровно один раз), но сразу упадет гибкость, так как данные, которые вы удалили при чистке уже не восстановить.

Тяжелые медиа, типа видеороликов, вы довольно скоро вынесете в отдельное хранилище, как только заметите что у вас этих одинаковых роликов тысячи, и неплохо бы к ним дедупликацию прикрутить.
А как хранить эмоджи - практически не важно.

Неправильно.
Названия переменных и функций должны быть говорящими, чтобы их назначение сразу было понятно. Урезать названия до пары символов, лишь бы было покороче, - очень плохо.
По пробелам, пустым строкам, отступам и пр. есть стайлгайды - рекомендации по оформлению кода. Например, PSR-1 и PSR-12 для PHP, Google Style Guide и Airbnb Style Guide для JS. В компании может быть принят и какой-то свой стайлгайд.

Не правильно.

Код должен быть читаем и понятен человеку. Причем, не только автору, но и «злому маньяку тим-лиду, который вооружен и знает, где вы живёте», как говорится в шутке программистов.
Для этого пустые строки между блоками кода бывают полезны. Как и комментарии, и длинные осмысленные наименования переменных и фукций.
Компилятор потом всё равно всё перелопатит по-своему в ацкие бинарные инструкции )

Как форматировать код — договариваются. Есть общепринятые стандарты форматирования кода (coding style). Например, стандартный для PHP. Или принятый в компании AirBnB для JavaScript.

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