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

А с чего вы взяли что "весь код этих файлов должен браться из angular2.dev.js"? Вы же system.js об этом ничего не сказали.

Все что вы сделали - сказали "загрузи ка typescript/boot", а дальше уже зависимости начали грузиться. Читайте как бандлить скрипты.

Для начала, как говорится, определитесь с целями. Вы хотите больше интересных задач. При этом ваша специализация - верстка. Раз уж вы только только решили попробовать "gulp" и sass - предположу что с такими инструментами, как скажем autoprefixer вы так же не знакомы. И тем более webpack.

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

По процессам вам стоит ознакомиться с существующими методологиями в верстке. BEM, Css modules и т.д. Сейчас все популярные фреймворки (в том числе и angular) идут по сути реюзабельных компонентов, и подобных подходы к верстке зададут вам какую-то основу.

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

Ох...

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 приложения или способы взаимодействия с ним меняются почаще логики или как минимум в разные моменты времени. Адаптеры в этом случае служат промежуточным слоем, они ничего сами не делают, это "переводчики". Они просто переводят то, что сказано в запросе в язык понятный приложению и обратно.

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

ну дата контейнеры - никак. Вы можете их сдампить в образы в принципе.

В целом же алгоритм такой
- пушим образы в docker hub (или свой registry/distribution на сервере, в этом случае надо сначала задеплоить его куда-нибудь по той же схеме)
- добавляем целевую удаленную машину в docker-machine (драйвер general) - тот ставит там докеры шмокеры и в целом настраивает все
- при помощи docker-machine env переключаемся на удаленный docker-демон
- делаем docker-compose up -d или как вы там оркестрируете все. Для удобства стоит отдельный yml файлик под прод сделать и указать образы которые вы запушили.

Готово.

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

Нет, достаточно просто настроить 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, потребление памяти на запрос посчитать немогу (так как все запущено как демон). Но этот вариант пока рекомендую для очень простых апишек где нужна скорость реакции системы.

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

p.s. тут лучше подходит ngIf

symfony/security - voters

помимо 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));
}

У вас тут идет рекурсивный вызов геттера и сеттера (вы из геттера age вызываете геттер age). Что бы понять что значит эта ошибка - читаем как работают рекурсии и что такое "стэк вызовов".

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

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

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

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. Имена классов, интерфейсов и т.д. должны быть существительными. Мы описываем тип объектов. Но это единственное место к которому я могу придраться.