Arris

Соберите php из исходников, какие проблемы? Раз вас всё равно интересует разработка модуля под ещё разрабатываемую версию PHP - то иметь дерево исходников самого php под рукой банально удобнее чем полагаться на некоторый сторонний репозиторий.

Кстати, вы совершенно не указали какой именно вы используете репозиторий. PHP7.4 на данный момент RC6. Значит это гарантированно не штатный репозиторий centos.

лучше хранить логи в отдельной базе данных
еще лучше - в более подходящей для этого (например elasticsearch)

Господи, в который раз-то уже?

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

Самое главное, что надо понимать про эмвэцэ.
Это не 50% твоего приложения. И даже не 10.
Это тонюсенькая прослоечка, которая обслуживает только один канал общения твоего приложения с внешним миром - браузер. Есть и другие каналы, их много.

Исходя из этого, получается что

• Модель входит в эту тройку чисто номинально. Поскольку это и есть все твое приложение, только без интерфейса. И к модели обращаются не только веб контроллеры, но и консольные скрипты, REST контроллеры, сервер очередей и прочее. Отсюда становится понятно, что "модель - это запросы в БД в основном-то" - это дикая чушь.
  
• Контроллер - это, как правильно нарисовано на картинке в соседнем ответе - это такая официантка, подай-принеси. Принять запрос от НТТР клиента, преобразовать в понятный для модели вид, запросить модель, получить ответ, вернуть что-нибудь клиенту. Также может заниматься чисто браузерными заморочками типа заголовков, авторизации и пр.
  
• Вью - если модель вернула что-то для показа клиенту, то вью это превращает в понятный для браузера вид.
  
• Роутер - не упоминается, но незримо присутствует. Преобразует НТТР адреса в вызовы контроллеров.
  

Традиционно рекомендую доклад Дмитиря Елисеева с ПХП Раша 2019, там все раскладывается по полочкам.

Блин, столько ответов, и на столько схожая ситуация, что не могу не оставить свой опыт.

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

Что на счет стресса, выгорания и прочего? Мне помогает расслабиться просмотр детективного сериальчика на досуге. Кладу большой болт на все и расслабляюсь. Спустя пару дней,как будто ничего и не было.

Что на счет знаний, я тоже очень много не знаю, но я знаю. где найти то что мне нужно и заставить это работать. Это тоже относиться к умению адаптироваться на работе.

И поверь мне, у тебя не все так плохо как может показаться, бывает и хуже.

Вы на этапе "Долины отчаянья", это пройдет.


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

Для начала максимально полно отстроить восстановление. Любые ресурсы закончатся , если тратить их без восполнения. Что я имею ввиду ? Это кажется ерундой, но на большой дистанции очень важно. Сон, спорт, нормальное питание , прогулки, хобби , поездки, общение. Некоторые рекомендуют витамины и так далее, но имхо это не самое важное. Простые вещи - Режим, спорт, позитивные занятия. Тушка и нервная система скажут вам спасибо. Только это должно стать привычкой. Инстинктом.
Далее... если есть ощущение , что прогресса нет , постоянный стресс, опять же ,имхо ,возможно, стоит поискать другое место работы. У меня была похожая ситуация. Я работал в команде гораздо более сильных разработчиков и постепенно ощутил полную загнанность. Они легко жонглировали всякими "эластик серчами" и прочими "монгами диби" , а мне нужно было врубаться во все это сходу, что не получалось, скажем прямо . Все время не покидало ощущение, что бегу "галопом по европам" , не уверен в качестве того, что делаю, вынужден быстрее закрывать таски в jira и тому подобное. В общем, после года работы в проекте я вежливо попрощался. Сейчас нашел более подходящий мне объем и профиль работы. Продолжаю изучать новые штуки , удовольствие от программирования не пропало. Есть идеи для своих проектов. А иначе зачем это все ? :)

Лол, добро пожаловать в веб-программирование. Оно немного не такое радужное и весёлое, как рисуют в статечках на Хаброчке и комиксах от XKCD, да?

Мой совет - меняйте сферу и/или место работы. Начните со второго, очевидно, это какая-то веб-студия с бесконечным потоком.

Нет, серьёзно, смените место.

что должен знать идеальный джуниор (мое личное мнение):

- Сетевой стэк. Нужно иметь хотя бы базовое представление о том как с сервером общаются. Ну то есть не нужно лезть в дебри, но понимать что такое HTTP или чем TCP от UDP отличается - нужно. В целом это пара часов чтения википедии.
- GIT или любая другая распределенная VCS. Базовые навыки, что бы хотя бы понимал что есть git revert или git rebase, что такое фичабрэнчи и примерное представление как это работает и зачем надо.
- Базовые основы unix. Ну то есть что бы не пугаться таких вещей как ssh хотя бы.
- PHP. Без этого никуда. Он должен понимать что такое слабая динамическая типизация (не заучивать табличку кастов типов, а понимать плюсы и минусы, такая же история с приоритетами операторов - не заучивать а знать как избегать проблем с чтением кода)
- Понимать что код чаще читают чем пишут, а потому не экономить 5 минут на написании кода, а писать так, чтобы сэкономить 30 минут человеку, разбирающемуся в куске кода.
- Знать базовые вещи в плане безопасности. XSS и как защищаться, SQL инъекции и как защищаться, CSRF, MITM. Понимать что такое NDA, что данные пользователей - секретная информация. Как хэшировать пароли (не md5 а password_hash) и почему это важно.
- Знать SQL. Глубоких знаний не требуется, нужно лишь понимание того, что такое нормальная форма, желательно разобраться с вопросом денормализации данных. Идеально иметь хотя бы базовые представления о том как работать с NoSQL решениями.
- Процедурное программирование: почему глобальные переменные порождают сложность, что такое состояние, как можно использовать классы для изоляции состояния и т.д. Инкапсуляция. Инварианты, пост/пред условия, сохранение целостности...
- Разделение ответственности. Это один из важнейших принципов, и упрощать все это до "mvc фреймворк" слегка неправильно. Вы должны понимать что от чего отделяете и главное зачем.
- Автоматические тесты. Джуниор должен знать что это такое и иметь хотя бы минимальный опыт их написания. Должен понимать разницу между юнит и интеграционными тестами. Быть знакомым с пирамидой тестирования.
- Уметь решать стандартные задачи не задавая слишком много вопросов. Например регистрацию пользователя по email-у вы должны написать, или авторизацию через соц сети, или комментарии, или новостную ленту.
- Уметь дебажить. xdebug, blackfire и тд.

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

p.s. Я в списке специально не указывал ООП, поскольку всеравно первые пару лет у разработчиков выходит процедурщина на классах. Это не плохо, но того что в моем списке более чем должно хватать для решения стандартных задач. Но термины вроде "инкапсуляция/полиморфизм/наследование" требуются в обязательном порядке подавляющем количеством интервьюверов, а стало быть знать это надо. Единственное что - рекомендую в свободное время глубже погрузиться в этот вопрос а не тупо заучивать формулировки.

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

for (i = 1; i <= M; i++) {
	for (j = 1; j <= N; j++) print min(i, M + 1 - i, j, N + 1 - j);
	print '\n';
}

Сделал на php. :)

// Вводный данные
$height     = readline('Укажите высоту: ');
$width      = readline('Укажите ширину: ');
// Определяем центр
$middle     = ['j' => $height / 2, 'i' => $width / 2];

for ($i = 0; $i < $width; $i++) {
    for ($j = 0; $j < $height; $j++) {
        echo min(
            $i < $middle['i'] ? $i + 1 : $width - $i,
            $j < $middle['j'] ? $j + 1 : $height - $j
        );
    }
    echo "\n";
}

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

Всё это можно сделать в 3 строчки:

$queryString = parse_url($url, PHP_URL_QUERY);
parse_str($queryString, $getValues);
return '/' . ($getValues['a']?? '')
   . (isset($getValues['filter'])? '/filter': '')
   . (isset($getValues['deleted'])? '/deleted': '');

Разберите исходники на нужные дорожки и воспользуйтесь более наглядным MKVToolnix (можно даже через GUI), чтобы собрать все в один контейнер и расставить очередность/приоритеты/свойства.
Лично мне всегда западло с этими -map возиться, когда их больше двух, тем более - еще и метаданные через ffmpeg пытаться редактировать.

Разумеется нет.
Защищается то что вы сделали.
А то что кто-то сделал свою программу, которая делает то же самое что и ваше это отлично.

Допустим кто-то придумал программу основная функциональность которой - математические операции, калькулятор в общем.
И что теперь, другим нельзя калькулятор сделать?

1. Да
2. При 80к вставок - это одна вставка в секунду - я бы не заморачивался с временным хранилищем, даже при большом объёме уже имеющихся данных. Если составной индекс не включает текстовое поле - точно не заморачивался, тем более, если вы планируете переходить на другие хранилища) Ну и вообще, если вы решили оптимизировать, у вас реально проседает вставка? Сколько по времени идёт?