Проверка OpenIDE: они этого не хотели, но мы сделали

Если хотите посмотреть, что нашёл статический анализатор PVS-Studio в исходном коде Intellij платформы, используемой OpenIDE, то добро пожаловать в статью.

Искусство создания компьютерных программ

Если хотите посмотреть, что нашёл статический анализатор PVS-Studio в исходном коде Intellij платформы, используемой OpenIDE, то добро пожаловать в статью.

Почти каждый разработчик рано или поздно сталкивается с задачей, когда ему нужно спроектировать такое сложное изменение в системе, которое затронет сразу несколько продуктов или команд. Кроме того, понимание архитектуры программного обеспечения ценится на рынке — ведущие IT-компании стремятся сохранять прежде всего тех, кто понимает, как устроены системы и решения, и способен решать сложные инженерные задачи.
На связи команда курса «Архитектура программного обеспечения» в Яндекс Практикуме. В этом материале мы расскажем, как ответили на запрос рынка и разработчиков и стали готовить инженеров в области архитектуры ПО, а также какие изменения внесли в курс совсем недавно.
Disclaimer: Эта статья предназначена исключительно для образовательных целей и повышения осведомлённости о киберугрозах. Любое использование описанных техник в злонамеренных целях строго запрещено и преследуется по закону.

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

Всем привет! Если вы как и я задавались вопросом "а что там у гуглов", когда находили какую-то новую крутую софтину, смело полагая что если уж есть такое чудо, то у гуглов должно быть что-то еще лучше - то у нас с вами много общего.
И вот сегодня, вместо того чтобы продолжать вайбкодить в клоде, я вдруг вспомнил, что пару месяцев назад слышал что-то про Jules. Тогда меня это не заинтересовало, но недавно где-то еще в комментариях всплыло и я понял что пришло время смотреть агента от гугл.
Все в курсе того, что количество разговоров вокруг ИИ растет с каждым днем. В нашу жизнь вошли такие термины как «вайбкодинг», «промпт-инжиниринг» и другие подобные. Работая в одной из крупнейших ИТ-компаний, я вижу, как в реальности выглядит внедрение ИИ-инструментов для разработчиков. Оно и понятно: эти инструменты обещают кратно увеличить производительность. Но что, по моему мнению, реально будет плотно применяться и являться неким бейзлайном для устройства на работу в ближайшее время?
Во-первых, я не верю в историю "вайб-кодинга", когда человек может вообще ничего не понимать в разработке ПО и пытаться создать какое-то более-менее сложное решение какой-то бизнес-задачи. LLM могут решить задачу, но вопрос качества будет всегда вставать на первое место. Из качества вытекает вопрос безопасности написанного кода. Поэтому мне кажется, что на текущем этапе развития ИИ корпорации не согласятся отказаться от разработчиков. Потенциальные риски принести убытки бизнесу очень велики.
Во-вторых, ИИ ограничивается помещением в контекст определенных участков кода. Это могут быть как небольшие куски кода, когда необходимо поправить ограниченные части функциональности, так и достаточно большие участки. Но тогда LLM сталкивается с тем, что в загруженном контексте достаточно сложно построить правильные связи: между сервисами, брокерами сообщений, базами данных, клиентскими приложениями. На самом деле, это может быть обоюдная вина. Есть легаси, которое никто не поддерживает, а доработки пишут постольку-поскольку или стараются не писать совсем. Есть расхождения между спецификациями — клиентской и серверной (по причине ошибок разработчиков, нежелания или отсутствия процесса актуализации). И всё это породит ещё больший процент ошибок генерации.

Пузырь ИИ - это уже не слон в комнате. Это обезумевший клоун, вооружённый ножом. Его нельзя игнорировать, а если вы попытаетесь, то сделаете это на свой страх и риск. Главный вопрос заключался не в том, лопнет ли пузырь и нападёт ли клоун, а в том, когда это случится. Этот пузырь сейчас столь огромен и так тесно переплетён с нашей экономикой и финансовыми системами (подробнее читайте здесь), что, когда он лопнет, то нанесёт ущерб всему. Поэтому предсказать, когда этот клоун пустится в свой смертоносный разгул, очень важно. Беда в том, что сделать такого рода предсказания также невозможно. Однако за последнюю неделю появились существенные признаки того, что этот пузырь уже начинает лопаться. Возможно, нам и не придётся ничего предсказывать, потому что, похоже, крах уже начался.

Нобелевский лауреат Джеффри Хинтон, которого часто называют «крёстным отцом ИИ» за его гигантский вклад в технологию искусственных нейронных сетей, питающую современный ИИ, в последнее время обрушился с гневной тирадой на Big Tech. От обвинений в корпоративной жадности до подчёркивания опасностей ИИ, он, подобно Пандоре, отчаянно пытается запихнуть судьбы обратно в ящик. Но в недавнем интервью для Bloomberg он выкрутил громкость на одиннадцать, поставив под сомнение саму экономическую жизнеспособность ИИ.
На вопрос Bloomberg, окупятся ли когда-нибудь головокружительные инвестиции в ИИ, Хинтон ответил: «Я считаю, что не смогут», и уточнил: «Я считаю, что для того, чтобы заработать деньги, вам придётся заменить человеческий труд»...

Конечно, существуют и успешные кейсы внедрения ИИ в бизнес, но даже в удачных случаях всё не так гладко. Успешное внедрение всегда сопряжено с множеством оговорок и допущений. Эта статья будет интересна тем, у кого получилось, и тем, у кого не получилось, и тем, кто только собирается внедрить искусственный интеллект в свой бизнес.
Откуда у C‑level берётся представление о розовых единорогах?
Привет, Хабр! В качестве пет-проекта для работы с API и базами данных решил написать своего бота-ассистента. Идея простая: прокси к OpenAI, но с нюансами: хотел разобраться, как работать с относительно новой внутренней валютой Telegram Stars, реализовать собственную систему промокодов и админку без использования громоздких фреймворков, оставаясь на библиотеке telebot (pyTelegramBotAPI).

На дворе уже ноябрь 2025 года, за окном нашей необъятной во многих городах и селах, уже наступила зима, но в инфополе ярко полыхаент схема «купи квартиру, отдай обратно продавец заскамлен был — неведал что творил».
На фоне этих «интересных» событий мне стало интересно изучить техническую сторону того, как это происходит. Анализ множества видео с красно‑белого видеохостинга показал, что залог успешно обмана это момент когда мошенник контролирует ПК или телефон жертвы, заставив ее включить видеозвонок в месенджере или установив специальную программу на устройство.

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

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