Я вроде кое-что в графическом дизайне понимаю; больше на уровне интуиции, конечно, но и теоретическая база кое-какая есть. Ну, и чувство прекрасного в определённой степени имеется — люблю, когда красиво (субъективщина, очевидно)!

Но типографика… У-у-у, типøграфика — это целый мир! Мир снобизма по моим ощущениям. То ли я прям вообще не шарю, то ли хз, однако, все эти ваши антиквы, гротески, акцидентные шрифты и т.д. не стоят столько внимания, сколько им уделяют. Да, поигравшись параметрами, можно сделать говно, а можно сделать норм — тут вопросов ноль. Но прям надрачивать на форму хвостика в букве Q — это примерно как «округлый и гибкий» вкус вина.

Такое имеет смысл разве что при создании уникального стиля бренда, но явно не в спорах про внешний вид софта или нонейм-сайта. Для приложений вообще нет смысла особо заморачиваться выбором обычно; для веб-сайтов иногда можно, если хочется походить на настоящие газеты. В среднем достаточно метрики «покатит / не покатит».

Даже миф о том, что в печатном виде лучше воспринимаются шрифты с засечками, а на экранах — без, не нашёл прямого подтверждения в исследованиях, а вот опровержения были.

Я что-то упускаю по всей видимости. Небось когда-то начитаюсь всякого и буду вам тут затирать про кернинги и интерлиньяжи. Но пока что не алё. Даже на канал тематический подписался, но не шевелится внутри ничего при просмотре.

Справедливости ради стоит отметить, что на аватарке канала, которую я сделал за пять минут левой рукой, не какой-то унылый дефолтный Arial, а прекрасная Futura 😅

В гуглоклаве на android обнаружилась абсолютно упоротая, но стёбная фича, позволяющая комбинировать разные emoji в один стикер. Залип минут на десять. Наверняка она там уже вечность, но не обращал внимания.

Было уже немало попыток сделать модульный девайс, но эта пока самая впечатляющая. Нравится, что всё подключаемое подхватывается на лету и просто работает (для линукса вообще будто невообразимое достижение).

Теперь о том, что не нравится. Во-первых, магнитные крепления выглядят не слишком надёжными, но тут хз — надо пробовать. Во-вторых, сама идея такого устройства немного мутная. Моя Insta360 One R тоже модульная, но у неё одно предназначение — снимать видосы. Тут же по сути универсальное устройство: можно сделать карманный комп, метеостанцию, диспенсер для мыла и прочую ебатеку, на которую хватит фантазии. Классно, но в этом и проблема: если у меня есть конкретный юзкейс или несколько, то проще и дешевле купить монолитный гаджет. В противном случае собирать-разбирать заебёшься. Ну и с модулями сложно определиться: каких-то будет не хватать, какие-то будут валяться без дела. Игрушка короче.

Но круто, да. Сдыбал на реддите. Вот официальный сайт.

История ходит по кругу, ну или как минимум по спирали. На текущем витке это называют «миллениалы переизобрели».

Программистам стало скучно, и они (снова) сделали виртуального питомца, чтоб получать свою долю окситоцина, пока пишешь код. В целом мне всегда нравились подобные бессмысленные штуки, мы даже с другом делали нечто отдалённо похожее. Но блин, зачем пиксель-арт? Даже Clippy в MS Office выглядел симпатичнее (его, кстати, можно было поменять на пёсика, кошечку :3 и пр.).

Жалкая копия и неповторимый оригинал (sheep.exe)

Я снова не смог написать кратко, но уж как вышло.

Существует мнение будто менеджеры, которые выросли из инженеров, управляют людьми плохо. И ведь на самом деле так и есть! У меня десятки примеров в личном опыте, включая меня самого.

Наиболее частый путь следующий: проект растёт, людей быстро набирают, кого-то назначают их менторить, в какой-то момент менеджеров перестаёт хватать. И тогда один из последних подходит к самому адекватному из команды в лучшем случае, а то и просто к самому способному инженеру в худшем и грит: «Слу, ты ж этих людей уже обучал всё равно. Теперь надо ещё немного помониторить их работу, раскидать задачки. Хуле там сложного, м?» — И на этом всё в общем-то. Человек соглашается на лычку тимлида и думает, что это и есть менеджмент, а его руководитель тем временем часть задач делегировал и больше не парится. Многие в таком состоянии прям и остаются на годы. И это ок, наверное.

Проблемы начинаются, если рост продолжается. Тут вроде два основных варианта (помимо редкого «как должно быть на самом деле» — мне по крайней мере с этим не повезло).

1. Новоиспечённый тимлид начинает зашиваться, времени на всё не хватает, а код писать ещё хочется, поэтому он сам уже ищет, кому б чё делегировать. Подходит к кому-то из команды и грит: «Слу, там надо вот это и это промониторить, хуле там. Сможешь?» — И круг замыкается. Никаких объяснений, в чём состоит работа, никаких особых напутствий.

2. Ещё хуже, если тимлид идёт на уровень выше, заводит себе своих подчинённых менеджеров и управляет в духе: «Так блэд, я теперь тут босс нахуй». По ощущениям этим часто грешат выходцы из СНГ, но у меня выборка не оч разнообразная так-то.

Оба варианта — это, конечно, всего лишь недостаток компетенции. Управлять людьми по наитию можно с некоторой долей эффективности лишь первое время. Некоторым это даётся лучше с ходу, но каким бы крутым вы ни были, без теории очень быстро и легко достичь потолка.

Но есть вариант, который бесит меня больше всего! Это когда бывший инженер настолько ударяется в менеджерскую стезю, что игнорирует свой предыдущий опыт. С этими людьми каши не сваришь. Они возможно ещё способны общаться с теми же программистами на одном языке благодаря своим остаточным знаниям, но они не помнят, каково это — быть программистом. Они не могут встать на место рядового инженера, прочувствовать его боль и нужды. «Так а чо, тут просто процесс новый введём и обяжем всех ему следовать». К сожалению, таких руководителей в моей практике больше, чем хотелось бы.

И вот буквально на прошлой неделе кто-то на HN раскопал старую статью с Harvard Business Review, говорящую о том, что согласно исследованиям люди в среднем счастливее на работе, если их руководитель способен при необходимости выполнять их обязанности. Другими словами, если он технически подкован 🙂 Причём оказалось, что это чуть ли не самый влиятельный фактор.

К чему я это… Если вы «рядовой» сотрудник и внезапно стали тимлидом, техлидом, engineering manager'ом и т.п., то высока вероятность, что управленческая часть — ваша слабая сторона. Безусловно имеет смысл инвестировать время в образование по теме. Но и корни свои забывать тоже не стоит!

Разгребаю залежи непрочитанных статей. Наткнулся на интересное.

Не секрет, что 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, как и полагается любой хорошей технологии, канет в Лету небось, уступив место всяким модным костылям.

Вдвойне забавно, что с одним из типцов из видео мы раньше вместе работали 🙂

Тут Sublime Text тизернул недавно четвёртую версию. В принципе выглядит ок, но не подкупает. Ничего такого, чего бы мы уже не видели в VS Code. С другой стороны, последний как-то потихоньку обрастает фичами и уже не такой резвый, а саблайм наверняка всё ещё стартует со скоростью дабл-клика.

Когда-то давно Sublime Text 2 стал для меня триггером перехода с использования IDE на редакторы кода именно потому, что [я в нём] работал супербыстро. (С тех пор, кстати, не видел Notepad++ — лет 8–9 уже). Оказалось, что всякие там go to definition и прочие extract method’ы — это, конечно, прикольно, но не необходимо. Это тема для отдельного поста впрочем.

Скину вам сегодня баян-смехуёчек про микросервисы. Лично меня в этом всём забавляют даже не долбоёбские названия или упоротая архитектура, а то, насколько сильно у девелопера подгорает, и то, насколько уравновешенный и приветливый при этом остаётся менеджер. Прям классический расклад: вижу подобное каждый день на работе.

Прочитал я когда-то книгу «Хороший интерфейс — невидимый интерфейс» Голдена Кришны. Перевод на русский местами мне не понравился, так что вот сайт оригинала, а если уж совсем хочется, вот русскоязычное издание. Подробный обзор я написать уже не смогу, но чисто в рамках краткой рекомендации в двух словах опишу.

Вся книга — это какая-то квинтэссенция нытья. Автор весьма эмоционально и заёбно ноет, ноет, ноет и ноет по поводу того, какие говнячие сейчас интерфейсы, как его заебали тачскрины, необходимость доставать из кармана телефон, пялиться в экран и т.д. И знаете что? Он прав! Меня тоже это заебало.

Вместо впихивания экрана и создания приложения для любого говна он рекомендует фокусироваться на типичных процессах, изучать привычки, воплощать их в аппаратном/программном виде и автоматизировать. Примеров тоже хватает: начиная от налобного фонарика, автоматически регулирующего свою яркость, багажника авто, открывающегося при проведении ногой под бампером, подушек безопасности, и заканчивая автоматическими дверьми в супермаркетах, термостатом Nest или, например, самоохлаждающейся Mazda 929 аж 1991-го года выпуска (привет, Тесла).

Автор, кстати, в Гугле работает. Отсюда у меня вопрос: когдааааа же, блядь, у вас в Гугле кто-то эту книгу наконец прочитает?

Ну и пример чисто от меня. Делал я тут себе «умный дом» на основе Home Assistant. Первым делом, конечно, законнектил в него всё, что смог, начиная от датчиков температуры и заканчивая твитчом и стимом. Законнектил и сел думать, а чё теперь с этим делать.

Понапридумывал юзкейсов всяких, заимплементил. Например, есть у меня кубик Xiaomi, так я на него кучу действий навесил, в зависимости от того, в какую сторону его вертеть.

Настроил дашборд, чтоб всю инфу выводить. Даже Grafana насетапил.

Стоит ли о говорить, что спустя год реально рабочими штуками оказались те, которые требуют примерно ноль внимания и вмешательства (ну или близко к тому). Автоматически включающийся и выключающийся свет, например. Ну или выключение всего в квартире нажатием на одну кнопку, когда спать ложишься.

Всё остальное — нахер не нужно. Я web-ui Home Assistant месяцами не вижу.

Короче, это тот самый случай, когда меньше — это больше.

Сдыбал тут ещё одно никому не нужное известное посягательство на лавры Excel — CubeWeaver. Особенно упорото на сайте смотрится видос, озвученный с помощью синтеза голоса 😅 Зато по видео сразу ясно, насколько не интуитивный там интерфейс.

Но я, конечно, люблю подобные штуки в первую очередь за идеи. Всегда интересно, как кто-то пытается выйти за рамки привычного. Статья прилагается.

Заметил, что нынче при описании каждого нового сервиса, инструмента и т.п. приписка «written in Rust» встречается уж крайне часто. Причём, я так понимаю, это должно добавлять сразу +100 к доверию.

Не, я понимаю, что «стильно, модно, молодёжно», но почему мне как пользователю не должно быть похеру на чём там оно написано?

Ах, да, мемори сейфти же? Типа по умолчанию более безопасно. Так давайте вспомним, как автора экстремально популярного actix-web затравили за то, что он в блоке unsafe чё-то написал. Не по канону типа. Язык — лишь инструмент и сам по себе гарантий никаких не даёт.

Вы видели, чтоб где-то гордо указывали, мол, написано на C++ или Delphi, или Java, или VB? Вот и я не припоминаю. Зато знаете, что ещё раньше гордо писали? Что смогли заимплементить что-то на JS. Забавно поначалу было, да, только теперь чат на компе полтора гигабайта ОЗУ хавает. Уже не так забавно.

А вот, кстати, и тот самый упомянутый мной ранее Hummer — теперь полностью электрический. Выйдет по ходу аж в начале 2023-го, так что заценить HMI на анриале в ближайшее время, вероятно, не получится.

Все, кто хоть раз использовал электронное устройство, знают такое словосочетание как «сообщение об ошибке» (error message). Даже мой МК-61 умел выводить слово ЕГГОГ семисегментными индикаторами.

Изначально это был просто способ диагностики, показывающий что «что-то пошло не так». Но чем дальше развивается индустрия, тем чаще сообщения об ошибке звучат так, будто накосячил именно человек. Мы создаём машины, которые заставляют нас играть по их правилам.

«Введён неверный адрес», «пароль не подходит по критериям», «задайте дату в формате MM/DD/YY», «файл с таким именем уже существует⚠️», «ты пропустил ; в коде, и я, компилятор, знаю это, но дальше работать отказываюсь» и т.д. Встречаю подобное ежедневно.

И намедни прочитал тут статью, где чел пишет про т.н. предписывающие (prescriptive) и описывающие (descriptive) инструменты.

Последние — те, что описывают происходящее (в логах, нотификейшнах, окнах статуса, месседж-боксах и т.д.). Большинство тулов именно такие, мы все к этому привыкли, но как же бесит сначала диагностировать проблему, нередко прибегая к помощи гугла и SO, а потом ещё и думать, как именно её резолвить. Больше бесит только ситуация, когда инструмент наверняка знает, в чём проблема, знает, как её решить, но всё равно заставляет выполнять какие-то специальные действия.

«Ах, ты пытаешься закоммитить что-то в репу с чистым git-конфигом? На, сука! Напиши вот эти две команды в терминал, чтобы сообщить своё имя и имейл. Я мог бы и сам сразу спросить, но я всего лишь инструмент, а ты человек, делающий работу».

Предписывающие инструменты же помогают пользователю решить проблему, предлагая конкретное действие или выбор из оных, а то даже и ничего не предлагая, а сразу выполняя, если дефолты хорошо продуманы. Вроде не так и сложно подобное заимплементить, но однозначно требует отдельных усилий. «Некогда этим заниматься — фичи надо пилить!»

Основная цель предписывающих инструментов, конечно, это решать проблемы пользователя, а не быть их частью. Доживу ли я до времён, когда таких инструментов будет большинство?