Вы когда‑нибудь логинились на сайте, используя аккаунт Google или Facebook? Или подключали приложение, требующее доступа к GitHub? Если да, то вы уже сталкивались с OAuth2, зная того или нет.

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

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

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

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

Должен признать, у меня есть некая особая любовь к классическому DOOM. Несмотря на то, что игре уже 31 год, в нее все еще весело играть самому (хотя и выходит у меня так себе) или просто смотреть на то, как другие в нее играют (вот в этом я показываю себя лучше); и поскольку исходный код игры открыт, ей можно наслаждаться на любой современной платформе — ПК, смартфон, камера, осциллоскоп — да и вообще на любой вещи, которая придет вам в голову. В результате чего, благодаря ряду обстоятельств, я оказался меинтейнером нескольких связанных с DOOM пакетов в Fedora Linux.

Итак, за несколько месяцев до нового релиза, проект Fedora Linux осуществляет массовую сборку всех пакетов. Это имеет несколько преимуществ — позволяет убедиться в совместимости ABI, обновить статически линкуемые зависимости, использовать новые оптимизации компилятора и так далее. Как бы то ни было, с приближением релиза Fedora Linux 42 в середине апреля, пришло время для массовой пересборки, и как часто бывает, не все пакеты выжили. Одним из пакетов, которые не удалось собрать оказался chocolate-doom.

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

В этом году я хотел написать идеальную программу для решения челленджа Advent of Code. Если идеальная программа и может существовать, она должна быть написана на Rust. Давайте помучаем декларативные макросы Rust для получения ответа на задачу первого дня Advent of Code в виде ошибки компиляции.

Это первая часть статьи, посвященной дженерикам в Go, из четырех.

Одна из последних и наиболее интересных фич в Golang — поддержка дженериков. Эта серия туториалов будет посвящена тому, что это такое, какую пользу приносит, когда их стоит использовать и как они меняют процесс написания приложений на Golang. Начнем же!

В прошлом я уже публиковал детальный разбор кода сборщика мусора CPython, однако стоит также дать более высокоуровневое объяснение механизмов управления памятью в CPython, не затрагивая сам код. Этому и будет посвящена данная статья. Статья в основном будет посвящена циклическому сборщику мусора (GC), как и когда он запускается и его влиянию на производительность приложений.

Иногда все, что требуется — быстро вывести какой‑то текст в Renderpass. Традиционно отрисовка текста требует отрендерить все возможные символы шрифта в атлас, затем привязать полученный атлас как текстуру и затем отрендерить каждый глиф, рисуя треугольники, каждый из которых должен соотноситься с нужным глифом из текстуры атласа шрифта.

Так делает imgui, равно как и все, кто использует stb_truetype. Сам процесс приятно напоминает процесс наборного производства на физических станках.

Причудливо, правильно, но в то же время напряжно.

Если нам нужно просто вывести какое‑то сообщение для дебага? Нет ли какого‑либо более простого метода?

В данной статье я опишу метод бестекстурной отрисовки дебаг‑текста. Вдобавок, отрисовка будет производиться в один вызов draw.

Как и многие, я храню свой код на GitHub. Пару лет назад я сделал простой пайплайн для сборки, анализа и тестирования моих веб‑приложений и сервисов. Он выполнял свою задачу, и так как это был мой первый опыт по настройке пайплайна CI/CD на GitHub, он сводился к одному шагу.

build (and deploy)

Со временем я стал замечать, что я стараюсь избегать вносить изменения в код. Будучи счастливым обладателем ADHD, я часто замечаю за собой сложность в решении задач с большим количеством препятствий и одним из них стало то, что выполнение пайплайна занимало больше 5 минут. Я коммитил изменения и шел делать кофе, пока пайплайн тестировал и деплоил код. И не всегда возвращался, отвлекаясь на другие вещи.

Я решил для себя, что максимальное количество времени, которое я готов ждать - 1 минута.

CPython 3.13 был выпущен две недели назад и стал одним из наиболее сфокусированных на производительности релизов за последнее время. Пробежавшись по release notes, я заметил несколько фич, которые могли бы повлиять на производительность.

В этой статье мы сфокусируемся на free‑threaded режиме и посмотрим, как его использовать и как он может влиять на производительность.

Мне нравится оптимизировать код — определение и исправление неэффективных участков кода приносит некое особое чувство удовлетворения в отличие от закидывания проблемы железом. Ведь последнее — пустая трата ресурсов и выбросов углерода!

В процессе моей работы я много раз оптимизировал использование памяти датафреймов Python. Не учитывая различные особенности, зачастую наиболее быстрым решением является понижающее приведение — к примеру, конвертация столбца нулей и единиц из int в bool. И хотя это срабатывает, недавно к своему удивлению я узнал, что булевы числа не всегда отображаются в качестве одиночных битов. Так как же отображаются типы данных в памяти?

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

Python 3.13 — отличный релиз, полный различных фич и улучшений, но уже есть тонна статей, которые подробно разбирают release notes. Если вам нужна хорошая выжимка — у RealPython есть хорошая статья, но я не вижу смысла проходиться по ним еще раз в этой статье.

Так что мы не будем говорить про новый REPL, no‑GIL сборку, экспериментальный JIT‑компилятор, устаревшие штуки, новые плюшки системы типов или улучшенные сообщения об ошибках (как всегда, мое любимое).

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

Это не кликбейт. Мы и правда сделали это! В Microsoft мы работаем с очень большим монорепозиторием, который между собой называем 1JS. Недавно мы достигли 1000 активных пользователей в месяц, около 2500 пакетов и ~20 млн строк кода! Последнее клонирование репозитория вернуло невероятные 178 ГБ.

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

Вопрос в том, как это вообще произошло?!

Конечно, async/await были придуманы не для сна. Нашей целью с самого начала был ввод‑вывод (I/O), а в особенности сетевой ввод‑вывод. Вооружившись futures и задачами, теперь мы можем перейти к реальным примерам.

В этой статье мы рассмотрим несколько стратегий по постепенному добавлению Rust в сервер, написанный на другом языке, например JavaScript, Python, Java, Go, PHP, Ruby и т. д. Один из возможных кейсов для подобного добавления — вы профилировали сервер, нашли «горячую» функцию, не соответствующую требованиям производительности из‑за боттлнека по CPU, а обычные техники мемоизации или оптимизации алгоритма были бы невозможны или малоэффективны по той или иной причине. После чего вы пришли к выводу, что стоит посмотреть в сторону реализации данной функции на что‑то написанное на более производительном языке, например на Rust. Отлично, данная статья для вас.

Во введении мы сказали, что async/await это про futures и задачи. В первой части мы рассмотрели futures и теперь пришло время задач. Благо, мы с ними уже встречались, хоть мы их так и не называли.

В введении мы посмотрели на пример асинхронного Rust без какого‑либо объяснения, как он работает. Это дало нам несколько вопросов для размышления: Что такое асинхронные функции и возвращаемые ими «future»? Что делает join_all? Чем отличается tokio::time::sleep от std::thread::sleep?

Чтобы ответить на эти вопросы нам потребуется преобразовать каждую из частей в обычный не асинхронный код Rust. Вскоре мы обнаружим, что воспроизвести foo и join_all достаточно просто, а вот со sleep ситуация чуть сложнее. Начнем же.

Async/await, или «асинхронный ввод‑вывод», — это относительно новая функция языка, которая позволяет программам выполнять несколько задач одновременно. Это своего рода альтернатива многопоточности, хотя программы на Rust часто используют и то и другое. Асинхронный ввод‑вывод особенно популярен в веб‑сервисах и сетевых приложениях, работающих с большим числом подключений одновременно.

Эта серия статей представляет собой введение в "futures", задачи и асинхронный ввод‑вывод в Rust. Наша цель — понять основные механизмы, чтобы асинхронный код не казался магией. Мы начнем с преобразования (так называемой «рассахаризации») асинхронных примеров в обычный Rust и постепенно создадим собственную асинхронную «среду выполнения». На данном этапе под «средой выполнения» мы понимаем библиотеку или фреймворк, которые используются для написания асинхронных программ.

Создание собственных фьючерсов, задач и механизма ввода‑вывода позволит понять, что именно делает для нас среда выполнения. Предполагается, что вы уже немного писали на Rust и читали The Rust Programming Language \или аналогичный источник.

Давайте начнем с выполнения нескольких задач одновременно с использованием потоков. Сначала все пойдет хорошо, но затем, с увеличением количества потоков, начнутся проблемы. Затем мы добьемся того же, используя async/await. В этой части мы разберем примеры, а в следующей мы начнем углубляться в них.

Релиз версии Go 1.23 добавил поддержку итераторов и пакет iter. Теперь можно перебирать константы, контейнеры (map, slice, array, string) и функции. Сначала создание итератора показалось мне неудобным, хотя в то же время его использование выглядело простым.

Моя проблема с подходом к итераторам в Go заключается в том, что их нельзя «связывать» так,как это можно делать в JavaScript:

Недавно я пытался объяснить коллеге, какие у меня критерии при формировании пул реквеста — когда стоит объединять что‑либо в один пул реквест, а когда нет. И я заметил за собой фразу «ну, кроме…» несколько раз и решил записать, как я использую git — чтобы разобраться в особенностях моего подхода, как я мог бы улучшить его и, возможно, поделиться чем‑то полезным.

Поскольку это интернет, давайте сразу обговорим: то, как я использую git основывается на последних 12 годах работы в компаниях с относительно небольшими (до 50 человек) командами. В каждой из них мы использовали только git и GitHub; изменения выполнялись в отдельных ветках, предлагались в виде пул реквестов и сливались в основную ветку. В последние несколько лет, после введения GitHub squash‑merging, мы использовали его.

Я никогда не использовал какую‑либо другую систему контроля версий. Я не могу и не буду сравнивать git с Mercurial, jj, Sapling, и т. д.

Итак, вот как я использую git.

На работе наша команда недавно столкнулась с необходимостью в высокопроизводительном IPC в Rust. Поиск привел нас к содержательной статье от 3tilley «IPC in Rust — a Ping Pong Comparison», что стало превосходной отправной точкой в нашем исследовании.

Вдохновляясь этой работой, мы решили копнуть глубже и провести собственные замеры производительности, в особенности нас интересовал новый многообещающий фреймворк iceoryx2. Взяв за основу работу в исходной статье, мы будем использовать UNIX Domain Sockets (как stream, так и datagram), Memory Mapped Files и Shared Memory с использованиемiceoryx2 для сравнения производительности IPC между процессами на одной машине для различных размеров пэйлоада.

Неожиданные результаты эксперимента с хранением большого количества числе в массиве в 64-битным Pharo Smalltalk, которые меня удивили.