У нас с женой кстати вот по такой кружке(?) Stanley за двадцатку. Пользуемся почти каждый день дома, берём в поездки. Збс.

Типочки запилили нехуйскую систему для отделения людей от фона на видеостримах в реалтайме (4K@30fps, 1080p@60fps). И она явно получше тех, что используются в современном софте для видеоконференции, и якобы даже лучше хромакея. Чтобы это работало, нужно сначала снять чисто фон, что, в принципе не такая уж большая плата. А, ну и топовая видяха нужна 🤑

Вот видос, вот сорцы (Python).

Написал, почему я перешёл с GMail на HEY.com. Последний появился всего около года назад, но я уже настолько привык, что позабыл о GMail, Outlook и т.д. Если кратко, то всё потому, что HEY помогает вырабатывать дисциплину, а не просто «предоставляет средства».

Кто-то решил, что блютуса в чашке недостаточно и решил добавить тач-управление в бидон с ручкой кружку, чтобы подстраивать температуру по своему вкусу. Ещё грят, мол, оно изучает привычки пользователя бла-бла-бла. Ожидаемая розничная цена — двести баксов всего 🙂

Совершенно не ясно, как этим пользоваться и что оно там изучает. При установке температуры тачем кружка чё-то там показывает светодиодами. Что именно‽ Во-первых, их не видно, когда они не светятся, во-вторых, никакой шкалы или пометок не нарисовано. Мне их считать или что?

По поводу изучения привычек я тоже хз. Я сам не ебу, какой там температуры я обычно что пью: 135°F или 142°F (сколько это в нормальных единицах-то?) — даже не уверен, играет ли разница в несколько градусов роль.

Если бы я делал «умную» кружку, я бы сделал на ней одну кнопку: «вот сча заебись». Просто жмёшь её, кружка запоминает текущую температуру и старается всегда её поддерживать.

Если прям хочется LEDов туда натолкать, то можно фигачнуть три красно-синих, чтоб показывать, насколько горячее/холоднее напиток в сравнении с моим дефолтом. Всё.

Кидайте деньги кароч, сделаю проект на кикстартере! 😂

Наткнулся тут на либу для игр — raylib на сишечке. Наверняка не впервые, но как-то я раньше не обращал внимания на количество байндингов к другим языкам, которых весьма дофига.

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

Если вдруг вы посмотрели на Catch2 и вам не хватает возможности мокать объекты, то я как раз только что наткнулся на другую библиотеку спецом для этого: называется Trompeloeil. Как на французском произносится trompe l'œil я хз, но в [слобожанском] русском есть малоизвестное слово «тремпель» — буду использовать его 🙂
Легко интегрируется не только с Catch2 кстати.

Есть ощущение, что то, во что выродились современные CLI, сильно отличается от задумки наших праотцов. Как часто вы реально пишете ванлайнеры с кучей свитчей, передавая результаты через пайп (особенно не в grep)? И как часто вы делаете это правильно с первого раза?

То, что когда-то задумывалось как способ общения с компьютером, теперь превратилось в способ для компьютера послать тебя нахер. Даже вот сервисы по типу https://explainshell.com/ не сильно помогают: половину из тех ванлайнеров, что я в нём проверил, он не смог нормально мне «объяснить».

Вместо того чтобы научить машины общаться с нами на более понятном нам языке, мы теперь учимся общаться на более понятном им. У меня есть теория на этот счёт.

Когда я только начинал программировать, я писал свои детские наивные программы так, будто бы компьютер со мной реально разговаривает. Он в интерактивном режиме задавал вопросы и, если ему по какой-то причине не подходил мой ответ, любезно говорил почему. Любезно — потому что я для себя же писал.

Позже мне кто-то сказал/показал, что это не труЪ. Сначала я увидел DOS. Позже: «Гляди, вон, в линуксе всё как сделано» — кто-то сказал мне. Десятки каких-то утилит, у каждой десятки свитчей с сотнями возможных параметров. Я тоже начал писать так, потому что же это «профессионально».

Сейчас маятник вроде качнулся в обратную сторону. Одни люди пытаются делать тулзы более дружелюбными, а другие им твердят, мол, говно, потому что: «А вдруг я буду деплоить это со своего утюга с аккордной клавиатурой на триста удалённых серверов в Микронезии через gopher — тогда что‽»

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

При этом на компромиссы люди идут неохотно. Они считают, что новые решения должны быть если не идеальными, то хотя бы такими же, как старые, только значительно лучше. То есть вариант -2,+3 их не устраивает, даже если в общем зачёте решено больше проблем, чем раньше.

Можно подумать, что этот пост — наброс на линукс, терминалы или что-то ещё. Но на самом деле он про интерфейсы и UX 😉

Важная для меня тема.
За всё время, что я программирую, я «изучил» весьма внушительное количество разнообразных языков. На некоторых я по итогу не написал ничего больше 100 строк кода, но ещё ни разу не пожалел о потраченном времени. Почему?

Для меня изучение языка программирования покрывает два основных топика: 1) поглядеть «а как ещё бывает» и 2) изучение новых концептуальных штук, расширяющих сознание. Первое чаще про синтаксис, и от него пользы мало, если не пишешь свой идеальный язык программирования, которым никто не будет пользоваться. Разве что похоливарить можно.

А вот на втором остановимся подробнее. Я люблю приводить пример, что я стал лучше понимать шаблоны в С++ после изучения Haskell, ведь оказалось, что шаблоны — это всего лишь функции над типами 🙂 Ну и STL стал лучше понимать, ведь он не сказать что очень уж в ООП-стиле. Хаскелем всё не ограничилось, конечно. У меня таких примеров — вагон и маленькая тележка.

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

По-настоящему же я понял, зачем я трачу время на языки с тремя с половиной пользователями после прочтения книги «Seven Languages in Seven Weeks». Например, благодаря изучению Ruby я увидел, как можно делать красивые, как мне тогда казалось, eDSL, и разобрался в метапрограммировании (которое сейчас в основном костыляю в Python). Благодаря io я отошёл от С++-версии ООП и приблизился к оригинальной с месседж-пассингом. Это впоследствии помогло с Objective-C, кстати. Ещё я увидел, что синтаксис может быть суперпростой, но при этом мощный. Благодаря ему же я раздуплился в прототипном наследовании в JavaScript. Лисп мне как-то не зашёл тогда, но не так давно я открыл для себя Red (наследник REBOL) и понял фишечку гомоиконичности. Erlang дал понимание модели акторов. Ну и т.д.

Важный момент: «а зачем учить столько языков, если всё это можно сделать в C++?» — спросите вы. Метапрограммирование/монады/акторы/eDSL/you name it… Я считаю, что это не эффективно. Вместо того чтобы бороться со сложностью и неприспособленностью языка и распылять своё внимание на нерелевантные вещи, я предпочитаю знакомиться с новыми концепциями в их нативной рафинированной среде. Языки приходят и уходят, а ваше понимание концептуальных вещей остаётся. И каждое такое знание значительно расширяет диапазон возможных решений той или иной задачи.

Короче, основная метрика, по которой я нынче оцениваю язык программирования — это не размер комьюнити, не количество либ или ответов на Stack Overflow и даже не производительность. Основная метрика — количество инсайтов, которые я получил, изучая его.

Вот бы теперь ещё с менеджментом так же 🙂

Глядите, кстати, чё Страуструп говорит на тему https://youtu.be/NvWTnIoQZj4

Есть стойкое ощущение, что некоторые коллеги на работе регулярно пользуются этим сервисом на митингах 🙄 https://zoomescaper.com/

Небольшой вводный пост по теме, на которую мне есть и ещё будет, что сказать.

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

Будучи программистом, я и сам любил позубоскалить на тему того, как менеджеры заебали, ничего полезного не делая. Однако ряд коллег по цеху искренне верит, мол, настоящее value компании приносят именно инженеры, тогда как управленцы скорее мешают. Некоторые манагеры в натуре хер на работу клали, но так-то и девелоперы не все поголовно дохуя перформеры 😉

Большинство программистов не могут друг с другом договориться, как класс назвать, не то что каким-либо образом самоорганизоваться и принести тот самый мифический велью. К счастью, не все такие. Есть и те, кто умеет коммуницировать с людьми и знает, куда приложить свою инициативность и как организовать работу. Такие инженеры часто, сюрприз-сюрприз, становятся менеджерами! И по итогу только коллаборация обоих лагерей повышает шанс лодки добраться до берега. Обе роли важны.

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

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

(Сча бы в комменты насрать что-то типа «все вы, менеджеры, так говорите», да? 🙂)

Из всех языков программирования, что я пытался учить, хуже всего мне поддаётся Prolog.

Это очень интересный язык логического программирования, оказавший немалое влияние на индустрию в своё время (вплоть до того, что синтаксис Erlang очень похож на синтаксис Prolog, так как первый интерпретатор был написан на нём).

Основных проблем в его изучении две: 1) я никогда не уделял ему достаточно времени, потому что редко мог придумать практическое применение; 2) источников информации не так-то и много. Я предпочитаю учить по книгам, и с ними как-то вообще тухло. А все статьи по прологу начинаются и заканчиваются определением того, чей там кому батя Сократ.

Осознанных подходов к его использованию у меня было три, и все они связаны с попытками решить головоломки в компьютерных играх, над которыми мне было западло думать самостоятельно. Первая была давным давно в какой-то из частей «Нэнси Дрю» и чем-то напоминала судоку. Вторая была в прошлом году в «We Were Here Together» — там мне просто не хватило мозгов описать концептуальную модель задачи синтаксисом языка. Третья была буквально на днях в «Dishonored 2» и являлась вариацией т.н. «задачи Эйнштейна». Я потратил полтора часа, чтобы вспомнить синтаксис, все эти темы с унификацией и т.п., описать факты и предикаты для задачи и получить на выходе false вместо списка, кто там где живёт и чем бухает 😂 Не хватило знаний/опыта, чтобы правильно увязать эти предикаты воедино. Стоит ли говорить, что во всех трёх случаях жена находила правильный ответ на листочке бумаги гораздо быстрее и безо всякого программирования.

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

Если вы шарите Prolog и можете подсказать, с чего и как лучше начинать, напишите мне плз.

Наткнулся на yet another ФП язык, компилящийся в JavaScript — Clio. Сам по себе он не примечательный, и если сегодня о нём узнают, то завтра забудут. Интересно тут другое.

Можно сколько угодно стебать хипстеров-миллениалов, которые ежедневно переизобретают давно существующие вещи и суют свой JS везде, но есть у них одно преимущество: в отличие от «дедов» они умеют сделать красиво и зачастую удобно. То и дело цепляю какие-то микроидеи.

Посмотрите на скрин: у бинаря, которым представлен язык, есть отдельная команда highlight, которая выводит код в терминал с подсветкой синтаксиса! How cool is that‽ Вроде такая мелочь, а приятно 🙂

Как там у вас, сишники, код без ньюлайна в конце файла уже компилится?)

Зацените. BMW продемонстрировала свою новую инфотейнмент-систему iDrive 8. Из промо-ролика наверняка понятно только одно: по ходу Microsoft поделилась с ними контактами студии 3D-шников и моушн-дизайнеров 🙂

Вот ещё из презентации (красным дописал начало фразы).

so informational much density wow

Окунаясь в управленческие темы, я обнаружил забавный и вроде как очевидный эффект, который ранее мне таковым не представлялся:

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

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

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

Моих знаний мало, опыта у меня мало — и всё же это в разы лучше, чем было! Если вы инженер, но ещё не начали интересоваться подобными вопросами, то самое время озаботиться и потенциально получить нехеровый буст в карьере (даже без смены роли).

Слава Microsoft Excel никому не даёт покоя вот уже 35 лет, так что постоянно ведутся попытки сделать что-то похожее, но лучше или хотя бы по-другому. Всяких разных табличных процессоров я видел немало, но вот лучше — всё ещё ни одного.

Держите тем не менее очередной вариант на Haskell. Надеюсь, там можно делать полиморфизм на уровне таблиц, иначе комьюнити не оценит 😁 Вот сайт: https://inflex.io/

Я продолжаю сравнивать программерские дисциплины с управленческими. В программировании на первый взгляд чуть больше порядка: всё как-то чётче и структурированнее. Только на первый взгляд, конечно, потому что иначе у нас бы не было регулярных срачиков на тему ООП vs ФП, (не)использования паттернов проектирования и прочей требухи — всё в конце концов упирается в работу с людьми, а там у каждого своё мнение. Менеджмент же по определению — это работа с людьми, поэтому никакой формализации никто особо и не ждёт.

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

Одной из таких моделей является 8-шаговая модель Коттера по ускорению изменений. Вот официальный сайт: https://www.kotterinc.com/

Я узнал о ней в районе 2018–2019 годов на тренинге и с тех пор время от времени вспоминаю и рефрешу знания. Многие люди, когда пытаются что-то изменить (в процессах на проекте, в архитектуре в коде, где-либо ещё), начинают с формирования и попытки донести свой вижн другим. Да, в каких-то случаях это работает, но модель Коттера расценивает это как аж третий шаг! И надо сказать, с прохождением первых двух у меня стало получаться и впрямь лучше.

В общем, ознакомьтесь. Пригодится, ей-богу.

Держите PDF-ку заодно

На прошлой неделе по твиттеру пролетел скрин с башорга (да, башорга! господи, он ещё живой…). Люди ломали голову, как же так, зачем и почему в РЖД такой API, пока не появилось объяснение на хабре.

Прежде чем в следующий раз ныть, какая ужасная у вас кодбаза, которой два года, и как срочно нужно всё переписать с нуля, прочитайте этот занимательный экскурс в историю и оцените глубину легаси 🙂