Богдан: Это самая ужасная идея, что только может быть.
Винда плохо (очень) подходит под разработку рельс. На линуксе то иногда возникают затупы с некоторыми гемами, а на винде вообще будет виселица.
Могу только в общих чертах описать, потому что на память не помню всех команд и деталей.
Надо создать upstart/systemd файл(ы), который(ые) описывает(ют):
1) какую команду(ы) он запускает
2) когда он их запускает - runlevel, запуск после того, как поднимется сетевой интерфейс или монтирование файловой системы - тут возможны различные варианты и комбинации.
3) описывает коллбэки - что сделать перед стартом, что сделать после старта, что сделать после остановки
4) описывает, перезапускать ли программу, если она падает, максимальное число попыток и т.д
5) описывает, запускать ли в виде демона или как-есть.
... и т.д и т.п - там хватает нюансов.
Поэтому, гугли в этом направлении. Точнее, к сожалению, не подскажу.
P.S, systemd пока сам до конца не осилил - уж больно от отличается от upstart, к которому я привык.
bogdan_uman: Достаточно одного файла, в котором можно описать конфигурацию под все окружения (development/test/production) по образу и аналогии с, например, "database.yml"
Т.е примерно твой инициализатор будет выглядеть вот таким образом:
file_path = Rails.root.join('config', 'savon.yml')
file = YAML.load_file(file_path)
GH_SAVON = file[Rails.env] # подгружаем конфиг для текущего окружения и записываем в нашу константу.
Тоже самое можно сделать и с JSON форматом. Тогда поменяется только вторая строчка.
bogdan_uman: Да, нужно создать свой файл. Структуры у них нет. Это просто файлы, которые исполняются один раз при запуске. Тебе нужно будет прочитать файл с конфигурацией, распарсить содержимое (если нужно) и записать в константу. Советую также почитать документацию по рельсам.
Ну почти. Только не сам ответ от БД, а его парсинг и маппинг на объекты.
Потому что сама БД, если спроектирована правильно, будет одной из самых быстрых частей системы.
А вот рендеринг, маппинг - это довольно медленные операции.
Если я ещё не забыл курс схемотехники, то на схеме первый операционный усилитель вместе с его резисторами - это схема аналогового сумматора напряжений.
Высота каждый отдельной ступеньки (а они, кстати, должны быть разными) зависит от включенного сопротивления:
1) 5V * 10kOhm / 18.75 kOhm = 2,66V
2) 5V * 10 / 37.5 kOhm = 1.33V
3) 5V * 10/ 75kOhm = 0.66V
4) 5V * 10/150kOhm=0.33V
И пока циферки будут ползти вверх от 0 до 15 (0000 -> 1111), это будет увеличивать напряжение.
Всё это помножить на коэффициент усиления второго операционного усилителя (3).
Итого: счётчик успеет досчитать где-то до 5 и остановится.
Ну, по-идее, при должной реализации должно работать.
Но надо предусмотреть несколько вещей
1) случайные изменения величины
2) фиксация конечного веса
Можно попробовать сделать так, что если величина угла превышает значение уставки (которое можно найти только экспериментально):
1) записать значение веса и запустить таймер (3 секунды),
2) смотреть - не насыпят ли ещё / ссыпят ли ещё (угол а).
2.1) если насыпали/ссыпали: с помощью угла и значения корректируем значение веса, которое запомнили в пункте 1, перезапускаем таймер и goto 2.
2.2) если ничего не произошло и таймер истёк - goto 3.
3) конечное значение веса записать в лог (базу данных, или куда надо).
Если конечная скорректированная величина больше, чем величина, которая была до пт.1 - нам насыпали, если меньше - ссыпали, а если около 0 (ввести какую-то неучётную зону или тару) - тогда ничего не произошло.
Примерно такой алгоритм.
Для удобства работы я бы ещё отшкалировал значение веса, чтобы оно было ну хоть примерно одного порядка с временем - я бы взял не кг, а тонны. Тогда угол будет считать удобнее, и он не будет крутиться возле +-90 градусов.