Всем, кто решает использовать MH-Z19B, имейте в виду, что этому датчику необходима калибровка. Первые 24 часа использования (не первые сутки, а именно первые 24 часа рантайма) он будет собирать данные, а потом откалибруется по минимуму. И дальше будет калиброваться каждые 24 часа использования. Если после получасового проветривания датчик показывает 1000 единиц, скорее всего, он просто не успел откалиброваться и привыкнуть к новым условиям. После активного получасового проветривания, когда открыто окно или дверь, показания должны падать до 400-500 единиц.
MH-Z19[B] — копеечный дачник с очень простым принципом работы, из-за чего его показания зависят от кучи факторов, в том числе от влажности, от температуры, от напряжения на датчике. Поэтому ему необходима постоянная калибровка, имейте это в виду.
А ещё я обнаружил, что в нашей Сибири при -30 и ниже окна очень сильно «фонят» чистым воздухом — при большой разнице температур его с силой втягивает в квартиру и протягивает через вентиляцию. В итоге даже без намеренного проветривания дома поддерживаются приемлемые 800-1000 единиц CO2 при наличии одного дышащего человека на 50 кв.м. площади.
То есть все залитое горючее закончилось бы за 5 минут полной тяги… Звучит не очень внушительно. А какой оставался запас по весу до ограничения 115 кг? И какое расстояние можно было бы пролететь, если заправиться по полной? Ну так, чисто из интереса.
Вы не поверите, но под macOS действительно нет драйверов для весьма стандартного решения NVidia GPU через Thunderbolt. По крайней мере официального решения для этой ситуации не существует. И это еще одна огромная претензия к Apple.
Нет драйверов для чего, для самой стандартной интеловской графики Intel Iris Pro Graphics 5200 или для самого стандартного дискретного видео NVIDIA GeForce GT 750M? Конечно же эти драйвера есть. А в интернете есть инструкции, как добиться включения обеих видеокарт, и тогда они обе чудесным образом включаются и работают. Я не знаю, насколько хорошо работает автоматическое переключение в таком случае и допускаю, что с этим могут быть трудности, но в целом-то задача использования двух видеокарт на Windows решаема. У меня сейчас подключены 750M + внешняя 1060, обе работают одновременно под виндой. Под макосью кстати не работают — потому что там нет драйверов, хе-хе.
… Ну хорошо, допустим, есть какая-то неразрешимая проблема в реализации Bootcamp, которая упирается в лицензии, проприетарщину, конфликты между производителями и т.д., и Apple не может решить эту проблему и допилить Bootcamp до рабочего состояния (во что я не верю). Ну так дайте мне свитчер в буткампе «использовать только дискретное/только интегрированное видео»! Предоставить такую возможность со стороны Apple было бы вполне реально, но это не сделано… для нашего же блага.
Вот вы и попались! Windows как раз все умеет. Там дело в том, что сам MacBook на уровне загрузчика Bootcamp намеренно отключает встроенное видео, когда грузится в неродную ОС, и таким образом встроенная видеокарта становится недоступна винде. В интернетах даже есть инструкции, как Bootcamp можно «взломать», чтобы он перестал так делать — и тогда винда начинает нормально работать на встроенном видео либо с двумя одновременно, по желанию пользователя. Я кстати пытался так сделать на своем макбуке, но потерпел поражение. Настроить eGPU было куда проще.
Вообще Apple конечно поражает своим умением вставить палки в колеса продвинутым пользователям. Это всегда делается под каким-нибудь благим девизом, но по факту Apple просто атакует конкурентов. Вот отключили Apple встроенное видео для винды — и все, Windows теперь ест батарейку быстрее «на том же самом железе». И это видно на глаз каждому пользователю. Конечно, в каких-то случаях Apple реально прикладывает усилия, чтобы оптимизировать энергопотребление, но при этом они не стесняются и таких отвратительных трюков.
Внизу пишут, что время автономной работы для этих роботов составляет 60-90 минут. Мне кажется, это очень хороший показатель. Хотелось бы дольше, но и такие значения уже достаточны для выполнения сложных задач. Кроме того, если говорить о промышленном применении, как например на стройке, такого робота легко научить перезаряжаться заменой батарей.
Грубо говоря, робот имеет два аккумулятора, один из которых постоянно стоит на зарядке. Когда робот видит, что ему не хватит заряда на следующую задачу, он идёт и самостоятельно меняет себе аккумулятор, ставя разряженный на подзаряд, и возвращается к работе. С такими перекурами, которые займут всего 5-10% рабочего времени, робот сможет функционировать круглыми сутками. Для теслы этот вид зарядки не взлетел, но для роботов вполне может, поскольку робот сможет заниматься этим полностью автономно.
Ну в крайнем случае можно просто иметь двух роботов, один из которых заряжается, а второй работает — вопрос только в стоимости. Короче говоря, проблема слабого аккумулятора точно не ставит крест на использовании этих роботов уже сегодня.
Погодите, вы утверждаете, что ждать вообще не нужно? Я что-то не очень понимаю. Если вы делаете запрос к БД, например, то ждать вам придется, иначе вы не сможете ответить клиенту. Вот и выходит что-то вроде:
let result = await database.collection.find(query).exec();
res.json({result: result});
Не очень понимаю, как вы можете модифицировать этот код так, чтобы ждать было не нужно?
Если же говорить о случаях, когда совсем-совсем не надо ждать, в голову приходит что-то вроде удаления временного файла после выполнения запроса. Но это делается не то что без await, но и без промисов. Достаточно просто использовать пустой колбэк:
fs.unlink('tempfile.tmp', e => {});
Но это всё же достаточно редкий случай, чаще всего как раз ждать приходится.
То, что вы описали здесь — а именно, неформализованная экспертная оценка без цифр — как раз и есть противоположность KPI. Это очень индивидуальный подход, при котором есть шанс учесть особенности отдельного работника. Я полностью согласен, что качество кода, скорость разработки, стабильность приложения и другие факторы в целом должны влиять на карьерный и зарплатный рост программиста. Это разумно.
Если тимлид оценивает программиста, и этот тимлид адекватен, то он может разобраться в сложной ситуации. Например, когда программист закрывает мало тикетов и пишет мало кода именно потому, что он решает самые сложные задачи самым эффективным способом. Хороший тимлид видит это, и усилия программиста оцениваются по достоинству.
Если же программиста оценивает не человек, а компьютер (тикет-трекер или репозиторий с прикрученными алгоритмами, считающими KPI), в разработке начинается хаос.
Решил прокомментировать пункты последнего опроса, уж очень они мне кажутся забавными.
Количество строк кода — если выбирается в качестве KPI, то программисты просто учатся разносить аргументы методов и скобочки по разным строкам, а потом и вовсе начинают писать откровенно ненужный код.
Качество кода — хорошая попытка, но как его измерить? Код ревью очень субъективен и зависит от конкретных ревьюверов. Прогонять линтер, статический анализатор, писать тесты? Тоже очень сомнительные показатели. В общем не очень понятно, как это реализовать.
Количество закрытых багов — приучает программистов писать на скорую руку и отправлять код в продакшн. Много мелких багов означают много закрытых багов, что означает рост KPI.
Количество закрытых тикетов — тикеты «добавить точку в конце текста» и «реализовать полноценную работу приложения в оффлайне» как будем сравнивать? Программист, который сделал все самые быстрые тикеты, самый лучший в компании? Не думаю.
Стабильность работы приложения/оборудования — все программисты бегают за ошибками, которые случаются на редких китайских девайсах в одном запуске из 10000. Стабильность достигает 99.999%, но работа практически остановилась!
Наставничество — а причем здесь программирование? Человек, который вырастил 30 программистов — это в первую очередь учитель, а не программист.
Лояльность компании, дружелюбие и т.д. — лояльность измеряем временем, проведенным в компании? Опять абсурд в общем.
Удовлетворённость клиентов — не зависит от программистов. Программист может выложиться на все 100, а клиенты вдруг станут недовольны тем, что банк перестал одобрять кредиты.
Короче говоря, я против KPI. Не придумано пока ничего, что работало бы хоть более-менее универсально.
MH-Z19[B] — копеечный дачник с очень простым принципом работы, из-за чего его показания зависят от кучи факторов, в том числе от влажности, от температуры, от напряжения на датчике. Поэтому ему необходима постоянная калибровка, имейте это в виду.
А ещё я обнаружил, что в нашей Сибири при -30 и ниже окна очень сильно «фонят» чистым воздухом — при большой разнице температур его с силой втягивает в квартиру и протягивает через вентиляцию. В итоге даже без намеренного проветривания дома поддерживаются приемлемые 800-1000 единиц CO2 при наличии одного дышащего человека на 50 кв.м. площади.
… Ну хорошо, допустим, есть какая-то неразрешимая проблема в реализации Bootcamp, которая упирается в лицензии, проприетарщину, конфликты между производителями и т.д., и Apple не может решить эту проблему и допилить Bootcamp до рабочего состояния (во что я не верю). Ну так дайте мне свитчер в буткампе «использовать только дискретное/только интегрированное видео»! Предоставить такую возможность со стороны Apple было бы вполне реально, но это не сделано… для нашего же блага.
Вообще Apple конечно поражает своим умением вставить палки в колеса продвинутым пользователям. Это всегда делается под каким-нибудь благим девизом, но по факту Apple просто атакует конкурентов. Вот отключили Apple встроенное видео для винды — и все, Windows теперь ест батарейку быстрее «на том же самом железе». И это видно на глаз каждому пользователю. Конечно, в каких-то случаях Apple реально прикладывает усилия, чтобы оптимизировать энергопотребление, но при этом они не стесняются и таких отвратительных трюков.
Грубо говоря, робот имеет два аккумулятора, один из которых постоянно стоит на зарядке. Когда робот видит, что ему не хватит заряда на следующую задачу, он идёт и самостоятельно меняет себе аккумулятор, ставя разряженный на подзаряд, и возвращается к работе. С такими перекурами, которые займут всего 5-10% рабочего времени, робот сможет функционировать круглыми сутками. Для теслы этот вид зарядки не взлетел, но для роботов вполне может, поскольку робот сможет заниматься этим полностью автономно.
Ну в крайнем случае можно просто иметь двух роботов, один из которых заряжается, а второй работает — вопрос только в стоимости. Короче говоря, проблема слабого аккумулятора точно не ставит крест на использовании этих роботов уже сегодня.
Не очень понимаю, как вы можете модифицировать этот код так, чтобы ждать было не нужно?
Если же говорить о случаях, когда совсем-совсем не надо ждать, в голову приходит что-то вроде удаления временного файла после выполнения запроса. Но это делается не то что без await, но и без промисов. Достаточно просто использовать пустой колбэк:
Но это всё же достаточно редкий случай, чаще всего как раз ждать приходится.
Если тимлид оценивает программиста, и этот тимлид адекватен, то он может разобраться в сложной ситуации. Например, когда программист закрывает мало тикетов и пишет мало кода именно потому, что он решает самые сложные задачи самым эффективным способом. Хороший тимлид видит это, и усилия программиста оцениваются по достоинству.
Если же программиста оценивает не человек, а компьютер (тикет-трекер или репозиторий с прикрученными алгоритмами, считающими KPI), в разработке начинается хаос.
Короче говоря, я против KPI. Не придумано пока ничего, что работало бы хоть более-менее универсально.