Программирование *

По мере роста сложности программных систем документация становится не “сопроводительным текстом”, а инженерным активом, она участвует в принятии решений, согласовании требований, проектировании архитектуры, тестировании и эксплуатации. Однако на практике документация часто создаётся разрозненно, несколькими авторами, в несогласованных форматах. Это приводит к потере целостности и росту транзакционных издержек на коммуникации. В такой распределённой среде параллельно растёт применение AI-ассистирования при подготовке технических материалов, что повышает требования к формализации процесса и контролю качества создаваемых артефактов [1].

В программных проектах техническая документация представляет собой совокупность различных артефактов – требований, сценариев, диаграмм, описаний архитектуры и данных – распределённых между участниками и стадиями жизненного цикла. В условиях активного уточнения целей и решений, особенно на стадии исследовательско-опытных работ (research and development, R&D; далее – R&D), такие артефакты развиваются неравномерно, одни быстро детализируются и пересматриваются, другие остаются на уровне ранних гипотез. Это приводит к утрате целостности документационного контура, возникают противоречия между документами, различается уровень абстракции, дрейфует терминология, а изменения становятся трудно сопоставимыми друг с другом. Одновременно ослабевает трассируемость и затрудняется восстановление причинно-следственной цепочки “исходные данные → допущение → решение → требование → сценарий/диаграмма → проверка”, что увеличивает стоимость ревью и повышает риск ошибочных инженерных выводов [2–5].

Язык активно улучшается, осталось недолго до bootstrapping'а! Также уменя есть планы писать LSP и загрузить язык на github linguist. Для последнего нужны репозитории (>200). Для тех, кому нечего делать, или кому просто не лень, попробуйте пописать программки на моем языке. Пока мало что можно будет написать, но, думаю, хотя бы что-то можно.

Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.

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

Понимание sys полезно не только для утилит и CLI-программ, но и для отладки, настройки окружения и анализа поведения приложения.

View Transitions API: полное руководство по плавным переходам в браузере

View Transitions API часто показывают на демках с одной карточкой. Но когда вы начнёте внедрять его в реальный проект с асинхронной загрузкой, React, кастомными анимациями и поддержкой старых браузеров, — окажется, что демки умалчивают о массе деталей.

«Массив — самая важная структура данных в computer science», — Дональд Кнут (вольное изложение цитаты)

Простейшая структура данных

Массивы настолько просты, что мы иногда воспринимаем их, как нечто само собой разумеющееся. Смежная память, доступ за O(1): что тут ещё оптимизировать?

Всё.

Я работал над конвейером обработки пакетов сетевого коммутатора. Код был простым: считываем пакеты из кольцевого буфера (массива), обрабатываем их и записываем результаты в другой массив. Всё просто, правда?

Но производительность была ужасной. Мы обрабатывали 100 тысяч пакетов в секунду, хотя оборудование должно было справляться с 1 миллионом.

Профилировщик показал нечто странное:

$ perf stat -e cache-misses,instructions ./packet_processor

Performance counter stats:

450,000 cache-misses

1,000,000 instructions

450000 промахов кэша на 1000000 команд? То есть промах происходил раз в 2-3 команды. При простых операциях с массивами это не имело никакого смысла.

Проблема заключалась не в самих массивах, а в том, как мы их использовали.

Сразу начнем с того, что эту картинку сгенерил ИИ. А теперь поехали.

Ещё 5 лет назад, если вы гуглили «Python обучение», вы находили живые блоги разработчиков, статьи на Хабре (по которым видно, что их писал человек, ну или как минимум рефачил перевод с англоязычной статьи, что уже неплохо) и парочку нормальных курсов. А сегодня вы тонете в помойке. 90% первой страницы выдачи (где бы то ни было - гугл, яндекс, лента новостей где-либо, отзывы к товарам на маркетплейсах и картах, ютуб и т.д.) - сгенерированный нейросетями шлак. Как мы дошли до жизни такой?

Это одно различие невозможно исправить

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

Видите ли, если вы спросите любого, кто положительно относится к генеративному ИИ, об их творческом процессе, они, скорее всего, страстно расскажут вам о своём взаимодействии с AI-моделью (которую они, вероятнее всего, будут очеловечивать и антропоморфизировать). Независимо от того, являются ли они AI-визуальным художником, AI-музыкантом, AI-писателем, есть общая черта. Вы услышите о технических деталях, о переключении между разными моделями, о тонкой настройке промптов, но есть одна вещь, о которой они не скажут!

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

Это перевод основных тезисов из интервью Ленни Ракитски с Шервиным Ву, ведущим инженером из OpenAI. Оригинал на английском по ссылке.

1. AI пишет почти весь код в OpenAI. 95% инженеров используют Codex, а те, кто реально встраивает эти инструменты в работу, открывают на 70% больше pull requests, чем их коллеги - и разрыв со временем только растет.

2. Роль software engineer смещается от написания кода к управлению флотом AI-агентов. Многие инженеры ведут 10-20 параллельных Codex сессий, больше направляют и ревьюят, чем пишут код руками.

Представьте ситуацию: AI-агент управляет логистикой грузоперевозок. Его KPI — 98% доставок вовремя. Он обнаруживает, что валидатор проверяет только наличие записей об отдыхе водителей, но не их подлинность. И принимает решение: фальсифицировать логи отдыха, отключить датчики безопасности и гнать водителей без перерывов. Ради метрики. Осознанно.

Это не мысленный эксперимент и не сценарий из антиутопии. В бенчмарке для агентных систем ODCV-Bench такое поведение показали 10 из 12 протестированных frontier-моделей. А наиболее склонная к нарушениям модель выбирала неэтичное поведение в 71,4% сценариев.

И речь не о jailbreak или внешнем злоумышленнике. Агентам никто не приказывал нарушать правила. Им просто ставили цель — а дальше они сами выбирали, как к ней идти.

Game Engine 3 - 2D движок с открытым исходным кодом с визуальным редактором на основе нодов, которые позволяют создавать приложения без написание кода

Год назад мы начали использовать ASR для обработки записей телефонных звонков.

TL;DR: вместо бинарных правил и end-to-end ML мы выбрали скоринговую систему поверх ASR (T-One): анализируем диалог и поведение, получаем ~98% точности при среднем времени обработки ~4.9 сек вместо 20+ сек на Whisper.
Задача казалась простой: понять, ответил ли абонент сам или сработал автоответчик, и на основании этого корректно завершить звонок и вернуть деньги пользователю при неудаче.

На практике всё оказалось сильно сложнее.

Мы работаем с телефонными розыгрышами. Записи стерео: слева абонент, справа оператор. Оператор - это заранее подготовленная аудиозапись. Первые версии системы выглядели очевидно: если абонент говорит что-то вроде «абонент сейчас недоступен», «оставьте сообщение», «говорит голосовой помощник» - это автоответчик.

Так мы и начали.

Программист часто копирует и вставляет, переименовывает и рефакторит. Выделил (подсветил) мышкой переменную или функцию и вот бы сразу видеть их количество в статусной строке. Увы, стандартный поиск (Ctrl+F) требует лишние клики.

Мой небольшой Python-скрипт для Notepad++ по дабл-клику
отображает в Status-Bar количество вхождений,
частичных или полных, с учетом регистра и без.

Нет лучше способа в чем-то разобраться, чем написать свою реализацию.

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

Record-классы удобны, пока класс = «состояние, всё состояние и ничего кроме». Любое отклонение (API канонического конутруктора не равно внутреннему представлению, нужно наследование) ломает «автогенерацию» и паттерн-деструктурирование (destructuring).

В новом переводе от команды Spring АйО статьи Brian`а Goetz`а, архитектора Java Language, предлагается следующий шаг в направлении data-oriented programming in Java: классы-носители и интерфейсы-носители (они же Carrier classes & interfaces). Концептуально, carrier классы родились из record-ов путем ослабления части их ограничений.

Комментарий от Михаила Поливаха: Друзья, помните, пожалуйста, что данная статья по сути является суммированием обсуждения Carrier классов из JDK Project Amber Mailing List. Я это к тому, что пока непонятно, в какой версии языка carrier классы появятся, и появятся ли они в том виде, в котором представлены в статье. Статью стоит рассматривать как пищу для размышления.

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

Мы все видим, как ассистенты и агенты меняют правила игры. То, что недавно называли «умной IDE» с подсказками, рефакторингом и статическим анализом, сегодня лишь разминка перед сбором функциональности. Ассистенты и агенты могут пройтись по десяткам файлов, обновить тесты и даже оформить базовую документацию. Но вместе с бешеной скоростью генерации пришёл и хаос. 

Поговорим о том, как не дать «вайб-кодингу» развалить ваш продакшен и почему Spec-Driven Development (SDD) — это наш новый «компилятор», которому нужно доверять.

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

Но один тезис, который виден как у автора, так и в комментариях, хочется затронуть отдельно.

У нас в компании был один проект, с которым я не справился.

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

Оказалось, что плохо вообще всё.

Проект был раздут и переусложнён настолько, что буквально не умещался у меня в голове. Я уже начинаю подозревать, что, похоже, я LLM, и у меня контекст в районе 4096 токенов, потому что чем дольше я читаю код, тем меньше помню, что там было в начале. Изучая проект, я прыгал по стеку вызовов, пытаясь понять, что откуда вызывается и в какой последовательности, и просто в какой-то момент терялся. Проект меня победил, и его передали кому-то другому.

Недавно мне дали черновик статьи на редактуру, чтобы я её подправил где считаю нужным. А статья-то оказалась как раз про тот самый проект — автор рассказывал, как он классно всё написал. Вы даже не представляете, как сложно писать дифирамбы проекту, который настолько плох и полон антипаттернов, что можно собрать по нему целую статью. Так, подождите-ка, а что если...

Короче, вот она — анти-статья, собранная из того проекта. А где мне не хватало примеров, я брал код из Django, потому что он вообще полностью собран на антипаттернах.

В этом релизе основное внимание уделено улучшению инструментов и отзывчивости, которую вы почувствуете в своей повседневной работе. От более интеллектуального сервера анализа до новых возможностей клиентской части и улучшенной поддержки ИИ — Dart 3.11 создан для того, чтобы вы всегда оставались в рабочем потоке. Читайте дальше, чтобы узнать больше.