Григорий Боев

https://developer.mozilla.org/en-US/docs/Web/API/D...

Я бы сделал так загрузил бы документ и прошелся бы по дочерним элементам
document.html
и выводил бы только теги

Такого рода проблемы все и всегда решаются однотипно.
1. Необходимо сформулировать критерии наличия проблемы.
Как именно пропадает интернет, насколько часто, как надолго. Это нужно для диагностики. поиска причины и определения ушла ли проблема после принятия каких либо мер.
2. Делить проблему на части и проверять части по отдельности.
Самый эффективный способ делить - это пополам. Отсекаем часть сети и проверяем наличие проблемы в обеих частях (если есть возможность) или в одной из частей.
3. Когда найден минимальный проблемный участок, который уже нельзя или бессмысленно делить - заменяем его.
4. Помним, что чаще всего сложные проблемы - это композиция нескольких более простых. которые по отдельности могут не проявляться. В вашем случае может быть проблема, связанная с нагрузкой на роутер, например, которую создает один из услов из-за плохого контакта обжима и большого объёма биттых пакетов. Устранив одну из причин, вы, может быть, сделаете проявления проблемы реже, но не устраните её полностью. К примеру, если замените ротуер, битые пакеты будут всё равно будут нагружать вашу сеть и портить ее производительность, но это будет не так очевидно. Переобжав коннектор вы избавитесь от части нагрузки, но еслив ваш ротуер работал на переделе, то лишний вафай-клиент или тяжелый видос в сети сможет его снова нагрузить до критического снижения производительности.

Итак, пробежимся по перечисленным пунктам сначала.
1. Критерии. Поиск критериев - это часть решения. Обычно в этом случае нуно сорать необходимую статистику. Есть куча софта, который это умеет делать, но пинг есть всегда под рукой.
Для этой тулзы есть две полезных опции: ключ для бесконечного пинга и размер пакета.
В разных ОС эти ключи немного разные, поэтому ищите их отдельно, у меня нет винды под рукой, поэтому не стану на этом заострять.
Скаж лишь, что пинговать лучше большими пакетами, жалетально превышающими размер TTL, прописанный в роутере. Тогда такой пинг будет реже проскакивать в периоды хорошей связи, то есть выловит больше пролблем.
Пинговать нужно в отдельных окнах сразу несколько хостов:
- ya.ru - этот хост всегда отвечает на пинги и выявит проблемы с DNS
- 8.8.8.8 - это гугловый DNS-сервер, тоже всегда отвечает на пинги, покажет, что связь с инетом есть даже если DNS, прописанныйна компе не правильно работает.
- 192.168.0.1 - или какой там IP у вашего роутера. Нужно. чтбы отделить проблемы с инетом от проблем с внутренней связностью до роутера
- 192.168.0.x - ip одного из компов в сети. Я обычно пингую несколько компов, доступных через баксимальное число потенциально проблемных узлов - ethernet-розеток, свичей, вайфай-соединений... Этот пинг поможет понять где проблема, во внутрисетевой связности или в последней миле.

Учтите, что проблемы часто бывают комбинированные и каждое сочетание симптомов будет свидетельствовать о раных проблемах.
Да, тревожным принаком может служить не только пропадание пакетов, но и скачки в длительности их возврата, особенно если такие длительности достигают 500мс и выше. Но и скачки от 3мс до 250мс тоже будут свидетельствовать о каких-то проблемах.

Запускать пинг на всех компах лучше одновременно и на некоторое время. Например минут на 20. Потом по статистике будет видно сколько где пакетов пропало.

2. Если критерии наличия проблемы позволяют, то можно попробовать отрубать части сети и смотреть наличие проблемы. Это я в том смысле, что если проблема происходит в среднем раз в пару-тройку часов, то отрубать на многие часы части сети при диагностикем ожет быть неприемлемым.
Редкеи пробемы дольше отлавливать. Но напоминаю, что критерии можно детализировать, ведь если пакеты у вас пропадат относительно редко, то скачки времени их возврата могут случаться чаще и подсвечивать проблему. Также можно сделать рамер пакета близким к максимальному, это должно тоже в некоторых случаях участить проявление проблемы.
Иногда не мешает нагрузить сеть комированием по локалке большого файла. В линуксе можнно с помощью утилиты tc послать большой поток рандомных байт на любой сокет..
3. Плавающие проблемы случаются из-за плохого обжима, перебитого жверью кабеля, перегрызенного UTP в плинтусе, из-за умиращих конденсаторов в блоке питания роутера (БП может не выдавать необходимого при нагрузках тока, но вольтметром такая неисправность не будет различима без нагрузки). Вообще старые (да и не только) роутеры могут страдать поплывшими электролитическими конденсаторами не только в блоках питания.
Хорошо, когда можно подменить роутер.
4. ну с четвертым пунктом ничего не пососветуешь, только разделать и тестировать все по отедльности и в разных сочетания и да поможет нам ктулху.

А для тех, кто дочитал этот опус до конйа - интересная задачка. Что пингуют эти команды, как и почему?

ping 1.1
ping 2130706433

Тех, кто знает, попрошу не спойлерить=)
Пусть для кого-то будет сюрпризом этот дивный мир=)

UPD. Простите за адское количество опечаток в тексте. Писал в спешке и с непривычной клавиатуры. Исправлю всё попозже. Не ожидал, что многим ответ придётся по душе. Вроде ж накапитанил как мог.

В общем случае - никак

Но можно сделать этот процесс на столько сложным, что смысла в этом уже никакого не будет. С помощью обфускации кода и использовании алгоритмов шифрования данных, передаваемых в браузер (не про https а когда данные, загружаемые браузером и передаваемые в скрипты/данные - зашифрованы). А чтобы конечный скрипт нельзя было вытащить через модификацию браузера (например логировать eval) то можно саму виртуальную машину, исполняющую скрипты, реализовать на js (wasm).

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

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

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

function sum(arr) {
  let result = 0;

  for (let i = (arr.length - 1); i !== 0; i--) {
    if (arr[i] === 0) return result;
    result += Math.abs(arr[i]);
  }
  return result;
}

console.log(sum([2.1, 3.1, 4.1, 6.1, 7.1, 9.1, 11.1, 0.0, 2.2, 1.4])); // 3.6
console.log(sum([2.1, 3.1, 4.1, 6.1, 7.1, 9.1, 11.1, 0.0])); // 0

https://www.155la3.ru/

А оно вам надо?
Возьмите плисину и сгенерируйте схему, выйдет дешевле

const converter = {
  "m":{
    "cm":{k:0.01	},
    "in":{k:0.254	},
    "ft":{k:0.3048	},
  },

Тут можно улучшить. Если посмотреть на этот JSON документ с "прищуром". То можно увидеть
полносвязный граф. Например узел футов ("ft") имеет свое ребро в направлении дюймов ("in").
И все другие также.

Нужно ли нам описывать так много цифр? Я-бы предложил одну таблицу. Все меры длины отобразить на метры.
Тогда формула перехода ft -> in будет всегда идти через метрическую систему. ft -> m -> in.

А ребра графа мы все равно сможем получить но уже путем вторичных расчетов если надо.

так
https://www.howtoexcel.org/generate-qr-codes/

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

80Тб это значит несколько дисков. В зависимости от того, как на их основе построен архив, можно попробовать по одному диску от архива отсоединять и на него восстаналивать (так не получится если на всех дисках создан один огромный raid массив)

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

Doom - это была одна из первых игр где была реализована в полной мере техника BSP (Binary-Space-Partition). Это позволяло в реальном времени очень быстро сортировать и рендерить полигоны без привлечения Z-Buffer. (Рендеринг был чисто прогарммный. На то время еще не было ускорителей 3Д графики и видеокарточка умела только отображать память на экран. ) Игра не была по настоящему трехмерной. А только рализовывала 1 этаж. Рендерить надо было только пол и потолок. Для каждой точки где стоял персонаж. И наклонных горизонтальных поверхностей в ней не было как раз по этой причине. Ее называли 2.5-мерной игрой. Было также много идей оптимизации вычислений. Например вместо вещественных чисел - целые 32х битные с fixed point.

В скобках замечу что это был 1993 год и на дворе было царство Intel 286/386. Это были машины с тактовой частотой меньше ваших телефонов (Pentium только только релизнулся и еще ни у кого не был). И трехмерный Doom был прорывом. На моем тогда еще 386SX от подтормаживал но играть было можно. И со звуком для SoundBlaster. И конечно это было лучше чем Wolfenstein.

Аналогичное было реализовано в Duke Nukem 3d. Но Дюк был менее популярен ИМХО. Были и масса других 3д игр в жанке RPG но они были не такие динамичные. Походовые в основном.

Вобщем сегодня если вы гейм-дев то вам желательно хотя-бы ознакомиться с техниками оптимизации которые были в Doom. Можно почитать и про Quake но это просто развитие идеи BSP деревьев для полного 3D с 5 или 6 степенями свободы. Еще можно почитать про реализацию игры Esctatica. Там не на полигонах а на шариках или эллипсах реализована игровая графика. Тоже интересно.

UPD: Заменил MMORPG на RPG.