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

Задача Эдсгера Дейкстры о философах – великая задача великого программиста. Уж сколько лет, а она актуальна. Решая ее, прикасаешься к этому величию. И вот, перефразируя известное, «давно не было такого и вот опять», можно познакомиться с ее «новым прочтением» на Хабре[1].

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

Познакомился с проблемой обедающих философов – Dinning Philosopher Problem (DPP), я более двадцати лет тому назад (про DPP см. [2]). Результатом стала статья, в которой философы выполняли поставленную задачу, как минимум, не хуже, чем классические алгоритмы сортировок[3]. Позднее был сделан доклад на конференции по параллельным вычислениям в Саратове, где на суд научной общественности была предъявлена модель автоматных параллельных вычислений и пример ее приложения - задача Дейкстры[4].  

Замечание 1. В рамках обсуждения статьи на Хабре было проигнорировано  предложение поручить сортировку философам. Зря, конечно, т.к. надо же как-то убедиться, что предлагаемое решение работает хотя бы в первом приближении. К примеру, тот же DeepSeek, моментально выдавший свое решение DPP, так и не смог заставить их сортировать.

Не знаю, считается ли данная задача решенной, но то, с чем я знаком, по большей части беглое рассмотрение проблем, которые она отражает. У задачи есть теория, которая представлена монографией Хоара[5], или моделями сетей Петри у Питерсона[6] и В.Е. Котова[7] или другими подобными публикациям. Но, повторюсь, все это по большей части достаточно краткий анализ свойств модели и/или даже конкретного решения. Статья на Хабре из этой же серии. Все это ни как не окончательное решение описываемых ею проблем параллелизма. Правда, может, [авторами] вопрос так и не ставился, но все же ответ на него весьма желательно иметь.

Пятая статья в серии о DOM-подобных моделях данных в разных языках программирования.

В предыдущих частях мы разобрали DOM-подобные структуры данных, оценили их поддержку в ряде языков с помощью бенчмарка CardDOM и сравнили их реализацию в JavaScript. и С++, Rust и D-lang (а также упомянули Zig, Odin, Jai, Python, V, Cone и Pony).

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

Посмотрим, как с этой задачей справляется Argentum — язык, для которого такие структуры данных являются нативными.

История о том, как наша команда смогла ускорить релизы, снизить затраты и построить масштабируемую архитектуру без хаоса. В статье вы узнаете, подходят ли вам микрофронтенды.

Это довольно короткая статья, целью которой является пояснение того, что вообще такое "модуляризация" Spring Boot, почему она появилась и откуда, собственно, ноги растут.

Для многих Spring Boot это просто автоконфигурация. Само собой Spring Boot гораздо шире и включает в себя в том числе ещё и

Spring Boot Actuator

Spring Boot DevTools

Spring Boot Tools и т.д.

Команда Go for Devs подготовила материал о том, почему попытка тащить в Go привычные ОО-паттерны часто заканчивается печально, а вот разделение интерфейсов — наоборот, работает почти магически. Разберём, как маленькие интерфейсы избавляют от «интерфейсного ожирения», упрощают тесты и делают код гибче, даже если вы никогда не читали SOLID. А заодно посмотрим, почему огромный S3Client — это архитектурный антипаттерн, замаскированный под благо.

Любую программу можно написать различными способами, и она будет как-то работать, иногда даже правильно. Но лучше все-таки в своем коде определенных конструкций избегать, чтобы не возникало последующих проблем. Эта статья предназначена для начинающих разработчиков на C++, и в ней мы рассмотрим несколько вредных советов по написанию кода и пояснений, почему так делать не нужно.

Команда AI for Devs подготовила перевод статьи о том, почему увлечение MCP-серверами может быть избыточным. Автор показывает на практике: во многих сценариях агенты справляются куда лучше, когда работают напрямую через Bash и небольшие скрипты, без громоздких серверов, длинных описаний и лишнего контекстного шума.

Когда в 1991 году Гвидо ван Россум представил миру Python, никто не мог предсказать, какое место через несколько десятилетий этот язык займет в веб-разработке, Data Science и Machine Learning. Сейчас Python продолжает развиваться: с новым поколением инструментов в прошлое уходят традиционные ограничения — производительность, GIL и сложность параллельных вычислений. 

Привет, Хабр! С вами Леша Жиряков, я руковожу бэкенд-направлением витрины KION, возглавляю гильдию по Python и пишу для блога MWS на Хабре. Я каждый день сталкиваюсь с вызовами высоконагруженных систем и сформировался пул инструментов, которые помогают решать критические проблемы современной разработки — от обработки данных с Polars до управления зависимостями с UV. 

В этом материале я сделаю обзор Python-библиотек, с которыми можно создавать системы, сравнимые по производительности с Go и Rust. 

На днях вышла новая версия GigaIDE Community Edition. Долгожданное обновление, которое помимо обновления базовой платформы до IntelliJ 2025.1 и мультиагентной системы на базе GigaCode, имеет собственный маркетплейс плагинов. Особенно стоит отметить, что команда GigaIDE пошла по пути максимальной открытости и добавила возможность переключаться между различными маркетплейсами прямо в интерфейсе GigaIDE.

Вы когда-нибудь хотели взглянуть на свой код под новым углом? Например, увидеть, как бы выглядела ваша кодовая база, будь она городом? Звучит как что-то невероятное. Давайте вместе заглянем в город PVS-Studio и просмотрим, какие тайны он в себе хранит :).

CryEngine2 использовал класс собственный CString для реализации работы со строками и немного использовал строки из стандартной строковой библиотеки Windows. Насколько я помню, последняя версия CryEngine всё ещё использует те же самые CString, она кардинально поменялась внутри, но как дань истории название класса менять не стали, зато сильно расширили функционал. Я не на 100% уверен, применялся ли CString только в редакторе или в рантайме игры тоже, вы можете сами это посмотреть в исходниках, которые все еще доступны на гитхабе. Это один подход к работе со строками, довольно распространенный в мире игростроя - когда мы все нужное пишем сами, не оглядываясь... хотя, тут больше уместно слово поглядывая, на существующие реализации и утаскивая в проект все самое лучшее.

Есть и другой подход... Я работал в команде над некоторым проектом, который должен был выйти на консолях, и в какой‑то момент на проект пришел эффективный тимлид, который хорошо умел в красивые презентации, и продавил использование std::string из sdk. Все очень опытные программисты, синьоры и руководство важно кивали на совещании и согласились всё перевести на std::string… не такие уж они оказались опытные, как выяснилось. В итоге мы заменили большую часть CString на std::string. Не сказал бы, что это сильно повлияло на время компиляции — плюс‑минус минута к проекту, который собирается двадцать минут, особой погоды не делают, но это также превратило наш довольно понятный базовый код в запутанный кошмар. Возможно, для переносимости это было лучше, но ни наш проект, ни CryEngine2 Editor так и не были портированы ни на Linux, ни на какую‑либо другую платформу.

Прошло десять лет, я вижу ровно туже ситуацию на текущем проекте — новый тимлид решил перевести местный MySuperPupeString на std::string, уже предчувствуя «нижней чуйкой» последствия — запасаюсь попкорном и беру отпуск на следующий месяц после принятия решения. Но не это интересно, а то — какие вообще строки могут быть в вашем с++ коде.

Так получилось, что свою карьеру я начинал сразу в ИТ, но был скорее теоретиком. По образованию я - математик, а это значит, что в университете меня учили доводить задачи ровно до той стадии, когда "далее все понятно, и реализация представляет чисто инженерную сложность".

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

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

Команда Python for Devs подготовила перевод статьи о том, почему автору SQLAlchemy нравится… но не настолько, чтобы не попробовать создать собственный ORM. SQLORM ― минималистичный, прямолинейный и честный: никакой магии, никаких скрытых Unit of Work, максимум контроля над SQL и минимум связности с сессией.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

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

Привет, Хабр!

Сегодня поговорим о том, как на практике построить высоконагруженный обратный прокси-сервер на основе YARP, отличной библиотеки от Microsoft для .NET.

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

Три основных типа карьерных самосвалов в России

В российской добывающей отрасли применяются три доминирующих класса машин, каждый из которых имеет собственные особенности измерения веса:

Классические карьерные самосвалы с жёсткой рамой, такие как БелАЗ 7555–7513 и CAT 777–793, оснащаются гидропневматической подвеской с датчиками давления. Эти датчики служат для оценки веса полезной нагрузки через измерение давления в подвеске. Однако их данные сильно зависят от темпа движения и амплитуды раскачки кузова, что создает шумы и неточности при динамическом движении. В качестве инженерного дополнения к измерению веса для таких моделей важно применять алгоритмы фильтрации и компенсации динамических колебаний, а также дополнять данные от датчиков давления весовыми сенсорами, установленными на шасси, для повышения точности оценки нагрузки и снижения влияния факторов движения. Для БелАЗ и CAT, реализованы высокоточные системы взвешивания с погрешностью в диапазоне до ±0,1–1%. Однако, из-за сильных вибраций и динамических пиков в процессе работы, количество данных с аномальными колебаниями составляет примерно 20–35%. Благодаря строгой конструкции и стабильной гидравлической и электронной схемам, такие системы обеспечивают относительно меньшую дисперсию и более предсказуемую точность, особенно при использовании фильтров и компенсационных алгоритмов.

Команда Go for Devs подготовила перевод материала о том, как изменилась экосистема Go к 2025 году. Рост числа профессиональных разработчиков, смещение баланса между веб-фреймворками, развитие инструментов тестирования, взлёт AI-редакторов и укрепление позиций Go в корпоративных и инфраструктурных командах — язык уверенно взрослеет и расширяет своё влияние.

Публикация Allure-отчётов — простая задача, пока не сталкиваешься с ограничениями конкретной CI/CD-системы. Но как опубликовать отчёт, чтобы это было и удобно, и стабильно, и без бубнов?

SDET-разработчик Николай разбирает три подхода — от самого простого до функционально полного. Работа GitLab Pages с историей, Allure Server и Allure Docker Service, а также плюсы, минусы и лайфхаками из практики.

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