Комментарии 31
По-моему, это вполне материал для Хабра. По теме — неплохо так, аккуратно за счет бутстрапа и очевидно что автор энтерпрайз-программист (со всеми вытекающими плюсами и минусами :)). Единственное — комментарии в коде на русском скорее всего отпугнут иностранных контрибьюторов.
P.S. Схему с архитектурой приложения вполне можно вставить в статью, имхо более удобно.
P.S. Схему с архитектурой приложения вполне можно вставить в статью, имхо более удобно.
Включать свет в комнатах при присутствии человека, раздвигать шторы или поднимать жалюзи при восходе солнца умеет из коробки?
Включать свет можно с помощью датчиков движения и силовых блоков nooLite (при этом можно навесить дополинтельно любую логику). Вообще, из коробки поддерживаются все возможности nooLite, включая получение данных с датчиков температуры/влажности и управление светодиодными RGB лентами.
По поводу жалюзи — есть возможность «из коробки» определить время восхода/захода солнца (эти данные загружаются из интернета плагином «прогноз погоды»), но механическая часть зависит от Вашего привода жалюзи. Если он управляется замыканием/размыканием провода с питанием 220В, то можно сделать тоже через nooLite.
По поводу жалюзи — есть возможность «из коробки» определить время восхода/захода солнца (эти данные загружаются из интернета плагином «прогноз погоды»), но механическая часть зависит от Вашего привода жалюзи. Если он управляется замыканием/размыканием провода с питанием 220В, то можно сделать тоже через nooLite.
За временем восхода-захода вовсе необязательно лезть в интернет, можно все локально посчитать — en.wikipedia.org/wiki/Sunrise_equation
НЛО прилетело и опубликовало эту надпись здесь
Если честно, я думал, что слово ".NET" в названии статьи даст понять людям, не любящим эту платформу, что тема для них будет не очень интересна и таким образом удастся избежать вопросов о выборе платформы :)
А если серьезно, то в моей конкретной ситуации по совокупности критериев .NET оказался лучше остальных платформ. Кроме критериев «распространенность» и «кроссплатформенность» учитывались критерии «наличие опыта работы с платформой», «качество средств разработки», «наличие и качество готовых компонентов» и другие.
Думаю, значительной части людей .NET не подойдет. Мне жаль, что мой проект не может принести им пользу, но вместе с тем я понимаю, что нельзя сделать штуку, которая подойдет абсолютно всем. На мой взгляд, лучше очень качественно сделать специализированную вещь для небольшого числа людей, чем универсальную, но низкого качества. Надеюсь, Вы меня понимаете…
А если серьезно, то в моей конкретной ситуации по совокупности критериев .NET оказался лучше остальных платформ. Кроме критериев «распространенность» и «кроссплатформенность» учитывались критерии «наличие опыта работы с платформой», «качество средств разработки», «наличие и качество готовых компонентов» и другие.
Думаю, значительной части людей .NET не подойдет. Мне жаль, что мой проект не может принести им пользу, но вместе с тем я понимаю, что нельзя сделать штуку, которая подойдет абсолютно всем. На мой взгляд, лучше очень качественно сделать специализированную вещь для небольшого числа людей, чем универсальную, но низкого качества. Надеюсь, Вы меня понимаете…
А представьте, человеку интересен «умный дом», описывается вполне развитая система, а тут раз, и .NET — что, проходить мимо?
Собственно, я бы например, не комментил, если бы статья была на старом добром хабре «до fallout'а». Но посмотрите, что мы имеем сейчас — хаб здесь, на geektimes, пуст, по сравнению с тем, каким он был на habr. Большинство интересных статей осталось там. Но потеряли тег раздела «умный дом». Их уже трудно найти. Они еще имеют тег «DIY», но и он в очереди на выпиливание. Поэтому либо мы, люди интересующиеся «умным домом», таки соберемся здесь на GT, отметимся в каментах, и попытаемся восстановить community, либо-либо…
Собственно, я бы например, не комментил, если бы статья была на старом добром хабре «до fallout'а». Но посмотрите, что мы имеем сейчас — хаб здесь, на geektimes, пуст, по сравнению с тем, каким он был на habr. Большинство интересных статей осталось там. Но потеряли тег раздела «умный дом». Их уже трудно найти. Они еще имеют тег «DIY», но и он в очереди на выпиливание. Поэтому либо мы, люди интересующиеся «умным домом», таки соберемся здесь на GT, отметимся в каментах, и попытаемся восстановить community, либо-либо…
Ну насчет кроссплатформенности .NET весьма недурная штука, во всяком случае для backend. Нормально написанное ПО отлично работает под Mono. Скомпилировал в Visual Studio, запустил под Linux :)
Вот то редактирование кода в бразуере — на кого оно рассчитано? Дело в том, что имея сотню скриптов (ведь мы говорим об умном доме, правда?), которые нужно разрабатывать и настраивать в течение долгого времени, то когда я захочу сделать правку, первым делом я захочу сделать git blame, git log -p и т.п. на этот скрипт, а потом уже вносить изменения. Так для кого все эти редакторы кода в бразере? Для блондинок? Увы, они не будут писать код вообще. А те кто будут писать код, очень скоро, если не сразу, захотят доступную структуру (как в дереве каталогов файловой системы), контроль версий, комфорт любимого редактора и т.п.
Собственно, вопрос не только к вам, а ко многим авторам, которые в последне время постились на Хабре. Вот Bluefox'а, автора этой системы, удалось «поймать» на признании: «Сразу скажу, что наверняка есть возможность то же самое сделать с ScriptGUI, но я этим не пользуюсь, т.к. мне быстрее написать JS, чем рисовать.» Т.е. в его системе есть супер-пупер гуевый редактор скриптов и ивентов, только он сам говорит, что рисовать комиксы более сложно и нудобно, чем просто писать на языке.
Дальше больше — зачем писать скрипты в браузере, не лучше ли это делать в терминале, в любимом редакторе или IDE, с git'ом под рукой? Дальше больше — в системе Bluefox'а есть редактор форм — опупеть, можно сделать произвольные страницы управления и отображения в браузере. Вот только позиционирование абсолютное, т.е. делаются под конкретное разрешение экрана. Нужен умный дом на компе, планшете, телефоне? Сделай одно и тоже три раза подряд. У жен другой телефон? Сделай еще раз. Купил новый планшет? И еще раз сделай тупую обезьянью работу. Вопрос все тот же — а зачем такое редактор форм нужен? Не легче ли зупустить vim/mc/sublime и неспешно патчить CSS, чтобы добиться responsive design, коммитая в git, чтобы через пол-года легко найти, откуда взялся какой-то regression.
И подытоживая, главный вопрос — господа, для кого вы пишите все эти системы, кто их target audience? Все эти гуевые редакторы — прекрасно для еще одного стартапа-который-не-взлетел (ну потому что не будут простые милые добрые люди писать код и алгоритмы — хоть в браузере, хоть без, хоть в буквах, хоть в комиксах), но вполне себе излишни для open-source-проекта-чтобы-реально-работал.
Собственно, вопрос не только к вам, а ко многим авторам, которые в последне время постились на Хабре. Вот Bluefox'а, автора этой системы, удалось «поймать» на признании: «Сразу скажу, что наверняка есть возможность то же самое сделать с ScriptGUI, но я этим не пользуюсь, т.к. мне быстрее написать JS, чем рисовать.» Т.е. в его системе есть супер-пупер гуевый редактор скриптов и ивентов, только он сам говорит, что рисовать комиксы более сложно и нудобно, чем просто писать на языке.
Дальше больше — зачем писать скрипты в браузере, не лучше ли это делать в терминале, в любимом редакторе или IDE, с git'ом под рукой? Дальше больше — в системе Bluefox'а есть редактор форм — опупеть, можно сделать произвольные страницы управления и отображения в браузере. Вот только позиционирование абсолютное, т.е. делаются под конкретное разрешение экрана. Нужен умный дом на компе, планшете, телефоне? Сделай одно и тоже три раза подряд. У жен другой телефон? Сделай еще раз. Купил новый планшет? И еще раз сделай тупую обезьянью работу. Вопрос все тот же — а зачем такое редактор форм нужен? Не легче ли зупустить vim/mc/sublime и неспешно патчить CSS, чтобы добиться responsive design, коммитая в git, чтобы через пол-года легко найти, откуда взялся какой-то regression.
И подытоживая, главный вопрос — господа, для кого вы пишите все эти системы, кто их target audience? Все эти гуевые редакторы — прекрасно для еще одного стартапа-который-не-взлетел (ну потому что не будут простые милые добрые люди писать код и алгоритмы — хоть в браузере, хоть без, хоть в буквах, хоть в комиксах), но вполне себе излишни для open-source-проекта-чтобы-реально-работал.
Спасибо за Ваш вопрос! Если честно, при написании статьи я очень сильно фильтровал ее содержание, чтобы осталось только самое основное. Иначе получилась бы трудновоспринимаемая каша и никто ничего бы не понял. Такие вопросы, как Ваш, помогают лучше раскрыть тему, и я рад им.
Собственно, по теме вопроса… если убрать эмоции, то Вы, по сути, пишете, что уже существуют IDE — привычные, удобные инструменты с огромными возможностями и при настройке сценариев умного дома Вам хотелось бы пользоваться ими, а не самописным UI.
На самом деле все так и устроено. Дело в том, что в системе есть два уровня, на которых выполняются действия: уровень плагинов и уровень сценариев (действия обоих уровней выполняются на стороне сервиса автоматизации).
Плагины пишутся на .NET и компилируются в DLL. Для их разработки можно использовать IDE, системы контроля версий и другие клевые штуки, которые люди придумали для программистов. Сложные последовательности действий и UI лучше (и нужно) реализовывать в плагинах.
Сценарии пишутся на JavaScript, хранятся в БД в виде текста и выполняются при помощи интерпретатора JS. Сценарии предназначены для настройки выполнения действий при наступлении событий. Иногда нужно не просто выполнить действия при наступлении события, но и добавить некоторую дополнительную логику. Например, выполнить какую-то простую проверку или задать последовательность сложных действий, которые вне конкретной ситуации не связаны между собой. Многие системы настраивают такие вещи через UI, но, на мой взгляд, намного проще написать несколько строчек кода, чем, например, конструировать с UI логиеское выражение для выполнения проверки. Предполагается, что все сценарии будут относительно простыми и отсутствие IDE не сильно затруднит работу с ними.
Вы также упомянули неудобства, связанные с большими списками сценариев, в которых может быть несколько сотен элементов. В этом с Вами полностью согласен — необходима доработка системы, позволяющая как-то организовать сценарии. Но я думаю, более удобно будет работать не с иерархической структурой папок, а назначать сценариям тэги и фильтровать по ним. Я пока не реализовал это, т.к. еще не было реальной ситуации, когда имелся бы такой большой список сценариев. В будущем это обязательно будет реализовано. Если Вы планируете использовать мой проект и эта доработка необходима срочно — напишите мне, я сделаю ее в первую очередь.
Собственно, по теме вопроса… если убрать эмоции, то Вы, по сути, пишете, что уже существуют IDE — привычные, удобные инструменты с огромными возможностями и при настройке сценариев умного дома Вам хотелось бы пользоваться ими, а не самописным UI.
На самом деле все так и устроено. Дело в том, что в системе есть два уровня, на которых выполняются действия: уровень плагинов и уровень сценариев (действия обоих уровней выполняются на стороне сервиса автоматизации).
Плагины пишутся на .NET и компилируются в DLL. Для их разработки можно использовать IDE, системы контроля версий и другие клевые штуки, которые люди придумали для программистов. Сложные последовательности действий и UI лучше (и нужно) реализовывать в плагинах.
Сценарии пишутся на JavaScript, хранятся в БД в виде текста и выполняются при помощи интерпретатора JS. Сценарии предназначены для настройки выполнения действий при наступлении событий. Иногда нужно не просто выполнить действия при наступлении события, но и добавить некоторую дополнительную логику. Например, выполнить какую-то простую проверку или задать последовательность сложных действий, которые вне конкретной ситуации не связаны между собой. Многие системы настраивают такие вещи через UI, но, на мой взгляд, намного проще написать несколько строчек кода, чем, например, конструировать с UI логиеское выражение для выполнения проверки. Предполагается, что все сценарии будут относительно простыми и отсутствие IDE не сильно затруднит работу с ними.
Вы также упомянули неудобства, связанные с большими списками сценариев, в которых может быть несколько сотен элементов. В этом с Вами полностью согласен — необходима доработка системы, позволяющая как-то организовать сценарии. Но я думаю, более удобно будет работать не с иерархической структурой папок, а назначать сценариям тэги и фильтровать по ним. Я пока не реализовал это, т.к. еще не было реальной ситуации, когда имелся бы такой большой список сценариев. В будущем это обязательно будет реализовано. Если Вы планируете использовать мой проект и эта доработка необходима срочно — напишите мне, я сделаю ее в первую очередь.
Спасибо за ответ. Но суть его можно свести к «имеет смысл делать почти одинаковые вещи двумя разными способами» и «я думаю, что работать с кодом будет удобнее не так, как с ним работали испокон веков, а как-то по-другому». Звучит неубедительно. Нет, на самом деле, я и сам мог наверное хотеть бы делать как-то так, если бы реально не делал что-то такое свое и не вел список из ~20 других проектов, которые тоже что-то как-то, но не всегда понятно, зачем, делают.
Собственно, не спора ради. Просто «свежая» мысль, которой хотелось поделиться с авторами систем умного дома.
Не смогу, даже если я захочу. Во-первых, инструкции по установки предполагают Windows, у меня его нет (впрочем, вру, есть — недавно получил Intel Galileo с Windows for IoT — будет под ним работать ваша система?). Далее, мой «умный дом» сейчас крутиться на Android планшете. Даже если ваша система (за)работает под Mono, скольку усилий придется потратить на сборку Mono в каком-нибудь Optware и как он будет там работать? Ну и наконец, виджеты только двух размеров — «normal» и «wide» меня не устраивают — а если я хочу 1x2 или 2x2? (Последняя проблема собственно объективно отражает суть моей критики веб-код-редакторов и прочих плюшек — зачем тратить на них время, вместо того, чтобы сделать базовые фичи, как например виджеты произвольных размеров?)
Собственно, не спора ради. Просто «свежая» мысль, которой хотелось поделиться с авторами систем умного дома.
Если Вы планируете использовать мой проект и эта доработка необходима срочно — напишите мне, я сделаю ее в первую очередь.
Не смогу, даже если я захочу. Во-первых, инструкции по установки предполагают Windows, у меня его нет (впрочем, вру, есть — недавно получил Intel Galileo с Windows for IoT — будет под ним работать ваша система?). Далее, мой «умный дом» сейчас крутиться на Android планшете. Даже если ваша система (за)работает под Mono, скольку усилий придется потратить на сборку Mono в каком-нибудь Optware и как он будет там работать? Ну и наконец, виджеты только двух размеров — «normal» и «wide» меня не устраивают — а если я хочу 1x2 или 2x2? (Последняя проблема собственно объективно отражает суть моей критики веб-код-редакторов и прочих плюшек — зачем тратить на них время, вместо того, чтобы сделать базовые фичи, как например виджеты произвольных размеров?)
Вы затронули несколько вопросов. Пожалуй, отвечу на каждый в отдельном комментарии, чтобы можно было обсуждать их отдельно.
Параметр «двойной размер» по сути добавляет элементу предопределенный css класс. Вы можете описать собственный css класс (с нужными размерами) и указать его в поле «className».
виджеты только двух размеров — «normal» и «wide» меня не устраивают
Параметр «двойной размер» по сути добавляет элементу предопределенный css класс. Вы можете описать собственный css класс (с нужными размерами) и указать его в поле «className».
public override void FillModel(TileModel model, dynamic options)
{
...
// классы элемента разделяются пробелом
model.className = "btn-primary my-super-css-class";
}
недавно получил Intel Galileo с Windows for IoT
По идее, если там есть нормальный .NET, то должно работать. ОЧень интересно было бы это проверить.
Спасибо за ответ. Но суть его можно свести к «имеет смысл делать почти одинаковые вещи двумя разными способами» и «я думаю, что работать с кодом будет удобнее не так, как с ним работали испокон веков, а как-то по-другому». Звучит неубедительно. Нет, на самом деле, я и сам мог наверное хотеть бы делать как-то так, если бы реально не делал что-то такое свое и не вел список из ~20 других проектов, которые тоже что-то как-то, но не всегда понятно, зачем, делают.
Этот кусок совсем не понял, поясните, пожалуйста.
Если привести пример из жизни, то, когда Вы строите дом, Вы будете копать котлован экскаватором, а если нужно посадить дерево, Вы будете использовать лопату, т.к. это проще и удобнее для данной задачи. Хотя в обоих случаях вы копаете землю и в обоих случаях верно утверждение «экскаватор позволяет копать удобно и очень производительно».
Кстати, кажется, я забыл написать в документации про отладку сценариев.
Поддерживается отладка в Visual Studio. В настройках сервиса нужно разрешить отладку сценариев и добавить в текст сценария команду
Когда выполнение дойдет до этой команды, появится диалоговое окно, предлагающее запустить отладчик (Visual Studio должна быть установлена на компьютере, на котором работает сервис). Процесс отладки ничем не отличается от отладки браузерных js-скриптов.
Сегодня добавлю это в документацию.
Поддерживается отладка в Visual Studio. В настройках сервиса нужно разрешить отладку сценариев и добавить в текст сценария команду
debugger;
Когда выполнение дойдет до этой команды, появится диалоговое окно, предлагающее запустить отладчик (Visual Studio должна быть установлена на компьютере, на котором работает сервис). Процесс отладки ничем не отличается от отладки браузерных js-скриптов.
Сегодня добавлю это в документацию.
Раз уж здесь затронули ccu.io :), позвольте ответить, хоть это и не моя статья.
Первым делом надо заметить, что желания и возможности часто расходятся. В моём случае так и есть и не всё что я желаю мы можем реализовать (исключительно из временных ограничений). Скрипты я редактирую исключительно в моей IDE и не пользуюсь редактором в браузере (только если с работы иногда нужно что нибудь подправить).
А дело было так, что человек, который разработал ScriptGUI просто написал нам письмо: «что так мол и так. Я написал графическую оболочку для редактора сценариев. Посмотрите».
То есть он пришел с готовой исполненной системой, которую, кстати, успешно использует треть пользователей ccu.io. У него было своё видение проекта, которое он посчитал полезным. Нам нужно было сказать: иди лесом? В итоге получился интересный проект, который нашёл своих пользователей.
Что я хочу сказать, что у нас есть и экскаватор и лопата (#)и даже грабли, что бы вырыть яму и это пользователь должен решить, чем он хочет пользоваться.
Это о скриптах.
А вы пробовали создать drag&drop систему с адаптивным дизайном? Я пробовал…
Для адаптивного дизайна есть yahui на jQuery Mobile, но с её помощью нельзя и близко создать, то что можно сделать с DashUI.
Так что для разных потребностей, опять таки, разные инструменты. Yahui для телефона. DashUI для таблета и десктопа.
Нет. Не легче. Это пройденный этап. Когда квартира строилась, то каждый месяц добавлялся новый датчик или исполнительное устройство, нужно было каждый раз лезть в код, задавать ручками ID и т.д и т.п.
Кстати, никто не мешает писать самому свои страницы с SlimUI c каким угодно дизайном.
Итог: всем угодить нельзя, но можно создать платформу к которой можно подключать разные модули для разных задач.
Первым делом надо заметить, что желания и возможности часто расходятся. В моём случае так и есть и не всё что я желаю мы можем реализовать (исключительно из временных ограничений). Скрипты я редактирую исключительно в моей IDE и не пользуюсь редактором в браузере (только если с работы иногда нужно что нибудь подправить).
А дело было так, что человек, который разработал ScriptGUI просто написал нам письмо: «что так мол и так. Я написал графическую оболочку для редактора сценариев. Посмотрите».
То есть он пришел с готовой исполненной системой, которую, кстати, успешно использует треть пользователей ccu.io. У него было своё видение проекта, которое он посчитал полезным. Нам нужно было сказать: иди лесом? В итоге получился интересный проект, который нашёл своих пользователей.
Что я хочу сказать, что у нас есть и экскаватор и лопата (#)и даже грабли, что бы вырыть яму и это пользователь должен решить, чем он хочет пользоваться.
Это о скриптах.
системе Bluefox'а есть редактор форм — опупеть, можно сделать произвольные страницы управления и отображения в браузере. Вот только позиционирование абсолютное, т.е. делаются под конкретное разрешение экрана.
А вы пробовали создать drag&drop систему с адаптивным дизайном? Я пробовал…
Для адаптивного дизайна есть yahui на jQuery Mobile, но с её помощью нельзя и близко создать, то что можно сделать с DashUI.
Так что для разных потребностей, опять таки, разные инструменты. Yahui для телефона. DashUI для таблета и десктопа.
Не легче ли зупустить vim/mc/sublime и неспешно патчить CSS, чтобы добиться responsive design, коммитая в git, чтобы через пол-года легко найти, откуда взялся какой-то regression.
Нет. Не легче. Это пройденный этап. Когда квартира строилась, то каждый месяц добавлялся новый датчик или исполнительное устройство, нужно было каждый раз лезть в код, задавать ручками ID и т.д и т.п.
Кстати, никто не мешает писать самому свои страницы с SlimUI c каким угодно дизайном.
Итог: всем угодить нельзя, но можно создать платформу к которой можно подключать разные модули для разных задач.
Ну что Вы так волнуетесь! Никто не сомневается, что у Вас хорошая система. А сделать идеальную штуку, которая подходит всем — в любом случае невозможно.
Спасибо, что присоединились к обсуждению!
Вот так сходу — точно нет конечно. Но одним из возможных продуктивных ответов (не в вашем случае — вообще) является: «Замечательно! Напишите, испытывали ли вы сложности с интеграцией — возможно, что-то недокументировано? А так, будем рады, если вы будете maintain'ить ваш проект сами — мы не можем тянуть все, а вот создать интеграционную платформу, которую бы поддерживали разные независимые разработчики — очень хотим».
Впрочем, если «которую, кстати, успешно использует треть пользователей ccu.io», то все очень хорошо. А откуда данные? Короче говоря, пишите новые статьи о вашей системе, если будет время — очень интересно.
Ну т.е. иными словами, идея «web-технологии позволяет 1 раз сделать интерфейс, который будет работать везде» реально не работает…
Вот это как раз суть того, что я хочу найти, и что увы не нахожу. Все норовят представить свою систему как «блекджек со ...», никто не пишет «наша система состоит из фронтенда и бекенда, все зависимости между ними четко документированы, если вас не устраивает наш моднячий бекенд на Java+.Net+Mongo+NodeJS в одном флаконе, выкиньте его нафик, и напишите свой.» Ближайшее, что я видел в этом направлении — это phpMyDomo но и тот зачем-то тащит PHP. А так в большинстве случаев мы имеем ситуацию, что если например проект на .NET, то даже юзеро-интерфейсный javascript надо прятать в DLLки, как же иначе.
человек, который разработал ScriptGUI просто написал нам письмо: «что так мол и так. Я написал графическую оболочку для редактора сценариев. Посмотрите». Нам нужно было сказать: иди лесом?
Вот так сходу — точно нет конечно. Но одним из возможных продуктивных ответов (не в вашем случае — вообще) является: «Замечательно! Напишите, испытывали ли вы сложности с интеграцией — возможно, что-то недокументировано? А так, будем рады, если вы будете maintain'ить ваш проект сами — мы не можем тянуть все, а вот создать интеграционную платформу, которую бы поддерживали разные независимые разработчики — очень хотим».
Впрочем, если «которую, кстати, успешно использует треть пользователей ccu.io», то все очень хорошо. А откуда данные? Короче говоря, пишите новые статьи о вашей системе, если будет время — очень интересно.
Так что для разных потребностей, опять таки, разные инструменты. Yahui для телефона. DashUI для таблета и десктопа.
Ну т.е. иными словами, идея «web-технологии позволяет 1 раз сделать интерфейс, который будет работать везде» реально не работает…
но можно создать платформу к которой можно подключать разные модули для разных задач.
Вот это как раз суть того, что я хочу найти, и что увы не нахожу. Все норовят представить свою систему как «блекджек со ...», никто не пишет «наша система состоит из фронтенда и бекенда, все зависимости между ними четко документированы, если вас не устраивает наш моднячий бекенд на Java+.Net+Mongo+NodeJS в одном флаконе, выкиньте его нафик, и напишите свой.» Ближайшее, что я видел в этом направлении — это phpMyDomo но и тот зачем-то тащит PHP. А так в большинстве случаев мы имеем ситуацию, что если например проект на .NET, то даже юзеро-интерфейсный javascript надо прятать в DLLки, как же иначе.
Блин, это уже третий Ваш комментарий, смысл которого мне не понятен :(
И что Вы имеете против скриптов в ресурсах? FYI это было сделано не из-за ограничений платформы, а для удобства установки плагинов (чтобы все необходимое было в одном файле).
И что Вы имеете против скриптов в ресурсах? FYI это было сделано не из-за ограничений платформы, а для удобства установки плагинов (чтобы все необходимое было в одном файле).
> Блин, это уже третий Ваш комментарий, смысл которого мне не понятен :(
Я рад изложить свои мысли более подробно, особенно если вы не будете воспринимать их как критику. Глобальный вопрос, над которым я здесь философствую — это как мы (международное сообщество любителей Open Source Smart Home'а) дошли до жизни такой, что есть 20-30 проектов, причем половина из них — реально активные, и при этом все время появляются новые, и некоторые люди (например вы) отдают им месяцы своего времени. И при всем этом, другие люди (например я), которые не хотят писать свое с нуля, а хотят найти подходящий проект для использования/участия, не могут такой найти, при казалось бы большом выборе «на любой вкус».
> FYI это было сделано не из-за ограничений платформы,
Конечно же, возможность пихать ресурсы в DLL — это не ограничение платформы. Это ее дополнительная фича. И вы эту фичу abuse'ите! Вы же сами привели ссылку «на вы все еще не любите JavaScript?» и там же одним из главных пунктов идет легкость вхождения и доступность. Если я захочу сделать динамическую веб-страничку, я могу это сделать на любом компе, потому закинуть на любой сервер, и если потом найду проблему, зайду на этот любой сервер и прямо там исправлю. А теперь сравните с вашей системой — я поставил ее, а через месяц увидел мелкую проблему в веб-интерфейсе. Я прекрасно знаю, как чинятся проблемы с веб-интерфейсом, залажу в каталог, и вместо привычных html, css, js вижу какие-то бинарники и узнаю, что чтобы поправить веб-интерфейс, вы хотите меня заставить вспоминать .NET и изучать, что там нового сталось за N лет, что я его не трогал. Тут-то наши пути и разойдутся.
> для удобства установки плагинов (чтобы все необходимое было в одном файле).
И на это я отвечал уже — это очень удобно для пропраетарного коммерческого продукта, и очень неудобно для open-source проекта (вы просто совершенно искусственно подымаете порог вхождения для потенциальных contributor'ов).
Я рад изложить свои мысли более подробно, особенно если вы не будете воспринимать их как критику. Глобальный вопрос, над которым я здесь философствую — это как мы (международное сообщество любителей Open Source Smart Home'а) дошли до жизни такой, что есть 20-30 проектов, причем половина из них — реально активные, и при этом все время появляются новые, и некоторые люди (например вы) отдают им месяцы своего времени. И при всем этом, другие люди (например я), которые не хотят писать свое с нуля, а хотят найти подходящий проект для использования/участия, не могут такой найти, при казалось бы большом выборе «на любой вкус».
> FYI это было сделано не из-за ограничений платформы,
Конечно же, возможность пихать ресурсы в DLL — это не ограничение платформы. Это ее дополнительная фича. И вы эту фичу abuse'ите! Вы же сами привели ссылку «на вы все еще не любите JavaScript?» и там же одним из главных пунктов идет легкость вхождения и доступность. Если я захочу сделать динамическую веб-страничку, я могу это сделать на любом компе, потому закинуть на любой сервер, и если потом найду проблему, зайду на этот любой сервер и прямо там исправлю. А теперь сравните с вашей системой — я поставил ее, а через месяц увидел мелкую проблему в веб-интерфейсе. Я прекрасно знаю, как чинятся проблемы с веб-интерфейсом, залажу в каталог, и вместо привычных html, css, js вижу какие-то бинарники и узнаю, что чтобы поправить веб-интерфейс, вы хотите меня заставить вспоминать .NET и изучать, что там нового сталось за N лет, что я его не трогал. Тут-то наши пути и разойдутся.
> для удобства установки плагинов (чтобы все необходимое было в одном файле).
И на это я отвечал уже — это очень удобно для пропраетарного коммерческого продукта, и очень неудобно для open-source проекта (вы просто совершенно искусственно подымаете порог вхождения для потенциальных contributor'ов).
Я рад изложить свои мысли более подробно, особенно если вы не будете воспринимать их как критику.
Извините, не хотел, чтобы Вы подумали, будто я негативно настроен по отношению к Вам. Просто, действительно, не понимаю, что Вы хотите сказать: у Вас очень общие рассуждения и не могу из этого сделать конкретный вывод.
Вы пишете о проблеме, но я не вижу ее. На мой взгляд, абсолютно нормально наличие большого числа подобных проектов и нет ничего особенного в том, что некоторым людям не нравится ни один из них (особенно, если учитывать, что их критерии — субъективны).
На счет размещения файлов в ресурсах DLL: никто Вам не запрещает сделать html-страничку и обращаться к API сервиса. Кроме того, в случае, когда UI находится в ресурсах DLL у Вас, вероятно, есть исходные коды этого плагина и их редактирование не намного сложнее изменения файлов на «боевой» системе (а выкладка исправленного файла происходит очень легко, т.к. нужно скопировать на сервер всего один файл DLL).
При беглом просмотре — КРУТО! Вы молодец!
Но, мне, как потенциальному пользователю, хотелось бы все-таки видеть платформу SM с IDE\GUI для разработки «лица» — интерфейса. Т.е. готовые контролы (баттоны, шкалы, gauge и другие), которые я могу драг-энд-дропнуть к себе, настроить их свойства статически или динамически в скрипте и быть счастливым. Пусть даже мне придется разратывать несколько версий дизайна для разных устройств.
До тех пор, пока приходится для создания GUI писать скрипты все эти системы теряют ОООЧЕНЬ большую часть «гиков», как мне кажется.
Каждый раз я вижу такую систему, и каждый раз понимаю — мне нужно учить скрипты\программирование на конкретном языке.
Я же хотел бы видеть готовый инструмент как в SCADA системах именно для «настройки» системы, а не программирования. Программирование — это уже по желанию.
Кстати, смотрел быстро — у вас поддерживается Модбас?) Если нет -очень хотелось бы!
Если бы появилась полноценная SCADA с IDE, я бы такую даже купил!)
Но, мне, как потенциальному пользователю, хотелось бы все-таки видеть платформу SM с IDE\GUI для разработки «лица» — интерфейса. Т.е. готовые контролы (баттоны, шкалы, gauge и другие), которые я могу драг-энд-дропнуть к себе, настроить их свойства статически или динамически в скрипте и быть счастливым. Пусть даже мне придется разратывать несколько версий дизайна для разных устройств.
До тех пор, пока приходится для создания GUI писать скрипты все эти системы теряют ОООЧЕНЬ большую часть «гиков», как мне кажется.
Каждый раз я вижу такую систему, и каждый раз понимаю — мне нужно учить скрипты\программирование на конкретном языке.
Я же хотел бы видеть готовый инструмент как в SCADA системах именно для «настройки» системы, а не программирования. Программирование — это уже по желанию.
Кстати, смотрел быстро — у вас поддерживается Модбас?) Если нет -очень хотелось бы!
Если бы появилась полноценная SCADA с IDE, я бы такую даже купил!)
Modbus добавили в список планируемых задач.
Добавляйтесь в нашу группу вконтакте — там все последние новости.
Добавляйтесь в нашу группу вконтакте — там все последние новости.
Просто интересно. А вы видели dashui.ccu.io?
Вроде drag&drop…
Вроде drag&drop…
Да, я читал вашу статью — очень даже.
Но опять же, модбас… )
Вы пробовали OpenHAB?
Но опять же, модбас… )
Вы пробовали OpenHAB?
А, так это ВЫ ДЕЛАЛИ CCU.IO?))))) Кррррууууто! я когда читал вашу статью — думал вы просто используете готовое!:)
Что-то видимо не отложилось в памяти, сейчас перечитал статью.
Но вопрос по Modbus остался открытым. Для меня просто это самый «знакомый» и «удобный» интерфейс, да и модули IO — что важно, недорого стоят.
Что-то видимо не отложилось в памяти, сейчас перечитал статью.
Но вопрос по Modbus остался открытым. Для меня просто это самый «знакомый» и «удобный» интерфейс, да и модули IO — что важно, недорого стоят.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мой умный дом на .NET, версия 2.0