Михаил Р.

Задачи? список где в бизнесе не применяется AI будет короче.

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

Замени, товары на документы, текст, на картинки, звук, видео, любое представление информации. Возможности для бизнеса безграничны.

ИИ за 24 часа, это всегда потеря времени. Развитие это своего рода, сложный процент + определенный шум. Что бы это работало, нужно основание больше 1 и время. Основание, это математика, и дело не в каких то формулах, а в определенном развитии мышления.

Неправильно настроили.
Галочку встроенный tun снимите.
А при самом подключении, ставьте ее там вверху справа.

Там не зря стоит звездочка над белым списком, и над встроенным tun.

Тут нужно понять такую идею, что ресурс - это неотъемлимая часть программы, которая должна существовать для ее нормальной работы и именно поэтому помещается в resources и существует внутри одного jar-файла. Если эти файлы убрать из jar, то они перестают быть "ресурсами", а становятся обычными файлами в файловой системе и работать с ними нужно соответственно - через пакеты java.io/java.nio условно

limit_req_zone

В качестве ключа можно использовать текст, переменные и их комбинации.
Запросы с пустым значением ключа не учитываются.

С помощью map новой переменной присваивать либо пустую строку либо $binary_remote_addr.

limit_req_zone $bad_locale zone=zh_limit:10m rate=10r/s;

map $cookie_locale $bad_locale {
    default     "";
    "zh"        $binary_remote_addr;
}

Дальше использовать limit_req zone=zh_limit как обычно. Ограничивать будеть только тех кто с нужной кукой.

Ещё вариант $http_accept_language если нужно проверять содержимое заголовка Accept-Language.

map $http_accept_language $bad_locale {
default     "";
~^zh        $binary_remote_addr;
}

Я рекомендую Gitlab
- Можно хостить весь Gitlab у себя. Вначале это может показаться лишним, но многие работодатели так делают, поэтому навыки по работе с Gitlab пригодятся.
- Отличный CI. Как по мне, гораздо лучше чем Github actions
- Проекты в Gitlab можно спокойно и очень просто синхронизировать с тем же самым Github прямо из интерфейса Gitlab, таким образом мы получаем преимущества обеих систем.

bitbucket всё, забудьте о нём.

System.Drawing
Загружаешь классом Image, превращает в битмап (не сжатый набор пикселов) с помощью Bitmap, у него есть метод bitmap.Clone в парметрах указываешь прямоугольную область (стороны параллельны осям) ну и обратно сохраняешь тут же bitmap.Save или отобразить как фон любого элемента UI или канвас

Для различных трансформаций изображения есть Graphics, там есть к примеру поворот на произвольный угол с помощью RotateTransform

У Google есть форма, через которую можно жаловаться на подобные сайты. При большом количестве жалоб, сайт удаляют из выдачи, как это было с qaru.site.

Какие БД используют крупнейшие торговые сети для хранения заказов?

В Магнит и X5 используются PostgreSQL, Greenplum и Clickhouse. В Эльдорадо во времена моей работы был Oracle и MS SQL Server, сейчас наверняка на PostgreSQL переехали.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Опять же не знаю, как сейчас, но 13 лет назад у Эльдорадо была довольно устойчивая иерархическая инфраструктура. Часть сервисов жила в двух ЦОДах, часть в серверных региональных офисов, часть на серверах магазинов, плюс кассы какое-то время могли продолжать работать вообще самостоятельно.

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

WordPress, как уже заметили выше, лишь инструмент. Для меня WP это лишь админка. Раньше для создания интерфейса админки нужно было использовать плагины вроде Advanced Custom Fields. Сегодня развивается система блоков для редактора, которые, кстати, пишутся на React. Как рисовать клиентскую часть по сути не важно. Можно использовать классический паттерн: только php. В таком случае обратите внимание на тему-боилерплейт Sage, а так же на окружение для WP "Bedrock". С ним можно будет коппозером устанавливать плагины и темы, и сам WP тоже.
По поводу сайтов за 1000 рублей вы зря. Я делаю свои проекты исключительно на WordPress, но у меня и специфика проектов особенная, там вообще не важно на чем, нужна удобная админка для контента. Знания WP никак не влияют на зарплату, влияют только ваши реальные знания в разработке в целом.