чувствительность в сумраке мне кажется сразу ограничивает тебя в выборе, лучше минимальный светильник там поставь (камеры с ночным режимом фактически со светильником и поставляются, просто в инфракрасном свете)
Я тут подумал, одно время это было решением, - покупаешь смартфон (из дешевых у сяоми хорошие камеры есть), выбираешь на али объектив нашлепку на смартфон (там есть как рыбий глаз так и узкий угол зрения) и получишь сразу и камеру, и проц, и компактность, и временную автономность (можно даже ветряк запилить, я серьезно, для смартфона это будет ветряк вида флюгер как украшение, но готовые решения я боюсь найти будет сложно или дорого, дешевле и разумнее сколхозить)
еще намек - распознование образов в реальном времени не тянут даже стационарные компы с дорогой видеокартой с киловат/час энергопотребления
Цифровая карта!
Свежая точная качественная оффлайн! и бесплатно!
Мир совсем сошел с ума ;) попробуй подумать, сколько стоит создание цифровой карты с объектами (это уже на порядок сложность повышает) да еще и оперативно обновляющаяся
реально openstreetmap отличный проект, попробуй допили его для своего города/района, вроде бы разрешение на ручное обведение карт яндекса гугла было получено.
p.s. дубльгис не катит совсем?
или тебе нужно в свое приложение? пили автоктикер и выгружай данные от туда, оффлайн, и да это будет считаться кражей
peacemakerv, x86 железо бери, просто одноплатник адекватный не получится, с m-itx получился бы, но в прайсах одни j1800, да ничего не скажу отличные железки были ... 17-го года, и даже они по любому быстрее будет малинки, в разы, а уж удобство и подавно!
просто намекаю, что arm процы хороши только если разрабатывать именно под них (си/с++/..), а это значит с питоном тебе будет там грустно! хотя, есть же cpython/pypy, может помогут
и не советую пока тратиться на jet nano, да железки от nvidia но судя по статьям про них, адекватно использовать их видеокарту не получится (или просто документации мало)
ключевые слова для гугла: nginx cookies based auth или nginx auth basic (устаревший, не очень удобный на клиентской стороне но вполне работающий способ)
p.s. есть вполне рабочий способ, не требующий заметных правок nginx и при этом оставляющий статику статикой - это создание симлинков на рабочий каталог файлов сайта, имя симлинка = уникальный идентификатор доступа, выдаваемый после авторизации (собственно на сервере авотризованному пользователю создается этот симлинк, а значит по ссылке с ним пользователь получит данные иначе 404, удаление симлинка - отзыв авторизации), недостаток - не работает кеширование файлов на стороне клиента
Muvka, почему спрашиваешь то? идешь и пробуешь
сам подумай, как приложение определяет что поддержка закончилась, если exe обычно предполагают еще и оффлайн работу?
upd. осторожно, на компьютере должна быть установлена старая версия флеш плеера, а не та что приезжает когда поддержка заканчивается
нет никакой разницы, я описал общее положение при использовании кеша, где он и какого уровня - вопрос алгоритма инвалидации, выбора, сохранять ли данные в кеше или пропустить из мимо.
бред какой, в какие шины данных ты хочешь залезть?
Как я сказал, если тебе нужна цифровая логика, то бери lpt, он самый простой, есть в трети материнок (бывает просто разъемом на материнке но не сзади), а так, все делают общение с компьютером на основе usb, и используют драйвер для общения программы с устройством.
Нужен специальный тестовый сервер и окружение (например локальный dns, подменяющий адрес рабочего сервера или отдельные конфиги самого приложения, направляющие его на тестовый сервер) который должен уметь устанавливать свое состояние по команде юнит тестов.
Наполнение тестовой базы данных, отдельный не простой разговор. Синтетические данные хороши, быстры (их можно сделать мало), но могут не учесть всей специфики пользовательской задачи и тесты проходящие на ней могут не пройти на боевой базе. Но бывает что доступ к самим продакшен данным тестерам давать нельзя по юридическим причинам (приватные данные), и вот тогда придется поизвращаться (замазывание/подмена всего что критично).
В простом варианте - скрипты поднимают в докере сервер и базу данных из указанного бакапа а по окончании тестов этот сервер удаляют. Юнит тесты же должны как минимум быть с пометкой, какая версия базы данных им нужна. Само собой, существуют ситуации, часто, когда тесты требуют последовательно взаимо связаные состояния сервера (т.е. например один тест создает объект, второй его редактирует, третий удаляет, логично что они должны выполняться последовательно либо каждый раз должны откатывать на заранее подготовленную базу данных, что медленнее но надежнее).
Состояние сервера можно хранить снапшотами виртуальной машины (их поддерживают практически все известные), это значительно быстрее но очень требовательно к месту на диске.
p.s. я не участвовал в крупном проекте где требовалось бы так тестировать, а там где требовалось, стратегия запуска тестов требовала только одно стартовое состояние базы данных сервера, а затем куча тестов выполнялось последовательно в непротиворечивом порядке, но если тестов много а нужно заниматься отладкой какого то конкретного, то вышеописанный вариант со снапшотами очень и очень поможет
нажми два раза левой кнопкой мыши на неизвестном тебе слове или выдели как умеешь, затем на выделении правую кнопку мыши, в меню браузера выбери search google for или какой у тебя там поисковик
благодаря гуглу, твой запрос будет понят максимально верно, и будет выдан в первых же результатах ссылка на страницах википедии, где огромное количество людей создали максимально объемный и подробный справочник, аналогов которому в мире нет
в общем случае, без относительно языков фреймворков и т.п. есть два кардинально разных подхода:
* стратегия тонкий клиент, каждый раз, когда тебе нужны данные, делай запрос в базу данных/сервер
* стратегия толстый клиент, клиент хранит все что возможно у себя (вплоть до дублирования функционала сервера), кешируя и отслеживая инвалидацию данных и прочее, красивый вырожденный пример - имея полное состояние базы на каждом клиенте, серверу достаточно пересылать любые события, меняющие эти состояния от клиентов напрямую клиентам (в т.ч. минуя сам сервер, используя p2p), а клиенты синхронно обновляют свое состояние, синхронизируя его друг с другом, используя минимум сетевого взаимодействия (примерно этим подходом пользуются онлайн игры, само собой клиенты хранят только нужный им на текущий момент слепок данных)
По твоим вопросам, да так и делай, это ведь не проблема. redis очень быстрая nosql база данных.
Еще момент, если у тебя websocket сервер, значит веб приложение скорее всего реализовано не http rest принципам а в виде не выгружаемого приложения, а значит многие данные можно не запрашивать постоянно из базы, а хранить в оперативной памяти в глобальных массивах
Между этими двумя подходами нет четкой границы, к примеру можно реализовать тонкий клиент с кешированием данных, для которых контроль инвалидации не критичен или не сильно требует ресурсы или ошибки ожидаемы, весь веб на этом построен.
Абра Кадабра, эээ, если платформа позволяет - то можно закинуть, но не получится так сэкономить на газе, ведь газ это не абстракция, а конкретные затраты (считай количество операций) необходимые для исполнения транзакций, объединив несколько в одну, затраты не изменятся.
Я тут подумал, одно время это было решением, - покупаешь смартфон (из дешевых у сяоми хорошие камеры есть), выбираешь на али объектив нашлепку на смартфон (там есть как рыбий глаз так и узкий угол зрения) и получишь сразу и камеру, и проц, и компактность, и временную автономность (можно даже ветряк запилить, я серьезно, для смартфона это будет ветряк вида флюгер как украшение, но готовые решения я боюсь найти будет сложно или дорого, дешевле и разумнее сколхозить)
еще намек - распознование образов в реальном времени не тянут даже стационарные компы с дорогой видеокартой с киловат/час энергопотребления