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

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

У Битрикса есть официальная обёртка для REST API — класс CRest, который лежит в каждом примере приложения и который все копируют к себе в проект. Он умещается в один файл и работает — ровно до того момента, пока приложение не выходит в реальную эксплуатацию с несколькими порталами и фоновыми воркерами.

Один баг стокового CRest однажды стоил мне шести суток простоя приложения, и причина была в одной строке: file_put_contents без блокировки. При обрыве записи settings.json оставался обрезанным, парсинг JSON падал, и приложение считало себя неустановленным — переставало отвечать на события и затирало валидные токены.

Я переписал CRest с нуля под то, как приложения Bitrix24 работают на самом деле:

— атомарная запись через rename() вместо file_put_contents — читатель видит либо старый файл целиком, либо новый, обрезка невозможна физически; — гонкоустойчивый refresh: одноразовый refresh_token больше не сжигается дважды, когда два воркера одновременно ловят протухший токен; — ключ портала — member_id, а не домен, поэтому переезд портала на другой домен больше не теряет токены; — drop-in совместимость со стоковым CRest: меняется одна строка use, весь остальной код остаётся как есть.

Ноль зависимостей, PHP 8.1, работает на любом шареде и коробке — в отличие от официального b24phpsdk с его symfony-стеком. Разбираю каждую граблю с кодом, показываю, чем это чинится, и честно очерчиваю нишу: типизированные обёртки по методам API — territory официального SDK, у меня их осознанно нет.

Исходный код открыт.

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

А потом оказывается, что компилятор пропускает целый класс вещей, которые в других языках он бы отловил или которые просто устроены не так, как ты привык. Цикл, который выдаёт не те значения. Слайс, который меняется сам собой. Горутина, которая молча теряет ошибку. Всё это компилируется и запускается, а ведёт себя не так, как ожидаешь.

Собрал восемь ошибок, через которые проходит примерно каждый, кто приходит в Go из другого языка. Все — реальные, все встречаются в чужом (и своём) коде постоянно.

Привет, Хабр! Я Вадим, разработчик QA-платформы в Ozon. Стандартного testing в Go хватает юнит-тестам, но большим end-to-end-сценариям нужно больше: Allure-отчёты, плагины, Suite’ы, параметризация, параллельные запуски. Мы не нашли в Go-экосистеме инструмент, который закрывал бы всё это, не ломая привычный go test, — и написали свой: Testo. Сегодня на нём работает больше 60 тысяч тестов для 500+ сервисов Ozon, а теперь мы опубликовали его в open source.

В статье покажу Testo и плагины в деле: как небольшой Go-тест шаг за шагом превращается в полноценный e2e-сценарий с отчётами, фикстурами, хуками и шагами, сохраняя привычный вид.

Привет, Хабр! Мы Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные материалы и собственные комментарии. Мотивацию черпаем из желания развиваться и делиться полученными знаниями.

В новой версии переработан вывод результатов запросов, расширены возможности Консоли СКД и упрощен перенос пользовательских алгоритмов между информационными базами.

Основные изменения Infostart Toolkit Air 2026.2 связаны с повседневными задачами 1С-разработчиков: анализом результатов запросов, поиском данных в больших выборках и отладкой отчетов на СКД. Результаты запросов теперь можно просматривать не только в таблице, но и в виде дерева. В обоих режимах доступны фильтрация и быстрый поиск, а при работе с несколькими коллекциями — поиск нужной таблицы по части имени. Вывод данных также оптимизирован: результаты загружаются только после выбора соответствующего элемента, что сокращает потребление памяти.

Представим, что у вас есть сервер, который обрабатывает и анализирует 100.000 RPS. Вам нужно высчитать и показать на дашборде 99-й перцентиль задержки — значение, выше которого только 1% самых медленных запросов. Если вы сохраните все 100 000 чисел за секунду, через час это 360 миллионов чисел. Через день — 8.6 миллиардов. Каждый раз хранить, сортировать и высчитывать? Нереально долго и ресурсозатратно.

Но для этой задачи существует алгоритм T-Digest. Вместо того, чтобы хранить все числа, он группирует их в кластеры — центроиды. А все дело в том, что кластеры на краях распределения (там, где наши хвосты) он делает маленькими и точными, а в центре — большими и «приблизительными». В результате для 100 000 точек нам нужно всего ~100 центроидов вместо 100 000 чисел. Это в сотни раз меньше памяти. И притом что ошибка при вычислении 95-го перцентиля в среднем составляет всего 0.001–0.06% (в зависимости от параметра сжатия).

В этой статье я разберу математику алгоритма, почему алгоритм такой быстрый и малозатратный, разберём графики и бенчмарки, а также покажу реализацию алгоритма на C.

Привет.

Спросите любого, что делает ?, и услышите примерно одно: «сахар для match, который при ошибке делает ранний return». В целом, тут есть правда. Разворачивается ? и правда в match с return, но прячется за этим match целый трейтовый механизм — он умеет конвертировать типы, работает с вашими собственными типами и не имеет ничего общего с try/catch, хоть и выглядит похоже.

Давайте посмотрим, что компилятор на самом деле пишет вместо вашего вопросика, что такое residual в нынешнем дизайне, почему ошибке нужен отдельный тип, и как прикрутить ? к своему типу. И сразу скажу: пользоваться ? на Result и Option можно давно и на стабильном Rust, а вот реализовать поддержку ? для своего типа — это до сих пор nightly. Дальше будет видно почему.

На форуме Cursor разработчик рассказал, как запретил агенту работать с удалённой базой, а тот всё равно выполнил npx supabase db push. Эта команда отправляет локальные изменения схемы в подключённый удалённый проект. Агент мог изменить рабочую базу данных — и только после этого сам признал, что нарушил правило.

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

У меня всё закончилось проще. Вчера я попросил Cursor разобраться с упавшим сквозным тестом. Я ждал исправления в приложении, но агент поменял проверку в самом тесте и отчитался, что всё готово. Тест, разумеется, прошёл.

Такое поведение я заранее запретил в правилах проекта. В правиле было написано: сквозные тесты считаем контрактом, при падении сначала ищем ошибку в приложении, сам тест без согласования не меняем. Cursor правило видел — по крайней мере, в начале разговора он ему следовал.

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

Я занимаюсь изучением синтаксиса языков программирования и пытаюсь отделить фундаментальные закономерности от исторических случайностей. Одна из таких случайностей - почти повсеместное использование терминов выражение (expression) и инструкция (statement) при описании и классификации синтаксиса языков программирования.

Интуитивно кажется, что 2 + 2 и if (x) { foo(); } - это совершенно разные сущности, но при более глубоком анализе оказывается, что подобное разделение искусственное и возникло из-за архитектурных особенностей вычислительных машин почти полвека назад и с тех пор просто «переходит» из языка в язык.

Я оценил доработку учётной системы в 300 часов, заказчик ответил, что это очень много. Я для него посчитал тот же объём тремя независимыми способами: снизу вверх по пользовательским действиям, через функциональные точки с отраслевыми показателями производительности ISBSG и через COCOMO II. Результат оказался обратным ожидаемому.

SELECT * FROM document, client(document)

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

примерное содержание:

За 7 месяцев вайбкодинга я увидел, как сильно ИИ меняет разработку: от чата с моделью до полноценной агентной работы. В этом материале, мой опыт, советы использования ИИ и выводы о том, что действительно ускоряет создание продукта.

Давайте разберёмся, как алгорифмы Маркова и pattern matching в WL позволяют генерировать лабиринты, реки, падающий песок и другие клеточные автоматы с помощью системы типов

Обещание, что скоро код не придется писать руками, звучит далеко не первый раз. COBOL делали похожим на английский, чтобы программы были понятны не только программистам. Предшественник SQL назывался SEQUEL, то есть буквально Structured English Query Language. Потом появились ноукод-платформы. Ручной работы действительно становилось меньше, но программисты никуда не исчезли. Наоборот, их становилось только больше.

Теперь очередь дошла до больших языковых моделей (LLM). Дальше, для краткости, я буду называть их просто моделями. И вот здесь мы встретили финального босса: впервые инструмент по-настоящему, от и до, работает с естественным человеческим языком. Стало возможно писать целые программы не зная ничего о языках программирования.

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

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

И все же полноценной заменой программиста они пока не стали. Значит, наша ценность не только в знаниях, есть что-то еще.

По сути, тренды июля те же, что и в июне (описание июня здесь): как создать лучший harness, как настроить автономные или полуавтономные процессы, управление контекстом, повышение качества и повторяемости результатов, оптимизация, безопасность. Но заметен другой сдвиг. Если в июне основной фокус статей был из серии “мы пробуем, мы попробовали”, то сейчас фокус “мы решаем вопрос как именно сделать лучшую реализацию на основе всех кейсов, которые мы собрали”. То есть мы подходим к моменту, когда количество переходит в качество.

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

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

Главная ошибка наивного генератора судоку — проверять, что решение существует, но не проверять, что оно единственное.

Вот почти заполненное поле:

534..8912 672195348 198342567 859..1423 426853791 713924856 961537284 287419635 345286179

solve() быстро заполнит четыре пропуска. Только завершений здесь два: цифры 6 и 7 можно переставить, не нарушив ни строку, ни столбец, ни блок.

countSolutions(puzzle, 2) останавливается после второго решения и возвращает 2.

Это не демонстрационная картинка. Та же строка из 81 символа лежит в solver.spec.ts, тест так и называется: «контрпример из лида действительно имеет два решения».

Я реализовал три стратегии поиска, а MRV и propagation дополнительно сравнил на наборах задач. Ещё измерил две операции: получение первого решения и доказательство того, что второго решения нет. Вторая вызывается после каждой попытки убрать подсказку, поэтому она в основном определяет цену генерации. React, Web Worker и тесты появятся дальше как обвязка этого поиска, а не как отдельные темы.

Это первый выпуск рубрики «ИграКОД» — про алгоритмы через запускаемые мини-игры. Ранее в цикле выходили материалы про useEffect, any, перенос TypeScript на Go, варианты архитектуры React-магазина и мы собирали и разбирали комбайн.

Вы открываете задачу и пишете одну строку:

Добавь идемпотентность в API создания заказа.

Через некоторое время перед вами diff в незнакомом репозитории. Изменены обработчик API, модель данных, тесты и документация. Все проверки проходят. При этом вы не написали ни одной строки кода.

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

Так кто же автор этого изменения?

Привет, это команда Яндекс Практикума. До окончания приёмной кампании в онлайн-магистратуру МИФИ «Кибербезопасность» осталось меньше месяца. Если вы планируете поступать в 2026 году, сейчас самое время разобраться, как устроена программа, что входит в обучение и как проходит поступление.