mletov

Зависит от задачи.
Если вам нужно просто добавить динамику на страницу, то однозначно jQuery.

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

Лично я пишу клиент на ангуляре легко и непринужденно :)

Да даже в .net стеке тоже самое можно решить другими методами.

• WinForms - WPF
  
• WinService - self-hosted Web Server или просто Web решение для IIS, не понятно что предполагается под "выполняет различные фоновые операции"
  
• WCF - WebApi, NancyFx
  
• EF - dapper, NPoco, linq2db, nhibernate
  

Хостинг ваше всё )) Делаете - заливаете

metanit.com
msdn.com

Это файл конфига php, никакого отношения к Drupal8 он не имеет, ищите в OpenServer

Рабочий вариант для работы с UTF-8 строками (2015-я студия). Не забудьте пересохранить исходник в UTF-8 кодировке.

#include <iostream>
#include <windows.h>

int main()
{
	SetConsoleOutputCP(CP_UTF8);
	auto message = u8"Тест тест";
	wprintf(L"%S", message);
    return 0;
}

На будущее:
1) с юникодом и UTF-8 в частности в Винде есть некоторый гемор по ряду исторических причин (в частности, из-за того что родная юникодная кодировка WinAPI - UTF-16); нужно просто уметь решать эту проблему (если нет желания заниматься разработкой на Linux);
2) это не отменяется того факта, что нужно хорошо знать, что вы вообще делаете. VS - инструмент для работы, особенно это касается C++ проектов, и нужно разобраться с определенными вещами, чтобы им пользоваться. Это я вообще, чтобы вы подход свой поменяли.

Это не ошибка - это ngResource так спроектирован.
Вам проще использовать $http.get, если вам не надо с REST общаться. Вот выдержка из документации по стандартным методам:

A resource "class" object with methods for the default set of resource 
actions optionally extended with custom actions. 
The default set contains these actions:

{ 'get':    {method:'GET'},
  'save':   {method:'POST'},
  'query':  {method:'GET', isArray:true},
  'remove': {method:'DELETE'},
  'delete': {method:'DELETE'} };

По спецификации REST GET-запрос может использоваться для запроса данных сущности либо получения их списка. $resource.get предполагается использовать как раз для первого варианта, а $resource.query для второго.
Поэтому в первом случае ngResource ожидает получить JSON-объект, а во втором - массив объектов.

Учетные задачи - это задачи для 1С.
Там основные объекты уже готовы из коробки.

Даже если не рассматривать 1С -
разрабатывать нуля под конкретного заказчика в наше время экономического смысла нет.

Лучше взять готовое ПО.
Иначе это ОЧЕНЬ ДОРОГО и ОЧЕНЬ ДОЛГО.

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

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

И неплохо было бы использовать кроссбраузерный метод подключения.

@font-face {
    font-family: 'helveticaneuecyr_roman';
    src: url('../font/helveticaneuecyr_roman.eot');
    src: url('../font/helveticaneuecyr_roman.eot?#iefix') format('embedded-opentype'),
         url('../font/helveticaneuecyr_roman.woff2') format('woff2'),
         url('../font/helveticaneuecyr_roman.woff') format('woff'),
         url('../font/helveticaneuecyr_roman.ttf') format('truetype'),
         url('../font/helveticaneuecyr_roman.svg#helveticaneuecyr_roman') format('svg');
    font-weight: normal;
    font-style: normal;
}

И дополню ответ mletov .

3) Проверьте наличие самих файлов, на всякий случай еще раз перезалейте папку со шрифтами

Проверьте еще права на файлы CHMOD.

Через host не подойдёт?

Если вас это немножко подбодрит, могу сказать что это смог провернуть мой бывший командир корабля (я в прошлом офицер ВМФ, но быстро понял что ступил не на ту дорожку и вернулся к любимым с детства компам), капитан 1-го ранга, хорошо за 50... а командир корабля - это ещё и очень особенный клад и уклад сознания... у нас был старенький комп - селерон под Миллениум, на котором мы в свободное от вахты и печати отчётов время гоняли Диабло. Кэп увлёкся. потом со скуки начал читить - там можно было открывать файлы своего персонажа и что-то накручивать по его параметрам... через это начал ковыряться и изучать. Я ему книжек подкинул. Кэп скучал - за него службу тянул перспективный и роющий землю старпом. Потом я уволился, уехал. Потом сильно удивился узнав, что выйдя на пенсию кэп увлёкся программированием настолько, что купил макбук ретина и что-то разрабатывает под iOS, что-то морское специфичное и за деньги.
Но правда там очень неслабая подушка безопасности в виде военной и более того, корабельной пенсии была...
Но если уж человек после 50 смог - вы сможете после 30 однозначно)) вопрос организации.

Если поля, по которым производится JOIN, имеют индексы, то запрос будет идти гораздо быстрее, чем без них, так что нужно смотреть индивидуально. Если индексов нет, то в плане выполнения, скорее всего, будет FULL SCAN и итоговое время будет пропорционально произведению количества строк в двух соединяемых таблицах - O(M*N).

Кажется, я сможил:
LIMIT 22, 10

To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:
SELECT * FROM tbl LIMIT 95,18446744073709551615;

Я вам, конечно, отвечу то, что вы не хотите услышать и не получю зеленую галочку на ответе, но нет никакой разницы.
То есть абсолютно.

Какой есть (хороший, разумеется) программист под рукой, какую технологию он знает/предпочитает - на том и писать.

Качество конечного продукта от языка программирования не зависит, а зависит от того, кто будет реализовывать, от его квалификации.

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

Если вы заказчик - то не занимайтесь не свойственными вам вопросами, пусть решает исполнитель.
Если вы исполнитель - то писать нужно на том, что лучше знаешь.

Запомните для этих случаев одну великую фразу "Ладно это я потом переделаю когда время появится" :)))

Идея не нова и витает в воздухе: наверняка кто-то такое уже реализовывал, но вы не знаете, так как не взлетело.

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

Поэтому попробуйте: а что, если повезет? ;)