Хорошая сказка. Вот только что-то мне подсказывает, что дело было совсем не в том, что "Его самая большая претензия заключалась в том, что если сервис не нужно дополнительно поддерживать, то трём инженерам не останется работы!", а из-за того, что нужно было нанимать еще трех новых человек, тогда как используя существующий стек технологий все можно было сделать уже имеющимися силами.
Директор посчитал бюджет и принял итоговое решение и конкретный язык программирования или framework тут не причем.
Я вообще в шоке от некоторых его перлов. Вроде бы взрослый человек, но самомнение и тупость из некоторых комментариев просто фонтанирует.
И если человек прямо заявляет, что ему приятнее читать портянки LLM, вместо того, чтобы попытаться разобраться в теме, то это уже скорее всего диагноз. Но я не доктор и для себя уже решил, что это последняя его статья (только ради поржать над комментариями), а все остальные сразу в бан не читая.
Осторожно, не попадитесь на его очередные вольные интерпретации.
В акторной модели все сообщения асинхронные. А не может ждать B по определению. Отправил и забыл.
"Ждать", это не обязательно "висеть на мьютексе", а, например, просто не выполнить какое-то действие из-за не пришедшего сообщения. И пусть это будет происходить в самом зеленом потоке асинхронной модели, но если одно событие не отправлено из-за того, что не пришло другое событие, которое ожидает предыдущее, это все равно будет взаимной блокировкой, несмотря на то, что мьютекс в этой модели взаимодействия вообще отсутствует :-)
Автор не понимает, что любая абстракция (ООП в том числе), так или иначе всегда будет приземляться на реальное физическое железо у которого присутствует необходимость в синхронизации некоторых действий. Таже самая очередь сообщений хоть выглядит идеальной иммутабельной абстракцией, но на самом деле объекты её синхронизации относятся "к внешней", по отношению к акторной модели, среде выполнения, но физически никуда не деваются.
В качестве основы я взял ESP32. У него кроме USB уже есть WiFi (что лучше и дешевле, чем LAN порт) + опционально можно прикрутить RS485.
Кроме поддержки последовательного протокола для NUT я хочу еще добавить Modbus RTU, а для опроса по сети Modbus TCP и SNMP для ИБП (тоже есть поддержка в NUT).
Такой измеритель с токовым шунтом уже попадает в нужный диапазон для измерений.
Но проблему вы сами описали. Это обычный измеритель напряжения и тока и он не приспособлен для определения режима заряда-разряда АКБ (только косвенно по уровню напряжения), как и вычислять деградацию емкости АКБ от времени или её состояния.
Под термином "ООП" каждый может понимать что-то свое, а в большинстве языков программирования могут встречаться различные, зачастую даже противоположные концепции, одновременно.
Однако ООП и многопоточность это всегда перпендикулярные и никак не связанные между собой понятия и любые попытки натянуть одно на другое, это из области совы и глобуса.
Если я правильно понял, генерируется описания коммита по заданному шаблону, которое потом используется как черновик, после чего его можно (нужно) править и лишь только после этого окончательно коммитить.
Это ничем не хуже написания бессмысленной портянки вручную.
Ну как же? Вы считаете, что данные могут храниться только в БД и других мест не может быть. Я правильно понимаю?
Я не считаю, что данные могут храниться только в БД.
Место хранения внешних данных, это обычная абстракция с API для обращения к этим самым данным. А уж где они физически хранятся, в БД, процессе Erlang, который живет уже 40 лет в виртуально машине, распределены между разными узлами или вообще вычисляются на лету по мажоритарному принципу, это дело десятое.
Подобный вольтамперметр точно не подойдет для ИБП. У него максимальный ток всего 10А, тогда как при работе от АКБ разрядный ток может быть в несколько раз больше.
С другой стороны, ваш Siemens Masterguard A3000 не только старый как ...овно мамонта, но и стоит как крыло от самолета и должен иметь контроль АКБ (либо иметь модуль расширения для мониторинга).
И вы скорее всего правы в том, что мое решение ему не подойдет не смотря на то, что использование внешних шутов (хоть до килоамер), позволяет контролировать практически любые нагрузки.
Разве? Это вам и вчера и сегодня популярно разжевали, что у вас нет понимания ни в ООП ни в БД (о чем вы сами и написали). А после нескольких высокомерных закидонов с вами и другие нормальные люди перестали общаться и осталось вам только переписываться с LLM :-)
Нет у меня никакой базы. Я не работаю с проектами, в которых есть база, с этим прекрасно справляются специально обученные хомячки с интеллектом уровня робота-пылесоса.
Что только подтверждает преположение, что у вас не только с ООП все плохо, но и с базами данных толку не хватило разобраться, хотя даже специально обученные хомячки с интеллектом уровня робота-пылесоса с БД прекрасно справляются.
Да, что-то вроде этого. Просто классифицировать объекты можно по разному и некоторые названия могут совпадать, несмотря на изначально разные трактовки и вкладываемый в них смысл.
Можно и адрес локальной переменой возвращать в return, можно даже писать по 0x0 адресу, никто вам этого не запретит и даже в Rust можно писать unsafe код.
Однако мы ведем разговор про синхронизацию доступа к объекту и в контексте нашей переписки "локальный" объект подразумевает отсутствие доступа к нему снаружи локальной области видимости.
Но для С++ это будет только соглашением, т.к. компилятор это не может проверить.
Так без биометрии или без паспорта????
Хорошая сказка. Вот только что-то мне подсказывает, что дело было совсем не в том, что "Его самая большая претензия заключалась в том, что если сервис не нужно дополнительно поддерживать, то трём инженерам не останется работы!", а из-за того, что нужно было нанимать еще трех новых человек, тогда как используя существующий стек технологий все можно было сделать уже имеющимися силами.
Директор посчитал бюджет и принял итоговое решение и конкретный язык программирования или framework тут не причем.
Я вообще в шоке от некоторых его перлов. Вроде бы взрослый человек, но самомнение и тупость из некоторых комментариев просто фонтанирует.
И если человек прямо заявляет, что ему приятнее читать портянки LLM, вместо того, чтобы попытаться разобраться в теме, то это уже скорее всего диагноз. Но я не доктор и для себя уже решил, что это последняя его статья (только ради поржать над комментариями), а все остальные сразу в бан не читая.
P.S.
Насчет
херовблокировок, гуглите "Динамическая взаимоблокировка" (livelock).Осторожно, не попадитесь на его очередные вольные интерпретации.
"Ждать", это не обязательно "висеть на мьютексе", а, например, просто не выполнить какое-то действие из-за не пришедшего сообщения. И пусть это будет происходить в самом зеленом потоке асинхронной модели, но если одно событие не отправлено из-за того, что не пришло другое событие, которое ожидает предыдущее, это все равно будет взаимной блокировкой, несмотря на то, что мьютекс в этой модели взаимодействия вообще отсутствует :-)
Настает "вендекапец"?
Автор не понимает, что любая абстракция (ООП в том числе), так или иначе всегда будет приземляться на реальное физическое железо у которого присутствует необходимость в синхронизации некоторых действий.
Таже самая очередь сообщений хоть выглядит идеальной иммутабельной абстракцией, но на самом деле объекты её синхронизации относятся "к внешней", по отношению к акторной модели, среде выполнения, но физически никуда не деваются.
А там где не спасает, то разработчики Rust договорились, что это все равно будет называться "безопасным" :-) https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
В качестве основы я взял ESP32. У него кроме USB уже есть WiFi (что лучше и дешевле, чем LAN порт) + опционально можно прикрутить RS485.
Кроме поддержки последовательного протокола для NUT я хочу еще добавить Modbus RTU, а для опроса по сети Modbus TCP и SNMP для ИБП (тоже есть поддержка в NUT).
Такой измеритель с токовым шунтом уже попадает в нужный диапазон для измерений.
Но проблему вы сами описали. Это обычный измеритель напряжения и тока и он не приспособлен для определения режима заряда-разряда АКБ (только косвенно по уровню напряжения), как и вычислять деградацию емкости АКБ от времени или её состояния.
Под термином "ООП" каждый может понимать что-то свое, а в большинстве языков программирования могут встречаться различные, зачастую даже противоположные концепции, одновременно.
Однако ООП и многопоточность это всегда перпендикулярные и никак не связанные между собой понятия и любые попытки натянуть одно на другое, это из области совы и глобуса.
Миллиомметр примерно таким же макаром https://habr.com/ru/companies/timeweb/articles/728684/
Если я правильно понял, генерируется описания коммита по заданному шаблону, которое потом используется как черновик, после чего его можно (нужно) править и лишь только после этого окончательно коммитить.
Это ничем не хуже написания бессмысленной портянки вручную.
Ну как же? Вы считаете, что данные могут храниться только в БД и других мест не может быть. Я правильно понимаю?
Я не считаю, что данные могут храниться только в БД.
Место хранения внешних данных, это обычная абстракция с API для обращения к этим самым данным. А уж где они физически хранятся, в БД, процессе Erlang, который живет уже 40 лет в виртуально машине, распределены между разными узлами или вообще вычисляются на лету по мажоритарному принципу, это дело десятое.
Сам придумал тезис, сам с ним поспорил. Вы уверены, что именно вас таким образом "не корежит"?
Подобный вольтамперметр точно не подойдет для ИБП. У него максимальный ток всего 10А, тогда как при работе от АКБ разрядный ток может быть в несколько раз больше.
С другой стороны, ваш Siemens Masterguard A3000 не только старый как ...овно мамонта, но и стоит как крыло от самолета и должен иметь контроль АКБ (либо иметь модуль расширения для мониторинга).
И вы скорее всего правы в том, что мое решение ему не подойдет не смотря на то, что использование внешних шутов (хоть до килоамер), позволяет контролировать практически любые нагрузки.
Разве? Это вам и вчера и сегодня популярно разжевали, что у вас нет понимания ни в ООП ни в БД (о чем вы сами и написали). А после нескольких высокомерных закидонов с вами и другие нормальные люди перестали общаться и осталось вам только переписываться с LLM :-)
Что только подтверждает преположение, что у вас не только с ООП все плохо, но и с базами данных толку не хватило разобраться, хотя даже специально обученные хомячки с интеллектом уровня робота-пылесоса с БД прекрасно справляются.
Ну раз нечего обсуждать, тогда удачи вам хорошо пообщаться с LLM в другой ветке комментариев.
Да, что-то вроде этого. Просто классифицировать объекты можно по разному и некоторые названия могут совпадать, несмотря на изначально разные трактовки и вкладываемый в них смысл.
Можно и адрес локальной переменой возвращать в return, можно даже писать по 0x0 адресу, никто вам этого не запретит и даже в Rust можно писать unsafe код.
Однако мы ведем разговор про синхронизацию доступа к объекту и в контексте нашей переписки "локальный" объект подразумевает отсутствие доступа к нему снаружи локальной области видимости.
Но для С++ это будет только соглашением, т.к. компилятор это не может проверить.