Всем привет.
Я, как говорится, человек простой: работаю в айти, пишу код, управляю людьми. Создал этот канал, чтобы делать записи для себя, делиться чем-то интересным, напаривать своё мнение и т.д. Дисциплины на этот счёт у меня нет нихуа, поэтому на регулярность я бы тут не рассчитывал.
Я, как говорится, человек простой: работаю в айти, пишу код, управляю людьми. Создал этот канал, чтобы делать записи для себя, делиться чем-то интересным, напаривать своё мнение и т.д. Дисциплины на этот счёт у меня нет нихуа, поэтому на регулярность я бы тут не рассчитывал.
И первый пост будет на тему матов — вместо дисклеймера на случай, если когда-нибудь на этот канал подпишется кто-то из тех людей, с которыми я не знаком лично. Ведь всё равно рано или поздно доебутся!
В жизни я достаточно много матерюсь на русском, чуть меньше на английском, поэтому продолжу делать это и тут. Можно бесконечно долго спорить о том, хорошо материться или плохо: думаю, я сам смог бы поддержать спор за любую из сторон. Некоторые матерятся нарочито креативно, с большим количеством неологизмов, другие же вообще считают, что это признак плохого воспитания/образования/whatever и используют их… никогда. Для меня же всё просто: я люблю лаконичность. Нет других настолько же ёмких слов, как маты. Если переводить на программерский: это сродни использованию
К сожалению, многие люди всё ещё по привычке воспринимают маты как нечто вульгарное, агрессивное, принимают на свой счёт, как личную обиду и всё в таком духе. (Если вы из таких, то задумайтесь об этимологии в следующий раз, когда будете употреблять «хз».). Это отчасти имеет смысл, потому что у матов не только высокая ёмкость, но и широкий диапазон экспрессии, поэтому важно следить за интонацией. В текстовом виде, конечно, всего этого не передашь, увы, поэтому полагайтесь на свой личный усреднённый вариант.
Без матов в гипотетической ситуации обсуждения какого-то технического решения можно бесконечно долго плутать в витиеватых фразах типа «Отлично! И в то же время… что если мы сделаем немного иначе?», «Мне кажется, можно было бы применить альтернативный подход», «Данное решение покрывает большинство кейсов, я согласен, однако, я переживаю о тех, которые не были учтены» и т.д. С матами же можно просто сказать: «Это хуйсосня. Вот здесь наебнётся». Гораздо короче. Профит!
В жизни я достаточно много матерюсь на русском, чуть меньше на английском, поэтому продолжу делать это и тут. Можно бесконечно долго спорить о том, хорошо материться или плохо: думаю, я сам смог бы поддержать спор за любую из сторон. Некоторые матерятся нарочито креативно, с большим количеством неологизмов, другие же вообще считают, что это признак плохого воспитания/образования/whatever и используют их… никогда. Для меня же всё просто: я люблю лаконичность. Нет других настолько же ёмких слов, как маты. Если переводить на программерский: это сродни использованию
for-statement вместо соответствующей ассемблерной вставки. К сожалению, многие люди всё ещё по привычке воспринимают маты как нечто вульгарное, агрессивное, принимают на свой счёт, как личную обиду и всё в таком духе. (Если вы из таких, то задумайтесь об этимологии в следующий раз, когда будете употреблять «хз».). Это отчасти имеет смысл, потому что у матов не только высокая ёмкость, но и широкий диапазон экспрессии, поэтому важно следить за интонацией. В текстовом виде, конечно, всего этого не передашь, увы, поэтому полагайтесь на свой личный усреднённый вариант.
Без матов в гипотетической ситуации обсуждения какого-то технического решения можно бесконечно долго плутать в витиеватых фразах типа «Отлично! И в то же время… что если мы сделаем немного иначе?», «Мне кажется, можно было бы применить альтернативный подход», «Данное решение покрывает большинство кейсов, я согласен, однако, я переживаю о тех, которые не были учтены» и т.д. С матами же можно просто сказать: «Это хуйсосня. Вот здесь наебнётся». Гораздо короче. Профит!
Немного о когнитивном.
Делал я тут, значит, недавно в Jupyter фейковые диаграммы для презентации 🙂 Если кто не знает, Jupyter — это интерактивный блокнот с текстом и кусками кода, которые можно выполнять прям там же и получать rich output. Такой себе literate programming в каком-то плане.
Блокнот там состоит из ячеек. Их можно добавлять выше и ниже текущей: соответственно хоткеи —
С некоторых пор я, впрочем, перестал использовать «нативный» юпитеровский UI, а переехал в VS Code и заметил, что там эти хоткеи по какой-то причине работают наоборот. Я уже и погуглил проблему, и посмотрел маппинг кнопок у себя на всяк — ничего. Ну и забил хер.
Позже я решил перечитать мануал по Юпитеру и перепроверить хоткеи. Всё так —
Что мешало сделать какие-то
Да, может это и мелочь, но фрустрацию вызывает. Не надо так со своими пользователями.
Делал я тут, значит, недавно в 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 однажды победит С++. И похоже, что всё к тому идёт, вот только битва эта — за самый сложный для изучения язык, используемый в продакшне.
Позволяет ли Rust описывать какие-то уникальные концепции, отсутствующие в других языках? М-м-м-м… Я бы не сказал. По сути он превратился в ещё один С++ с единственной фичей — memory safety. Но последнее — это фича компилятора, а не языка. Можно ли было сделать синтаксис проще? Я уверен, что да.
Все пророчили, как Rust однажды победит С++. И похоже, что всё к тому идёт, вот только битва эта — за самый сложный для изучения язык, используемый в продакшне.
Тред про парное программирование https://twitter.com/N_Lopin/status/1367735338811146243 Чел в принципе дело говорит. Если правильно организовать, то это профитная тема. Жаль, что правильно организовать достаточно сложно.
Twitter
Ник Лопин
Так вот, про парное программирование. В индустрии еще не все понимают, зачем нужно писать тесты. Парное программирование в такой картине мира выглядит как сжигание ресурсов. Давайте разбираться, зачем это нужно и как делать
SOL Talks
Тред про парное программирование https://twitter.com/N_Lopin/status/1367735338811146243 Чел в принципе дело говорит. Если правильно организовать, то это профитная тема. Жаль, что правильно организовать достаточно сложно.
Про парное программирование он написал, а про тесты нет, поэтому напишу я. Про юнит-тесты, если точнее. Длиннопост.
Я прошёл все те же стадии (не)принятия юнит-тестирования, что и все: «а нах они?», «не отстреливаю, как их писать», «чё-то скучно», «та позже напишем» и т.д. Проблема в том, что дохуильон программистов застряли где-то посредине. У тех, кто пишет на динамических языках, ситуация чуть получше, потому что без тестов вероятность поставить что-то хоть сколь-нибудь качественное быстро множится на процент покрытия. Мои знакомые плюсовики же зачастую воспринимают написание тестов как тяжкое бремя.
Попросил я тут недавно одного своего девелопера напилить фичу и сразу покрыть код тестами. Он отлынивать не стал, к задаче подошёл ответственно и нахуячил тест-кейсы по паре сотен строк, проверяя в каждом целую пачку функций. Не удивительно, что это для многих тяжко и скучно — я б тоже хер положил с таким раскладом! Где-то на чтении середины первого кейса я потерялся и уже не смог отслеживать, что там происходит.
Вины девелопера в том нет. Он просто не видел, как надо, и никто никогда ему не объяснял, а метрики по line-coverage в этом явно не помогают. Я и сам долгое время морщился при упоминании юнит-тестов. На своих работах за более чем 10 лет я вроде не написал ни одного теста 😎 То не было ясно, как и зачем, то «не было нужно», то никто не просил, то проект закрыли…
Озарение, как это часто бывает, пришло, откуда не ждали. Писал я как-то на Nim и чё-то так притомился перезапускать прогу и проверять одно и то же руками в логах, что решил написать тест. И написал. Урвал дозу дофамина прям!
Программисты при написании кода так или иначе держат в голове какие-то реквайрменты, инварианты, пред- и постусловия, ожидаемые промежуточные значения переменных, которые они либо вручную протыкивают в дебаггере, либо дампят в лог, который потом так же вручную проверяют на правильность. Заче-е-ем‽ Можно же написать код, который будет делать ровно то же автоматически. Разве писать код — это не то, что мы любим? 🙂
Главное тут, как и с любым другим кодом, придерживаться некоторых простейших правил, чтобы потом не было мучительно больно этот код поддерживать: декомпозировать побольше, стейт хранить поменьше и всё в таком духе. Я типочку, о котором выше писал, показал на парочке простейших примеров, как надо — и это сразу поменяло его восприятие. Он быстро уловил фишку и теперь пишет збс.
Так а чё ж я раньше такой дохуя умный не был? Какую роль тут сыграл Nim? А всё очень просто: если в С++ надо порядочно поебаться, выбрать либу для юнит-тестирования, прикрутить к проекту, насетапить всё, то в Nim это буквально один импорт и можно фигачить тесты прям в том же файле, поближе к контексту то есть. Это важно.
Поэтому моя рекомендация: настроить инфраструктуру для запуска юнит-тестов в самом начале проекта и, может, хернуть один тест для примера. Остальные люди сами подтянутся (после пары пинков — уж точно).
Мой текущий фаворит для С++ — Catch2, кстати.
Я прошёл все те же стадии (не)принятия юнит-тестирования, что и все: «а нах они?», «не отстреливаю, как их писать», «чё-то скучно», «та позже напишем» и т.д. Проблема в том, что дохуильон программистов застряли где-то посредине. У тех, кто пишет на динамических языках, ситуация чуть получше, потому что без тестов вероятность поставить что-то хоть сколь-нибудь качественное быстро множится на процент покрытия. Мои знакомые плюсовики же зачастую воспринимают написание тестов как тяжкое бремя.
Попросил я тут недавно одного своего девелопера напилить фичу и сразу покрыть код тестами. Он отлынивать не стал, к задаче подошёл ответственно и нахуячил тест-кейсы по паре сотен строк, проверяя в каждом целую пачку функций. Не удивительно, что это для многих тяжко и скучно — я б тоже хер положил с таким раскладом! Где-то на чтении середины первого кейса я потерялся и уже не смог отслеживать, что там происходит.
Вины девелопера в том нет. Он просто не видел, как надо, и никто никогда ему не объяснял, а метрики по line-coverage в этом явно не помогают. Я и сам долгое время морщился при упоминании юнит-тестов. На своих работах за более чем 10 лет я вроде не написал ни одного теста 😎 То не было ясно, как и зачем, то «не было нужно», то никто не просил, то проект закрыли…
Озарение, как это часто бывает, пришло, откуда не ждали. Писал я как-то на Nim и чё-то так притомился перезапускать прогу и проверять одно и то же руками в логах, что решил написать тест. И написал. Урвал дозу дофамина прям!
Программисты при написании кода так или иначе держат в голове какие-то реквайрменты, инварианты, пред- и постусловия, ожидаемые промежуточные значения переменных, которые они либо вручную протыкивают в дебаггере, либо дампят в лог, который потом так же вручную проверяют на правильность. Заче-е-ем‽ Можно же написать код, который будет делать ровно то же автоматически. Разве писать код — это не то, что мы любим? 🙂
Главное тут, как и с любым другим кодом, придерживаться некоторых простейших правил, чтобы потом не было мучительно больно этот код поддерживать: декомпозировать побольше, стейт хранить поменьше и всё в таком духе. Я типочку, о котором выше писал, показал на парочке простейших примеров, как надо — и это сразу поменяло его восприятие. Он быстро уловил фишку и теперь пишет збс.
Так а чё ж я раньше такой дохуя умный не был? Какую роль тут сыграл Nim? А всё очень просто: если в С++ надо порядочно поебаться, выбрать либу для юнит-тестирования, прикрутить к проекту, насетапить всё, то в Nim это буквально один импорт и можно фигачить тесты прям в том же файле, поближе к контексту то есть. Это важно.
Поэтому моя рекомендация: настроить инфраструктуру для запуска юнит-тестов в самом начале проекта и, может, хернуть один тест для примера. Остальные люди сами подтянутся (после пары пинков — уж точно).
Мой текущий фаворит для С++ — Catch2, кстати.
GitHub
GitHub - catchorg/Catch2: A modern, C++-native, test framework for unit-tests, TDD and BDD - using C++14, C++17 and later (C++11…
A modern, C++-native, test framework for unit-tests, TDD and BDD - using C++14, C++17 and later (C++11 support is in v2.x branch, and C++03 on the Catch1.x branch) - catchorg/Catch2
Оказывается, самостоятельно издать книгу не так уж и сложно.
Помню, решил я написать книгу про QML где-то в 2010–2011 годах и для этого конечно же сначала изучил LaTeX. И забил 🙂 С тех пор ни разу им не воспользовался. Можно сейчас попробовать ещё разок, но с книгой на другую тематику, конечно.
Помню, решил я написать книгу про QML где-то в 2010–2011 годах и для этого конечно же сначала изучил LaTeX. И забил 🙂 С тех пор ни разу им не воспользовался. Можно сейчас попробовать ещё разок, но с книгой на другую тематику, конечно.
Theroadchoseme
How I self-published a professional paperback and eBook using LaTeX and Pandoc | The Road Chose Me
How I self-published a professional paperback and eBook using LaTeX and Pandoc Introduction After years working as a Software Engineer I wanted to
Помимо общей слабости к девайсам я какого-то хера особо падок на камеры, хотя за всю жизнь ничего толкового не снял. И Insta360 выпустила новую. Как обладатель Insta360 One R могу сказать, что эта китайская контора шарит, как и качество заделиверить, и прикольные мелочи туда натолкать.
Вроде только канал создал, а уже пост из серии «придётся брать™» 😅
Вроде только канал создал, а уже пост из серии «придётся брать™» 😅
YouTube
Introducing Insta360 GO 2 - The Tiny, Mighty Action Camera
Meet Insta360 GO 2. Available now at http://bit.ly/Insta360GO2_yt
Insta360 GO 2 – the tiny action camera that packs an almighty punch! Just 27g (that’s less than an ounce) and the size of your thumb, GO 2 captures the action without ever getting in the way…
Insta360 GO 2 – the tiny action camera that packs an almighty punch! Just 27g (that’s less than an ounce) and the size of your thumb, GO 2 captures the action without ever getting in the way…
SOL Talks
Немного о когнитивном. Делал я тут, значит, недавно в Jupyter фейковые диаграммы для презентации 🙂 Если кто не знает, Jupyter — это интерактивный блокнот с текстом и кусками кода, которые можно выполнять прям там же и получать rich output. Такой себе literate…
Я уже писал про Jupyter. Так уж повелось, что он в каком-то плане конкурирует с Excel: оба неплохо подходят для анализа данных, оба — со своими достоинствами и недостатками. Первый больше любят программисты, так как код на знакомом языке всё-таки писать как-то роднее, а второй больше любят… э-э-эм… остальные?
И тут чуваки сделали какой-то недо-Excel для Jupyter (с тотально ублюдочной анимацией сайдбара). Сильно сомневаюсь, что оно полетит. Но ещё в голову пришла другая мысль: было бы клёво, если бы в Excel добавили какой-то аналог блокнотов а ля Wolfram! 🤔 Думаю, Microsoft это даже вполне по силам. Интересно, можно ли наговнячить что-то похожее на VBA?
И тут чуваки сделали какой-то недо-Excel для Jupyter (с тотально ублюдочной анимацией сайдбара). Сильно сомневаюсь, что оно полетит. Но ещё в голову пришла другая мысль: было бы клёво, если бы в Excel добавили какой-то аналог блокнотов а ля Wolfram! 🤔 Думаю, Microsoft это даже вполне по силам. Интересно, можно ли наговнячить что-то похожее на VBA?
SOL Talks
Помимо общей слабости к девайсам я какого-то хера особо падок на камеры, хотя за всю жизнь ничего толкового не снял. И Insta360 выпустила новую. Как обладатель Insta360 One R могу сказать, что эта китайская контора шарит, как и качество заделиверить, и прикольные…
Кстати, сейчас это уже как-то и подзабылось, но работал я в 2015-м на SanDisk над похожей штукой. Это должна была быть камера в виде кулона, которая бы сама снимала фоточки и короткие ролики с какой-то периодичностью, а потом приложение-компаньон бы «автомагически» выбирало из них самые интересные моменты и склеивало в один клип. Проект быстро прикрыли: видимо, кто-то из менеджеров повыше решил, что оно того не стоит. А какая идея! Опередили время, эх.
SOL Talks
Помимо общей слабости к девайсам я какого-то хера особо падок на камеры, хотя за всю жизнь ничего толкового не снял. И Insta360 выпустила новую. Как обладатель Insta360 One R могу сказать, что эта китайская контора шарит, как и качество заделиверить, и прикольные…
Несомненный плюс того, что многие знают о моём интересе к разного рода гаджетам: люди делятся со мной своими находками. Сегодня дружбан подкинул линк на чашку, которая поддерживает установленную температуру напитка… за 130 баксов (или 150€)! Придётся брать!™ (На самом деле, конечно, чашка с блютус моментально идёт нахуй, но вдруг кому надо…).
Ember®
Ember Mug² (EU)
Designed for home or office, Ember Mug² does more than simply keep your coffee hot. Our smart mug allows you to set an exact drinking temperature, so your coffee is never too hot, or too cold.
Ember then maintains your chosen temperature for 1.5 hours with…
Ember then maintains your chosen temperature for 1.5 hours with…
SOL Talks
Несомненный плюс того, что многие знают о моём интересе к разного рода гаджетам: люди делятся со мной своими находками. Сегодня дружбан подкинул линк на чашку, которая поддерживает установленную температуру напитка… за 130 баксов (или 150€)! Придётся брать!™…
У нас с женой кстати вот по такой кружке(?) Stanley за двадцатку. Пользуемся почти каждый день дома, берём в поездки. Збс.
Stanley 1913
Classic Trigger-Action Travel Mug | 12 OZ
Shop Stanley insulated drinkware & gear! The 12oz Classic Travel Mug. The classic keeps your beverage warm (or cold) with its double-wall vacuum insulation.
This media is not supported in your browser
VIEW IN TELEGRAM
Типочки запилили нехуйскую систему для отделения людей от фона на видеостримах в реалтайме (4K@30fps, 1080p@60fps). И она явно получше тех, что используются в современном софте для видеоконференции, и якобы даже лучше хромакея. Чтобы это работало, нужно сначала снять чисто фон, что, в принципе не такая уж большая плата. А, ну и топовая видяха нужна 🤑
Вот видос, вот сорцы (Python).
Вот видос, вот сорцы (Python).
Написал, почему я перешёл с GMail на HEY.com. Последний появился всего около года назад, но я уже настолько привык, что позабыл о GMail, Outlook и т.д. Если кратко, то всё потому, что HEY помогает вырабатывать дисциплину, а не просто «предоставляет средства».
Teletype
Почему и зачем я перешёл на использование HEY.com?
Если вдруг кто не в курсе, то HEY.com — это почтовый сервис от Basecamp. Они пообещали переопределить само понятие электронной почты...
SOL Talks
Несомненный плюс того, что многие знают о моём интересе к разного рода гаджетам: люди делятся со мной своими находками. Сегодня дружбан подкинул линк на чашку, которая поддерживает установленную температуру напитка… за 130 баксов (или 150€)! Придётся брать!™…
Кто-то решил, что блютуса в чашке недостаточно и решил добавить тач-управление в бидон с ручкой кружку, чтобы подстраивать температуру по своему вкусу. Ещё грят, мол, оно изучает привычки пользователя бла-бла-бла. Ожидаемая розничная цена — двести баксов всего 🙂
Совершенно не ясно, как этим пользоваться и что оно там изучает. При установке температуры тачем кружка чё-то там показывает светодиодами. Что именно‽ Во-первых, их не видно, когда они не светятся, во-вторых, никакой шкалы или пометок не нарисовано. Мне их считать или что?
По поводу изучения привычек я тоже хз. Я сам не ебу, какой там температуры я обычно что пью: 135°F или 142°F (сколько это в нормальных единицах-то?) — даже не уверен, играет ли разница в несколько градусов роль.
Если бы я делал «умную» кружку, я бы сделал на ней одну кнопку: «вот сча заебись». Просто жмёшь её, кружка запоминает текущую температуру и старается всегда её поддерживать.
Если прям хочется LEDов туда натолкать, то можно фигачнуть три красно-синих, чтоб показывать, насколько горячее/холоднее напиток в сравнении с моим дефолтом. Всё.
Кидайте деньги кароч, сделаю проект на кикстартере! 😂
Совершенно не ясно, как этим пользоваться и что оно там изучает. При установке температуры тачем кружка чё-то там показывает светодиодами. Что именно‽ Во-первых, их не видно, когда они не светятся, во-вторых, никакой шкалы или пометок не нарисовано. Мне их считать или что?
По поводу изучения привычек я тоже хз. Я сам не ебу, какой там температуры я обычно что пью: 135°F или 142°F (сколько это в нормальных единицах-то?) — даже не уверен, играет ли разница в несколько градусов роль.
Если бы я делал «умную» кружку, я бы сделал на ней одну кнопку: «вот сча заебись». Просто жмёшь её, кружка запоминает текущую температуру и старается всегда её поддерживать.
Если прям хочется LEDов туда натолкать, то можно фигачнуть три красно-синих, чтоб показывать, насколько горячее/холоднее напиток в сравнении с моим дефолтом. Всё.
Кидайте деньги кароч, сделаю проект на кикстартере! 😂
Kickstarter
HAVA Mug: The most advanced, self-heating smart mug (Canceled)
Keep coffee or tea at your desired temperature for up to 2 hours | simply swipe on the mug to adjust
Наткнулся тут на либу для игр — raylib на сишечке. Наверняка не впервые, но как-то я раньше не обращал внимания на количество байндингов к другим языкам, которых весьма дофига.
Само́й библиотекой я пользоваться, конечно, не буду — мне нечего писать с её использованием. Но вот список языков пригодится: люблю я изучить новый под настроение. Когда-то напишу, откуда у меня такое пристрастие.
Само́й библиотекой я пользоваться, конечно, не буду — мне нечего писать с её использованием. Но вот список языков пригодится: люблю я изучить новый под настроение. Когда-то напишу, откуда у меня такое пристрастие.
raylib
raylib is a simple and easy-to-use library to enjoy videogames programming.