Дмитрий Макаров

Ну чуть чуть кнчн увеличится пинг - потому что роутеру надо будет как то пакеты обработать. Но скорее всего даже в тестах вы это не заметите. Если кнчн роутер нормальный.

Я полагаю, что такие магазины сохраняют всё, например в 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-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

Не гошник, но расскажу в целом.
1. На 1 уровень абстракции меньше. При работе с ORM нужно думать одновременно и об особенностях твоей ORM-ки и об особенностях базы.
2. На сыром SQL некоторые вещи сделать проще, чем с ORM-ками.
3. Лучше сырой SQL, чем тупая ORM-ка.
4. Некоторые ORM-ки могут негативно влиять на производительность.

Если тебе приходится при работе с ORM писать куски SQL-я (например для WHERE), передавать названия колонок в параметрах, и при этом ты не можешь использовать специфику твоей базы не опускаясь до уровня сырого SQL, то это плохая ORM.

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

Нормальные ормки я пока видел только:
1. В C# из-за Linq
2. В Rust из-за макросов.

Уберите из docker-compose
"ports:
- "5400:5432"
и порт не будет публиковаться наружу, будет доступен только на внутреннем ip адресе вашего контейнера docker.
Для подключения или используйте внутренние имена контейнеров, или создайте отдельную подсеть docker (подсеть по умолчанию не дает выдавать контейнерам статические ip адреса) и переведите оба контейнера на ее использование с выдачей статических ip адресов.

Самого запуска бота в коде нет. Собственно поэтому и ошибок нет без запуска.
Последней строчкой
bot.run(TOKEN)

P.s ознакомьтесь с правилами ресурса и исправьте вопрос, если надеетесь на дальнейшую помощь

Помогла команда: netsh int tcp set global autotuninglevel=normal.
Страничка с инструкцией: https://pureinfotech.com/disable-window-auto-tunin...
Нашел ответ из вопроса по ссылке: Почему скорость интернета в 20 раз ниже, чем та, которая должна быть?

System.PlatformNotSupportedException: UI not available for copy or move

По моему все доходчиво. Платформа не поддерживает данный метод.
Выходов несколько.
Первый спросить систему кто она и выполнять банальное File.Move для линукса
либо ловить эксепшен и делать то же самое в обработчике

Запишите указатель в переменную и отдайте адресс этой переменной.
Примерно так.

#include <iostream>

void bar(int n) {
    std::cout << (n*n) << std::endl;
}

void foo(void(**ptr)(int)) {
    (*ptr)(4);
    (*ptr)(40);
}

int main () {
    void(*c)(int);
    c = bar;
    foo(&c);
}

https://godbolt.org/z/heaWxPP7j

UPD: Похоже, проблема в библиотеке
https://github.com/espressif/arduino-esp32/issues/7675
Исправляющий комит
https://github.com/espressif/arduino-esp32/commit/...

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

#include <iostream>
using namespace std;

using esp_spp_cb_event_t = int;
using esp_spp_cb_param_t = void;

void btCallback(esp_spp_cb_event_t event, esp_spp_cb_param_t *param) {
    cout << "btCallback" << endl;
}

class MyBt {        
public:
    typedef void (*callback_type)(esp_spp_cb_event_t, esp_spp_cb_param_t *);    

    void register_callback(callback_type cb) {
        cb(0, nullptr);
    }
};

int main()
{    
    MyBt bt;
    bt.register_callback(btCallback);
    return 0;
}

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

Всегда можно к чему-то придраться.
Качество архитектуры можно понять только в динамике - легко ли вносить изменения в продукт, или сложно.
А так есть eShopOnWeb и eShopOnContainers

API API рознь.

Если один контроллер и 3 экшена, в которые засунута вся логика - то никому не интересно, даже с навыками фронта.

А вот если API сделано:

- с использованием ООП и паттернов
- многоуровневой архитектурой
- SQL запросами, которые сложнее просто SELECT
- авторизацией, проверкой прав на рутинги, JWT
- асинхронностью
- Swagger

то хватит более чем, возьмут и без знания фронта или по крайней мере с минимальным знанием (например, bootstrap + jquery).

А если еще всяких рэббитов, монги и сфинкса для кучи сверху навернуть и тестами покрыть, то вообще с руками оторвут.

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

Изучать нужно С#.

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

Например
1. отключаешь display manager - lightdm (или что у тебя там для меню авторизации и выбора DE)
2. минимум что необходимо для работы графического режима - это xserver, для его запуска достаточно запустить утилиту X (кстати кажется до сих пор требует root), будет запущен графический сервер без Desktop Environment, но нужно понимать что DE отвечает за управление окнами, а точнее управление их размерами, положением на экране и вообще сокрытие/минимизация. Т.е. без этого, если твое приложение ожидает что пользователь будет перемещать его окна (а это к примеру диалоговое окно открытия/сохранения файлов) то он уже это сделать не сможет, все окна будут без заголовков и бордюра для изменения их размеров.
И кстати, чтобы графическое приложение запустилось и отображалось на X нужно устанавливать переменную окружения DISPLAY, значение смотреть либо в конфиге X либо в логах (скорее всего будет что то типа :0, это имя сервера и номер xserver, запущенного на нем, напоминаю, что linux из коробки умеет multiseat)
3. чтобы появился хоть какой то интерфейс взаимодействия, нужно установить DE, из минималистичных, идеальных для kiosk mode - я бы рекомендовал awesome, в нем к примеру можно настроить чтобы все открываемые окна сразу разворачивались на весь экран.

Кстати со всеми xserver обычно идет древний дефолтный twm, настолько примитивный что даже смешно, но если бы при открытии любого окна он не требовал от пользователя указать расположение и размер, им можно было бы пользоваться (не удивлюсь если это настраивается но никогда этим вопросом не задавался).

Из минималистичных и вполне функциональных DE можно предложить еще какой-нибудь openbox, его можно настроить так чтобы вообще никаких 'пуск' и списка задач не было, а только иконки и приложение на весь экран. Но пользователь сможет добраться до редактирования меню и запустить любое приложение, т.е. это не для kiosk mode

Чтобы запустить xserver с DE автоматически можно либо настроить автозагрузку в lightdm (это правильно) либо просто запускать утилиту startx, которая смотрит в пользовательском каталоге .xinitrc и запускает DE от туда.

На самом деле процесс запуска DE стал очень замудреный, его запутали несколько поколений разработчиков и выпутывать не желают, но обычно все это критично для тяжелых DE типа KDE, а что то простое и легкое с приложениями на gtk работает и так

Собственно как запускать приложения автоматически при включении компьютера тоже вопрос очень интересный, способов много, минимум три могу предложить
* правильный - настроить службу и прописать ей зависимости и автозапуск,
* так же до сих пор есть устаревший способ настройки службы без зависимостей sysvinit - /etc/init.d
* ну еще есть /etc/rc.local

Вроде недавно несколько раз задавали такой вопрос.

Если будешь делать фронтенд, то js тебе понадобится в любом случае.

Сам по себе в чистом виде асп нет к фронтенду отношения не имеет, но у него есть расширения в виде Blazor и MVC, которые как раз отвечают за фронт.

ИМХО: тут идеально подходит поговорка "волков бояться - в лес не ходить".
Сейчас практически все продукты так или иначе связаны с интернетом, а значит с сайтами и js.

Сам по себе JavaScript очень простой язык и его бояться не следует, особенно если говорить про TypeScript.

Если вот принципиально не хочешь писать на js, а хочешь писать только на C#, то обрати внимание на геймдев с Unity и десктопную/мобильную разработку с WPF, Winforms, Xamarin, MAUI, UNO, Avalonia

Сеть в клубах клиентам настраиваю часто.

Для Вашего случая вполне подойдёт любой неуправляемый коммутатор TP-Link на 16 портов (если не потребуется ещё, скажем, видеонаблюдение делать), а в качестве роутера - hEX либо hAP ac2. На скоростях до 100 Мбит/с выдержит большое количество очередей (о них позже).
Сами эти роутеры вывозят реальную скорость до гигабита, но не в случае очередей трафика.
Если скорость уже 200-300 Мбит/с, то лучше выбирать RB4011, он помощнее.

Предложенный в комментах RB5009 на мой взгляд бессмысленное приобретение для 12 компов. Из пушки да по одному воробью.

Теперь про очереди. В онлайн-играх важно, чтобы игровой трафик получал приоритет. При игре по локальной сети обычно никаких проблем не бывает, но при игре с игроком за пределами клуба можем столкнуться с проблемой потерь пакетов в случае загруженного канала. Решаю обычно следующим образом - выделяем несколько типов трафика:
1. Игровой - в него входит собственно игровой трафик, голосовой трафик, и icmp запрос-ответ (в народе - пинг). Обычно не более 2-3 Мбит/с в сумме.
2. Трафик обновления игр (когда при запуске клиент хочет обновиться).
3. Всё остальное, что не вошло в два предыдущие - веб-серфинг, обновление Windows, прочее.
4. Трафик от гостевого Wi-Fi.

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

Получается два дерева очередей - на загрузку и на выгрузку.

Ещё пара слов про коммутаторы. В данном случае не вижу смысла брать ни CRS326, ни CSS326, они оба избыточны в данном кейсе. Если же есть желание получать подробную информацию о трафике на каждом порту, то, конечно, предпочтение за CRS326. Если такого желания нет, то достаточно тупого 16-портового надёжного коммутатора.