lol
нас тоже засосет, куда мы денемся. Я получаю поистине геймерское наслаждение, когда таки преодолеваю выполняю транзакцию и перехожу на следующий уровень. Но времени теряется столько!
главным становится вопрос задержек в реакции на действия пользователя...
Для того, чтобы была реакция на действия, необходимо заполнить поля. Порой, заполнение моей формы необходимо согласовать с 2-3 отделами! Иначе постигнет кара в виде мрачного сторно и повторного согласования с еще большим количеством лиц.
«Почему приходится согласовывать, что за глупость?», спросите вы. Да потому что три десятка полей в некоторые из которых (догадайся сам в какие) нужно ввести данные, которыми я не владею, но иначе я не выполню свою работу! И я должен принимать решения о типах данных, в которых я не компетентен.
Может, так новичкам везет, но на несколько попыток проведения транзакций (полтора — два десятка) пришлось 5 ошибок, с которыми пришлось бежать к программистам. После очередного исправления (о котором они, конечно, не уведомляют) начинается очередной день сурка, т.е очередная попытка провести транзакцию.
Работа растягивается на дни! Тут я не шучу. Возможно, учет там близок к идеалу, но КПД простых сотрудников при общении с программой порой падает до плинтуса.
1. Подавляющее большинство пользователей, которые хотят удобные экраны не имеют полномочий ставить задачи ни службе поддержки ни интегратору.
2. У нас немалый штат эртришников, их отдел принимает решение об обновлении ПО и убеждает руководство в необходимости (или отсутствии последней). Как думаете, как скоро они перейдут на новую версию из-за которой они станут не нужны и их придется сократить? А так они при деле.
Месячные не месячные, но курсы мы проходили. Первое, с чем сталкиваются начинающие — полное несоответствие принятым привычным интерфейсам и методам работы современного человека. Культурный шок. Контрактов нам читать не дают.
Мой процесс простой. Зачем мне интерфейс из сотен рычажков и лампочек, если я просто заправщик Боинга? Мой интерфейс — горловина топливного бака. А я тащу свой заправочный шланг через кабину пилота. В R3 в формах, которые я использую, я встречаю много полей, которые не имеют отношения к данным, с которыми работаю.
Программные интерфейсы тем и отличаются от «железных», что могут быть простыми. Мы же уже ушли из эры ранних вычислительных машин, где для каждой функции была своя кнопка и своя лампочка. Примеров сложных систем с простыми интерфейсами масса.
Просьба не обижаться. Нет в структуре ни одного предприятия, где я работал такого элемента. На курсах, где нас «прокачивали» по R3 для всех это слово было больше похоже на эвфемизм. Конечно, я поискал в словарях толкование слова «мандант». Зачем множить сущности без необходимости?
Похоже, тут Вы правы. Пошел учить матчасть. Однако, почему-то уверен, что это не просто взять ключ на 13 и прикрутить MQTT библиотеку.
F5, по-моему, для этих целей никто не использует. JS (jquery и т.п.) умеет получать данные без этого.
lingvo, вот это конкретный разговор!
1. Как я уже писал, все датчики имеют wifi модуль. Когда появляется питание на этом модуле он коннектится к точке доступа и там регистрируется! т.е. посылает get запрос со своим id. Сервер записывает в бд его IP (у меня последний октет IP). Там уже записаны id каждого реле. К каждой кнопке привязан id реле. Т.е. я, нажимая на кнопку посылаю запрос на сервер. Сервер, заглянув в бд, пересылает его по IP, где находится это реле. Простой прокси механизм.Т.е. вся конфигурация датчика состоит из параметров точки доступа.
2. Датчики посылают свои значения регулярно. Например, темп. и влажн. я отправляю раз в 3 минуты. Если сервер не получает данные с датчика более, скажем, 10 минут — тревожная запись в журнал (откровенно говоря, это еще не реализовано, но ясное представление как это сделать есть). Датчику знать ничего не надо. Сервер решает отправить смс, включить сирену или закрыть воду. Как я упоминал, вся логика на сервере. Исполняемые устройства с датчиками не связаны никак!
3. Это самое простое. Когда я открываю страницу в планшете (компьютере), для каждой кнопки отправляется запрос статуса реле (1 или 0) и отображается на странице. Если я включил свет с планшета, другой заходит с другого планшета и видит, что свет-то уже включен. Так работают все веб сервера. Сервер сообщает любому клиенту текущий статус и принимает команду от любого клиента.
4. Про модули с реле я уже писал, а датчикам вообще все равно, появилось питание, они подключаются к точке доступа и начинают слать свои регулярные запросы на известный всем адрес.
Эти усовершенствования уже были проведены до появления Ваших вопросов. Откуда неразбериха? Я же говорю, прототип рабочий. Логики ЕСЛИ-ТО на сервере пока не хватает. Реализацию этого этапа я бы обсудил более охотно.
Конечно, интересно. В плане применения модулей и организации взаимодействия с пользователем.
Возможно, знающие люди убедят меня в бесперспективности собственной разработки. То тогда и в плане внедрения конкретных проектов. Всегда восхищался людьми которые доводили дело до законченного решения.
Похоже, никому не верится, что это делается просто!
Отправляю get запрос (если надо json_encode) — в php получаю готовый объект одной командой json_decode;
С объектом делаю что хочу. Хочу отображаю пользователю, хочу исполняю условие в зависимости от параметров объекта
Зачем парсить заголовки?
Про какую систему Вы пишете? В моей системе поллинг еще изобретен не был.
Выключатель является датчиком. Датчики сами отправляют запросы на сервер, он передает его на исполняемое устройство (реле). Задержки в этом случае нет.
Я нажимаю на кнопку — get запрос через сервер (/control.php?slave=290&do=1) идет на wifi модуль с реле. Если планшет не тормозной задержки абсолютно не заметно. Обратно от модуля с реле возвращается ответ и отображается на состоянии кнопки (она подсвечивается). Никаких лишних запросов
Как я уже упомянул, сервер стоит полторы тыр. В рабочем режиме необходимо иметь один сконфигурированный прозапас. Файлы и бд лежат на usb диске. Замена неисправного сведется к перетыканию Ethernet кабелей и флешки из одного в другой.
Можно сделать кластер, scsi хранилище, только если играться очень серьезно.
Сейчас я использую простые GET запросы с ответами в формате json. Возможно мне стоит изучить преимущества этих протоколов. Чем упростит/улучшит обмен их использование?
Абсолютно согласен. Некоторые виртуальные элементы управления должны быть продублированы физическими. А физические могут опять же как отправлять команды на сервер, так и напрямую на устройство. Как я упомянул в статье я только собираюсь сделать такое дублирование.
Однако, эта технология позволяет создать нестандартные элементы управления.
Например — кубик размером с кружку. Положил на одну грань — включился свет, на другую — выключился. Повернул по часовой стрелке — ярче, обратно — тусклее. Внутри гироскоп (датчик наклона) и ESP01 с батарейкой.
нас тоже засосет, куда мы денемся. Я получаю поистине геймерское наслаждение, когда таки
преодолеваювыполняю транзакцию и перехожу на следующий уровень. Но времени теряется столько!Для того, чтобы была реакция на действия, необходимо заполнить поля. Порой, заполнение моей формы необходимо согласовать с 2-3 отделами! Иначе постигнет кара в виде мрачного сторно и повторного согласования с еще большим количеством лиц.
«Почему приходится согласовывать, что за глупость?», спросите вы. Да потому что три десятка полей в некоторые из которых (догадайся сам в какие) нужно ввести данные, которыми я не владею, но иначе я не выполню свою работу! И я должен принимать решения о типах данных, в которых я не компетентен.
Может, так новичкам везет, но на несколько попыток проведения транзакций (полтора — два десятка) пришлось 5 ошибок, с которыми пришлось бежать к программистам. После очередного исправления (о котором они, конечно, не уведомляют) начинается очередной день сурка, т.е очередная попытка провести транзакцию.
Работа растягивается на дни! Тут я не шучу. Возможно, учет там близок к идеалу, но КПД простых сотрудников при общении с программой порой падает до плинтуса.
2. У нас немалый штат эртришников, их отдел принимает решение об обновлении ПО и убеждает руководство в необходимости (или отсутствии последней). Как думаете, как скоро они перейдут на новую версию из-за которой они станут не нужны и их придется сократить? А так они при деле.
"… нам остаётся только есть кактус..." как выразился один из комментаторов
F5, по-моему, для этих целей никто не использует. JS (jquery и т.п.) умеет получать данные без этого.
1. Как я уже писал, все датчики имеют wifi модуль. Когда появляется питание на этом модуле он коннектится к точке доступа и там регистрируется! т.е. посылает get запрос со своим id. Сервер записывает в бд его IP (у меня последний октет IP). Там уже записаны id каждого реле. К каждой кнопке привязан id реле. Т.е. я, нажимая на кнопку посылаю запрос на сервер. Сервер, заглянув в бд, пересылает его по IP, где находится это реле. Простой прокси механизм.Т.е. вся конфигурация датчика состоит из параметров точки доступа.
2. Датчики посылают свои значения регулярно. Например, темп. и влажн. я отправляю раз в 3 минуты. Если сервер не получает данные с датчика более, скажем, 10 минут — тревожная запись в журнал (откровенно говоря, это еще не реализовано, но ясное представление как это сделать есть). Датчику знать ничего не надо. Сервер решает отправить смс, включить сирену или закрыть воду. Как я упоминал, вся логика на сервере. Исполняемые устройства с датчиками не связаны никак!
3. Это самое простое. Когда я открываю страницу в планшете (компьютере), для каждой кнопки отправляется запрос статуса реле (1 или 0) и отображается на странице. Если я включил свет с планшета, другой заходит с другого планшета и видит, что свет-то уже включен. Так работают все веб сервера. Сервер сообщает любому клиенту текущий статус и принимает команду от любого клиента.
4. Про модули с реле я уже писал, а датчикам вообще все равно, появилось питание, они подключаются к точке доступа и начинают слать свои регулярные запросы на известный всем адрес.
Эти усовершенствования уже были проведены до появления Ваших вопросов. Откуда неразбериха? Я же говорю, прототип рабочий. Логики ЕСЛИ-ТО на сервере пока не хватает. Реализацию этого этапа я бы обсудил более охотно.
Возможно, знающие люди убедят меня в бесперспективности собственной разработки. То тогда и в плане внедрения конкретных проектов. Всегда восхищался людьми которые доводили дело до законченного решения.
Отправляю get запрос (если надо json_encode) — в php получаю готовый объект одной командой json_decode;
С объектом делаю что хочу. Хочу отображаю пользователю, хочу исполняю условие в зависимости от параметров объекта
Зачем парсить заголовки?
Выключатель является датчиком. Датчики сами отправляют запросы на сервер, он передает его на исполняемое устройство (реле). Задержки в этом случае нет.
Я нажимаю на кнопку — get запрос через сервер (/control.php?slave=290&do=1) идет на wifi модуль с реле. Если планшет не тормозной задержки абсолютно не заметно. Обратно от модуля с реле возвращается ответ и отображается на состоянии кнопки (она подсвечивается). Никаких лишних запросов
блока питания
wifi модуля
и, собственно датчиков
Можно сделать кластер, scsi хранилище, только если играться очень серьезно.
Однако, эта технология позволяет создать нестандартные элементы управления.
Например — кубик размером с кружку. Положил на одну грань — включился свет, на другую — выключился. Повернул по часовой стрелке — ярче, обратно — тусклее. Внутри гироскоп (датчик наклона) и ESP01 с батарейкой.