Сергей Протько

https://en.wikipedia.org/wiki/IEEE_754-1985

в PHP оператор умножения имеет левую ассоциативность, то есть выражение выполняется слева на право. В вашем случае - по порядку.

$d4 = ((((6031 * 8109) * 980) * 1909) * 429) * 1714;

$filmActors1 = array_column($arr1, null, 'eng_name');
$filmActors2 = array_column($arr2, null, 'eng_name');

$actors = array_intersect_keys($filmActors1, $filmActors2);

Ох...

Model View Controller. Да ну его, ему уже 45 лет (придумали в 79-ом году). Давайте лучше про Model View Adapter погокорим. это то что все используют в популярных фреймворках последние лет так 10 так точно.



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

View - это не только HTML, но и вообще представление в целом, а так же логика его формирования. Шаблонизаторы, фильтры, различные функции/объекты помогаютщие нам сформировать view (например форматирование дат, сериализаторы и т.д.) В подавляющем большинстве случаев "представление" наших данных - это HTTP запросы и HTTP ответы. HTML - э то лишь часть HTTP ответа.

Model - Это целый слой, который может быть представлен в виде кучи отдельных объектиков, структур и т.д. Его задача - делать дела и хранить/менять состояние системы. Тут легко запутаться потому что термин "модель" много чего значит. Воспринимайте его как "слой логики" а не конкретные объекты. И да - база данных и прочая чушь - это детали реализации этого слоя. "не важные штуки" словом. Туда же и ActiveRecord, ORM-ки всякие. Это деталь реализации и все остальные чуваки (view и controller) о них знать ничего не должны (хотя иногда могут в целях упрощения).

Controller или адаптер. Это опять же не обязательно один объект. это может быть цепочка адаптеров (еще называют фронт-контроллером, middlewares и т.д.). Его задача весьма простая. Получаем представление данных на входе (HTTP запрос), определяем что надо делать, и просим модель что-то сделать (ни в коем случае не меняем ничего самостоятельно в контроллере, он только просит). Потом мы можем попросить модель вернуть нужный нам кусок состояния, и попросить View сформировать представление (HTTP ответ).

Как-то так. В целом же это я сейчас описал "идеальный мир". Вся суть этого подхода - разделение логики презентационной и логики приложения. Зачем это надо? что бы было проще жить! Обычно UI приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

Но на начальной стадии можно слегка нарушать эти правила, делать толстые контроллеры и т.д. В этом случае бизнес логика будет потихоньку "вытекать" из модели. Это не хорошо, и на хоть сколько нибудь больших проектах может привести к проблемам. Потому важно находить баланс.

Ну дак в чем собственно вопрос, стоит ли делать подобные жертвы ради производительности?

Нет, достаточно просто настроить opcache нормально:

1) использовать автозагрузчик который генерит вам composer (обязательно с флагом -o, тогда он сдампит жирную мэпу классов и не будет дергать файловую систему просто так)

2) Отключить инвалидацию кэша в opcache (opcache.validate_timestamps=0) и сбрасывать кэш вручную при деплое

3) проверить через API opcache как там по выделенным ресурсам. Для вашего теста скорее всего дефолта хватит за глаза. Для больших проектов уже можно поиграться с размерами буферов. Читать в документации о функциях opcache что бы статистику собирать.

4) обновитесь до php7

p.s. среднее время ответа для простеньких запросов - 30ms, память - 10-15Mb. Если запускать симфони в php-pm, то запросы отдаются за ~10-15ms, потребление памяти на запрос посчитать немогу (так как все запущено как демон). Но этот вариант пока рекомендую для очень простых апишек где нужна скорость реакции системы.

помимо GET/POST есть еще PUT/PATCH, а еще нынче часто присылают в качестве тела запроса JSON. И работать с сырыми заголовками/телом ответа как-то не очень удобно. А еще есть проекты типа php-pm которые поднимают свой HTTP сервер из под CLI, то есть вообще другое SAPI.

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

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

Неужели чтобы написать даже самую простую CMS для личных элементарных нужд придется изучать куча всего другого чтобы выстроилась точная картина о ее разработке?

нет, если вы не будете писать велосипеды и возьмете фреймворк как готовую основу.

но интерес составляет написать самому

Начните с фреймворка:

- библиотека для рендринга шаблонов (буферизация вывода, работа с файловой системой немножко)
- библиотека для маршрутизации запросов (прошаритесь в регулярках)
- библиотека для работы с базой данных (не ORM, начните с Table Data Gateway или DAO хотя бы. Прошаритесь в SQL минимально).
- Ядро, связывающее все это вместе. Желаельно с какой-то концепцией мидлвэров, что бы все остальныекомпоненты ничего не знали о ядре. (прошаритесь в HTTP)

В целом же писать CMS очень и очень скучно и долго. Вы намного быстрее прошаритесь во всем что надо делая отдельные компоненты. Благо сейчас век composer-а и вы можете крутить и вертеть фреймворками как хотите, подменяя чужие компоненты на свои.

php.net/manual/en/function.ip2long.php
php.net/manual/en/function.long2ip.php

то есть работаем с IP как с числом.

updated

добавил свой вариант функции:

function ipRange($startIp, $endIp) {
    $start = ip2long($startIp);
    $end = ip2long($endIp);

    return array_map(function ($ip) {
         return long2ip($ip); // нам не надо проверять эти условия с нулями и 255.
    }, range($start, $end));
}

Никакого отношения сингелтону этот код не имеет.

с какой целью его автор создает экземпляр объекта в статичном методе

У этого приема много названий. По сути это статический метод-фабрика, еще можно встретить "именованный конструктор".

class User {
    private function __construct($email, $password) { /* ... */}
    public static function create($email, $password) { 
         return new static($email, $password); 
    }
    public static function createWithProfile($email, $password, UserProfile $profile) {
         $user = static::create($email, $password);
         $user->profile = $profile;
         return $user;
    }
}

$user1 = User::create('example@example.com', 'example');
$user2 = User::createWithProfile('example@example.com', 'example', new UserProfile(
    $firstName, $lastName, $avatar /* ... */
));

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

Отличие тут в том что мы не возвращаем экземпляр класса, он однаразовый. Только для этой последовательности.

Почему бы не сделать так, спросите вы:
(new Reboot())->reboot();

Потому что нам не нужен этот инстанс. Функция reboot ничего не должна вернуть, а объект который создается - одноразовый. Почему так - надо смотреть в контексте. При работе с процессами я могу придумать десяток кейсов когда это надо.

По сути можно было бы спокойно сделать это обычной функцией, но автор посчитал что так будет читабельнее. Говнокод часть тут только имя класса - Reboot. Имена классов, интерфейсов и т.д. должны быть существительными. Мы описываем тип объектов. Но это единственное место к которому я могу придраться.

time выдает время в UTC

The documentation should have this info. The function time() returns always timestamp that is timezone independent (=UTC).

Условия Йоды

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