Как стать автором
Обновить

Комментарии 9

Удивительно и интересно. Но пока что непонятно, как оно связывается с реальными устройствами. В примере с котельной, где находится код, опрашивающий устройства по Ethernet?

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

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

Интересно, каким образом зарабатываете на проекте. Доработка под заказ? Поддержка?

Разработка, доработка и поддержка. Доработка в основном если меняется или добавляется оборудование. Чаще всего нужно только написать новое устройство (если нет готового) и подменить его в схеме - стоит это дешево.

Зачем JSON, если в формате Tree всё куда наглядней?

device Interval1
	type guide.Interval
	param timeout 1000
device Interval2
	type guide.Interval
	param timeout 10000
	param retryCount 3
device Counter
	type guide.Counter
connection
	Interval1.gate -> Counter.increment
	Interval2.gate -> Counter.reset

Или даже так:

Interval1 guide.Interval
	timeout 1000
Interval2 guide.Interval
	timeout 10000
	retryCount 3
Counter guide.Counter
	increment <= Internal1.gate
	reset <= Internal2.gate

Это не имеет значения. JSON конечно используется как формат для схемы, но он в 99% случаев формируется генератором.

На самом деле можно написать адаптер, который будет из дерева формировать JSON, скорее всего модуль будет занимать не более 50 строк. Другое дело, готовы ли вы отказываться от генерации в пользу более понятного вида?

Зачем отказываться? Tree прекрасно генерируется.

Привет коллега! У меня очень похожая ситуация с проектом.

Круто и думаю что некое массовое использование и признание программе обеспечено.

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

Как уже писал, я тоже развиваю свой проект и так же больше разработчик, чем продажник, так же пользуюсь ею, тоже на ее базе делаю кастдев и так же всё не могу её раскачать. Однако в твоей статье вижу ответ в том что надо делать. А надо доделать до "законченный продукт" для нового пользователя. Сам как разработчик будешь обходить баги, нелогичности, дизайн, но новый пользователь при тесте будет спотыкаться и терять интерес к системе, можно только лично обучить. И когда будет доведёно до "конечного продукта", то можно пускать трафик. И просто ждать)). Но надо понимать что готовый продукт делать как ремонт можно только прекратить. Надо ставить адекватный уровень для финальной цели

Буду рад сотрудничеству, думаю у нас могут быть общие проекты. Я занимаюсь автоматизацией управленческого, складского учёта в малом бизнесе.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации