Не думал, что опрос соберет столько реакции. Пользуясь случаем, хочу задать общественности другой вопрос: какие концепции в программировании, какую базу необходимо знать условному новичку, если на изучение у него есть 3 условных месяца?

Чтобы в дальнейшем он мог двигаться в любом интересующем его направлении

Верите в совпадения? Tracing Frames 101

В конце октября я делал доклад на ITeaConf (опубликовали в ноябре), где говорил о том, почему мы не следим за отброшенными кадрами. Если кратко, потому что это сложно. В докладе я лишь упомянул о том, что ответ нужно искать в работе жизненного цикла компоновщика.

В ноябре выходит доклад Tracing Frames 101 на конференции BlinkOn 15, который как раз и раскрывает эту тему глубже — профилирование (или точнее трассировка) кадров.

Если вам интересны тонкости работы рендеринга Chromium браузера, то рекомендую видео к просмотру.

Дополнительные ссылки

- BlinkOn - youtube-канал с всеми докладами конференции;
- BlinkOn 15 — официальное описание мероприятия;
- How cc Works — документ о работе компоновщика в Chromium;
- Life of a frame — документ о жизненном цикле кадра.

Donut math: how donut.c works

Как написать вращающийся в пространстве пончик в консоли на JavaScript

На днях пересобрал из своих заметок доклад Браузерный рендеринг (слайды) для podlodka fecrew, если до этого не смотрели доклады на эту тему, то текущий может вполне зайти.

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

В следующем году п̶е̶р̶е̶с̶к̶а̶з̶ы̶в̶а̶т̶ь̶ делать доклады про рендеринг не собираюсь — пора переключиться на другую большую тему, погружение в которую слишком долго откладывал. Постараюсь выдать некоторый контент на тему приватности и/или анонимности с точки зрения браузера.

Возможно, вам не нужен Rust, чтобы ускорить ваш JS

Статья начала 2018 года, не знаю насколько она актуальна сегодня, вдруг в v8 для некоторых примеров из статьи что-то изменилось за это время, однако сами подходы к оптимизации JavaScript кода довольно интересны и неожиданны. И почему я раньше не читал статьи от Вячеслава Егорова

Русский перевод: https://habr.com/ru/post/350018/
Оригинал: https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html

Defront Feed — новости веб-разработки

Мне часто попадаются небольшие новости и статьи, которые не попадают под формат канала. Такие материалы я обычно ретвичу или делюсь ими в чате канала. Долго думал, как эффективнее доносить их до аудитории. Публиковать их здесь не хочется, так как пропадёт фишка канала с дистиллированными статьями. Поэтому решил сделать отдельный канал для такого новостного контента — Defront Feed. В нём будут публиковаться новости и мини-посты, которые не попали в Defront и Defront Plus.

Приглашаю подписаться на канал. Если у вас есть какие-нибудь замечания, идеи и любой другой фидбек, то пишите мне в лс или в чат, контакты есть в описании канала.

@defront_feed

Менеджеры состояний

Гости выпуска:
— Артем Арутюнян: twitter, telegram
— Александр Колесников: twitter

Содержание выпуска:
- 00:03:12 - Состояние и менеджер состояний (SM)
- 00:06:00 - Множество состояний
- 00:10:18 - Зачем SM, если есть встроенные API
- 00:12:28 - Единый интерфейс, единственный API
- 00:20:13 - Принципы, лежащие в основе SM
- 00:27:46 - Почему появляются новые SM
- 00:35:58 - Влияние SM на архитектуру приложения
- 00:42:12 - Как быть непосвященному разработчику
- 00:47:32 - Переход на новый SM в приложении
- 00:51:52 - Стандартизация API
- 00:59:41 - Проблемы больших состояний
- 01:05:18 - Синхронизация c бекэндом
- 01:09:05 - 2 менеджера состояний и 1 состояние

Слушать подкаст на других платформах

Материалы к выпуску s01e09:
- Архитектура менеджера состояния
- Ромбовидное наследование
- Ромбовидные зависимости
- ECMAScript proposal for the Record and Tuple value types
- yjs: Shared data types for building collaborative software
- BuilderIO/partytown

Дружественные каналы о разработке

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

— devSchachtChannel — Подкаст. Переводы. Веб-разработка. Ведущий канала Андрей Мелихов. У Андрея есть также youtube-канал, где вы сможете найти ролики про NodeJS, Nest, архитектуру и прочее, также есть подкаст на soundcloud. Благодаря Андрею можно сказать появился подкаст Станция НЛО, ведь все записи происходят на подаренный им микрофон.

— Defront — ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков. Ведущий канала — Александр Мышов. В канале публикуются краткие пересказы статей, у каждой статьи есть хэштэги, что помогает поиску. В свое время канал позволил ознакомится со множеством статей касательно performance. Существует еще дочерний проект Defront Feed.

— Вебня — JS VMs, спецификации, пропозалы, встречи #TC39, WebAssembly, W3C, браузеры, нёрдство. Ведущие канала: Сергей Рубанов, Роман Дворнов (@gorshochekvarit). Благодаря вебне, можно быть на один шаг впереди касательно обновлений в ECMAScript.

— wild_wild_web — небольшие заметки о TypeScript/Node.js. Ведущий канала: Евгений Обрезков. Известен своим проектом type-challenges-solutions. Если возникают какие-то вопросы по тонкостям типизации, то иногда заглядываю на его канал. Евгений помимо всего прочего первый гость подкаста Станция НЛО. Доклады Евгения.

— vladtenlive — личный канал Влада, в котором помимо всего прочего появляются ссылки на технический контент. Концентрированный контент касательно разработки можно найти на его youtube канале, где он устроил марафон решений задач из leetcode. Также в рамках проекта "Мы обречены" Влад брал интервью у известных представителей мировой айти сферы в выпусках Тен за Бугром.

— KirJS — Кирилл стримит про front-end, Open Source, Angular. Приходите на его стримы, там очень лампово. Кирилл периодически приглашает на стримы других разработчиков, где он пытается вместе с гостями разобраться в поставленных технических вопросах.

— Math.random() — профессиональное сообщество: бесплатные вебинары; публичные собеседования; проекты на JavaScript из FrontEnd, BackEnd, Mobile. Ведущий канала: Андрей К. Присутствует также youtube-канал, на котором можно найти весь вышеобозначенный контент.

— typesafesound — типы, фронтенд, DX и программирование в целом. Occasional music. Канал ведет Михаил, который пытается углубиться в типизацию, например, на канале можно найти стрим как решались задачки на Coq.

Григорий Петров - Почему Python медленный

Несмотря на заявленное название, в докладе рассматриваются и другие языки, в том числе Java, C#, JavaScript и тд. Рекомендую к ознакомлению всем интересующимся языками программирования.

Антон Сергеев, «Go под капотом»

Скомпилированная программа "Hello world" на одной и той же машине, написанная:
— на C++ весит 8.2Кб
— на Golang весит 2.0Мб

Такая разница связана с находящимся в программе на Golang runtime: горутины, планировщики, стандартная библиотека и прочее.

О том, как работает Golang runtime, вы узнаете в этом видео. Помимо любителей Golang доклад будет интересен и тем, кто питает интерес к устройству программ, написанных на других языках.

Вчера Артем Арутюнян (@artalar) нашел уязвимость в популярном пакете Nano ID, у которого миллионы скачиваний в неделю. В частности Артем нашел проблему колизий при генерировании новых ID и предложил способ решения.

valueOf

В моем личном списке, “что должен сделать успешный программист за свою карьеру”, есть два пункта: найти уязвимость в чужом ПО и исправить ее. Я никогда не надеялся их реализовать тк предметная область мне кажется достаточно сложной. Но вчера, совершенно случайно, при регулярном использовании nanoid у меня что-то стрельнуло в голове, и я пошел копать исходники.

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

Для нетерпеливых вот ПР с кодом воспроизведения проблемы и ее фиксом.

Детали. В вызов генератора идентификатора можно передать число для указания его длины. Чаще всего его не указывают и используется значение по умолчанию - 21. Одна из особенностей JS заключается в том что для математических операций над значениями вызывается их метод valueOf, который для Number возвращает само число, но для любых других объектов мы можем его переопределить. И возвращать разные числа по условию!

Проанализировав код библиотеки, я понял, что переданный параметр длинны идентификатора передается по ссылке и в какой-то момент участвует в трех математических операциях с условиями, в которых можно создать логическую ошибку, если значение переменной будет меняться для каждого условия. В ПРе есть наглядный пример реализации.

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

Интересно было и придумать исправление для этой ошибки. Не хотелось вносить большой оверхед в нано библиотеку, я сам увлекаюсь микрооптимизациями производительности и бандлсайза и для меня это был отдельный челендж. Несколько часов я экспериментировал. Первая реализация добавляла 4 байта, последующая size += size добавляла 2 байта. В итоговой версии я добавил всего 3 символа -=0, а магия минификатора и архиватора смогла нивелировать это до ничего - бандлсайз не изменился.

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

В течении дня я нашел уязвимость, связался с автором, сделал фикс, отрепортил все это в snyk, который завел CVE-2021-23566 (скоро будет опубликован). Андрей со всем помогал и сразу же зарелизил новую версию 3.1.31, за что ему отдельно спасибо.

В общем опыт был интересный, наконец удалось получить фан от слабой динамической типизации ЖСа 🙂

В ближайшее время планируется выпуск подкаста с разработчиком в сфере IT Healthcare с медицинским образованием.

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

IT Healthcare

Гости выпуска:
— Александр Павлушкин (telegram, linkedin)

Содержание выпуска:

- 00:37 - Знакомство с гостем
- 05:31 - Информационные системы
- 11:41 - IT Healthcare
- 13:36 - Разработка без экспертизы
- 17:28 - Контроль FDA
- 20:17 - Ошибки в ПО
- 22:43 - Стандартизация ПО
- 27:19 - Google Healthcare API
- 28:10 - С чего начать в IT Healthcare
- 30:40 - Требования к стэку
- 32:33 - Удаленная диагостика
- 34:50 - Обмен данными м/у клиниками
- 39:32 - Кому принадлежат данные
- 42:14 - prodoctorov.ru
- 46:43 - Машинное обучение
- 51:51 - Чипирование
- 55:15 - Напутствие разработчикам

Слушать подкаст на других платформах

Материалы к выпуск s02e01:
- FDA, Food and Drug Administration;
- FHIR — standard for health care data exchange;
- МКБ-10;
- SNOMED International;
- Google Healthcare API.

Дедлоки (1/2)

Всех с наступившим! 🐌

Решил я тут почитать, что умные дядьки пишут про дедлоки. Как обычно оказалось, что поверхностное понимание уровня «пройти интервью» неверно от начала до конца, а в реальности всё супер интересно и конечно известно уже последние лет 50.

Дедлок или deadly embrace, как их называл товарищ Дейкстра (тот самый, который алгоритм) — ситуация бесконечного ожидания, при которой группа процессов не может продолжать работу, пока «внешние силы» не совершат определенные действия. Слово «процесс» здесь не имеет отношения к процессам в операционной системе. Процесс в дедлоке — некий автомат с набором состояний. Такими состояниями могут быть «процесс А не владеет ресурсами» или «процесс B владеет ресурсом alpha и пытается получить ресурс beta». На самом деле определение не совсем корректное в 100% ситуаций, но для обсуждения большинства подходов подойдёт.

Для начала, рассмотрим самый простой случай: дедлок на одной машине, вызванный конкурентным доступом к некоторому ресурсу из нескольких процессов. Ресурсом может быть как примитив синхронизации, например мьютекс, так и устройство, например принтер.

Такой дедлок называется либо ресурсным, либо interleaved дедлоком. Первое более привычное и популярное название, второе я нашёл только в [4]. Для возможности его возникновения необходимо выполнение 3 условий:

1. Exclusive access. Только один процесс может захватить ресурс одновременно.
2. No-preemption. Процесс, захвативший ресурс, не может быть прерван.
3. Hold and wait condition. Должны разрешаться ситуация, при которой процесс захватил сначала один ресурс, а теперь ждёт пока освободится второй. Не отпуская при этом первый.

Наличие этих условий в системе ещё не гарантирует возникновение дедлока! Это только необходимые условия. Их наличие означает существование unsafe region[5] — такого набора состояний процессов, попав в которое, ни один из процессов не может завершить свою работу.

При наличии unsafe region достаточно найти лишь 1 набор состояний, чтобы обеспечить дедлок. Оно же последнее условие:

4. circular wait condition. Процессы и ресурсы должны иметь возможность собираться в «цепочку». К примеру: Процесс A владеет ресурсом a при этом хочет захватить ресурс b, которым владеет процесс B, который хочет завладеть ресурсом a. Если обозначить эти отношения стрелочками:

a -> A значит процесс A владеет ресурсом a.
A -> b значит процесс A хочет завладеть ресурсом b.

Схематично получится круг (ну или квадрат):

a  -> A
^     |
|     v
B <-  b

Дедлоки (2/2)

Первый инсайт: дедлоки не возникают просто так, для них необходимо 3 условия: exclusive access, no-preemption, hold-and-wait + одно достаточное: circular wait.

Второй инсайт: чтобы побороть дедлок, достаточно избавить от одного из условий!

Пункт 2 особенно интересен, и позволяет другими глазами взглянуть на работу с ресурсами и привычные «программистские трюки». Например: почему часто разделяют локи на read-only и write-only локи? Для перформанса, конечно. Но ещё и потому что в read-only локе не может возникнуть дедлок, так как он не эксклюзивный (первое условие)!

Или вот я недавно сделал нечаянно не concurrent индекс в postgres на табличку с парой сотен миллионов записей и всё встало колом. Решение проблемы — preemption! Руками грохаем транзакцию и дедлок перестаёт существовать. И это магистры компьютерных наук знали ещё в 70-ых. Подобные же механизмы можно и автоматизировать. Правда не так просто. С одной стороны, обнаружение дедлока — в сущности задача на графах, где просто нужно правильно пройтись по ребрам от процессов до ресурсов. С другой, граф постоянно меняется буквально пока по нему проходишься. Кажется решений проблемы в общем случае нет, но в частных, например только в БД, они есть и работают.

С hold-and-wait тоже интересно. А что если бы процесс сразу же запрашивал все ресурсы, которые ему требуются? Или по крайней мере захватывал бы их постепенно, но при успехе отпускал бы все уже захваченные. Такой подход, оказывается, тоже убирает проблему дедлоков. К сожалению, не каждый процесс знает наперёд ни все нужные ему ресурсы, ни порядок, в котором они будут захватываться. Опять в общем случае решить тяжело, в частном вполне. Например обычно заранее известно, сколько памяти и CPU нужной новой виртуалке/контейнеру, а это тоже ресурсы, за которые тоже может быть конкуренция. Там правда ситуация не обязательно завершиться дедлоком, а скорее перемещением одного из процессов, но это детали. Раскидывать задачи по компьютерам — очень сложная задача, поэтому в как-нибудь в следующий раз.

Наконец, circular-wait. А пусть все ресурсы должны захватывать только в определенном порядке. К примеру, перечислим все ресурсы в системе от 1 до n. И добавим условие: если процесс захватил ресурс 1 <= k <= n, он может захватить только любой другой ресурс с номером m, где m < k. Другими словами, процессу сначала нужно захватить самый «высокоуровневый» ресурс, а дальше все ресурсы пониже. Наличие нумерованных ресурсов и одного условия на их захватывание также позволяет избавиться от дедлоков. Полный пруф есть в [5].

Все эти подходы можно широкими мазками разделить на 3 категории:

- Detection. Подходы, которые по графу ресурсов и их зависимостей позволяют обнаружить дедлок. Для борьбы используется preemption.
- Prevention. Цель: задизайнить систему таким образом, чтобы дедлок был невозможен. Например: пронумеровать ресурсы и ввести условие их захвата. Или запретить захватить ресурс, а затем ждать второй.
- Avoidance. Подходы, при которых система переходит только из одного «безопасного» состояния в другое. Решение о выдаче ресурса принимается динамически, к примеру во время запроса. Самый популярный алгоритм: алгоритм банкира. К сожалению для него необходимо, чтобы процессы сразу знали, какие ресурсы им нужны.
- Алгоритм страуса. Или ничего не делать. Стратегия при которой программист сажается на on-call и ему выдаётся кнопка «отмена».

Ресурсы:
1. E.G. Coffman, M. Elphick, A. Shoshani. System Deadlocks.
2. Richard C. Holt. Some deadlock properties of computer systems.
3. S.S. Isloor, T.A. Marsland. The Deadlock Problem: An Overview.
4. Gertrude Neuman Levine. Defining deadlocks.
5. Charles M. Shub. A Unified Treatment of Deadlock.

Вчера запустили CTF-квэст игру для фронтендеров https://ctf-2022.ilovefrontend.ru