Михаил Ливач

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

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

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

Использовать средства парсинга, которые умеют исполнять javascript: headless браузеры, Selenium и т.п.

Хотя, в данном конкретном случае нужно просто быть внимательнее и отправлять POST-запрос, а не GET.

надо
$i < count($arr) - 1
потому что дальше в сравнении $i+1, отсюда и ошибка была (выход за пределы массива)

Используйте Constructor property promotion чтобы писать меньше букв)

<?php

class Product
{
    public function __construct(
        public int $id,
        public ?int $parentId = null
    ) {
    }

    public function getParentId(): ?int
    {
        return $this->parentId;
    }

}

$obj = new Product(1);
if (!empty($obj->getParentId())) {
    echo 'ok';
}

Либо уберите типизацию у свойства и при public $parentId; ошибки не будет. Всё как и написано в тексте ошибки, нельзя обратиться к типизированному свойству до его инициализации, а значит нужно либо задать значение по умолчанию при описании свойства, либо через конструктор, либо вызвав setter.

uninitialized и typed properties
https://php.watch/versions/7.4/typed-properties#un...

1. Разве по умолчанию свойства не null?
2. У меня 20-30 свойств. Для каждого что-ли делать так? Код какой-то не логичный и громоздкий.

1. Нет, в данном случае у свойства нет значения, оно не инициализировано. Какое значение вы хотите получить из свойства, если у свойства нет значения? То, что php в некоторых случаях при отсутствии типов выполняет неявное приведение к null не распространяется на ситуации, когда вы явно указали типы, а значит хотите явного поведения.
А вот Null - это уже значение, которое используется для передачи отсутствия значения как значение.

2. Если заботитесь о качестве кода, то да. Все абсолютно логично, php подсказывает вам, что вы вероятно забыли инициализировать переменную, т.е. допустили ошибку, обратившись к переменной раньше, чем положили в нее значение.
Здесь нет ничего "громоздкого", просто вы явно описываете поведение. Можете этого, конечно, не делать, например не использовать указание типов и расчитывать на то, что php сам что-нибудь подставит - но, очевидно, это ненадежный путь, ведущий к ошибкам.
В идеале, вы должны задать свойству корректное значение, а затем его использовать. Т.е. использовать 1 единственный тип. Не всегда логика это позволяет и тогда нужно инициализировать переменную значением null.

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

Дока
Не так
'className' => '\Namespace\GlobalLogHandler',

А так
'class_name' => '\Namespace\GlobalLogHandler',

Как получить строки таблицы:

// если гарантируется отсутствие thead и tfoot, или их содержимое также должно учитываться
const { rows } = table;

// если tbody один
const [ { rows } ] = table.tBodies;

// если tbody несколько
const rows = Array.prototype.flatMap.call(table.tBodies, n => [...n.rows]);
// или
const rows = [].concat(...Array.from(table.tBodies, n => [...n.children]));
// или
const rows = table.querySelectorAll('tbody tr');

Как получить средний элемент:

const middle = arr => arr[arr.length >> 1];
// или
const middle = arr => arr[Math.floor(arr.length / 2)];
// или
const middle = arr => arr[Math.round(~-arr.length / 2)];
// или
const middle = arr => arr[(arr.length - arr.length % 2) / 2];

Всё, можно доставать ячейку:

const cell = middle(middle(rows).cells);
// или
const cell = middle([].reduce.call(rows, (acc, n) => (acc.push(...n.children), acc), []));
// или, без получения строк
const cell = middle(table.querySelectorAll('tbody td'));

Задача, конечно, максимально странная, но решается она так:

select zagolovok from (
    select 1 as sort, name as zagolovok from sotrudniki
    union
    select 2 as sort, nazvanie as zagolovok from transport
    order by sort, zagolovok
) as tmp

Вы получаете значение span один раз при запуске скрипта и туда попадает первый span первого div.
Вам же нужно при клике брать span внутри кликнутого элемента:

div.addEventListener('click', function(e) {
    let span = this.querySelector('span');

    set.add(this.textContent); 
    let arr = [...set];
    el1.textContent = arr.join(', ');
    
    sum += +span.textContent;
    console.log(span.textContent);
    el2.textContent = sum;
})

Во втором случае функцию в data вы не вызываете:
data().init

У компонента catalog.smart.filter (Умный фильтр) есть параметр SAVE_IN_SESSION (Сохранять установки фильтра в сессии пользователя), выставьте его в N

Потому что это 2 разных графика, 2 разных примера. Могли бы на втором обозвать вместо f и g f` и g`. Но авторам, наверно, было лень.

"... поскольку Тета обозначения более сильные чем О обозначения..."
Ответ кроется тут. Тета - более ограниченное множество, чем О, т.к. есть ограничение снизу:
- Тета = g1(n) <= f(n) <= g2(n)
- О = 0 <= f(n) <= g2(n)

Можешь заметить вот этот промежуток [0; g1(n)]. Это и есть разница между тета и О.
Таким образом, Тета меньше чем О, поэтому не может быть надмножеством. Ну а так как верхняя граница одинакова, то можно сказать, что О = Тета + [0; g1(n)]

JOIN так и должен работать, а нужно использовать EXISTS, что-то вроде

SELECT servers.serverInviteID, servers.serverDescription
FROM servers
WHERE EXISTS (
  SELECT * FROM tags
  WHERE tags.serverInviteID = servers.serverInviteID
  AND tags.tag IN ('onetwothe', 'oo')
)

Обычно при стриминге информации разделяют 2 процесса. Первое - это регистрация
событий с устройств. Это обычно запись в Message Hub, Kafka, RabbitMQ, Apache Pulsar e.t.c.
прочие брокеры или системы которые работают с очередью. Тут - главная задача просто успеть
регистрировать событие. С этим системы очередей справляются отлично.

При регистрации событий никакого синхронизма между устройствами нет и в принципе
не может быть. По законам физики и по часовому времени и по прочим сложным процессам
которые идут в мире. Мы не можем вообще гарантировать точного совпадения часов на всех
устройствах поэтому фактор времени мы пропустим. К свойствам дублирования и грязи в атрибутах
на этом уровне можно относиться очень толерантно и не требовать никакой сложной логики фильтрации.
Если допустим 99.9% событий зашло ровными - оно и ладненько. Дальше почистим.

Дальше идет - процессинг. Вот здесь уже может вступать в игру MySQL сервер с его логикой
транзакций. Счетчиков. Уникальностей. Сурогатных или натуральных ключей. Партишенинга
и прочего. Здесь у вас уже может возникнуть лимит на скорость генерации (inserts) но он будет
мягкий потому что очередь уже смягчает удар.

Если у тебя приложение - тайм-критичное и клиент хочет видеть КАЖДОЕ событие как счетчик
в браузере то здесь тебе скорее всего надо отказаться от MySQL и попробовать что-то другое.
Что - я не знаю. Надо исследовать глубже use-case. Обычно разработка таких систем - это
компромисс между одним и другим. Идеала тут не будет.

Нашел решение.
Мой косяк, я установил arch через скрипт archinstall, и видимо linux-headers не установились.

sudo pacman -S linux-headers
sudo pacman -S broadcom-wl

Рестарт системы
Потом чере networkmanager подключился

nmcli device wifi list
nmcli device wifi connect SSID password PASSWORD