Adamos

Что значит «хранится»?
• Значение nullptr хранится в переменной-указателе — как и любое &someObject.
• Объекта правильной «объектной» формы (если, конечно, у объекта присутствует какой-то инвариант или хотя бы таблица виртуальных методов) по адресу *nullptr нет; в большинстве ОС разыменование nullptr приводит к нарушению сегментации и мгновенному вылету (но не обязательно — например, DOS).
• Во всех известных мне ABI (x86/DOS, x86 и x64/Windows, x86 и x64/Linux) nullptr равен нулевому адресу. Это обосновано — по этому адресу обычно располагается таблица прерываний, точка входа, префиксный сегмент или прочая системная хрѣнь, сюда точно соваться не стоит. Но теоретически не обязательно. Этот адрес, естественно, общий для ABI, чтобы можно было объединять в одну программу результаты компиляции разными языками.

Самое простое - nginx отдаёт статику. На больших объёмах делать это через Ноду неэффективно.
Посложнее - nginx позволяет управлять ходом запроса. Например, редиректить на https.
Ещё сложнее - можно настроить nginx, чтобы он умно балансировал запросы между несколькими бэкендами и автоматом блокировал слишком частые попытки подключения.

Nginx очень хорошо в промышленных масштабах делает определённую часть работы, связанной с http-запросом, поэтому ему эту часть работы и делегируют.

Почитайте для начала, может передумаете
https://habr.com/ru/post/541196/

Извини, дорогой друг, но не работает, потому что ты ленивый рукожоп.

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

Суперглобальные переменные ($_GET, $_POST и т.д.) потому так и называются, что доступны всегда и из любого места.
Вы назвали параметр своей функции _POST и таким образом пытаетесь перезатереть суперглобальную переменную. Так делать нельзя.
Все будет работать, если убрать _POST из параметров (и не передавать его при вызове - он и так отовсюду доступен).

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

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

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

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

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

в общем: все зависит, универсального ответа нет.

ну и стоит отдельно определиться, что подразумевается под сырыми запросами: квери-билдер или прямой доступ к базе. последнее я практически не использую.

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

if (!glfwWindowShouldClose(pWindow))
  {
    isClosed = true;
    glfwTerminate();
    return;
  }

Если не было события о закрытии окна, то завершить glfw. Почему же окно закрывается?

В общем, проблему решил. Теперь по порядку.
Причина проблемы? Кратко: Wine.
Подробнее: В моем случае это был CrossOver. Дело в том, что при изменении/удалении/отключении видимости НЕКОТОРЫХ Windows ярлыков в бутылке, а конкретно в настройке "Редактировать меню" бутылки, происходит обновлении файлов конфигураций содержащих информацию о ярлыках в меню пуск. Один чел из забугра пишет, что Wine для построения имен для ярлыков(и не только) использует кодировку ANSI вместо нужного нам UTF-8 и в результате может случится так, что в конфигурацию меню будет занесено не читаемое название. В народе их еще называют крякобрязы. Решил проверить лог через Looking Glass и там действительно при запуске аплета menu@cinnamom.org была ошибка UTF-8 при чтении файла, но не было написано какого именно файла. Первый файл пришедший в голову, это конечно же cinnamon-applications.menu расположенный в /home/USER/.config/menus и это верно. Там действительно было строка с крякобрязами в разделе Menu. Переименовал просто в Menu. Проблема с кодировкой решилась и в логах ошибка UTF-8 больше не высвечивалась. Но основную проблему исчезновения меню она не решила и пришлось пробовать все подряд попутно в поисках информации в сети.

Выполнил целый комплекс мер. Перечислю какие. После каждого пункта я делал перезапуск Cinnamon на всякий случай. Просто нажимаю на CTRL+ALT+Backspace
1. В домашнем каталоге удалить файл ~/.config/menus/cinnamon-applications.menu
Судя по отзывам, в 50% случаях это помогает.
2. Полная очистка папки ~/.config/menus/
Поможет в 70% случаях
3. Сброс настроек Cinnamon. Правая кнопка мышки на панели > Устранить неполадки > Сбросить все настройки. Поможет в 75% случаях.
4. Переименовать папки menus и dconf например в menus2 и в dconf2 и быстро сделать перезапуск Cinnamon нажав на CTRL+ALT+Backspace. Поможет в 80% случаях.

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

Теперь подходим к тому, как в моем случае решилась данная проблема. Проблемные ярылки Windows в CrossOver которые я удалял, на самом деле не удалились и именно они не давали запускаться аплету меню. Находятся эти ярылки в домашней директории ~/.local/share/applications/ выберите и удалите оттуда ярлыки которые вы хотели убрать через CrossOver.

Нормальная миграция подразумевает следующие характеристики:

• идемпотентность - будучи запущена, серия миграций приводит к одинаковому результату
  
• обратимость - любой шаг миграции можно откатить с откатом версии приложения
  
• целостность - миграция переводит приложение из рабочего состояния в рабочее (баги не в счет)
  

Естественное применение миграций - это CI/CD. Т.е. в большинстве случаев ожидается минимальный простой приложения во время деплоя, именно поэтому миграции в большинстве своем изменяют структуры данных.
Но это совсем не означает того, что данные не могут быть изменены. Часто так бывает, что некоторые системные справочники требуют обновления или же данные пользователей требуют изменений. Например - для имени и фамилии использовалось одно поле, а теперь оно делится на два, как положено. Миграция данных в данном случае естественный и необходимый процесс, который может занять значительное время. Поэтому используется запланированный процесс выкатки приложения с его аннонсированием для пользователей. Запланированный даунтайм стандартная практика больших и сложных приложений, которые могут это себе позволить.
Если ваше приложение не может себе позволить остановку обслуживания пользователей, то для таких случаев пишется вспомогательный код, который делает обработку случаев немигрированных данных и вообще всевозможные костыли, лишь бы оно работало (основной источник гемора).

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

Итак, мои ответы по вашим вопросам (как бы делал я):

1. Добавил бы миграции с внесением/удалением 2 новых столбцов. Первый для email, второй email_verified. После развертывания запустил бы скрипт верификации почты (ох нескорый и ненадежный этот процесс). По-хорошему, по первому логину просил бы проверить и верифицировать email путем отправки кода на него. Думаю, вы уже поняли, что мы попадаем в серую область того, что машинная проверка здесь неуместна. Но допустим, мы использовали машинную верификацию, все проверили, все нужно сделали. В следующей версии мы удаляем столбец email_verified.
   
2. Как правило, такие вещи данные в БД не изменяют, а значит нет необходимости в миграциях, достаточно скрипта. Но, если вы ок с простоем приложения, то можно вполне внести данный скрипт в миграцию, а также не забыть об откате этой миграции (удалять новые размеры, к примеру).
   

Как мы все видим, миграцию можно рассматривать, как в контексте СУБД, так и в контексте приложения в целом.
Общепринятая практика - рассматривать миграцию в контексте баз данных. Все остальное - скрипты и костыли в самом приложении.

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