Вячеслав Алексеев

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

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

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

Давать советы удаленно, не имея полной картины обстановки особого смысла нет.
Но так если на вскидку самое лучшее решение - четыре правильно настроенных точки доступа, по одной в каждой комнате, с передатчиками выкрученными на минимум, и правильно расположенных в пространстве.
Точки доступа следует использовать те, которые позволяют тонко настраивать параметры. Микротик, убикьюти, в крайнем случае обычные с прошивкой типа DD-WRT.

https://github.com/ryanb/nested_form
https://github.com/nathanvda/cocoon

Для все простых типов в C++ есть верхние и нижние пределы, а также некоторая эпсилон окрестности, которые лежат в numeric_limits. В Вашем случае, если значение будет меньше эпсилон, можно считать числа равными. Например, сравнение вещественных переменных а и b будет выглядеть так:

bool isSame( double a, double b)
{
return  std::fabs(a - b ) <= std::numeric_limits<double>::epsilon()
}

Если isSame истина, значит, числа равны, иначе нет.

В одном проекте. Просто представьте что создаете сайт из трех страниц, правила будут те же. Только в роутинге привязать домены надо будет - в рельсовых routes.rb за это отвечает параметр constraints: {domain: 'domain.org'}. В sinatra работал очень давно, возможно и там есть нечто подобное. В самом худшем случае - наладить в nginx.conf редирект с других доменов на страницы основного (domain.org/lending1).

https://github.com/ConradIrwin/pry-rescue
https://github.com/charliesome/better_errors

1. Да, не к чему в в одно пользовательском режиме сервис thin`а - про runlevel

2. Подразумевается, что запускается три сервера на одной машине и обслуживают запросы от клиентов, в Вашем случае таковых 3 штуки. Используется для балансировки нагрузки, например когда один сервере выполняет "тяжёлую" задачу, и приходят еще запросы от клиентов.
2.1 Порт может быть использоваться любой выше 1024.
2.2 Сервера Thin`а, по умолчанию, будут доступны в сети с адресом, если память не изменяет, 0.0.0.0 (т.е любой), для привязки к конкретному адресу, надо запускать с ключем -a, пример thin -a 127.0.0.1

Про upstream в конфиге nginx'а, как раз таки и используется для создания пула с целью балансировка нагрузки, только у вас в настройках указан юниксовые сокеты, (запуск thin -S /tmp/thin.sock -s3)

Про связку с php, потребуется до настройка Nginx под конкретную конфигурацию, т.е. что будет выступать бакендом для php (apache. fastcgi), и какие условия для перенаправлявления на этот бакенд.
Как то, так.

Для этой цели используются хуки. Вы можете почитать о них вот здесь .