Теперь не даю клиенту долго думать. Показываю материалы, черчу эскиз, обговариваю цену и заключаю договор на месте.
Был у меня подобный производитель. Заказывал кухню и повелся на обещание бесплатного замера, а по факту оказалось, что требуется обязательно заключить договор с предоплатой и только в этом случае замер будет бесплатным.
А отсутствие материалов (вовремя не закупили) или если вас подвел контрагент никоим образом не создает форсмажортных обстоятельств, т.к. все это может и должно вами контролироваться и оцениваться как обычные бизнес-риски.
Послал подальше таких изготовителей с их филькиными форсмажорными обстоятельствами и заказал в другом месте.
По большей части правильно (в том числе и на основе собственного опыта), но не соглашусь с некоторыми очень категоричными утверждениями.
Во первых, любой менеджмент (в том числе и ПМ) обязан контролировать использование ресурсов, т.е. трудозатраты разработчиков. И если он этого не делает или не умеет делать, то это не проблемы разработчиков, а проблемы именно менеджеров, т.к. именно они управляют расстановкой приоритетов по задачам, а тогда как разработчик волен использовать свою сортировку задач (делать то, что ему наиболее интересно, например, изучать новые языки программирования или фреймворки).
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
для которых еще нужна обвязка MCU + разъем и обвязка для USB (у самых дешевых микроконтроллеров поддержки USB может и не быть) + обязательно плата (навесным монтажом проводки к ножкам не припаяешь).
В итоге все это выйдет гораздо дороже и сложнее какого нибудь ESP32 с уже рабочим USB и встроенными WiFi и Bluetooth
В пятьсот рублей у меня никак не влезает: IOT модуль + преобразователь питания (12-24В до 5-7В) + токовый шунт 75мВ + 4 резистора для делителей напряжения + датчик температуры ds18b20. Это минимум без платы и без монтажа.
В принципе можно, но итоговая стоимость такого решения будет значительно дороже. Ведь такая батарея довольно дорогая и к ней потребуется отдельный контролер заряда (ведь зарядка UPSа рассчитана обычную АКБ)
И все это никак не убирает изначальную проблему - удаленный контроль состояния АКБ в ИБП.
теперь Нетбинс настроен, но как настроить дебаг пока не понял.
Начиная с NetBeans 22 у него убрали поддержку старых версий плагинов из-за чего приходится пользоваться NetBeans 21 из-за С/С++ плагина с нормальной поддержкой побсов. К сожалению рано или поздно придется придется переходить на что-то другое, так по сравнению с ним, у ligthweight C++ все приходится настраивать руками.
Конечно плохо, но не этим (поток управления в catch явный, а затраты не такие уж и большие по сравнению с чистотой кода и элементарной логикой обработки ошибок с помощью исключений).
Плохо тем, что если исключения в языке есть, то ими можно не пользоваться (из-за якобы неявного потока управления или "больших затрат"), но если их нет, то приходится писать потрянки кода или и вовсе ошибки игнорировать.
В обозримом будущем команда разработчиков Go перестанет пытаться внедрить в язык синтаксические изменения для обработки ошибок. Также мы без подробного изучения будем закрывать все открытые и новые предложения, основной смысл которых связан с синтаксисом обработки ошибок.
А просто сделать классические исключения не позволяет сделать религия языка?
Почему "не в счет"? Если это в тему, то какое нибудь теоретическое доказательство может поставить точку в попытках фанатиков практиков продолжать трясти пальму :-)
У вас, кажется, есть по статье на Хабре на все случаи жизни :)
Хабр очень удобно использовать как рабочий журнал для подведения итогов, а так же для апробации различный идей и архитектурных решений: (простите, не удержался) :-)
Мне много раз приходилось слышать от т.наз. практиков насмешливые высказывания в адрес т.наз. теоретиков. Но всё это - нытьё в стиле, "тут не думать надо, а грушу трясти".
Что же касается теоретиков и практиков, то я хоть и практик, но в данном вопросе скорее на стороне теоретиков.
Кондиционером с тепловым насосом получается нормально обогреваться до -15С на улице https://habr.com/ru/articles/857436/
Был у меня подобный производитель. Заказывал кухню и повелся на обещание бесплатного замера, а по факту оказалось, что требуется обязательно заключить договор с предоплатой и только в этом случае замер будет бесплатным.
А отсутствие материалов (вовремя не закупили) или если вас подвел контрагент никоим образом не создает форсмажортных обстоятельств, т.к. все это может и должно вами контролироваться и оцениваться как обычные бизнес-риски.
Послал подальше таких изготовителей с их филькиными форсмажорными обстоятельствами и заказал в другом месте.
Для этого кнопка не нужна, а как, зависит от конкретного сайта, например тут на Хабре, это будет https://habr.com/ru/articles/page-1/
По большей части правильно (в том числе и на основе собственного опыта), но не соглашусь с некоторыми очень категоричными утверждениями.
Во первых, любой менеджмент (в том числе и ПМ) обязан контролировать использование ресурсов, т.е. трудозатраты разработчиков. И если он этого не делает или не умеет делать, то это не проблемы разработчиков, а проблемы именно менеджеров, т.к. именно они управляют расстановкой приоритетов по задачам, а тогда как разработчик волен использовать свою сортировку задач (делать то, что ему наиболее интересно, например, изучать новые языки программирования или фреймворки).
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
Clang ?
var в java, это фактически auto в C++
Ага, теперь понятно, почему у меня YouTube ролики не показывал, а после выключения и повторного включения блокировщика рекламы опять появились.
Именно контроль тока на шунте. В этом случае можно будет и емкость/заряд подсчитать и ручную корректировку настроить при необходимости.
Для этого нужен контроль входного напряжения, но вот это делать как раз и не хочется.
Беспроводные интерфейсы идут в комплекте, тогда как основной это USB
С точки зрения потери данных, потерь вообще не будет, так как я дома работаю на ноутбуке, только с внешним монитором и клавиатурой.
Тут больше защита от скачков напряжения при продолжении работы при отсутствии питания.
для которых еще нужна обвязка MCU + разъем и обвязка для USB (у самых дешевых микроконтроллеров поддержки USB может и не быть) + обязательно плата (навесным монтажом проводки к ножкам не припаяешь).
В итоге все это выйдет гораздо дороже и сложнее какого нибудь ESP32 с уже рабочим USB и встроенными WiFi и Bluetooth
Кроме "поддержки" еще есть проблема в актуальных данных.
Именно так я и делаю.
В пятьсот рублей у меня никак не влезает: IOT модуль + преобразователь питания (12-24В до 5-7В) + токовый шунт 75мВ + 4 резистора для делителей напряжения + датчик температуры ds18b20. Это минимум без платы и без монтажа.
Согласен, что нормальные ИБП именно так и должны делать.
Вот только где найти такой нормальный и не дорогой ИБП с поддержкой Linux?
В принципе можно, но итоговая стоимость такого решения будет значительно дороже. Ведь такая батарея довольно дорогая и к ней потребуется отдельный контролер заряда (ведь зарядка UPSа рассчитана обычную АКБ)
И все это никак не убирает изначальную проблему - удаленный контроль состояния АКБ в ИБП.
Начиная с NetBeans 22 у него убрали поддержку старых версий плагинов из-за чего приходится пользоваться NetBeans 21 из-за С/С++ плагина с нормальной поддержкой побсов. К сожалению рано или поздно придется придется переходить на что-то другое, так по сравнению с ним, у ligthweight C++ все приходится настраивать руками.
Конечно плохо, но не этим (поток управления в catch явный, а затраты не такие уж и большие по сравнению с чистотой кода и элементарной логикой обработки ошибок с помощью исключений).
Плохо тем, что если исключения в языке есть, то ими можно не пользоваться (из-за якобы неявного потока управления или "больших затрат"), но если их нет, то приходится писать потрянки кода или и вовсе ошибки игнорировать.
А просто сделать классические исключения не позволяет сделать религия языка?
Почему "не в счет"? Если это в тему, то какое нибудь теоретическое доказательство может поставить точку в попытках
фанатиковпрактиков продолжать трясти пальму :-)Хабр очень удобно использовать как рабочий журнал для подведения итогов, а так же для апробации различный идей и архитектурных решений: (простите, не удержался) :-)
Что же касается теоретиков и практиков, то я хоть и практик, но в данном вопросе скорее на стороне теоретиков.