Армянское Радио

const arr = [10, 20, 30, 50, 235, 3000];
const digits = [1, 2, 5];
for (const num of arr) {
  const digit = (num / 10 ** (Math.log10(num) | 0)) | 0;
  if (digits.includes(digit)) {
    console.log(num);
  }
}

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

Если по мультиметру давление выходит так же как и на приборе - сдох датчик. Если по мультметру и по прибору расхождение - сдох прибор.

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

Групповые политики

LDAP, MS AD
как вариант...

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

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

Сайт может манипулировать другими сайтами через их уязвимости, например если где-то есть XSS уязвимость - он может эту уязвимость эксплуатировать.

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

До появления IDE это могло считаться решением.
Сейчас - никому не нужный и даже мешающий костыль.

Собственно, класс на тысячи строк - сам по себе не проблема.
А вот то, что его хочется раскидать по пяти файлам - явный намек на то, что для упрощения кода требуется рефакторинг.

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

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

2. противоположный, использование одной таблицы key-value для нескольких разнородных справочников (id, value, table_name), в 99% случаев можно использовать один сиквенс (одну последовательность идентификаторов), вам же не обязательно чтобы разные справочники начинали счет своих строк с одного и того же числа 1.
Недостаток - база данных теперь не сможет контролировать что вы используете непротиворечивый идентификатор (можно в запись одного справочника указать номер из другого), хотя несуществующий так же нельзя будет указать (и будут работать delete cascade), так же удобной автогенерации sql не будет. Структура будет проще, так же интерфейс редактирования таких справочников может быть один вместо кучи форм и добавлять новые справочники будет сильно проще (хотя с точки зрения разработки нет особой разницы, один insert ты написал или create table перед этим)

3. не хранить справочники в базе данных вообще, т.е. за значение справочников отвечает бакэнд (хранятся в статичных файлах или в коде) самый дибильный подход, редактировать такие справочники скорее всего только руками в конфигах/исходниках. Недостатки - база данных совсем не будет знать ничего о значениях и не сможет ни проконтролировать ни помочь с запросами
Но это позволит снять немного нагрузки с базы данных, сделает структуру проще и позволит перенести управление значениями справочников на откуп ide редактора (если хранить значения справочников в коде, можно дать значениям имена переменных, так как в коде часто их так или иначе заводить придется)

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

Ни в коем случае НЕ используейте самописные крипто-либы. Если нельзя использовать XOR для "шифрования", то ни в коем случае не испоьзуйте самописных библиотек. Криптографические библиотек иразрабатывают сотни человек десятками лет и они всё-равно содержат ошибки и уязвимости. Самописная либа на 99.99999% будет уязвима.
Конкретных либ рекомендовать не буду, но я бы выбирал исключительно бибилиотеки, которые реализуют хорошо описанный алгоритм с открытым кодом (или хотя бы математическим описанием алгоритма шифрования). Если алгоритм шифрования засекречен, то независимые эксперты не могут его проанализирвоать и указать на ошибки и нет причит ему доверять.