neol

password_hash всегда разный возвращает хэш, чтоб проверить нужно юзать password_verify.

password_hash - юзаем только при регистрации и смене пароля
password_verify - только при авторизации

Т.е. по логину достаешь запись из БД и через password_verify сравниваешь хэш бд с указанным паролем

По своему опыту могу сказать, что при переходе на удалённую работу(10 лет) из офиса(7 лет) мое развитие и производительность увеличились в разы.
1) В офисе ты можешь ничего не делать, а просто показывать лицо и с умным видом рассуждать о полиморфизме. На удалёнке тебя никто не видит, а видят только твои результаты- это обязывает шевелиться быстрее и только по делу.
2) В офисе ты слишком призязан к месту и организации, зачастую тебя берут на какой нибудь вырост, а в последствии могут дать поддерживать старую программку на фортране или на бейсике, или сунут печатать документы и рисовать рисунки и т.п. и ничего не скажешь. На удалёнке тебе легко поменять проект, если закончились твои задачи, ты смотришь на работу не как на что-то вечное и стабильное, а как на проект, на который тебя взяли из-за определенных скиллов, под конкретные задачи и от тебя ждут конкретные результаты.
3) В офисе тебя отвлекают разговорами, совещаниями, теннисом и т.п., купят тот стул и комп, который купят, а не который ты хочешь, на удаленке у тебя отдельная комната - как минимум, кресло и мощный игровой ноут (легко поднимающий виртуальные машины или докер-контейнеры), которые ты сам себе выбрал.
4) Да, экономия на времени, дороге, спорте, месте жительства само собой.
5) В офисе обучение предлагается/навязывается, но так как вроде положение там стабильное то и оно не так и хочется прям учится, на удалёнке ты понимаешь что это твое конкурентное преимущество и без обучения никак, ты ищешь, анализируешь, что в тренде и больше востребовано, и подгоняешь свои скилы под общие требования рынка, а не конкретной организации.
6) в офисе не особо поднимают тебе зарплаты типа никуда не денешься, а попросить неудобно, на удалёнке ты с каждым новым проектом пересматриваешь свою цену и приобретенный опыт. (ну хотя здесь немного вру, в офисе повышали нормально, после удачных релизов )

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

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

class CalculationData;

abstract class Calculation 
{
  public function calculate(CalculationData data);
}

class CalculationQueue 
{
  public function addCalculation(Calculation calculationVariant, int priority);

  public function calculate(CalculationData data) {     
     for (c in calculations) {
       if(res = c.calculate(data)) return res;
     }
  }
}

Уж не "Радио?.. Это очень просто!" ли?

Алан Бьюли очень прост, почитать конечно стОит, но скорее для упорядочения текущих знаний, чем получения новых)
По глубокому пониманию MySQL сложная, но хорошая книга MySQL. Оптимизация производительности. - позволяет взглянуть на многие вещи со стороны "почему так лучше", а не "так принято".

РАЗУМЕЕТСЯ, ни то ни другое

Хранить надо в отельной таблице, с колонками ид сущности, картинка.

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

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

Со стороны трудно оценить объем вносимых изменений - если это разовая работа, проще добавить в эту свалку костылей еще один и забыть как страшный сон.

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

Полный рерайт - это, возможно, остановка каких-то процессов на время рерайта. Маловероятно, что это допустимо.

У вас не переопределён символ конца запроса, из-за этого запрос CREATE PROCEDURE заканчивается на первой же точке с запятой.

DELIMITER $$
CREATE PROCEDURE ...
BEGIN
...
END$$
DELIMITER ;

Всё, что не важно для бизнес-логики, должно быть вне domain-слоя.
Разве бизнесу важно, как будет выстроен хеш пароля? (Несомненно, зависит от бизнеса, но в 90% случаев нет).
Спросите об этом доменного эксперта или хотя бы менеджера.
Они могут даже не знать, что такое "хеш" в принципе.

А интерфейс лежит в домене, потому что нужно как-то соединить это "неважно" с "нужно".

Даже если бы была только одна реализация, ее в примере вынесли все равно.

Можно ли положить в домене? Вы строите систему. Хотите, положите в доменный слой, хотите, вынесите в микросервис. Хотите, пишите на PHP, или на Go или на C++.
Как решите Вы, так и делайте.

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

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

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

Мне кажется вы не с той стороны на это смотрите, ps4 и пк - инстурменты для решения задачи "поиграть в игры", но игры на пк и на консоли отличаются, и я бы вам советывал делать выбор исходя из того во что вам играть хочется. Тк как будет старнно например покупать консоль если вы любитель шутеров или RTS.

В точке входа в проект (index.php), в самом начале выставить все по нулям

ini_set('display_errors', 0);
ini_set('display_startup_errors', 0);
error_reporting(E_ALL);

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

А на самом деле, кластер работает подобно команде сценаристов, которые пишут сценарий сериала из двадцати серий, работая удаленно по бумажной почте: сначала главный сценарист придумывает персонажей и общий сюжет, записывает это, потом ему нужно разбить его на серии и отослать каждому из сценаристов, указав, какую серию тому нужно прописать в подробностях. Если бы он писал все сам, ему бы понадобилось по неделе на серию, итого - двадцать недель. А съемки можно начинать, когда готова первая серия (через неделю). Поскольку съемки одной серии занимают три дня, съемочная группа будет простаивать четыре дня из каждой недели, пока не будет готова следующая серия (деньги во время простоя тоже расходуются, хотя ничего не производится). Съемки будут, таким образом, завершены через 20*7+3=143 дня.

Наемным сценаристам тоже нужно по неделе на написании серий, но начальная работа главного сценариста тоже занимает неделю, плюс - три дня на доставку "каркаса сценария" наемным сценаристам, три дня на доставку сценария серий обратно, еще пять дней на проверку и исправление нестыковок. Итог - начинать съемки можно только через 25 дней, а не через семь, но продолжать их можно уже непрерывно. Съемки будут завершены через 25+3*20=85 дней.

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

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

1. Есть DBA - ничего. Нет DBA - все.
2. Религия в основном.
3. Читать документацию. Пробовать.
4. Бекап перед апдейтом всегда.
5. Сравнивать самому на типичных для выбранного проекта нагрузках.
6. От задач отталкиваться. Вроде как MyISAM быстрее на запись.
7. Гугл, маны и практика.