Наверное, тем что в обратной польской записи операции идут за операндами?
1 + 2 - 3 в RPN будет 1 2 + 3 - а вовсе не "массив операндов" и "массив операторов".
Вы упорно продолжаете путать запись и алгоритм — первое это то с чем имеет дело пользователь, второе (ваши массивы и прочие детали) он вообще не видит (и ему всё равно).
Если бы вам нужно было реализовать обработку выражений именно в RPN — то реализация алгоритма уместилась бы в двух десятках строк (но пользователи вас бы проклинали).
Я буду третий (наверное). Потому что, как уже чуть выше сказали, речь про "запись", да и ваша ссылка говорит о способе записи выражений, а у вас обычный инфикс. Как это реализовано внутри (стеки, регистры etc) совершенно не имеет значения с точки зрения нотации.
Кстати, есть неплохая реализация разбора и вычисления выражений на JS, может вам пригодится в качестве источника идей, раз уж интересуетесь этой темой.
Зачем? Тем кому действительно важен факт физического отсутствия питания камеры или микрофона проще вообще не пользоваться телефоном, подавляющему же большинству остальных вообще пофиг, они и так всю свою жизнь выкладывают онлайн.
Было бы не пофиг, первый же "баг" (в крайнем случае второй) со включенной камерой (как в случае Instagram) убил бы компанию (или сильно её подкосил), но реально это находит отражение в специализированных изданиях, IT-сообщество (и то не всё) негодует, компания извиняется, и все об этом забывают через неделю.
Для того чтобы можно было оптимизировать выполнение операций если конечный результат не зависит от порядка вычисления.
К примеру, если у нас есть нечто вроде:
x = a * b + c * d;
и при этом значения c или d уже находятся в регистрах в связи с более ранним использованием, компилятор может сгенерировать код для вычисления правого слагаемого перед вычислением левого.
Кажется, вас не смущает тот факт что сама идея индикации активности (tally light) существовала ещё до появления первого iPhone (и даже самого Apple), ещё в те времена когда только первые телекамеры и микрофоны появились? Там тоже были лампочки, знаете-ли, правда обычно красного цвета. Да и на ноутбуках и прочих веб-камерах индикаторы задолго до iPhone появились.
gcc -Wall тоже предупреждает, хотя логично чтобы это было по умолчанию.
Вообще же по спецификации C/C++ порядок выполнения действий в пределах выражения отдаётся на усмотрение компилятору и не определен совершенно официально, любое "определенное" поведение конкретного компилятора — это частный случай.
Не решают, потому что облако служит для единственной цели — хранить данные от устройства (по крайней мере в случае трекера) и отдать их если попросят. Для любых других запросов (кроме самого устройства) — да, облако мастер.
По логике только само устройство (или его пользователь) могут решить какие данные верные, а данные нужны только на случай отсутствия данных в устройстве.
В любом случае для работы с оперативными (доступными на самом устройстве) данными доступ к облаку (и сети) вообще не нужен, особенно для просмотра, потому что данные на которые уже есть на устройстве — по определению мастер (а не те которые в облаке), и именно этот принцип был нарушен Garmin.
PS: Преставьте что вы пишете рассказ и периодически заливаете новые версии в облако, но в какой-то момент облако решает что ваша версия — совсем не мастер, и нужно вернуть то что хранится в облаке. Вы правда этого хотите? Данные трекеров — тот же рассказ.
Ваш вопрос очень абстрактный. Какое устройство? Была ли на нём предусмотрена возможность повторной передачи? Как оно определяет что данные нужно передавать за определенный период? Где хранятся данные (внешний носитель, внутренний, доступный извне, недоступный etc)? Какими метаданными располагает база и какие находятся в передаваемых данных (метки времени, etc)? Есть ли валидация данных (контрольные суммы etc)? Могут ли в принципе переданные данные корректироваться или дополняться пока не было связи?
Но всё же… поскольку устройство (по крайней мере если это фитнес-трекер) — изначальный генератор данных и в конечном итоге их потребитель — то верить нужно только устройству. База должна быть исключительно репликой данных устройства.
Хотя то о чём вы спрашиваете больше вопрос обработки исключительных ситуаций — если устройство изначально не было расчитано на "правильное" взаимодействие с базой, можно предположить два варианта:
был сбой и повторная передача содержит точно те же данные что у нас уже есть — игнорировать передачу но притвориться что мы их приняли, чтобы "успокоить" устройство.
был сбой и (возможно) старые данные уже повреждены — соответственно игнорировать, ибо по определению данные о ваших тренировках не могут измениться в принципе.
имеет место быть намеренная попытка "переписать историю" — я бы заблокировал передачу данных и спросил пользователя что делать (это его данные и спрашивать нужно его, объяснив что происходит)
Если же оно изначально было расчитано на адекватную обработку, но ведет себя неестественно — это либо очень жёсткий сбой с повреждением критических данных, либо попытка вмешаться в его работу, в обоих случаях автоматически (без ручного анализа данных на устройстве и в базе) мало что можно сделать.
Хотя самая простая стратегия, которая покроет 99% всех случаев — это игнорировать старые данные, тем не менее подтверждая их приём, опционально сравнивая с уже имеющимися.
Если попыток несколько — значит устройство явно в неадекватном состоянии и все попытки передачи данных нужно блокировать, с информированием пользователя, или сохранять только различающиеся данные в пределах первых нескольких попыток и потом всё равно блокировать (потому что это ненормально).
Как я уже сказал, способов зиллион, но нужно знать точно о чём речь и текущую архитектуру.
Доктор или тренер должны получить их лично от меня, на USB стике или в виде файла, или даже просто посмотреть на моём экране — и ни при каких условиях они не должны получать их с сервера в интернет. Если лично не получается — передача в зашифрованном виде на устройство доктора. В любом случае — только push, никаких pull — это единственное что может минимизировать (хотя и не исключить) проблемы с их утечкой и злоупотреблениями.
В тех редких случаях когда доктору нужен постоянный доступ на протяжении длительного времени — нужно обеспечить независимое устройство с правом доступа только у меня и доктора, а при необходимости хранения в облаке — они должны быть зашифрованы, чтобы бы оператор облака не имел принципиальной возможности на них посмотреть.
При этом, я (пользователь) должен иметь возможность в любой момент этот доступ запретить, а также (при необходимости) получить полный отчёт — когда и какие данные использовались или были запрошены доктором, и с какой целью (если это не очевидно — к примеру, тренеру совсем не нужно знать сколько раз я ходил в туалет).
Более того — я, как пользователь, должен иметь возможность получить все эти данные ровно в том виде в котором их получает доктор, а также иметь возможность делать ручной или автоматический бэкап этих данных в структурированном машинно-читаемом виде без дополнительных затрат, в конце концов это мои данные и даже моё устройство.
Плюс ко всему — любые данные которые хранятся в облаке должны быть зашифрованы с ключём доступным только пользователю (или доверенным агентам, которых он сам определяет — исключительно opt in), с детальным трекингом кто, когда и что оттуда вытаскивал.
Если у меня есть сенсор который что-то передает на сервер, каждая единица данных имеет временную метку и непрерывный id, который увеличивается строго последовательно, то есть и устройство и база всегда точно знают что уже там а что нет, и даже способны определить проблемы с синхронизацией таймеров (если это важно). Для особо важных случаев можно даже делать валидацию уже переданных данных, путём банального сравнения последних переданных N блоков или дней или (проще) посредством хешей (это позволит быстро проверять даже очень большие наборы данных).
В сочетании с уникальным идентификатором набора данных (учётка + id устройства) это обеспечивает довольно простой и отказоустойчивый способ передавать только то что нужно, причём в обе стороны (синхронизировать).
На самом деле есть куча способов это решить с минимальными усилиями, было бы желание.
Мастер источником логично считать всё же мастер источник — то есть собственно устройство, ибо только оно производит эти данные, а центральная БД — это просто реплика собранных данных, и что там с ними происходит дальше никак не должно отражаться на устройстве, даже если база исчезнет.
Другое дело если устройства собирают столько данных что они физически нехранимы на нём самом, тут да, проблемы могут быть — но меня терзают смутные сомнения что фитнес-браслеты требуют десятков гигабайт на хотя бы год работы.
Да и конфликты версионности вряд-ли возможны — потому что все (практически) обновления обязательны, без них устройство не допускается к передаче данных, да и без них можно построить архитектуру в виде сенсор-коллекторы-база где коллекторы будут разбираться с форматами и версиями сенсоров и в нужном виде отправлять в базу.
А так… похоже о пользователях думали лишь как об источнике данных, вариант даже просто отсутствия сети длительное время явно не учитывали (хотя это нормальное явление в ряде регионов), что уж тут говорить про катастрофу...
В конце концов, приложения типа GadgetBridge спокойно обходятся без облака, но производители устройств применяют невероятные усилия чтобы без учётки и сети ими невозможно было пользоваться, даже простой автоматический экспорт данных в чём-то типа "csv" там редкость, что уж тут говорить про открытие API для сторонних приложений.
На самом деле нет — предпочитаю жить без людей, совершенно серьезно. Чем меньше личных контактов — тем лучше я себя чувствую, поэтому для меня это не просто слова. Раньше было по другому, теперь так.
Возможно при определённых условиях. В моём понимании свобода — это когда существуют только ограничения чисто физического порядка, например, невозможность переплыть океан чтобы попасть на другой континент, или отсутствие космического корабля для достижения других планет.
А пока мне нужен загранпаспорт и виза для того чтобы (хотя бы) покинуть страну — это хоть и свобода в какой-то мере, но всё же далека от истинной свободы.
Да и космонавтами станут не все желающие, а только очень миксроскопическая их часть, даже если все они соответствуют требованиям, и квадрокоптеры без лицензии не особо позапускаешь, даже если они никому не мешают (причём не только в РФ) — это всё же очень условная свобода.
Про свободу слушать музыку на любой громкости и прочие свободы я ужу молчу — потому что все без исключения свободы человека живущего в обществе ограничиваются этим самым обществом, прямо или косвенно.
Если же говорить про отшельника в условном космическом корабле, на котором есть всё для жизнеобеспечения (и лечения) — вот это пожалуй будет действительно максимальное приближение к свободе — вся вселенная перед ним, он ограничен только физикой и продолжительностью жизни, то есть чем-то гораздо более объективным чем неестественная окружающая среда вроде общества.
Все ваши свободы ограничены обществом, государством, законами, финансовыми и технологическими возможностями.
Попробуйте стать космонавтом и расскажите о свободе выбора профессии, или попробуйте запускать квадрокоптеры в свободное от работы время и расскажите о свободе выбора хобби. Наконец, попробуйте поехать в Северную Корею (или даже просто куда-то где сейчас закрыты границы в связи с короновирусом) и расскажите о свободе перемещения.
Свет, отраженный от поверхности освещённой прожектором явно "мощнее" чем свет излучаемый экраном смартфона или даже монитора. Если бы это было иначе, то проще было бы светить им в глаза собственно мониторами, или я ошибаюсь?
В любом случае статья не про мониторы, и ссылка на неё в соответствующем контексте просто нерелевантна.
Я добавлял соответствующий WSL пакет в %USERPROFILE%\AppData\Local\Packages — у меня это Ubuntu (есть в названии, типа CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc).
На этот счёт у них есть древний тикет с жалобами, но воз и ныне там. Народ в нём пишет что само по себе исключение якобы не помогает (хотя я явно это ощутил), и что нужно отключить Real Time Protection (причём в Group Policy, а не из UI) — но это можно делать только на системе в которой вы уверены и если вы уверены что фигне взяться неоткуда (обычно это не проблема, если комп только для разработки).
Впрочем, есть скрипт для PowerShell который отключает Real-Time только для WSL, путём добавления каждого бинарника оттуда в исключения RTP.
PS: Насчёт касперского не знаю, увы. Но если доверяете себе и системе, просто попробуйте его отключить хотя бы в качестве эксперимента.
Сокращение или отказ от пользования смартфонами и прочими излучателями «синего» света. Выработка мелатонина начинается как только прекращается действие «синего» света.
А вы читали статью по вами же приведенной ссылке? А именно тот момент что в экспериментах для освещения использовали ксеноновые лампы мощностью от 450 до 1200 ватт — т.е. на порядки превышающие то что вы можете получить от смартфонов и обычных мониторов даже если будете смотреть на них круглосуточно, да и вообще статья о воздействии освещения, а не излучения мониторов.
Тот "синий свет" который попадает на человека (включая глаза) со стороны мониторов не имеет никаких ощутимых эффектов, кроме сниженной концентрации, усталости и прочих "прелестей" постоянного смотрения в монитор, и вовсе не потому что он "синий", хотя если это будет синий на чёрном — то да, будет весьма неприятно, но на уровень мелатонина это едва ли способно повлиять.
Нельзя считать безопасным встраиваемый ассемблерный код, влияющий на указатель стека.
Если код корректно написан, то он ничем не хуже кода на любом другом (даже "безопасном") языке, нет смысла считать любой код считать потенциально небезопасным просто потому что он (в теории) может таким быть в силу возможностей языка.
А вообще-то всё описанное когда-то давно уже было сделано в виде очень неплохой библиотеки, но почему-то не взлетело.
Наверное, тем что в обратной польской записи операции идут за операндами?
1 + 2 - 3в RPN будет1 2 + 3 -а вовсе не "массив операндов" и "массив операторов".Вы упорно продолжаете путать запись и алгоритм — первое это то с чем имеет дело пользователь, второе (ваши массивы и прочие детали) он вообще не видит (и ему всё равно).
Если бы вам нужно было реализовать обработку выражений именно в RPN — то реализация алгоритма уместилась бы в двух десятках строк (но пользователи вас бы проклинали).
Я буду третий (наверное). Потому что, как уже чуть выше сказали, речь про "запись", да и ваша ссылка говорит о способе записи выражений, а у вас обычный инфикс. Как это реализовано внутри (стеки, регистры etc) совершенно не имеет значения с точки зрения нотации.
Кстати, есть неплохая реализация разбора и вычисления выражений на JS, может вам пригодится в качестве источника идей, раз уж интересуетесь этой темой.
О как… В Фейсбуке новый интерфейс?
Правда, мне не совсем понятно, зачем всё это чистить и ограничивать если проще вообще не пользоваться?
Зачем? Тем кому действительно важен факт физического отсутствия питания камеры или микрофона проще вообще не пользоваться телефоном, подавляющему же большинству остальных вообще пофиг, они и так всю свою жизнь выкладывают онлайн.
Было бы не пофиг, первый же "баг" (в крайнем случае второй) со включенной камерой (как в случае Instagram) убил бы компанию (или сильно её подкосил), но реально это находит отражение в специализированных изданиях, IT-сообщество (и то не всё) негодует, компания извиняется, и все об этом забывают через неделю.
Для того чтобы можно было оптимизировать выполнение операций если конечный результат не зависит от порядка вычисления.
К примеру, если у нас есть нечто вроде:
и при этом значения
cилиdуже находятся в регистрах в связи с более ранним использованием, компилятор может сгенерировать код для вычисления правого слагаемого перед вычислением левого.Кажется, вас не смущает тот факт что сама идея индикации активности (tally light) существовала ещё до появления первого iPhone (и даже самого Apple), ещё в те времена когда только первые телекамеры и микрофоны появились? Там тоже были лампочки, знаете-ли, правда обычно красного цвета. Да и на ноутбуках и прочих веб-камерах индикаторы задолго до iPhone появились.
gcc -Wallтоже предупреждает, хотя логично чтобы это было по умолчанию.Вообще же по спецификации C/C++ порядок выполнения действий в пределах выражения отдаётся на усмотрение компилятору и не определен совершенно официально, любое "определенное" поведение конкретного компилятора — это частный случай.
Не решают, потому что облако служит для единственной цели — хранить данные от устройства (по крайней мере в случае трекера) и отдать их если попросят. Для любых других запросов (кроме самого устройства) — да, облако мастер.
По логике только само устройство (или его пользователь) могут решить какие данные верные, а данные нужны только на случай отсутствия данных в устройстве.
В любом случае для работы с оперативными (доступными на самом устройстве) данными доступ к облаку (и сети) вообще не нужен, особенно для просмотра, потому что данные на которые уже есть на устройстве — по определению мастер (а не те которые в облаке), и именно этот принцип был нарушен Garmin.
PS: Преставьте что вы пишете рассказ и периодически заливаете новые версии в облако, но в какой-то момент облако решает что ваша версия — совсем не мастер, и нужно вернуть то что хранится в облаке. Вы правда этого хотите? Данные трекеров — тот же рассказ.
Ваш вопрос очень абстрактный. Какое устройство? Была ли на нём предусмотрена возможность повторной передачи? Как оно определяет что данные нужно передавать за определенный период? Где хранятся данные (внешний носитель, внутренний, доступный извне, недоступный etc)? Какими метаданными располагает база и какие находятся в передаваемых данных (метки времени, etc)? Есть ли валидация данных (контрольные суммы etc)? Могут ли в принципе переданные данные корректироваться или дополняться пока не было связи?
Но всё же… поскольку устройство (по крайней мере если это фитнес-трекер) — изначальный генератор данных и в конечном итоге их потребитель — то верить нужно только устройству. База должна быть исключительно репликой данных устройства.
Хотя то о чём вы спрашиваете больше вопрос обработки исключительных ситуаций — если устройство изначально не было расчитано на "правильное" взаимодействие с базой, можно предположить два варианта:
Если же оно изначально было расчитано на адекватную обработку, но ведет себя неестественно — это либо очень жёсткий сбой с повреждением критических данных, либо попытка вмешаться в его работу, в обоих случаях автоматически (без ручного анализа данных на устройстве и в базе) мало что можно сделать.
Хотя самая простая стратегия, которая покроет 99% всех случаев — это игнорировать старые данные, тем не менее подтверждая их приём, опционально сравнивая с уже имеющимися.
Если попыток несколько — значит устройство явно в неадекватном состоянии и все попытки передачи данных нужно блокировать, с информированием пользователя, или сохранять только различающиеся данные в пределах первых нескольких попыток и потом всё равно блокировать (потому что это ненормально).
Как я уже сказал, способов зиллион, но нужно знать точно о чём речь и текущую архитектуру.
Доктор или тренер должны получить их лично от меня, на USB стике или в виде файла, или даже просто посмотреть на моём экране — и ни при каких условиях они не должны получать их с сервера в интернет. Если лично не получается — передача в зашифрованном виде на устройство доктора. В любом случае — только push, никаких pull — это единственное что может минимизировать (хотя и не исключить) проблемы с их утечкой и злоупотреблениями.
В тех редких случаях когда доктору нужен постоянный доступ на протяжении длительного времени — нужно обеспечить независимое устройство с правом доступа только у меня и доктора, а при необходимости хранения в облаке — они должны быть зашифрованы, чтобы бы оператор облака не имел принципиальной возможности на них посмотреть.
При этом, я (пользователь) должен иметь возможность в любой момент этот доступ запретить, а также (при необходимости) получить полный отчёт — когда и какие данные использовались или были запрошены доктором, и с какой целью (если это не очевидно — к примеру, тренеру совсем не нужно знать сколько раз я ходил в туалет).
Более того — я, как пользователь, должен иметь возможность получить все эти данные ровно в том виде в котором их получает доктор, а также иметь возможность делать ручной или автоматический бэкап этих данных в структурированном машинно-читаемом виде без дополнительных затрат, в конце концов это мои данные и даже моё устройство.
Плюс ко всему — любые данные которые хранятся в облаке должны быть зашифрованы с ключём доступным только пользователю (или доверенным агентам, которых он сам определяет — исключительно opt in), с детальным трекингом кто, когда и что оттуда вытаскивал.
Конечно, это в идеальном мире...
Если у меня есть сенсор который что-то передает на сервер, каждая единица данных имеет временную метку и непрерывный id, который увеличивается строго последовательно, то есть и устройство и база всегда точно знают что уже там а что нет, и даже способны определить проблемы с синхронизацией таймеров (если это важно). Для особо важных случаев можно даже делать валидацию уже переданных данных, путём банального сравнения последних переданных N блоков или дней или (проще) посредством хешей (это позволит быстро проверять даже очень большие наборы данных).
В сочетании с уникальным идентификатором набора данных (учётка + id устройства) это обеспечивает довольно простой и отказоустойчивый способ передавать только то что нужно, причём в обе стороны (синхронизировать).
На самом деле есть куча способов это решить с минимальными усилиями, было бы желание.
Мастер источником логично считать всё же мастер источник — то есть собственно устройство, ибо только оно производит эти данные, а центральная БД — это просто реплика собранных данных, и что там с ними происходит дальше никак не должно отражаться на устройстве, даже если база исчезнет.
Другое дело если устройства собирают столько данных что они физически нехранимы на нём самом, тут да, проблемы могут быть — но меня терзают смутные сомнения что фитнес-браслеты требуют десятков гигабайт на хотя бы год работы.
Да и конфликты версионности вряд-ли возможны — потому что все (практически) обновления обязательны, без них устройство не допускается к передаче данных, да и без них можно построить архитектуру в виде сенсор-коллекторы-база где коллекторы будут разбираться с форматами и версиями сенсоров и в нужном виде отправлять в базу.
А так… похоже о пользователях думали лишь как об источнике данных, вариант даже просто отсутствия сети длительное время явно не учитывали (хотя это нормальное явление в ряде регионов), что уж тут говорить про катастрофу...
В конце концов, приложения типа GadgetBridge спокойно обходятся без облака, но производители устройств применяют невероятные усилия чтобы без учётки и сети ими невозможно было пользоваться, даже простой автоматический экспорт данных в чём-то типа "csv" там редкость, что уж тут говорить про открытие API для сторонних приложений.
На самом деле нет — предпочитаю жить без людей, совершенно серьезно. Чем меньше личных контактов — тем лучше я себя чувствую, поэтому для меня это не просто слова. Раньше было по другому, теперь так.
Возможно при определённых условиях. В моём понимании свобода — это когда существуют только ограничения чисто физического порядка, например, невозможность переплыть океан чтобы попасть на другой континент, или отсутствие космического корабля для достижения других планет.
А пока мне нужен загранпаспорт и виза для того чтобы (хотя бы) покинуть страну — это хоть и свобода в какой-то мере, но всё же далека от истинной свободы.
Да и космонавтами станут не все желающие, а только очень миксроскопическая их часть, даже если все они соответствуют требованиям, и квадрокоптеры без лицензии не особо позапускаешь, даже если они никому не мешают (причём не только в РФ) — это всё же очень условная свобода.
Про свободу слушать музыку на любой громкости и прочие свободы я ужу молчу — потому что все без исключения свободы человека живущего в обществе ограничиваются этим самым обществом, прямо или косвенно.
Если же говорить про отшельника в условном космическом корабле, на котором есть всё для жизнеобеспечения (и лечения) — вот это пожалуй будет действительно максимальное приближение к свободе — вся вселенная перед ним, он ограничен только физикой и продолжительностью жизни, то есть чем-то гораздо более объективным чем неестественная окружающая среда вроде общества.
Все ваши свободы ограничены обществом, государством, законами, финансовыми и технологическими возможностями.
Попробуйте стать космонавтом и расскажите о свободе выбора профессии, или попробуйте запускать квадрокоптеры в свободное от работы время и расскажите о свободе выбора хобби. Наконец, попробуйте поехать в Северную Корею (или даже просто куда-то где сейчас закрыты границы в связи с короновирусом) и расскажите о свободе перемещения.
У меня возникает опасение что если подобное случится с Alexa, то как минимум четверть её пользователей умрут от голода, холода или жары...
Свет, отраженный от поверхности освещённой прожектором явно "мощнее" чем свет излучаемый экраном смартфона или даже монитора. Если бы это было иначе, то проще было бы светить им в глаза собственно мониторами, или я ошибаюсь?
В любом случае статья не про мониторы, и ссылка на неё в соответствующем контексте просто нерелевантна.
Я добавлял соответствующий WSL пакет в
%USERPROFILE%\AppData\Local\Packages— у меня это Ubuntu (есть в названии, типаCanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc).На этот счёт у них есть древний тикет с жалобами, но воз и ныне там. Народ в нём пишет что само по себе исключение якобы не помогает (хотя я явно это ощутил), и что нужно отключить Real Time Protection (причём в Group Policy, а не из UI) — но это можно делать только на системе в которой вы уверены и если вы уверены что фигне взяться неоткуда (обычно это не проблема, если комп только для разработки).
Впрочем, есть скрипт для PowerShell который отключает Real-Time только для WSL, путём добавления каждого бинарника оттуда в исключения RTP.
PS: Насчёт касперского не знаю, увы. Но если доверяете себе и системе, просто попробуйте его отключить хотя бы в качестве эксперимента.
А вы читали статью по вами же приведенной ссылке? А именно тот момент что в экспериментах для освещения использовали ксеноновые лампы мощностью от 450 до 1200 ватт — т.е. на порядки превышающие то что вы можете получить от смартфонов и обычных мониторов даже если будете смотреть на них круглосуточно, да и вообще статья о воздействии освещения, а не излучения мониторов.
Тот "синий свет" который попадает на человека (включая глаза) со стороны мониторов не имеет никаких ощутимых эффектов, кроме сниженной концентрации, усталости и прочих "прелестей" постоянного смотрения в монитор, и вовсе не потому что он "синий", хотя если это будет синий на чёрном — то да, будет весьма неприятно, но на уровень мелатонина это едва ли способно повлиять.
Если код корректно написан, то он ничем не хуже кода на любом другом (даже "безопасном") языке, нет смысла считать любой код считать потенциально небезопасным просто потому что он (в теории) может таким быть в силу возможностей языка.
А вообще-то всё описанное когда-то давно уже было сделано в виде очень неплохой библиотеки, но почему-то не взлетело.