код зеленый что значит
По зелёному сертификату. Как действует система QR-кодов в разных странах
Собеседники «БелПрессы» из СНГ, Европы и Южной Америки – о том, какие антиковидные ограничения существуют в их странах
С 8 ноября в Белгородской области ввели систему QR-кодов для всей сферы услуг, кроме продуктовых магазинов и магазинов с товарами первой необходимости. Пока белгородцы привыкают жить в условиях обязательных QR-кодов, изучаем зарубежный опыт.
Италия
В странах ЕС с 1 июля ввели цифровой ковид-сертификат, или Green pass – QR-код в электронном или бумажном варианте. Его можно получить, загрузив в приложение сертификат о прививке от коронавируса одобренной ЕС вакциной, или сертификат об отрицательном ПЦР-тесте, а также сертификат о перенесённом коронавирусе. Последний в цифровом виде выдают через 11 дней после получения положительного ПЦР-теста. Самыми доступными называют первые два – выданный в Европе сертификат о вакцинации или ПЦР-тест, сделанный в стране Еврозоны.
В Италии с августа без зелёного пропуска всем жителям страны старше 12 лет нельзя попасть в рестораны или кафе, в спортивные и фитнес-залы, бассейны, музеи, театры, а также нельзя стать участником массовых мероприятий. С 1 сентября QR-коды необходимы на внутренних и международных авиарейсах, междугородных и скоростных поездах, автобусах дальнего следования, кораблях и паромах. 22 сентября требования Green pass снова ужесточили. Без него предприятия не должны пускать сотрудников на рабочие места.
«QR-код проверяет начальник на работе, официант в ресторане. Если придёт проверка, а ты без кода, – штраф. И начальнику, и хозяину ресторана, и тебе – от 400 до 2 000 евро (работодателю до 1 000 евро и до 2 000 евро при повторном нарушении, сотруднику – от 600 до 1,5 тыс. евро – прим. ред.), – рассказывает Вероника Джентили из Ливорно. – Альтернатива – ПЦР-тест на 72 часа за 50 евро или экспресс-тест в аптеке за 15 евро на 48 часов. Приходишь в аптеку, палочка в нос, и через пять минут тебе присылают на телефон код, который ты должен ввести в специальной программе, где отслеживают всех, кто сделал тест. Потом ты получаешь QR-код. Что касается прививок, у нас тут уже делают третью дозу, и с ноября начинается вакцинация детей с 8 до 12 лет».
Казахстан
В Казахстане ещё зимой этого года разработали приложение Ashyq (в переводе – «открыто») для контроля и анализа данных по эпидситуации в стране – как альтернативу полному закрытию бизнеса и для частичного снятия ограничений. Жители страны используют его на входе в общественные места.
«На дверях крупных магазинов, офисов и т. д. висит изображение QR-кода. Человек сканирует его на смартфон с установленной программкой Ashyq, и сразу выявляется твой статус. Показываешь этот статус охраннику и всё», – поясняет местный журналист Сергей.
Как поясняют на сайте электронного правительства страны, приложение интегрировано с общей базой Министерства здравоохранения Республики Казахстан и позволяет определить, является посетитель носителем вируса или нет. Чтобы попасть в заведение, которое присоединилось к проекту Ashyq, посетитель авторизуется в приложении через свой номер мобильного телефона и индивидуальный идентификационный номер, который жителю страны присваивают один раз и пожизненно. Статусы, которые нужно показать ответственному сотруднику заведения на входе, различаются по цветам.
Зелёный означает, что ограничений в передвижении нет: пользователь обозначен в базе данных как прошедший ПЦР-тестирование с отрицательным результатом на COVID-19. Синий – ограничений в передвижении нет, кроме мест, где ПЦР является обязательным. Жёлтый – частичное ограничение передвижения: человек в базе данных ПЦР обозначен как контактный. Ему можно посещать продуктовые и хозяйственные магазины, аптеки не далее 500 метров от места, где больной коронавирусом, который с ним контактировал, соблюдает режим домашней изоляции. Красный статус – передвижение ограничено, пользователь обязан соблюдать режим строгой изоляции дома при амбулаторном наблюдении.
Если посетитель отказывается использовать Ashyq при входе, то услугу ему вправе не предоставлять.
Сербия
Корреспондент российского СМИ на Балканах и создатель телеграм-канала «Балканская_GolubKa» Ксения Голуб живёт в столице Сербии – Белграде.
«В Сербии существуют QR-коды, они привязаны к нашим цифровым зелёным сертификатам, которые признаются в Европе и ряде других стран, но, увы, не действуют в России. Этот документ выдают гражданину Сербии или иностранцу с видом на жительство, при одном из нескольких условий. У него должно быть свидетельство получения второй или третьей дозы вакцины против COVID-19, подтверждающее, что вакцинация совершена не позднее 210 дней, или отрицательный результат ПЦР не старше 72 часов, либо отрицательный тест на антиген не старше 48 часов, либо свидетельство о перенесённом коронавирусе в предыдущие 7 месяцев, которое подтверждено положительными ПЦР или тестом на антиген, либо положительный тест на антитела, не старше трёх месяцев и сделанный в гослаборатории», – рассказывает Ксения «БелПрессе».
QR-коды, по её словам, находятся в зелёном сертификате и необходимы при посещении «угостительских объектов»: ресторанов, кафе, ночных клубов, а также различных казино, игровых клубов и прочих заведений, для тех, кто приходит туда после 20:00. С 6 часов утра и до 20:00 они не требуются.
«При этом в стране жёстко соблюдались и соблюдаются меры по ношению масок во всех общественных местах, особенно в транспорте. У нас даже летом без масок людей в транспорте не было», – говорит она.
По словам Голуб, сделать прививку от коронавируса в Сербии можно пятью вакцинами.
«Pfizer, Moderna, AstroZeneca, «Синофарм» (вакцина BBIBP-CorV, разработанная компанией Sinopharm – прим. ред.) и «Спутник V». В основном вакцинируются китайской «Синофарм», российской и Pfizer, – добавила она. – В стране относительно спокойный уровень опасности, мы не в красной зоне. Население страны 8 млн человек, из них 3 млн человек уже полностью вакцинированы двумя-тремя дозами. Заболело у нас 1,2 млн человек, а летальных случаев 10 595. Антипрививочники есть, но их мало. Протесты против введения тех же QR-кодов тоже бывают, но они малочисленны».
Эквадор
Игорь Иванов из города Гуаякиль в Эквадоре говорит о ковидных ограничениях в стране:
«QR-кодов, ковидных паспортов и прочего нет, если не считать обязательного измерения температуры при входе в публичные пространства. При этом власти требуют, чтобы работники предприятий и учреждений с высоким уровнем контактности были привиты (это преподаватели, врачи, продавцы, официанты и т. п). В противном случае эти организации не могут работать контактным образом. У меня отдел кадров университета потребовал сертификат о вакцинации, «Спутник» вполне устроил. Но надо понимать, что ситуация в Эквадоре серьёзно отличается от российской. Начало пандемии было очень сложным, не успевали хоронить погибших. Был жёсткий локдаун в течение 3–4 месяцев. Но как только стали доступны вакцины, Эквадор за 100 дней провёл тотальную вакцинацию».
По словам Иванова, сейчас в Эквадоре привито больше 75 % взрослого (старше 11 лет) населения.
«Антиваксерных настроений в Эквадоре практически нет. Сейчас регистрируется около 300 случаев заражения в день и единичные случаи гибели. А на Галапагосских островах, где вакцинированы почти все, практически нет заражений (один случай за две-три недели), – говорит он. Жизнь почти нормализовалась, но в публичных местах по‑прежнему строго соблюдаются масочный режим и правила дистанцирования. Такое развитие событий характерно для всех стран Южной Америки, кроме Бразилии и Венесуэлы».
Подготовили Алексей Стопичев, Нелля Калиева, Оксана Придворева
Как создавать «зеленый» код
Что такое энерго-эффективность в применении к мобильным платформам? Простыми словами это возможность сделать больше, затратив при этом меньше энергии.
Каждому пользователю хотелось бы как можно реже заряжать свое мобильное устройство, будь то смартфон, нетбук, ультрабук. Возможно, когда-нибудь наступит момент, когда устройство нужно будет зарядить всего один раз, после его покупки и пользоваться до тех пор пока оно не надоест или морально не устареет.
Если рассмотреть укрупненую модель любой мобильной платформы то она состоит и 3-х основных частей.
Аккумулятор
Является хранилищем энергии мобильного устройства. Производители аккумуляторов каждый год стараются увеличить емкость, уменьшить время полной зарядки.
Железо
Является основным прямым потребителем энергии. Тут прогресс тоже не стоит на месте. Производители «железа» создают все более энерго-эффективные чипы, выдающие большую производительность на Ватт потребленной энергии, добавляют различные режимы энергопотребления, позволяющие отключать неиспользуемое железо, переводить в режимы низкого энергопотребления, экономя тем самым батарею.
Является косвенным потребителем энергии. Напрямую софт ничего не потребляет, он вынуждает железо потреблять энергию. Здесь тоже есть свои методики, позволяющие продлить жизнь батареи. О проблеме энерго-эффективности софта я и хотел бы поговорить в данной статье.
Как именно софт влияет на потребление энергии? Если в двух словах — он не дает железу «спать».
Рассмотрим одного из крупных потребителей энергии в системе — процессор.
Процессор может управлять своим энергопотреблением с помощью, так называемых, C-State. Для тех, кто не знаком с этими режимами, привожу короткую справку:
С0 — рабочее состояние процессора, подразделяется на различные P-States.
C1 — состояние, когда процессор ничего не делает, но готов приступить к работе, правда с небольшой задержкой. Многие процессоры имеют различные вариации этого состояния.
С2 — почти тоже самое, что и С1, но в этом состоянии процессор потребляет меньше энергии, и имеет большую задержку для перехода в рабочее состояние.
С3 — состояние «сна», переходя в это состояние процессор очищает кэш второго уровня. Характеризуется меньшим энергопотреблением, и более долгим временем перехода в рабочее состояние.
… и так далее в зависимости от процессора.
Для того чтобы было более наглядно приведу иллюстрацию:
Самый энерго-эффективный вариант — процессор всегда спит. Значит самая эффективная, в плане энергозатрат программа, это та программа, которая не запущена и его не «будит». Она не производит никаких действий, и вообще ничего не потребляет. Но такой софт никому не нужен, программа должна делать что-то полезное. Компромисное решение — программа, которая не делает ничего тогда когда не должна ничего делать («будит» только по нужде), и если делает что-то, то делает это максимально быстро.
Особенно это касается программ, которые выполняют какие-либо действия в фоновом режиме. Эти программы должны спать всегда и просыпаться только при наступлении какого-либо события.
События рулят или Event-driven подход
Приведу пример «неправильного» кода (к сожалению, такой подход к написанию кода используется гораздо чаще, чем вы думаете). Данный пример кода служит для получения и данных из сокета, например, в каком-нибудь серверном приложении.
Что же здесь «неправильного»? Есть данные или нет данных, код будет «будить» процессор каждые 1000 мс. Поведение кода напоминает осла из Шрека: «Уже приехали? А теперь приехали? А сейчас приехали?».
«Правильный» код, для данной задачи, не будет ни кого спрашивать, он уснет у будет ждать когда разбудят его. Для этого, во многих операционных системах, существуют объекты синхронизации, такие как события. С учетом сказанного код должен выглядеть так (код не полный, опущена обработка ошибок и кодов возврата, моя задача просто проиллюстрировать принцип):
В чем прелесть примера выше? Он будет спать тогда, когда ему нечего делать.
Таймеры, будильники нашего кода
Иногда без таймеров не обойтись, примеров масса — проигрывание аудио, видео, анимация.
Немного о таймерах. Интервал системного таймера Windows, по умолчанию, равен 15,6 мс. Что это означает для программ? Допустим вы хотите, чтобы выше приложение выполняло какое-то действие каждые 40 мс. Проходит первый интервал в 15,6 мс, слишком мало, проходит второй 31,1, опять рано, третий 46,8 — попали, таймер сработает. В большинстве случаев лишние 6,8 мс не имеют значения.
Так же прямое влияние на Sleep, если вы вызовете Sleep(1), при установленном интервале в 15,6 мс, то спать код будет не 1 мс, а все 15,6 мс.
Но если дело касается проигрывания видео — тогда это поведение не приемлемо. В этих случаях разработчик может изменить дискретность системного таймера вызвав функцию из Windows Multimedia API — timeBeginPeriod. Данная функция позволяет изменить период таймера вплоть до 1мс. Для кода это хорошо, но сильно сокращает жизнь батареи (вплоть до 25%).
Как найти компромисс? Все просто изменяйте период системного таймера только тогда, когда это действительно необходимо. Например, если вы разрабатываете приложение, использующее анимацию и вам нужна меньшая дискретность таймера меняйте таймер тогда, когда анимация отображается и происходит, и возвращайте если, например, окно свернуто или анимация остановлена.
С точки зрения пользователя иногда, чтобы понять как продлить жизнь от батареи будет интересна утилита Powercfg. С ее помощью можно узнать какое-то приложение изменило период системого таймера, значение периода системного таймера, информацию о проблемах драйверов, не позволяющих переводить «железо» в режим низкого энерго потребления и т.д.
Объединение таймеров
В Windows 7 появилась замечательная возможность объединять таймеры. Что это такое и как это работает представлено на рисунке ниже:
Т.е. Windows «подстраивает» таймеры приложений таким образом, чтобы они совпадали со срабатываниями таймера самой операционной системы.
Для того, чтобы использовать эту возможность необходимо вызвать
Полное описание функции вы можете найти в MSDN. В рамках данной статьи нас интересуют только параметр TolerableDelay, который определяет максимальное допустимое отклюнение от заданного интервала.
Более подробно о таймерах в Windows можно прочитать в статье Timers, Timer Resolution, and Development of Efficient Code
Сделай это быстро
Еще один способ сделать программу более энерго-эффективной это научить ее делать нужные вещи быстро, на сколько это возможно. Добиться этого можно, например, оптимизировав код, путем использования SSE, AVX и других аппаратных возможностей платформы. В качестве примера хочу привести использование Quick Sync в Sandy Bridge для кодирования и декодирования видео. На сайте Tom’s Hardware можно посмотреть результаты.
Допустим мы оптимизировали нашу программу, но насколько она теперь более энерго-эффективна, как это оценить? Очень просто — с помощью специальных программ и инструментов.
Инструменты для анализа энерго-эффективности
1. Intel Power Checker. Пожалуй самый простой и быстрый способ оценить энерго-эффективность своей программы.
Обзор и описание программы можно найти в блоге ISN
Более сложный, но вместе с тем более информативный инструмент, служит для отслеживания различных активностей железа и софта, которые влияют на время работы от батареи.
Тоже достаточно интересный инструмент, определяющий энергопотребление различных компонентов платформы. Может работать в связке с ваттметром WattsUp.
Где узнать больше
Intel Power Efficiency Community статьи, практические рекомендацие и советы по созданию энерго-эффективного программного обеспечения.
Battery Life and Energy Efficiency сборник статей и рецептов от Microsoft
Timers, Timer Resolution, and Development of Efficient Code ссылка уже приведена выше, для тех, кто начинает читать статью с конца.
Если есть вопросы — задавайте в комментариях. Также свои вопросы по разработке «зеленого» софта можете задать мне на вебинаре, который состоится завтра, 15 декабря в 11 утра.
Green Code и березки. Основные принципы зеленого кода в разработке
Всем привет. Меня зовут Стас, в компании Домклик я курирую разработку сервисов бек-офиса для ипотечного кредитования Сбербанка.
В последнее время во всевозможных докладах и подкастах я довольно часто стал встречать термин «Green Code». Покопавшись в интернете и изучив эту тему, я понял, что этим термином описывают комплекс приёмов в разработке и проектировании приложений, позволяющих сократить энергопотребление оборудования, на котором этот код выполняется.
Более-менее этим вопросом обычно озадачиваются разработчики мобильных приложений, в основном потому, что устройство, на котором будет выполняться их код, имеет ограниченную емкость батареи.
Тема стала достаточно «хайповой», и я решил прикинуть, как именно принципы «зеленого» могут быть отражены в WEB-разработке.
Основные принципы написания «зеленого кода»
Прочитав достаточно много докладов и статей на эту тему, я бы выделил следующие аспекты разработки приложений, которые влияют на энергопотребление:
1) Упрощение и оптимизация алгоритмов
Как уже было сказано выше, выполнение кода должно приводить к минимальному потреблению энергии. Оптимизированный код будет выполняться быстрее и, соответственно, потребует меньше затрат на его обработку и охлаждение оборудования.
Давайте попробуем посчитать разницу в энергозатратах на исполнение конкретной операции в коде — классической сортировке списка. Я специально буду утрировать ситуацию в приведенном примере, чтобы контрастнее показать разницу.
Возьмём сортировку методом пузырька. Наверное, это один из самых неоптимальных способов. Очень нам подходит. Рассчитаем сортировку списка и посмотрим, как она отразилась на энергозатратах MacBook. Для начала смоделируем массив данных и саму логику сортировки пузырьком:
Для замера влияния исполнения кода на энергозатраты я использовал систему мониторинга iStat Menus 6 (https://bjango.com/mac/istatmenus/). Подключил MacBook к сети, закрыл все сторонние приложения, выждал определенное время для зарядки батареи, и запустил сортировку:
График энергопотребления при выполнении сортировки пузырьком:
Виден ярко выраженный скачок потребления мощности длительностью в 305 секунд. Он вызван исполнением нашего неоптимального запроса. Дополнительно потраченная энергия за 5 минут (305 секунд):
Теперь допустим, что этот код случайно попал на промышленный продуктовый сервер (примем как допущение, что дополнительные энергозатраты на сервере будут такими же, как на моем MacBook, и зависимость прямо пропорциональная) и стал выполняться с частотой 1 раз в 10 секунд. Тогда в год мы получим дополнительные энергозатраты:
Предположим, что ЦОД, в котором размещается сервер, получает энергоснабжение от котельной, в качестве топлива в которой используется березовая древесина. При сгорании 1 м 3 березовой древесины выделяется 1900 кВт*ч/м 3 энергии. Разумеется, КПД котельной не 100 %, и если принять его за 75 %, то получим:
Если принять дерево за правильный цилиндр, объем которого равен
где R — радиус ствола дерева, примем его за 0,12 метра (среднее значение),
H — высота ствола дерева, примем ее за 3 метра (среднее значение).
V = 3,14 × 0,0144 × 3 = 0,14 м 3
График энергопотребления при выполнении стандартной сортировки в Python:
Применяя ту же логику расчета (длительность пика была 10 сек), получаем:
P = (W2 – W1) × 10 сек = (3,51 [мощность при выполнении скрипта] – 2,9 [мощность в состоянии покоя]) × 10 сек = 6,1 Дж = 0,0000016 кВт*ч
В год получим (при условии выполнения операции 1 раз в 10 секунд)
365 дней × 24 часа × 3600 с/10 × 0,0000016 кВт*ч = 5,05 кВт*ч
5,05 / 1900 / 0,75 × 7,14 = 0,025 бревна березы.
Конечно, в этом примере много допущений, да и сортировку пузырьком делают достаточно редко. Но полученные числа показались мне интересными
2) Использовать событийную модель (event driven model) работы приложения там, где только можно
Дело в том, что большинство процессоров поддерживают несколько «состояний» энергопотребления. В том случае, если ядро не занято какими-то вычислениями, операционная система переводит его в состояние «сна», при котором процессор потребляет гораздо меньше энергии.
Спектр состояний (оптимизация по энергопотреблению):
Подробнее об этом можно прочитать тут.
Довольно часто бывает ситуация, когда какая-то логика приложения должна выполниться при возникновении определенного события. И чтобы узнать, что это событие произошло, заинтересованный в получении этой информации сервис зачастую периодически опрашивает сервис, хранящий факт выполнения этого события. По таймеру. Причем подавляющая часть запросов получает отрицательный ответ, то есть 99 % запросов, по сути, не нужны.
Правильно было бы транслировать соответствующее событие в очередь, и считывать факт его возникновения всем заинтересованным сервисам.
Спектр состояний (оптимизация по энергопотреблению):
Другой пример — взаимодействие фронтенд- и бекенд-компонентов приложения. Если фронту надо поменять свое состояние в зависимости от данных в базе, иногда на бекенд периодически шлют запросы, создавая ненужную дополнительную нагрузку. Хотя можно проинформировать фронт об изменении состояния необходимых данных через сокет–сервер.
Хотя с сокетами тоже можно ошибиться, вот пример «плохого» кода:
Видно, что даже если данные в сокет не поступили, всё равно каждые 1000 секунд код будет выполняться, тратя драгоценную энергию.
То же самое можно написать чуть по-другому, и энергии будет тратиться меньше:
3) UI/UX: Интерфейс пользователя не должен показывать «лишние» данные
Если данные всё же используются, но редко, то лучше их не отображать по умолчанию, а показывать только по кнопке «Показать детальную информацию».
Простой пример, иллюстрирующий этот принцип: отображение списков объектов данных (заявок, пользователей, торговых точек, складов, офисов) при условии, что сценарий использования формы всё равно предполагает поиск нужного объекта.
Пример плохого интерфейса:
На странице отображается огромный список задач (разбитый на «страницы»), однако пользователь всё равно будет искать определенного клиента (по определенной логике у него в голове) в поисковой строке сверху. Зачем тратить ресурсы на получение списка задач?
Тот же самый сценарий, реализованный по-другому:
Пример «зеленого» интерфейса:
Логика выбора клиента перенесена в систему, по умолчанию не запрашивается лишних данных «по привычке». Этому варианту, помимо экологов, и кибербезопасность будет люто аплодировать.
4) Рефакторинг
Рефакторинг полезен почти всегда. Но в этом контексте он нужен для одной простой цели: выкинуть ненужный (мусорный) код или упростить существующий, чтобы снизить энергопотребление.
Многие приложения, развивающиеся более трёх лет, накапливают в себе сотни строк неиспользуемого или непрогнозируемо работающего кода, оставшегося от ранее реализованных (и уже, возможно, выпиленных) функций. Иногда этот код даже исполняется, но результат его работы не востребован.
Периодический аудит и рефакторинг снизят количество такого кода, хотя, вероятно, избавиться от него до конца не получится.
К примеру, регулярно рефакторя один из наших сервисов (в рамках технической квоты рабочего времени), мы обнаружили вот такое:
Всё это можно убрать без потери функциональности.
5) Использовать низкоуровневые языки программирования для высоконагруженных приложений
Очевидно, что в большинстве случаев приложения, написанные на низкоуровневых языках, более энергоэффективны. Нагруженный сервис на Python (если он выполняет простую операцию) имеет смысл переписать на C/C+. Будет быстрее и «зеленее».
Правда, часто у нас нет нужных знаний для написания логики на таких языках.
6) Группировать I/O-операции
Системы хранения, как и процессоры, также имеют различные состояния энергопотребления.
В режиме «сна» потребляется гораздо меньше энергии, чем в рабочем «прогретом» состоянии. Особенно это характерно для систем хранения/жестких дисков.
Если в работе приложения можно группировать данные, записываемые на диск, и обращаться к диску не постоянно, а в определенные периоды времени, то это будет энергоэффективнее, поскольку в период «простоя» операционная система отправит диск в «спячку».
7) Использование менее энергоемких систем хранения для логов
Хорошей практикой будет использовать «горячее» и «холодное» хранение. Например, логи за последнюю неделю имеет смысл хранить в индексированном виде «горячего» приготовления, поскольку вероятность обращения к ним будет достаточно высока. Логи за более длительный период можно хранить в более дешевых и менее энергозатратных системах хранения.
А как в промышленном масштабе?
Выше мы рассмотрели основные приемы работы с кодом для обеспечения его энергоэффективности. Но даже соблюдение большинства этих правил даст весьма скромную экономию, которую сложно будет визуализировать. Конечно, если в проде не сортировать списки методом пузырька
Гораздо больший эффект даст целенаправленная разработка функциональности по внедрению электронного документооборота.
Одним из направлений деятельности команд Домклик является оптимизация и упрощение процесса получения ипотеки. И в этом ипотечном процессе на финальной стадии готовится достаточно много документов на бумаге. Причем в нескольких экземплярах. Один экземпляр для продавца, один для покупателя, один для архива банка.
Мне приятно осознавать, что Домклик тратит много усилий для изничтожения этой порочной практики и перевода всего документооборота в электронный формат. В этом году значительная часть ипотечных сделок была уже полностью оцифрована (печаталась только одна бумага: заявление на выпуск УКЭП, усиленной криптографической электронной подписи). Все остальные документы подписывались уже этим УКЭП и бумага на них не тратилось.
Благодаря этой инициативе было сэкономлено уже более 67 491 108 листов бумаги. В березках это примерно 23 000 деревьев!