Defront — про фронтенд-разработку и не только
24.6K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Сергей 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