Объяснение легковесных потоков в 200 строк на Rust

Легковесные потоки (ligthweight threads, coroutines, корутины, green threads) являются очень мощным механизмом в современных языках программирования. В этой статье Carl Fredrik Samson попытался реализовать рантайм для легковесных потоков на Раст, попутно объясняя, как они устроены "под капотом".

Так же следует учесть, что статья не суперсвежая, так что для того, чтобы примеры заработали в современной ночной версии компилятора Раст, скорее всего понадобятся изменения, найти которые можно в репозитории кода для этой статьи.

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

У нас в TeamHood есть wiki. Там собралась коллекция рекомендаций, в том числе, по улучшению производительности тяжелого фронтенда на vue.js. Улучшать производительность понадобилось, потому что в силу специфики наши основные экраны не имеют пагинации. Есть клиенты, у которых на одной kanban/gantt доске больше тысячи вот таких вот карточек, все это должно работать без лагов.

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

В этой статье мы собираемся создать пайплайн непрерывной интеграции (CI) с Tekton, фреймворком с открытым исходным кодом для создания конвейеров CI / CD в Kubernetes.

Мы собираемся подготовить локальный кластер Kubernetes через kind и установить на нем Tekton. После этого мы создадим пайплайн, состоящий из двух шагов, который будет запускать модульные тесты приложения, создавать образ Docker и отправлять его в DockerHub.

Это 1 из 2 частей, в которой мы установим Tekton и создадим задачу, запускающую тест нашего приложения. Вторая часть доступна здесь.

Данная статья будет полезна тем, кто никогда прежде не экспериментировал с Raspberry, но считает, что этому самое время.

Привет, Хабр! Тенденция приписывать любому техническому устройству эпитет «умный» достигла, кажется, своего апогея (по количеству употребления, разумеется). К тому же, большинство моих знакомых не из IT-сферы до сих пор наивно полагают, что каждый уважающий себя программист живет в самом «умном» доме во всём квартале, у которого вместо стен — серверные стенды исполинских размеров, а в свободное от работы время этот же человек-программист выгуливает «умную» собаку из Boston Dynamics. Дабы не отставать от этих современных стандартов, мы с товарищем решили собственноручно создать что-то «умное», но несложное, поскольку в школе схемотехника и конструирование роботов обошли нас стороной.

За последние 5 лет Node.js очень изменился, но знания о платформе у сообщества остались на уровне 2013-2015 годов, все те же подходы, все те же проблемы. Сообщество плохо следит за новыми возможностями, а если и узнает про них, то это не влияет на написание ежедневного кода. В Node.js, да и в JavaScript, слабо проникают фундаментальные знания по программной инженерии и архитектуре, параллельному программированию, GRASP, SOLID, GoF, а если и проникают, то не подвергаются адаптации и переосмыслению. Поэтому, среди других языков программирования JavaScript воспринимается, как несерьезный, а в среде разработчиков Java, C++, C#, распространено мнение, что Node.js, это платформа для малограмотных людей. Как преодолеть эту тенденцию и как изменить подход к разработке на Node.js в 2020 году, с использованием всех современных возможностей и знаний, а так же, что нужно изменить в ежедневных практиках написания кода, эти и другие вопросы рассматриваются в трех бесплатных вебинарах «Node.js в 2020: Выйди и зайди нормально» 11, 14 и 21 апреля, накануне выхода Node.js v14.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Futures — Isolates — Event Loop" автора Didier Boelens об асинхронности и многопоточности в Dart (и Flutter в частности).

TLDR: В целом, статья ориентирована на новичков и не изобилует откровениями. Если вы знакомы с механизмами Event Loop, Future и async/await (например, в JavaScript), корутинами в Кotlin, скорее всего, вы не найдёте для себя много нового. Однако, реализация многопоточности в виде механизма Изолятов имеет особенности.

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

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

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

Статья описывает трансляцию кода TypeScript в OData запросы во время компиляции программы.

Плагин babel-plugin-ts2odata выполняет разбор JavaScript AST с помощью библиотеки TsToOdata описание которой в моей предыдущей статье Типизированные запросы OData в TypeScript.

Примерно месяц назад общаясь с одним разработчиком приложения на Flutter встала проблема торможения обработки маленьких (в десятках тысяч) массивов данных на телефоне юзера.

Многие приложения предполагают обработку данных на телефоне и, далее, их синхронизацию с бэкендом. Например: списки дел, списки каких либо данных (анализов, заметок и т.п.).

Совсем не круто, когда список всего нескольких тысяч элементов, при удалении одного из них и далее записи в кеш или при поиске по кешу — начинает тормозить.

Решение есть! Hive — noSql база, написанная на чистом Dart, очень быстрая. Кроме этого плюсы Hive:

• Кросс-платформенность — так как на чистом Dart и нет нативных зависимостей — mobile, desktop, browser.
• Высокая производительность.
• Встроенное сильное шифрование.

В статье мы посмотрим как использовать Hive и сделаем простое ToDo приложение, которое в следующей статье дополним авторизацией и синхронизацией с облаком.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Pattern: Saga" автора Chris Richardson.

Ситуация

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

Например: давайте представим, что мы разрабатываем интернет магазин, где у клиента есть кредитный лимит. Приложение должно гарантировать, что новый заказ не превышает кредитный лимит клиента. Так как Заказы и Клиенты — различные базы данных, то приложение не может использовать локальные ACID транзакции.

Проблема

Как обеспечить согласованность данных между сервисами?

Решение

Необходимо каждую бизнес транзакцию, которая охватывает несколько сервисов, реализовывать как сагу.

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