Сергей

Много решений подходит под такие критерии. Смотри, изучай, выбирай.

Cocos2d-x является одним из самых популярных открытых движков. У него большое сообщество и масса поклонников. Есть документация и все нужное для старта.

Defold является еще одним очень популярным кроссплатформенным и открытым решением для разработки 2D игр. Сообщество тоже очень большое, документация и уроки для начинающих тоже на месте.
Defold часто выбирают в качестве решения для своей первой игры. И этот выбор далеко не случаен.

Godot Engine не менее популярен и не менее поднят по возможностям. В чем-то Godot даже будет лучше чем Cocos. Сообщество у него тоже большое. Документация тоже присутствует.

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

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

Urho3D является нареченной Open-Source альтернативой Unity. Движок используется многими энтузиастами. По разным уголкам сети раскиданы многочисленные группы обсуждения этого движка. Документация и примеры у него на месте.

GDevelop - это довольно популярное решение для небольших игр. Документация на месте.

Panda3D - тоже довольно популярное решение со своим сообществом. Документация имеется.

Hazel Engine - один разработчик - один движок. Полностью вся разработка изложена в видео на youtube. Пользоваться можно... на свой страх и риск.

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

GZDoom - современная инкарнация движка DOOM.

Дальше решения пойдут или сложные, или экзотические. Всё на свой страх и риск.

CryEngine - от Crytek.
X-Ray - движок S.T.A.L.K.E.R.
UE 3 - для коммерческих проектов использовать нельзя.
Lumberyard - от Amazon. Да-да, тот самый.
Banshee Engine - он просто существует.
Diligent Engine - у него есть свое сообщество.
Atomic Engine - на нем тоже выпускают игры.
Lumix Engine - тоже что-то может.
Horde 3D - просто существует и этого уже достаточно.

Я для этих целей использую расширение Decimal:

(new Decimal\Decimal('153.17'))->mul(100)->toInt(); // 15317

Но можно использовать и функцию bcmul:
(int)bcmul('153.17', '100'); // 15317

Во первых книга по симфони есть в сети в свободном доступе.
Во вторых есть курс от Елесеева по симфони. Достаточно глубоко раскрывает предметную область. правда длится 50 часов наверное - не меньше. Не у каждого хватит воли пройти этот курс. но оно того стоит.

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

Ну еще и Симфоникасты гдето лежат в сети. Да и на ютубе есть материал.

Вот группа в телеграм посвященная Симфони расстроила. В силу последних военных операций в ней стало невозможно находиться если ты с РФ.

Если в PDF лежит текст, то Вам поможет консольная утилита (pdfToText), она может по странично разбить pdf на текстовые файлы, а по ним уже делаете поиск. Если с утилитой возится не хочется есть библиотека для PHP - PDF Parser, тоже умет по страницам считывать и получать текст.

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

Ну как-то так :)

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

2. Сущность можно при желании положить в поле в корне агрегата.

Я на эту тему делал доклад: https://www.youtube.com/watch?v=rQDd5kCwDj8
Там есть и личный опыт и ссылки на исследования.
Правда, с 2016-го что-то могло поменяться, но я, честно говоря, сомневаюсь.

Если резюмировать ответ на вопрос: лучше всего собирать две версии - для HTTP/1 и для HTTP/2 и отдавать клиенту то, во что он умеет.

Вот и напишите проект, который будет генерировать идеи проектов.

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

1. Отображайте возможность выбора типа организации прямо в той же форме, где пользователь выбирает, физлицо он или организация. ng-if в помощь.
2. Вызывать диалоговое окно не стоит, а если уж вызываете, сделайте кнопку отмены.
3. В диалоговых окнах Angular Material свой $scope. Для правильной обработки используйте такой код:

$mdDialog.show({
    templateUrl: '/template/dialog.html',
    controller: [ '$scope', '$mdDialog', function($scope, $mdDialog){
        $scope.cancel = $mdDialog.cancel; // Отмена. Ничего сложного.
        $scope.save = function(){
            $mdDialog.hide($scope.model); // Диалог закрывается, promise разрешается моделью
        };
    }]
}).then(function (model) {
    // Та самая модель, которую возвращает $mdDialog. 
    // При использовании метода cancel() выполняет код для reject
});

то контроллер наследуется и я в результате "соберу" форму?

он не наследуется, вы просто получаете доступ к контроллеру директивы, от которой зависит ваша.

Как, в случае с директивой, поступать с ui-router, можно ли куда то засунуть stateProvider

uiRouter должен остаться снаружи. Вы можете добавить колбэк у директивы, который будет вызываться по переходу между скринами, а там уже менять состояние у ui router. Или еще как. Но uiRouter и все что связано с навигацией между состояниями должно остаться снаружи.

Наследуется ли контроллер (link) в директиве, чтобы не терялась форма?

link это не контроллер, link это link. И нет, и контроллер и link будут уничтожены при разрушении скоупа (или при удалении элемента).

Храните данные в сервисе.