d'Ivan

Так у вас Bibucket недоступен. Не пингуется.
Сперва решите проблемы на уровне сети. Далее всё само заработает.

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

А баг - это несоответствие поведения программы требованиям.

Теперь рассмотрим две ситуации:

1) Требований вообще не было.
Ни на словах, ни на бумаге. Решили сразу херачить код и начали. В таком случае вопрос "Как правильно назвать то, что мы продолбали валидацию" будет беспокоить в последнюю очередь - вам херачить надо.

2) Требования написаны (или обговорены) и там четко указано, что валидации не должно быть.
В таком случае - в реализации нет бага - работает же согласно требованиям.
Однако требования противоречат здравому смыслу (все входящие данные надо валидировать), так что это ошибка в требованиях и исправлять надо требования, ссылаясь на то какие проблемы может вызвать отсутствие валидации.

По поводу предков, используя метод ancestors можно выдвинуть предположение, что конкретно у ActionController::RoutingError базовый рельсовый класс ActionController::ActionControllerError (который уже восходит к рубишному StandardError).

2.3.1 :029 > ActionController::RoutingError.ancestors
 => [ActionController::RoutingError, 
ActionController::ActionControllerError, 
StandardError, Exception, ActiveSupport::Dependencies::Blamable, 
Object, PP::ObjectMixin, ActiveSupport::Dependencies::Loadable, 
V8::Conversion::Object, 
JSON::Ext::Generator::GeneratorMethods::Object, 
Kernel, 
BasicObject]

Но я уверен, что у других компонентов Rails есть свои родительские exception-классы, а может даже и не один. Например, у ActiveRecord есть ActiveRecord::ActiveRecordError.
Возможно вам придётся пройтись по исходникам рельсы и поискать классы, наследующиеся от StandardError.

давайте так, есть два вида задач:

- CPU bound - различные алгоритмы, математика, кодирование/декодирование/шифрование... словом все что нагружает процессор.
- I/O bound - собственно когда у нас идет множество операций с вводом/выводом, где-то 90% задач связанных с WEB и серверной разработкой.

Для CPU bound стоит использовать языки вроде Си, Rust, Dlang, Go и т.д. Словом языки которые компилируются в эффективный машинный код.

Для I/O bound - Go, NodeJS, Erlang, Java.... да в принципе не важно какой язык, главное что бы использовались неблокируемые вызовы и отсутствовали блокировки.

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

Какие языки лучше использовать для этого? Какие не использовать?

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

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

И на таких объемах даже если бы мы взял Си, если наш алгоритм имеет сложность O(N^2) то как бы ничего тут особо не поделать. И так и так медленно будет. А вот если мы возьмем какие-либо алгоритмы имеющие сложность O(NLogN) то уже возможно что алгоритм этот можно хоть на php/python/ruby имплементить. Так например у меня этот алгоритм реализован на Java и не самым эффективным образом. Справляется.

Еще влияет скорость разработки (всякие ruby/python/node в этом плане хороши), стоимость поддержки (Си поддерживать сильно дороже чем Go например, хотя всегда можно написать все настолько плохо что проще выкинуть чем поддерживать), стоимость разработчиков.... Скажем найти дешевых сильных разработчиков на Go или Rust будет весьма проблематично.

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

Собственно главное правило высоконагруженных систем - нагрузочное тестирование а потом уже оптимизации

Да, можно. USB можно пробросить через usbip. Только руки нужны прямые.

Как вести разработку и вести учёт изменений?

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

после шифрования сжимать будет нечего.

update tablename set fieldname = concat('prepend', fieldname) where /**/;

Состояние MySQL-сервера тоже неплохо бы посмотреть (запрос SHOW PROCESSLIST).

Вот и делайте архив, ZIP самый универсальный вариант, в интернете полно информации по работе с архивами с помощью C#.

В MariaDB и Percona реализация стандарта такая же как в MySQL

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

Весь список различий: https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql...
Сравнение совместимости: https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql...

FIRST() MERGE и т.п. операторы так же не поддерживаются?

https://mariadb.com/kb/en/mariadb/merge/

В вакансиях иногда пишут знание MariaDB, Percona так в чём там особенность "знания" заключается если это прозрачная замена MySQL - умеешь работать с ней - сможешь и с ними.

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

Может быть, конечно, что их инфраструктура сильно завязана на отдельные фичи MariaDB.
Может быть, это просто отсев тех, кто выпал из прогресса и даже не знает, что это за слово.

Распределить работу покомпонентно.
Любые макеты можно разобрать на следующие компоненты и этапы.

0. Создается общий репозиторий для проекта.
Все работы ведутся сразу в нем. Чем чаще делаются коммиты, тем раньше вылезут и будут исправлены проблемы. У каждого компонента есть свой css/less/sass файл, чтобы легче управлять кодом и избегать merge-конфликтов.

1. Основные строительные блоки:
- Типографика и стили для контента (таблицы, цитаты)
- Элементы форм + стили валидации
- Декоративная графика (иконки, плашки)
- Модульная сетка (сразу респонсив)

Каждый верстальщик отвечает за свой кусок работы и создает демо-страничку с перечнем компонентов, которые он сверстал. Работа верстальщиков не пересекается.

2. Повторяющиеся компоненты:
- Навигация
- Ленты новостей, событий, блогпостов, результатов поиска, чего угодно
- Типовые формы (логин, регистрация, поиск)
- Табы
- Слайдеры
- и так далее

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

После этих двух этапов у команды готов UI-kit проекта.

3. Предварительная сборка всех шаблонов страниц с реальным контентом

Работа распределяется постранично. Каждый верстальщик копипастит блоки из UI-кита и наполняет реальным контентом. В конце команда оценивает, где что еще нужно доделать.

4. Редкие кастомные компоненты и модификации

На основе проблем, которые вылезли на третьем этапе, каждый верстальщик допиливает блоки, за которые он отвечает.

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

Обо всем этом говорят Atomic Design, ITCSS и многие другие методологии.