SOL Talks
Важная для меня тема. За всё время, что я программирую, я «изучил» весьма внушительное количество разнообразных языков. На некоторых я по итогу не написал ничего больше 100 строк кода, но ещё ни разу не пожалел о потраченном времени. Почему? Для меня изучение…
Тут тем временем язык Crystal 1.0 зарелизился. Выглядит как такой себе статически типизированный компилируемый Ruby, а последний мне всегда нравился в первую очередь приятным синтаксисом.
Я на Crystal не писал и, пожалуй, не буду. Там вон по ходу даже поддержка винды не полная. Не то чтобы это было каким-то шоу-стоппером для меня, так как у меня в ходу девайсы со всеми популярными десктопными операционками (с обеими то есть 🙃), но закладываться на язык без кроссплатформенности в наше время я бы не стал.
Тем не менее, релиз 1.0 — это всегда важный майлстоун для любого языка. Помню, синтаксис Rust до 1.0 менялся чуть ли не каждый месяц; а пока я ждал 1.0 для Nim, успел на него забить. Наверное, и стабильного релиза Red не дождусь 🙁
Я на Crystal не писал и, пожалуй, не буду. Там вон по ходу даже поддержка винды не полная. Не то чтобы это было каким-то шоу-стоппером для меня, так как у меня в ходу девайсы со всеми популярными десктопными операционками (с обеими то есть 🙃), но закладываться на язык без кроссплатформенности в наше время я бы не стал.
Тем не менее, релиз 1.0 — это всегда важный майлстоун для любого языка. Помню, синтаксис Rust до 1.0 менялся чуть ли не каждый месяц; а пока я ждал 1.0 для Nim, успел на него забить. Наверное, и стабильного релиза Red не дождусь 🙁
The Crystal Programming Language
Crystal is a general-purpose, object-oriented programming language. With syntax inspired by Ruby, it’s a compiled language with static type-checking. Types are resolved by an advanced type inference algorithm.
Девелоперы постоянно ноют про митинги (совещания по-нашему), мол, их настолько много, что работать-то некогда, и они настолько бесполезные, что время уходит попусту.
Это канеш один из основных индикаторов проблем с коммуникацией, а также камень преткновения, мешающий инженерам и руководителям подружиться. Плохие-плохие манагеры затаскали по тупым митингам! Причём к тупым обычно относят те, на которых нужно обрисовать статус работы.
Ребята, менеджерам митинги нахуй не спеклись, отвечаю. Мудаков хватает естественно, но так или иначе каждый менеджер мечтает лишь об одном: делегировать задачу и быть уверенным, что она будет выполнена как минимум в срок и с качеством не меньшим, чем он/а рассчитывает.
Тут сразу несколько проблем. Во-первых, конечно, постановка задачи. Ну, тут всё ясно: прояснить реквайрменты, устроить груминги-хуюминги, задефайнить риски и т.д. — без обсуждения никуда.
Вторая проблема побольше: отсутствие доверия и какой-либо обратной связи. Если я не доверяю подчинённому девелоперу или менеджеру, то так или иначе мне придётся его дёргать и спрашивать, как продвигаются дела. Многие даже если уже видят проблему, то ссыкуются сказать, рассчитывая, что ближе к концу оно как-то рассосётся. Не рассосётся! А даже если и да, то можно вообще это выставить как ачивмент 😉 Но чем раньше я узнаю, что что-то пошло не по плану, тем больше у меня пространства для манёвра. И тем раньше я смогу сказать своему руководителю, чтобы и у него оно было.
Короче, рецепт прост: хотите меньше митингов — сделайте так, чтобы на вас можно было положиться.
Это канеш один из основных индикаторов проблем с коммуникацией, а также камень преткновения, мешающий инженерам и руководителям подружиться. Плохие-плохие манагеры затаскали по тупым митингам! Причём к тупым обычно относят те, на которых нужно обрисовать статус работы.
Ребята, менеджерам митинги нахуй не спеклись, отвечаю. Мудаков хватает естественно, но так или иначе каждый менеджер мечтает лишь об одном: делегировать задачу и быть уверенным, что она будет выполнена как минимум в срок и с качеством не меньшим, чем он/а рассчитывает.
Тут сразу несколько проблем. Во-первых, конечно, постановка задачи. Ну, тут всё ясно: прояснить реквайрменты, устроить груминги-хуюминги, задефайнить риски и т.д. — без обсуждения никуда.
Вторая проблема побольше: отсутствие доверия и какой-либо обратной связи. Если я не доверяю подчинённому девелоперу или менеджеру, то так или иначе мне придётся его дёргать и спрашивать, как продвигаются дела. Многие даже если уже видят проблему, то ссыкуются сказать, рассчитывая, что ближе к концу оно как-то рассосётся. Не рассосётся! А даже если и да, то можно вообще это выставить как ачивмент 😉 Но чем раньше я узнаю, что что-то пошло не по плану, тем больше у меня пространства для манёвра. И тем раньше я смогу сказать своему руководителю, чтобы и у него оно было.
Короче, рецепт прост: хотите меньше митингов — сделайте так, чтобы на вас можно было положиться.
-----------------------------------------
Ну и чисто из моего опыта.
Был у меня в подчинении чувак: очень умный и скилловый девелопер, но любил уйти в астрал в поисках идеальной архитектуры, покрывающей 100,1% кейсов. Зная о его склонности оверинжинирить, мы с нашим архитектором и этим типочком проработали дизайн модуля системы без излишеств, но с прицелом на возможное расширение в будущем, и взяли с чела обещание, что именно в таком виде оно и будет заимплеменчено. Работы недели на две и 500 строк кода от силы, ей-богу. Договорились синкаться несколько раз в неделю. Вроде всё поначалу неплохо шло, но в какой-то момент WIP-коммит чел вылить на ревью отказался, мол, чуть надо причесать. В конце концов он его ещё пару месяцев «причёсывал», время релиза наступило, пришлось регрессии гнать — куча ресурсов просрана. До конца этот модуль до сих пор небось никто не понимает. Отличный урок мне вышел. Жаль, что через какое-то время чувак ушёл из конторы; поспешил — мы как раз через неделю собирались его сами выпиздить на мороз.
Ещё пример: другой девелопер делает тасочки и фиксит баги очень быстро, но порой немного «на отъебись». Не то чтобы херово, но вот немного глубже бы копнуть или наоборот вокруг осмотреться — и было бы лучше. Но мотивации у него не было как-то, а у меня соответственно — доверия. Провели кое-какую работу на разных уровнях, и что вы думаете? Сейчас я говорю ему просто: «Сделай заебись». И всё, работа сделана, а если возникают препятствия, я узнаю об этом заранее. Много митингов надо теперь, думаете? 🙂
Ну и чисто из моего опыта.
Был у меня в подчинении чувак: очень умный и скилловый девелопер, но любил уйти в астрал в поисках идеальной архитектуры, покрывающей 100,1% кейсов. Зная о его склонности оверинжинирить, мы с нашим архитектором и этим типочком проработали дизайн модуля системы без излишеств, но с прицелом на возможное расширение в будущем, и взяли с чела обещание, что именно в таком виде оно и будет заимплеменчено. Работы недели на две и 500 строк кода от силы, ей-богу. Договорились синкаться несколько раз в неделю. Вроде всё поначалу неплохо шло, но в какой-то момент WIP-коммит чел вылить на ревью отказался, мол, чуть надо причесать. В конце концов он его ещё пару месяцев «причёсывал», время релиза наступило, пришлось регрессии гнать — куча ресурсов просрана. До конца этот модуль до сих пор небось никто не понимает. Отличный урок мне вышел. Жаль, что через какое-то время чувак ушёл из конторы; поспешил — мы как раз через неделю собирались его сами выпиздить на мороз.
Ещё пример: другой девелопер делает тасочки и фиксит баги очень быстро, но порой немного «на отъебись». Не то чтобы херово, но вот немного глубже бы копнуть или наоборот вокруг осмотреться — и было бы лучше. Но мотивации у него не было как-то, а у меня соответственно — доверия. Провели кое-какую работу на разных уровнях, и что вы думаете? Сейчас я говорю ему просто: «Сделай заебись». И всё, работа сделана, а если возникают препятствия, я узнаю об этом заранее. Много митингов надо теперь, думаете? 🙂
Кажется, появился потенциальный конкурент LaMetric — Tidbyt. Не могу объяснить, почему мне нравится такое дерьмо. Вроде я не большой любитель ретро, но иногда прям любопытные штуки попадаются. Придётся брать™. (Ну, не за двести баксов конечно. За полтинник я б подумал. А пока, как говорится, «скажи мне, кто твой конкурент, и оба идите нахуй»).
Помню, кстати, лет двадцать назад играл в квест под названием «Ядерный титбит». Трэш тот ещё был.
Помню, кстати, лет двадцать назад играл в квест под названием «Ядерный титбит». Трэш тот ещё был.
Kickstarter
Tidbyt: The Retro Display from the Future
Tidbyt is a lo-fi smart display that gives you weather, stocks, transit, and a whole lot more.
Глядите, какой протез руки. Это, конечно, ещё не Адам Дженсен, но чисто внешне прототип выглядит достаточно впечатляюще. Всему, что я видел раньше, будто не хватало именно эстетической составляющей. Надеюсь, тема будет развиваться и дальше и приведёт нас в светлое кибернетическое будущее.
Кстати, автор изделия — украинский стартап Esper Bionics.
Кстати, автор изделия — украинский стартап Esper Bionics.
YouTube
Nika uses Esper Hand. By Esper Bionics
Subscribe to see what are the next upgrades.
Nika is amazing and a fast learner.
A month ago she tried her left hand for the first time in her life: https://youtu.be/xR8yVsT4zFM
If you want to become a user of the hand or join the team, please apply here:…
Nika is amazing and a fast learner.
A month ago she tried her left hand for the first time in her life: https://youtu.be/xR8yVsT4zFM
If you want to become a user of the hand or join the team, please apply here:…
Есть нечто притягательное в терминальных интерфейсах. Думаю, всё дело в простоте и строгой лэйаутной сетке. Например, чел написал приложение для отображения статистики пользователя на гитхабе. Выглядит местами и правда неплохо, но, исусе, как же адски бесит этот отступ справа от аватарки. Даже больше, чем снизу. Польза pie-диаграмм в таком виде мне тоже представляется сомнительной. Всё-таки лучше под конкретные нужды выбирать конкретные хорошие инструменты.
Я вроде кое-что в графическом дизайне понимаю; больше на уровне интуиции, конечно, но и теоретическая база кое-какая есть. Ну, и чувство прекрасного в определённой степени имеется — люблю, когда красиво (субъективщина, очевидно)!
Но типографика… У-у-у, типøгра
Такое имеет смысл разве что при создании уникального стиля бренда, но явно не в спорах про внешний вид софта или нонейм-сайта. Для приложений вообще нет смысла особо заморачиваться выбором обычно; для веб-сайтов иногда можно, если хочется походить на настоящие газеты. В среднем достаточно метрики «покатит / не покатит».
Даже миф о том, что в печатном виде лучше воспринимаются шрифты с засечками, а на экранах — без, не нашёл прямого подтверждения в исследованиях, а вот опровержения были.
Я что-то упускаю по всей видимости. Небось когда-то начитаюсь всякого и буду вам тут затирать про кернинги и интерлиньяжи. Но пока что не алё. Даже на канал тематический подписался, но не шевелится внутри ничего при просмотре.
Но типографика… У-у-у, типøгра
фика — это целый мир! Мир снобизма по моим ощущениям. То ли я прям вообще не шарю, то ли хз, однако, все эти ваши антиквы, гротески, акцидентные шрифты и т.д. не стоят столько внимания, сколько им уделяют. Да, поигравшись параметрами, можно сделать говно, а можно сделать норм — тут вопросов ноль. Но прям надрачивать на форму хвостика в букве Q — это примерно как «округлый и гибкий» вкус вина. Такое имеет смысл разве что при создании уникального стиля бренда, но явно не в спорах про внешний вид софта или нонейм-сайта. Для приложений вообще нет смысла особо заморачиваться выбором обычно; для веб-сайтов иногда можно, если хочется походить на настоящие газеты. В среднем достаточно метрики «покатит / не покатит».
Даже миф о том, что в печатном виде лучше воспринимаются шрифты с засечками, а на экранах — без, не нашёл прямого подтверждения в исследованиях, а вот опровержения были.
Я что-то упускаю по всей видимости. Небось когда-то начитаюсь всякого и буду вам тут затирать про кернинги и интерлиньяжи. Но пока что не алё. Даже на канал тематический подписался, но не шевелится внутри ничего при просмотре.
This media is not supported in your browser
VIEW IN TELEGRAM
В гуглоклаве на android обнаружилась абсолютно упоротая, но стёбная фича, позволяющая комбинировать разные emoji в один стикер. Залип минут на десять. Наверняка она там уже вечность, но не обращал внимания.
Media is too big
VIEW IN TELEGRAM
Было уже немало попыток сделать модульный девайс, но эта пока самая впечатляющая. Нравится, что всё подключаемое подхватывается на лету и просто работает (для линукса вообще будто невообразимое достижение).
Теперь о том, что не нравится. Во-первых, магнитные крепления выглядят не слишком надёжными, но тут хз — надо пробовать. Во-вторых, сама идея такого устройства немного мутная. Моя Insta360 One R тоже модульная, но у неё одно предназначение — снимать видосы. Тут же по сути универсальное устройство: можно сделать карманный комп, метеостанцию, диспенсер для мыла и прочую ебатеку, на которую хватит фантазии. Классно, но в этом и проблема: если у меня есть конкретный юзкейс или несколько, то проще и дешевле купить монолитный гаджет. В противном случае собирать-разбирать заебёшься. Ну и с модулями сложно определиться: каких-то будет не хватать, какие-то будут валяться без дела. Игрушка короче.
Но круто, да. Сдыбал на реддите. Вот официальный сайт.
Теперь о том, что не нравится. Во-первых, магнитные крепления выглядят не слишком надёжными, но тут хз — надо пробовать. Во-вторых, сама идея такого устройства немного мутная. Моя Insta360 One R тоже модульная, но у неё одно предназначение — снимать видосы. Тут же по сути универсальное устройство: можно сделать карманный комп, метеостанцию, диспенсер для мыла и прочую ебатеку, на которую хватит фантазии. Классно, но в этом и проблема: если у меня есть конкретный юзкейс или несколько, то проще и дешевле купить монолитный гаджет. В противном случае собирать-разбирать заебёшься. Ну и с модулями сложно определиться: каких-то будет не хватать, какие-то будут валяться без дела. Игрушка короче.
Но круто, да. Сдыбал на реддите. Вот официальный сайт.
История ходит по кругу, ну или как минимум по спирали. На текущем витке это называют «миллениалы переизобрели».
Программистам стало скучно, и они (снова) сделали виртуального питомца, чтоб получать свою долю окситоцина, пока пишешь код. В целом мне всегда нравились подобные бессмысленные штуки, мы даже с другом делали нечто отдалённо похожее. Но блин, зачем пиксель-арт? Даже Clippy в MS Office выглядел симпатичнее (его, кстати, можно было поменять на пёсика, кошечку :3 и пр.).
Программистам стало скучно, и они (снова) сделали виртуального питомца, чтоб получать свою долю окситоцина, пока пишешь код. В целом мне всегда нравились подобные бессмысленные штуки, мы даже с другом делали нечто отдалённо похожее. Но блин, зачем пиксель-арт? Даже Clippy в MS Office выглядел симпатичнее (его, кстати, можно было поменять на пёсика, кошечку :3 и пр.).
Visualstudio
vscode-pets - Visual Studio Marketplace
Extension for Visual Studio Code - Pets for your VS Code
SOL Talks
История ходит по кругу, ну или как минимум по спирали. На текущем витке это называют «миллениалы переизобрели». Программистам стало скучно, и они (снова) сделали виртуального питомца, чтоб получать свою долю окситоцина, пока пишешь код. В целом мне всегда…
Жалкая копия и неповторимый оригинал (sheep.exe)
Ну и раз уж я один из тех, кто занят созданием MBUX — инфотейнмент-системы в новых Мерседесах, держите немного однотипных фоточек грядущего EQS с гиперскрином (так и называется, ей-богу). Презентация намечена на 15 апреля вроде.
SOL Talks
Окунаясь в управленческие темы, я обнаружил забавный и вроде как очевидный эффект, который ранее мне таковым не представлялся: То, что вы изучаете об управлении людьми, в первую очередь вам пригодится для управления самим собой. Если взять шире, то можно…
Я снова не смог написать кратко, но уж как вышло.
Существует мнение будто менеджеры, которые выросли из инженеров, управляют людьми плохо. И ведь на самом деле так и есть! У меня десятки примеров в личном опыте, включая меня самого.
Наиболее частый путь следующий: проект растёт, людей быстро набирают, кого-то назначают их менторить, в какой-то момент менеджеров перестаёт хватать. И тогда один из последних подходит к самому адекватному из команды в лучшем случае, а то и просто к самому способному инженеру в худшем и грит: «Слу, ты ж этих людей уже обучал всё равно. Теперь надо ещё немного помониторить их работу, раскидать задачки. Хуле там сложного, м?» — И на этом всё в общем-то. Человек соглашается на лычку тимлида и думает, что это и есть менеджмент, а его руководитель тем временем часть задач делегировал и больше не парится. Многие в таком состоянии прям и остаются на годы. И это ок, наверное.
Проблемы начинаются, если рост продолжается. Тут вроде два основных варианта (помимо редкого «как должно быть на самом деле» — мне по крайней мере с этим не повезло).
1. Новоиспечённый тимлид начинает зашиваться, времени на всё не хватает, а код писать ещё хочется, поэтому он сам уже ищет, кому б чё делегировать. Подходит к кому-то из команды и грит: «Слу, там надо вот это и это промониторить, хуле там. Сможешь?» — И круг замыкается. Никаких объяснений, в чём состоит работа, никаких особых напутствий.
2. Ещё хуже, если тимлид идёт на уровень выше, заводит себе своих подчинённых менеджеров и управляет в духе: «Так блэд, я теперь тут босс нахуй». По ощущениям этим часто грешат выходцы из СНГ, но у меня выборка не оч разнообразная так-то.
Оба варианта — это, конечно, всего лишь недостаток компетенции. Управлять людьми по наитию можно с некоторой долей эффективности лишь первое время. Некоторым это даётся лучше с ходу, но каким бы крутым вы ни были, без теории очень быстро и легко достичь потолка.
Но есть вариант, который бесит меня больше всего! Это когда бывший инженер настолько ударяется в менеджерскую стезю, что игнорирует свой предыдущий опыт. С этими людьми каши не сваришь. Они возможно ещё способны общаться с теми же программистами на одном языке благодаря своим остаточным знаниям, но они не помнят, каково это — быть программистом. Они не могут встать на место рядового инженера, прочувствовать его боль и нужды. «Так а чо, тут просто процесс новый введём и обяжем всех ему следовать». К сожалению, таких руководителей в моей практике больше, чем хотелось бы.
И вот буквально на прошлой неделе кто-то на HN раскопал старую статью с Harvard Business Review, говорящую о том, что согласно исследованиям люди в среднем счастливее на работе, если их руководитель способен при необходимости выполнять их обязанности. Другими словами, если он технически подкован 🙂 Причём оказалось, что это чуть ли не самый влиятельный фактор.
К чему я это… Если вы «рядовой» сотрудник и внезапно стали тимлидом, техлидом, engineering manager'ом и т.п., то высока вероятность, что управленческая часть — ваша слабая сторона. Безусловно имеет смысл инвестировать время в образование по теме. Но и корни свои забывать тоже не стоит!
Существует мнение будто менеджеры, которые выросли из инженеров, управляют людьми плохо. И ведь на самом деле так и есть! У меня десятки примеров в личном опыте, включая меня самого.
Наиболее частый путь следующий: проект растёт, людей быстро набирают, кого-то назначают их менторить, в какой-то момент менеджеров перестаёт хватать. И тогда один из последних подходит к самому адекватному из команды в лучшем случае, а то и просто к самому способному инженеру в худшем и грит: «Слу, ты ж этих людей уже обучал всё равно. Теперь надо ещё немного помониторить их работу, раскидать задачки. Хуле там сложного, м?» — И на этом всё в общем-то. Человек соглашается на лычку тимлида и думает, что это и есть менеджмент, а его руководитель тем временем часть задач делегировал и больше не парится. Многие в таком состоянии прям и остаются на годы. И это ок, наверное.
Проблемы начинаются, если рост продолжается. Тут вроде два основных варианта (помимо редкого «как должно быть на самом деле» — мне по крайней мере с этим не повезло).
1. Новоиспечённый тимлид начинает зашиваться, времени на всё не хватает, а код писать ещё хочется, поэтому он сам уже ищет, кому б чё делегировать. Подходит к кому-то из команды и грит: «Слу, там надо вот это и это промониторить, хуле там. Сможешь?» — И круг замыкается. Никаких объяснений, в чём состоит работа, никаких особых напутствий.
2. Ещё хуже, если тимлид идёт на уровень выше, заводит себе своих подчинённых менеджеров и управляет в духе: «Так блэд, я теперь тут босс нахуй». По ощущениям этим часто грешат выходцы из СНГ, но у меня выборка не оч разнообразная так-то.
Оба варианта — это, конечно, всего лишь недостаток компетенции. Управлять людьми по наитию можно с некоторой долей эффективности лишь первое время. Некоторым это даётся лучше с ходу, но каким бы крутым вы ни были, без теории очень быстро и легко достичь потолка.
Но есть вариант, который бесит меня больше всего! Это когда бывший инженер настолько ударяется в менеджерскую стезю, что игнорирует свой предыдущий опыт. С этими людьми каши не сваришь. Они возможно ещё способны общаться с теми же программистами на одном языке благодаря своим остаточным знаниям, но они не помнят, каково это — быть программистом. Они не могут встать на место рядового инженера, прочувствовать его боль и нужды. «Так а чо, тут просто процесс новый введём и обяжем всех ему следовать». К сожалению, таких руководителей в моей практике больше, чем хотелось бы.
И вот буквально на прошлой неделе кто-то на HN раскопал старую статью с Harvard Business Review, говорящую о том, что согласно исследованиям люди в среднем счастливее на работе, если их руководитель способен при необходимости выполнять их обязанности. Другими словами, если он технически подкован 🙂 Причём оказалось, что это чуть ли не самый влиятельный фактор.
К чему я это… Если вы «рядовой» сотрудник и внезапно стали тимлидом, техлидом, engineering manager'ом и т.п., то высока вероятность, что управленческая часть — ваша слабая сторона. Безусловно имеет смысл инвестировать время в образование по теме. Но и корни свои забывать тоже не стоит!
Harvard Business Review
If Your Boss Could Do Your Job, You’re More Likely to Be Happy at Work
Technical competence matters for managers.
SOL Talks
Ну и раз уж я один из тех, кто занят созданием MBUX — инфотейнмент-системы в новых Мерседесах, держите немного однотипных фоточек грядущего EQS с гиперскрином (так и называется, ей-богу). Презентация намечена на 15 апреля вроде.
Разгребаю залежи непрочитанных статей. Наткнулся на интересное.
Не секрет, что MBUX написан на C++ и QML. Если с первым всё ясно, то последний известен в меньшей мере и представляет собой декларативный язык для UI в составе фреймворка Qt. Он позволяет нам и быстродействия добиться, и шейдеров всяких для эффектов поверх навернуть, и модельку машины в 3D покрутить, и при этом достаточно быстро весь этот полностью кастомный интерфейс разрабатывать.
Собсно, даже сама Qt Company сильно к автомотив-отрасли и прочим embedded-системам нынче тяготеет. В отличие от Nokia — предыдущего владельца Qt — им не так интересны мобильные приложения, а про десктоп и говорить нечего — веб-приложения всё вытесняют.
И тут в конце прошлого года оказалось, что Epic Games, не нуждающаяся в представлении, запартнёрилась с General Motors, и следующий Hummer последних выйдет с HMI на основе Unreal Engine.
Оно и понятно. Unreal Engine — это игровой движок, а кто, как не гейм-девелоперы, шарит в создании кастомных UI и выжимании фпс-ов даже на слабом железе? С последним, кстати, ситуация тоже упростилась. Даже первое поколение MBUX, выпущенное вместе с «бюджетным» A-class, работало на вполне себе не слабой Tegra.
В среднем, короче, перспективы у Qt Company выглядят не очень радужно. А мой любимый QML, как и полагается любой хорошей технологии, канет в Лету небось, уступив место всяким модным костылям.
Вдвойне забавно, что с одним из типцов из видео мы раньше вместе работали 🙂
Не секрет, что MBUX написан на C++ и QML. Если с первым всё ясно, то последний известен в меньшей мере и представляет собой декларативный язык для UI в составе фреймворка Qt. Он позволяет нам и быстродействия добиться, и шейдеров всяких для эффектов поверх навернуть, и модельку машины в 3D покрутить, и при этом достаточно быстро весь этот полностью кастомный интерфейс разрабатывать.
Собсно, даже сама Qt Company сильно к автомотив-отрасли и прочим embedded-системам нынче тяготеет. В отличие от Nokia — предыдущего владельца Qt — им не так интересны мобильные приложения, а про десктоп и говорить нечего — веб-приложения всё вытесняют.
И тут в конце прошлого года оказалось, что Epic Games, не нуждающаяся в представлении, запартнёрилась с General Motors, и следующий Hummer последних выйдет с HMI на основе Unreal Engine.
Оно и понятно. Unreal Engine — это игровой движок, а кто, как не гейм-девелоперы, шарит в создании кастомных UI и выжимании фпс-ов даже на слабом железе? С последним, кстати, ситуация тоже упростилась. Даже первое поколение MBUX, выпущенное вместе с «бюджетным» A-class, работало на вполне себе не слабой Tegra.
В среднем, короче, перспективы у Qt Company выглядят не очень радужно. А мой любимый QML, как и полагается любой хорошей технологии, канет в Лету небось, уступив место всяким модным костылям.
Вдвойне забавно, что с одним из типцов из видео мы раньше вместе работали 🙂
YouTube
Unreal Engine HMI Initiative | Automotive
Human-machine interfaces (HMI) are one of the next great frontiers for the automotive industry. At Epic Games, we’re committed to developing functionality that will empower HMI UI designers to create highly-engaging 2D/3D infotainment experiences. General…