Денис Дерепко

Единственно-верный вариант здесь: построение "дерева" связей между частями речи (внутри одного предложения), собранное из множества разных текстов с помощью человека на конкретных эталонных примерах.

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

А задача такого плана решается исключительно только с помощью создания и обучения НС.

Пример:
Подаём текст на анализ: "Сервер не включался из-за сломанного блока питания."
Отправляем на вход: "Почему не включался сервер?"
Получить должны: "Был сломан блок питания."
или
Отправляем на вход: "Блок питания был сломан?"
Получить должны: "Да."

Возможно, что автор имел ввиду разделить и заменить местоимения на цельно-выраженные сущности.
"Вот дом, который построил Джек":
1. "Дом" ("вот" - удаляем, т.к. это частица)
2. "Дом построил Джек" ("который" заменяем на управляющее существительное "Дом")



PS: По ссылкам от Mikhail есть только простой шаблонный/словарный поиск с использованием правил и регулярных выражений - это не решение задачи в том виде, в котором возможно добиться правильной работы и корректного результата.

symfony.com/doc/current/routing.html
symfony.com/doc/current/routing/debug.html

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

это пять))
чистить надо кеш приложения, а не браузера.
symfony.com/doc/current/console/usage.html

1. расширение кругозора.
2. возможность пилить собственные экстеншены.

особенными преимуществами не является, но является жирным плюсом и хорошим дополнением.

Выберите сферу, где хотите работать. Зайдите на hh.ru и посмотрите требования вакансий по теме. Сделайте выводы и напишите что-нибудь. Затем идите к работодателю.

Забудьте про универсальный проект, который понравится всем. Программировать микроконтроллеры и писать какие-нибудь шейдеры - это две разные области со своей спецификой.

Собственно разработать план по тому как разобраться в этом проекте, написать по нему документацию самому.
Если компания гавно это отличный шанс сделать все так как вы хотите

ruhighload.com

Создаёт обьект и передаёт его или только определяет и конфигурирует, а создаёт фабрика

Именно так. Мы когда регистрируем сервис в сервис локаторе, у нас появляются фабрики сервисов. Они могут быть явными (то есть мы явно пишем код который занимается созданием объектов, например так сделано в pimple) или не явно (всякие автоконфигураторы на основе рефлексий как в PHP-DI или конфиги в Symfony). Так или иначе у нас будут появляться фабрики.

Сервис локатор по запросу сервиса проверяет создавал ли он такой или нет. И если нет - просит фабрику сделать сервис и выплевывает его тому кто запросил.

Итак, обо всем по порядку:

1. Дописать новую фичу можно в любой системе и в любом фрейморке (ZF/Laravel/SF/Cake/CI/Phalcon ... ), даже если все было спроектировано не правильно изначально. Единственно на это уйдет чуть больше времени и нервов.

2. Симфони второй по востребованости в СНГ, после Yii - согласно hh и brainstorage. Остальное - ZF/Laravel. В Европе/США - наоборот, ZF2/Laravel, потом Symfony, а Yii вообще редко попадается.

3. Да Ларавел работает быстрее и есть меньше памяти. Это потому в симфони очень много слоев абстракции. Но как правило, память дешевая и многие могут её себе позволить. То есть в основном никого не волнует какие-то 9-10 лишних МБ памяти.

4. Симфони - не для слабаков. Его API гораздо сложнее всех остальных. Нужно уже знать и понимать DI контейнеры, принцип разделения концепций и аналогичное. Для работы с Yii/Laravel - знать этого не нужно, поэтому каждый второй школьник Yii/Laravel программист (образно говоря).

5. Не встречал адекватных мануалов для новичков на русском языке, к сожалению. Могу посоветовать только англоязычные:

Symfony2 Registration and Login
Creating a blog in Symfony2

Пройдя эти мануалы, уже сможешь писать приложения.

6. В любом фрейворке, тебе нужно будет в основном только это:

- Роутер / контроллеры
- Компонент валидации форм
- Слой над базой данных

И все! Фремворк предоставляет только инструменты, не более того. Т.е фреймворк - это не цель, а средство.

95% веб-проектов — лендинги с иисусьими тряпками, магазины и «визитки». 95% игр — казуальное барахло, HOG'и, клоны subway surfer и прочий фримиум. В дизайн-студиях 95% работы — это годовые отчеты, каталоги иисусьих тряпок и дизайн для вышеперечисленных веб-проектов.
Везде так, интересной работы везде мало и ее еще надо заслужить.

Идея/концепция к проектированию не относится, это отдельный предварительный этап. Для проектов побольше, и в общем случае, проектирование включает такие шаги, многие из которых, конечно, можно пропустить или сократить до минимума, если задача не сложная:
1. Системный анализ и изучение предметной области
2. Формирование требований к разрабатываемой системе
3. Архитектуная задача, которая сводится к простой формуле: разделять, называть и связывать подсистемы
3.1. Декомпозиция сложных задач
3.2. Слои (построение слоев абстракций)
3.3. Планирование топологии системы, программной и серверной инфраструктур
3.4. Решение вопроса интеграции подсистем, программные интерфейсы, контракты и связывание
3.5. Интеграция с унаследованными приложениями
3.6. Минимизация изменений, для случаев, когда постоянно происходят изменения в предметной области
4. Выбор инструментов решения
4.1. Выбор парадигм программирования и языков
4.2. Выбор технологий и платформ
4.3. Выбор моделей данных, алгоритмов и библиотек
4.4. Выбор топологий и протоколов
4.5. Выбор паттернов программирования
5. Предварительные исследования
5.1. Проверка гипотез, эксперименты
5.2. Изучение особенностей технологий
5.3. Прототипирование
6. Задачи обеспечения надежности
6.1. Планирование безопасности и защиты от несанкционированного доступа
6.2. Планирование отказоустойчивости
6.3. Планирование мер по обслуживанию системы в режиме эксплуатации
6.4. Задачи высоких нагрузок, балансировки и масштабирования, если таковые предполагаются
7. Организация процесса разработки
7.1. Жизненный цикл программной системы
7.2. Конвенции кода, соглашения и стандарты
7.3. Оценка необходимых временных и финансовых ресурсов для разработки системы
7.4. Календарный план
7.5. Анализ и минимизация рисков, выявление слабых мест технологий и коллектива
7.6. Закрепление принципов управления процессом разработки и корректировки задания в процессе
8. Сборка технического задания из результатов всех предыдущих пунктов

Выбирайте базу в зависимости от схемы хранения данных. Если между данными предполагаются отношения типа hasOne, hasMany, manyToMany, то здесь лучше использовать реляционную БД типа MySQL. Если хотите хранить какие-то динамические структуры, то тут лучше взять MongoDB, ну или другую документно-ориентированную БД.