Ну и чтоб два раза не вставать https://teletype.in/@sol-talks/no-rules-rules

Немного о когнитивном.

Делал я тут, значит, недавно в Jupyter фейковые диаграммы для презентации 🙂 Если кто не знает, Jupyter — это интерактивный блокнот с текстом и кусками кода, которые можно выполнять прям там же и получать rich output. Такой себе literate programming в каком-то плане.

Блокнот там состоит из ячеек. Их можно добавлять выше и ниже текущей: соответственно хоткеи — a (above) и b (below). Пользуюсь я им редко, мышечной памяти ещё нет. Но с такой простой мнемоникой она вроде как и не нужна.

С некоторых пор я, впрочем, перестал использовать «нативный» юпитеровский UI, а переехал в VS Code и заметил, что там эти хоткеи по какой-то причине работают наоборот. Я уже и погуглил проблему, и посмотрел маппинг кнопок у себя на всяк — ничего. Ну и забил хер.

Позже я решил перечитать мануал по Юпитеру и перепроверить хоткеи. Всё так — a и b. Попробовал в VS Code — работает! 🤔 В конце концов я словил себя на мысли, что иногда мысленно «произношу» a/b как above/below, а иногда как after/before 🙂 Я даже сейчас не уверен, как там на самом деле надо. Вангую, что я не один такой.

Что мешало сделать какие-то Ctrl+↑/Ctrl+↓? Я хер знаю. Об ущербности режимов, таких как ввод/управление, например (привет вимерам), ещё Раскин писал в своём «Интерфейсе» — тут мне добавить нечего. В Wolfram вроде вообще без этого разделения обошлись, если мне память не изменяет.

Да, может это и мелочь, но фрустрацию вызывает. Не надо так со своими пользователями.

Сча модно ныть, поною и я. Прочитал статью, где чел пишет почему он переключился с нудного и сложного Rust на более легковесный (но не суперизвестный) Zig. И это очень похоже на мои ощущения. Я помню, с чего Rust начинался: это был красивый лаконичный (в сравнении с С++) язык: «вот тут», — говорили они, — «мы убрали лишние скобочки, а тут убрали return, чтоб можно было писать проще и короче. А ещё мы сделали traits». Посмотрите, в какой пиздец превратился код на расте сейчас. Это ж невозможно читать. Какая-то ебанутая мешанина из символов, угловые скобки повсюду, лайфтаймами всё засрано к псам.

Позволяет ли Rust описывать какие-то уникальные концепции, отсутствующие в других языках? М-м-м-м… Я бы не сказал. По сути он превратился в ещё один С++ с единственной фичей — memory safety. Но последнее — это фича компилятора, а не языка. Можно ли было сделать синтаксис проще? Я уверен, что да.

Все пророчили, как Rust однажды победит С++. И похоже, что всё к тому идёт, вот только битва эта — за самый сложный для изучения язык, используемый в продакшне.

Тред про парное программирование https://twitter.com/N_Lopin/status/1367735338811146243 Чел в принципе дело говорит. Если правильно организовать, то это профитная тема. Жаль, что правильно организовать достаточно сложно.

Про парное программирование он написал, а про тесты нет, поэтому напишу я. Про юнит-тесты, если точнее. Длиннопост.

Я прошёл все те же стадии (не)принятия юнит-тестирования, что и все: «а нах они?», «не отстреливаю, как их писать», «чё-то скучно», «та позже напишем» и т.д. Проблема в том, что дохуильон программистов застряли где-то посредине. У тех, кто пишет на динамических языках, ситуация чуть получше, потому что без тестов вероятность поставить что-то хоть сколь-нибудь качественное быстро множится на процент покрытия. Мои знакомые плюсовики же зачастую воспринимают написание тестов как тяжкое бремя.

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

Вины девелопера в том нет. Он просто не видел, как надо, и никто никогда ему не объяснял, а метрики по line-coverage в этом явно не помогают. Я и сам долгое время морщился при упоминании юнит-тестов. На своих работах за более чем 10 лет я вроде не написал ни одного теста 😎 То не было ясно, как и зачем, то «не было нужно», то никто не просил, то проект закрыли…

Озарение, как это часто бывает, пришло, откуда не ждали. Писал я как-то на Nim и чё-то так притомился перезапускать прогу и проверять одно и то же руками в логах, что решил написать тест. И написал. Урвал дозу дофамина прям!

Программисты при написании кода так или иначе держат в голове какие-то реквайрменты, инварианты, пред- и постусловия, ожидаемые промежуточные значения переменных, которые они либо вручную протыкивают в дебаггере, либо дампят в лог, который потом так же вручную проверяют на правильность. Заче-е-ем‽ Можно же написать код, который будет делать ровно то же автоматически. Разве писать код — это не то, что мы любим? 🙂

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

Так а чё ж я раньше такой дохуя умный не был? Какую роль тут сыграл Nim? А всё очень просто: если в С++ надо порядочно поебаться, выбрать либу для юнит-тестирования, прикрутить к проекту, насетапить всё, то в Nim это буквально один импорт и можно фигачить тесты прям в том же файле, поближе к контексту то есть. Это важно.

Поэтому моя рекомендация: настроить инфраструктуру для запуска юнит-тестов в самом начале проекта и, может, хернуть один тест для примера. Остальные люди сами подтянутся (после пары пинков — уж точно).

Мой текущий фаворит для С++ — Catch2, кстати.

Оказывается, самостоятельно издать книгу не так уж и сложно.

Помню, решил я написать книгу про QML где-то в 2010–2011 годах и для этого конечно же сначала изучил LaTeX. И забил 🙂 С тех пор ни разу им не воспользовался. Можно сейчас попробовать ещё разок, но с книгой на другую тематику, конечно.

Помимо общей слабости к девайсам я какого-то хера особо падок на камеры, хотя за всю жизнь ничего толкового не снял. И Insta360 выпустила новую. Как обладатель Insta360 One R могу сказать, что эта китайская контора шарит, как и качество заделиверить, и прикольные мелочи туда натолкать.

Вроде только канал создал, а уже пост из серии «придётся брать™» 😅

Я уже писал про Jupyter. Так уж повелось, что он в каком-то плане конкурирует с Excel: оба неплохо подходят для анализа данных, оба — со своими достоинствами и недостатками. Первый больше любят программисты, так как код на знакомом языке всё-таки писать как-то роднее, а второй больше любят… э-э-эм… остальные?

И тут чуваки сделали какой-то недо-Excel для Jupyter (с тотально ублюдочной анимацией сайдбара). Сильно сомневаюсь, что оно полетит. Но ещё в голову пришла другая мысль: было бы клёво, если бы в Excel добавили какой-то аналог блокнотов а ля Wolfram! 🤔 Думаю, Microsoft это даже вполне по силам. Интересно, можно ли наговнячить что-то похожее на VBA?

Кстати, сейчас это уже как-то и подзабылось, но работал я в 2015-м на SanDisk над похожей штукой. Это должна была быть камера в виде кулона, которая бы сама снимала фоточки и короткие ролики с какой-то периодичностью, а потом приложение-компаньон бы «автомагически» выбирало из них самые интересные моменты и склеивало в один клип. Проект быстро прикрыли: видимо, кто-то из менеджеров повыше решил, что оно того не стоит. А какая идея! Опередили время, эх.

Несомненный плюс того, что многие знают о моём интересе к разного рода гаджетам: люди делятся со мной своими находками. Сегодня дружбан подкинул линк на чашку, которая поддерживает установленную температуру напитка… за 130 баксов (или 150€)! Придётся брать!™ (На самом деле, конечно, чашка с блютус моментально идёт нахуй, но вдруг кому надо…).

У нас с женой кстати вот по такой кружке(?) 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 компании приносят именно инженеры, тогда как управленцы скорее мешают. Некоторые манагеры в натуре хер на работу клали, но так-то и девелоперы не все поголовно дохуя перформеры 😉

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

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

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

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