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

Программирование — это редко про «написать кнопку». Чаще это попытка перевести хаос бизнес-процессов, привычек пользователей и странных требований в систему, которая должна работать стабильно. В статье — реальные истории из легаси, enterprise и автоматизации: DOS-мышление в вебе, Excel как основа бизнеса, реверс-инжиниринг без документации и почему иногда лучший аналитик — оператор с цифровым блоком клавиатуры.

Исключения рождаются не только в основном коде, но и в обработчиках этих самых исключений. Зачастую вопросу не уделяется должного внимания. Действительно, что может пойти не так в блоке catch? Там ведь код тривиальный! Но это только на первый взгляд.

Например, безобидный LOG.warn("...") выливается в десяток вызовов нижележащих методов. И чем больше «наслоений» в библиотеке логгирования, тем выше вероятность сбоя. Всё бы ничего, если бы не одна особенность языка Java…

Плагин для JetBrains-IDE, который встраивает полноценный Telegram прямо в редактор. Плюс шифрованный шеринг кода, подсветка синтаксиса в теме получателя и магия с метаданными в обычном тексте сообщения. Разбираю изнутри.

Привет, Хабр! Архитектура ПО — это фундамент, на котором строится предлагаемый пользователю продукт. И если этот фундамент даёт трещину, последствия могут быть катастрофическими.

Меня зовут Евгений, я являюсь ведущим экспертом в области информационной безопасности компании ИнфоТеКС. В этой статье я разберу шесть архитектурных антипаттернов в рамках системного подхода к проектированию и покажу, как их избежать, либо оперативно исправить. Эти знания помогут улучшить качество продукта, сэкономить нервы, время и ресурсы — как свои, так и Компании.

Я три года пилю Telegram-бот для одного B2C-продукта. В пятницу вечером маркетолог попросил убрать запятую — я потратил двадцать минут на одну запятую, потому что текст был размазан по семи питон-файлам. И тут меня переклинило. Так появилась библиотека, где все диалоги бота живут в одном YAML — с клавиатурами, медиа, условиями и опциональной очередью под лимит Telegram. Выложил на PyPI, делюсь.

Когда программист впервые слышит слово «архитектура», он обычно представляет что-то скучное: диаграммы, стрелочки, коробочки, совещания на три часа и человека, который запрещает писать код.

А потом проходит несколько лет.

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

Добавили одну кнопку — сломался импорт. Поменяли отчёт — умерла авторизация. Обновили библиотеку — перестала открываться половина форм.

И начинается археология.

Почему так происходит?

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

В Kotlin деструктурирование выглядело так: val (name, age) = person. Но компилятор берет значения не по именам, а по позиции component1/component2.

Отсюда проблемы. Если поменяли порядок параметров в data class или сделали age вычисляемым свойством: то та же строка начинает доставать другое поле. Причем иногда код даже скомпилируется, но, конечно, смысл изменится: val (age, name) = person.

И вот теперь Kotlin эксперементально переводит круглые скобки на деструктурирование по имени. Синтаксис будет такой: (val name, val age) = person. И порядок внутри скобок не важен. Переименование явно: (val years = age, val theName = name) = person.

Позиционное же деструктурирование остается, но переезжает в квадратные скобки для Pair/Triple и коллекций: val [x, y] = point.

Разбираемся полностью в новом переводе от команды Spring АйО.

Более тридцати лет назад норвежские разработчики Ховард Норд и Эйрик Чамбэ-Энг создали Qt — фреймворк, которому суждено было стать стандартом де-факто для кроссплатформенной разработки. Широкому распространению Qt во многом способствовал Маттиас Эттрих: основатель проекта KDE выбрал его в качестве фундамента этой среды, а затем занял руководящую позицию в команде разработчиков Qt. А уж тем более трудно было предвидеть, что у Qt появится свой «летописец» в России, книги которого разойдутся тиражом более 25 000 экземпляров.

Вот как сам Эттрих напутствовал читателей в первом издании книги Макса Шлее:"Давайте начнём с вымышленной истории. Представьте, десять лет назад кто-то пришёл ко мне и спросил: «Возможно ли написать многофункциональное графическое приложение, а затем скомпилировать и запустить его на всех основных операционных системах? На Linux, на UNIX, на Windows и на Macintosh?» Тогда — будучи молодым прграммистом — я, вероятно, ответил бы: «Нет, это невозможно. А если бы и было возможно, то система была бы очень сложной в использовании и ограниченной самой слабой платформой. Лучше выберите одну платформу или напишите свой код несколько раз». Несколько лет спустя я открыл для себя Qt — и понял, как сильно я ошибался! Qt делает настоящую кроссплатформенную разработку реальностью, не ограничивая ваш выбор и творчество. Слишком хорошо, чтобы быть правдой? Не верите? Что ж, доказать легко. Я передаю слово Максу, который расскажет вам, как именно это делается. Макс, твой выход.

В прошлой статье я поделился своими наработками в области работы ИИ с CAD-программами (в моём и нашем случае, SolidWorks). В этот раз поделюсь практическими результатами на примере тестового ядра своей программы.

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

200 задач. 248 тысяч тестов. Девять моделей, среди них всё свежее: Opus 4.7, GPT 5.4, Gemini 3.1 Pro, Sonnet 4.6. На SWE-bench те же модели берут 70 % и выше. На ProgramBench — ноль полного резолва. Лучший «почти решено» у Opus 4.7 — 3 %. У остальных и того нет. Это новый бенчмарк от Meta Superintelligence Labs, Stanford и Harvard (2026). Агенту дают скомпилированный бинарь и описание программы. Никаких сорсов, никакой декомпиляции, никакого интернета. Задача — собрать программу с нуля так, чтобы она прошла 248 тысяч поведенческих тестов. Это не «пофиксить баг в существующем коде» (как SWE-bench) и не «дописать функцию по сигнатуре» (как HumanEval). Это другой ТИП задачи: спроектировать систему. Внутри — методология, паттерн результатов (что модели вытягивают, а что нет), и почему этот ноль — на самом деле важная новость для тех, кто строит на LLM продакшен.

Вот с детства меня ругали родители: «Хватит читать книжки про программирование и писать код на листочках бумаги. Посмотри в окошко, познакомься и пообщайся с людьми, посмотри, какие девочки красивые». Кто‑то всю жизнь будет учиться играть на музыкальном инструменте и, если повезет, и у него есть талант, научится играть хорошо. Кто‑то будет изучать иностранные языки и, если повезет обладать талантом, выучит несколько. А если будет таким же тупым как я — с трудом будет осваивать один английский несколько лет подряд.

А что может Opus 4.7 с контекстным окном в миллион?

Помните время, когда искусственный интеллект был простой говорящей головой? 

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

Хочешь, чтобы ИИ прочитал лог-файл? Пиши кастомный плагин. Хочешь, чтобы он сделал простой запрос в базу данных? Садись и пиши очередной адаптер. Каждая новая интеграция требовала написания отдельного, уникального кода. По сути, приходилось соединять зоопарк различных ИИ-моделей с бесконечным множеством баз данных, API и сервисов, собирая костыльные решения на ходу.

И так продолжалось бы еще долго, если бы не одно событие.

Но 25 ноября 2024 года компания Anthropic представила Model Context Protocol (MCP). И, честно говоря, это событие полностью изменило правила игры.

Сотня рекомпозиций в секунду при скролле — это приговор. Приговор батарее устройства, плавности анимаций и вашей репутации как инженера. Мы привыкли мыслить высокоуровневыми абстракциями: закинуть LazyColumn, добавить пару Modifier.padding и отправить в продакшен. Но что делать, когда стандартные компоненты начинают "захлебываться", а Layout Inspector горит красным от избыточных отрисовок?

Очередной рассказ про вайбкодинг, про то что Kotlin Native на что-то годится и в целом может потягаться с Go, пиар моего бота и история неуспеха.

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

Начинающим разработчикам строки обычно кажутся едва ли не самым простым, что есть в языке программирования. Возможно, причина в том, что знакомство с новым языком зачастую начинается с вывода на экран строки Hello, world!.

«Это же просто набор символов, заключённый в кавычки!» — обычно восклицает джуниор Python-разработчик.

Но в Python всё немного интереснее. И за простым синтаксисом скрывается большой набор возможностей, правил и нюансов. Более того, если посмотреть внимательнее, окажется, что в Python целый зоопарк строковых представлений и связанных с ними особенностей.

Привет, я Евгений Бартенев, автор и техлид курса «Python-разработчик» в Практикуме. В этой статье последовательно разберу, какие бывают строки в Python, чем они отличаются друг от друга, какие возможности дают и какие подводные камни могут встретиться в работе с ними. Поговорим и о базовом использовании, и о важных деталях, которые стоит помнить каждому разработчику.

ИИ-тесты - это один из самых простых, эффективных и надёжных методов использования искусственного интеллекта в компаниях и организациях. В статье рассмотрим реальный кейс, и на примере простого промпта сгенерируем тесты для проверки знаний правил habr.

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

Ответы словами vs галочками: ИИ возвращает проверку знаний к временам, когда тестов не было и нужно было понимать суть, а не запоминать правильный вариант ответа.

Когда человек приходит в программирование, он думает, что главное — выучить язык.

Python. C#. Java. Go. Неважно.

Кажется: выучил → стал программистом.

Нет.

Язык — это самая простая часть профессии.

Я сравнил Codex 5.3, Claude Opus 4.6 и GPT-5.5 на реальном многомодульном Java-монолите: скопировал проект в отдельные ветки, дал агентам похожие задачи и прогнал их через цикл правок, ревью и e2e-тестов.

Результат: чем дешевле - тем лучше результат.

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