Юрий

Все будет нормуль, не ссыте, рубль отвоюет свое, не метайтесь. Если вы не имеете кредитов или расходов в какой либо валюте, то падение ваших доходов в 2 раза никак на вас не отразится.
С голода точно не загнетесь.
Ну не купите в ближайшее импортных товаров.
Что у вас мало барахла?
Наверстаете после подъема.
А насчет ответа про рынок, кто-то потеряет, кто-то выиграет. Сам рынок никуда не исчезнет и тьму ПО надо будет писать, поддерживать и обслуживать дальше.
Кризис повод развиваться и быть конкурентноспособным.

На работу устраивайтесь, а не "видео-уроки" смотрите.

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

Есть ещё книжица "7 languages in 7 weeks", там галопом по европам, но идей можно нахвататься.

Существуют также DoctrineExtensions, а именно Translatable. Легко интегрируются в Symfony2 через StofDoctrineExtensionsBundle

Присоединюсь к @OnYourLips -- нахваливать в основном будут адепты того или иного фреймворка. Я сам для новых проектов первое время использовал yii, но сейчас, чтобы прикрутить к нему более-менее современные технологии из пыхомира(тот же codeception), требуется потрудиться(фреймворк делался с прицелом на 5.2). Сейчас же поймал себя на мысли, что очень большую долю времени работаю, пытаясь обойти некоторые ограничения фреймворка. Практически все они связаны с использованием active record или виджетами. Плюс, у yii все-таки довольно сильная связанность, в отличие от того же Symfony, который по сути эдакий швейцарский нож -- большое количество классов, если не на все, то на многие случаи жизни.
В общем, если проект будет большой, с довольно сложной бизнес-логикой и постоянно развиваться, то я бы все-таки агитировал за Symfony2, ну или за использование компонентов aura php. Прошу прощения, если ответ несколько сумбурен.

1. Жесткая типизация и контроль входных и выходных данных. Много проблем получали, когда php-сервер отдавал string вместо int, например.
2. Предусмотреть разный формат возвращаемых данных — json, xml и т.п. — на клиентсайде может оказаться не только ios.
3. Предусмотреть перехват всех внутренних ошибок и исключений, чтобы клиент всегда получал логичный ответ вместо неожиданных ошибок.
4. REST моден, но совершенно необязателен. После нескольких лет существования некоторых сервисов мы только сейчас начали вводить поддержку REST. Это нам не мешает разрабатывать популярные мобильные приложения на всех видах устройств.
5. Изучите хорошие примеры сервисов и наоборот — ужасные примеры (Facebook). Никогда и ни за что не делайте, как у FB.
6. Предусмотрите инструменты отладки.
7. Сразу продумайте версионность. Выпустив однажды мобильное приложение уже нельзя будет просто поменять API.
8. Можно сразу заложить инструменты кеширования и авторизации на уровень ядра API. Например, в одном приложении мы передавали oauth-токен в заголовках. Это позволило избавиться от постоянных проверок авторизации внутри модулей API, отдав это в родительские классы и управляя доступами через конфиги.
И т.п.

Кстати, ещё есть silex

тоже самое.
Однако использование котейнера внутри сервисов — это не правильно с точки зрения архитектуры. более правильно передавать параметры через конструктор или set-методы.
Основная дока тут: symfony.com/doc/current/book/service_container.html

по самим параметрам:

в файле sevices.yml — так же в любом другом (не обязательно сервисы)
может быть строчка
parameters:
test: 1

в файле config.yml тоже могут быть такие строки

а ещё есть файл paremeters.ini
test = 1


а ещё есть переменные окружения. их тоже можно доставать так же через параметры.

если хочешь чтобы параметр попал в конструктор сервиса, то указываешь его имя
%test%

пример, из офф документации:
# src/Acme/HelloBundle/Resources/config/services.yml
parameters:
my_mailer.class: Acme\HelloBundle\Mailer
my_mailer.transport: sendmail

services:
my_mailer:
class: %my_mailer.class%
arguments: [%my_mailer.transport%]