Денис Бондарь

Один из самых простых способов организации фоновых задач (таких как отправка письма, например) — делегировать их скрипту в cron-е через базу данных. То есть записывать задачу с аргументами в таблицу-очередь, а кроном эту очередь разбирать по таймеру. Если по каким-то причинам это не подходит (например, из-за скорости реакции или нагрузки на бд), то наверное смотреть в сторону gearman.

Вали от туда

А вообще вопрос глуповат. Если там php 5.4 и Kohana старенькая, то конечно они не используют композер.
Если нет тестов — не всегда плохо, очень много проектов без тестов работают. Да там ты не научишься хорошему программированию, но не так все ужасно... можно потихоньку их притащить, но не всегда это нужно бизнесу (вообще это задачи тимлидов и гигиены разработчиков)

А вот ответ Тимлида ужасен. Почему это выяснилось не на собеседовании?

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

UPD: Очень хороший ответ ниже по ссылке -- Разве Composer бесполезен в 2017?

Все красиво объяснил Nkly777, только в блоке PS merge с rebase перепутаны.
Добавлю картинок.

git rebase devel - собачка на молнии - "сшивает" коммиты по дате их создания
(ветка devel "растворяется" в основной ветке)

git merge devel - пожарная лестница, все коммиты ветки devel крепятся в конец, образуется пересечение
(devel остается отдельной веткой, к которой можно вернуться)

git chery-pick idea - забрать коммиты из ветки idea

Дмитрий Елисеев
www.elisdn.ru/oop-week
Очень расжевывает и доступно объясняет.
Есть много бесплатных видео, чтоб понять уровень.
Это не очередной говно-курс как срубить бабок на перессказе документации.
Посмотрите посты в блоге. Я правда курсы не проходил, но видео-материалы смотрел.

Берите микрофреймворки Slim, Zend Expressive

У вашего "быстро выучить" есть большой подвох, что вы и останетесь на том что выучили.

Потому что такие фреймворки как laravel, yii провоцируют писать не очень хороший код.

я решаю путем выделение функционала в модули которые содержат: контроллер и шаблон
вызов в php шаблоне делаю: <?=Module("module_name")?>
или в twig: {{module("module_name")}}

А в чем проблема использовать описанную Вами конценпцию? это вполне нормальный вариант аля HMVC

Из личного опыта - когда я работал сетевым алмином и у меня в эксплуатации было 8k разношерстного активного сетевого оборудования, питон я активно использовал для опроса по snmp разных девайсов, бота для телнета. Ещё для смены делал тупой веб интерфейс для того, чтобы на свичах можно было включить/выключить порт, подписать дескрипшен. Пытался делать на нем генератор конфигурации, но bash+sed для этого подошли лучше.

Надо плясать от задачи, а не от языка. По моему скромному мнению питон избыточен для повседневного системного администрирования, возможностей баша хватает с головой. Он удобен для больших расширяемых програмулин, но часто ли надо писать самому такой софт админу? Также он хорош для сетевого программирования, но опять же, часто ли надо прогать сокеты? Полезен в распаршивании всяких html/xml.

Однострочники писать на нем неудобно, а в бытовом админском скриптовании именно они составляют львиную часть работы.

$model = new User(['ip' => Yii::$app->request->userIP]);
if ($model->load(Yii::$app->request->post()) && $model->save()) {
......
}

либо перед сохранением

if ($model->load(Yii::$app->request->post()) && $model->validate()) {
    $model->ip = Yii::$app->request->userIP;
    $model->save(false);
}

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

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