German Jet

0. Направление не новое и хорошо изученное.

1. Зависит от того, какое именно ПО.
Что-то пишется на Си, что-то на языках высокого уровня, а что-то реализуется на уровне железа (плис/fpga/asic)
Для моделирования каких-то процессов может использоваться уже упомянутый матлаб, например.

2. Изучать нужно теорию управления и физику, тк по сути всё управление моторами базируется на ней - а это по сути основная и единственная задача, как удержать дрон в воздухе, не сталкиваться с препятствиями при движении, а в случае отсутствия движения - оставаться на месте.
По разработке - собственно Си для микроконтроллеров и verilog для железа. По хорошему ещё электронщиком нужно быть.
Не сильно от обычной embedded разработки отличается, выходит.

А на высоком уровне - там уже на конкретную задачу нужно смотреть. Где-то может даже ML и компьютерное зрение понадобится.
Получается тоже не так уж много отличий от обычной разработки.

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

Диагонально прочитал статью и хочу сказать, что с частью пунктов соглашусь, но, не абсолюнто со всем.
Прежде всего задайте себе вопрос а чего вы хотите? Что вам интересно?
Действительно написание ПО под MCU требует понимание (в основном, цифровой) электроники. Например, классические цифровые интерфейсы передачи данных (UART, I2C, SPI) это прямой мостик между знаниями software и hardware и хороший embedder должен понимать как эти протоколы работают и куда ткнуть осцилограф/логический анализатор, чтобы понять что не так.

Помимо описанного выше есть более hardcore уровень - программирование под embedded Linux. В ситуации, когда вам не хватает ресурсов MCU для, например, проигрывания высококачественного звука, считывания изображений с камер, а также все ещё нужно управлять сигналами на плате напрямую, то ваш выбор это embedded Linux и так далее. Тут опять же много чистого С.

Есть и третья известная мне сфера для embedded разработчиков (которая также не лишена славы). Компании, занимающиеся разработкой CPU, MCU и иных цифровых/цифроаналоговых микросхем. Да, вам покажется, что это только про Intel, AMD, Samsung, Huawei. Но даже в РФ минимум с пол десятка компаний, которые занимаются подобными разработками и активно нанимают людей. Все это довольно сложные и, в то же время, интересные темы.

Как вы догадываетесь, для каждого из трех пунктов нужны немного разные знания (хотя базовое образование, в основном, требуется одно и тоже). Также для 2 и 3 пункта ваше физическое присуствие на рабочем месте, вряд ли, потребуется, ровно как и лезть руками что-то паять (просто потому что руками в этих областях уже никто не паяет). Обычно, для embedded из 1 абзаца, требуется больше работы с железом, но и тут есть вариации.

P.S. Лично мне несколько наскучило копаться с железками (а их проектирование - это моя магистерская работа)) и отлаживать низкоуровневые интерфейсы и код, поэтому я и сам немного свернул с этой embedded дорожки, но я занимался только тем, что описано в 1 пункте и совсем немного из 2 (к слову оба успел поработать и оффлайн и онлайн). Найти работу с моим опытом не было особо сложно, так что embedded не приговор: разонравилось вполне сможете перейти в С++/Rust было бы желание.
P.S.S. Извиняюсь, что получилось немного скомкано, спрашивайте, могу рассказать про свой опыт подробнее.

Официально поддерживается только Enterprise:
https://docs.oracle.com/en/database/oracle/oracle-...

Там же и список необходимых пакетов.

Оттуда же про 32 бита:

Note:If you intend to use 32-bit client applications to access 64-bit servers, then you must also install (where available) the latest 32-bit versions of the packages listed in this table.

Во первых это не MySQL, а MS SQL Server.
Во вторых документация говопит:

Ограничения
При использовании в виде производной таблицы ограничение на количество строк отсутствует.

При использовании в виде предложения VALUES инструкции INSERT... VALUES применяется ограничение в размере 1000 строк. Если число строк превышает 1000, возвращается ошибка 10738. Чтобы вставить более 1000 строк, используйте один из следующих методов:

Создайте несколько инструкций INSERT

Используйте производную таблицу

Выполните массовый импорт данных, используя служебную программу bcp, класс SqlBulkCopy .NET, OPENROWSET (BULK ...) или инструкцию BULK INSERT.

Моё мнение - десктоп-разработка по-прежнему актуальна, но стала более нишевой.
Кажется, что её совсем мало - но это не потому, что прям десктоп вообще никто не пишет, а потому что веба пишут намного-намного больше.

Почему веба сейчас так много?
Потому что веб дал возможность доставлять на клиента исполняемую логику очень быстро. Не нужно ничего ставить, просто заходишь на сайт. При этом, обеспечивается ПРИЕМЛЕМЫЙ уровень user experience. Это всё ещё и кроссплатформенно.
Вот на мобилках веб во многих случаях не даёт столь же хороший UX, поэтому там пышным цветом цветёт разработка "нативных" приложений. Забавно, не так ли? Ну и на мобилках изначально были созданы каналы быстрой доставки приложений - Магазины. Очень важно, что это было сделано изначально, и к этому все сразу привыкли.

Так что там с десктопом?
Я считаю, он остался для того софта, который обычно относят к категории проф. инструментов (тут согласен с Dmitry Roo ). Тяжелые редакторы вроде After Effects, CAD-системы, ну и тулы для разработчиков. Если так подумать, десктопный софт и раньше был в основном для специалистов и профессионалов, как и вообще стационарный компьютер. Просто раньше те, кто сейчас читает новости на смартфоне, читали их в бумажной газете, а пиццу заказывали по телефону.

Иными словами, это не десктопа стало прям в 10 раз меньше, это просто НЕпрофессиональных пользователей стало в десятки раз больше, как и кейсов непрофессионального использования техники - для заказа пиццы, для общения в мессенджере и т.д. И это всё закрывается в том числе мобильной и веб-разработкой. (с другой стороны, почему Телеграм такой ох*енный? Ну например потому, что его десктоп написан НЕ на вебе. И он просто отлично работает, а не тормозит по 20 секунд при запуске как Скайп)

А что с WPF?
Конечно именно эта технология потеряла в популярности. Основная причина очевидна - отсутствие кросс-платформенности. Да, Винда все ещё имеет сильные позиции на десктопе, но всё-таки уже перестала быть нерушимой. Одних макодрочеровюзеров вон сколько. Линукс уже не такой страшный (хотя конечно это все ещё 1-2% от всего десктопа). Да и вообще, когда на вебе платформа по сути одна - это Хром (я обожаю Firefox, но такими темпами через лет 10 он точно сдохнет, как это не прискорбно), то видя это десктоп-разработчики жутко бомбят (я в том числе) и требуют себе такого же удовольствия. Поэтому вместо WPF нынче интересны Avalonia и Platform UNO (это если на дотнете).

С точки зрения Винды есть WinUI, но это опять таки платформозависимая есть. Она для тех, кому интересна только Винда, или у кого есть бабки поддерживать нативно все нужные платформы.
Ну и соглашусь с ответом Василий Банников , он хорошо описал границы десктопа на сегодняшний день.

А вообще, я жду когда WebAssembly наберёт ещё больше силы, и границы между вебом и десктопом просто сотрутся. Нет ничего такого в HTML и тем более JS, чтобы на них всё на свете переписывать. Это делается только по одной причине - см. выше про скорость доставки логики на машину клиента. И текущая популярность веба как платформы для приложений (именно платформы, а не информационной сети) - это по причине того, что Гугол всех победил производительностью браузера, и все подсели на Хром как на платформу - дешёво, доставляется ОЧЕНЬ быстро, работает ДОСТАТОЧНО быстро, покрыты сразу все устройства.

Эм, не очень понятен вопрос. Express является фреймворком для разработки серверных приложений на языке JavaScript, который работает на Node.js. Вы не можете подключить Express напрямую в HTML файл

Чтобы делать нужные вам вещи, вам нужно через javascript на фронте обращаться к серверу , который как раз написан на Express

<button onclick="connectToDatabase()">Подключиться к базе данных</button>

  <script>
    function connectToDatabase() {
      fetch('/connect')
        .then(response => response.text())
        .then(data => {
          console.log(data); // Вывод ответа от сервера в консоль
        })
        .catch(error => {
          console.log('Ошибка при подключении к базе данных:', error);
        });
    }
  </script>

В данном примере мы обращаемся к странице / роут - /connect
Этот роут слушает Express и на запрос отвечает / что-то делает

// index.js (серверное приложение с использованием Express)
const express = require('express');
const app = express();

// Функции для подключения к базе данных
// ...

// Обработка GET-запроса на /connect
app.get('/connect', (req, res) => {
  // Вызов функции подключения к базе данных
  // ...

  // Отправка ответа клиенту
  res.send('Подключение к базе данных выполнено успешно');
});

// Запуск сервера на порту 3000
app.listen(3000, () => {
  console.log('Сервер запущен на порту 3000');
});

1. В поисковике множество решений с публикацией на ОС Windows, но это требует лишних вложений в лицензию. Есть ли тонкости при публикации в Debian/CentOS?

Для этих случаев есть PostgreSQL. Инструкции должны быть, на сайте у 1С в поддержке точно были.

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

Для работы нужны только клиентские лицензии для тех машин, на которых будет запускаться клиентское приложение 1С, но хотя бы одна клиентская лицензия на машине с веб-сервером и опубликованной базой не помешает, что бы можно было на ней запустить конфигуратор для обновления и перепубликации базы

3. Можно ли опубликовать базу на машине с лицензией, а затем перенести её на другую машину (без лицензий 1с) простым копированием?

Не совсем поняла мысль. Перенести файловую базу разумеется можно, как любой каталог с файлами, только что будет с публикацией?
Если перенести и заново опубликовать, то нет проблем.

P.S.
9ГБ для файловой базы уже серьезно, можно дождаться, что база в какой-то момент перестанет запускаться.
Советую подумать о переходе на SQL или о свертке базы.
У 1С есть лицензия на Сервер МИНИ до 5 одновременных сеансов в режиме 1С:Предприятие + 1 сеанс в режиме конфигуратора по вполне разумной цене - 14400 руб.

Пробовал только на CRS125-24g-1s-rm делать сеть, постоянная загрузка под 100%
не забывайте что CRS310 позиционируется как коммутатор а не роутер, хоть и умеет им быть
Ядром сети должен быть именно RB а не CRS
У меня
RB3011UIAS-RM как роутер, DHCP сервер, DNS для гостевой, разделение сети на гостевую и основную, VPN сервер, CAPsMAN и TheDUDE
CRS125-24g-1s-rm как коммутаторы и переведенные в режим AP роутеры HAP AC LITE как двухдиапазонные WiFi точки доступа и доп коммутаторы в кабинетах где протянут только один кабель
Всё летает

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

2. противоположный, использование одной таблицы key-value для нескольких разнородных справочников (id, value, table_name), в 99% случаев можно использовать один сиквенс (одну последовательность идентификаторов), вам же не обязательно чтобы разные справочники начинали счет своих строк с одного и того же числа 1.
Недостаток - база данных теперь не сможет контролировать что вы используете непротиворечивый идентификатор (можно в запись одного справочника указать номер из другого), хотя несуществующий так же нельзя будет указать (и будут работать delete cascade), так же удобной автогенерации sql не будет. Структура будет проще, так же интерфейс редактирования таких справочников может быть один вместо кучи форм и добавлять новые справочники будет сильно проще (хотя с точки зрения разработки нет особой разницы, один insert ты написал или create table перед этим)

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

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

являясь собственно DBA последние сколько-то там лет...

Основная рутина:
- внесение изменений схемы данных без даунтайма собственно приложения
- выполнение каких-то массивных операций над данными (удалить половину данных из полутеррабайтной таблички, например)
- исследование проблем производительности со стороны базы
- решение в целом проблем на серверах баз, не только производительности
- текущее сопровождение: бекапы, репликация, переезды с одних серверов на другие, настройка новых серверов, минорные обновления базы
- major обновления базы
- заведение пользователей и организация прав доступа
- консультации разработчикам "как лучше сделать"
- консультации "так это работать не будет, придётся менять"

То же самое, что и раньше - Лутца вплоть до 37-й главы и руководство Django. Но надо понимать, что конкуренция среди джунов огромная, так что за место придётся бороться с людьми, которые могут отлично знать SQL, теорию реляционных баз данных, принципы работы сетей, алгоритмы и шаблоны проектирования, могут свободно чувствовать себя в консоли Linux, могут разбираться в виртуализации, уметь тонко настраивать сервера, разбираться в железе и т.д. и т.п.