Растишка

Вы - PM (Project Manager), ваша задача - управлять человеческими ресурсами, НЕ лезьте в разработку.
Задача программиста, согласно вами описанными правилами - реализовывать функционал, однако инструменты для этого он должен выбирать самостоятельно, согласно ТЗ.

То, что вы указали несколько цифр - это архитектурные требования и они ВНЕ вашей компетенции.

Вы указали требования на запись/чтение, а что на счет целостности, себестоимости, сложности внедрения и поддержки?

Redis - это key-value хранилище (чаще всего используется как кэш, и pub/sub роутер), MySQL - это реляционна БД. Это как сравнивать мотоцикл и фуру, они предназначены для разных целей.

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

1. Back-end с опытом фронтенда - это хорошо
2. Back-end оплачивается больше, сама сфера напорядок больше. У нас в компании разница в senior back/front правда небольшая - в 15-20%
3. Все таки это разные вещи, и творчество проявляешь по разному =)
Back-end это более хардкорная разработка) Для серьезных бородатых дядей) Например результат труда ты своего визуально не подкрепишь) Какая нибудь нетривиально анимированная SVGшка не будет радовать твой взор)
Но зато ты имеешь шанс получить кайф от того что написал какую нибудь автоматизированную интеграцию двух больших баз данных, или запилил нереально крутую архитектуру проекта =)

В общем на ЗП и условия не смотри - попытайся понять что тебе больше нравится =)
И если нет вариантов работать в текущей компании по интересному тебе направлению, если живешь в достаточно большом городе и выбор есть - то лучше смени место работы)

Вот чисто для php недавно вышел www.sesmikcms.ru/pages/read/biblioteka-dlja-raboty...

Потому что потом их придется отправлять в прошлое.

Основная проблема в том, что у популярных РНР фреймворков нет модели вообще.
А моделью называется тот самый ORM.

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

В случае с Ларавелью мы получаем

• Модели лежит в папке Controllers, при этом используя
  • ORM из папки Models для манипуляции с данными
• Визуальное отображение лежит в папке Views
• Секретарша лежит в routes.php.

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

Добавлю в список: angular, angular light

В парадигме MVC работа с данными ведется в модели.
Я бы описал MVC это как небольшую фирму в которой есть С - секретарша, которая принимает заказ и передает его M - боссу, он в свою очередь говорит V - художнику что и как нарисовать. Полученный шедевр V передает С, которая отдает его клиенту.

"Студентов и школьников прошу продолжить играть в Dota и не отвлекаться на мой вопрос."
Яркий пример предвзятого отношения от которого стоит избавляться..

да никому, кроме вас не нужен ваш этот шаблон.

Можно ли js-способом узнать текущий URL, и если он не авторский, то закрыть сайт и отправить email автору?

можно. но я удалю его в 2 клика.

я за Laravel

С помощью небольшой магии и короткого синтаксиса код можно еще больше сократить

$sql = 'SELECT * FROM users WHERE email = ?';
$rows = $db->prepare($sql)->execute([$email])->fetchAll();

В файле /setup/index.php прописывали?
@ini_set('date.timezone', 'Europe/Moscow');

При установке git.exe мог быть прописан в PATH, просто возможно OpenServer использует только свой PATH. Лично мне помогло в настройках во вкладке "Сервер" выставить значение "Свой Path + Win Path".

Вообще-то эти "общие СЭД программы" на то и общие, чтобы подстраиваться под всевоможные нужды.
Если они вам чем-то не угодили, значит вам не нужен документооборот, а что-то другое.

Ну а судя по первому опыту и упоминаиню PHP(yii) в качестве "платформы", думаю, что вас ждёт неминуемый провал и потеря времени и денег.

Все ринулись упражняться в остроумии по поводу 1С и программирования на русском, а ведь у автора проблема совсем не в этом. Автору не хочется изучать синтаксис языка, на котором он хочет программировать. Причем даже не самые сложные конструкции (цикл, объявление и присвоение значений переменных и т.д.).
Оставив в стороне предметную область, в том же 1С только описание встроенного языка с минимальными примерами кода составляет объем в 7 книг. + еще столько же по особенностям применения тех или иных конструкций и объектов языка, языку запросов и администрированию системы в целом.
Да, блин, даже если блок-схемами программу рисовать и то придется запомнить, что обозначает ромбик, а что - прямоугольничек.
Автору могу посоветовать либо забыть о программировании вообще, либо ждать благословенных времен, которые все время предсказывают различные "эксперты" - когда программировать не будет никто, программисты будут не нужны, а пользователь просто будет говорить компьютеру что ему нужно, а на выходе получать готовую программу.

Учите английский, нафиг не нужна русскоязычная среда программирования.

Программируйте на 1C.

А дальше вы куда с этими программами? Учите английский не смешите людей ))

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

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

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

Также даже со всеми такими подсказками совершенно не понять как например нарисовать простейший пиксель на экране. Нужно сначало лезть по документации изучить язык, затем узнать что существуют библиотеки(opengl например) затем научиться с ними работать, затем узнать что есть всякие api(winAPI или qt) , и научиться работать с ними. И только потом вывести пиксель на экране. И ведь для всего мне придёться читать документацию (javaJDK openglSDK MSDSN qt-доки) и всё на иностранном для меня языке.

Так и есть. Хотите пользоваться OpenGL - изучите его специфику. Опять пример с машиной.
Конечно, можно просто скопировать кусок и вставить, но если потом придется что-то править, без понимания Вы можете порушить всю архитектуру программы

Русскоязычные пользователи вынуждены лезть в google и искать, перелопачивать тонну информации ради маленького фрейма. Англичанам проще их инструкции написаны на понятном им языке.

Так уж сложилось, что программирование зародилось в англоязычной среде. И никакой патриотизм к этому отношения не имеет. У меня был опыт написания программ на языке с русским синтаксисом, и я проклял все как раз из-за конструкций вида <имя><знач.>[<зн.оп.><знач.>].
Если не знаете английский, купите книжку типа "<ВыбранныйЯзыкПрограммирования> для начинающих" или "Введение в <ВыбранныйЯзыкПрограммирования>", там все на русском и понятно. Все так начинали.

Не пытайтесь вести машину, не зная ПДД. Не пытайтесь готовить, не зная рецепт. Не пытайтесь программировать, не зная языка программирования. Все это приводит к плохим результатам.