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

Property‑тесты умеют находить ошибки на самых неожиданных входных данных. Но настоящая магия начинается после падения теста: вместо списка из сотен случайных значений Hypothesis часто показывает один короткий и предельно понятный контрпример.

Разбираемся, как работает shrinking, почему ручные shrinker'ы плохо масштабируются и за счёт чего Hypothesis умеет минимизировать ошибки практически автоматически.

Ключевые особенности:

Расчёт опорной траектории на 5000 бит всего один раз.
Реактивный расчёт миллионов пикселей на аппаратном double.
При использовании чисел с плавающей запятой двойной точности (порядка ) теория возмущений позволяет приблизиться к уровню - не дальше.
Революционный алгоритм Reference Reset to Zero.
Настоящий SSAA 2x2 для идеально сглаженного изображения.
Параллелизм OpenMP для высокоскоростного многопоточного рендеринга.
Синхронизация через DwmFlush для плавного вывода кадров.
Динамическое вращение палитры для создания классического эффекта.

https://github.com/Divetoxx/Mandelbrot-2#russian

Это Гитхаб с Mandelbrot_AVX2.exe и Mandelbrot_SSE3.exe

А тут полный код на языке С++ - main.cpp

_id в MongoDB кажется мелочью, пока не попадает в API, события и миграции.

Разбираем, когда оставить стандартный ObjectId, когда нужен UUID, почему его лучше хранить как BSON Binary subtype 4 и зачем иногда разделять внутренний и публичный идентификатор.

«Я собрал приложение за вечер. Разработчики больше не нужны».

Лента забита такими постами, но мало кто показывает продолжение этих историй. А оно бывает ярким: от продовской базы, снесённой AI-агентом, до взлома на второй день после запуска.

По красивой картинке больше не понять, кто её собрал — инженер или человек, который научился красиво писать промпты. Разбираемся, почему рынок ослеп, при чём тут верстальщики на Tilda и что с этим делать бизнесу и инженерам.

В этой статье я расскажу, на какие подводные камни я споткнулся при разработке своего пет‑проекта — мониторинга сайтов на Golang, аналог UptimeRobot.

Начнем издалека... Я хотел разработать пет‑проект, но не банальный todolist, а что‑то свежее, интересное в плане архитектуры и реализации. Шерстя по просторам интернета, я наткнулся на UptimeRobot — сервис для мониторинга сайтов. Азарт и любопытство взяли верх и я начал продумывать, как буду разрабатывать «свой» UptimeRobot. Думал — делов на пару недель от силы. Ведь принцип прост: дергать URL по таймеру и проверять код ответа и всё. Но на практике все оказалось намного сложнее, чем я изначально представлял...

Код работает, тесты зелёные — а читать его невозможно.

Документация «содержит всё» — а в голове после неё не остаётся ничего.

Привычный диагноз «плохо обучили» объясняет не всё: человек и LLM мыслят по-разному устроенными механизмами, и значительная часть «низкого качества» — это столкновение двух когнитивных архитектур.

Где на самом деле предел внимания LLM, почему у человека сложность болит, а у модели нет, и кто в системе «человек + LLM» заметит момент потери контроля.

Спойлер: никто.

Привет, Друзья!

Хотел написать короткий пост по мотивам одного казалось бы простого ПР-а, который мы недавно получили в рамках Axelix: Open Core продукта для решения основных известных болей при разработке Spring Boot приложений (кстати, give us a star!).

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

Я не буду погружать вас в детали того, что мы делали, просто покажу на абстрактном примере.

Давайте с места в карьер. Посмотрите на этот код:

BGPLite — open-source BGP route-server на C# и .NET 10. Он принимает BGP-сессии, динамически загружает префиксы через RIPE Stat и управляется через HTTP API. В статье разберём архитектуру проекта и реализацию собственного BGP-сервера с нуля.

После выхода первой части прошло 2 месяца, и наши многоуважаемые американские партнёры из Anthropic и Google что-то подхимичили, и новые версии Claude Code и Antigravity перестали работать.

А так хочется попробовать новые чудо-модели типа Fable 5 и Opus 4.8! Поэтому нам придётся осваивать новые хитрости для настройки VPS, чтобы быть на острие прогресса.

Приветствуем, уважаемые читатели! На связи Олег Сивченко @OlegSivchenko.

Пару месяцев назад мы анонсировали выход русскоязычного издания знаменитой в узких кругах книги Дениса Бахвалова, которая в оригинале называется «Performance Analysis and Tuning on Modern CPUs» или просто «perf-book». Теперь она, наконец, в продаже и на полках магазинов. Русское издание называется «Оптимизация производительности современных процессоров. 2-е изд.». Это один из моих наиболее сложных, выстраданных, многоэтапных и при этом ценных проектов за последние четыре года. Уверен, он бы не состоялся без активного участия автора, его искренней заинтересованности и содействия в редактуре, проверке терминологии и в целом качества перевода, а также при составлении глоссария.

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

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

Модели класса Mythos (такие как Claude Fable 5) изменили рабочий процесс многих из нас в Anthropic. Хочу поделиться двумя советами, как работать с этим классом моделей эффективнее.

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

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

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

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

И тут появляется ChatGPT. Вопросы теперь задаются не в StackOverflow или гугл, а напрямую в нейронку, где ты сразу получаешь ответ. Да, он не идеален, местами нарушает все правила хорошего кода одновременно, но все же работает. Ты тратишь дополнительное время на его улучшение, но общее решение все же принимаешь. Хороший инструмент!

Салют, Хабр!

Я Марк, Android-разработчик, работаю над мобильным приложением для управления умным домом Салют. Для мира Android-разработки вопросы архитектуры, её надёжности и качества актуальны, но… на самом деле не так уж интересны. Интересно, чтобы приложения были надёжными, устойчивыми к ошибкам, поддерживаемыми и легко масштабируемыми. Самый популярный подход — по-прежнему архитектурные паттерны (MV* паттерны) и разделение архитектуры по слоям. Что никак не избавляет от ошибок.

При этом существует множество подходов, которые делают архитектуру надёжнее, а в перспективе исключают целый класс ошибок, как введение в Котлине Null Safety избавило от класса ошибок NPE. Это проектирование на основе состояний (state-oriented programming), логика Хоара, программирование по контракту Бертрана Мейера. Возможно, и более серьёзные — например, формальные методы верификации. Отмечу, что в целом это общие принципы computer science, независимые от платформы. Но мой фокус — Android-разработка клиент-серверных приложений.

Сейчас хотел бы поговорить, как создание своей системы типов в проекте исключает популярный класс логических ошибок — semantic type error. Поехали!

Всем привет, меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

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

В какой-то момент я сказал себе: «Стоп. Хватит. Пора уходить в компанию, где всё организовано правильно». Мне казалось, что там не будет хаоса, бессмысленных авралов и вечной гонки за дедлайнами.

Ну что могу сказать - я попал.

Только вот ожидания и реальность оказались совершенно разными.

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

Всем привет! Я Дмитрий Милов, Python-разработчик компании МУЛЬТИФАКТОР в команде продукта MULTIDIRECTORY, мы разрабатываем собственную службу каталогов.

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

Почему продолжается путаница в концепциях, которые давно описаны и формализованы?

В реактивной системе все состояния связаны друг с другом инвариантами в единый граф. Когда мы изменяем что-то с одной стороны этого графа, рантайм обеспечивает каскадный пересчет зависимых состояний. Такие последовательности пересчетов — это ничто иное, как потоки информации (data-flow). Чем прямолинейнее эти потоки, чем меньше они разветвляются и затрагивают состояния, не относящиеся к изменениям, тем эффективнее работает система. И здесь есть два подхода к оптимизации потоков информации…

Она умерла в воскресенье вечером, и никто не услышал ни звука. Детективная история о том, как поставить прослушку на собственное приложение: Prometheus, Grafana, Micrometer, алерты, SLO. Все улики в комплекте, демо-проект прилагается. Совпадения с вашим продакшеном не случайны.

Мне было интересно проверить GigaChat/GigaCode не в обычном чате, а в нормальной агентной среде разработки. То есть не “ответь на вопрос”, а вот это всё: tools, function calling, streaming, MCP-инструменты, история диалога и работа внутри реального проекта.

Для проверки я подключил GigaChat к OpenCode через TypeScript-плагин. Простой текстовый запрос завёлся быстро, а дальше началось самое интересное: OpenAI-like API оказался похожим на совместимый агентный протокол только снаружи. Внутри пришлось собирать отдельный слой совместимости.

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