Алексей Уколов

серьезно, в который раз? ты на каждый "детский" вопрос так и будет набегать сюда? т.е читать доки, специализированные форумы, гуглить, где подобное кучу раз разжевано ты вообще не хочешь?

Там список хранит данные о rect из pygame, это отрисовка поля

Так передавай данные так, чтобы их удобно было парсить. Простейший вариант - используй json.
Например, сначала генерируешь данные для отправки:

import json
# в словаре для отправки могут быть только числа, строки, bool, списки, словари, None.
# и никаких других объектов. Так что переделываем список rect в список списков.
# как из rect координаты добыть ищи сам
rects_to_send = [ [rect.x, rect.y, rect.w, rect.h] for rect in rectangles ]
data_to_send = {  # в словарь можно также добавить другие данные
  'rects': rects_to_send,
}
string_to_send = json.dumps(data_to_send, ensure_ascii=True)+'\n'
# дальше через сокет эту строку и передаёшь

Ну и чтение аналогично.

import json

received_string = ...  # это строка, которую ты получил из сокета
received_data = json.loads(received_string)
#received_data будет таким же словарём, как data_to_send выше
for x, y, w, h in received_data['rects']:
  ...  # рисуешь эти прямоугольники у себя

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

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

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

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

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

В action ты кладёшь функцию onClick с сигнатурой (item: LinkItem) => void, а требуется (data: MobileMegaMenuItem | LinkItem) => void, , т.е. функция которая умеет работать и с тем и с тем. Подразумевается что onClick как раз не умеет и может привести к ошибке, потому и не даёт.

Используй дженерик чтобы вывести конкретный тип:

export const useOpenMenuByHash = <Data extends MobileMegaMenuItem | LinkItem>(
    data: Data[],
    action: (data: Data) => void,
    actionRoom?: () => void
) => {
  //...
};

useOpenMenuByHash(data, onClick); // ok

Ну или кастуй руками:

useOpenMenuByHash(data, onClick as (d: LinkItem | MobileMegaMenuItem) => void);

Вам должно быть виднее, что там за формат времени у Вас, но, на первый взгляд, это выглядит как объединение без пробелов:
Год месяц число часы минуты секунды.
Соответственно Ваш запрос легко превращается в интервал (или два условия больше - меньше)

IP определяются обычным перебором. При отправке на порт RDP нужного запроса, злоумышленник получает hello от сервиса. Дальше - брутфорс логина и пароля. Возможно логин и пароль подслушивают сетевым сниффером в общедоступных сетях. Бывают определённые 0-day уязвимости, которые позволяют зайти, выполнив специальный запрос. Если хотите подробностей - откройте у себя сниффер входящих запросов на RDP порту. Посмотрите - какие запросы к Вам приходят, какие методы при этом используются. Будет интересно )

Тебе нужно найти автора/правообладателя, а не просто первый попавшийся сайт.

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

Предположу, что вас интересует не вопрос "почему такая цена", а вопрос "чем они отличаются".

Насчет "чем отличиются" есть вот такое видео, надеюсь, станет понятнее.

Вопрос похоже поставлен некорректно.
На гитлабе хранятся только исходники. Там не надо выполнять миграции.
Создать миграцию - это сделать файл миграции, который будет преобразовывать БД.
Выполнить миграцию - это применить логику этого файла к конкретной БД.
Выполнять миграцию вы можете на любой машине, но подключаться при этом должны к конкретной БД на которой хотите применить эту миграцию.
Обычно к какой БД подключаться указывается в настройках.
Если у вас есть продакшн-сервер, на котором запущен проект, то миграции делаются (выполняются, применяются к БД продакта) при деплое (релизе) очередной ревизии. Обычно это происходит после успешного слияния текущей рабочей ветки в релизную.
Есть такой механизм, который называется CI\CD. Он отвечает за обнаружение нового коммита в релизной ветке, сборку продукта (докер-образов, например) и выкатку (остановку старой и запуск на проде новой версии продукта). При этом настроен автоматический запуск миграций.