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

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

В жизни я достаточно много матерюсь на русском, чуть меньше на английском, поэтому продолжу делать это и тут. Можно бесконечно долго спорить о том, хорошо материться или плохо: думаю, я сам смог бы поддержать спор за любую из сторон. Некоторые матерятся нарочито креативно, с большим количеством неологизмов, другие же вообще считают, что это признак плохого воспитания/образования/whatever и используют их… никогда. Для меня же всё просто: я люблю лаконичность. Нет других настолько же ёмких слов, как маты. Если переводить на программерский: это сродни использованию for-statement вместо соответствующей ассемблерной вставки.

К сожалению, многие люди всё ещё по привычке воспринимают маты как нечто вульгарное, агрессивное, принимают на свой счёт, как личную обиду и всё в таком духе. (Если вы из таких, то задумайтесь об этимологии в следующий раз, когда будете употреблять «хз».). Это отчасти имеет смысл, потому что у матов не только высокая ёмкость, но и широкий диапазон экспрессии, поэтому важно следить за интонацией. В текстовом виде, конечно, всего этого не передашь, увы, поэтому полагайтесь на свой личный усреднённый вариант.

Без матов в гипотетической ситуации обсуждения какого-то технического решения можно бесконечно долго плутать в витиеватых фразах типа «Отлично! И в то же время… что если мы сделаем немного иначе?», «Мне кажется, можно было бы применить альтернативный подход», «Данное решение покрывает большинство кейсов, я согласен, однако, я переживаю о тех, которые не были учтены» и т.д. С матами же можно просто сказать: «Это хуйсосня. Вот здесь наебнётся». Гораздо короче. Профит!

Ну и чтоб два раза не вставать 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?