На Microsoft Build 2019 пару дней назад был интересный доклад Дэниала Розенвассера про новые возможности в TypeScript "What’s new in TypeScript".

Разработчики компилятора последний год работали над скоростью. В версии 3.4 добавили инкрементальную сборку сборку проекта с сохранением состояния между сборками с помощью флага --incremental.

Было добавлено ключевое слово readonly, которое можно использовать вместо ReadonlyArray. Ещё теперь можно разворачивать кортеж типов в rest-параметрах функции, что позволяет избавиться от перечисления всех возможных параметров с помощью перегрузки типов. Это позволило улучшить типизацию методов bind и call у функций. Пример использования:

type MyTuple = [string, number];
declare function foo(...args: MyTuple): string;

После доклада автор TypeScript — Андерс Хайлсберг — отвечал на вопросы. Среди них был вопрос про компиляцию в WebAssembly. Если говорить кратко, это не имеет смысла. Для запуска TypeScript в WebAssembly необходим скомпилированный в WebAssembly JavaScript-движок, таким образом появляется избыточный слой (речь шла про браузерное окружение).

В общем, доклад хороший, советую посмотреть.

#typenoscript #webassembly #talk

https://www.youtube.com/watch?v=Au-rrY0afe4

Джереми Кейт написал у себя в блоге статью "Timing out" про то, как он использует Service Workers, чтобы улучшить пользовательский опыт при "Lie-Fi" (при неустойчивом соединении с сетью).

Стратегия работы с кэшом Service Worker'а выглядит следующим образом. Когда пользователь пытается загрузить страницу, сначала происходит попытка загрузки этой страницы из сети. Если это не удаётся, запрошенная страница берётся из кэша. Если в кэше страницы нет, показывается специальная страница для offline-режима. При этом, если запрашиваемая страница загружается слишком долго (Lie-Fi), пользователю отдаётся закэшированная страница.

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

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

#offlinefirst #serviceworker #cache

https://adactio.com/journal/15122

Посмотрел доклад с прошедшего Google I/O'19 "Next-Generation 3D Graphics on the Web" про настоящее и будущее 3D-графики в Web'е.

Из первой части доклада запомнилось использование веб-компонентов для снижения сложности кода при использовании WebGL-фич. Вот так выглядит пример вставки просмотрщика 3D-моделей на страницу:

// импорт библиотеки
<noscript type="module" src="model-viewer.js"></noscript>
// добавление просмотрщика на страницу
<model-viewer src="astronaut.glb"></model-viewer>

Вторая часть доклада для меня была самой интересной. Она была посвящена новому API — WebGPU. Показали демо, где на сцене рендерилось 10000 объектов. Всё работало довольно производительно (~40fps). WebGPU способен отправить в три раза больше команд на отрисовку относительно WebGL.

Рассказали про то, что с помощью WebGPU теперь можно эффективнее работать с фильтрами пост-процессинга и алгоритмами машинного обучения, так как WebGPU гораздо гибче чем WebGL — он позволяет работать с разделяемой памятью GPU. Это также открывает возможность вынесения симуляции жидкости, скиннинга, параллельной сортировки и других алгоритмов с CPU на GPU.

Новое API доступно пока в Chrome Canary на macOS в экспериментальном режиме. API включается с помощью флага chrome://flags/#enable-unsafe-webgpu. Над новой спецификацией работают производители всех браузеров.

#talk #webgl #webgpu

https://www.youtube.com/watch?v=K2JzIUIHIhc

Хоть я и пользуюсь для разработки Vim'ом, не могу пройти мимо этой новости. Недавно разработчики Visual Studio Code анонсировали поддержку удалённой разработки в WSL, контейнерах и на удалённых машинах через SSH — "Remote Development with VS Code".

Иногда бывает так, что локально развернуть проект для разработки либо сложно, либо невозможно. В этом случае можно синкать файлы на удалённую машину или примонтировать локально удалённую директорию. При таком подходе используются те инструменты, которые доступны локально, что бывает не очень удобно. Можно разрабатывать полностью на сервере, запустив удалённо Vim/Emacs, но это подойдёт далеко не всем. Разработчики VS Code попробовали улучшить опыт удалённой разработки, и, по-моему, у них это получилось.

Они сделали поддержку запуска VS Code одновременно на сервере (development services) и на клиентской машине. Серверная часть работает непосредственно с кодом: реализует поддержку IntelliSense, go to definition, поиск и т.п. Локальная версия VS Code выступает "тонким клиентом". Благодаря этому становится возможна отладка linux-приложений в VS Code, запущенном на Windows, и многое другое.

Поддержка удалённой разработки доступна в insiders build. Когда она будет доступна в стабильном релизе, пока неизвестно.

#vscode #devexperience #microsoft

https://code.visualstudio.com/blogs/2019/05/02/remote-development

Томаш Лакоми написал неплохую статью о том, как приготовить хороший технический доклад "What I wish someone told me about speaking at tech conferences".

Сначала в статье даются рекомендации, как подаваться на большую конференцию. Запомнился совет про то, чтобы дать прочитать тезисы доклада своим коллегам. Советует не сдаваться, если получили отказ, и продолжать подавать доклад на другие конференции и локальные митапы. (Кстати, если вы хотите выступить с докладом, то можете написать мне. Я один из организаторов митапа JS Party Nsk.)

Далее Томаш пишет про подготовку слайдов. Делится тем советом, который запомнился ему больше всего: "Люди либо могут вас слушать, либо читать ваши слайды. Они не будут делать это одновременно". Меня немного удивило то, что он предлагает разместить ник, использующийся в социальных сетях, на всех слайдах в углу, кажется, что в этом есть смысл.

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

В общем, советую прочитать статью особенно тем, у кого пока нет большого опыта выступлений.

#conference #softskills

https://dev.to/tlakomy/what-i-wished-someone-told-me-about-speaking-at-tech-conferences-3opp

Сегодня прочитал хорошую статью Юана Чуана про нестандартное свойство -webkit-box-reflect "Chinese Window Lattice And CSS".

В статье рассказывается, как с помощью CSS нарисовать традиционный китайский узор. Идея заключается в том, чтобы выделить минимальный элемент, который с помощью отражений можно преобразовать в сложный паттерн, используя подход похожий на разворачивание сложенного листа бумаги. Достигается это с помощью нестандартного CSS-свойства -webkit-box-reflect, который используется на вложенных друг в друга div'ах. Каждый уровень увеличивает число отображаемых элементов экспоненциально.

Обязательно загляните в статью, так как без иллюстраций описать красоту этого подхода сложно.

P.S. Ссылку на эту статью мне прислал телеграм-товарищ, ex-Amazon бэкендер Олег Ковалёв. Олег ведёт канал @oleg_log, в котором много полезной (и не очень, но весёлой) инфы. Пишет в основном про бэкенд. Читаю его каждый день, интересно, даже если что-то непонятно. В общем, рекомендую.

#css #experimental

https://yuanchuan.dev/2019/05/15/window-lattice-and-css.html

Недавно Артур Столяр написал на хабре статью "Наши урезанные мобильные веб-сайты" про проблему мобильных сайтов в российском сегменте интернета.

Артур обратил внимание на то, что опция для перехода с мобильной версии сайта на десктопную в мобильных браузерах с русской локализацией называется как "Полная версия". Так же называется и ссылка для перехода на десктопную версию на многих российских сайтах. Подсознательно это воспринимается так, что мобильные версии какие-то неполные или урезанные. Соответственно, если в них есть баги или лаги, то мы как разработчики и как пользователи можем воспринимать их несерьёзно. Это же не "полная" версия.

В англоязычном интернете, нет ссылок и опций с названием "Full version", там есть "Desktop site". Артур завёл тикеты на изменение локализации в Chrome, Firefox, Safari и Яндекс.Браузере. "Версия для ПК" уже появилась в стабильном Chrome для Android и iOS. Также был заведён баг в ВК, ребята отнеслись с пониманием и поменяли ссылку на «Версия для компьютера».

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

#musings #mobile #web

https://habr.com/ru/post/451518/

Сегодня наткнулся на список ресурсов по accessibility от Марси Саттон. Нашёл я его через твит Флориана Бэйенса — разработчика из Нидерландов. Флориан слеп с самого рождения, поэтому его рекомендации стоит уделить как минимум немного внимания.

В этом списке есть много ссылок на ресурсы от W3C, сайты, курсы, инструменты и книги, посвящённые a11y:
- A11y Style Guide
- Google/Udacity Web Accessibility course
- Accessibility Wins
- Inclusive Design Patterns
- Accessibility for Everyone
- и т.д.

Я не специалист по a11y, но кажется, что подборка очень хорошая. Добавил себе в закладки.

#a11y #list

https://marcysutton.com/web-accessibility-resources

Ингвар Степанян из Cloudflare написал статью про объяснение принципа работы Binary AST — "Faster noscript loading with BinaryAST?"

Binary AST — это предложение в TC39, цель которого ускорить парсинг JavaScript. Парсинг может быть основной причиной медленного старта приложений на слабых устройствах. Например, на флагманских смартфонах парсинг 1Мб JavaScrpt занимает 100ms, в то время как на слабых устройствах (Moto G4) — более секунды. С помощью Binary AST на этапе сборки можно представить AST JavaScript в бинарном виде с дополнительными хинтами, которое позволяет ускорить парсинг до 90% в синтетических тестах.

Ингвар в статье также рассказывает про то, каким образом Cloudflare внедрил поддержку Binary AST. Они используют кодировщик Binary AST, который написан на Rust. Исходный JavaScript при этом парсится с помощью Shift в инстансе v8. На данный момент их следующая цель — сбор данных с реальных проектов, чтобы улучшить формат представления AST.

Binary AST находится на первом этапе рассмотрения в TC39. Прототип реализации уже добавлен в Nightly-версию Firefox. Над развитием стандарта работает Mozilla, Cloudflare, Facebook и Bloomberg.

#js #proposal #tc39

https://blog.cloudflare.com/binary-ast/

Пару дней назад Дас Сурма из Google опубликовал у себя в блоге статью про работу с WebAssembly — "Raw WebAssembly".

В статье объясняются базовые принципы работы виртуальной машины wasm. Разбирается структура WebAssembly-модулей в текстовом формате "wat". Есть пара интересных примеров. Например, показывается как из WebAssembly вызывать JavaScript-функцию. Подобный подход используется в wasm-bindgen, для того чтобы из Rust-кода манипулировать DOM-узлами в браузере. Есть пример работы с памятью.

Сурма в статье пишет про то, что для эффективной работы c WebAssembly необязательно знать внутреннюю структуру wasm-модулей и особенности работы виртуальной машины. Но это знание может помочь в тех ситуациях, когда что-то идёт не так.

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

#webassembly #vm

https://dassur.ma/things/raw-wasm/

Евгений Вецель написал отличную статью о том, как сохранить здоровье программисту — "Стимуляторы работы программиста. Здоровье".

Евгений советует делать физические нагрузки на протяжении дня. Например, если любите слушать подкасты, то лучше слушать их находу. В принципе ходить очень полезно для здоровья. Для пополнения энергии советует хорошо питаться и спать. В статье есть такой совет, что если днём вам хочется поспать, то можно задремать на 15-20 минут. Но лично мне было бы некомфортно спать прямо на рабочем месте, поэтому я стараюсь спать минимум 8 часов каждый день. Есть несколько советов про еду: кушайте полезную еду, старайтесь делать это регулярно, пейте много воды и уменьшайте количество употребляемого кофе.

В статье ещё есть и другие советы про посещение врачей, профилактику туннельного синдрома и т.п. Имхо имеет смысл прислушаться к рекомендациям из статьи. Как говорится, здоровье у нас одно.

#productivity #life #health

http://blog.csssr.ru/2019/05/07/work-stronger

Несколько дней назад в Firefox Nightly (версия 68) появилась поддержка Resize Observer. В принципе, я про него уже знал, но захотелось более подробно поразбираться в его особенностях. На сайте Web Fundamentals есть очень хорошая статья с описанием того, какие проблемы он решает и как с ним работать — "ResizeObserver: It’s Like document.onresize for Elements".

До появления этой спецификации отслеживание изменения размеров можно было реализовать с помощью getBoundingClientRect или getComputerStyle. Это очень непроизводительный подход, который приводит к лагам при взаимодействии со страницей. Resize Observer позволяет очень эффективно отслеживать и реагировать на изменение геометрии элементов на странице. Обработка событий изменения размеров в Resize Observer происходит сразу после этапа раскладки (layout) до стадии отрисовки (paint), таким образом это самое подходящее место для размещения логики изменения положения элементов или их размеров.

Resize Observer немного напоминает Media Queries и Element Queries из CSS, но они предназначены для разных целей. Media Queries и Element Queries задаются декларативно в CSS и определяют представление при изменении размеров. С помощью Resize Observer описывается необходимое поведение при изменении размеров. В статье есть очень показательный пример с окном чата, когда при изменении размера окна, список сообщений всегда должен быть "приклеен" к самому низу, но только в том случае, если пользователь не прокрутил список к другому сообщению.

На данный момент экспериментальная поддержка Resize Observer есть уже во всех актуальных браузерах. Для более старых версий браузеров можно использовать полифил.

#web #performance #future

https://developers.google.com/web/updates/2016/10/resizeobserver

Вчера вышла новая версия Firefox 67. В блоге Mozilla Hacks по традиции опубликовали пост с самыми интересными нововведениями — "Firefox 67: Dark Mode CSS, WebRender, and more".

В Windows 10 начался процесс постепенной выкатки на всех пользователей с видеокартами NVidia нового WebRender. Это новый движок рендеринга, написанный на Rust и активно использующий GPU для отрисовки элементов страницы.

Появилась поддержка медиа-функции prefers-color-scheme с помощью, которой можно определить, включена ли у пользователя светлая или тёмная тема ОС, и соответствующим образом изменить внешний вид страницы. В JavaScript были добавлены динамические импорты import() и String.prototype.matchAll. Улучшили инструменты разработчика. Теперь можно ставить брекпойнты на частях одного большого выражения, записанного в одну строку (column breakpoint). Добавлена фича "log point", с помощью которой можно добавлять логирование в ходе процесса отладки, не используя console.log().

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

С каждым релизом Firefox становится лучше, это не может не радовать. Здорово то, что много внимания уделяется инструментам разработчика. WebRender тоже очень крутая фича, очень жду когда она появится под macOS.

#firefox #announcement

https://hacks.mozilla.org/2019/05/firefox-67-dark-mode-css-webrender/

Алекс Реадрон в конце апреля написал статью "What does react-beautiful-dnd cost to maintain?", в которой он делится своим опытом поддержки популярной библиотеки для drag'n'drop в react.

Поддержка занимает очень много времени — примерно один полный день в неделю. Чтобы снизить нагрузку, Алекс оптимизировал процессы, с помощью которых пользователи библиотеки могут самостоятельно решать возникающие проблемы. Он написал подробную документацию и поддерживает её в актуальном состоянии. Записал бесплатные видео-уроки на egghead. Добавил вывод warning-сообщений в консоль при неправильной настройке библиотеки. Он не добавляет новые фичи в библиотеку, когда есть открытые баги. В итоге такой подход тоже позволяет снизить время на поддержку.

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

Статья хорошо рассказывает про то, что у популярных Open Source-проектов ненулевая стоимость владения. Очень много времени уходит не только на написание кода, но и на попытки воспроизвести описанные ошибки и многое другое.

#programming #musings #opensource

https://dev.to/alexandereardon/what-does-react-beautiful-dnd-cost-to-maintain-52e8

Посмотрел доклад Джефа Ши из Netflix про то, как развивалась их часть React-приложения, отвечающая за регистрацию нового пользователя — "Redux For Transactional Apps".

Из доклада мне запомнилось то, как они боролись с разобщённостью флоу процесса регистрации на разных платформах: Web, Mobile, TV. На каждой платформе транзакции описывались в самом приложении (в докладе под транзакцией подразумевается пошаговое изменение состояния приложения). Логика транзакций в итоге была перемещена в API, что позволило решить проблему.

Ещё в докладе Джеф рассказал про то, какой профит они получили при использовании Redux. Благодаря тому, что view отделено от стейта, они могут использовать одну и ту же логику изменения состояния на разных платформах, просто подменяя компоненты, отвечающие за представление.

Доклад не хардкорный. Не могу сказать, что он будет полезен всем. Но если вы работаете с React, то посмотреть его можно.

#react #statemanagement #talk

https://youtu.be/V8oTJ8OZ5S0?t=1134

Попалась на глаза очень прикольная статья Сид Балы про объяснение принципа работы кодека H.264 — "H.264 is Magic". Перевод статьи на русский язык есть на хабре.

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

После обработки фреймов наступает этап кодирования компенсации движения, когда выделяется базовый фрейм I-frame и последующие фреймы, которые кодируют смещение блоков 16x16 пикселей базового фрейма. Это позволяет эффективно сжимать движущиеся изображения на статичном фоне. После кодирования компенсации движения применяется энтропийное кодирование.

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

#algorithm #video

https://sidbala.com/h-264-is-magic/

Пару месяцев в закладках лежала статья Дага Силларса про объяснение того, почему инлайн изображений в CSS с помощью Base64 является анти-паттерном — "Performance Anti-Patterns: Base64 Encoding".

Добавление закодированных в base64 изображений блокирует critical rendering path. Если изображение очень большое, то это повлияет на размер CSS. После загрузки большой CSS-файл должен будет распариться. Комбинация этих двух факторов увеличивает задержку перед отображением документа. Также может возникнуть такая ситуация когда один и тот же файл может быть заинлайнен несколько раз. Даг нашёл пример, в котором одно и тоже фоновое изображение было заинлайнено 115 раз. Ещё в статье был пример большого CSS, в который было заинлайнено 6 разных шрифтов.

Совет в статье простой — использовать инлайн изображений с умом. Также не стоит инлайнить шрифты. И по возможности надо переходить на HTTP/2.

P.S. Завтра буду рассказывать обновлённый доклад про кодмоды на FrontendConf в Москве. Если среди вас кто-нибудь там будет, подходите сказать привет, буду рад вашему фидбеку.

#performance #base64 #css

https://calendar.perfplanet.com/2018/performance-anti-patterns-base64-encoding/

Прочитал серию из двух хороших статей "Disguise-Driven Testing: Jest Mocks in Depth" Джо Моргана про использование моков в Jest.

Jest — это фреймворк для тестирования, разработанный Facebook, который развивался в самом начале как форк Jasmine. В первой части рассказывается про основы использования моков, зачем они нужны и как их использовать. Очень подробно разбирается пример их использования для подмены результатов вызова Rest API сервиса. Первая часть написана очень доступно, поэтому особенно рекомендую почитать её новичкам и тем, у кого небольшой опыт работы с инструментами для тестирования.

Во второй части статьи рассматриваются, на мой взгляд, более интересные примеры. Пример мока генератора уникального id, с возможностью его тонкой настройки. И пример мока библиотеки, которая работает с DOM API. В последнем примере тестируется React-компонент, использующий хуки. Для того чтобы useEffects заработал корректно, использовался небольшой трюк с задержкой с помощью async/await. Вторую часть статьи рекомендую тем, у кого уже есть опыт использования Jest. Скорее всего из неё вы узнаете что-нибудь новое.

#jest #mocks #testing

https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth
https://ponyfoo.com/articles/disguise-driven-testing-jest-mocks-in-depth-part-2

Вчера увидел ссылку на статью Марка Миллера (участник TC39) "The Tragedy of the Common Lisp: Why Large Languages Explode".

Несмотря на название статьи речь в ней идёт про JavaScript. Марк работает над стандартизацией языка с 2007 года. Он очень заботится о том, чтобы язык оставался минимальным и элегантным. В статье он объясняет, почему избирательно подходит к выбору того, что будет добавлено в ECMAScript. По его мнению, минимализм языка является тем качеством, который ценят большинство разработчиков. Осознание того, что мы полностью понимаем принципы работы инструмента, ведёт к чувству удовлетворения.

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

В конце статьи он призывает (видимо, своих коллег по TC39) стремиться к дисциплине, чтобы возможности языка не разрослись до такой степени, когда язык не даёт удовлетворения от его использования.

#js #tc39 #musings

https://medium.com/@erights/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9

Инженеры eBay неделю назад написали пост про то, как они используют WebAssembly у себя в проекте — "WebAssembly at eBay: A Real-World Use Case". На хабре есть перевод.

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

Сначала для чтения штрих-кодов они использовали JavaScript библиотеку BarcodeReader. Но она работала хорошо только в 20 процентах случаев. Потом они воспользовались скомпилированной в WebAssembly C++ библиотекой, которую они используют в нативных приложениях. И опять возникла проблема — библиотека даёт отличный результат только на сфокусированном изображении. Так как есть ограничения Web-платформы связанные с камерой, они не смогли добиться хорошего результата. Потом они попробовали другую Open Source C++ библиотеку, там тоже было не очень всё ок, но она работала в тех случаях, когда не работала предыдущая библиотека. Поэтому у них появилась идея распознавать штрих-код, используя сразу три разных подхода одновременно: с помощью двух скомпилированных в WebAssembly библиотек и с помощью JavaScript-библиотеки.

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

#webassembly #usecase

https://www.ebayinc.com/stories/blogs/tech/webassembly-at-ebay-a-real-world-use-case/

Давайте вернёмся к теме отладки приложений. Нашёл в дебрях интернета статью 2014-го года "The Debugging Toolbox".

В статье Бэн МакКормик пишет про свою стратегию решения проблем в коде. В этом ему помогает выстроенный с годами процесс, который можно поделить на несколько шагов:

- Определение проблемы
- Воспроизведение проблемы
- Сужение возможных мест, где возникла ошибка
- Выдвижение гипотез, с учётом прошлого опыта
- Погружение в чтение кода, в тех местах, где потенциально могла возникнуть ошибка
- Повтор предыдущих шагов, до того момента пока не получится сформировать суть проблемы (тезис)
- Проверка корректности полученного тезиса
- Повтор предыдущих, пунктов пока не будет сформирован корректный тезис
- Задокументировать полученное решение, чтобы знать, куда копать в подобных ситуациях, завести необходимые тикеты в сторонних библиотеках, если проблема была в них и т.п.

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

#debug #programming

https://benmccormick.org/2014/08/19/the-debugging-toolbox