Меня зовут Валерий Шавель, я из команды разработки векторного движка Яндекс.Карт. Недавно мы внедряли в движок технологию WebAssembly. Ниже я расскажу, почему мы её выбрали, какие результаты получили и как вы можете использовать эту технологию в своём проекте.

Как Flutter работает на самом деле?

Что такое Widgets, Elements, BuildContext, RenderOject, Bindings?..

Сложность: Новичок

Вступление

В прошлом году (прим: в 2018), когда я начал свое путешествие в сказочный мир Flutter, в Интернете было очень мало информации по сравнению с тем, что есть сегодня. Сейчас, несмотря на то, что уже написано много материалов, лишь небольшая их часть рассказывает о том, как на самом деле работает Flutter.

Что же такое Widgets (виджеты), Elements (элементы), BuildContext? Почему Flutter быстрый? Почему иногда он работает не так, как ожидается? Что такое деревья и зачем они нужны?

В 95% случаев при написании приложения вы будете иметь дело только с виджетами, чтобы что-то отображать на экране или взаимодействовать с ним. Но неужели вы никогда не задумывались, как вся эта магия работает внутри? Как система узнает, когда обновить экран и какие части должны быть обновлены?

Содержание:

• Вступление
• Часть 1: Предыстория
  
  • Немного об устройстве
  • Интерфейс между кодом и устройством
  • Управление Flutter Framework рендерингом Flutter Engine
  • RenderView и RenderObject
  • Инициализация bindings
  • SchedulerBinding
  • GestureBinding
  • RendererBinding
  • WidgetsBinding

Опубликованная месяц назад статья Алексис Бингесснер «Рендеринг текста вас ненавидит» очень мне близка.

В далёком 2017 году я разрабатывал интерактивный текстовый редактор в браузере. Неудовлетворённый существующими библиотеками на ContentEditable, я подумал: «Эй, да просто заново реализую выделение текста! Разве это сложно?» Я был молод. Наивен. Прикинул, что справлюсь за две недели. На самом деле попытка решить эту проблему отняла несколько лет моей жизни, в том числе год оплачиваемой работы с утра до вечера по разработке текстового редактора для новой ОС.

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

Рендеринг текста: насколько сложным он может быть? Оказывается, невероятно сложным! Насколько мне известно, буквально ни одна система не выводит текст «идеально». Где-то лучше, где-то хуже.

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

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

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

Достаточно много было шумихи по поводу того, что из-за нового чипа T2 невозможно установить linux на новые MacBook 2018 года с тачбаром. Шло время, и под конец 2019 года стронними разработчиками был реализован ряд драйверов и патчей ядра для взаимодействия с чипом T2. Основной драйвер для MacBook моделей 2018 и новее реализует работу VHCI (работа тача/клавиатуры/и.т.д.), а также функционирование звука.

Проект mbp2018-bridge-drv разделен на 3 основных компонента:

• BCE (Buffer Copy Engine) — устанавливает основной канал связи с T2. VHCI и Audio требуют этот компонент.
• VHCI — это виртуальный хост-контроллер USB; клавиатура, мышь и другие компоненты системы предоставляются этим компонентом (другие драйверы используют этот хост-контроллер для обеспечения большей функциональности.
• Audio — драйвер для аудиоинтерфейса T2, в настоящее время поддерживается только вывод звука через встроенные динамики MacBook

В предыдущей статье мы разбирали протокол Modbus, являющийся стандартом де-факто в промышленности для M2M-взаимодействия. Разработанный в далеком 1979 году, он имеет ряд существенных недостатков, которые решает MQTT.

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

Главные особенности протокола MQTT:

• Компактный и легковесный — минимальные накладные расходы на пересылку данных, для экономии трафика.
• Устойчивость к потерям — гарантированная доставка в условиях нестабильных сетевых подключений.
• Асинхронный — позволяет обслуживать большое количество устройств, и не зависит от сетевых задержек.
• Поддержка QoS — возможность управлять приоритетом сообщений и гарантировать доставку сообщения адресату.
• Динамическая конфигурация — не требует предварительно согласования полей и форматов данных, может конфигурироваться «на лету».
• Работает за NAT — клиенты могут находиться за NAT, только сервер (брокер) должен иметь реальный IP. Позволяет обойтись без VPN и пробрасывания портов.
• Удобная адресация — поля данных имеют текстовые названия, понятные для человека. Не нужно запоминать цифровые адреса и битовые смещения.

«В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки» — сообщает нам Википедия. Сами будучи поклонниками Linux, мы регулярно сталкиваемся с вопросом, какими именно инструментами её лучше осуществлять. И хотим поделиться переводом статьи программиста Хонгли Лая, который рекомендует bpftrace. Забегая вперёд, скажу, что заканчивается статья лаконично: «bpftrace — это будущее». Так чем же он так впечатлил коллегу Лая? Развёрнутый ответ под катом.

Источники вдохновения

Этот пост возник благодаря недавней публикации Араса Пранцкевичуса о докладе, предназначенном для программистов-джуниоров. В нём рассказывается о том, как адаптироваться к новым ECS-архитектурам. Арас следует привычной схеме (объяснения ниже): показывает примеры ужасного ООП-кода, а затем демонстрирует, что отличным альтернативным решением является реляционная модель (но называет её «ECS», а не реляционной). Я ни в коем случае не критикую Араса — я большой фанат его работ и хвалю его за отличную презентацию! Я выбрал именно его презентацию вместо сотен других постов про ECS из Интернета потому, что он приложил дополнительные усилия и опубликовал git-репозиторий для изучения параллельно с презентацией. В нём содержится небольшая простая «игра», используемая в качестве примера выбора разных архитектурных решений. Этот небольшой проект позволил мне на конкретном материале продемонстрировать свои замечания, так что спасибо, Арас!

Слайды Араса выложены здесь: http://aras-p.info/texts/files/2018Academy — ECS-DoD.pdf, а код находится на github: https://github.com/aras-p/dod-playground.

Я не буду (пока?) анализировать получившуюся ECS-архитектуру из этого доклада, но сосредоточусь на коде «плохого ООП» (похожего на уловку «чучело») из его начала. Я покажу, как бы он выглядел на самом деле, если бы правильно исправили все нарушения принципов OOD (object-oriented design, объектно-ориентированного проектирования).

Спойлер: устранение всех нарушений OOD приводит к улучшениям производительности, аналогичным преобразованиям Араса в ECS, к тому же использует меньше ОЗУ и требует меньше строк кода, чем ECS-версия!

TL;DR: Прежде чем прийти к выводу, что ООП отстой, а ECS рулит, сделайте паузу и изучите OOD (чтобы знать, как правильно использовать ООП), а также разберитесь в реляционной модели (чтобы знать, как правильно применять ECS).

­­ 

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

Мы больше не контролируем свои домашние каталоги.

В моём собственном 25 обычных файлов и 144 скрытых. В дотфайлах хранятся данные, которые не принадлежат мне: они принадлежат программистам, чьи программы решили захватить моё пространство, предназначенное для хранения моих личных файлов.

Я не могу убрать эти файлы в другое место. Если я попытаюсь их удалить, они появятся снова. Всё, что я могу сделать — это сидеть и знать, что в темноте, за кулисами, они есть. Ожидание в тишине. Некоторые из этих программистов решили дополнительно разместить здесь несколько обычных файлов и каталогов. Они хорошо видны каждый раз, когда я выполняю ls. Понятия не имею, как в мою личную папку попали каталог node_modules, файлы package-lock.json, yarn.lock (я никогда сознательно даже не ставил yarn!), какие-то два странных лог-файла от какой-то Java-программы, явно использующей СУБД H2, и папка Desktop. Последнюю создал Steam, что довольно неудачно, поскольку на моей машине просто нет рабочего стола или какого-то десктопа. Боюсь того дня, когда услышу громкий стук в дверь — и один из этих программистов ворвётся и сообщит, что собирается хранить часть своей мебели посреди моей гостиной, если я не возражаю.

Барни проснулся от звука будильника. На часах было 6:15 утра.

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

Спустившись вниз, Барни с удивлением обнаружил, что он явился на завтрак последним.

– Опаздываешь, товарищ, – улыбнулся Гордон.
– Погоди-ка, – Барни поднял руку и взглянул на часы, а затем его глаза с подозрением прищурились. – Сейчас 6:29, до условленного времени еще целая минута. Это просто вы пришли раньше, а начальники не опаздывают.
– Этого парня не провести, – заметил Джо, отправляя себе в рот кусок мяса.

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

Предлагаю вашему вниманию субъективную подборку ржавых новостей за январь. В этой подборке: Rust 1.32, уход Стива Клабника и Ника Камерона, киш от Cloudflare, устройство rust-analyzer и страничной памяти, поиски GUI и async, Oxydyze конференция для встроенщиков.

Rust 1.32

Вышел Rust 1.32. По сравнению с масштабным прошлым выпуском, на котором было сконцентрировано множество сил всего сообщества, тут серьезных нововведений не очень много:

• Новый вспомогательный макрос для отладки dbg!;
• По умолчанию убран jemalloc.
• Стабилизированы "единообразные пути" ("uniform paths")

Подробности в переводе новости.

Стив Клабник и Ник Камерон уходят из Mozilla

Печальные новости: Стив Клабник и Ник "nrc" Камерон покидают Мозиллу.

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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