(мой друг будет рад плюсикам на гитхабе, так как проект интересный, еще и Elixir)

Последние полгода стало модно создавать новые и переводить старые проекты на рельсы AI-First (или AI-Friendly) стандарта. Уже появляются проекты, которые декларируются как «designed for AI to write». Например, AIR — AI-First веб-фреймворк на Python.

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

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

*уворачиваюсь от помидора из за слова ИИ в статье*

https://habr.com/ru/companies/ru_mts/articles/1027642/

Как работает HEX-редактор?

Как вы знаете, он позволяет открывать бинарные (двоичные) файлы. hex-редактор отображает данные в виде матрицы.

Первая часть - это адрес, offset, смещение в байтах от начала файла. Первая строчка с нуля, каждая следующая прибавляет ширину дампа - количество байт в одной строке. Байт - это два hex-числа. Десятичный адрес вроде 00000016 ничего не говорит о границах, а hex-адрес 00000010 сразу показывает, что мы пересекли границу 16 байт — аккурат строка дампа.

Вторая часть это сами байты. Байты в основном строятся по 16 (но может быть и другое число степени двойки) в колонку. Байты группируются по четыре для читаемости.

И третья часть - ASCII-панель, те же байты, но интерпретированные как символы (диапазон ASCII от 0x20 до 0x7E, от пробела до тильды). Если символ непечатаемый - пишется обычно точка.

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

Если твой ответ начинается с "Вот что мне сказал Claude:" или 800 слов неотредактированной простыни от ChatGPT - поздравляю: ты только что доказал, что твой мозг - просто прокладка. Дарвин бы гордился. Пожалуйста, не размножайся.

https://habr.com/ru/articles/1038534/

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

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

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

Будет и код, и архитектура, и результат, и практика.

https://habr.com/ru/companies/timeweb/articles/1034646/

https://habr.com/ru/companies/timeweb/articles/1034646/

https://habr.com/ru/companies/timeweb/articles/1034646/

Обычно я пишу о опенсорсе и разработке софта, но сегодня хочу рассказать о своем товарище, с которым познакомился на экскурсии по дата-центру Selectel. Даня работает там инженером, но речь пойдет о том, что делает после работы — конечно, продолжает инженерить (но уже, как говорят таксисты, для души).

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

https://habr.com/ru/articles/1041370/

Буду рад фидбеку и плюсикам, старался сделать объемной и затронуть много тем.

Следующая статья будет про один очень интересный алгоритм - hyperloglog, с реализацией на си и разбором

Я начал изучать Elixir, и вчера вышел релиз 1.20.0: https://elixir-lang.org/blog/2026/06/03/elixir-v1-20-0-released/

Меня весьма позабавило это заявление

Сделать систему типов одновременно sound, gradual и developer-friendly - это Святой Грааль, который в теории почти невозможен.

Sound (надёжная, корректная, если тайпчекер не выдал ошибок, значит не будет ошибок в рантайме), Gradual (постепенная типизация, можно не сразу типизировать весь код) и Developer-friendly (удобная для разработчика)

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

Интересно, что может получиться. Судя по всему, готовы резать фичи, или достичь Soundness + Gradualness ценой частичной Developer-friendly

Вы можете победить бинарный поиск

В этой статье речь пойдёт не просто об очередном алгоритме, а о том, как можно обойти классический бинарный поиск. Казалось бы, что может быть эффективнее старого доброго деления массива пополам для нахождения значения в отсортированных данных? Однако можно пойти дальше. В этой статье будет рассказываться о самодельном алгоритме «SIMD Quad» - квадратичном поиске.

Идея возникла из необходимости быстро искать 16-битные целые числа в массивах размером до 4096 элементов — именно такие структуры лежат в основе популярного формата Roaring Bitmap. Вместо того чтобы на каждом шаге сравнивать искомый элемент только с одной серединой интервала, авторский алгоритм использует две ключевые аппаратные особенности современных процессоров. Во-первых, это SIMD-инструкции, позволяющие за раз сравнить до 16 элементов. Во-вторых, это распараллеливание работы с памятью, которое даёт возможность безболезненно делить массив не на две, а сразу на четыре части. Так родился гибрид, который сначала выполняет учетверённый поиск по блокам, а затем находит нужный элемент с помощью векторных инструкций. Давайте разберёмся, как это работает и почему такой подход действительно позволяет превзойти бинарный поиск.

https://habr.com/ru/companies/timeweb/articles/1036538/

HyperLogLog: как найти уникальные значения в терабайте данных, не храня их

Представим задачу: хайлоад-сервис гонит поток данных — логи, IP-адреса, ID пользователей, миллиарды записей в сутки. Ваша задача — посчитать количество уникальных посетителей за неделю.

Первым решением может показаться завести HashSet и кидать туда ключи, а в конце посмотреть размер. Решение неплохое, но когда речь заходит о миллиардах записей — память будет слабым местом. Один IP-адрес (4 байта) как ключ в HashSet потянет за собой накладные расходы на ноды, указатели и хеши. На практике один элемент сжирает не меньше 50–100 байт. Поток в миллиард уникальных записей потребует под сотню гигабайт оперативной памяти. Это дорого, а если инстансов десять — то просто нереально.

Но существует алгоритм, который способен решить эту задачу примерно в 1.5 килобайта памяти с погрешностью около 2%? Без хранения самих данных и гигантских кластеров. Достаточно одного прохода по потоку и пары битовых трюков — именно так и работает HyperLogLog, алгоритм родом из математической статистики, который перевернул подход к подсчёту уникальности в Big Data.

HyperLogLog используют в Redis, BigQuery, ClickHouse, Presto. В этой статье мы разберем и реализуем этот алгоритм на C, а также узнаем его предысторию.

https://habr.com/ru/companies/timeweb/articles/1046345/
https://habr.com/ru/companies/timeweb/articles/1046345/
https://habr.com/ru/companies/timeweb/articles/1046345/

Планирую изучать дальше тему вероятностных алгоритмов.

Следующая тема - фильтр блума!