Шедевральное

Кстати, я в своё время на своей работе понял довольно простую вещь: если существующий код мешает решить задачу — его можно и поменять.

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

#prog

TIL что в Github есть возможность склонировать отдельно вики репозитория.

https://docs.github.com/en/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages#cloning-wikis-to-your-computer

(немножко #лингво) #meme про воздержание

#music

А вообще почему это четвёртый трек? Потому что он, кхм, четвёртый из набора оригинальных треков, каждый из которых сочетает стилистику Doom Eternal с другими темами.

Providence — Doom + киберпанк (не сразу, но зашло)
Maker's hand — Doom + постапокалиптичные пустоши в духе Mad Max
Livitica Void — Doom + sci-fi
Crown of Oris — Doom + симфонический орекстр

И, разумеется, есть видео о том, как эти треки создавались:

What if the Doom Eternal OST was made for fighting cyborgs instead of demons?
What if the Doom Eternal OST was made for fighting psychos and bandits?
What if Control had Doom Eternal style music instead?
I put a 56-piece orchestra into a Doom Eternal style song and it crashed my computer

А, и ещё есть ремикс Providence от Audiofreq. Доля Doom в этом варианте сильно меньше и куда больше, прости г-споди, дабстепа, но звучит тоже хорошо.

Папищеки
Вы такие харошие

Telegram

#prog

Bloaty — инструмент для оценки размеров различных составляющих исполняемого файла.

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

Поддерживает ELF и Mach-O. Поддержка PE и Wasm заявлена как экспериментальная.

#prog #лингво

The Korean Writing System

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

Система письма на удивление стройная и логичная. Каждый иероглиф обозначает отдельный слог, состоящий из начальной согласной (которая может отсутствовать), гласной и конечной согласной (которая также может отсутствовать). Для обозначения каждого из этих элементов есть набор элементов, называемых чамо. Иероглиф, обозначающий конкретный слог, составляется из трёх чамо, соответствующим составляющим слога. При этом способ сборки иероглифа зависит от того, является ли чамо для гласной вытянутым по горизонтали или по вертикали.

Парочка примеров из статьи:

녹 (NOG) = ㄴ(N) + ㅗ(O) + ㄱ(G)

냇 (NAES) = ㄴ(N) +ㅐ(AE) + ㅅ(S)

(да, некоторые чамо являются диграфами/триграфами/дифтонгами, так что это не столь стройная система, какой она могла бы быть)

Какое это имеет отношение к Unicode? Не смотря на то, что технически тексты на хангыле можно записывать исключительно из комбинирующихся чамо, это расточительно по памяти + многие системы рендера текста это не осиливают (напоминаю, что статья в основном предназначена для веб-дизайнеров). Поэтому помимо чамо (коих, кстати, весьма немного) в Unicode есть code point-ы для уже составленных символов хангыля. Каждый из этих символов кодируется тремя байтами в UTF-8 (как и каждый чамо). Конкретные коды при этом выбраны не наобум: код для иероглифа хангыля можно вычислить через линейную комбинацию кодов составляющих его чамо. Соответственно, из кода для иероглифа можно вычислить коды составляющих его чамо.

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

#prog #sql #db

You Need More Constraints

Чеклист ограничений на таблицы в SQL, которые почти наверняка имеют смысл для ваших данных, вместе с конкретными примерами.

#meme про Линка

Кстати, в Армении открыл для себя мандариновую Фанту. Гораздо вкуснее обычной

#prog #cpp #article

Разработчики PVS-studio неоднократно проверяли Chromium. Есть даже цикл статей Chromium: шестая проверка проекта и 250 багов. Как всегда, познавательно и показывает мощь статического анализа, но при чтении статьи меня не покидала мысль, что очень многого количества ошибок можно было бы избежать, просто используя более грамотно спроектированный API. Некоторые (многие) из указанных ошибок не могли бы появиться в нормальном коде на Rust, и предотвращение этих ошибок обычно даже не требовало бы каких-то киллер-фич Rust.

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