Константин Подыганов

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

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

setInterval(), setTimeout() — не точны. Для музыки/ритма/игры лучше полагаться на абсолютные метки времени и часы компьютера.

// в относительных единицах от старта песни
const hits = [ { time: 0 }, { time: 24 }, { time: 36 }, ];

// on play start
const timeK = 1200; // в зависимости от темпа
const playStartTime = Date.now();
const events = hits.map(hit => {
  hit.ts = playStartTime + timeK * hit.time;
  return hit;
});
// теперь у каждой ноты есть время ts, когда она должна сыграть

// внутри цикла requestAnimationFrame, который часто-часто,
// сраниваем текущее время с нотами,
// если разница менее 100 мс, ноту можно "играть"
const now = Date.now();
events.filter(note => Math.abs(note.ts - now) < 100).forEach(note =>play(note));

Наверное, надо смотреть и «в прошлом» пропущенные ноты – мало ли, комп притормозил.. И убирать сыгранные ноты из массива, чтобы не возвращаться к ним.

Самый простой вариант - поддерживать вектор из указателей на самые правые узлы во всех доступных уровнях.

Сначала читаете первую строку и создаете из нее корень дерева.

А потом в цикле читайте строку и считайте, сколько там пробелов. Их должно быть не больше, чем количество доступных уровней (т.е. элементов в векторе).
Добавляете текущую строку к узлу, который на уровне равном количеству пробелов (-1, потому что индексация с 0). Укорачиваете вектор до этого узла (все с уровенем ниже та вершина, к которой добавили ребенка - уже недоступно). Добавляете в вектор указатель на только что добавленную вершину.

В вашем примере.

Прочитали иван, сделали корень дерева. Вектор будет {"иван"} (указатель на вершину-корень дерева).

Прочитали алексей. 1 проблел - все хорошо, в векторое 1 элемент, значит может быть до 1 пробела. Добавили "алексей" к вершине "иван". Вектор {"иван", "алексей"}

Прочитали игорь. Вектор стал {"иван", "алексей", "игорь"}.

Прочитали андрей. 1 пробел. Может быть до трех пробелов, ведь в векторе 3 элемента. Добавили "андрей" к узлу из вектора по индексу 0 (-1 к количеству пробелов). обрезали вектор до длины 1 и добавили туда новую вершину. Вектор стал {"иван", "андрей"}

И т.д.

Для добавления вершины создайте новый TreeNode с нужной строкой и push_back в список детей для нужного отца.

замените * на +

Только отдельные таблицы, а ответы с вопросами можно получить одним запросом (было бы желание):

create table questions (
  id int primary key auto_increment,
  question varchar(255)
);

create table question_options (
  id int primary key auto_increment,
  question_id int,
  answer varchar(255)
);

select 
	q.question,
	json_arrayagg(answer) answers
from questions q
join question_options qo on qo.question_id = q.id
group by q.id, q.question
;

Результат:

+=============+============================+
| question    | answers                    |
+=============+============================+
| Question 1? | ["Answer 1?", "Answer 2?"] |
+-------------+----------------------------+
| Question 2? | ["Answer 3?", "Answer 4?"] |
+-------------+----------------------------+

Проверить SQL запрос

Не могу разобраться со схемой

Ну вот вам ваша схема.

Берёте переключательный тумблер на два положения и два направления, и соединяете как здесь нарисовано. В одном положении тумблера элементы будут параллельны (это для зарядки), в другом - последовательны (это для питания нагрузки).
Но вообще-то есть куда более удобный способ, при котором заряжать от обычной смартфонной зарядки можно оба элемента без их переключения. Покупаете на Алиэкспрессе вот такую аккумуляторную Крону:
Внутри неё два литиевых элемента и платка с балансиром и повышающим преобразователем напряжения. Штатные элементы удаляете и подсоединяете вместо них свои (соединение при этом будет последовательное). Затем в имеющуюся на этой платке втычку microUSB втыкаете шнур от любой мобильной зарядки. Далее следите за цветом светящегося светодиода. Красный - идёт зарядка, зелёный - зарядка закончена, зарядник можно отключить.
Кстати, на Али предлагается множество литиевых Крон, по моей ссылке это не единственная.

JSON

https://dev.mysql.com/doc/refman/8.0/en/distinct-o...

Смотря что содержится в config.php. Если он выполняет функцию возвращения массива, например:

<?php
return[
    'host' => 'localhost',
    'dbname' => 'MAYABASA',
    'user' => 'root',
    'password' => ''
];

То ничего скрывать не нужно, пользователь и так не сможет получить содержимое.

Если вы делаете вывод контента по средствам php и получаете содержимое через, например, file_get_contents($url), то в начале файла можно проверять ip адрес с которого поступает запрос. Если запрос делает только ваш сервер, то это может смотреться так:

if ($_SERVER['REMOTE_ADDR'] !== '127.0.0.1') exit();
echo 'Этот контент будет выводиться только для запросов с Ip 127.0.0.1';

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

Ну и напоследок, есть способ для защиты в .htaccess
RewriteRule ^/?some_path/config\.php$ - [F,L]