Ну вот такой конструктивный просчёт (ну или если хотите, особенность модели). На версии для арабского рынка есть дополнительный радиатор охлаждения КПП - это один из способов решения проблемы.
Мне бы вообще хотелось на этой машине МКПП, но имеем что имеем.
Сидеть и часами буксовать на одном месте - путь вникуда, даже если отбросить перегревы, банально только закопаетесь. Нужно прибегнуть к подручным средствам для эвакуации, например сенд-траки подложить, или какой-н валяющийся вокруг хлам в качестве них использовать, и спокойненько выехать ничего не перегружая. Нет сенд-траков и вокруг Сахара?
Вокруг не Сахара, а вполне себе Кузомень. Буксовать конечно не на месте. Просто "дорога" покрыта достаточно толстым слоем песка и автомобиль хоть и движется, но с пробуксовкой (и соответствующими нагрузками на трансмиссию). Не все ездять по асфальту.
Ну тут возвращаемся к вопросу здравого смысла - нафига туда переться на неподготовленной машине
А кто сказал, что на неподготовленной? Но в любом случае, производитель позиционирует автомобиль как внедорожник (и приводит даже в руководстве рекомендации по преодолению разных препятствий). Потому иметь дополнительные средства отслеживания состояния агрегатов - вполне укладывается в позиционирование этого автомобиля.
Если уже начался "пар из-под капота", то у меня есть плохие новости - двигатель уже перегрелся и может быть случились неприятности вида "повело ГБЦ и пробило её прокладку". Потому стрелка, которая показывает, что "начинаются какие-то нештатные процессы" - нужна и полезно. А водитель пусть интерпретирует: греется оно потому что мы в горку в пробке едем (и это ожидаемо в некоторых разумных пределах) или же греется непонятно почему и надо лезть разбираться.
Вот вам пример: Mitsubishi Pajero Sport 2 поколения. В некоторых режимах работы (не спорю, не самых простых) начинает греться АКПП (а через теплообменник АКПП в радиаторе двигателя - и сам двигатель).
Есть лампочка перегрева АКПП, но она загорается когда уже "совсем капец". Очень хотелось бы момент когда "чёт греется" ловить раньше. Но увы.
Режимы работы - что-то типа "ехать в горку в течение 2-3 часов" или "тащить тяжёлый прицеп по трассе со скоростями 100-110" или "буксовать в песке".
В моём случае датчик "вроде как" должен именно напряжение выдавать, но учитывая, что из документации только страничка описания на aliexpress, полагаю может быть всякое.
На WB же вполне себе линукс, можно прямо на нём писать. https://wirenboard.com/wiki/Cpp Присматриваюсь в ним, нужен контроллер для управления контурами тёплого пола и котлом, а собирать из ESP32 и релюшек уже как-то неохота (хочется чтобы "прикрутил кабели и кодишь и сразу всё красиво выглядит").
А какой датчик давления использовали и как подключали? Я как-то возился с GS01525 и постоянно имел проблемы с тем, что он выдаёт чепуху (то-ли из-за помех, то-ли потому что делаю что-то не так). Был бы признателен за схему.
В нормальном вузе будут преподавать сети, устройство операционной системы (а на практике придётся собственно "взаимодействовать с ОС на высоком уровне" - файлы, сокеты, пайпы, процессы и потоки).
И также там будет курс по формальным грамматикам (откуда наш реальный программист узнает, как вообще правильно и эффективно что-либо парсить и перекладывать). Ну и всякие мелочи, вроде сложности алгоритмов (не пихай N^2 куда не надо), формальной логики (чтобы можно было написать сколько-нибудь сложное условие), SQL и устройства БД, криптографии (как оно работает и почему не надо его писать вручную) и прочее-прочее-прочее.
ИМХО, это очень сильно пересекается с набором знаний, которые требуются программисту в реальной работе. Понятно, что в зависимости от работы будет подмножество того, что давали в ВУЗе, но тем не менее.
Там оно по историческим причинам, legacy так сказать. И для сохранения обратной совместимости мы конечно его переконвертировать не будем.
Вопрос вот какой: для чего нам в нашем проекте может потребоваться сохранять данные в UTF-16? Имеются в виду конечно те данные, которые "внутри" проекта (понятно, что при интеграции с чем-то, где используется UTF-16, нам придётся его использовать, но от этого конечно не денешься никуда).
Касаемо же утилит, неверно определяющих кодировку - а зачем её определять? Опять же, либо мы знаем кодировку полученных данных (по заголовкам запросов-ответов или по какому-то соглашению вида "все наши файлы храним в UTF-8"), либо не знаем. И во втором случае BOM опять же может как быть, так и нет (т.е. ситуацию "прилетело нечто без BOM" обрабатывать придётся). BOM поможет в ситуации "можем иметь на входе разный юникод, но обязательно юникод и обязательно с BOM". Но мне такая ситуация кажется крайне маловероятной.
Дак опять же, тут ситуация, что мы "знаем", в какой кодировке сохраняли. Можно конечно такую информацию запихать и в BOM, но это не очень удобно, если полученные файлы надо обрабатывать чем-то, кроме своего кода.
И слабо представляю ситуацию, когда нужен UTF-16, если честно.
Не соглашусь. Если мы знаем, что в файле UTF-8, то BOM просто не нужен. А если не знаем, что там, то запросто может быть и без BOM, стало быть нам всё равно нужны какие-то эвристики.
А ситуаций, когда случайная %PROGRAMNAME% не понимает BOM было много. И отлаживать их тяжело.
Докину своего опыта. Сервер - самосбор. Раньше был просто ПК на Intel Core i3 каком-то старом. Потом сервер переехал в гараж и обзавёлся комплектом из 2xIntel Xeon на китайской плате от SZMZ. Вопреки опасениям, работает без глюков уже 3 года как.
Из софта могу порекомендовать OpenHab (почти как HomeAssistant, но не он).
И ещё для заметок - Joplin. Подкупает наличием клиента для Android и iOS и возможностью синхронизироваться через WebDAV (соответственно базу заметок имеем одну и ту же на компе и телефоне).
WebDAV же можно организовать при помощи Seafile, который также работает self-hosted гуглодрайвом.
У mc своих "приколов" хватает. Меня например больше всего бесит неудобный плагин для SSH/SFTP сессий. В FAR-e в NetBox все частоиспользуемые сессии сохранены и открываются буквально несколькими нажатиями клавиш. А в mc приходится каждый раз вспоминать "а как там точно этот сервер называется и какой туда логин".
Ну и не хватает кучи хоткеев для подстановки чего-либо в командную строку (Ctrl+Space, Ctrl+Enter итп).
Делается, но при этом нет фичей "посмотреть глазками, какой файл тебе нужно в эту команду подставить, одним хоткеем добавить в команду его имя, скопировать что-то куда-то". Короче, для меня в FAR самое удобное - именно синергия возможности использовать консоль с визуальным способом работы с файлами.
Киллер-фича FAR-а - интеграция с консолью (можно "не отходя от кассы" наколотить консольную команду, перенаправить её в файл, файл поглазеть штатным редактором, скопировать-поправить итп). И всё в пределах одного окна, без переключений.
А зачем альпинистам городить систему с разделением воздуха на кислород и остальное? Если уж заморачиваться с компрессором, то просто повысить давление наружного воздуха и подать его в герметичную маску - будет вполне достаточно.
Да так-то примерно любое программирование. Взять ту же логику, без которой мало-мальски сложное условие не напишешь - тоже раздел математики. Она же не ограничивается только матаном, дифурами и прочими подобными вещами. Логика, комбинаторика, прочая всякая дискретка - в программировании постоянно встречается.
Ну вот такой конструктивный просчёт (ну или если хотите, особенность модели). На версии для арабского рынка есть дополнительный радиатор охлаждения КПП - это один из способов решения проблемы.
Мне бы вообще хотелось на этой машине МКПП, но имеем что имеем.
Вокруг не Сахара, а вполне себе Кузомень. Буксовать конечно не на месте. Просто "дорога" покрыта достаточно толстым слоем песка и автомобиль хоть и движется, но с пробуксовкой (и соответствующими нагрузками на трансмиссию). Не все ездять по асфальту.
А кто сказал, что на неподготовленной? Но в любом случае, производитель позиционирует автомобиль как внедорожник (и приводит даже в руководстве рекомендации по преодолению разных препятствий). Потому иметь дополнительные средства отслеживания состояния агрегатов - вполне укладывается в позиционирование этого автомобиля.
Если уже начался "пар из-под капота", то у меня есть плохие новости - двигатель уже перегрелся и может быть случились неприятности вида "повело ГБЦ и пробило её прокладку".
Потому стрелка, которая показывает, что "начинаются какие-то нештатные процессы" - нужна и полезно. А водитель пусть интерпретирует: греется оно потому что мы в горку в пробке едем (и это ожидаемо в некоторых разумных пределах) или же греется непонятно почему и надо лезть разбираться.
Вот вам пример: Mitsubishi Pajero Sport 2 поколения. В некоторых режимах работы (не спорю, не самых простых) начинает греться АКПП (а через теплообменник АКПП в радиаторе двигателя - и сам двигатель).
Есть лампочка перегрева АКПП, но она загорается когда уже "совсем капец". Очень хотелось бы момент когда "чёт греется" ловить раньше. Но увы.
Режимы работы - что-то типа "ехать в горку в течение 2-3 часов" или "тащить тяжёлый прицеп по трассе со скоростями 100-110" или "буксовать в песке".
Спасибо! Попробую
Спасибо!
В моём случае датчик "вроде как" должен именно напряжение выдавать, но учитывая, что из документации только страничка описания на aliexpress, полагаю может быть всякое.
На WB же вполне себе линукс, можно прямо на нём писать.
https://wirenboard.com/wiki/Cpp
Присматриваюсь в ним, нужен контроллер для управления контурами тёплого пола и котлом, а собирать из ESP32 и релюшек уже как-то неохота (хочется чтобы "прикрутил кабели и кодишь и сразу всё красиво выглядит").
А какой датчик давления использовали и как подключали?
Я как-то возился с GS01525 и постоянно имел проблемы с тем, что он выдаёт чепуху (то-ли из-за помех, то-ли потому что делаю что-то не так).
Был бы признателен за схему.
В нормальном вузе будут преподавать сети, устройство операционной системы (а на практике придётся собственно "взаимодействовать с ОС на высоком уровне" - файлы, сокеты, пайпы, процессы и потоки).
И также там будет курс по формальным грамматикам (откуда наш реальный программист узнает, как вообще правильно и эффективно что-либо парсить и перекладывать).
Ну и всякие мелочи, вроде сложности алгоритмов (не пихай N^2 куда не надо), формальной логики (чтобы можно было написать сколько-нибудь сложное условие), SQL и устройства БД, криптографии (как оно работает и почему не надо его писать вручную) и прочее-прочее-прочее.
ИМХО, это очень сильно пересекается с набором знаний, которые требуются программисту в реальной работе. Понятно, что в зависимости от работы будет подмножество того, что давали в ВУЗе, но тем не менее.
Там оно по историческим причинам, legacy так сказать. И для сохранения обратной совместимости мы конечно его переконвертировать не будем.
Вопрос вот какой: для чего нам в нашем проекте может потребоваться сохранять данные в UTF-16? Имеются в виду конечно те данные, которые "внутри" проекта (понятно, что при интеграции с чем-то, где используется UTF-16, нам придётся его использовать, но от этого конечно не денешься никуда).
Касаемо же утилит, неверно определяющих кодировку - а зачем её определять?
Опять же, либо мы знаем кодировку полученных данных (по заголовкам запросов-ответов или по какому-то соглашению вида "все наши файлы храним в UTF-8"), либо не знаем. И во втором случае BOM опять же может как быть, так и нет (т.е. ситуацию "прилетело нечто без BOM" обрабатывать придётся).
BOM поможет в ситуации "можем иметь на входе разный юникод, но обязательно юникод и обязательно с BOM". Но мне такая ситуация кажется крайне маловероятной.
Дак опять же, тут ситуация, что мы "знаем", в какой кодировке сохраняли. Можно конечно такую информацию запихать и в BOM, но это не очень удобно, если полученные файлы надо обрабатывать чем-то, кроме своего кода.
И слабо представляю ситуацию, когда нужен UTF-16, если честно.
Не соглашусь.
Если мы знаем, что в файле UTF-8, то BOM просто не нужен.
А если не знаем, что там, то запросто может быть и без BOM, стало быть нам всё равно нужны какие-то эвристики.
А ситуаций, когда случайная %PROGRAMNAME% не понимает BOM было много. И отлаживать их тяжело.
Докину своего опыта.
Сервер - самосбор. Раньше был просто ПК на Intel Core i3 каком-то старом. Потом сервер переехал в гараж и обзавёлся комплектом из 2xIntel Xeon на китайской плате от SZMZ. Вопреки опасениям, работает без глюков уже 3 года как.
Из софта могу порекомендовать OpenHab (почти как HomeAssistant, но не он).
И ещё для заметок - Joplin. Подкупает наличием клиента для Android и iOS и возможностью синхронизироваться через WebDAV (соответственно базу заметок имеем одну и ту же на компе и телефоне).
WebDAV же можно организовать при помощи Seafile, который также работает self-hosted гуглодрайвом.
Плюс Gitea в качестве собственного гитлаба.
У mc своих "приколов" хватает. Меня например больше всего бесит неудобный плагин для SSH/SFTP сессий. В FAR-e в NetBox все частоиспользуемые сессии сохранены и открываются буквально несколькими нажатиями клавиш. А в mc приходится каждый раз вспоминать "а как там точно этот сервер называется и какой туда логин".
Ну и не хватает кучи хоткеев для подстановки чего-либо в командную строку (Ctrl+Space, Ctrl+Enter итп).
Делается, но при этом нет фичей "посмотреть глазками, какой файл тебе нужно в эту команду подставить, одним хоткеем добавить в команду его имя, скопировать что-то куда-то".
Короче, для меня в FAR самое удобное - именно синергия возможности использовать консоль с визуальным способом работы с файлами.
Киллер-фича FAR-а - интеграция с консолью (можно "не отходя от кассы" наколотить консольную команду, перенаправить её в файл, файл поглазеть штатным редактором, скопировать-поправить итп).
И всё в пределах одного окна, без переключений.
Точно, дошло, чего-то я тупанул, про мышцы не подумал. Тогда да, надо либо количество кислорода повышать, либо герметично упаковываться.
А можно почитать где-нить про это, интересно очень?
А зачем альпинистам городить систему с разделением воздуха на кислород и остальное?
Если уж заморачиваться с компрессором, то просто повысить давление наружного воздуха и подать его в герметичную маску - будет вполне достаточно.
Да так-то примерно любое программирование. Взять ту же логику, без которой мало-мальски сложное условие не напишешь - тоже раздел математики.
Она же не ограничивается только матаном, дифурами и прочими подобными вещами.
Логика, комбинаторика, прочая всякая дискретка - в программировании постоянно встречается.