Я не очень понял смысл вашего послания. Я разве где-то говорил, что API должен быть в HTML-виде, что должны быть ssh-ключи, или что-то подобное? Я вообще о реализации конкретики где-то что-то упоминал? Почему вы за меня это додумали и критикуете эту «выдуманную» часть?
Но если хотите, мы поговорим и об этом.
Есть фактически две разные задачи: контролировать нагрузку на БД и дать доступ извне к отслеживанию отправлений, включая доступ к «публичному или не очень» API.
И как раз более целесообразно в первую очередь контролировать нагрузку на БД. Для этого можно сделать общий API доступа к запросам инфы по посылкам _только_ по «партнерскому паролю». Я бы в это звено никаких XML не пускал бы — XML является human-readable стандартом, для межсерверного общения он отнюдь не снижает нагрузку — его же еще парсить надо. И ваши «я в своих проектах трачу… 41 секунду» очень похожи на московское «я сделал ремонт у себя в квартире», это когда данная фраза фактически в подавляющем большинстве случаев означает «я только заплатил», а не «я его реально сделал сам». То есть ваша фраза всего лишь одначает, что вы вписываете пару строчек, которые вызывают либо некий кусок чужого кода, либо вами же ранее написанного(тогда вы уже лукавите — не честную 41 секунду тратите), который и формирует на выходе XML.
В общем, для общения с БД я ввел бы binary-протокол, более быстрый и легкий для машинной обработки, чем любые ваши XML.
А уж далее ставится один или несколько серверов с доступом извне, которые и будут обслуживать непосредственно клиентов, будут им предоставлять уже более удобный API на базе XML или любой human-readable структуры, но которые по сути будут только тем и заниматься, что выполнять преобразования binary<->xml, первично проверяя легитимность доступа, отсекая явно спуффинговые запросы(с различного рода ошибками и несоответствиями) и являющиеся как раз теми буфферами, каждый из которых может «упасть» без особых последствий для всех остальных узлов системы. На них же можно возложить задачу кеширования инфы из БД, дабы один и тот же трек не спрашивать у БД чаще, чем раз в N минут. И к ним же можно прикрутить средства сбора статистики, чтоб мониторить и понимать, «чего сервисам не хватает».
Так вот. Если сделать эту систему, тогда можно начинать раздавать доступ к API в том виде, в котором это сделано сейчас — пусть по договору(пусть даже по формальному бесплатному), пусть с выдачей ключей/паролей каждому «партнеру» и т.п. В таком случае страничка отслеживания на сайте ПР(которая с капчей и о которой в данном топике речь идет изначально) может быть технически реализована, как еще один «партнер» — то есть выдать этой страничке свой ключ и пусть она запрашивает внутри себя тот же самый API на общих основаниях.
P.S. И никаких ssh, ssl и подобных систем аля «пара открытый/закрытый ключ». Все знают, на сколько тупит HTTPS протокол против нешифрованного HTTP. Нафиг это надо — такие лаги, и такая нагрузка на процессорные ядра в задаче, где та сверхнадежность, которую они предоставляют — нафиг не нужна.
P.P.S. qnub вам все правильно написал — если открыть публичный доступ к API, «жадность» массовых отслеживальщиков не будет знать предела, поэтому будут и по 3000 и по 5000 номеров запрашивать за раз. И эти «разы» будут частенько повторяться.
Поэтому как обычный юзер, я тоже думаю «вот сволочи, закрыли мне возможность сделать себе удобное отслеживание», но как системный программер, я их вполне поддерживаю в данном вопросе. А там посмотрим, доведут ли они эту систему до ума, или будем их еще песочить в дальнейшем.
Ну так, на вскидку…
Вряд ли у них сервера расчитаны на большую нагрузку и вряд ли они умеют с этим эффективно бороться. Если контролировать список и количество тех, кто имеет доступ к API(у каждого «легитимного» свой хеш/ключ для доступа к инфе), это какая-никакая защита от DoS атак: не выдавать каждому желающему на каждый запрос полную инфу, не напрягая лишний раз сервера БД. Кроме прочего, те, кто имеет доступ к API, могут кешировать информацию хотя бы малым временем жизни(несколько минут или час к примеру), тем самым тоже снижая нагрузку на сервера ПР от особо нетерпеливых пользователей, присевших на кнопку рефреша в браузере(даже если на рефреш присели на сайте партнера).
На мой взгляд в принципе — это решение. По крайней мере решение данной части проблем с Почтой России. Сервисов отслеживания сейчас уже предостаточно. Необходимость заморочек с договором отсечет несерьезных «отслеживальщиков». Да, это минус, если хочется «самому для себя» написать такой сервис, но если взвесить все плюсы и минусы… ))))
Да это я в курсе. И на сайте FLIR изучал линейки продукции. На тот момент по отдельности компоненты были, адаптированного набора не было. А так, я ж не постоянно эту тему мониторю. В свое время поискал чего имеется, на том и успокоился. А текущая тема на хабре опять интерес пробудила )
Спасибо. А то от журналюг ничего путнего ждать не приходится. Бред какой-то пронесут вечно, из которого ничего не понятно.
Правда 320x240 немного разочаровывают, но не суть. Цены на 800x600 микроболометры начинаются от 6 килобаксов и выше.
Еще года 3 назад где-то видел у американцев похожую разработку, контора делает устройства для полиции/SWAT, там девайс(ценник от 8 килобаксов) за 800 метров определяет живые организмы, попискивает и на экране прямоугольниками выделяет.
Гайцев с «феном» в кустах издалека хорошо детектирует )
P.P.S. кстати, BMW в свое время вроде анонсировала, что эту систему с термовизором будут продавать отдельно с возможностью установки на любые авто(не только BMW), цену комплекта заявляли около 4килобаксов. Правда позже я больше об этом ничего не слышал. Наверное передумали, либо это была утка.
Да, верно, вы правы. Признаю свою ошибку. Я видел в свое время совершенно другие скриншоты меринского дисплея, там не было некоторых отличительных признаков. Кроме того смутила перекраска картинки, как это обычно делают в термовизорах. Оттуда я выводы тогда и сделал.
На приведенном вами видео есть все признаки обычной камеры. Включая машину с мигающей аварийкой — на термовизоре видны только нагретые спирали лампочек в виде отдельных пикселей. то есть мигающую аварийку там разглядеть было бы очень(!) проблематично.
Вот еще пара скринов с ТопГировского видео, тут тоже на среднем кадре видна тень от неровности дороги. На термовизоре ее быть не должно в принципе.
Кроме прочего, судя по приведенному вами видео, используются пара ИК-прожекторов и две камеры. Перед одной из них стоит светофильтр, отсекающий только ИК-диапазон, а потом видимо идет постобработка и наложение двух сигналов с очисткой засветов и т.п.
P.S. это скорее всего именно обычная ч/б камера с хорошей чувствительностью. Ничего революционного в этом нет, нет смысла делать «уклон камеры в ИК-спектр». Достотачно отфильтровать лишнее. У нас все-равно прожектор лупит вперед, и камера снимает отраженный свет. Термовизору доп.подсветка была бы до лампочки.
А то, что обычные камеры видят ИК, вы можете и сами в этом убедиться. Известный способ проверки работоспособности пульта от телека — включаем на мобильнике камеру и смотрим через него на лампочку пульта, нажимая какую-либо кнопку. Даже простейшие камеры мобильников видят работу ИК-диода )
Вы не правы. По картинке даже в том же выпуске Top Gear люди, знающие принципы формирования изображения в тепловизорах и в обычных высокочувствительных камерах, однозначно отделят одно от другого. В меринах именно термовизоры.
По вашим аргументам по порядку:
1. Ночное видение на меринах работает только при включении фар.
Вы думаете, что сей факт обязательно означает техническую зависимость одного от другого? Вариант педантичности немцев и соблюдения безопасности «а чтоб всякие придурки не катались ночью без фар» вы не рассматриваете?
2. Джереми Кларксон возмущался по этому поводу
Кларксон умный чувак, но давайте не забывать, что он шоу-мен. Иными словами: далеко не каждое высказывание Кларксона произносится всерьез. Частенько он шутит «для эфира», но при этом его собственное мнение не обязательно совпадает с этой шуткой.
3. По факту в машинах либо используется инфракрасный спектр обычных фар, либо специальные фонари. Далее картинку снимает камера в режиме ночной съемки. Вот и весь секрет
Обычная камера в режиме ночной съемки(даже с обычной или ИК-подсветкой, о которой вы говорите) не подходит для вождения. максимум для видеорегистратора, но не для ассистента езды. И тому есть несколько препятствий, как то:
— обычную камеру слепят фары встречных машин.
— обычная камера не видит сквозь туман, дождь, запыленность и т.п.
— обычная камера показывает ч/б картинку обычного контраста.
Приведу пример. Когда-то я пытался разобраться в данном вопросе именно в целях ассистента ночной езды. Есть у меня ч/б камера с матрицей от Sony чувствительностью 0.0003 Lux(три десятитысячных люкса). При такой чувствительности ей хватает света звезд в необлачную погоду. Ночью на даче, где отсутствует вообще какое-либо фоновое освещение и на глаз ощущается кромешная темень, эта камера выдавала на монитор картинку «как днем». Мы прифигевали от такой чувствительности. Но! Если у вас есть просто обычная камера с ч/б режимом и небольшим мониторчиком, вы можете попытаться проехаться «по ней» даже днем — сами поймете, что это не подходит. Картинка нормальная, но в оттенках серого любые препятствия, пешеходы на обочине и т.п. видны весьма неконтрастно. Вы просто рискуете не среагировать на опасность вовремя. Тут при обычном цветном зрении в сумерках пешеходы и собаки сливаются с дорогой, а вы будете видеть то же самое на маленьком дисплейчике.
А вот термовизор дает очень контрастную картинку. Встречные фары не слепят(просто более светлые точки без «ореолов и „звездочек“»), задымленность, дождь, туман, снегопад и прочее практически не влияют на ее «зрение». Даже разметка видна отчетливо, ибо материал и его теплоемкость отличается от асфальта и обычно имеет другую температуру. А уж «живые организмы», сильно отличаясь температурой от окружающих объектов, так вообще очень хорошо выделяются.
Ну смысл я вам описал. А вот относительно нормальные термовизоры и стоят прилично, и из-за бугра просто так не закажешь — попадают под таможенные ограничения. Да и среди нормальных то, что можно купить в частном порядке в принципе — там разрешения от 320х240 до 800х600 максимум. Тоже можно придраться, что не под все задачи хватит.
Короче получается, что так или иначе данный девайс очень даже неплохо займет свою нишу. Хочется большего — не вопрос, но придется раскошеливаться. Как-то так.
Вы знаете, сколько стоят обычные тепловизоры?
А это за 175(195) USD в готовом виде и 145(160) USD за набор для самостоятельной сборки — это уже очень даже неплохо и подходит для многих нетребовательных задач. Например, на паяльной ИК-станции мониторинг зоны обогрева и обратная связь для контроля термопрофиля — этого девайса вполне достаточно. Пирометры, опять же, вполне неплохие получатся.
А вот если делать термовизор ночного видения для автомобиля, как в меринах S-класса, то тут конечно скорость и разрешение вообще никакое и для подобных задач совсем не подходит. Впрочем, смотря что там с чувствительностью и «дальнобойностью». Ночью на трассе детектировать пешеходов, зверье на обочинах и разогретые движки других автомобилей и хотя бы просто попискивать об этом водителю — тоже может пригодиться. Правда на счет «дальнобойности» данной сборки я что-то сомневаюсь…
Еще добавить бегущий курсорчик текущей позиции(вариант — закрашивание уже проигранного) и колобка с флажком, чтоб заранее показывал, с какого такта вступать )))
В английской википедии(правда в разных местах) довольно подробно расписано, что входит в A-GPS, и что может в него входить, но стандартом не является. Например триангуляция по сотовым вышкам(LBS) формально не является частью A-GPS, но чаще всего она уже прикреплена к нему и для девайса, поддерживающего A-GPS, встроена по-умолчанию.
Только читать надо английскую версию. В русской много воды и неточностей.
Смотря что за GPS и в какой ситуации. В обычном автономном случае львиная доля энергии уходит на перелопачивание принимаемых сырых данных и вычисление собственно координат. В A-GPS система пытается по возможности переложить вычисления на процессорные мощности ближайшей базовой станции(организует трансфер сырых данных на сотовую вышку и принимает оттуда готовые результаты вычислений). В таком случае энергия тратится в основном только на прием-передачу доп. пакетов.
>> это будет означать постоянно включенный блютуз на телефоне, а значит будет довольно быстро есть батарейку
А вы каким телефоном пользуетесь? Вроде как блютуз батарею садит только на старых телефонах, либо в постоянно активном режиме(музыку слушать). А так в современных телефонах(смарт) остались лишь две вещи, быстро сажающие батарею — WiFi и подсветка экрана(жрущие проц приложения и игры не учитываем).
Тогда и пищалка не нужна — легкого электростимулятора достаточно(легкий — это раздражение, а не болевой электрошокер).
Нажал кнопку, и слушай, за каким шкафом возня началась.
Да я всего-лишь занудно указал на формальную верность расстановки LValue и RValue в выражении «прямоугольник != квадрат». А в контексте о «квадрате Малевича» он, конечно же, не прав )
Ну если позанудствовать, то человек изначально написал выше правильно: «прямоугольник != квадрат». Возможно только знак "!=" слишком жесткий.
Формулируя более точно, «не каждый прямоугольник является квадратом, но каждый квадрат является прямоугольником».
Справедливости ради, парой комментов ниже он же написал уже неверно:
>> И это и есть, то самое отличие, которое не даст в суде доказать, что «квадрат = прямоугольник».
Да и кроме того, «квадрат Малевича» так или иначе попадает в определение прямоугольника )
Но если хотите, мы поговорим и об этом.
Есть фактически две разные задачи: контролировать нагрузку на БД и дать доступ извне к отслеживанию отправлений, включая доступ к «публичному или не очень» API.
И как раз более целесообразно в первую очередь контролировать нагрузку на БД. Для этого можно сделать общий API доступа к запросам инфы по посылкам _только_ по «партнерскому паролю». Я бы в это звено никаких XML не пускал бы — XML является human-readable стандартом, для межсерверного общения он отнюдь не снижает нагрузку — его же еще парсить надо. И ваши «я в своих проектах трачу… 41 секунду» очень похожи на московское «я сделал ремонт у себя в квартире», это когда данная фраза фактически в подавляющем большинстве случаев означает «я только заплатил», а не «я его реально сделал сам». То есть ваша фраза всего лишь одначает, что вы вписываете пару строчек, которые вызывают либо некий кусок чужого кода, либо вами же ранее написанного(тогда вы уже лукавите — не честную 41 секунду тратите), который и формирует на выходе XML.
В общем, для общения с БД я ввел бы binary-протокол, более быстрый и легкий для машинной обработки, чем любые ваши XML.
А уж далее ставится один или несколько серверов с доступом извне, которые и будут обслуживать непосредственно клиентов, будут им предоставлять уже более удобный API на базе XML или любой human-readable структуры, но которые по сути будут только тем и заниматься, что выполнять преобразования binary<->xml, первично проверяя легитимность доступа, отсекая явно спуффинговые запросы(с различного рода ошибками и несоответствиями) и являющиеся как раз теми буфферами, каждый из которых может «упасть» без особых последствий для всех остальных узлов системы. На них же можно возложить задачу кеширования инфы из БД, дабы один и тот же трек не спрашивать у БД чаще, чем раз в N минут. И к ним же можно прикрутить средства сбора статистики, чтоб мониторить и понимать, «чего сервисам не хватает».
Так вот. Если сделать эту систему, тогда можно начинать раздавать доступ к API в том виде, в котором это сделано сейчас — пусть по договору(пусть даже по формальному бесплатному), пусть с выдачей ключей/паролей каждому «партнеру» и т.п. В таком случае страничка отслеживания на сайте ПР(которая с капчей и о которой в данном топике речь идет изначально) может быть технически реализована, как еще один «партнер» — то есть выдать этой страничке свой ключ и пусть она запрашивает внутри себя тот же самый API на общих основаниях.
P.S. И никаких ssh, ssl и подобных систем аля «пара открытый/закрытый ключ». Все знают, на сколько тупит HTTPS протокол против нешифрованного HTTP. Нафиг это надо — такие лаги, и такая нагрузка на процессорные ядра в задаче, где та сверхнадежность, которую они предоставляют — нафиг не нужна.
P.P.S. qnub вам все правильно написал — если открыть публичный доступ к API, «жадность» массовых отслеживальщиков не будет знать предела, поэтому будут и по 3000 и по 5000 номеров запрашивать за раз. И эти «разы» будут частенько повторяться.
Поэтому как обычный юзер, я тоже думаю «вот сволочи, закрыли мне возможность сделать себе удобное отслеживание», но как системный программер, я их вполне поддерживаю в данном вопросе. А там посмотрим, доведут ли они эту систему до ума, или будем их еще песочить в дальнейшем.
Вряд ли у них сервера расчитаны на большую нагрузку и вряд ли они умеют с этим эффективно бороться. Если контролировать список и количество тех, кто имеет доступ к API(у каждого «легитимного» свой хеш/ключ для доступа к инфе), это какая-никакая защита от DoS атак: не выдавать каждому желающему на каждый запрос полную инфу, не напрягая лишний раз сервера БД. Кроме прочего, те, кто имеет доступ к API, могут кешировать информацию хотя бы малым временем жизни(несколько минут или час к примеру), тем самым тоже снижая нагрузку на сервера ПР от особо нетерпеливых пользователей, присевших на кнопку рефреша в браузере(даже если на рефреш присели на сайте партнера).
На мой взгляд в принципе — это решение. По крайней мере решение данной части проблем с Почтой России. Сервисов отслеживания сейчас уже предостаточно. Необходимость заморочек с договором отсечет несерьезных «отслеживальщиков». Да, это минус, если хочется «самому для себя» написать такой сервис, но если взвесить все плюсы и минусы… ))))
Правда 320x240 немного разочаровывают, но не суть. Цены на 800x600 микроболометры начинаются от 6 килобаксов и выше.
Еще года 3 назад где-то видел у американцев похожую разработку, контора делает устройства для полиции/SWAT, там девайс(ценник от 8 килобаксов) за 800 метров определяет живые организмы, попискивает и на экране прямоугольниками выделяет.
Гайцев с «феном» в кустах издалека хорошо детектирует )
На приведенном вами видео есть все признаки обычной камеры. Включая машину с мигающей аварийкой — на термовизоре видны только нагретые спирали лампочек в виде отдельных пикселей. то есть мигающую аварийку там разглядеть было бы очень(!) проблематично.
Вот еще пара скринов с ТопГировского видео, тут тоже на среднем кадре видна тень от неровности дороги. На термовизоре ее быть не должно в принципе.
Кроме прочего, судя по приведенному вами видео, используются пара ИК-прожекторов и две камеры. Перед одной из них стоит светофильтр, отсекающий только ИК-диапазон, а потом видимо идет постобработка и наложение двух сигналов с очисткой засветов и т.п.
P.S. это скорее всего именно обычная ч/б камера с хорошей чувствительностью. Ничего революционного в этом нет, нет смысла делать «уклон камеры в ИК-спектр». Достотачно отфильтровать лишнее. У нас все-равно прожектор лупит вперед, и камера снимает отраженный свет. Термовизору доп.подсветка была бы до лампочки.
А то, что обычные камеры видят ИК, вы можете и сами в этом убедиться. Известный способ проверки работоспособности пульта от телека — включаем на мобильнике камеру и смотрим через него на лампочку пульта, нажимая какую-либо кнопку. Даже простейшие камеры мобильников видят работу ИК-диода )
По вашим аргументам по порядку:
1. Ночное видение на меринах работает только при включении фар.
Вы думаете, что сей факт обязательно означает техническую зависимость одного от другого? Вариант педантичности немцев и соблюдения безопасности «а чтоб всякие придурки не катались ночью без фар» вы не рассматриваете?
2. Джереми Кларксон возмущался по этому поводу
Кларксон умный чувак, но давайте не забывать, что он шоу-мен. Иными словами: далеко не каждое высказывание Кларксона произносится всерьез. Частенько он шутит «для эфира», но при этом его собственное мнение не обязательно совпадает с этой шуткой.
3. По факту в машинах либо используется инфракрасный спектр обычных фар, либо специальные фонари. Далее картинку снимает камера в режиме ночной съемки. Вот и весь секрет
Обычная камера в режиме ночной съемки(даже с обычной или ИК-подсветкой, о которой вы говорите) не подходит для вождения. максимум для видеорегистратора, но не для ассистента езды. И тому есть несколько препятствий, как то:
— обычную камеру слепят фары встречных машин.
— обычная камера не видит сквозь туман, дождь, запыленность и т.п.
— обычная камера показывает ч/б картинку обычного контраста.
Приведу пример. Когда-то я пытался разобраться в данном вопросе именно в целях ассистента ночной езды. Есть у меня ч/б камера с матрицей от Sony чувствительностью 0.0003 Lux(три десятитысячных люкса). При такой чувствительности ей хватает света звезд в необлачную погоду. Ночью на даче, где отсутствует вообще какое-либо фоновое освещение и на глаз ощущается кромешная темень, эта камера выдавала на монитор картинку «как днем». Мы прифигевали от такой чувствительности. Но! Если у вас есть просто обычная камера с ч/б режимом и небольшим мониторчиком, вы можете попытаться проехаться «по ней» даже днем — сами поймете, что это не подходит. Картинка нормальная, но в оттенках серого любые препятствия, пешеходы на обочине и т.п. видны весьма неконтрастно. Вы просто рискуете не среагировать на опасность вовремя. Тут при обычном цветном зрении в сумерках пешеходы и собаки сливаются с дорогой, а вы будете видеть то же самое на маленьком дисплейчике.
А вот термовизор дает очень контрастную картинку. Встречные фары не слепят(просто более светлые точки без «ореолов и „звездочек“»), задымленность, дождь, туман, снегопад и прочее практически не влияют на ее «зрение». Даже разметка видна отчетливо, ибо материал и его теплоемкость отличается от асфальта и обычно имеет другую температуру. А уж «живые организмы», сильно отличаясь температурой от окружающих объектов, так вообще очень хорошо выделяются.
Короче получается, что так или иначе данный девайс очень даже неплохо займет свою нишу. Хочется большего — не вопрос, но придется раскошеливаться. Как-то так.
А это за 175(195) USD в готовом виде и 145(160) USD за набор для самостоятельной сборки — это уже очень даже неплохо и подходит для многих нетребовательных задач. Например, на паяльной ИК-станции мониторинг зоны обогрева и обратная связь для контроля термопрофиля — этого девайса вполне достаточно. Пирометры, опять же, вполне неплохие получатся.
А вот если делать термовизор ночного видения для автомобиля, как в меринах S-класса, то тут конечно скорость и разрешение вообще никакое и для подобных задач совсем не подходит. Впрочем, смотря что там с чувствительностью и «дальнобойностью». Ночью на трассе детектировать пешеходов, зверье на обочинах и разогретые движки других автомобилей и хотя бы просто попискивать об этом водителю — тоже может пригодиться. Правда на счет «дальнобойности» данной сборки я что-то сомневаюсь…
Только читать надо английскую версию. В русской много воды и неточностей.
А вы каким телефоном пользуетесь? Вроде как блютуз батарею садит только на старых телефонах, либо в постоянно активном режиме(музыку слушать). А так в современных телефонах(смарт) остались лишь две вещи, быстро сажающие батарею — WiFi и подсветка экрана(жрущие проц приложения и игры не учитываем).
Нажал кнопку, и слушай, за каким шкафом возня началась.
P.S. «Устами зануды гундосит истина» (с) ))))
Формулируя более точно, «не каждый прямоугольник является квадратом, но каждый квадрат является прямоугольником».
Справедливости ради, парой комментов ниже он же написал уже неверно:
>> И это и есть, то самое отличие, которое не даст в суде доказать, что «квадрат = прямоугольник».
Да и кроме того, «квадрат Малевича» так или иначе попадает в определение прямоугольника )