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

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-портового надёжного коммутатора.

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

Я предложу вашей фирме хард аудитинг и порку вашего архитектора.
что вью что реакт дают все тоже самое

Перейдя на реакт вы будете страдать. Реакт - это тупо даунгрейд. Всё то же самое, но хуже и местами отсутствует. Есть ли в нём хоть какие-то преимущества перед vue? Не знаю таких.
Что за проблемы у вас с библиотеками?

Никуда.

Эта штука работает вместе с старым объявлением переменной.

function test(){
// Работаем в области функции нет разницы
var a = 10; // console.log(a)  - 10
let b = 10; // console.log(b)  - 10
// var в блоке можно получить из вне.
for(var c = 0;c < 2; c++){}
console.log(c) // console.log(c) - 2
for(let d = 0;d<1;d++){}
console.log(d) // console.log(d) - ошибка нет такой переменной
}

use strict - директива включающая новые правила для написания правильного кода. Чтобы человек меньше себе стрелял в ногу тем что переменная из цикла могла существовать на глобальном уровне.
Там если ошибка то сразу по ручкам.
Пример:

//Обычный js:
function test(){
magic = 10;}
test();
console.log(magic) // 10
//С use strict:
function test(){
magic = 10;}
test();
console.log(magic) // magic is not defined

P.S:
Если можете то просто посмотрите как писать с use strict ) И не вспоминайте как можно работать без него

Single File Application - фича современных дотнетов со времён .net Core 3
Буквально при помощи одной опции в файле проекта или одной строкой в консоли собирает ваш проект в единый екзешник, в который ещё может быть опционально встроен рантайм.
Вот пример csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <PropertyGroup>
    <!-- Вот это самое главное -->
    <PublishSingleFile>true</PublishSingleFile>
    <!-- Это чтобы тащить за собой рантайм До .NET 6 будут рядом лежать нативные библиотеки jit-а и сборщика мусора-->
    <SelfContained>true</SelfContained>
    <!-- Это необходимо, чтобы сборщик понимал, для какой ОС нужен экзешник -->
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <!-- Это чтобы ускорить запуск -->
    <PublishReadyToRun>true</PublishReadyToRun>
    <!-- Эти две строки, чтобы уменьшить размер бинарника -->
    <PublishTrimmed>true</PublishTrimmed>
    <TrimMode>link</TrimMode>
  </PropertyGroup>
</Project>

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

Для старых версий дотнета есть ILMerge и Costura.Fody, но в .net 5+ они не нужны, и я крайне советую использовать именно .NET 8, тк он сейчас самый актуальный