Увидел сегодня в твиттере ссылку на статью про код ревью от разработчика из Red Hat Дэвида Лойда — "10 tips for reviewing code you don’t like".

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

1. сделайте из возражения вопрос;
2. избегайте преувеличений;
3. не насмехайтесь;
4. ведите диалог в позитивном ключе;
5. помните, что не у всех одинаковый опыт;
6. не преуменьшайте сложность того, что неочевидно;
7. проявляйте уважение;
8. управляйте ожиданиями (и своим временем);
9. говорите "пожалуйста";
10. начинайте обсуждение, если возникает недопонимание.

Статья хорошая. Очень рекомендую почитать всем, кто работает в команде или занимается поддержкой open source проекта.

#musings #codereview #programming

https://developers.redhat.com/blog/2019/07/08/10-tips-for-reviewing-code-you-dont-like/

Абстракции и программирование неотъемлемые друг от друга части. Умение добавлять хорошие абстракции и определять те абстракции, которые наносят проекту вред, многого стоит. Мерик Кристенсен написал про эту тему статью — "Art Of Abstraction".

В статье нет каких-либо практических советов, но тем не менее в ней есть тезисы, которые заставят задуматься:

— Абстракция — это инструмент коллективного мышления. Корректное применение абстракции выражается в целостном API и инструментарии, так как люди взаимодействуют с проектом, руководствуясь общим языков.

— Фундаментально, компьютерная наука — это наука абстракций, создающая правильную модель для понимания проблемы и разрабатывающая подходящие воспроизводимые техники для её решения.

В статье есть много ссылок на хорошие статьи и доклады. Я уже выбрал доклад, который буду смотреть завтра — "Hammock Driven Development" Ричарда Хикки.

#musings #programming #abstraction

https://www.merrickchristensen.com/articles/abstraction/

Посмотрел доклад Ричарда Хикки — "Hammock Driven Development".

Ричард — создатель языка Clojure. При работе над языком ему надо было много думать над тем, чтобы добавляемые в язык абстракции органично взаимодействовали друг с другом. Ему надо была решать много задач. Про это он и рассказывает в своём докладе — про подходы решения разных задач, возникающих при разработке.

Способность эффективного решения задач — это не врождённое качество, а навык, который можно приобрести. Ричард порекомендовал всем почитать книгу "Как решить задачу" Д. Пойа. Книге уже больше 50 лет, но она до сих пор остаётся лучшей книгой на эту тему. В самом конце доклада он говорит про то, что не надо бояться, особенно не надо бояться оказаться неправым.

Очень крутой доклад. Рекомендую посмотреть или почитать транскрипцию.

#talk #programming #musings

https://www.youtube.com/watch?v=f84n5oFoZBc
https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/HammockDrivenDev.md

Сегодня вспомнил такое выражение: "Make It Work Make It Right Make It Fast". Насколько я помню, видел (или услышал) её в контексте разработки алгоритмов. Сегодня стало интересно, откуда она появилась.

Автор этой фразы Кент Бек; в другой формулировке она существует как часть философии Unix. Интерпретировать её можно по-разному, но в общем виде её можно понять так:
1. Сначала сделайте задачу с наименьшим количеством движущихся частей (Make It).
2. Потом следует обработать все крайние случаи и потенциальные ошибки (Make It Right).
3. И только потом можно заниматься оптимизацией (Make It Fast). Если для задач, с которыми не приходилось работать, сразу пытаться писать оптимизированный код, то такая преждевременная оптимизация усложнит систему и превратит её в то, что невозможно будет понять.

Как мне близок последний пункт. Помню, решал последнюю задачу из курса по алгоритмам от Стенфорда на Coursera (очень рекомендую пройти). Там надо было с помощью перебора решить NP-complete задачу. Использовал для решения задач C (потому что быстро, конечно). Ну и в итоге запутался в своём коде... Курс закончил, но было бы гораздо проще, если бы использовал python (javascript система проверки заданий не принимала).

#programming #musings #performance

https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Дэн Абрамов написал пост про проблемы фанатичного рефакторинга кода — "Goodbye, Clean Code".

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

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

Сейчас в твиттере и реддите немного бомбит из-за того, что Дэн призывает писать плохой код, но, имхо, статья не про это.

#musings #programming

https://overreacted.io/goodbye-clean-code/

Продолжаем тему преждевременных оптимизаций. Пару дней назад Никита Прокопов поделился своими мыслями по поводу известного высказывания "Premature optimization is the root of all evil".

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

Снова хочу закончить пост цитатой из статьи.

Then, if you are really serious about your final program’s performance, every decision must be made with performance in mind. [...] These sort of decisions are easy to make early on, but impossible to change later.

#programming #performance #musings

https://tonsky.me/blog/performance-first/

Добрался до статьи Андрея Ситника про допущенные ошибки в советской космической программе, и чему они могут научить — "What I learned as a developer from accidents in space".

В статье разбирается несколько реальных эпизодов. Самый интересный (и пугающий) — возвращение Андрея Волынова на Землю 18 января 1969 года. Его корабль, как все Союзы состоял из трёх отделяемых модулей. Во время приближения к Земле сервисный модуль не смог отсоединиться. Из-за этого корабль начал входить в атмосферу в неправильной позиции — корабль начал гореть. Космонавт начал описывать вслух все звуки, которые он слышал и вибрации, которые чувствовал, в надежде, что записывающая аппаратура сохранит все данные, для того чтобы избежать подобной трагедии в будущих полётах. Но всё закончилось хорошо — космонавт уцелел. Тут можно провести аналогию. Если вы вдруг столкнулись с какой-либо проблемой в сторонней библиотеке, например, сделали опечатку в конфиге и не получили предупреждение, подумайте над тем, чтобы завести issue или открыть пулл реквест — это поможет другим разработчикам при работе с библиотекой в будущем.

Статья очень интересная. Рекомендую почитать всем.

#programming #musings

https://evilmartians.com/chronicles/what-i-learned-as-a-developer-from-accidents-in-space

Александра Сикора поделилась мыслями о проблемах статей, посвящённых разработке, — "Most tech content is bullshit".

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

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

#musings #programming

https://www.aleksandra.codes/tech-content-consumer

Джек Франклин — разработчик Chrome Dev Tools — написал статью про важность простоты кода — "Keeping Code Simple".

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

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

#programming #musings

https://www.jackfranklin.co.uk/blog/keep-javascript-code-simple/

Сергей Ufocoder написал статью про полиморфизм — "Полиморфизм простыми словами".

Многие разработчики знакомы с полиморфизмом только в контексте ООП, но это далеко не всё, что стоит за этим понятием. По большому счёту любой код, который без изменения может работать с разными типами, может считаться полиморфным. Лука Карделли и Питер Вагнер в научной статье "On Understanding Types, Data Abstraction, and Polymorphism" обобщили все виды полиморфизма и выделили две группы. В первую группу (универсальный полиморфизм) попадают параметрический полиморфизм и полиморфизм включений. Во вторую группу (специальный полиморфизм) попадают перегрузка и приведение типов. В статье подробно разбирается введённая классификация на примере JavaScript, Python, C++ и TypeScript.

Очень крутая статья. Рекомендую почитать всем, кто хочет основательно разобраться в теме полиморфизма. Сергей очень основательно подошёл к её написанию, на несколько месяцев закопался в теорию и привлёк специалистов, разбирающихся в теории типов.

#programming

https://medium.com/devschacht/polymorphism-207d9f9cd78

Гиллель Уэйн поделился своими мыслями о том, как можно улучшить подсветку синтаксиса — "Syntax highlighting is a waste of an information channel".

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

В теории всё это выглядит очень заманчиво, но имплементация упирается в суровую действительность. Такая семантичеcкая подсветка должна реализовываться для каждого языка в отдельности, при этом многие фишки возможно реализовать только тогда, когда доступно AST.

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

#programming #musings

https://buttondown.email/hillelwayne/archive/syntax-highlighting-is-a-waste-of-an-information/

Генрик Уорн написал статью про хорошее логирование — "Good Logging".

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

Логирование не должно быть слишком подробным или скупым. Хорошие сообщения в логах должны говорить не про абстрактные серверы и файлы, а про конкретные ip-адреса и имена файлов. Сообщения должны быть таким, чтобы по ним можно было удобно grep'ать. При логировании сложной логики все шаги можно поместить в список, и вывести его в лог как одну большую строку. В хороших сообщениях не должно быть специальных символов, чтобы подчеркнуть важность, лучше для этого использовать разные уровни логирования (DEBUR, ERROR, INFO etc.) Очень трудно с первого раза придумать хорошие сообщения, поэтому их нужно постепенно улучшать. Также нужно не забывать добавлять новые сообщения, если при отладке ошибки в логах нет всей нужной информации.

Очень толковая статья. Рекомендую почитать всем.

#debug #programming

https://henrikwarne.com/2020/07/23/good-logging/

Степан Парунашвили объяснил принципы работы Lisp-подобных языков с помощью JavaScript — "An Intuition for Lisp Syntax".

В статье разбирается пример создания системы, которая принимает команды и выполняет их. Сначала используются предопределённые команды, затем добавляется поддержка переменных, потом поддержка создания произвольных функций. В итоге получается игрушечный язык, с помощью которого объясняются основные принципы, на которых построены все Lisp-подобные языки. А именно, почему синтаксис построен на списках, и в чём преимущества подхода "data is code".

Очень интересная статья. Рекомендую почитать всем для общего развития.

#programming #js

https://stopa.io/post/265

Джош Комю написал статью о том, как он программирует без клавиатуры — "Hands-Free Coding".

В этом году у Джоша возник локтевой туннельный синдром, из-за которого он больше не может использовать мышь и клавиатуру. Чтобы продолжать работать, он перешёл на альтернативные системы ввода: голосовой ввод текста и систему отслеживания взгляда. Для голосового ввода текста используется программа Talon, которая приспособлена для написания кода. Для отслеживания взгляда используется девайс tobii 5. По сравнению с обычным воркфлоу скорость написания кода примерно в два раза ниже, но самое главное, что благодаря такому набору софта/железа можно полноценно работать с компьютером.

Рекомендую почитать статью и посмотреть там небольшие скринкасты рабочего воркфлоу Джоша.

P.S. В случае проблем не откладывайте поход к врачу, не упарывайтесь с кодом и делайте регулярные перерывы.

#programming #a11y

https://joshwcomeau.com/accessibility/hands-free-coding/
https://habr.com/ru/company/vdsina/blog/524664/ (перевод)

Нашел интересную статью Санди Мец про проблему неправильных абстракций — "The Wrong Abstraction".

В психологии есть понятие "ловушка невозвратных затрат" (sunk cost fallacy). Это особенность психики, которая заставляет инвестировать время, деньги и другие ресурсы в убыточное дело. То есть чем больше мы вкладываем усилия в что-то, тем больше оно для нас становится ценнее.

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

Хорошая статья. Рекомендую почитать всем.

#programming #musings

https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

Майкл Линч написал статью о том, в каком виде лучше всего отправлять код на код ревью, чтобы оно прошло максимально быстро — "How to Make Your Code Reviewer Fall in Love with You".

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

Очень полезная статья. Must read для всех, кто работает в команде.

#programming

https://mtlynch.io/code-review-love/

Никита Прокопов из JetBrains написал статью про внутреннее устройство эмоджи — "Emoji under the hood".

В самом простом случае эмоджи — это одна кодовая позиция (то есть символ) из Unicode-таблицы. Сами изображения эмоджи находятся в шрифтах операционной системы: Apple Color Emoji (macOS/iOS), Segoe UI Emoji (Windows), Noto Color Emoji (Android). Приложения и сайты могут поставлять свой уникальный набор глифов эмоджи.

Большой набор эмоджи создаётся с помощью комбинации нескольких кодовых позиций Unicode — кластера графем. Например, два эмоджи можно объединить в один с помощью кодовой позиции U+200D (ZERO-WIDTH JOINER). Если эмоджи представляют людей, им можно задать оттенок кожи с помощью специальных модификаторов U+1F3FB..U+1F3FF и т.п.

Очень интересная статья. Рекомендую почитать всем.

#programming

https://tonsky.me/blog/emoji/

Два дня назад вышла новая мажорная версия текстового редактора Sublime Text. Бенджамин Шааф рассказал о его новых возможностях — "Sublime Text 4".

Теперь Sublime Text поставляется со встроенной поддержкой TypeScript, TSX и JSX. Есть все основные фичи: подсветка синтаксиса, автодополнение кода, переход к объявлению.

Переработан UI приложения. Теперь его компоновка происходит на GPU, улучшая отзывчивость интерфейса при работе с большими проектами. Также немного обновили дизайн и добавили поддержку автоматической смены тем.

Был переписан движок автодополнения кода. Теперь он понимает структуру проекта и, в целом, стал более полезен. В списке автодополнения были добавлены значки типа символа и опция для перехода к месту его объявления в коде.

Был улучшен движок подсветки синтаксиса. Упрощено открытие вкладок в режиме split view. Добавлена нативная поддержка Apple Silicon и Linux ARM64.

#tool #programming #announcement

https://www.sublimetext.com/blog/articles/sublime-text-4

Космические лучи и ошибки в программах

В университете у меня был предмет по теории управления. Там преподаватель рассказывал про альфа-частицы и протоны из космоса, переключающие биты в процессоре и ломающие программы. На эту тему на youtube-канале Veritasium было опубликовано видео — "The Universe is Hostile to Computers".

Ошибки, вызванные подобными явлениями, называются нарушениями в результате единичного события (single-event upset, SEU). Их учитывают при проектировании микроэлектроники и при разработке программного обеспечения, которое должно надёжно работать в условиях высокой радиации и повышенного влияния космических лучей. По этой причине в космосе вычисления дублируют на независимых компьютерах, а NASA во многих космических миссиях использует специальную версию процессора PowerPC — RAD750. По сравнению с обычными процессорами RAD750 в 30 раз более устойчив к возникновению SEU.

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

#programming #debug #video

https://www.youtube.com/watch?v=AaZ_RSt0KP8
https://www.youtube.com/watch?v=jOTM9T59IX4 (на русском языке)

Числа, которые должны быть известны каждому

Пол МакЛелан рассказал о числах, которые должны знать все программисты — "Numbers Everyone Should Know".

По интернету давно гуляет список Питера Норвига со временем тика CPU, доступа к L1, L2-кешам, доступа к памяти и т.п. В статье Пола этот список обновлён и расширен новыми пунктами: временем доступа к L3-кешу, временем передачи TCP-пакета в пределах датацентра, из Америки в Европу и обратно и т.п.

Обновлённый список:
— Тик CPU: 0.3 нс
— Доступ к L1: 0.5 нс
— Стоимость ошибки предсказания ветвления в CPU: 5 нс
— Доступ к L2: 3 нс
— Доступ к L3: 28 нс
— Доступ к памяти (DRAM): 100 нс
— Передача 2 Kб по 1 Gbps-сети: 20,000 нс
— Последовательное чтение 1 Мб данных из памяти: 250,000 нс
— Передача TCP-пакета в пределах одного датацентра: 500,000 нс
— Обращение к SSD: 100,000 нс
— Обращение к магнитному жёсткому диску: 10,000,000 нс
— Последовательное чтение 1 Мб данных из сети: 10,000,000 нс
— Последовательное чтение 1 Мб данных с жёсткого диска: 30,000,000 нс
— Время передачи TCP-пакета из Калифорнии в Европу и обратно: 150,000,000 нс
— Время на написание одного слова: 1 c
— Время на открытие PowerPoint на macOS: 10 с

Величину разрыва между этими цифрами можно прочувствовать в масштабе. Если бы тик CPU занимал одну секунду, то время передачи TCP-пакета из Калифорнии в Европу и обратно составляло бы десять лет, а PowerPoint открывался бы тысячелетие.

#programming

https://community.cadence.com/cadence_blogs_8/b/breakfast-bytes/posts/numbers-everyone-should-know