mayton2019

В задаче есть такая матрица выбора. По горизотнали - технологии работы с USB/COM/TCP/UDP. Их много. Но в простом варианте (если бы ком-порты стояли в железе) то линукс бы видел такие устройства-файлы.
/dev/ttyS[0123]
И это было-бы прекрасно. В духе линукс. С переходниками и адаптерами - сложнее но принцип наверное такой-же.

И второе измерение матрицы - это собсно на чем делать UI. Конешно если автор знает делфи - то пускай берет лазарус и кодит. Но я-бы предложил рассмотреть вариант веб-интерфейса. Это - более современно и вообще веб-интерфейсы сейчас имеют вид - более привлекательный чем Windows95/Delphi лет 20 назад. По картинке с железной дорогой - вроде ничего сложного нету. Сейчас браузерны игры и то посложнее выглядят. Вот как-то так.

Да просто сосед пользуется твоим паролем. Смени и все будет норм. А соседа видно по мак-адресам которые щас подключены.

Самое главное - я не могу работать по найму (пытался не раз, сбегаю с такой работы через пару дней), только на себя.

Вы считаете себя надёжным фрилансером? Как вам можно доверить техподдержку при таком режиме работы? Техподдержка - это офигеть какой отвественный цикл работ. И вам никто не позволит завтра просто так "сбежать".

Вам надо порешать сначала ваши внутренние проблемы и поменять убеждения. Поддержка - это всегда корпоративная деятельность. Практически всегда. Корпорация - это мини-государство. Никакого либерализма там внутри нет. Внешний либерализм (катание на электросамокатах и распитие кофе) это просто ширма. Корпорации - жесткие. Имеют свой code of conduct. Имеют пакован документов NDA вам на подпись и регулярные митинги как обязательную часть работы от которой никто не укрывается никогда.

Вобщем думайте про софт-скилы.

Там - простое правило. Для денег - бери decimal. Всегда бери.

А для научных расчетов (там где копейка в младшем разряде роли не играет) - бери float/double.
Отличаются они разрядностью. Если экономить надо (матрицы чисел) - то бери float (32 bit).
Если просто нужна вещественная величина в переменной - то бери сразу double. Никто не будет
возражать.

В свете последних трендов разработки - тебе нужен аккаунт в AWS или Azure и вот эти штуки

• https://learn.microsoft.com/en-us/azure/machine-le...
  
• https://aws.amazon.com/sagemaker/
  

Мощность "твоей" мясорубки для DataScince не должна иметь никакого значения. Продуктовые pipelines все равно будут работать не на ноутбуках а на специфичном железе с поддержкой TPU.

Более того. Никакие "твои" специфичные железяки не должны превалировать над качеством модели на выходе.

Поэтому покупай себе самый обычный ноутбук и не парь мозги. Излишек денег потрать на облачные подписки.

const converter = {
  "m":{
    "cm":{k:0.01	},
    "in":{k:0.254	},
    "ft":{k:0.3048	},
  },

Тут можно улучшить. Если посмотреть на этот JSON документ с "прищуром". То можно увидеть
полносвязный граф. Например узел футов ("ft") имеет свое ребро в направлении дюймов ("in").
И все другие также.

Нужно ли нам описывать так много цифр? Я-бы предложил одну таблицу. Все меры длины отобразить на метры.
Тогда формула перехода ft -> in будет всегда идти через метрическую систему. ft -> m -> in.

А ребра графа мы все равно сможем получить но уже путем вторичных расчетов если надо.

Тебе нужна функция цветовой дистанции между двумя цветами. Типа

double getDistance(int rgb1, int rgb2) {
    ....
}

Формула будет похожа на взвешенную сумму цвета как ты писал выше. Только в цветах
нужны будут разности r1 - r2 e.t.c. И взять декартово расстояние.

Она будет возрващать от 0 до некоторого максимального вещественного. Если 0 - то цвета идентичны.

Задаешь порог чувствительности например 5% и если цвета rgb1 и rgb2 близки - то соотв. считаешь
что совпадение было. Сравнивать по знаку == цвета нельзя в фотографиях. Там очень редко
бывает численное совпадение. Практически - никогда не бывает.

Можно попробовать Graphana+Prometheus.

Я тоже голосую за MQ сервисы. Тут само задание тяготеет к такому подходу. Но автор работает на MS-технологиях и ему наверное органичнее будет брать какое-то решение от МС. Вот облачное https://learn.microsoft.com/en-us/azure/service-bu...

И еще можно посмотреть Microsoft Message Queuing (MSMQ) но жив ли этот проект сейчас я не знаю. Надо смотреть.

Какими языками программировани....

С помощью Apache Poi https://poi.apache.org/apidocs/index.html я работал с XLSX документами (язык Java и платформа Linux. Насколько полно POI покрывает возможности MS документов - я не знаю. Другие типы не пробовал. Вообще сама постановка вопроса насчет языков - неверная. Если вы берете например LibreOffice - то там главное ядро например написано на сях а к ней идет куча API разработки https://api.libreoffice.org/ смотрите полный список по ссылке.

Будьте осторожны с заменой MS-Office. У меня есть предположение что заменить их на 100% невозможно. Уж слишком они тесно связаны с технологиями MS. Возможен такой вариант что какой-то офисный документ вы не откроете просто потому что в нем есть всякие OLE/COM e.t.c штуки которые являются компонентами ОС Windows. И заместить их ничем будет невозможно. Или вы нарушите условия импортозамещения.

Где-то также читал статью одного из разработчиков старого офисного формата Word. Он признается что формат сложен даже для него самого.

Массив можно сделать через JSON тип. По крайней мере MariaDb его поддерживает. Может и MySQL тоже имеет.

Хранить его в пользователе я-бы не советовал. Лучше создать отдельную таблицу типа sessions или какие-то юзерские активности и складывать туда связку session_id + user_id + JSON с корзинкой. Причем добавить обязательно TTL хотя-бы на неделю. Чтоб рассеянные пользователи не заполняли мусором таблицу.

А если я приду чинить 2 вещи сразу?

У меня 1 заказ но 2 предмета. Один - ювелирка. А другой - из спортивного инвентаря. А потом мне одну вещь починят. А по второй будет отказ. Как это все трекать?

В reddit есть.

Как записывать в файл до тех пор пока есть место в нем?

Это не функционал файловой системы. Порешай такие задачи на уровне прикладного кода. Это не сложно.

Более того. В свете развития современных файловых систем (облачных систем) понятие "свободное место" сильно девальвировало. Его стало сложно посчитать. Оно уже не является уравнением где можно суммировать логический размер файлов и что-то прикидывать. Файлы стали обладать свойством SPARSE - разреженные, COMPRESSED - сжатые, стали иметь хард-линки (несколько внешних имен одного файла).

Во времена 32х битных ОС файлы часто ограничивались в 2Гб сверху. И это и сейчас наблюдается по
устаревшим API для файлов. А после ext4 например размер файлов лимитирован числом exbibyte а это на 12
порядков поболее чем 32х битки. Короче такой размер нам никогда не заполнить ничем.

Кроме того при использовании PIPELINE или канальных устройств само понятие размер файла лишено
смысла. Файл представляет собой трубу через которую с одно стороны пишут а с другой читают
информацию. И это - хорошо. Это гибкость файловой системы которую развивают еще со времен ОС Unix.
Зачем нам эту гибкость ограничивать.

Exe-шник - это конечный продукт после которого уже ничего не делают. Более того. Владелец этого артифакта обычно предпринимает все технические и юридические ходы чтобы ты не мог ничего сделать с файлом кроме как просто его выполнить.

и как будет происходить компиляция минуя среду разработки?

Если хотят пере-использовать какой-то бинарник в API - то создают *.dll и к нему идет спецификация (заголовочный файл *.h) который описывает функции которые внутри. Это - легальный способ переиспользования бинарного кода в Windows.

Что ты там придумал с билдером - непонятно. Возможно ты пытаешся собой подменить компиллятор. Почитай про сборщики (CMake например). Может там будут ответы на твои вопросы.

Тут щас в ответах наговорят миллион банальностей общего плана. Конечно нейросеть не работает
со словами. Она их просто не знает. Но она работает с входами и выходами вещественного типа.
Какую дать ИНТЕРПРЕТАЦИЮ входу и выходу - задача разработчика НС. Можем входом считать
букву. Можем фонему или слог. Можем - слово. Или лемматизированное слово. Или целую фразу
или фрагмент AST. Или целый абзац текста. Все зависит от задачи.

В последние 10 лет НС сильно рванули вперед. В особенности в части архитектур. Благо мощности догнали. Например свёрточные сети. Которые узнают картинки. Им надо просто большое число параллельно работающих ядер, которые разбирают на слои одну и ту-же картинку. Скорее всего мощности догнали и сети обработки
естесвтенного языка.

По поводу обработки языка, что у нас есть. У нас есть как минимум ChatGPT. У нас есть Co-Pilot.
Надо почитать что о них пишут сами разработчики. Из каких частей и из каких архитектур они построены.

Там будет элемент ноу-хау. Иначе они-бы так громко не выстрелили.