bzz

Для очередей есть сервера очередей. Как вариант, ознакомься с Gearman. Для информации habrahabr.ru/post/142210/.

Найдите художника и фотографа, платите им деньги за хорошие картинки. Проблем-то?

Симфонисты не работают с yii2 и не до конца понимают о чем пишут :)
Я скажу так: оба фреймворка на высоте, по возможностям одинаковы, но подходы очень разные.
Объективно скажу так: на yii2 не получится запускать отдельные модули без запуска всего приложения, тут у симфони2 огромный плюс. Так же у симфони более классные консольные команды для генерирования каркасов, мне больше нравится, чем gii(но дело вкуса). Но по факту большинство сильных сторон симфони не оправдывается в связи с высоким порогом вхождения. Найти хорошего симфони программиста намного сложнее, чем найти его на yii2. Поэтому взависимости от бюджета и масштаба проекта можете выбирать. Симфони2 - это больше уровень корпораций, yii2 более простой при практчески том же функционале.
Если знаете симфони2, то лучше подтяните его. Yii2 изучить намного проще, намного всё прозрачнее внутри работает, там Вам хватит пару вечеров, чтобы пройтись по исходникам и всё для себя понять как изнутри как работает.

var f = function() {}; — function expression
function f() {}; — function declaration

Основная разница в том, что второе поднимает определение функции до начала области видимости, в которой она объявлена. То есть можно использовать функцию до ее объявления.

hoisted(); // выведет 'foo'

function hoisted() {
  console.log('foo');
}

notHoisted(); // TypeError: notHoisted is not a function

var notHoisted = function() {
   console.log('bar');
};

upd:
Другое отличие состоит в возможности моментального вызова функции, так называемое iife

var expression = function() { console.log('foo'); }();
// выведет 'foo'

function declaration() { console.log('bar'); }();
// SyntaxError: expected expression, got ')'

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

Создаём новый AssetBundle, прописываем нужные js/css/dependies.
Подключаем его в нужном view:
MyAssetBundle::register($this);

php composer.phar global require "fxp/composer-asset-plugin:1.0.0"

С версии 2.0.1 (вроде) обязательная штука

1. Собака не имеет никакого отношения к include. Это не один оператор, а два совершенно разных оператора.
   
2. Увидев @ в коде ты можешь почти со стопроцентной уверенностью сказать, что его писал неграмотный пользователь, и пользоваться этим кодом не стоит.
   
3. Увидев в коде @include ты можешь смело считать его автора абсолютным лохом и нубом, а сам код надо выкидывать немедленно. Потому что @include глушит не только саму ошибку включения файла, но и все ошибки в этом файле - то есть, поступает стократ хуже. Это значит, что если автор допускает такие косяки в коде, то и все остальное у него тоже ад кромешный.
   
4. Самое главное. Ошибки надо не подавлять. Ошибки надо исправлять. Но опять же, делать это с умом. Начинающие программисты считают сообщения об ошибках своими личными врагами, и борются с ними всеми доступными средствами - с помощью @, error_reporting(0) и др. Получив линейкой по рукам и запомнив на всю жизнь, что так делать не надо, ониначинают с не меньшим рвением писать всякие проверки - лишь бы не допустить, не дай бог, ненавистного сообщения об ошибке. Например:
   
   

if (file_exists($inc))
{
    include $inc;
} else {
    echo "Файл не найден";
}

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

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

Ошибки не надо подавлять. Ошибки не надо прятать. Ошибки надо исправлять.

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