Telegram
oleg.milantiev.com
Сайт Олега Милантьева
После трёх недель воздержания (был занят заработком денег … тем же самым программированием), продолжил разработку Автоматизатора съёмки дипская. Программа лично мне очень нужная, да и другим может оказаться полезной.
Сразу хочу извиниться за обилие программерских терминов. Итак, сегодня пол дня делал, с позволения сказать, концептуальный переход от C# программы с еёшным же GUI к … тоже C# программе, но весь пользовательский интерфейс буду переносить в привычный мне веб. Получается примерно так, как на диаграмме слева.
Браузер общается с самописным простым веб-сервером, написанным на C#, встроенным в программу Автоматизатора. Сервер отдаёт статику (html, css, js, fonts), и служит REST API шлюзом. Через этот самый REST, пока что без авторизации, веб-приложение на javascript может как получать данные, так и давать команды Автоматизатору.
Автоматизатор же, через ASCOM-абстракцию общается непосредственно с оборудованием по одному ему известному принципу.
По сути вся логика программы живёт в ядре, написанном на C#. Веб реализует лишь интерфейсные функции. Но реализует их хорошо, качественно и красиво.
Зачем это нужно?
Во-первых, я ненавижу программирование интерфейсов в Windows.Form. Я не умею и не испытываю ни малейшего желания учиться. Стоило мне запустить программу на другом компе, как начались проблемы. То залезло на это, тут буквы распёрлись, а вон то и вовсе почему-то не показалось. Почему? Не интересно. Я знаю веб (javascript, dhtml, REST). Я хорош в нём. Так зачем мне изначально делать кривой продукт? Ни к чему.
Во-вторых, Автоматизатор всё равно нужно было бы выносить в веб, ибо там ему самое место. Вот и получалось, что мне нужно было бы сначала реализовать весь интерфейсный функционал в C#, а потом повторять его в вебе. Это удваивает работу. Это усложняет поддержание, ведёт к грусти моей и грусти пользователей. Ибо я тут один и, увы, не могу уделить необходимое время проекту здесь и сейчас.
В-третьих, пока я пишу веб-приложение, я описываю, реализую и тестирую механизм внешнего взаимодействия программы. Её будущее и возможность расширения — её «лицо с компьютерным интерфейсом» — REST API.
Именно поэтому я сегодня потратил несколько часов на догугливание и допиливание однопоточного веб-сервера на C#, а так же набросал каркас twitter bootstrap приложения на html5 / javascript.
Была идея, кроме веб-сервера встроить в C# прогу и WebSocket сервер. Но я отказался от неё, так как не спутник запускаю и можно позволить себе потерять актуальность до пяти секунд, например, повысить потребление трафика до десятка мегабайт за ночь. Не факт, что на вебсокетах получилось бы сильно дешевле по трафику.
Дополнительная мотивация отказа от сокетов — необходимость прокидывания дополнительного IP-порта для них. А так как основной концепцией программы остаётся DSS-style (простота интерфейса вкупе с внутренней мощью), то один, стандартный 80й порт — то, что доктор прописал.
«А как же», — спросите вы, — «как же управлять программой на том же компе, где снимаю? Если у меня не удалённая обсерватория, а вот он, маленький телескоп в метре от меня».
Ответ простой и незамысловатый. Можно управлять с того же компа, зайдя по адресу http://127.0.0.1 (локальный комп — как раз такой пример на скриншоте ниже). Можно зайти с мобилы или планшета. Можно зайти даже со smart-tv : ) или же с соседнего компа. Больше того, можно зайти со всех эти устройств и ещё дать доступ соседу-Ваське, чтобы тот радовался Космосу. Это веб, он доступен отовсюду. В этом его фишка. Примерный вид каркаса приложения такой:
Завтра планирую начать реализовывать и документировать REST API.
Привет Олег!
На мой взгляд, Здорово! Решение заслуживает одобрения.
Выделение в программной системе ADSC отдельного Серверного компонента, отвечающего за реализацию тяжелой бизнес-логики и работающего в режиме 24*7 оправдано.
На начальном этапе к облику программы тобою были обозначены очень значимые (т.н. «сладкие») функциональные возможности, связанные с автоматическим планированием и последующим автоматическим (без участия пользователя) выполнением Заданий, а еще и автоматическим диагностированием оборудования астрографа (монти, колесо, фокусер, камера и т.д) перед началом сеанса и во время его выполнения.
Это возможно если функции будут возложены на некий «ADSC-Серверный процессор».
Именно им запускаются таймеры, инициируется исполнение атомарных операций для Заданий, если нужно он формирует сообщения для последующей отправки пользователю, приостанавливает выполнение операций, инициирует перезапуск оборудования при необходимости и т.д….
Веб-приложение — некая «Витрина» обеспечивающая возможность пользователю создание заданий, просмотра Плана на астрономическую ночь, хода выполнения Заданий, а также краткой информации о текущем состоянии оборудования Астрографа.
В будущем (а может и сейчас), будет логично наметить возможность развертывания программной системы по принципу: Одно Веб-приложение («Витрина») для N ADSC-Серверных компонентов, которые обслуживают свой уникальный астрограф и развернутых на разных компьютерах (! именно твой случай).
С уважением,
Борис
Совершенно верно. Веб — именно внешний вид и управление серверной частью. Собственно, именно для этого веб и придумали — чтобы создавать интерфейсы, доступные с любого устройства в любой точке мира.
Надо будет подумать, как общаться с несколькими REST-endpoint’ами. Обычно задания не пересекаются по астрографам, но бывает ситуация, когда нужно прям сейчас отснять несколько кадров, причём в полной синхронности (для дальнейшего сложения). Эта возможность, лично для меня, была бы прорывной, т.к. вручную подобную синхронизацию делать сложно.
Судя по одному из последних сеансов, которые тебе пришлось выполнять, когда 3 телескопа были направлены на один объект и требовалось синхронизировать их съемку — функция исполнения одного Плана на астрономическую ночь несколькими астрографами синхронно — это будет прорыв!
А почему неудобоваримый REST, который конкретно привязан к HTTP, а не современный JSON pure, который во-первых удобнее, во-вторых мухи среды передачи отделены от котлет содержимого запроса, да и вообще хорошЕе по многим другим причинам?
А я ничё не понял.
Если кто не заметил, то в современных монтировках до сих пор есть ком-порты. Это что значит? Что тема не на гребне волны и … я, честно сказать тоже. У меня XP на астрокомпах и 7ка на основном.
JSON, он и в африке JSON. Будет ли он поверх HTTP или нет — вся разница в 100 байтах заголовков.
Это значит, что ты подменяешь понятия, т.к. не старый телескоп с ком-портом восстанавливаешь из руин, а новосовременную (как сам вроде писАл) мегапрограмму делаешь.
Сравнение не принимается, низачот!
100 байтов заголовка — и к чему это? Тема сис… JSON не раскрыта.
Не…. единственное значимое отличие вебсокета и get/post запроса от браузера в получении событийно-ориентированной модели от сервера к клиенту, а не только от клиента к серверу.
Есть ещё в вебсокете возможность получить событие от клиента к многим клиентам (через сервер), но здесь одно- (мало-) пользовательская система и эта возможность не будет использоваться.
Вот и выходит, что можно получить плюс в виде события от астрографа. Но нам всё равно надо раз в несколько секунд сканировать backend для получения и отображения текущего статуса. Туда же можно вставить и ссылку на событие. Поэтому вебсокеты — это очень круто, но в данном применении не несут большой прибыли, кроме повышения актуализации с 3..5 сек до «почти моментально».
Ежли я правильно понял суть статьи и ты говоришь о сокетах без http.
На мой взгляд основное — Request-Response-Confirmation и независимость от протокола. Хочешь HTTP — дерзай, надо что-то добавить через веб-сокеты — да не вопрос. И всё это в единой системе понятий, словарей, схем и т.д.
Прочёл https://mmikowski.github.io/json-pure/
Я думал собрать на вебсокетах, но решил отказаться. О том в этой статье чуть сказано.