Безусловно, ваш вариант является более корректным. Я тут почему-то не посчитал нужным ограничить область видимости классом (почему-то держал в голове, что класс у нас может быть только один, что может быть некорректно в более-менее большом проекте).
В разных мануалах обычно подчёркивается что «экспортированная модель представляет собой простой массив» (и даже в этом примере, в статье) — поэтому, я так полагаю, этот массив в виде кода C, — является набором поправочных коэффициентов для предсказания результатов, при получении входных данных (с микрофона, камеры и откуда либо ещё) — но, могу ошибаться.
По поводу размера кадра: так как везде в дальнейшем идёт речь только о работе с уменьшенной версией кадра — видимо это ошибка автора этого конкретного решения (уменьшил кадр и добился приемлемой производительности, а в коде поправить забыл).
Каких-то специальных замеров скорости не проводил, но этот код отлично работает для тех целей, которые обозначены: открытие и закрытие робозахвата. Всё работает чётко и без тормозов.
Всё верно! Просто в этой статье был сделан упор не на идею «сделать всё правильно и оптимально», а скорее рассмотрено с точки зрения «а ещё вот так можно» 😊. Кроме того, использование микроконтроллера даёт возможность реализовать всякие плюшки вроде некой логики. Например, зашел человек в комнату — сработал инфракрасный датчик движения — включился лазер и передал на удаленное устройство код, который означает приказ на включение записи. И начинаем удаленно слушать и записывать. К тому же — оптический канал не глушится радиоглушилками, а лазер может быть невидимым (инфракрасным) И т.д. и т.п. Много интересного можно наворотить…
Тут я сказал, что этот вариант сделан для того, что если уж очень нужно запихнуть всё в один большой блок, то можно сделать так.
Например, у меня в проде это дело стоит на всех обработчиках handler для возврата JSON, где этот JSON возвращается клиенту. Но «клиент» это air-gapped API.
При этом можно просто взять и всё обернуть в WriteError. В данном случае я воспользовался таким подходом. Но это не обязательно. Когда ошибки выводятся стороннему пользователю их нужно ловить поштучно, и обрабатывать поштучно.
Банальная бытовая автоматизация. И это без учёта того, что в индизайне тоже можно писать скрипты автозамены и автоматизировать вёрстку.
Верно, именно в этом и была цель статьи, — показать, как может быть применено программирование для сферы, вообще далекой от этого. То есть, рассказать на своём примере, как даже обычные простые (казалось бы) вещи могут оказаться вполне себе сложными, если их решать иначе. И наоборот – как программное обеспечение может существенно облегчить жизнь, даже если его применять «точечно и совсем не в этой сфере» :-)
P.S. насколько мне известно (могу и ошибаться) – скрипты для индизайна пишутся на javascript – а я с ним не очень хорошо дружу. Ну так уж вышло :-)
Согласен, совершенство не знает границ — любую задачу можно решить многими способами ;-) Но сами скрипты вполне себе сработали в той ситуации, когда необходимо было срочно оптимизировать работу в этой области и выполнили свою роль. Соответственно, оптимизировать их конечно можно и нужно, но по большому счету, только из-за «любви к искусству».
Именно так и было сделано. Просто тут вопрос в том, что перетекание (когда оно есть) — оно автоматом решает вопрос правых и левых страниц. Правда перетекание обычно приводит к не прогнозируемым ошибкам и потребности правок «ниже этого места». Что в условиях катастрофической нехватки времени – весьма критично. А когда выключено – приходится потом применять шаблон к диапазону страниц, что и было показано ;-).
Знаковые целые использовались для совместимости с другими реализациями UUID. А так, вы правы, в го с ними то же, что и в си. Да и во всех других нормальных языках.
По поводу запроса данных с сервера, — да вполне можно и так сделать, ваш подход здравый.
Почему был сделан «учет в железке»: основная мысль заключалась только в том, чтобы устранить критическую зависимость от качества сети, для осуществления операции выдачи. То есть внешняя база в офисе, в данной схеме служит только «представительским» целям, чтобы торговый представитель примерно понимал (особая точность даже не требуется), сколько товара (+-) нужно завезти в эту точку и когда. Потому что лично приходилось сталкиваться с разного рода «глушилками» связи при встречах важных людей и прочими неожиданными ситуациями.
Смотрите: здесь под проектированием понимается очерчивание общих рамок системы. В другом случае, это была бы история про «детальный разбор существующей или полностью спроектированной системы». Так как каждая конкретная реализация будет иметь свои нюансы, и соответственно разную архитектуру (в целом или в частностях). В данном случае, система достаточно простая и вполне может выполнять, при соответствующих доработках, озвученную функцию: учет количества определенного товара в ячейке/ячейках и оперативное информирование центрального офиса.
Собственно именно для этого и предназначен счетчик. По поводу срабатывания ПОСЛЕ события: так как «событием» в самом простом случае (когда рядом с ячейкой нет никаких мониторов, извещающих о количестве в ячейке) является физическое открытие ячейки – поэтому срабатывания счетчика происходит после события.
Если необходимо срабатывание ДО – нужно усложнять схему выводом предварительного отображения количества рядом с ячейкой.
Так как количество товаров в ячейке не может быть равным «-1». Поэтому и условие уменьшения товара работает только в случае, если минимальное число товаров равно 1. (1-1=0. «Ячейка пуста»).
«Товар клиенту отдали, а уменьшение количества товара регистрировать отказались?»
Регистрация происходит в строке 24, когда срабатывает функция ToDataBaseLoader (), отправляющая состояние глобальной переменной (GoodsCounter) – в базу данных, с помощью метода POST.
По поводу размера кадра: так как везде в дальнейшем идёт речь только о работе с уменьшенной версией кадра — видимо это ошибка автора этого конкретного решения (уменьшил кадр и добился приемлемой производительности, а в коде поправить забыл).
Например, у меня в проде это дело стоит на всех обработчиках handler для возврата JSON, где этот JSON возвращается клиенту. Но «клиент» это air-gapped API.
При этом можно просто взять и всё обернуть в WriteError. В данном случае я воспользовался таким подходом. Но это не обязательно. Когда ошибки выводятся стороннему пользователю их нужно ловить поштучно, и обрабатывать поштучно.
P.S. насколько мне известно (могу и ошибаться) – скрипты для индизайна пишутся на javascript – а я с ним не очень хорошо дружу. Ну так уж вышло :-)
Почему был сделан «учет в железке»: основная мысль заключалась только в том, чтобы устранить критическую зависимость от качества сети, для осуществления операции выдачи. То есть внешняя база в офисе, в данной схеме служит только «представительским» целям, чтобы торговый представитель примерно понимал (особая точность даже не требуется), сколько товара (+-) нужно завезти в эту точку и когда. Потому что лично приходилось сталкиваться с разного рода «глушилками» связи при встречах важных людей и прочими неожиданными ситуациями.
Собственно именно для этого и предназначен счетчик. По поводу срабатывания ПОСЛЕ события: так как «событием» в самом простом случае (когда рядом с ячейкой нет никаких мониторов, извещающих о количестве в ячейке) является физическое открытие ячейки – поэтому срабатывания счетчика происходит после события.
Если необходимо срабатывание ДО – нужно усложнять схему выводом предварительного отображения количества рядом с ячейкой.
Так как количество товаров в ячейке не может быть равным «-1». Поэтому и условие уменьшения товара работает только в случае, если минимальное число товаров равно 1. (1-1=0. «Ячейка пуста»).
Регистрация происходит в строке 24, когда срабатывает функция ToDataBaseLoader (), отправляющая состояние глобальной переменной (GoodsCounter) – в базу данных, с помощью метода POST.