> Всё это уродливое нагромождение странных технологий, соединённых универсально-бесполезными интерфейсами. Все эти костыли, подпирающие структуру изначально созданную для других целей
> и его более молодого, всего-то пятнадцатилетнего лучшего клона & большого улучшения — vim
И его совсем юного продолжателя — neovim. В который добавлен полноценный терминал, асинхронные комманды и много других фич уже работающих или только планируемых
Поставить всю эту байду с ключами и ПО на сервер. Сотрудникам пробросить локальный прокси на нужный порт (через интернет в том числе). Если такая схема работает, то shut up and take my money
> Первое присвоение это _не_ изменение состояния, это его _создание_
Ну второй раз тоже напишите var перед переменной. Будет создание. В Rust так можно
А вот в Erlang, например, нельзя. И он не слишком популярен в том числе и по этой причине
PS: для полного погружения в ФП надо заставить апологетов редукс заменить все for на соответствующие рекурсивные вызовы. Посмотрим как долго они протянут
Ключевой момент в том, что вы приводите по-своему. Другой разработчик сделает иначе (другой формат данных, другая иерархия в топиков и т. д.) Так что MQTT в своем изначальном виде для домашней автоматизации малопригоден.
А вот если обвешать его допольнительными спеками и заставить всех эти спеки соблюдать — то тогда вполне. По крайней мере для малых проектов. Для распределенных, в которых много брокеров соединены в бриджи, между ними будет гоняться слишком много лишнего трафика
Подскажите, а как вы делаете сишные биндинги (всяких modbus и прочего) к ноде? Не вызывает ли этот процесс затруднений? Я в свое время отказался от ноды, осознав что придется использовать C++ и V8 API. Перешел на чистый libuv и lua. Может зря
> Хотя протокол взаимодействия от google Weave кажется наиболее продуманным
Похоже этот протокол будет сильно завязан на платформу Brillo от гугл. Если это так, то «общим знаменателем» для всех новых и существующих технологий и протоколов ему не быть. Ведь кто-то захочет сервер на OpenWrt, кто-то на Windows-десктопе…
> Каждый из производителей при этом, обязательно изобретает свой велосипед протоколов взаимодействия и никто не хочет уступать другому.
А вы не смотрели на полностью открытые Alljoyn и IoTivity?
Alljoyn это линуксовый dbus, расширенный для работы в распределенных системах. А IoTivity ближе к REST-сервисам. Оба поддерживают «PlugAndPlay» устройств, рефлексию API, стандартные профили (свет, кондиционеры, етц) и всё-всё чтобы носить звание протокола IoT (в отличие от MQTT, который больше паттерн pub/sub для сырых данных)
Судя по последним новостям эти группы собираются объединить свои усилия в пользу IoTivity
Порой слышу похожие слова в адрес «Си с плюсами»
И его совсем юного продолжателя — neovim. В который добавлен полноценный терминал, асинхронные комманды и много других фич уже работающих или только планируемых
Ну второй раз тоже напишите var перед переменной. Будет создание. В Rust так можно
А вот в Erlang, например, нельзя. И он не слишком популярен в том числе и по этой причине
PS: для полного погружения в ФП надо заставить апологетов редукс заменить все for на соответствующие рекурсивные вызовы. Посмотрим как долго они протянут
Почему нельзя использовать одну локальную переменную несколько раз? Кто запретил? Чем чревато?
Ключевой момент в том, что вы приводите по-своему. Другой разработчик сделает иначе (другой формат данных, другая иерархия в топиков и т. д.) Так что MQTT в своем изначальном виде для домашней автоматизации малопригоден.
А вот если обвешать его допольнительными спеками и заставить всех эти спеки соблюдать — то тогда вполне. По крайней мере для малых проектов. Для распределенных, в которых много брокеров соединены в бриджи, между ними будет гоняться слишком много лишнего трафика
Подскажите, а как вы делаете сишные биндинги (всяких modbus и прочего) к ноде? Не вызывает ли этот процесс затруднений? Я в свое время отказался от ноды, осознав что придется использовать C++ и V8 API. Перешел на чистый libuv и lua. Может зря
Похоже этот протокол будет сильно завязан на платформу Brillo от гугл. Если это так, то «общим знаменателем» для всех новых и существующих технологий и протоколов ему не быть. Ведь кто-то захочет сервер на OpenWrt, кто-то на Windows-десктопе…
> Каждый из производителей при этом, обязательно изобретает свой велосипед протоколов взаимодействия и никто не хочет уступать другому.
А вы не смотрели на полностью открытые Alljoyn и IoTivity?
Alljoyn это линуксовый dbus, расширенный для работы в распределенных системах. А IoTivity ближе к REST-сервисам. Оба поддерживают «PlugAndPlay» устройств, рефлексию API, стандартные профили (свет, кондиционеры, етц) и всё-всё чтобы носить звание протокола IoT (в отличие от MQTT, который больше паттерн pub/sub для сырых данных)
Судя по последним новостям эти группы собираются объединить свои усилия в пользу IoTivity