Дешевые vds

4 января 2021 года для многих людей во всем мире, также как и для большинства работников Slack был первым рабочим днем после нового года (за исключением специалистов горячей линии и службы поддержки, которые никогда не спят). В день Азии и утро в Европе прошло спокойно, но когда забрезжил рассвет в Америке мы стали получать сообщения от внешней службы мониторинга о росте количества ошибок. Мы начали разбираться, в чем дело. Ситуация с ошибками ухудшалась и мы инициировали процесс расследования инцидентов (о том, как у нас устроено управление инцидентами подробнее можно почитать в статье Райана Каткова (Ryan Katkov) All Hands on Deck https://slack.engineering/all-hands-on-deck/).

Как будто нам этого было недостаточно для того, чтобы окончательно испортить первый рабочий день нового года, в тот момент, мы пытались понять, что происходит, упали сервисы панелей мониторинга и оповещений. Мы связались с группой мониторинга, чтобы они попытались восстановить их как можно быстрее.

Чтобы сократить список возможных причин мы по-быстрому откатили некоторые изменения, которые были сделаны сегодня (забегая вперед дело было не в них). Также мы подключили еще нескольких человек из инфраструктурных групп, потому что процесс поиска сбоя шел медленно из-за того, что не работали панели мониторинга и оповещения. У нас сохранялся доступ к различным внутренним консолям и страницам статуса, к некоторым консольным утилитам, а также к системе сбора логов. Система сбора метрик тоже функционировала и мы могли запускать запросы к ней напрямую, но это было и совсем не так результативно, как как использование наших панелей мониторинга с преднастроенными запросами. Хотя наша инфраструктура в целом функционировала, мы видели признаки деградации сети, о чем мы сообщили AWS, нашему основному облачному провайдеру. На тот момент Slack работал в 6:57 по тихоокеанскому стандартному времени 99% сообщений успешно доставлялись (хотя это не было нормой, поскольку наше обычное значение этого параметра 99.999%).

Трафик в Slack имеет характерные всплески в начале и середине каждого часа, когда уведомления и другие типы автоматически создаваемых сообщений (большая часть из них внешняя это задачи cron со всего мира). У нас настроено масштабирование звена веб-служб и бэкэнда для того, чтобы подстроится под эти пики. Тем не менее всплеск нагрузки в 7 утра в сочетании с проблемами сетевой инфраструктуры привел к перегрузке звена веб-служб. С ростом нагрузки стали расти потери пакетов. Это, в свою очередь, привело к большим задержкам обращений веб-служб к бэкэнду, и их перегрузке. Slack упал.

В это время независимо друг от друга происходили две вещи. Во-первых, некоторые инстансы были автоматически помечены системой как проблемные, потому что они не могли достучаться до служб бэкэнда, от которых они зависели. Система попыталась заменить их новыми. Во-вторых, наша система автоматического масштабирования уменьшила размеры звена веб-сервисов. Так как мы работали без панелей мониторинга, некоторые инженеры, которые вели работы по данному инциденту подключались напрямую к сервисам, работающим на проде. У многих из них начали прерываться сессии SSH, потому что инстансы, с которыми они работали были отключены системой. Это еще больше затрудняло наши попытки разобраться в ситуации, поэтому мы отключили автоматическое уменьшение размеров системы. Это упростило работу по поиску сбоя и позволило стабилизовать производительность системы.

Наше звено веб-сервисов масштабируется на основании двух видов сигналов. Один из них, это загрузка процессоров (метрика, которая используется для масштабирования практически везде) а другой, это загрузка доступных рабочих потоков Apache. Проблемы с сетью до 7:00 означали, что потоки находились больше времени в режиме ожидания, что приводило к уменьшению загрузки процессоров, а это инициировало автоматическое уменьшения количества инстансов. Поскольку состояние сети продолжало ухудшаться, из-за чего звено веб-служб больше времени находилось в ожидании ответа от бэкэнда, что приводило к увеличению загрузки рабочих потоков, и система автоматически увеличила количество инстансов веб-служб. Между 7:01 и 7:15 мы попытались добавить 1200 серверов в наше звено веб-сервисов.


К сожалению, наше масштабирование не отработало как полагается. У нас работает сервис, удачно названный службой обеспечения (в оригинале provision-service прим. пер.) и его название полностью отражает его функционал, в который входит настройка и тестирование новых инстансов, а также выполнение роли управляющего для инфраструктуры. Службе обеспечения нужно взаимодействовать с внутренними системами Slack и c API AWS, а поскольку это взаимодействие происходило по той же нестабильной сети и поскольку, как и большинство систем Slack на тот момент, он тратил больше времени на соединение и получение ответа, и использовал больше ресурсов, чем обычно. Пиковая нагрузка, связанная с необходимостью ввести одновременно большое число инстансов в условиях нестабильной сети привело к тому, что служба обеспечения уперлась в системные ограничения (наиболее значимым из которых было ограничение количества открытых файлов в Linux, но также были превышены и квоты AWS).

Пока мы пытались восстановить работу службы обеспечения, производительность звена веб-сервисов оставалась недостаточной для восстановления нормальной работы из-за того, что масштабирование системы не работало как надо. У нас было запущено большое число инстансов, но большая часть из них не была до конца настроена службой обеспечения и не работала. Большое количество сбойных инстансов привели к тому, что мы достигли предварительно установленного лимита автомасштабирования для нашего звена веб-сервисов, который кратен количеству инстансов, обычно требующихся для того, чтобы справиться с пиковым трафиком. Часть специалистов, работающих над данным инцидентом, занялись тем, что вручную удаляли неработающие инстансы, остальные продолжали искать источник проблемы. Ко всему этому у нас до сих пор не работала служба панелей мониторинга, мы не могли ее запустить из-за того, что служба обеспечения была перегружена.

В один прекрасный момент служба обеспечения заработала (было около 8:15) и начала запускать работающие инстансы. Ситуация стала понемногу улучшаться. У нас по-прежнему были некоторые проблемы с продом, часть из которых удалось смягчить, а другая была в процессе решения. Также мы до сих пор испытывали проблемы связанные с повышенным уровнем потери пакетов в сети. Несмотря на это в 9:15 у нашего звена веб-сервисов было достаточно работающих узлов чтобы переваривать входящий трафик. Из-за проблем с сетью балансировщики нагрузки показывали большое число проблемных узлов, но к счастью у них был режим panic mode https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold в котором балансеры начинают распределять нагрузку на все узлы независимо от результатов проверки их состояния. Это, плюс повторные соединения и паттерн circuit breaking, помогли нам возобновить работу сервиса. Да, Slack был медленнее, чем обычно, и частота ошибок была выше, но в 9:15 он уже работал, а не лежал, как до этого. Целый час ушел на то, чтобы снизить частоту ошибок до приемлемого уровня по двум причинам. Во-первых, из-за нестабильности сети нам требовалось больше инстансов, чем обычно, чтобы нормально обслуживать входящий трафик. Во-вторых, больше времени ушло на процесс развертывания опять же из-за проблем с сетью.


К тому времени, как Slack восстановился, инженеры AWS нашли причину сбоя: часть нашей сетевой инфраструктуры AWS действительно была перегружена, что и приводило к потерям пакетов.

Чтобы было проще понять, что же произошло, стоит рассказать немного подробней о некоторых архитектурных особенностях Slack. На старте, не так уж много лет назад, все, что касается работы Slack работало в одном аккаунте AWS. По мере роста размера, сложности и количества специалистов, задействованных в обслуживании системы, мы отказались от этого решения и разнесли сервисы по различным аккаунтам и VPC (Virtual Private Clouds). Это решение позволило нам добиться большей изолированности между различными сервисами, и позволяло более точно контролировать привилегии операторов. Для того, чтобы связать наши VPC, в качестве хаба мы использовали AWS Transit Gateways (TGWs).

4 января наши TGWs оказались перегружены. TGWs обслуживаются AWS и предполагается, что они должны масштабироваться незаметно для нас. Но в первые дни после нового года трафик Slack имеет необычную структуру, он ниже в выходные дни, поскольку все отвлекаются от работы (молодцы, что поддерживаете баланс работы и лично жизни, пользователи Slack, так держать!). В первый рабочий день кэши клиентов не прогреты и при первом подключении они подгружают больше данных, чем обычно, после нескольких дней затишья нагрузка растет до самых больших значений за год буквально в течении одной ночи.

Наши системы позволяют быстро отмасштабировать производительность систем, чтобы переварить нагрузку такого рода (и в прошлые годы мы всегда хорошо с ней справлялись). Но наши TGWs не смогли отмасштабироваться достаточно быстро. В ходе данного инцидента специалисты AWS были оповещены о нашей проблеме с потерей пакетов их внутренним мониторингом и вручную увеличили емкость TGWs. К 10:40 это изменение вступило в силу во всех зонах доступности (Availability Zones) и наша сеть вернулась к нормальному режиму работы, а с ним вернулись обычные уровни ошибок и задержки.


AWS заверили нас, в процессе разбора данного инцидента ими были пересмотрены алгоритмы масштабирования TGW для резких скачков объема трафика. А мы поставили себе напомнание (конечно же это было напоминание Slack slack.com/intl/en-ie/help/articles/208423427-Set-a-reminder) превентивно увеличить емкость TGWs в конце следующих новогодних каникул.

Выводы

Мониторинг является одним из наших наиболее критичных сервисов благодаря ему мы узнаем в порядке ли службы, с которыми взаимодействуют пользователи, а помимо этого это один из наших наиболее важных инструментов для выявления проблем. Мы прилагаем все усилия, чтобы наши инструменты мониторинга были как можно более независимыми от инфраструктуры Slack, чтобы они были доступны тогда, когда мы нуждаемся в них больше всего. В данной ситуации наши панели мониторинга и оповещения упали, поскольку базы данных, из которых они брали информацию оказались расположены в другом VPC, что привело к зависимости от TGWs. Запуск их в одном VPS позволит избавиться от этой зависимости.

Также мы приняли решение в дальнейшем регулярно проводить нагрузочное тестирование службы обеспечения, для того чтобы исключить проблемы с масштабированием (мы делали это и раньше, но в данном случае превысили параметры наших предыдущих испытаний). Также мы пересмотрим наши конфигурации контроля здоровья сервисов, а также конфигурации автомасштабирования для того, чтобы в дальнейшем избежать подобной перегрузки службы обеспечения даже в случае экстремальных условий, как, например, нестабильного сетевого соединения.

Мы глубоко сожалеем о перебоях в работе нашего приложения. Каждый инцидент это возможность учиться и незапланированный вклад в повышение надежности сервиса в будущем. Мы многое узнали благодаря данному сбою и, как всегда, мы намерены использовать эти незапланированные инвестиции чтобы улучшить нашу инфраструктуру в 2021 и последующие годы.

---

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Статей о том, как подключить дисплей на электронных чернилах к Arduino, STM32, ESP32 и т.д. (нужное подчеркнуть) на этом ресурсе более чем достаточно, и я не стану утомлять читателя очередным погодным информером. Речь пойдет о том, как в хозяйстве можно использовать электронную книгу, ставшую жертвой комбинации четвертой фундаментальной силой природы гравитации и седалищной мышцы Человека Разумного. Хе-хе. Нисколько не сомневаясь в том, что читатель прекрасно знает принцип работы дисплея на электронных чернилах, все же очень кратко пробегусь по основным тезисам.

Для простоты рассмотрим, как устроен один чернильный пиксель. В наиболее распространённом случае, это прозрачная сфера микронных размеров, наполненная неким подобием силиконового масла. В ней плавает некоторое количество частиц черного и белого цвета, имеющих разноименные заряды. И нет, это не электроны с протонами. Как правило частицы представляют собой полимер, обладающий электретными свойствами, то есть они способны долговременно удерживать электрический заряд со всеми вытекающими отсюда свойствами. То есть они будут соответственно себя вести в электрическом поле заряженные частички будут испытывать силу притяжения или отталкивания от обкладок конденсатора с соответствующими зарядами. Ниже, я проиллюстрировал эту магию:



Справедливости ради, стоит упомянуть еще один распространенный вариант устройства пикселя, где черные и белые частички слеплены вместе образуя электрический диполь. В этом случае, такая частичка, при приложении электрического поля, просто вращается в соответствии с ориентацией поля.
Ну а теперь к сути.
Случилось страшное и безжалостная пятая точка смертельно ранила нашу читалку. В подобных случаях я себя всегда успокаиваю тем, что убитый девайс навсегда останется в моем сердце можно использовать как донор разных полезных ништяков. Ну ладно, экран мы разбили, но пиксели-то остались целыми. А значит приступим к операции и экспериментам. Справедливости ради надо сказать, что это далеко не первый мой эксперимент с мертвой читалкой и я наперёд знаю, что и как надо делать, чтобы получить нужную и полезную в хозяйстве вещь. Итак, первое что надо сделать, это разобрать убитый девайс и снять дисплей с электронными чернилами. Сейчас я буду нудно рассказывать о том, как это все сделать самому, ибо сфотографировать процесс не хватило мозгов. А потому:



В общем-то сам экран представляет собой бутерброд, где на активную стеклянную подложку приклеена гибкая пленка с намазанной с внутренней стороны пастой с пикселями. В разрезе это выглядит приблизительно вот так:



Для того что бы отделить активный слой от стеклянной подложки, достаточно немного прогреть феном бутерброд и пленка легко отделиться от основания. Однако, как правило стеклянная подложка по площади чуть больше защитной пленки и по краям пленка приклеена на довольно прочный клей и тут придётся немного повозиться, чтобы схватиться за край пленки. Проще всего использовать канцелярский нож для этих целей. На фото ниже уже препарированный экран, в нижней части частично отделена пленка от основания и видна стеклянная подложка:



По моему опыту есть два вида дисплеев, отличающихся клеевой основой для удержания пленки на подложке. Принципиально они ничем не отличаются, разве что при препарировании клей может либо остаться на основе, либо отделиться вместе с пленкой. В моем случае клей остался на пленке. На фото ниже, обратная сторона пленки покрыта темно-оранжевым клеем. Его тоже желательно удалить, это увеличит контрастность в конечном устройстве.



Клей отделяется как тончайшая, гибкая но довольно хрупкая пленка, обнажая слой с чернилами. Тут важна аккуратность, поскольку чернила легко можно смазать прикосновением пальца. Более того, их можно просто смыть водой.

Итак, мы сняли активный слой с чернилами. Что дальше? Опять теория. Как я уже писал выше, пиксели начинают активничать при приложении к ним электрического поля. Стеклянная подложка представляет собой матрицу из огромного числа обкладок конденсатора, где одна обкладка один пиксель. Второй обкладкой служит прозрачный токопроводящий слой на защитной пленке. Таким образом, изменяя полярность на обкладках конденсатора, происходит изменение цвета пикселя.
А теперь сама суть. Подложка у нас не рабочая, но ничего не мешает нам самим изготовить ту самую подложку, вытравив на текстолите пиксели и подключив их да хоть к ардуине и таки собрать очередной погодный информер с преферансом и барышнями. Вот прям информер я собирать не буду, для упрощения реализуем семисегментный дисплей, но суть та же. В теории это должно выглядеть примерно следующим образом:



Снова включаем воображение и представляем, что это текстолит с вытравленным рисунком семисегментного индикатора. Оранжевые участки это обкладки конденсатора. Синяя рамка это зона, где расположен наш дисплей. Прямоугольник слева нужен для контакта с токопроводящим слоем дисплея, посредством которого и будет создаваться разность потенциалов. Из схемы видно, что каждый сегмент дисплея управляется отдельным контактом. Arduino UNO, на котором мы и построим устройство, имеет достаточно контактов для реализации двухразрядного индикатора. Я решил исполнить устройство в виде шилда и после разводки получил примерно такой рисунок:


Верхняя и нижняя стороны

Синим обозначен контакт для второй обкладки конденсатора, его мы соединим с токопроводящим слоем пленки. Я их по ошибке развел на разные контакты Arduino, но тут достаточно одного. Белые сегменты индикатора соединяются с контактами Arduino с противоположной стороны платы. Зеленая область нужна для очистки остаточного изображения на дисплее. Суть в том, что если мы будем изменять напряжение только на сегментах, то, в случае если мы сняли экран с остаточным изображением, то оно у нас так и останется в тех местах, где НЕ будет приложено напряжение между обкладками. То есть везде вне сегментов. Если же у нас экран был чист, то они и не нужны. Под экраном я развел контакты для кнопок управления, но впоследствии решил их не распаивать. Плату изготавливал классическим способом через фоторезист.

Пару фото:

Верхняя и нижняя сторона заготовки. Фоторезист пленочный, наносил при помощи ламинатора. Маски распечатал на прозрачной пленке лазерным принтером. Лежат по бокам. Засвечивал матрицей УФ светодиодов.



Обратная сторона:



Не засвеченный фоторезист смывал обычным стиральным порошком:



Травил в хлорном железе:



Остатки фоторезиста легко смываются ацетоном:



Теперь необходимо соединить сегменты индикатора, с обратной стороной платы. Я использовал обычные проволочные перемычки, после чего зачистил шкуркой верхнюю сторону платы:



Исключительно ради удобства решил нанести на плату паяльную маску на верхнюю сторону. Использовал двухкомпонентную зеленую.

Для начала креплю заготовку на устойчивое основание на малярный скотч:



Наносить маску буду через трафаретный шелк, натянутый на деревянную фоторамку:



Замешав пасту, наношу ее прямо поверх шелка и продавливаю пластиковым шпателем:





В результате получаем более-менее однородный и ровный слой маски:



Далее все это дело сушу 15 минут в коробке из-под обуви, с воткнутым в нее термофеном, и выставленной температурой в 150 градусов. Затем засвечиваю пасту ультрафиолетом через маску, распечатанную на все том же лазерном принтере и смываю стиральным порошком. Результат ниже:



Как видим, открытыми для дисплея остаются участки с сегментами и контактные площадки по бокам для верхней обкладки конденсатора.

Теперь займемся дисплеем. Поскольку он выполнен на полимерной пленке, нужную форму легко вырезать ножницами:



На дисплее сохранилось остаточное изображение, для этого и использовал дополнительный полигон вокруг сегментов. Стоит обратить внимание, что по бокам я снял слой чернил, эти открытые площадки нужны для контакта с полигонами верхней обкладки конденсатора. Тут надо заострить внимание на некоторых особенностях. Как я писал выше, пленка у меня снялась вместе с клеевой основой. Первый вариант клеил к плате вместе с этим клеем и для того, чтобы оголить участки по бокам, может возникнуть желание канцелярским ножом отрезать эти участки клея и затем их механически удалить. Но токопроводящее покрытие на пленке очень тонкое и даже легкий разрез легко его повреждает, в результате у нас будет отсутствовать контакт между участками экрана. На фото ниже образец поврежденного таким образом дисплея:



Тут мы видим, что клеевой слой я удалил вместе со слоем чернил, но прозвонка между боковыми контактами показала бесконечное сопротивление. Во втором варианте я удалил клеевой слой и просто смыл влажной салфеткой чернила с боковых контактов. Сам дисплей приклеил к плате на ту же пасту что и использовал для создания зеленой маски на плате. Затем несколько раз прогнал плату через ламинатор, засветил УФ светодиодами и распаял контакты для Aarduino:



Для улучшения контакта дисплея с боковыми площадками, я подложил между дисплеем и контактами на плате кусочки фольги и затем дополнительно покрыл все скотчем:



Теперь можно воткнуть шилд в Arduino и набросать скетч. Тут важно понимать, что при смене изображения, весь экран для начала нужно очищать, а потом выводить новое изображение.

Собственно, видео того, что получилось в результате. Идет счет от 1 до 99 в цикле.



На видео видно, что смена изображения идет через черный и затем белый экран, но как показала практика, от черного экрана можно отказаться, хотя в этом случае очищает немного лучше.

Здесь можно скачать PSD с разведенной платой и скетч.

Послесловие

Какие выводы можно сделать из данного эксперимента?

Во-первых, технология не так сложна, как кажется на первый взгляд и вполне годна для использования в домашних поделках.

Во-вторых, убитая читалка это вовсе не повод ее отправлять на мусорку.

И самое вкусное очевидно, что радиолюбитель может не ограничиваться теми средствами вывода информации, которые нам предоставляет производитель. Мы имеем возможность самостоятельно изготовить дисплей любой формы и нужного нам размера. Более того, я уже экспериментировал с нанесением дисплея на гибкую печатную плату, небольшой тизер:



На фото выше, прототип наручных часов, изготовленный на гибкой печатной плате.

А теперь скромно озвучу свои наполеоновские планы. В этой статье можно прочесть о технологии изготовления электронных чернил. Принципиальных сложностей там нет. Есть мысль упростить и попробовать повторить самостоятельно.

P.S. Если будет интерес, запилю статью с поэтапным изготовлением наручных часов на гибкой печатной плате с самодельным экраном E-ink.



Спасибо за просмотр ;)

---

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Аудит (здесь и далее слово аудит употребляется в значении оценка качества) CSS не относится к повседневным задачам при разработке веб-приложений, но иногда приходится этим заниматься. Это может быть частью процесса определения критического CSS, удаления неиспользуемых селекторов, улучшения доступности, когда все цвета в кодовой базе оцениваются на предмет контрастности, и т.д.

Существуют некоторые инструменты, облегчающие выполнение указанных задач. Но давайте начнем с того, что понимается под аудитом CSS.

Аудит CSS задача не из легких

Как правило, оценка качества кода включает в себя его анализ в поиске багов и других проблем, например, проблем с производительностью. Для большинства языков программирования концепция аудита кода проста: она работает или не работает. Но CSS это особенный язык, большая часть ошибок которого игнорируется браузером. Один и тот же стиль можно применять совершенно по-разному. Это обуславливает сложность аудита CSS. И сложность это еще мягко сказано.

Для обнаружения проблем с CSS мы можем использовать расширения в нашем любимом редакторе кода или какой-нибудь линтер. Однако, подчас этого бывает недостаточно. Мы по-прежнему будем иметь возможность использовать слишком большое количество цветов, определений шрифтов или z-index, что сделает CSS плохо поддерживаемым и нестабильным.

Для настоящего аудита CSS нам необходимо погрузиться гораздо глубже с целью обнаружения блоков кода, которые считаются плохой практикой. Для обнаружения таких мест мы можем использовать следующие инструменты.

Инструменты разработчика в браузере

Давайте взглянем на инструменты разработчика для аудита CSS, предоставляемые барузером Google Chrome.

Для ручной проверки CSS существует инструмент Inspect (стрелка в квадрате в верхнем левом углу). С его помощью мы можем увидеть CSS, примененный к определенному элементу. А с помощью стрелки можно получить детальную информацию о цветах, шрифтах, размере и доступности.

Инспектор Grid и Flex

Интерфейс DevTools предоставляет много интересных возможностей, но моей любимой является инспектор Grid и Flex. Для того, чтобы его включить, необходимо перейти в настройки (шестеренка в верхнем правом углу), выбрать Experiments и Enable new CSS Flexbox debugging features.

Данный инструмент можно использовать как для отладки проблем с макетом, так и просто для определения того, используется ли CSS Grid или Flexbox на странице.

CSS Overview

Инспектирование CSS позволяет получить базовую информацию об используемом на странице CSS. Рассмотрим более продвинутые инструменты разработчика.

Одним из таких инструментов является CSS Overview. Для его включения необходимо перейти в настройки, выбрать Experiments и CSS Overview. Для открытия панели CSS Overview можно нажать Ctrl/Cmd+Shift+P, ввести css overview, выбрать Show CSS Overview и нажать Capture overview. Данный инструмент суммирует CSS-свойства, такие как цвета, шрифты, проблемы с контрастностью, неиспользуемые объявления и медиа-запросы. Я, обычно, использую этот инструмент для получения общего представления о качестве CSS. Например, если на странице используется 50 оттенков серого или слишком много определений шрифтов, это может свидетельствовать об отсутствии какого бы то ни было руководства по стилю.

Coverage panel

Инструмент Coverage (покрытие) показывает общее количество и процент кода, используемого на странице. Для его запуска следует нажать Ctrl/Cmd+Shift+P, ввести coverage, выбрать Show Coverage и нажать на иконку обновления.

Для фильтрации CSS-файлов нужно ввести ".css" в URL filter input. Обычно, я использую этот инструмент для понимания техники CSS, используемой на сайте. Например, если я вижу высокую степень покрытия, я могу предположить, что CSS-файл генерируется для каждой страницы в отдельности. Иногда это также помогает определить применяемую на сайте стратегию кэширования.

Rendering panel

Панель Rendering (рендеринг) другой полезный инструмент. Для его использования снова нажимаем Ctrl/Cmd+Shift+P, вводим rendering, выбираем Show Rendering. У этого инструмента много настроек, но моими любимыми являются следующие:

• Paint flashing показывает зеленые прямоугольники во время перерисовки. Может использоваться для определения областей, повторная отрисовка которых занимает слишком много времени
• Layout Shift Regions показывает синие прямоугольники при смещении (сдвиге) макета. Для того, чтобы получить максимальную пользу от этой настройки, я устанавливаю Slow 3G во вкладке Network. Иногда я записываю экран и смотрю видео в замедленном режиме для обнаружения сдвигов макета
• Frame Rendering Stats показывает использование GPU и фреймов в режиме реального времени. Эта настройка помогает обнаружить проблемы с анимацией и прокруткой

Я не слишком часто использую рассматриваемый инструмент, но он иногда может быть полезен для выявления проблем с производительностью и связанного с этим расхода заряда батареи устройства пользователя.

Другие настройки, такие как эмуляция и отключение определенных возможностей, включение prefers-color-scheme или медиа-типа для печати или отключение локальных шрифтов, на мой взгляд, являются менее полезными.

Инструменты разработчика помогают понять, какие возможности CSS используются на странице, насколько эффективно они используются и каково их влияние на производительность. Разумеется, ими аудит CSS далеко не исчерпывается.

Онлайн-инструменты

Specificity Visualizer

Specificity Visualizer показывает специфичность CSS-селекторов. Для его использования достаточно зайти на сайт, вставить CSS и нажать Visualize it!.

Основной график показывает специфичность в зависимости от нахождения таблицы со стилями. Два других графика показывают правильное использование специфичности. Я часто использую этот инструмент для обнаружения плохих селекторов. Например, если я вижу много красных точек, значит, мой код не так хорош, как я думал. Проанализируем основной файл со стилями Хабра:

CSS Specificity Graph Generator

CSS Specificity Graph Generator это похожий инструмент для визуализации специфичности. Он показывает немного другой график, позволяющий определить, как наши селекторы организованы с точки зрения специфичности. Общее правило гласит, что селекторы с большей специфичностью в таблице стилей должны указываться позже, чем селекторы с меньшей специфичностью.

CSS Stats

CSS Stats еще один инструмент для анализа и визуализации таблиц стилей.

Все, что нужно сделать, это ввести адрес сайта и нажать Enter. Информация разделяется на логические секции, такие как количество цветов, шрифты, z-index, специфичность и т.д. Можно сделать скриншот для последующего сравнения.

Project Wallace

Одной из главных особенностей Project Wallace является то, что данный инструмент позволяет сравнивать и визуализировать изменения на основе импортов. Это означает, что мы можем видеть разницу между предыдущим и текущим состояниями нашего CSS. Это может быть очень полезным для демонстрации улучшения кодовой базы.

Инструменты CLI

Wallace

Одним из моих любимых инструментов (интерфейсов) командной строки является Wallace. После установки, введите wallace и название сайта. В терминал будет выведено все необходимое, что нужно знать о CSS, используемом на указанном сайте. Например, можно посмотреть, сколько раз используется !important или сколько id встречается в коде. Плохой код отмечается красным цветом.

Что мне нравится в этом инструменты, так это то, что он извлекает весь CSS, используемый на сайте, т.е. не только из внешних файлов, но также встроенный. Вот почему отчеты CSS Stats и Wallace не совпадают. Для работы Wallace требуется Python.

csscss

CLI csscss показывает, какие правила являются распределенными (совместно используемыми). Это может быть полезным для определения дублирующегося кода, что позволяет избавиться от такого кода, уменьшив общий размер кодовой базы. Для сайтов, использующих правильные механизмы кэширования, данная проблема не слишком актуальна. Для работы csscss требуется Ruby.

Другие полезные инструменты

• Color Sorter сортирует цвета по сначала по оттенку, затем по насыщенности
• CSS Analyzer анализирует строку CSS
• constyble линтер для определения сложности CSS, основанный на CSS Analyzer
• Extract CSS получение всего CSS, используемого на странице
• Get CSS альтернатива Extract CSS
• uCSS определение неиспользуемого CSS

Заключение

Ни один веб-проект не обходится без CSS. Поэтому его качеству следует уделять самое пристальное внимание. Не столь важно, что другие люди думают о вашем CSS, сколько то, что вы сами о нем думаете. Если ваш CSS хорошо написан и правильно организован, вы будете тратить меньше времени на его отладку и больше на разработку новых фич.

Я понимаю, что аудит CSS может быть очень скучным и утомительным занятием. Однако, если вы попробуете хотя один инструмент из указанных в данной статье, и этот инструмент поможет сделать ваш CSS лучше, значит, мои усилия были не напрасны.

А какие инструменты для аудита CSS вы используете в своей работе? Дайте знать в комментариях.

---

Облачные серверы от Маклауд идеально подходят для разработки и хостинга сайтов.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Недавно мне довелось побеседовать с разработчикомThunderbirdо проектировании API. В ходе этой беседы я поделился соображениями о RNP,новой реализации OpenPGP, которую Thunderbird недавно стал использовать вместо GnuPG.

Собеседник скептически отнесся к моему тезису о том, что API RNP нуждается в улучшении, и спросил, разве это не субъективно какие API лучше, а какие хуже?. Согласен, у нас нет хороших метрик для оценки API. Но не соглашусь, что мы в принципе не в силах судить об API.

На самом деле, подозреваю, что большинство опытных программистов узнают плохой API, если увидят его. Думаю, далее в этой статье получится разработать хорошую эвристику, которую я попытаюсь выстроить на моем собственном опыте работы с (и над) GnuPG,Sequoia и RNP. Затем я рассмотрю API RNP. К сожалению, этот API не только можно запросто использовать неправильно он к тому же обманчив, поэтому пока его не следует использовать в контекстах, где принципиальная роль отводится соблюдению безопасности. Но целевая аудитория Thunderbird это люди, известные своей уязвимостью, в частности, журналисты, активисты, юристы и их партнеры, отвечающие за коммуникацию; все эти люди нуждаются в защите. На мой взгляд, это означает, что в Thunderbird должны лишний раз подумать, стоит ли использовать RNP.

Примечание: также предлагаю ознакомиться с этим электронным письмом:Lets Use GPL Libraries in Thunderbird!, которое я отправилв постовую рассылку по планированию развития Thunderbird.

Каковы черты плохого API?

Прежде, чем мы вместе с Юстусом и Каем приступили к проектуSequoia, мы все втроем работали над GnuPG. Мы не только сами копались в gpg, но и беседовали, и сотрудничали со многими последующими пользователями gpg. Люди смогли сказатьмного хорошего по поводу GnuPG.


Что касается критикиgpg, наиболее значительными нам показались два вида замечаний по поводу API. Первое сводится к следующему: API gpg слишком догматичен. Например, вgpgприменяется подход, основанный на использовании личной базы ключей (keyring). Таким образом, просмотреть или использовать сертификат OpenPGP можно лишь в том случае, если он импортирован в личную базу ключей. Но некоторые разработчики желают сначала просмотреть сертификат, и лишь потом импортировать его. Например, при поиске сертификата на сервере ключей по его отпечатку, можно проверить и убедиться, что возвращенный сертификат действительно тот, что нужен, поскольку его URL является самоаутентифицируемым. Это можно сделать при помощи gpg, но только обходным путем, огибая принципы той модели программирования, которая в него заложена. Базовая идея такова: создать временный каталог, добавить в него конфигурационный файл, приказать gpgиспользовать альтернативный каталог, импортировать туда сертификат, проверить сертификат, после чего очистить временный каталог. Это официальная рекомендация, добавленнаяЮстусомна основе наших бесед с последующими пользователями gpg. Да, этот метод работает. Но для него требуется писать код, специфичный для операционной системы, этот код медленный, и в нем часто заводятся ошибки.

Другой класс замечаний, с которыми мы сталкивались неоднократно, заключается в том, что для работы с gpgтребуется знать массу неочевидных вещей чтобы не злоупотреблять этим механизмом. Или, выражаясь иначе, нужно проявлять крайнюю осмотрительность при использовании APIgpg, чтобы ненароком не привнести в код уязвимость.

Чтобы лучше понять второй повод для беспокойства, рассмотрим уязвимости EFAIL. Основная проблема, связанная с API дешифрования gpg: при дешифровании сообщенияgpgвыдает обычный текст, даже если ввод был поврежден.gpgв таком случае действительно возвращает ошибку, но некоторые программы все равно выводят обычный текст в поврежденном виде. Так как, почему нет? Определенно, лучше показать хотя бы часть сообщения, чем не показать ничего, верно? Так вот, уязвимости EFAIL демонстрируют, как злоумышленник может этим воспользоваться, чтобы внедрить веб-багв зашифрованное сообщение. Когда пользователь просматривает это сообщение, веб-баг просачивается из сообщения. Уф.

Итак, на чьей совести этот баг? РазработчикиGnuPGнастаивали, чтопроблема на уровне приложений, в том, что они используют gpgнеправильно:

Рекомендуется, чтобы в почтовых пользовательских агентах учитывался код состояния DECRYPTION_FAILED, и не отображались данные, либо, как минимум, подбирался уместный способ для отображения потенциально поврежденной почты, не создавая оракул и информируя пользователя о том, что почта не внушает доверия.

gpgпросигнализировала об ошибке; приложения не соблюдают контракт API. Должен согласиться с разработчиками GnuPG и добавить: интерфейсgpg был (и остается) бомбой замедленного действия, поскольку не подсказывает пользователю, как действовать правильно. Напротив, легкое и, казалось бы, полезное действие является неверным. ИAPI такоготипа, к сожалению, обычны в GnuPG.

Из чего слагается хороший API?

Осознание двух этих вещей что APIgpg слишком догматичен, и что им сложно пользоваться как следует сформировало мои планы. Когда мы приступили к проекту Sequoia, мы сошлись на том, что подобных ошибок хотим избежать. Основываясь на наблюдениях, мы ввели в практику два теста, которыми продолжаем пользоваться в качестве ориентиров при разработке API Sequoia. Во-первых,дополнительно к любому высокоуровневому API должен существовать и низкоуровневый, который не догматичен в том смысле, что не мешает пользователю делать что-либо, что не запрещено. В то же время,API должен наводить пользователя на верные (жестко прописанные) вещи, делая так, чтобы правильные действия были просты в исполнении и наиболее очевидны при выборе действия.

Для воплощения двух этих слегка конфликтующих целей сделать возможным всё, но предотвратить ошибки, мы особенно активно опирались на два средства: типы и примеры. Благодаря типам, становится сложно использовать объект непредусмотренным образом, так как контракт API формализуется во время компиляции и даже навязывает конкретные преобразования. Примеры же фрагменты кода будуткопироваться. Поэтому, хорошие примеры не только приучат пользователей правильно обращаться с функцией, но и сильно повлияют на то, как именно они будут ее использовать.

Типы

Покажу на примере, как мы используем типы в Sequoia, и как они помогают нам сделать хороший API. Чтобы пример был понятнее, полезно будет напомнить некоторый контекст, касающийся OpenPGP.


Простой сертификат OpenPGP

В OpenPGP существует несколько фундаментальных типов данных, а именно: сертификаты, компоненты (например, ключи и пользовательские ID), а также подписи привязки. Корень сертификата это первичный ключ, полностью определяющий отпечаток сертификата (fingerprint = Hash(primary key)). В состав сертификата обычно входят такие компоненты как подключи и пользовательские ID. OpenPGP привязывает компонент к сертификату при помощи так называемой подписи привязки. Когда мы используем в качестве отпечатка обычный хеш первичного ключа и используем подписи для привязки компонентов к первичному ключу, создаются условия, чтобы впоследствии можно было добавить и дополнительные компоненты. В состав подписей привязки также входят свойства. Поэтому есть возможность изменить компонент, например, продлить срок действия подключа. Вследствие этого с конкретным компонентом может быть ассоциировано несколько действительных подписей. Подписи привязки являются не только фундаментальной, но и неотъемлемой частью механизма безопасности OpenPGP.

Поскольку может существовать множество действительных подписей привязки, требуется способ выбирать из них нужную. В качестве первого приближения предположим, что нужная нам подпись самая недавняя, неистекшая, неотозванная действительная подпись, создание которой не отложено на будущее. Но что такое действительная подпись? В Sequoia подпись должна не только пройти математическую проверку, но и согласовываться с политикой. Например, в силу противодействия скомпрометированным коллизиям, мыдопускаем SHA-1 только в очень небольшом количестве ситуаций. (Пол Шауб, работающий надPGPainless, недавноподробно написал об этих сложностях.) Вынуждая пользователя API держать в уме все эти соображения, мы создаем почву для уязвимостей. В Sequoia легкий способ получить время истечения это безопасный способ. Рассмотрим следующий код, который работает как надо:

let p = &StandardPolicy::new(); let cert = Cert::from_str(CERT)?;for k in cert.with_policy(p, None)?.keys().subkeys() {    println!("Key {}: expiry: {}",             k.fingerprint(),             if let Some(t) = k.key_expiration_time() {                 DateTime::<Utc>::from(t).to_rfc3339()             } else {                 "never".into()             });}

cert это сертификат. Начинаем с применения политики к нему. (Политики определяются пользователем, но, как правило,StandardPolicyне только достаточна, но и наиболее уместна). Фактически здесь создается представление сертификата, в котором видны только компоненты с действительной подписью привязки. Важно, что она также изменяет и предоставляет ряд новых методов. Метод keys, к примеру, изменен так, что возвращаетValidKeyAmalgamationвместоKeyAmalgamation. (Это слияние, так как результат включает не только Key, но и все подписи, связанные с ним; некоторые считают, что этот процесс было бы удачнее назвать Катамари.\_()_/) УValidKeyAmalgamationесть действительная подпись привязки, согласно вышеприведенным критериям. А также предоставляет такие методы как key_expiration_time, что имеет смысл только с действительным ключом! Также отметим: возвращаемый тип, используемый сkey_expiration_time, эргономичен. Вместо того, чтобы возвращать необработанное значение, key_expiration_timeвозвращает SystemTime, безопасный и удобный в работе.

В соответствии с нашим первым принципом позволить использовать все, разработчик по-прежнему сохраняет доступ к единичным подписям иисследует субпакеты, чтобы узнать из иной привязки подписи, когда истекает срок действия ключа. Но, по сравнению с тем, как в API Sequoia положено правильно узнавать срок истечения действия ключа, любой иной подход противоречил бы API. По нашему мнению, это хороший API.

Примеры

Релиз 1.0библиотеки Sequoia состоялся в декабре 2020 года. За девять месяцев до того мы вышли на ситуацию полной работоспособности (feature complete) и были готовы к релизу. Но выжидали. Следующие девять месяцев ушли у нас на добавление документации и примеров к публичному API. Посмотрите документацию к структуре данныхCertв качестве примера, посмотрите, что у нас получилось. Как указано в нашем посте, нам не удалось предоставить примеры для всех функций до одной, но мы успели довольно много. В качестве бонуса к написанию примеров мы также успели найти несколько шероховатостей, которые при этом отполировали.

После релиза нам удалось пообщаться со многими разработчиками, включившими Sequoia в свой код. Красной нитью через их отзывы проходили признания в том, насколько полезны оказались и документация, и примеры. Можем подтвердить: хотя это и наш код, мы заглядываем в документацию практически ежедневно и копируем наши собственные примеры. Так проще. Поскольку в примерах показано, как правильно использовать ту или иную функцию, зачем переделывать работу с нуля?

API RNP

RNP это свежая реализация OpenPGP, разработанная преимущественно Ribose. Примернодва года назад в Thunderbird решили интегрироватьEnigmailв Thunderbird и одновременно с этимзаменить GnuPG на RNP. Тот факт, что в Thunderbird выбрали RNP не только лестен для RNP; он также означает, что RNP стал, пожалуй, самой востребованной реализацией OpenPGP для шифрования почты.

Критику легко воспринять как негатив. Я хочу совершенно однозначно высказаться: думаю, что работа, которую делают в Ribose, хороша и важна, я благодарен им за то, что они вкладывают время и силы в новую реализацию OpenPGP. В экосистеме OpenPGP отчаянно требуется добавить разнообразия. Но это не оправдание за выпуск незрелого продукта для использования в контексте, где безопасность критически важна.

Инфраструктура с критически важными требованиями к безопасности

К сожалению, RNP пока не дошла до состояния в котором, на мой взгляд, ее можно безопасно развертывать. Enigmail пользовались не только люди, озабоченные приватностью своих данных, но и журналисты, активисты и адвокаты, которым важна собственная безопасность и безопасность их собеседников. В интервью, данном в 2017 году, Бенджамин Исмаил, глава Азиатско-Тихоокеанского отделения организации Репортеры без границ, сказал:

В основном мы используем GPG для свободной коммуникации с нашими источниками. Информация, которую они сообщают нам о правах человека и нарушениях этих прав небезопасна для них, поэтому необходимо защищать неприкосновенность наших разговоров.

Интервью с Бенджамином Исмаиломиз организацииРепортеры без границ

Принципиально важно, чтобы Thunderbird и далее обеспечивала этих пользователей максимально безопасными возможностями работы, даже в такой переходный период.

RNP и подписи привязки подключа

Говоря о том, как мы используем типы в Sequoia для того, чтобы усложнить неправильное использование API, я показал, как узнать срок истечения действия ключа, написав всего несколько строк кода. Хотел начать с примера, демонстрирующего человеку, неискушенному в OpenPGP или RNP, как тот же самый функционал можно реализовать при помощи RNP. Следующий код перебирает подключи сертификата (key) и выводит на экран срок истечения действия каждого подключа. Напоминаю: время истечения действия хранится в подписи привязки подключа, а значение 0свидетельствует, что срок действия ключа не истечет никогда.

int i;for (i = 0; i < sk_count; i ++) {  rnp_key_handle_t sk;  err = rnp_key_get_subkey_at(key, i, &sk);  if (err) {    printf("rnp_key_get_subkey_at(%d): %x\n", i, err);    return 1;  }   uint32_t expiration_time;  err = rnp_key_get_expiration(sk, &expiration_time);  if (err) {    printf("#%d (%s). rnp_key_get_expiration: %x\n",           i + 1, desc[i], err);  } else {    printf("#%d (%s) expires %"PRIu32" seconds after key's creation time.\n",           i + 1, desc[i],           expiration_time);  }}

Я проверил этот код на сертификате с пятью подключами. Первый подключ имеет действительную подпись привязки и не истекает; второй имеет действительную подпись привязки и в будущем истекает; у третьего действительная подпись привязки, но срок его действия уже истек; у четвертого недействительная подпись привязки, согласно которой срок действия подключа истекает в будущем; у пятого подписи привязки нет вообще. Вот вывод:

#1 (doesn't expire) expires 0 seconds after key's creation time.#2 (expires) expires 94670781 seconds after key's creation time.#3 (expired) expires 86400 seconds after key's creation time.#4 (invalid sig) expires 0 seconds after key's creation time.#5 (no sig) expires 0 seconds after key's creation time.

Первым делом отмечаем, что вызов rnp_key_get_expirationоканчивается успешно, независимо от того, есть ли у подключа действительная подпись привязки, либо недействительная подпись привязки, либо вообще нет подписи привязки. Если почитатьдокументацию, то это поведение кажется немного удивительным. Там сказано:

Получить время истечения срока действия ключа в секундах.Обратите внимание: 0 означает, что ключ не истечет никогда.

Поскольку время истечения срока действия ключа сохранено в подписи привязки, я, эксперт по OpenPGP, понимаю это так: вызов кrnp_key_get_expirationувенчается успехом лишь в том случае, если у подключа есть действительная подпись привязки. На самом же деле оказывается, что, если действительная подпись привязки отсутствует, то функция просто принимает по умолчанию значение 0, что, учитывая вышеприведенное замечание, пользователь API ожидаемо интерпретирует так: данный ключ действует бессрочно.

Чтобы улучшить этот код, сначала необходимо проверить, есть ли у ключа действительная подпись привязки. Некоторые функции, делающие именно это, недавно были добавлены в RNP для решения проблемыCVE-2021-23991. В частности, разработчики RNP добавили функциюrnp_key_is_valid, чтобы возвращать информацию о том, действителен ли ключ. Это дополнение улучшает ситуацию, но требует от разработчика явно выбирать, должны ли проводиться эти критичные для безопасности проверки (а не явно отказываться от уже заданных проверок как было бы в случае работы с Sequoia). Поскольку проверки безопасности не относятся к выполнению полезной работы, о них легко забыть: код работает, даже если проверка безопасности проведена не была. А поскольку чтобы правильно выбрать, что проверять, нужны экспертные знания, о проверках забывают.

Следующий код предусматривает проверку безопасности и пропускает любые ключи, которые rnp_key_is_validсочтет недействительными:

int i;for (i = 0; i < sk_count; i ++) {  rnp_key_handle_t sk;  err = rnp_key_get_subkey_at(key, i, &sk);  if (err) {    printf("rnp_key_get_subkey_at(%d): %x\n", i, err);    return 1;  }   bool is_valid = false;  err = rnp_key_is_valid(sk, &is_valid);  if (err) {    printf("rnp_key_is_valid: %x\n", err);    return 1;  }   if (! is_valid) {    printf("#%d (%s) is invalid, skipping.\n",           i + 1, desc[i]);    continue;  }   uint32_t expiration_time;  err = rnp_key_get_expiration(sk, &expiration_time);  if (err) {    printf("#%d (%s). rnp_key_get_expiration: %x\n",           i + 1, desc[i], err);  } else {    printf("#%d (%s) expires %"PRIu32" seconds after key's creation time.\n",           i + 1, desc[i],           expiration_time);  }}

Вывод:

#1 (doesn't expire) expires 0 seconds after key's creation time.#2 (expires) expires 94670781 seconds after key's creation time.#3 (expired) is invalid, skipping.#4 (invalid sig) is invalid, skipping.#5 (no sig) is invalid, skipping.

Этот код правильно пропускает два ключа, не имеющих действительной подписи привязки, но он также пропускает и истекший ключ пожалуй, не этого мы хотели, пусть документация нас и предупреждает, что эта функция проверяет сроки истечения.

Хотя бывает и так, что мы не хотим использовать тот ключ или сертификат, срок действия которого истек, иногда мы к ним прибегаем. Например, если пользователь забудет продлить срок действия ключа, то у него должна быть возможность увидеть, что ключ истек, и тогда проверить сертификат, а также продлить в таком случае срок действия ключа. Хотя gpg --list-keysне показывает истекшие ключи, при редактировании сертификата все-таки видны истекшие подключи, так, чтобы пользователь мог продлить срок их действия:

$ gpg --edit-key 93D3A2B8DF67CE4B674999B807A5D8589F2492F9Secret key is available.sec ed25519/07A5D8589F2492F9created: 2021-04-26 expires: 2024-04-26 usage: Ctrust: unknown    validity: unknownssb ed25519/1E2F512A0FE99515created: 2021-04-27 expires: never    usage: Sssb cv25519/8CDDC2BC5EEB61A3created: 2021-04-26 expires: 2024-04-26 usage: Essb ed25519/142D550E6E6DF02Ecreated: 2021-04-26 expired: 2021-04-27 usage: S[ unknown] (1). Alice <alice@example.org>

Есть и другие ситуации, в которых истекший ключ не должен считаться недействительным. Предположим, например, что Алиса посылает Бобу подписанное сообщение: я заплачу тебе 100 евро за год, а срок действия ключа подписи истекает через полгода. Когда год закончится, будет ли Алиса должна Бобу, если исходить из этой подписи? По-моему, да. Подпись была действительна, когда ставилась. Тот факт, что срок действия ключа уже истек, не имеет значения. Разумеется, когда ключ истек, подписи, скрепленные им после момента его истечения, должны считаться недействительными. Аналогично, сообщение не следует шифровать истекшим ключом.

Короче говоря, то, должен ли ключ считаться действительным, сильно зависит от контекста.rnp_key_is_validлучше, чем ничего, но, несмотря на название, эта функция предусматривает достаточно нюансов при определении того, действителен ли ключ.

В рамках того же коммита была добавлена вторая функция,rnp_key_valid_till. Эта функция возвращает метку времени, до наступления которого ключ может считаться действительным Если ключ никогда не был действителен, то в качестве значения возвращается ноль. При помощи этой функции можно определить, был ли ключ действителен когда-либо, для этого нужно проверить, возвращает ли эта функция ненулевое значение:

int i;for (i = 0; i < sk_count; i ++) {  rnp_key_handle_t sk;  err = rnp_key_get_subkey_at(key, i, &sk);  if (err) {    printf("rnp_key_get_subkey_at(%d): %x\n", i, err);    return 1;  }   uint32_t valid_till;  err = rnp_key_valid_till(sk, &valid_till);  if (err) {    printf("rnp_key_valid_till: %x\n", err);    return 1;  }   printf("#%d (%s) valid till %"PRIu32" seconds after epoch; ",         i + 1, desc[i], valid_till);   if (valid_till == 0) {    printf("invalid, skipping.\n");    continue;  }   uint32_t expiration_time;  err = rnp_key_get_expiration(sk, &expiration_time);  if (err) {    printf("rnp_key_get_expiration: %x\n", err);  } else {    printf("expires %"PRIu32" seconds after key's creation time.\n",           expiration_time);  }}

Результаты:

#1 (doesn't expire) valid till 1714111110 seconds after epoch; expires 0 seconds after key's creation time.#2 (expires) valid till 1714111110 seconds after epoch; expires 94670781 seconds after key's creation time.#3 (expired) valid till 1619527593 seconds after epoch; expires 86400 seconds after key's creation time.#4 (invalid sig) valid till 0 seconds after epoch; invalid, skipping.#5 (no sig) valid till 0 seconds after epoch; invalid, skipping.

Теперь мы получили те результаты, которых добивались! Мы выводим на экран правильное время истечения для первых трех подключей, а также указываем, что последние два подключа недействительны.

Но давайте подробнее рассмотримrnp_key_valid_till. Во-первых, в OpenPGP время истечения ключа хранится как беззнаковый 32-разрядный отступ от времени создания ключа, также в беззнаковом 32-разрядном формате. Следовательно, функция должна была бы использовать более широкий тип или, как минимум, проверять код на переполнение. (Ясообщил об этой проблеме, и ее уже исправили.)

Но, даже если игнорировать этот косяк, функция все равно странная. В OpenPGP ключ может быть действителен в течение нескольких периодов времени. Допустим, срок действия ключа истекает 1 июля, а пользователь продлевает его только с 10 июля. В период с 1 по 10 июля ключ был недействителен, а подписи, сгенерированные в это время, также должны считаться недействительными. Итак, что же должна возвращать рассматриваемая функция для такого ключа? Гораздо важнее, как пользователь такого API должен интерпретировать результат? Уместно ли вообще использовать такой API? (Да, я спрашивал.)

В Sequoia мы пошли другим путем. Вместо того, чтобы возвращать информацию, что ключ действителен, мы переворачиваем ситуацию; пользователь API может спросить:действителен ли этот ключ в моментt. По нашему опыту, это все, что на самом деле требовалось во всех известных нам случаях.

Не подумайте, что я специально придираюсь именно к этой проблеме с API RNP. Это просто сложность, о которой я недавно размышлял. Когда мы заново реализовали API RNP, чтобы создать альтернативный бэкенд OpenPGPдля Thunderbird, мы столкнулисьсо многими подобными проблемами.

Заключение

Ошибки, допущенные разработчиками RNP, понятны и простительны. OpenPGP сложен, как и многие другие протоколы. Но его можно существенно упростить, если мы стремимся сохранить его гибкую и надежную ИОК, а не просто иметь инструмент для шифрования файлов.

Тем не менее, API RNP опасен. А Thunderbirdиспользуетсяв контекстах с критическими требованиями к безопасности. В интервью от 2017 годаМихал Рысьек Вознякиз Центра по исследованию коррупции и организованной преступности (OCCRP) четко сообщил, что на кону чьи-то жизни:

Я действительно категорически уверен, что, если бы мы не использовали GnuPG все это время, то многие наши информаторы и журналисты оказались бы в опасности или за решеткой

ИнтервьюсМихалом Рысьеком Вознякомиз Центра по исследованию коррупции и организованной преступности

Как это отразится на Thunderbird? Вижу три варианта. Во-первых, Thunderbird мог бы переключиться обратно на Enigmail. Можно подумать, что портирование Enigmail на Thunderbird 78 далось бы сложно, но я слышал от многих разработчиков Thunderbird, что это технически осуществимо вполне подъемными усилиями. Но одна из причин, по которым Thunderbird предпочла уйти от Enigmail огромное время, которое разработчикам Enigmail приходилось тратить, чтобы помочь пользователям правильно установить и сконфигурировать GnuPG. Поэтому такой путь неидеален.

Во-вторых, Thunderbird могла бы переключиться на иную реализацию OpenPGP. В наше время ихцелая кучана выбор. Лично я считаю, что Thunderbird следовало бы переключиться на Sequoia. Конечно же, я разработчик Sequoia, поэтому необъективен. Но дело здесь не в деньгах: мне платит фонд, а на свободном рынке мне предложили бы, пожалуй, вдвое больше, чем я зарабатываю сейчас. Я работаю ради того, чтобы защитить пользователей. Но, даже кроме API Sequoia и преимуществ реализации, Thunderbird в данном случае выигрывает и еще в одном отношении: мы уже заставили эту реализацию работать. Несколько недель назад мы выпустили Octopus, альтернативный бекенд OpenPGP для Thunderbird. У него не только функциональный паритет с RNP, но и есть ряд ранее недостававших фич, например, интеграция с gpg, а также залатаны некоторые бреши в безопасности и выполнено несколько нефункциональных требований.

В-третьих, Thunderbird мог бы вообще отказаться от использования OpenPGP. Такое решение меня не устраивает. Но несколько раз мне доводилось беспокоиться о безопасности наиболее уязвимых пользователей Thunderbird, и я считаю, что не предоставлять никакой поддержки OpenPGP вообще это решение, возможно, даже более безопасное, чем статус-кво.

---

VPS от Маклауд идеально подходят для разработки API.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Аудит (здесь и далее слово аудит употребляется в значении оценка качества) CSS не относится к повседневным задачам при разработке веб-приложений, но иногда приходится этим заниматься. Это может быть частью процесса определения критического CSS, удаления неиспользуемых селекторов, улучшения доступности, когда все цвета в кодовой базе оцениваются на предмет контрастности, и т.д.

Существуют некоторые инструменты, облегчающие выполнение указанных задач. Но давайте начнем с того, что понимается под аудитом CSS.

Аудит CSS задача не из легких

Как правило, оценка качества кода включает в себя его анализ в поиске багов и других проблем, например, проблем с производительностью. Для большинства языков программирования концепция аудита кода проста: она работает или не работает. Но CSS это особенный язык, большая часть ошибок которого игнорируется браузером. Один и тот же стиль можно применять совершенно по-разному. Это обуславливает сложность аудита CSS. И сложность это еще мягко сказано.

Для обнаружения проблем с CSS мы можем использовать расширения в нашем любимом редакторе кода или какой-нибудь линтер. Однако, подчас этого бывает недостаточно. Мы по-прежнему будем иметь возможность использовать слишком большое количество цветов, определений шрифтов или z-index, что сделает CSS плохо поддерживаемым и нестабильным.

Для настоящего аудита CSS нам необходимо погрузиться гораздо глубже с целью обнаружения блоков кода, которые считаются плохой практикой. Для обнаружения таких мест мы можем использовать следующие инструменты.

Инструменты разработчика в браузере

Давайте взглянем на инструменты разработчика для аудита CSS, предоставляемые барузером Google Chrome.

Для ручной проверки CSS существует инструмент Inspect (стрелка в квадрате в верхнем левом углу). С его помощью мы можем увидеть CSS, примененный к определенному элементу. А с помощью стрелки можно получить детальную информацию о цветах, шрифтах, размере и доступности.

Инспектор Grid и Flex

Интерфейс DevTools предоставляет много интересных возможностей, но моей любимой является инспектор Grid и Flex. Для того, чтобы его включить, необходимо перейти в настройки (шестеренка в верхнем правом углу), выбрать Experiments и Enable new CSS Flexbox debugging features.



Данный инструмент можно использовать как для отладки проблем с макетом, так и просто для определения того, используется ли CSS Grid или Flexbox на странице.

CSS Overview

Инспектирование CSS позволяет получить базовую информацию об используемом на странице CSS. Рассмотрим более продвинутые инструменты разработчика.

Одним из таких инструментов является CSS Overview. Для его включения необходимо перейти в настройки, выбрать Experiments и CSS Overview. Для открытия панели CSS Overview можно нажать Ctrl/Cmd+Shift+P, ввести css overview, выбрать Show CSS Overview и нажать Capture overview. Данный инструмент суммирует CSS-свойства, такие как цвета, шрифты, проблемы с контрастностью, неиспользуемые объявления и медиа-запросы. Я, обычно, использую этот инструмент для получения общего представления о качестве CSS. Например, если на странице используется 50 оттенков серого или слишком много определений шрифтов, это может свидетельствовать об отсутствии какого бы то ни было руководства по стилю.

Coverage panel

Инструмент Coverage (покрытие) показывает общее количество и процент кода, используемого на странице. Для его запуска следует нажать Ctrl/Cmd+Shift+P, ввести coverage, выбрать Show Coverage и нажать на иконку обновления.

Для фильтрации CSS-файлов нужно ввести ".css" в URL filter input. Обычно, я использую этот инструмент для понимания техники CSS, используемой на сайте. Например, если я вижу высокую степень покрытия, я могу предположить, что CSS-файл генерируется для каждой страницы в отдельности. Иногда это также помогает определить применяемую на сайте стратегию кэширования.

Rendering panel

Панель Rendering (рендеринг) другой полезный инструмент. Для его использования снова нажимаем Ctrl/Cmd+Shift+P, вводим rendering, выбираем Show Rendering. У этого инструмента много настроек, но моими любимыми являются следующие:

• Paint flashing показывает зеленые прямоугольники во время перерисовки. Может использоваться для определения областей, повторная отрисовка которых занимает слишком много времени
• Layout Shift Regions показывает синие прямоугольники при смещении (сдвиге) макета. Для того, чтобы получить максимальную пользу от этой настройки, я устанавливаю Slow 3G во вкладке Network. Иногда я записываю экран и смотрю видео в замедленном режиме для обнаружения сдвигов макета
• Frame Rendering Stats показывает использование GPU и фреймов в режиме реального времени. Эта настройка помогает обнаружить проблемы с анимацией и прокруткой

Я не слишком часто использую рассматриваемый инструмент, но он иногда может быть полезен для выявления проблем с производительностью и связанного с этим расхода заряда батареи устройства пользователя.

Другие настройки, такие как эмуляция и отключение определенных возможностей, включение prefers-color-scheme или медиа-типа для печати или отключение локальных шрифтов, на мой взгляд, являются менее полезными.



Инструменты разработчика помогают понять, какие возможности CSS используются на странице, насколько эффективно они используются и каково их влияние на производительность. Разумеется, ими аудит CSS далеко не исчерпывается.

Онлайн-инструменты

Specificity Visualizer

Specificity Visualizer показывает специфичность CSS-селекторов. Для его использования достаточно зайти на сайт, вставить CSS и нажать Visualize it!.

Основной график показывает специфичность в зависимости от нахождения таблицы со стилями. Два других графика показывают правильное использование специфичности. Я часто использую этот инструмент для обнаружения плохих селекторов. Например, если я вижу много красных точек, значит, мой код не так хорош, как я думал. Проанализируем основной файл со стилями Хабра:

CSS Specificity Graph Generator

CSS Specificity Graph Generator это похожий инструмент для визуализации специфичности. Он показывает немного другой график, позволяющий определить, как наши селекторы организованы с точки зрения специфичности. Общее правило гласит, что селекторы с большей специфичностью в таблице стилей должны указываться позже, чем селекторы с меньшей специфичностью.

CSS Stats

CSS Stats еще один инструмент для анализа и визуализации таблиц стилей.

Все, что нужно сделать, это ввести адрес сайта и нажать Enter. Информация разделяется на логические секции, такие как количество цветов, шрифты, z-index, специфичность и т.д. Можно сделать скриншот для последующего сравнения.

Project Wallace

Одной из главных особенностей Project Wallace является то, что данный инструмент позволяет сравнивать и визуализировать изменения на основе импортов. Это означает, что мы можем видеть разницу между предыдущим и текущим состояниями нашего CSS. Это может быть очень полезным для демонстрации улучшения кодовой базы.

Инструменты CLI

Wallace

Одним из моих любимых инструментов (интерфейсов) командной строки является Wallace. После установки, введите wallace и название сайта. В терминал будет выведено все необходимое, что нужно знать о CSS, используемом на указанном сайте. Например, можно посмотреть, сколько раз используется !important или сколько id встречается в коде. Плохой код отмечается красным цветом.

Что мне нравится в этом инструменты, так это то, что он извлекает весь CSS, используемый на сайте, т.е. не только из внешних файлов, но также встроенный. Вот почему отчеты CSS Stats и Wallace не совпадают. Для работы Wallace требуется Python.

csscss

CLI csscss показывает, какие правила являются распределенными (совместно используемыми). Это может быть полезным для определения дублирующегося кода, что позволяет избавиться от такого кода, уменьшив общий размер кодовой базы. Для сайтов, использующих правильные механизмы кэширования, данная проблема не слишком актуальна. Для работы csscss требуется Ruby.

Другие полезные инструменты

• Color Sorter сортирует цвета по сначала по оттенку, затем по насыщенности
• CSS Analyzer анализирует строку CSS
• constyble линтер для определения сложности CSS, основанный на CSS Analyzer
• Extract CSS получение всего CSS, используемого на странице
• Get CSS альтернатива Extract CSS
• uCSS определение неиспользуемого CSS

Заключение

Ни один веб-проект не обходится без CSS. Поэтому его качеству следует уделять самое пристальное внимание. Не столь важно, что другие люди думают о вашем CSS, сколько то, что вы сами о нем думаете. Если ваш CSS хорошо написан и правильно организован, вы будете тратить меньше времени на его отладку и больше на разработку новых фич.

Я понимаю, что аудит CSS может быть очень скучным и утомительным занятием. Однако, если вы попробуете хотя один инструмент из указанных в данной статье, и этот инструмент поможет сделать ваш CSS лучше, значит, мои усилия были не напрасны.

А какие инструменты для аудита CSS вы используете в своей работе? Дайте знать в комментариях.

---

Облачные серверы от Маклауд идеально подходят для разработки и хостинга сайтов.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

Люди сейчас новая нефть, и только ленивый не говорит о том, как важны soft skills.

Так было не всегда. Менеджмент как таковой в нашей стране появился только в девяностые. Жизнь тогда била ключом, страна менялась на глазах. Менялись и мы с друзьями: многие тогда начали управленческую карьеру.

Не всё было гладко. Интернета ещё не было, социальных сетей тоже. Приходилось читать много книг и периодики. К сожалению, западные методики на постсоветскую действительность так просто не ложились.

Мы с друзьями собирались на кухне, обсуждали попытки внедрения прочитанного и разбирали интересные случаи из практики. Это всё и сформировало наше общее видение мастерства управления.

Руководитель не может быть успешным без знания и умелого применения принципов, изложенных в базовых учебниках по экономике и менеджменту.

В основе основ

Есть великое множество отличных учебников по этим дисциплинам, но мы в своё время остановились на Практике менеджмента Питера Друкера и Экономикс Макконнелла и Брю. Так сложилось исторически.

Сразу замечу, что изложенные в этих трудах базовые принципы экономики и управления начинают работать в проектной деятельности только после обработки напильником. Но если эти принципы не знать, их приходится всякий раз изобретать заново.

Кстати, тема обработки напильником была блестяще раскрыта Тимоти Листером и Томом Демарко в книге Человеческий фактор: успешные проекты и команды. Затем последовал Deadline: роман об управлении проектами Демарко, самая светлая книга об управлении разработкой, которую я когда-либо читал.

А вот самая тёмная и мрачная: Смертельный марш Эдварда Йордана

Должен сказать, что чёткое понимание причин наших управленческих неудач к нам пришло только при разборе книги американского психиатра Эрика Бёрна Люди, которые играют в игры.

Оригинальное название книги дословно переводится: Что вы говорите после того, как поздоровались?. Основная идея книги это ритуалы и упорядочивание времени с помощью этих ритуалов.

В книге Бёрн вводит понятие жизненного сценария, который формируется родительским программированием, и даёт примеры таких сценариев на основе свой клинической практики. Там же вскользь упоминается Юнг с его архетипами, т.е. неким бессознательным содержанием, которое изменяется, становясь осознанным и воспринятым.

В примерах автор многократно подчёркивает, что ребёнок зачастую слышит в словах взрослых свой контекст, и что жизненный сценарий пациента можно определить по любимому герою сказки.

Примечательно, что особенностью архетипа является то, что он входит в сознание только тогда, когда соединяется с личным опытом. Мы решили проверить это на практике и замахнулись на святое, на Курочку-Рябу.

Архетипичность Курочки-Рябы

Сказку про Курочку-Рябу знают все. Короткий текст буквально растащен на цитаты. Скажите: Мышка бежала. Вам тут же ответят: Хвостиком махнула. Часто употребляются выражения: не простое, а золотое или бил-бил, не разбил.

При этом какой-то одной морали у этой сказки нет. Все её понимают по-своему. Дети видят в сказке волшебство, взрослые воспринимают её с точки зрения своего опыта.

В качестве примера приведу три трактовки сказки от людей одного возраста, которые пять лет учились в одной группе в институте.

Курочка-Ряба с точки зрения пирамиды Маслоу

Дед и Баба имеют базовые потребности в пище и безопасности. Они получают от Курочки-Рябы золотое яйцо и пытаются использовать его по обычному назначению, т.е. съесть. Яйцо при этом не удаётся даже разбить.

Яйцо было положено на полку для сохранности, но пробегающая мышь столкнула его и разбила. Яйца нет; пищи нет; жилище, где мыши портят имущество небезопасно.

Вывод: когда есть нечего, простое съедобное яйцо нужнее золотого.

Курочка-Ряба с точки зрения что имеем, то не ценим

Дед и Баба получают настоящий подарок судьбы: золотое яйцо. Что имеем, то не ценим: они зачем-то пытаются это яйцо разбить. Когда же яйцо разбивается, они сильно расстраиваются. Потерявши, плачем.

Курочка-Ряба с точки зрения проектной деятельности

Продукт проекта (яйцо) получился просто золотым. Испытания прошли на отлично (били-били, не разбили).

На эксплуатации же оказалось, что любая мышка может разбить изделие, что называется, одним движением хвоста.

Вывод: всё предусмотреть невозможно.

Что дальше

Этот короткий эксперимент показал нам тогда, что универсальных методик и сценариев в искусстве управления людьми нет. Каждый человек воспринимает всё по-своему и действует согласно своим представлениям о добре и зле.

Однако, у людей намного больше общего, чем может показаться, и это внушало оптимизм. Оптимизм подкреплял Deadline: роман об управлении проектами Тома Демарко. И это уже другая история

---

Дешевые VPS-серверы Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!

О чем вы беспокоитесь больше: о физических упражнениях, употреблении овощей или о воздухе, которым вы дышите?

Несмотря на то, что большинство вещей, которые благотворно влияют на здоровье, хорошо известны, одна из них крайне недооценена: повышение качества воздуха. Полагаю, что зачастую это самое эффективное вмешательство в здоровье, и точка. Ничто другое не является настолько важным и простым одновременно.

Давайте посмотрим на это с разумной стороны: возьмем четыре самые большие страны мира и сравним, сколько людей умерло по тем или иным причинам в 2019 году.



Трудно отдавать приоритет советам по здоровью. Мне сказали, что мне следует ограничить употребление соли и есть крестоцветные овощи, делать кардио, хорошо спать, ограничить употребление алкоголя, уменьшить уровень стресса и регулярно проходить медицинские осмотры. Но насколько каждая из этих рекомендаций имеет значение? Что делать в первую очередь, если вы безволосая обезьяна, склонная совершать ошибки?

Чтобы ответить на этот вопрос, нам нужны числа. Ниже я оценил, насколько различные факторы влияют на жизнь через качество воздуха.

Образ жизни
Быть викингом стоит 4 года жизни.
Жить в Дели стоит 3 года жизни.
Постоянно ездить на поезде из Ньюарка в Нью-Йорк стоит 6 месяцев жизни
Проживание в средней части США стоит 3 месяца жизни
(Вдыхать дым от чьего-то вейпа около 0?)

Отдельно взятое событие
Если вы жили рядом с лесными пожарами на западном побережье США 2020 года, то это стоило вам 2,4 дня жизни.
Разжечь дома по-настоящему дымный огонь стоит 1 день жизни
Жечь конусное благовоние 2,3 часа жизни
Одну ночь использовать ультразвуковой увлажнитель воздуха 50 минут жизни
Жарить рыбу при закрытых окнах 45 минут жизни
Жечь благовония-палочки 27 минут жизни
Использование лака для волос 14 минут жизни
Выкурить одну сигарету 11 минут жизни
Задуть свечу перед сном 10 минут жизни

Это хорошие новости вы можете купить дополнительную жизнь с минимальными затратами денег, времени, усилий или силы воли!

Обязательно контролируйте массу тела, хорошо ешьте и начинайте бегать. Это важно, но и довольно сложно. Возможно, вам не удастся похудеть, но если вы попытаетесь повысить качество воздуха, у вас все получится. Вы должны начать с того, что дает максимальную отдачу от усилий, и это воздух.

Что я рекомендую

Если вы не хотите читать эту длинную-длинную статью (извините), просто выполните следующие действия в следующем порядке:

• Если у вас есть ультразвуковой увлажнитель воздуха, уничтожте его.
• Следите за качеством местного воздуха, как за погодой.
• Никаких благовоний.
• Свечи гасите только крышкой.
• Будьте осторожны с дымом при приготовлении пищи.
• Заведите себе счетчик частиц.
• Все время используйте дома очиститель воздуха. (Это пункт 1, если в наружном воздухе, где вы живете, много твердых частиц.)
• Установите в свой автомобиль салонный воздушный фильтр HEPA.
• Избегайте использования аэрозолей.
• При нахождении в грязном воздухе используйте маску очень осторожно.

На первый взгляд, странный список, но, похоже, именно к нему приводят доказательства.

Частицы и проблемы, которые они вызывают

Что мы измеряем

Мы измеряем частицы в единицах PM_2,5. Теоретически это можно измерить следующим образом:

Возьмите кубометр воздуха.
Отфильтруйте все твердые частицы.
Оставьте только частицы размером 2,5 микрометра/микрона (мкм) или меньше.
Взвесьте оставшиеся частицы в микрограммах (мкг).
Единицы измерения мкг/м, поскольку вы взвешиваете частицы (в мкг) в одном м воздуха.
Для справки: человеческие волосы имеют ширину около 70 микрометров, бактерии от 1 до 10, а вирусы от 0,02 до 0,4. Агентство по охране окружающей среды дает полезную визуализацию:



Вы можете спросить: все ли химические вещества равны? Одинаково ли вредны 50 мкг/м3 при сжигании угля, производстве цемента или природной пыли? Ответ нет (слышали об асбесте?). Но мы действительно не знаем, насколько эти различия имеют значение на практике.

Количественная оценка вреда

Лучшим показателем, чем количество смертей, является количество лет жизни с поправкой на инвалидность или годы жизни, скорректированные по нетрудоспособности (DALY). Это количество потерянных лет жизни плюс поправка на несмертельные условия, которые ухудшают жизнь. Например, шизофрения это очень плохо, поэтому считается, что тот, кто становится шизофреником на год, теряет половину лет жизни, скорректированных по нетрудоспособности. Это дает аналогичную картину.



Эти цифры относятся только к загрязнению атмосферного воздуха, например, из-за автомобилей, электростанций и производства. К этому добавляется загрязнение воздуха внутри помещений.

Как частицы вредят тебе

Мы беспокоимся о мелких частицах, потому что они кажутся наиболее вредными, особенно с точки зрения того, как хроническое воздействие приводит к долгосрочным проблемам со здоровьем.

Эти частицы действительно вызывают рак легких, но это одно из меньших зол. Они также вызывают хронические респираторные проблемы. Тем не менее, более половины вреда исходит вовсе не от легких, а от диабета и сердечно-сосудистых заболеваний. Вот вред, нанесенный США в 2019 году:
Вред от мелких частиц:



Как частицам удается все это делать, все еще остается предметом исследования. Основная история, по-видимому, заключается в том, что мельчайшие частицы могут проникать через легкие в кровоток. Затем эти инородные частицы активируют вашу иммунную систему, которая начинает буйствовать, вызывая всевозможные проблемы.

Почему так много сердечно-сосудистых заболеваний? Что ж, вы, наверное, можете догадаться, куда уходит кровь после того, как она покидает легкие.

Эвристика для количественной оценки вреда

Насколько сильно Вам вредят частицы? Хотя это сложно сказать точно, в этом разделе будут представлены две простые эвристики:

• Длительное воздействие 33,3 PM_2,5 стоит 1 года жизни, скорректированные по нетрудоспособности. Это лучше всего подходит для изменения образа жизни. Например, перемещение из места, где нет твердых частиц, в место с уровнем 100 PM2,5 стоит 3 года жизни, скорректированные по нетрудоспособности.
• При 2500 PM_2,5 вы теряете годы жизни, скорректированные по нетрудоспособности в реальном времени. Это лучше всего для разовых мероприятий. Например, если вы подвергаетесь воздействию уровня 5000 PM_2,5 в течение 3 часов, вы теряете 6 часов жизни, скорректированных по нетрудоспособности.

Конечно, единственный способ быть уверенным это провести рандомизированные эксперименты, в которых мы запираем людей в одинаковых средах на всю их жизнь, меняем частицы, влиянию которых они подвергаются, и наблюдаем, как долго они живут. Поскольку мы не можем этого сделать, нам остаются только наблюдательные исследования.

В статье 2013 года рассматривалась продолжительность жизни и уровни частиц в 545 округах США, при этом учитывались смешанные переменные, такие как благосостояние, курение и демография. Они обнаружили, что каждые 28,5 мкг/м3 твердых частиц стоят 1 год (без учета нетрудоспособности).

Стоит ли доверять этому числу? Большинство статей посвящено вопросам общественного здравоохранения, но мы можем извлечь некие оценки. Во всеобъемлющем документе 2017 года оценивается среднее значение PM_2,5 для населения в разных странах, а также затраты на здоровье, связанные с частицами в окружающем воздухе. Я взял их оценки и умножил их на цифры ожидаемой продолжительности жизни ВОЗ, чтобы получить оценку общего количества годов жизни, скорректированных по нетрудоспособности, которые каждый человек теряет за свою жизнь. Вот уровни частиц в зависимости от общего потерянного количества годов жизни, скорректированных по нетрудоспособности.



Прямая линия показывает соотношение. График говорит о том, что если вы подвергаетесь воздействию 33,3 PM_2,5 в течение всей жизни, в результате вы потеряете около 1 года жизни, скорректированного по нетрудоспособности. Я бы не стал слишком полагаться на это точное число. Оно варьируется от страны к стране, и все это основано на очень сложной статистике. Тем не менее, обнадеживает тот факт, что разные данные и методы приводят к цифре, близкой к статье 2013 года.

Вы можете спросить: не должен ли один и тот же уровень частиц причинять больший вред там, где люди живут дольше, поскольку у них больше времени, чтобы вдохнуть частицы?

Может быть. Я попытался связать частицы с потерей годов жизни, скорректированных по нетрудоспособности за один год, не умножая на ожидаемую продолжительность жизни. Это предполагает, что воздействие 2500 PM_2,5 в течение одного года стоит 1 года жизни, скорректированного по нетрудоспособности.



Другими словами, если вы вдыхаете частицы с концентрацией 2500 PM_2,5, вы удваиваете скорость, с которой вы движетесь к своей судьбе (с поправкой на нетрудоспособность). Если вы подвергаетесь воздействию уровня X 2500 в течение H часов, вы теряете XH часов жизни с поправкой на нетрудоспособность.

На практике это не слишком отличается от предыдущей оценки, поскольку ожидаемая продолжительность жизни в разных странах не сильно различается.

Личное воздействие

Итак, мы можем оценить, какой вред наносят твердые частицы. Следующий естественный вопрос: какому количеству частиц вы подвергаетесь? Вероятно, ответ это частицы из окружающей среды плюс некоторое дополнительное количество в помещении, но трудно сказать, насколько велико это количество.

Где люди проводят время

Есть хорошие записи об уровнях частиц на открытом воздухе, но большинство людей не очень много времени проводят на открытом воздухе. Вот обзор НNHAPS о том, как американцы проводили свое время с 1992 по 1994 год.



Время, проведенное в помещении (86,9%). На месте проживания (68,7%), офис/производство (5,4%), бар/ресторан (1,8%), другие помещения (1,8%), в транспорте (5,5%), на открытом воздухе (7,6%).

Похоже, что ни один недавний опрос не сравнится с этим. У них даже есть кривые показывающие, где люди находятся в течение дня.

Личное VS наружное воздействие

Уровни частиц в помещении такие же, как и на открытом воздухе?

Существует сильная корреляция, особенно если люди держат окна открытыми, но она варьируется. Обычно уровни в помещении выше, чем на открытом воздухе. Чен и Чжао просматривают кучу статей, в которых пытаются оценить соотношение внутреннего/внешнего соотношения:



Но на самом деле все это не имеет значения. Уровни в помещении различаются по пространству и времени. Что вас волнует, так это ваше личное воздействие, воздух, который фактически попадает в ваши легкие.

Это сложно изучать, так как вам нужно носить с собой измерительное устройство, но это уже было сделано несколько раз. В течение ранних попыток маленькую трубку помещали возле рта, которая в свою очередь пропускала воздух через фильтр, который позже был взвешен. В более поздних исследованиях используются устройства, измеряющие светорассеяние.

Я не нашел хорошего анализа, поэтому сделал свой. Вот сравнение среднего личного и уличного уровней во всех исследованиях, которые я нашел:



*Вы можете развернуть таблицу с подробностями обо всех исследованиях здесь, если хотите.
Личное воздействие сильно коррелирует с уровнями на открытом воздухе, но обычно оно немного выше. Если вы доверяете линии на графике, она предсказывает, что у кого-то с наружным уровнем 50 будет личное воздействие 62,5.

Однако личное воздействие гораздо менее предсказуемо, чем можно предположить из приведенного выше графика. Каждая точка усредняется по множеству людей. Индивидуальные исследования, которые разбирали каждую ситуацию по отдельности, показывают огромный разброс.

Итак, ваше воздействие, вероятно, равно окружающему уровню плюс некоторая величина, которая зависит от того, что вы делаете и куда идете. Чтобы понять это, нам нужно копнуть глубже.

Частицы на открытом воздухе

Большинство частиц являются результатом деятельности человека. Обычными источниками частиц являются электростанции (особенно угольные, но также природный газ и нефть), фабрики, антропогенные пожары, автомобили и грузовики. Естественные источники это пыль, лесные пожары и (как ни странно) морские брызги.

Разница по городу/региону большая: уровни сильно различаются по всему миру. Исчисления различаются, но у некоторые стран показатели действительно низкие (Новая Зеландия, Канада), а у некоторых на порядок выше (Индия, Катар). Различные местоположения внутри стран связаны частично из-за того, что вокруг дует один и тот же воздух, а частично из-за совместного контроля выбросов. Тем не менее, если в вашем городе нет ветра и много заводов и машин, уровни будут выше.

Различия относительно местоположения в пределах города/региона маленькие: насколько различаются те или иные места в одном и том же городе? Ответ: вроде бы как-то различаются. Массовое исследование, проведенное в различных местах Европы, показало, что уровни частиц вблизи улиц были примерно на 20% выше, чем в городах, которые, в свою очередь, были примерно на 20% выше, чем в регионах.

Различия, обусловленные датой умеренное: в одном и том же месте уровни меняются в течение года. Вот средняя концентрация в Лос-Анджелесе за каждый день за 20 лет, любезно предоставленная Агентством по охране окружающей среды.



Вы можете увидеть влияние от людей, запускающих фейерверки, чтобы отпраздновать свою свободу (4 июля каждого года), всех, кто остается дома из-за пандемии (март-апрель 2020 года), и массивных лесных пожаров (сентябрь 2020 года).

Кстатм, какое значение имели эти пожары? Во многих областях их уровень поднялся примерно до 100 за несколько недель, а в некоторых поднялся до 200-500. В качестве пессимистической оценки предположим, что ваши уровни выросли на 200 за полный месяц. Это увеличивает ваш средний годовой показатель на 16,67, что будет стоить 6 месяцев от года жизни, скорректированного по нетрудоспособности, если это будет происходить каждый год. Если бы это произошло всего один раз, вы бы потеряли 200/2500 = 0,08 месяца или 2,4 скорректированных жизненных дня.

Различия, обусловленные временем суток небольшое: в одном месте и в один и тот же день уровни меняются по часам. Manning (2018) объединил измерения с 3110 объектов по всему миру, чтобы получить следующий график.



Здесь у нас есть большая загадка: почему уровни самые низкие в середине и конце дня? Они предполагают, что эта замечательная глобальная однородность суточных циклов PM_2,5 предполагает влияние общих факторов, включая суточный цикл глубины смешанного слоя, модулируемый другими процессами, такими как суточные колебания выбросов.

Я думаю, это означает следующее: солнце нагревает землю по утрам. Это заставляет воздух у земли подниматься, смешивая различные слои воздуха. Это притягивает множество частиц от земли к небу, уменьшая их плотность. После того, как земля остынет, воздух перестает так сильно перемешиваться. Кроме того, возможно, это как-то связано с тем, когда люди ездят на работу и так далее.

Я очарован этим феноменом смешанной глубины слоя, но пока не смог разобраться в нем. Меняется ли он по сезонам? Поэтому качество воздуха зимой часто бывает хуже? Я не знаю.

Частицы в пути

Вождение: автомобили генерируют множество частиц. Если вы едете рядом с множеством других автомобилей, уровень частиц, вероятно, выше, чем в окружающем воздухе. В нескольких исследованиях, которые я видел, были обнаружены уровни в диапазоне от 50 до 100 в автомобилях. Другие предполагают, что это не так уж и плохо и схоже с обычным нахождением на улице. Вероятно, это зависит от вашего автомобиля, трафика, местных средств контроля выбросов и погоды.

Ходьба, езда на велосипеде и бег. Если вы находитесь на улице, ваше воздействие может быть немного выше, чем фон, но не намного. Как упоминалось выше, уличные измерения обычно немного выше, чем у городских. Если вы едете на велосипеде или бегаете, вам становится тяжелее дышать. Кажется, что типичный взрослый дышит примерно 15 раз в минуту, но может ускориться в 4 раза, если будет усиленно тренироваться. Это может означать, что частицы накапливаются в 4 раза быстрее, но я не могу найти никаких явных доказательств этому.

Мы могли бы оценить вред от загрязнения в результате бега или езды на велосипеде, но я не буду этого делать, поскольку упражнения также улучшают здоровье сердечно-сосудистой системы, и я не знаю, как рассчитать это баланс.

Езда в метро: Luglio (2020) измерил частицы для всех основных систем поездов на северо-востоке США. Делали измерения на надземных станциях, но всегда выходило мало (10-25).



Для самой опасной системы поездов поездка из Ньюарка, штат Нью-Джерси, до Всемирного торгового центра в Нью-Йорке должна стоить 7,5 минут жизни. Поездка пять дней в неделю будет стоить 0,56 годов жизни, скорректированных по нетрудоспособности.

Поездка занимает 25 минут. Предположим, вы проводите по 10 минут на двух станциях. Ваше воздействие за час, который вы проводите в этой поездке, составляет 779 10/60 + 449 25/60 = 316,9, что приводит к затратам 316,9 / 2500 = 0,126 часа.

Всего есть 10 поездок, каждая из которых увеличивает воздействие на 316,9 за один час. Это увеличивает ваше среднее недельное воздействие на 316,9 10 / (7 24) = 18,86 при затратах 18,86 / 33,33 = 0,56 годов жизни, скорректированных по нетрудоспособности.

Smith (2020) обнаружил, что в лондонском метро линия Виктория имела средний уровень 361, северная линия 194, пара других около 50, а остальные еще ниже. Линия Виктория имеет самые высокие показатели, потому что она полностью находится под землей, а это означает, что частицам некуда деваться.

Martins (2015) рассматривает многие предыдущие исследования с обнаруженными уровнями более 100 в Лондоне, Буэнос-Айресе, Париже, Пекине, Нью-Йорке, Стокгольме, Шанхае, Барселоне и Сеуле. Более низкие уровни были в Будапеште, Гуанчжоу, Хельсинки, Лос-Анджелесе, Мехико, Тайбэе и Сиднее.

Rant: Посмотрим правде в глаза, эти уровни позор. В некоторых местах над ними работают, но прогресс идет медленно, потому что сложно модернизировать поезда. Послушайте меня, транспортные агентства: не модернизируйте эти проклятые поезда. Просто установите на станциях обычные очистители воздуха. Сделайте это, потому что:

• Проблема в том, что частицы медленно накапливаются в туннелях, откуда им некуда деться. Мы можем решить проблему в источнике, медленно убирая частицы.
• Установить статические очистители на станции несложно. Вы можете использовать стандартные компоненты.
• Частицы в поездах поступают со станций и туннелей.
• Люди тоже дышат воздухом на станциях.

Очистители воздуха слишком дороги? Ну, в метро Нью-Йорка (MTA) 275 станций метро. Предположим пессимистично, что каждой станции нужно 50 очистителей, а их эксплуатация стоит 1000 долларов в год. (MTA любит сильно переплачивать.) Стоимость составит 13,75 миллиона в год, что составляет менее 0,1% бюджета MTA. Кажется, это стоит того, чтобы не подвергать миллионы людей воздействию воздуха, в пять раз более опасного, чем самые загрязненные города мира.

Частицы в помещении

Предположим, вы находитесь в своем доме. Качество воздуха, которым вы дышите, можно снизить пятью факторами:

• Уровни твердых частиц на открытом воздухе.
• Как долго частицы висят в воздухе в помещении.
• Скорость обмена между внутренним и наружным воздухом.
• Вы совершаете действия, которые создают частицы в помещении (приготовление пищи, свечи).
• Вещи, которые вы делаете для удаления частиц в помещении (работает очиститель).
• Мы уже рассмотрели 1. Давай рассмотрим все остальное.

Как долго частицы висят в воздухе

Может быть, воздух в помещении каким-то образом автоматически чище, чем воздух снаружи? Об этом свидетельствуют рекомендации общественного здравоохранения оставаться в помещении при плохом качестве воздуха.

Оставленные в покое, частицы оседают из воздуха. В абсолютно неподвижном воздухе это происходит детерминировано, когда более крупные частицы падают быстрее. В реальном (турбулентном) воздухе частицы отскакивают, пока не прилипнут к поверхности. Это приводит к экспоненциальному спаду со скоростью, зависящей от размера частиц и турбулентности воздуха. Эксперименты предполагают примерно следующее:



Мне сложно определить, насколько это время зависит от турбулентности воздуха или от того, соответствует ли скорость перемешивания реальным условиям.

Период полураспада воздуха в домах

Даже при закрытых окнах воздух постоянно проходит через щели в здании. Давайте определим это как период полураспада при вентиляции, количество времени, по истечении которого половина воздуха в помещении заменяется извне. В обычных домах это время составляет от 1 до 5 часов. Он длиннее в более энергоэффективных домах и (намного) короче, если окна открыты.

Чаще (и более запутанно) используется так называемая скорость воздухообмена.
Таким образом, если вы активно не очищаете воздух, уровни в помещении, вероятно, аналогичны уровням на открытом воздухе, плюс любые частицы, которые вы производите внутри. Воздух обменивается достаточно быстро, чтобы к тому времени, когда частицы выпали из воздуха, новые частицы пришли извне. (Однако закрытые окна должны работать для более крупных частиц, и может быть некоторая польза от открытия/закрытия окон в зависимости от изменения уровней наружного освещения.)

Воздействие с уменьшающейся концентрацией

Чтобы рассчитать влияние конкретных вещей, которые генерируют частицы, нам понадобится быстрый расчет. Если вы создадите клуб дыма с пиковой концентрацией c и периодом полураспада h, уровни со временем будут медленно падать. Какое у вас общее воздействие?
На следующем графике показана пиковая концентрация c = 1000, которая распадается с периодом полураспада h = 0,2 часа. Оказывается, это эквивалентно (такая же площадь под кривой) выдержке с константой 288 в течение 1 часа.



Откуда взялось 288? Общая формула 1.44 c h. Это вполне естественно: по математике это пиковая концентрация, умноженная на период полураспада, умноженная на дополнительную константу. Как и следовало ожидать, удвоение пиковой концентрации или периода полураспада удваивает общее воздействие.

Общая формула происходит от простого интеграла.
По прошествии некоторого времени t частицы претерпели период полураспада t/h, что означает, что общая концентрация уменьшится в (1/2) ^ (t / h) раз, и, таким образом, текущий уровень в момент времени t равен c (1/2) ^ (т / ч). Если мы проинтегрируем это, чтобы получить общее воздействие, это будет c (1/2) ^ (- t / h) dt = c h / ln (2). Бывает, что 1 / ln (2) 1,44.

Вещи, которые создают частицы в помещении

Курение: Вы слышали? Курение вредно для Вас. Shaw (2000) оценивает, что одна сигарета сокращает продолжительность жизни (без поправки на трудоспособность) на 11 минут, и указывает, что этого времени достаточно для довольно безумного полового акта. Давайте двигаться дальше.

Вейпинг: здесь речь идет исключительно о вторичном вейп-дыме. (Я не рекомендую вейпинг, если вы не делаете это для того, чтобы бросить курить.)

Иногда кажется, что сообщество общественного здравоохранения одержимо стремится уничтожить вейпинг, согласно чертовым доказательствам. Конечно, я всегда думал, что вейпинг это не здорово, но разве вред настолько большой?

Сообщество вейпинга часто ссылается на этот отчет Центры по контролю и профилактике заболеваний США, который не обнаружил никаких проблем. Однако они не проверяли наличие частиц. Это ничего не доказывает.

Многие люди измерили частицы около вейпинга и обнаружили высокие уровни. Soule (2017) обнаружил уровень частиц около 1000 на конференции по электронным сигаретам. Li (2021) обнаружил, что в шести вейп-шопах в Южной Калифорнии средний уровень составляет 276. Protano (2020) обнаружил, что один человек, пользующийся вейпом, может достичь уровня от 1000 до 10000. Множество случайных людей измеряют частицы и сообщают числа вроде 600, 546 или 1000. Некоторые сообщают, что их заставляли делать это их родители (хорошая работа, родители).

Энтузиасты вейпинга возражают, что почти все частицы состоят из воды, глицерина и небольшого количества никотина. Это похоже на правду в отличие от табачного дыма, выдыхаемый воздух вейпа не содержит значительно больше фенолов или карбонилов (таких как формальдегид или ацетон), чем обычный выдыхаемый воздух.

Я предварительно называю это Team Vape. В горах работ, в которых измеряется содержание вейп-дыма с высоким содержанием частиц, мало кто даже признает утверждение, что все это вода и глицерин. Может я что-то упускаю? Мое представление о заговоре против вейпинга не отступило.

Камины и твердое топливо

. В различных исследованиях было обнаружено, что обычный день из жизни фермера 18 века, викинга или приготовление пищи на открытом огне в Гватемале может привести к среднесуточной концентрации частиц около 200. Эти исследования всегда находят безумные уровни частиц около огня (около 1000), но в этих зданиях хорошая вентиляция, и люди не проводят так много времени возле самого сильного дыма. Это предполагает потерю примерно 6 годов жизни, скорректированных по нетрудоспособности, несмотря на то, что настоящие викинги могли снизить количество дыма после многих поколений практики использования огня.

По сей день во всем мире много людей, которые готовят дома на твердом топливе (уголь/дрова). В Индии, в том числе вред, наносимый твердыми частицами воздуха в домашних условиях, почти вдвое увеличивает (и без того большие) потери, вызываемые загрязнением атмосферного воздуха.

Насколько сильно может повредить огонь в камине? Это зависит от многих факторов: насколько велик огонь? Хорошо ли горит? Насколько хорошо вентилируется ваш дом? У вас есть стеклянная панель перед огнем? Насколько хорошо дымоход для камина втягивает воздух?
Давайте будем по-настоящему пессимистичными и представим, что у вас есть огонь с концентрацией 25000, который горит пять часов. Это будет стоить вам около 25 часов жизни с поправкой на трудоспособность. Если все сделать правильно, это, вероятно, уменьшится в 23 раза. Современная дровяная печь с плотными уплотнениями могла бы стать еще лучше.

Кулинария: А как насчет других способов приготовления? Опять же, все зависит от обстоятельств. Kang (2019) пробовал готовить разные блюда в 30 разных зданиях Кореи. В среднем суп давал пиковую концентрацию 65, жарка на масле 424 и жарка на огне 1256. И жарка на масле, и жарка на огне всегда сильно различались.

Открытие окна снизило пиковую концентрацию примерно до . Использование вытяжки (с открытым окном или без него) уменьшило его примерно до .

И как долго частицы остаются? Без вытяжки или вентиляции средний период полураспада составлял около часа. (На самом деле это более быстрый период полураспада посредством вентиляции, о котором мы говорили выше.) С вытяжкой период полураспада составлял около 20 минут. При открытых окнах это было около 6-7 минут (независимо от вытяжки).

Эти цифры показывают, что приготовление рыбы при закрытых окнах приводит к потере около 45 минут.

Свечи: Свечи образуют некоторые частицы во время горения, но подавляющее большинство их частиц появляются в тот момент, когда свеча гаснет. (Это подтверждается другими исследованиями.) Задувание свечи вызывает всплеск примерно 50-200, при этом частицы остаются в воздухе в течение 3-5 часов.

Если принять средние значения, то каждое задувание свечи будет стоить вам 10 минут. Если делать это ежедневно, то это будет стоить вам полгода.

Давайте возьмем пиковое значение в 100 и предположим, что частицы висят в воздухе 4 часа. Тогда это будет стоить 100 4/2500 = 0,16 часа или 9,6 минуты в день.

Очевидное решение избегать свечей. Если вам это не подходит, свечи, вероятно, не так уж и плохи, просто не задувайте их. Вместо этого потушите их, надев герметичную крышку.

Благовония: одна статья предполагает, что при сжигании ароматической палочки пиковая концентрация может составлять около 800, а в конусе более 4000, а период полураспада составляет около 1,6 часа.

Это предполагает, что сжигание конуса благовоний стоит 3,68 часа жизни.

Используя нашу формулу полураспада, общее воздействие составляет 4000 1,6 1,44 = 9216 часов частиц. Таким образом, общая стоимость составляет 9216/2500 = 3,68 часа с поправкой на нетрудоспособность.

Не используйте благовония.

Аэрозоли: некоторые чистящие средства образуют тонны частиц. В одной статье было описано, что использование Febreze вызывает всплеск частиц на 50-75. Они также обнаружили, что лак для волос может вызвать всплеск до 200 с периодом полураспада 2 часа. Они также являются исключительно мелкими частицами, которые очень долго висят в воздухе.

Это говорит о том, что использование лака для волос (в помещении) стоит около 14 минут.
Предположим увеличение на 200 с периодом полувыведения 2 часа. Тогда общая стоимость составит 200 2 1,44 / 2500 = 0,23 часа.

Старайтесь не разбрызгивать что-либо в воздух. Если вы действительно любите лак для волос, вы можете использовать его на улице или в хорошо проветриваемой комнате прямо перед выходом из дома.

Увлажнители: вам это не понравится, но ультразвуковые увлажнители производят огромное количество частиц. Они превращают любые минералы в воде в частицы, переносимые по воздуху. Они делают это почти намеренно! Park (2020) протестировал различные типы воды в небольшой камере с тщательно контролируемой скоростью воздухообмена и получил следующие устойчивые повышения по сравнению с фоновыми уровнями.

• Минеральная вода: ~ 265
• Водопроводная вода (Сеул): ~ 260
• Очищенная вода: ~ 50
• Дистиллированная вода: ~ 0

Похоже, это показывает, что учитываются не только частицы воды. Некоторые люди из реального мира сообщают о еще больших цифрах. Я сам это проверил и обнаружил то же самое.

Это говорит о том, что использование ультразвукового увлажнителя с водопроводной водой в ночное время в течение 8 часов стоит 50 минут. Делая это каждую ночь, вы теряете 2,6 года.
(Поскольку мы смотрим на стационарные концентрации, а не на пик, мы не рассматриваем периоды полураспада.) Ваше общее воздействие за одну ночь составляет 260 8 = 2080, при стоимости 2080/2500 = 0,832 часа = 50 минут. Если вы будете делать это каждую ночь, это повысит ваше среднее дневное воздействие на 260 8/24 = 86,66 с затратами на 86,66 / 33,33 = 2,6 года.

Ночью пользоваться увлажнителем почти так же плохо, как выкурить 5 сигарет!? Я скептически относился к реальности таких больших чисел. Я прочитал инструкции по эксплуатации нескольких ультразвуковых увлажнителей воздуха. Было несколько моментов в инструкции, откуда я понял, что они знают об этой проблеме:

• Для наполнения резервуара для воды используйте только чистую прохладную воду из-под крана (рекомендуется использовать фильтрованную или дистиллированную воду, чтобы избежать образования белой пыли, если вода из-под крана слишком жесткая).
• Лучший способ минимизировать накопление минералов использовать дистиллированную или деминерализованную воду.
• ВАЖНО: использование водопроводной воды с высоким содержанием минералов, известной какжесткая вода, с любым увлажнителем может привести к выделению мелкой белой пыли. Чтобы этого избежать, используйте дистиллированную или деминерализованную воду .

В качестве дополнительного доказательства Агентство по охране окружающей среды опубликовало отчет, в котором говорится: Недавние исследования [] показали, что ультразвуковые и импеллерные (или холодный туман) увлажнители могут рассеивать материалы, такие как микроорганизмы и минералы, из резервуаров для воды в воздух в помещении. Они рекомендуют осушать и очищать резервуар каждый день, а также использовать дистиллированную воду.

Агентство по охране окружающей среды подчеркивает, что нет никаких доказательств того, что именно эти частицы вредят здоровью. Это, конечно, интересный способ смотреть на вещи. Возможно, это подходящая логика для правительства, рассматривающего вопрос о запрете, но не для нас. Увлажнители имеют огромный эффект, и вы должны понимать, что они опасны, пока не появятся убедительные доказательства обратного.

Теоретически вы можете попытаться решить проблему, используя дистиллированную воду или увлажняя комнату, находясь вне дома или закрывая дверь. Но не стоит. Что делать, если увлажнитель загрязняется? Что делать, если частицы просачиваются из комнаты? Что делать, если у вас накапливаются бактерии и загрязняют воду? Вы действительно собираетесь отключать, чистить и сушить увлажнитель каждый раз, когда вы его используете?

Просто используйте испарительный или паровой увлажнитель воздуха, которые, кажется, почти не создают частиц.

Другие случайные вещи

Оказывается, пылесос приводит к увеличению количества частиц на 50. Сушилка для чистки ворса вызывает всплеск PM₁₀, но не PM_2,5. Вы можете получить небольшой подъем уровня частиц, застелив постель!

В целом, избежать появления частиц невозможно. Практически любая деятельность, связанная с молекулами, создаст некоторые частицы. На самом деле, воздействие в течение небольшого промежутка времени не имеет такого уж большого значения. Решение состоит в том, чтобы избежать самых серьезных проблем и убедиться, что частицы удаляются из воздуха достаточно быстро, чтобы не причинить серьезного вреда. Сделать это можно, очистив воздух. Или, если вам повезло с чистым и умеренным воздухом на улице, вы можете просто держать окна открытыми.

Что делать

Старайтесь не создавать частицы в помещении.
Прежде всего, избавьтесь от своих ультразвуковых увлажнителей воздуха. Не сжигайте продукты во время готовки. Никогда не используйте благовония. Гасите свечи крышкой. Избегайте опасных чистящих средств. Если вы пользуетесь лаком для волос, я думаю, вы могли бы делать это на улице?

Следите за уровнями частиц на открытом воздухе.
В большинстве мест в мире есть средства измерения частиц в реальном времени. Вы должны следить за ними, как и за погодой. Некоторые погодные веб-сайты/приложения уже включают подсчет частиц подумайте об их использовании.

Заведите себе счетчик частиц.
Вы можете оценить скорость воздухообмена в вашем доме и скорость, с которой ваш очиститель удаляет частицы. Вы можете попытаться уменьшить активность, генерирующую частицы в помещении. Но единственный способ убедиться это проверить.

Вы можете купить нормальный счетчик частиц за 100 долларов. Иногда носите его с собой, чтобы проверять, нет ли каких-то неприятных сюрпризов. Поделитесь этой информацией с вашими друзьями. Нам действительно нужны более совершенные портативные счетчики частиц. В идеале они должны быть встроены в часы или в телефоны.

(Многие люди просили у меня порекомендовать хороший счетчик частиц. Я не хочу рекомендовать тот, который у меня есть, потому что он несколько хреновый. Если вы ищете монитор качества воздуха, есть много вариантов, которые будут лучше. Дайте мне знать, если у вас есть счетчик частиц, который вам действительно нравится.)

Используйте в помещении очиститель воздуха

Очиститель воздуха нужен вашему дому по двум причинам:

• Для снижения стационарного уровня внешних частиц.
• Чтобы уменьшить период полураспада частиц, которые вы производите в помещении.

Оказывается, очиститель воздуха уменьшает и то, и другое в одинаковой степени. Чтобы получить более точные данные, предположим

• Период полураспада вашей вентиляции равен t, что означает, что по прошествии этого времени половина воздуха в вашем доме была заменена наружным воздухом. (Обычно это от одного до пяти часов.)
• Период полураспада вашего очищения равен s, что означает, что по прошествии этого времени ваш очиститель удаляет половину частиц из воздуха (при условии отсутствия вентиляции).

Когда вы включаете очиститель, по математическим расчетам, ваше общее воздействие как от внутренних, так и от внешних источников умножается на коэффициент

с/(с+т).

Это интуитивно понятно: вы хотите, чтобы очистка была быстрее, чем вентиляция, т.е. вы хотите, чтобы s <t. В этом случае ваше общее воздействие умножается на небольшое число.
Например, предположим, что в вашем доме средний период полураспада вентиляции составляет 120 минут, а кубовидный очиститель воздуха работает на низком уровне, что означает период полураспада очистки 15 минут в комнате объемом 31 м. Затем этот очиститель снижает ваше воздействие на долю = 15 / (15 + 120) от того, что было бы в противном случае.

Хотя это работает как для внутренних, так и для наружных частиц, помните, что всегда полезно открывать окна, если уровень на открытом воздухе в настоящее время ниже, чем в помещении например, потому что вы только что сожгли свой обед.

*Поскольку это уже подробности, я оставлю детали того, как вывести эту формулу здесь.
Сначала поговорим об устойчивом состоянии. За фиксированный промежуток времени очистители удаляют фиксированную фракцию частиц из воздуха, в то время как вентиляция заменяет фиксированную часть воздуха в помещении на наружный. Таким образом, чем больше частиц, тем быстрее работает очистка и меньше вентиляция. Устойчивое состояние это когда они равны.

Если уровни наружного воздуха равны L, оказывается, что устойчивое состояние для уровней внутри помещений равно L s / (s + t).

Например, предположим, что уровни на открытом воздухе равны 100, средний период полураспада вентиляции в вашем доме составляет 120 минут, и что вы используете кубовидный очиститель воздуха на высокой скорости в комнате среднего размера, что означает период полураспада очистки 7 минут. Тогда установившаяся концентрация будет 5,5 = 100 7 / (7 + 120).

Теперь поговорим о частицах, созданных в помещении. Допустим, вы генерируете клубок дыма и получаете максимальную концентрацию c. Если частицы уходят только из-за вентиляции, ваше общее воздействие в конечном итоге составит 1,44 ct. Теперь предположим, что у вас есть воздушный фильтр с периодом полураспада s без вентиляции. Комбинированный период полураспада составляет st / (s + t), поэтому ваше новое воздействие составляет 1,44 c s t / (s + t). Соотношение нового и старого воздействия снова s / (s + t).

Установите в машину салонный воздушный фильтр HEPA

Одна автомобильная компания всячески раздумывает над своей системой очистки воздуха. Это замечательно повышать осведомленность, но в большинстве автомобилей, выпущенных за последние 10-20 лет, есть фильтры салона, через которые воздух проходит перед тем, как попасть вам в лицо.

Обычно это не HEPA, но вы можете купить версию HEPA примерно за 1020 долларов и легко установить ее самостоятельно. В большинстве автомобилей вы просто вытаскиваете перчаточный ящик, а затем выдвигаете фильтр. Это занимает около 5 минут и не требует никаких инструментов.

Если вы похожи на большинство людей, вы скорее всего даже не подозревали, что у вас есть воздушный фильтр в салоне, так что, вероятно, пришло время его заменить. Заплатите дополнительно 5 долларов, чтобы получить тот, который удаляет мелкие частицы. (Это может немного снизить скорость воздуха.)

Маски действительно ненадежные

В некоторых частях мира принято носить маски, чтобы уменьшить воздействие частиц. Насколько это помогает? Я не думаю, что кто-то действительно знает. Тем не менее, мы можем сделать несколько убедительных заявлений:

1. Можно использовать маску, чтобы исключить большую часть воздействия частиц (уменьшение> 90%).
2. Многие широко продаваемые маски просто не работают так, как говорится в рекламе, независимо от того, как они используются.
3. Для успешного использования маски крайне важно иметь такую, которая подходит вашему лицу, и необходимо проверять ее соответствие.

Во время лабораторных испытаний исследователи покупают кучу масок n95, затем осторожно прикрепляют их либо к манекенам, либо к настоящим человеческим головам, а затем проверяют, насколько хорошо они работают. С оптимизмом Shakya (2016) обнаружил, что две маски n95 работали хорошо, и даже тканевые маски что-то делали. Ричард Сен-Сир попробовал несколько масок в Китае, очень осторожно подходя к подгонке, и получил числа от 56% до 99%. В некоторых работах (Cherrie, 2018; Pacitto, 2019) было протестировано несколько различных масок и было обнаружено, что одна или две работают хорошо, но большинство удаляют половину частиц или меньше. К сожалению, Faridi 2020 попробовал 50 различных масок, доступных в Иране, и обнаружил, что ни одна из них не работает лучше 40%, а большинство из них намного хуже.

Я предполагаю, что реальные условия ближе к плохим случаям, чем к хорошим.

Что вы можете сделать? Две вещи:

• Откажитесь от покупки какой-либо маски без независимого тестирования, чтобы доказать, что она работает.
• Навязчивый тест на подгонку проверка низкого качества заключается в том, чтобы посмотреть, что происходит, когда вы вдыхаете или выдыхаете воздух проходит по краям маски? Но на самом деле вам нужен формальный тест на пригодность.

Распространенный метод настоящих тестов сделать аэрозоль с сахарином (да, искусственный подсластитель) и проверить, блокирует ли маска запах. Provenzano (2020) дает некоторые предварительные доказательства того, что это можно сделать с небольшими затратами.

Пока нет проверенного рецепта, сделанного своими руками, но это кажется возможным. Может быть, мы сможем использовать эти чертовы ультразвуковые увлажнители воздуха, чтобы сделать аэрозоль сахарина. Кто знает, может, появится какая-то не связанная с этим причина для интереса к маскам.

---

Облачные серверы от Маклауд быстрые и безопасные.

Зарегистрируйтесь по ссылке выше или кликнув на баннер и получите 10% скидку на первый месяц аренды сервера любой конфигурации!