Помню как-то раз к нам пришли с ТЗ типа: "Хотим следить за сотрудником, что он на рабочем месте, но так, чтоб не устанавливать ничего на телефон, чтоб без камер и аудиторов. А к WiFi объекта мы доступ не дадим. Но точность должна быть - 100%, ошибок быть не должно."
Стоит ли говорить, что ничего разумного придумать не удалось на этих вводных :)
Спасибо за комментарий. Как раз на подходе вторая статья на эту тему, как раз с разбором документации ЦБ (доступной) и анализом того, что там написано в соотношении с тем, как это заявляется на уровне СМИ.
Ожидаемый релиз статьи - середина октября, если время позволит. В этой статье появится ссылка на вторую статью
Спасибо за статью, прочитал с удовольствием! Однако попробую кое-что дополнить в меру возможностей.
В ООП-разработке есть такое понятие "божественный класс". Класс, который делает все и сразу. В вашем описании БА выглядит, почему-то, как "божественный класс". Обычно это происходит несколько иначе.
Делить СА и БА не имеет смысла, так как в крупной системе эти элементы будут плотно переплетены. Ну либо вы раздуете штат в 2 раза и увеличите плечо согласований. С учетом, что IT сотрудник - это дорого, то "дуть штат" заказчики не любят.
Например: Заказчику требуется какая-то бизнес фича, ее потребуется перевести с языка заказчика на язык разработчика.
Но прежде чем ее переводить - нужно оценить ее исполнимость, иначе есть риск того, что БА подпишется под неисполнимое в рамках бюджета задание. Эта ошибка, кстати, встречается часто.
Более того, у каждого задания есть несколько вариантов исполнения, а значит требуется определить граничные условия. Вот и получается, что БА должен быть немного разработчик, чтоб понимать, как это можно сделать " в теории", чтоб задать правильные вопросы. Как это будет "на практике" - финально решит разработчик или тим лид исходя, как раз, из граничных условий.
Если же БА попробует сам спрогнозировать финальное решение на уровне кода и далее будет требовать исполнения "именно так", то скорее всего это приведет к низкому качеству кода и сложности его поддержки. Разработчик в 99,9% случаев напишет более оптимальное решение и выберет паттерн, который лучше соответствует задаче.
Далее потребуется зафиксировать User Flow. И тут БА аналогично потребуется лишь на входе, так как далее задачу возьмет себе Тестировщик и Дизайнер. Задача БА на этом этапе отрисовать каркас переходов и не более. Как их лучше расположить и какие цвета выбрать - скажет дизайнер. Как сделать так, чтоб никто не нажал лишнего - тестировщик.
Следом потребуется хоть как-то оценить вопрос железа. Где будет развернуто ПО и как именно, какие есть условия по безопасности и т.п. И опять же БА нужно задать правильные вопросы. Однако задачей будет заниматься DevSecOps и это правильно.
Вот и получается, что БА подключается только в самом начале, на этапе "согласования и запуска", а далее вопроса более не касается. А если касается - значит плохо расписана спецификация и требуется уточнение.
Потому и знать БА приходится очень и очень много, но без глубины. БА выступает в роли справочника, который сможет направить заказчика в нужное русло.
Как итог БА потребуются: 1) Хотя бы общие принципы передачи информации по сети (модель OSI). 2) Хотя бы базовое понимание разработки и принцип работы с фреймворками. 3) Хотя бы базовое понимание верстки сайтов (HTML+CSS+JS). 4) Хотя бы базовое понимание разных видов API (REST обязательно). 5) Хотя бы базовое понимание того, как ПО деплоится на сервер. 6) Хотя бы базовое понимание того, какая будет скорость ответов при том или ином решении (обязательно понимать разницу между ответами 200,300,400,500), а самое главное почему ответ пользователям Москвы придет быстрее, чем пользователям Владивостока. 7) Хотя бы базовое понимание работы с БД. Многие заказчики считают Excel базой данных и будут не понимать, почему нельзя использовать формулу из excel. 8) Иметь громадный уровень переговорных навыков, потому что потребуется много общаться со всеми подряд ради общей цели :)
А вот бегать и следить за правильностью исполнения - это уже к тех лиду, тим лиду, РМ-у и т.п. У кого как принято, так сказать. Но точно не к БА.
"Попробую расписать процесс, как его вижу я со своей колокольни. Прошу сразу камнями не закидывать, так сказать мнение автора может не совпасть с вашим. И надеюсь, что мое видение будет вам полезно в работе.
По правильному, аналитик перед разработкой создает спецификацию того, что требуется создать. Он создает это не просто так, а для того, чтоб разработчик мог "не думать" и делать то, что написано. Сказано 4 ножки у табурета и высота в 2 бутылки 0.5 Кока-колы - делаем 4 ножки и высота в 2 бутылки. Не сошлось - вопрос к спецификации.
Причем делает он ее не абы как, а подробно, детально прописывая все, что потребуется знать разработчику и РМ."
"Следом идет роль РМ, который по сути должен получить подтверждение от Заказчика, что это действительно тот стул, который имел ввиду заказчик. "От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?" - должен спрашивать РМ у заказчика. Мнения разошлись - спецификация уходит обратно к аналитику. Мнения сошлись - информация идет на уровень ниже."
"Далее начинается уровень Разработчика."
"После этого действительно наступает уровень Тестировщика."
Надеюсь, что комментарий был для вас полезен и поможет дополнить, при необходимости, статью :)
Первый же пункт статьи опровергает утверждение "доступная сумма кошелька хранится именно в памяти карты".
Опять же, не очень безопасно хранить сумму на самой карте. Думаю реестр, все же, находится в банке. Иначе я ломаю карту и вот могу снять вместо 100 рублей 100 000 рублей.
Как итог "смарт карта" и "банковский пластик" - это все же одно и тоже, т.е. относится к разделу "безнал", который не работает оффлайн.
Если я вас правильно понял: 1) "безнал" - всегда есть данные у банка о состоянии счета и потеря карты не проблема, их откатывают из данных банка. 2) "крипта" - всегда есть данные о состоянии счета, но потеря кошелька/пина - проблема. 3) "смарт карта" - данных о состоянии счета нет и потеря кошелька - проблема. Однако, вряд ли информация о балансе хранится в самой карте. В этом случае крайне высок риск подделки данных и как итог незаконного обогащения.
Предполагаю, что вы заблуждаетесь, так как смарт карта, исходя из описания в интернете - это микрочип + пластик. Т.е. по своей сути - это банковская карта, т.е. "безнал" с центральным реестром в банке. А значит оффлайн она не работает, как минимум терминал должен отсылать транзакционные данные и получать соответствующий ответ.
Спасибо за комментарий. Статья называется "Мнение" и призывает к обсуждению вопроса.
Насколько знаю, даже такого уровня материалов сейчас в сети не очень много. Если ваша экспертиза по этому вопросу выше - вы можете внести свой вклад в этот материал.
После проверки - обязательно добавлю с указанием вас, как источника :)
Т.е. по сути смарт карта - это карта Тройка из Метрополитена, верно уловил вашу мысль?
Мне не кажется, что это очень безопасный метод хранения финансовых средств и практика не распространилась как раз по этой причине. Т.е. ниша "оффлайн инструмент для банковских операций" так и осталась открытой
1) Ссылки на часть источников в статье присутствуют. 2) За ваши ссылки - благодарю, после изучения добавлю их апдейтом в текст статьи с указанием вас, как источника ссылок. Если вы не против, конечно. И если они смогут дополнить статью чем-то, конечно.
Спасибо за комментарий. Усиление контроля - не всегда плохо. Зависит от того, кого собираются контролировать и с какой целью.
Ваша мысль касательно смарт-карт показалась мне интересной. Если механизм существовал, то почему он сейчас не применяется в отдаленных уголках РФ? Сможете более подробно обосновать свою позицию, если вам тема знакома?
Ваше предположение находит подтверждение еще в одном наборе данных. 1) Китай не легализует статус "крипты", как официального средства платежа. 2) В 2023 году в Индии блокировали работу криптобирж, а в 2024, насколько понимаю, начали облагать налогом, при этом не дав статус легальной валюты. 3) Схожий механизм налогообложения от продажи "крипты" работает сейчас в РФ.
Сложность в том, что это могут быть случайные корреляции на схожие экономические вызовы в разных странах. Как схожим образом у всех птиц кости стали легче в ответ на попытку полетов.
Спасибо за комментарий, попробую ответить на базе той информации, которая у меня есть.
Основным средством хранения выступают распределенные реестры ЦБ, при этом в роли UI выступает телефон. Точных сведений о том, сколько будет реестров и как они между собой связаны - найти не удалось.
Сведения о том, что в роли "хранилища" может выступать телефон присутствуют, однако, предполагаю, что эта возможность "резервная", как раз для случаев оффлайн-покупок.
Касательно безопасности такого подхода - соглашусь, что есть риски. Однако, схожий механизм используется сейчас банковскими приложениями и приложениями госуслуг, где в роли UI выступает смартфон, который обращается к "реестру", но не распределенному.
Это может означать, что такой подход более-менее эффективен, проверен и защищен. Хотя, справедливости ради, в минусы при публикации был добавлен пункт "Повышенный спрос на вредоносы с бэкдором на смартфон." То есть риск безопасности смартфонов мне тоже показался весомым.
Добрый день. Одобрил ваш комментарий, предположив, что вы сможете перейти на язык конструктивной критики.
Статья полностью написана человеком без участия AI. Да, на базе информации из СМИ - об этом написано в самом начале.
Если вы считаете, что статья вводит в заблуждение, то прошу указать конкретные пункты, которые расходятся с официальной информацией СМИ. Если же вы владеете техническими деталями реализации проекта - можете ими поделиться с сообществом, мы будем благодарны.
Спасибо за вопрос. Если исходить из того, что стейблкоин - это "крипта" с присущими ей плюсами и минусами, то "цифра" - это нечто совсем другое. Как минимум из-за возможности офлайн оплат и подготовки инфраструктуры ритейла РФ к использованию "цифры".
Хотя согласен, что прослеживается интересная параллель между связкой "цифра"-Рубль и "стейбл"-Доллар.
К сожалению пока не было информации о том, что валюты будут взаимно интегрироваться с какими-то еще. У меня было такое предположение, но не имея конкретной доказательной базы обозначать это как "действующий" пункт не стал.
Если предположить, что "цифра" будет ликвидна не только в рамках РФ, но и в других странах, то вы правы. Однако пока об этом говорить рано хотя бы в силу того, что позиционируется она как как внутренний инструмент для граждан РФ, а не как средство межгосударственного обмена.
Спасибо за комментарий. Соглашусь, что с уверенностью сказать не сможет никто. Об этом же пишу и я в начале статьи, приглашая пользователей к обсуждению вопроса.
Тем не менее, если исходить из информации СМИ об этой технологии, то банки не пострадают вообще. Основная прибыль банков идет из кредитов, которые выдаются из финансового массива вкладов. А поскольку "цифра" не приносит прибыли в виде процентов, то вклады как были в банках, так и останутся. Это означает, что кредиты, как выдавались банками, так и будут.
Таким образом получается, что банки пострадают лишь с точки зрения эквайринга, который и без того выдавливается с рынка системой СБП.
Согласен полностью, в частности в рамках статьи мной было высказано предположение о том, что "окраска" будет производится на базе "Кода ТН ВЭД". Более точной информации, к сожалению, у меня нет.
Если вы сможете дополнить какие-то части статьи дополнительными элементами, то после проверки источников информации - обязательно включу данные в статью и укажу в апдейте вас, как автора апдейта
Благодарю за комментарий, однако мне бы хотелось избежать политической плоскости данного вопроса. Обсуждается именно техническая часть и особенности работы системы как таковой.
Думаю, что по итогу разобрались с вопросом. :) Вы действительно правы, что стекло не блокирует ИК-спектр полностью.
Цитирую мой ответ пользователю REPISOT:
Благодарю за картинку, она навела меня на мысль поискать подробную информацию у тех, кто на этом специализируется. На всякий случай напомню, что в статье описывается не ИК-излучение, а работа блютуз-маяков, т.е. ИК-спектр находится не совсем в моем рабочем пространстве :)
В частности для моего ответа ниже будет использован материал "Светопропускание оконных конструкций и различные способы достижения нормативных результатов к.т.н. А.Г. Чесноков (АО "ГИС", Москва)"
Если исходить из него, то есть несколько интересных выводов: 1) Стекло действительно пропускает диапазон от 500 до 2500 нм, т.е. утверждать, что ИК-спектр НЕ проходит через стекло - неверно. Соответвенно, здесь вы правы полностью, а я заблуждался. Даже обычное стекло может пропускать ИК-спектр. 2) Стекло пропускает определенный % от ИК-спектра. Если мы рассматриваем его как 700-2500нм, то это +/- 50%, исходя из графика. Таким образом получается, что общий принцип работы объяснен мной верно. Наблюдается эффект термоса, когда входящее излучение блокируется внутри, правда в счет "частичного отражения", а не "полного отражения".
Помню как-то раз к нам пришли с ТЗ типа:
"Хотим следить за сотрудником, что он на рабочем месте, но так, чтоб не устанавливать ничего на телефон, чтоб без камер и аудиторов.
А к WiFi объекта мы доступ не дадим.
Но точность должна быть - 100%, ошибок быть не должно."
Стоит ли говорить, что ничего разумного придумать не удалось на этих вводных :)
Спасибо за комментарий.
Как раз на подходе вторая статья на эту тему, как раз с разбором документации ЦБ (доступной) и анализом того, что там написано в соотношении с тем, как это заявляется на уровне СМИ.
Ожидаемый релиз статьи - середина октября, если время позволит.
В этой статье появится ссылка на вторую статью
Спасибо за статью, прочитал с удовольствием!
Однако попробую кое-что дополнить в меру возможностей.
В ООП-разработке есть такое понятие "божественный класс".
Класс, который делает все и сразу.
В вашем описании БА выглядит, почему-то, как "божественный класс".
Обычно это происходит несколько иначе.
Делить СА и БА не имеет смысла, так как в крупной системе эти элементы будут плотно переплетены.
Ну либо вы раздуете штат в 2 раза и увеличите плечо согласований.
С учетом, что IT сотрудник - это дорого, то "дуть штат" заказчики не любят.
Например:
Заказчику требуется какая-то бизнес фича,
ее потребуется перевести с языка заказчика на язык разработчика.
Но прежде чем ее переводить - нужно оценить ее исполнимость, иначе есть риск того, что БА подпишется под неисполнимое в рамках бюджета задание.
Эта ошибка, кстати, встречается часто.
Более того, у каждого задания есть несколько вариантов исполнения, а значит требуется определить граничные условия.
Вот и получается, что БА должен быть немного разработчик, чтоб понимать, как это можно сделать " в теории", чтоб задать правильные вопросы.
Как это будет "на практике" - финально решит разработчик или тим лид исходя, как раз, из граничных условий.
Если же БА попробует сам спрогнозировать финальное решение на уровне кода и далее будет требовать исполнения "именно так",
то скорее всего это приведет к низкому качеству кода и сложности его поддержки.
Разработчик в 99,9% случаев напишет более оптимальное решение и выберет паттерн, который лучше соответствует задаче.
Далее потребуется зафиксировать User Flow.
И тут БА аналогично потребуется лишь на входе, так как далее задачу возьмет себе Тестировщик и Дизайнер.
Задача БА на этом этапе отрисовать каркас переходов и не более.
Как их лучше расположить и какие цвета выбрать - скажет дизайнер.
Как сделать так, чтоб никто не нажал лишнего - тестировщик.
Следом потребуется хоть как-то оценить вопрос железа.
Где будет развернуто ПО и как именно, какие есть условия по безопасности и т.п.
И опять же БА нужно задать правильные вопросы.
Однако задачей будет заниматься DevSecOps и это правильно.
Вот и получается, что БА подключается только в самом начале,
на этапе "согласования и запуска", а далее вопроса более не касается.
А если касается - значит плохо расписана спецификация и требуется уточнение.
Потому и знать БА приходится очень и очень много, но без глубины.
БА выступает в роли справочника, который сможет направить заказчика в нужное русло.
Как итог БА потребуются:
1) Хотя бы общие принципы передачи информации по сети (модель OSI).
2) Хотя бы базовое понимание разработки и принцип работы с фреймворками.
3) Хотя бы базовое понимание верстки сайтов (HTML+CSS+JS).
4) Хотя бы базовое понимание разных видов API (REST обязательно).
5) Хотя бы базовое понимание того, как ПО деплоится на сервер.
6) Хотя бы базовое понимание того, какая будет скорость ответов при том или ином решении (обязательно понимать разницу между ответами 200,300,400,500),
а самое главное почему ответ пользователям Москвы придет быстрее, чем пользователям Владивостока.
7) Хотя бы базовое понимание работы с БД.
Многие заказчики считают Excel базой данных и будут не понимать, почему нельзя использовать формулу из excel.
8) Иметь громадный уровень переговорных навыков, потому что потребуется много общаться со всеми подряд ради общей цели :)
А вот бегать и следить за правильностью исполнения - это уже к тех лиду, тим лиду, РМ-у и т.п.
У кого как принято, так сказать.
Но точно не к БА.
Недавно, кстати, комментировал схожую статью,
только она была написана от лица тестировщиков:
https://habr.com/ru/companies/samolet/articles/841906/
Предполагаю, что некоторые мои мысли оттуда будут полезны и здесь.
Цитаты:
"Попробую расписать процесс, как его вижу я со своей колокольни.
Прошу сразу камнями не закидывать, так сказать мнение автора может не совпасть с вашим.
И надеюсь, что мое видение будет вам полезно в работе.
По правильному, аналитик перед разработкой создает спецификацию того, что требуется создать.
Он создает это не просто так, а для того, чтоб разработчик мог "не думать" и делать то, что написано.
Сказано 4 ножки у табурета и высота в 2 бутылки 0.5 Кока-колы - делаем 4 ножки и высота в 2 бутылки.
Не сошлось - вопрос к спецификации.
Причем делает он ее не абы как, а подробно, детально прописывая все, что потребуется знать разработчику и РМ."
"Следом идет роль РМ, который по сути должен получить подтверждение от Заказчика, что это действительно тот стул, который имел ввиду заказчик.
"От нас точно ждут табурет? Не стул, не кресло, не скамью? Табурет?" - должен спрашивать РМ у заказчика.
Мнения разошлись - спецификация уходит обратно к аналитику.
Мнения сошлись - информация идет на уровень ниже."
"Далее начинается уровень Разработчика."
"После этого действительно наступает уровень Тестировщика."
Надеюсь, что комментарий был для вас полезен и поможет дополнить, при необходимости, статью :)
Услышал, благодарю за обратную связь.
Подумаю как можно использовать эту информацию во второй редакции статьи :)
Сошлюсь на статью 2010 года, которая (с учетом количества лайков) на мой взгляд заслуживает доверия.
https://habr.com/ru/articles/82670/
Первый же пункт статьи опровергает утверждение "доступная сумма кошелька хранится именно в памяти карты".
Опять же, не очень безопасно хранить сумму на самой карте.
Думаю реестр, все же, находится в банке.
Иначе я ломаю карту и вот могу снять вместо 100 рублей 100 000 рублей.
Как итог "смарт карта" и "банковский пластик" - это все же одно и тоже, т.е. относится к разделу "безнал", который не работает оффлайн.
Если я вас правильно понял:
1) "безнал" - всегда есть данные у банка о состоянии счета и потеря карты не проблема, их откатывают из данных банка.
2) "крипта" - всегда есть данные о состоянии счета, но потеря кошелька/пина - проблема.
3) "смарт карта" - данных о состоянии счета нет и потеря кошелька - проблема.
Однако, вряд ли информация о балансе хранится в самой карте.
В этом случае крайне высок риск подделки данных и как итог незаконного обогащения.
Предполагаю, что вы заблуждаетесь, так как смарт карта, исходя из описания в интернете - это микрочип + пластик.
Т.е. по своей сути - это банковская карта, т.е. "безнал" с центральным реестром в банке.
А значит оффлайн она не работает, как минимум терминал должен отсылать транзакционные данные и получать соответствующий ответ.
Или все же имелось ввиду что-то иное?
Спасибо за комментарий.
Статья называется "Мнение" и призывает к обсуждению вопроса.
Насколько знаю, даже такого уровня материалов сейчас в сети не очень много.
Если ваша экспертиза по этому вопросу выше - вы можете внести свой вклад в этот материал.
После проверки - обязательно добавлю с указанием вас, как источника :)
Т.е. по сути смарт карта - это карта Тройка из Метрополитена,
верно уловил вашу мысль?
Мне не кажется, что это очень безопасный метод хранения финансовых средств и практика не распространилась как раз по этой причине.
Т.е. ниша "оффлайн инструмент для банковских операций" так и осталась открытой
Спасибо, с таблицей идея принята, согласен.
Действительно в итогах ее не хватает.
Взял в работу - дополню по мере доступного времени :)
1) Ссылки на часть источников в статье присутствуют.
2) За ваши ссылки - благодарю, после изучения добавлю их апдейтом в текст статьи с указанием вас, как источника ссылок.
Если вы не против, конечно.
И если они смогут дополнить статью чем-то, конечно.
Спасибо за комментарий.
Усиление контроля - не всегда плохо.
Зависит от того, кого собираются контролировать и с какой целью.
Ваша мысль касательно смарт-карт показалась мне интересной.
Если механизм существовал, то почему он сейчас не применяется в отдаленных уголках РФ?
Сможете более подробно обосновать свою позицию, если вам тема знакома?
Ваше предположение находит подтверждение еще в одном наборе данных.
1) Китай не легализует статус "крипты", как официального средства платежа.
2) В 2023 году в Индии блокировали работу криптобирж, а в 2024, насколько понимаю, начали облагать налогом, при этом не дав статус легальной валюты.
3) Схожий механизм налогообложения от продажи "крипты" работает сейчас в РФ.
Сложность в том, что это могут быть случайные корреляции на схожие экономические вызовы в разных странах.
Как схожим образом у всех птиц кости стали легче в ответ на попытку полетов.
Спасибо за комментарий, попробую ответить на базе той информации, которая у меня есть.
Основным средством хранения выступают распределенные реестры ЦБ, при этом в роли UI выступает телефон.
Точных сведений о том, сколько будет реестров и как они между собой связаны - найти не удалось.
Сведения о том, что в роли "хранилища" может выступать телефон присутствуют, однако, предполагаю, что эта возможность "резервная", как раз для случаев оффлайн-покупок.
Касательно безопасности такого подхода - соглашусь, что есть риски.
Однако, схожий механизм используется сейчас банковскими приложениями и приложениями госуслуг, где в роли UI выступает смартфон, который обращается к "реестру", но не распределенному.
Это может означать, что такой подход более-менее эффективен, проверен и защищен.
Хотя, справедливости ради, в минусы при публикации был добавлен пункт
"Повышенный спрос на вредоносы с бэкдором на смартфон."
То есть риск безопасности смартфонов мне тоже показался весомым.
Добрый день.
Одобрил ваш комментарий, предположив, что вы сможете перейти на язык конструктивной критики.
Статья полностью написана человеком без участия AI.
Да, на базе информации из СМИ - об этом написано в самом начале.
Если вы считаете, что статья вводит в заблуждение, то прошу указать конкретные пункты, которые расходятся с официальной информацией СМИ.
Если же вы владеете техническими деталями реализации проекта - можете ими поделиться с сообществом, мы будем благодарны.
Спасибо за вопрос.
Если исходить из того, что стейблкоин - это "крипта" с присущими ей плюсами и минусами, то "цифра" - это нечто совсем другое.
Как минимум из-за возможности офлайн оплат и подготовки инфраструктуры ритейла РФ к использованию "цифры".
Хотя согласен, что прослеживается интересная параллель между связкой "цифра"-Рубль и "стейбл"-Доллар.
К сожалению пока не было информации о том, что валюты будут взаимно интегрироваться с какими-то еще.
У меня было такое предположение, но не имея конкретной доказательной базы обозначать это как "действующий" пункт не стал.
Если предположить, что "цифра" будет ликвидна не только в рамках РФ, но и в других странах, то вы правы.
Однако пока об этом говорить рано хотя бы в силу того, что позиционируется она как как внутренний инструмент для граждан РФ, а не как средство межгосударственного обмена.
Спасибо за комментарий.
Соглашусь, что с уверенностью сказать не сможет никто.
Об этом же пишу и я в начале статьи, приглашая пользователей к обсуждению вопроса.
Тем не менее, если исходить из информации СМИ об этой технологии, то банки не пострадают вообще.
Основная прибыль банков идет из кредитов, которые выдаются из финансового массива вкладов.
А поскольку "цифра" не приносит прибыли в виде процентов, то вклады как были в банках, так и останутся.
Это означает, что кредиты, как выдавались банками, так и будут.
Таким образом получается, что банки пострадают лишь с точки зрения эквайринга, который и без того выдавливается с рынка системой СБП.
Согласен полностью,
в частности в рамках статьи мной было высказано предположение о том, что "окраска" будет производится на базе "Кода ТН ВЭД".
Более точной информации, к сожалению, у меня нет.
Если вы сможете дополнить какие-то части статьи дополнительными элементами, то после проверки источников информации - обязательно включу данные в статью и укажу в апдейте вас, как автора апдейта
Благодарю за комментарий, однако мне бы хотелось избежать политической плоскости данного вопроса.
Обсуждается именно техническая часть и особенности работы системы как таковой.
Думаю, что по итогу разобрались с вопросом. :)
Вы действительно правы, что стекло не блокирует ИК-спектр полностью.
Цитирую мой ответ пользователю REPISOT:
Благодарю за картинку, она навела меня на мысль поискать подробную информацию у тех, кто на этом специализируется.
На всякий случай напомню, что в статье описывается не ИК-излучение, а работа блютуз-маяков, т.е. ИК-спектр находится не совсем в моем рабочем пространстве :)
В частности для моего ответа ниже будет использован материал
"Светопропускание оконных конструкций и различные способы достижения нормативных результатов к.т.н. А.Г. Чесноков (АО "ГИС", Москва)"
Если исходить из него, то есть несколько интересных выводов:
1) Стекло действительно пропускает диапазон от 500 до 2500 нм, т.е. утверждать, что ИК-спектр НЕ проходит через стекло - неверно.
Соответвенно, здесь вы правы полностью, а я заблуждался.
Даже обычное стекло может пропускать ИК-спектр.
2) Стекло пропускает определенный % от ИК-спектра.
Если мы рассматриваем его как 700-2500нм, то это +/- 50%, исходя из графика.
Таким образом получается, что общий принцип работы объяснен мной верно.
Наблюдается эффект термоса, когда входящее излучение блокируется внутри, правда в счет "частичного отражения", а не "полного отражения".