just_evgenii

Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

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

Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.

Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

Соотвтственно, ответ на вопрос "что использовать?" очень простой:
- при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
- при автоматическом создании экземпляра объекта, использовать dependency injection container

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

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Первый деплой:

git clone
composer install
yii init
#правите локальные конфиги (прописываете базу)
yii migrate

следующие деплои:

git pull
composer install
yii migrate

миграции создаем ручками
yii migrate/create createUserTable
и правим файл миграции

сколько примерно времени займёт период от начала изучения до первого собеседования

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

На symfony2 в среднем проекты поинтереснее, так что я рекомендовал бы именно его. В любом случае переход laravel <-> symfony не является проблемой, ибо различия принципиальные там только в ORM идущей из коробки. Архитектура же этих фреймворков в целом схожа, разница в нюансах. Например в laravel мидлвэры как отдельная сущность, а в symfony они реализуются через события ядра, но суть та же. Еще нюансы с доктриной, эта штука довольно сложная и ее очень легко использовать неправильно, особенно с mysql. Но после того как разберетесь с ней возвращаться на всякие там active record-ы совсем не захочется. По сути это единственная полноценная ORM в php мире.

Еще вне зависимости от выбора рекомендую ознакомиться с такими штуками как луковая/гексагональная архитектура, почитать чего по TDD и тестирование в целом. Кента Бэка например, Эрика Эванса.

Источник

Источник

Ещё статистика

Брейкпоинты фрэймворков
Старенькое
На закуску
Viewport Sizes

UPD. Из презентации Яндекса о адаптивности интерфейсов:

<?php

class Stp008 {
   /**
    * Вытащи этот текст проще, че это сделал я
    */
	public function get() {

	}
}

$reflection = new ReflectionClass('Stp008');
$method = $reflection->getMethod('get');
echo $method->getDocComment();