Михаил Р.

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

А бесплатных курсов и репетиторов тут нет.

Привет

1) Для начала тебе нужно определиться с тем, что ты хочешь делать по итогу. Т.е. если запустить какой-то свой проект, то php/python. Если тут нужен асинхрон или научиться асинхрону, то node.js. Если хочешь работать устроиться куда-то в банк, то Java/C#. Т.е. выбирай инструмент под задачу, а не задачу для инструмента.

2) Python - универсальный язык, который может делать многое. Вопрос, что не всегда это можно сделать эффективно. В общем, если нужен асинхрон и много соединений то бери node.js, если нужно другое - то бери Python.

3) Не понимаю разницы между обычными сайтами и веб-сервисами. Вопрос сложности реализации - основа то везде одинаковая. Будешь делать сервисы, будешь уметь делать обычные веб-сайты.

4) Если для личного развития, то можно. Если для работы, то нет. Скорее всего ты будешь работать либо на php, либо на python, либо на node.js - и там уже сможешь детально рассматривать все нюансы и стек. Учить все сразу - не учить ничего.

5) Судя по тому, что ты описал в требованиях, Java тебе не подходит. Тут либо должна быть цель устроиться в какую-то большую компанию под сложный проект, либо должно быть четкое понимание того,что ты будешь делать, и почему ты хочешь взять именно Java.

Вопрос: Ты чем заниматься хочешь в итоге? Что-то для себя пилить, работать на фрилансе или пойти в какую-то контору (стартап или гиганта типа Яндекса, Меил.ру?)

Если ты учишься и хочешь навыки развить, что бы в будущем тебя кормило программирование, тогда мой совет такой. Начинай изучать python и javascript. Реальность такова, что без js не напишешь фронт, а python имеет множество библиотек под все задачи. Py очень понятный язык, js не очень понятный.

Есть проект PonyORM + PonyJS + ReactJS https://www.youtube.com/watch?v=6AWL4iSfZXU
За такими технологиями будущее, python на бэкенде и react на фронте.

Выбор ЯП и стека вещь сугубо субьективная. Параметров слишком много, чтобы можно было объективно сравнить.
Все перечисленные технологии популярны и в ближайшиее 5 лет будут востребованы. Выбирай то что нравится.

В пользу Node: всё идет к тому, что js станет стандартом как на фронте, так и на сервере. Через 5 лет серверную часть не на js будут писать только ленивые ретрограды.

Ну-ну. Или стухнет как руби.

Приложения получаются быстрее python и др. в 10-15 раз, выдерживают большие нагрузки,

У JS нет превосходства в производительности над Python. Скорее наоборот. Но в целом я бы не рассматривал производительность как фактор выбора, т.к. в первом приближеннии она одинакова.

нет задач, которые нельзя было бы реализовать в рамках MEAN-стека.

Можно так и про ассемблер сказать, но это не делает его удобным для веб разработки.

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

Некоторые косяки действительно будут исправлены. С монгой все поигрались и забыли, вернулись к реляционным БД. Express.js это наколенная поделка, которую можно написать за один вечер. Там по сути кроме роутинга ничего нет. Может быть черзе 5 лет на ноде появятся какие-то полноценные фреймворки типа Джанги, Рельсов или Симфони, но на сегодняшний день их нет. Angular это вообще фронтенд, его можно с любым бакендом использовать.

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

Они не отказываются. Скорее происходит отказ от "парадигмы" разработки. Языки стали мульти-парадигменные. Посмотрите на С++20 или Scala. Их невозможно положить в коробочку ООП или ФП. В них есть почти полный набор фич и оттуда и отсюда. И с каждым годом число фич растет и граница размывается. Нашим потомкам будет вообще непонятно где идет раздел.

По поводу golang. Это язык ограниченной разработки. Его создавали специально чтобы порог вхождения был низкий. Фактически делали лайтовый С++ которому можно обучить школьника за 14 дней. Но с перформансом выше чем у Питона. Поэтому выражать какие-то сложные конструкции на типах там скорее всего не получится. У golang есть свой манифест. Я забыл как он называется и где он. Вобщем там довольно четко обоснованно почему такие принципы и почему такая идеология.

Дело в том что курсор может потреблять ресурсы. Например вы захотели взять первые 10 строк из 10000000 выборки но предварительно отсортировали. Выбрали 10 строк и не сделали финализирующие протокольные действия в Python. База данных будет удерживать в памяти алгоритмы и структуры данных для снапшота результата этого запроса до тех пор пока не придет явный CLOSE с вашей стороны либо интеллекуальный драйвер который еще и обладает логикой уборки мусора сам не догадается что Statement уже вышел из scope вашего использования и может быть удалён GC.

Я был свидетелем ситуации когда крупное ent-приложение Java/Oracle переполняло память из-за неверной обработки Exception и плодила много незакрытых курсоров в БД. Java от этого не сильно страдала (GC всё убирал) но страдал Oracle. Потому что уборка происходила слишком поздно. Пофиксилось тогда переписыванием с try на try-with-resources.

Поэтому если вы неряшливо обращаетесь с курсорами (явными и неявными (обычный select к примеру может прождать неявный курсор)) то не ваше приложение а база данных почувствует себя плохо. Как быстро и какие ошибки вы будете получать - зависит от настроек вашей БД.

кол-во вакансий у RN в раза 2-3 выше

Это.

1. Зачем парсить, если существует куча сервисов с API?
2. По geoip или как-нибудь ещё узнаешь локацию пользователя, и сопоставляешь со страницами на сайте.
Например если пользователь в Алматы, то парсишь https://www.gismeteo.kz/weather-almaty-5205/
А если в Астане, то парсишь https://www.gismeteo.kz/weather-astana-5164/

Все уровни выше users_on_lessons называются денормализацией - хранить эти данные необязательно, их можно вычислить из других по цепочке связей.
"Правильно" в данном случае не существует, вы выбираете на каждом конкретном проекте между скоростью и консистентностью. Храните денормализованные данные? Тогда придётся обеспечивать их связность, чтобы не оказалось, что в users_on_lessons пользователь привязан к одному топику, а в users_on_topics к другому. Храните только "жёсткие" данные? Тогда будьте готовы считать нужное.

Я в данном случае не вижу необходимости в денормализации в том виде, в котором вы её реализовали. Курсов относительно немного (а пользователь всегда работает только с одним из них в момент времени), в каждом курсе относительно немного глав, в главе немного топиков, в топике немного уроков. Посчитать по уроку где там пользователь в этом дереве совсем не сложно прямо на клиенте, а ведь ещё у нас есть возможность кешировать данные.

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

function groupValues(arr, defaultValue = null) {
  const keys = [...new Set(arr.flatMap(Object.keys))];
  return arr.reduce((acc, n) => {
    keys.forEach(k => acc[k].push(Object.hasOwn(n, k) ? n[k] : defaultValue));
    return acc;
  }, Object.fromEntries(keys.map(k => [ k, [] ])));
}


const result = groupValues(arr);

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

const groupValues = (arr, defaultValue = null) =>
  arr.reduce((acc, n, i, a) => (
    Object.keys(n).forEach(k =>
      (acc[k] ??= Array(a.length).fill(defaultValue))[i] = n[k]
    ),
    acc
  ), {});

const items = document.querySelectorAll('.item');
const sorted = [... items].map(item => item.dataset.id);
console.log(sorted);

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

когда лучше реляционную и нереляционную использовать?

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

Как только осознаёшь этот простой факт, то всё сразу становится на место:
Если нужна база данных, то и использовать надо базу данных. Реляционную. Какую именно - в вашем случае не принципиально.

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

Вливайтесь в сам проект по развитию Python-а. Там же много работы: Перевод, документация, библиотеки, CPython и др. Да. Сразу будет жесть как тяжело, но зато потом, потом будет такая визитная карточка, что достаточно быстро будете находить новую работу.

1) Выбираешь проект (для начала небольшой), которым пользуешься сам.
2) Смотришь список issues
3) Выбираешь ту, которую сможешь сделать сам (для начала лучше поправить небольшую багу)
4) Форкаешь проект
5) Реализуешь issue
6) Гоняешь тесты
7) Если всё ок, делаешь пулл-реквест автору
8) Повторить

Ну и главное, надо следовать общему стилю всего проекта и про pep-8 помнить.