German Jet

Читаем внимательно документацию: https://laravel.com/docs/queues

Если коротко, то по умолчанию у вас в env используется QUEUE_DRIVER=sync, что по сути значит "никаких очередей, выполняй всё сразу". Если вы хотите, чтобы очереди выполнялись в фоне, вам нужно изменить драйвер на один из подходящих вариантов. К примеру, если изменить на database и создать в БД нужные таблицы, то все задания будут помещаться в эти таблицы. Для их выполнения нужно либо запускать php artisan queue:work (одноразовое выполнение всех заданий), либо php artisan queue:work --daemon (демон, который будет висеть и мониторить добавление заданий в очередь), либо, лучше всего, использовать supervisor, который будет сам следить за тем, чтобы демон висел в памяти.

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

MVC это абстрактное понятие, которое обозначает разделение логики. Как вы это назовете не суть. Главное чтобы работа с логикой, с данными и с внешним видом была разделена. Т.е. если у вас три класса в одном файле и с помощью одного вы делаете доступ к данным, с помощью другого делаете доступ к внешнему виду, а с помощью третьего связываете все это вместе, то у вас тоже MVC.
В django логика работы программы(controller из MVC) описывается во view, работа с данными(model из MVC) происходит через model, а внешний вид(view из MVC) описывается в template. Во flask нужно самому думать что в какой файл положить и как делать структуру файлов.

Приходилось делать такое =)
Как я делал. Сначала переработал бд, затем переписал CI под эту бд. Поставил все на рабочий сайт. Потихоньку начал переделывать морду сайта ипользуя Yii2 (на зеркале) не добавляя ничего нового. Просто повторяя тот старый функционал(благо его немного). Когда морда была закончена и протестирована - поставил ее. Админка уехала на домен 3 уровня и осталась на CI. Чуть позже также была переделана с минимальным необходимым и установлена как рабочая.

Самым трудным было переписать код игнайтер под новую бд, т.к. бесил до состояния "аж трисет!". Но если базу не надо переделывать, то тут вообще нет проблем. Просто брать и пилить все по новой. А старое пусть работает пока так.

Совмещать 2 фреймворка, как написал index0h: это по моему черезчур усложнено. Тут главное не торопится =) Хотя, наверное, смотря какой проект...

Как безболезненно его портировать на Yii2?

Безболезненно - никак, от слова "совсем".

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

Самый большой вопрос о замене коробочных методов.

Пишите обертки для использования в старом коде нового.

А что с главной страницей?

создай апп с названием core || common || main || etc и сделай там вью со своей главной

Т.е. сама основа на которой хедер, футер и в нее уже контент этих приложений вставляется.

основа верстки ложится в темплейт, основа контекста, может ложится в core

Ее что отдельным приложением сделать?

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

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

Modx+pdoTools+MiniShop2 и никакого PHP. Правда с синтаксисом Modx придется все же познакомиться.

Сколько видел вакансий - везде стопицот непохожих требований, а когда доходит до собеседований и тестовых заданий, то всплывает еще стопицот сюрпризов.

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

Другая проблема заключается в том, что инди-разработчик - это вещь в себе, оторванная от мейнстрима чуть меньше чем полностью. Работая на фрилансе/аутсорсе ты, как правило, получаешь задачи от людей, слабо понимающих что там под капотом у сложных веб-приложений. Соответственно ты больше акцентируешься на удовлетворенность клиента, которая приводит к возникновению финансовых потоков в твой адрес, но совершенно не способствует твоему росту как профессионала. Ты просто превращаешься в человека-оркестра, выхватившего по верхам в стопицот направлений, и нигде толком. Безусловно, и на этом поприще бывают исключения, но, как правило, это ребята с "правильным" бэкграундом.

Достаточно крупные компании обычно набирают группы, по конкурсу, отбирают лучших и готовят уже их с определенным прицелом. Опять же лучших начинают присматривать еще с первых курсов вузов.

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

Примерно до 2010 года я старался свой веб-стек держать в пределах возможностей любого самого задрипанного шаренного хостинга, в результате чего лишался массы вкусных возможностей. Справедливости ради стоит сказать, что годные доступные впски массово стали появляться ближе к году 12-13. Когда уже сил терпеть не стало, я сказал себе доколе, и волевым решением отказался от шары, о чем ни разу не пожалел.

С 2015 года я положил глаз на full-stack JavaScript и потихоньку развиваюсь в данном направлении. Тренды таковы, что все больше вакансий и прочих предложений будут так или иначе именно в эту сторону. Одно меня печалит, пока что рынок фронтенда держит angular 1.x, но, думаю, это временно.