Михаил Р.

То есть Вы упорно не хотите изучать теорию?

UPD:
Там же луч

Открыть лучше в отдельном окне. На ЛКМ можно переместить точку начала луча.

А ошибка где? Если вы про то, что у вас больше 10К изменений, о чём вам VSCode говорит, то сами виноваты. Добавьте в .gitignore лишнее и не пихайте всё подряд в репозиторий.

Привет.

Burp Pro, особенно с некоторыми плагинами, даст неплохой результат. OWASP Zap можно подтянуть до аналогичного уровня, но он больше FP даёт в процессе работы. В перспективе аналогичной функциональностью может обзавестись Caido - потенциальный конкурент Burp Suite.

+ Acunetix, Intruder.

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

VPN-туннели между площадками и подклюние принтеров на сервере. Лучше, если принтеры сетевые и подключение будет сразу по ip-адресам принтеров. Хуже, если расшаривать доступ к принтерам на ПК, но всё равно худо-бедно будет работать.

Всё дело в MIME-type. Если в заголовке от сервера передаётся MIME-type, связанный с каким-то расширением файла, на который есть ассоциация в операционной системе клиента, то ОС запустит процесс скачивания

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

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

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

function Foo(arg) {
    this.bar = function() {
        return arg;
    };

    return this.bar();
}

const notfoo = Foo('not foo');
console.log(notfoo); // "not foo", т.е. notfoo - это не новый Foo, это строка текста.
console.log(notfoo.bar); // undefined, что логично, у стандартной строки никакого bar нет.

const foo = new Foo('foo');
console.log(foo); // [object Object], т.е. вот это - настоящий новый Foo.
console.log(foo.bar); // function() { ... }, и метод bar в нем есть.
console.log(foo.bar()); // "foo"

https://www.raspberrypi.com/products/raspberry-pi-5/
Стявят VPN прокси сервер (выходную TOR-ноду)
Чтобы потом "товарищи" приходили к Вам, а не к ним или их клиентам

Засовывать всё в докер, и сразу писать compose-файл? Но можно ли это всё потом интегрировать с IDE?

Да все верно. В нижней панели, там же где терминал и питон консоль есть вкладка Services, там и логи и управление всеми запущенными (микро)сервисами.
В compose достаточно стрелку ткнуть, он тебя первый раз попросить конфиг настроить и все.


Так же можно с ssh работать так что можно хоть локально запускать, хоть на удаленной машине

у меня сборка где весь мусор вырезан

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

Алгоритм:
0. В любом случае есть родительский контейнер, поэтому работаешь от него. Лучше чтобы у него был id, тогда при работе функции отслеживания ты сможешь её запускать с нужным айди, она будет универсально и поддерживать множество независимых подобных контейнеров с этим меню.
1. По клику ищешь текущий isActive (с учетом специфичности родительского контейнера) и снимаешь все активные.
2. Делаешь кликнутый активным.

Условный пример. Не продашн рэди) Но смысл ясен.

У меня поднят xray (VLESS, Reality - в инете инструкций по настройке полно) на зарубежном хостинге,
на серверах где нужен доступ к подобным ресурсам стоит все тот-же xray но настроенный как обычный прокси (SOCKS, http, https)
в настройках Docker указан этот (локальный) прокси, который в свою очередь пересылает запросы на сервер зарубежом.
Все работает отлично

Для начала для нас важно осознать, что у разных фильтров разная вычислительная сложность. Они не все "плохие". Алгоритмы для brightness, grayscale, hue-rotate и других манипуляций с цветом выполняются за O(1) для каждого пикселя. Т.е. нагрузка на железо растет линейно в зависимости от площади элемента на экране. Это не так страшно. А вот фильтры размытия, blur или drop-shadow, имеют сложность где-то в районе O(R^2). Там есть разные варианты оптимизаций, но в среднем мы говорим именно о квадратичной зависимости от радиуса размытия. И это для каждого пикселя. Именно отсюда мы имеем сильные тормоза при попытке что-то большое размыть на пол экрана. Дохлые видеокарты телефонов и ноутбуков не вывозят. Браузеры не умеют такие вещи переиспользовать, так что это переразмытие происходит снова и снова, и мы имеем что имеем.

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

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

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