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

Современная разработка погрязла в driven, first и based подходах, недавно этот зоопарк пополнился еще одним заморским зверем под названием AI-driven (пусть меня простят свидетели AGI, но я сознательно не выделяю этот подход на фоне остальных и в конце объясню почему). Но не пытаются ли все эти подходы на самом деле решить одну и ту же проблему, известную еще с середины прошлого века, проблему "абстрактного перехода"?

Способности LLM писать код растут очень быстро. А вот инженерные практики вокруг них – заметно медленнее. Поэтому на рынке одновременно существуют две реальности.

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

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

AI-сообщество активно продвигает Skills как новый стандарт для расширения возможностей LLM. Я с этим не согласен. Skills отлично работают как чистая передача знаний — когда нужно объяснить модели, как использовать уже установленный инструмент. Но для подключения к реальным сервисам Model Context Protocol остаётся более правильным архитектурным решением. Нам нужно строить коннекторы, а не плодить CLI.

Баланс между производительностью, читаемостью и поддерживаемостью — ключевая задача при разработке микросервисов на Go. На практике всё сложнее из-за неочевидных факторов: от влияния частоты вызовов GC на время отклика до последствий избыточной вложенности в контрактах API. Если не учесть эти нюансы, даже грамотно спроектированный сервис может просаживаться по RPS (requests per second) — или его может быть сложно обновлять и дорабатывать.

Меня зовут Артём Кущ. Я Go-разработчик в команде VK Видео. В статье поделюсь подходами к оптимизации микросервисов и расскажу, как балансировать между скоростью и простотой.

CoreBus — кроссплатформенный терминал для работы с COM-портами и TCP-сокетами с поддержкой протоколов Modbus TCP / RTU / ASCII и много чего еще.

Приложение развивается уже довольно давно. Но была одна фича, которой не хватало, чтобы сделать CoreBus по-настоящему универсальным терминалом. Мне об этом писали еще с первых релизов. В личных сообщениях и в комментариях к статьям. Эта идея формулировалась по-разному, но суть была одна.

И поэтому хочу представить вам новый режим - "Modbus мониторинг"!

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

Добавить поддержку i18n в Lazarus — дело пяти минут. Проблемы начинаются потом: DefaultTranslator не подхватывает файлы, компилятор молча принимает resourcestring в const-массиве и ничего не переводит, fuzzy-флаг тихо блокирует строку без единого предупреждения.

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

Недавно я опубликовал мнение о фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должна способствовать) массовому переходу с C/C++ на «безопасные» языки программирования Экономика безопасности кода или почему Rust не нужен.

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

Пользуюсь Codex с подпиской pro месяц. Собрал несколько очень тупых, но эффективных промптов, отлично показавших себя во время разработки с использованием GPT-5.4.

Вы наверняка встречали задачки на логику: «Все кошки — животные. Это животное — кошка. Значит ли это, что все животные — кошки?» Нет. С тимлидами та же история: не каждый сильный разработчик становится сильным тимлидом. Но и обратное неверно.

Меня зовут Юлия Аравина, я психолог и коуч IT-руководителей, а также наставник на курсе «Управление командой» в Яндекс Практикуме PRO. В этой статье я разберу, в какие ловушки попадают сильные разработчики после повышения, как из них выйти, и как понять, что тимлидство не для вас (или всё же для вас).

Дали мне недавно задачу написать тесты для одной CLI-тулзы. Это мне уже привычно и понимание, зачем тулза нужна, есть. Я только не знал, что меня ждёт в коде. Программист, писавший её, сделал гигантскую работу — претензий нет (не обижайся, пожалуйста, если читаешь это, но это стоит отдельной статьи). Там суммарно, наверно, порядка 30к строк кода написано. Нюанс в том, что, видимо, он раньше не писал на C#,

Так что тут я соберу для вас примеры, как нельзя писать и как стоит.

Проектируете REST API и всё ещё используете 200 OK для ошибок?

А знаете, почему неправильные статус-коды могут убить производительность и как всего один кейс с TSB Bank показал цену плохого анализа?

В этой статье разбираем реальные принципы REST, модель зрелости Ричардсона.Полезно всем, кто пишет бэкенд или проектирует микросервисы.

Продолжаем серию «Kotlin для новичков»!

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

В этом туториале вы узнаете:

▪️ Как объявлять функции и чем это отличается от Java.
▪️ Что такое именованные аргументы и значения по умолчанию (и почему это круто).
▪️ Как работает стек вызовов и области видимости.
▪️ Главные best practices, которые используют в разработке.

ИИ‑агенты вроде Claude Code и Cursor умеют писать код. Но одного файла с инструкциями им хватает ровно до первых сложных задач. Дальше агент молча трогает семь модулей вместо одного, уверенно додумывает чужой API и третий раз подряд наступает на одни и те же грабли. На тридцатом проекте становится ясно, что нужен полноценный инженерный стандарт, а не набор личных правил. В индустрии такого стандарта до сих пор не было, поэтому пришлось написать его самому. Так появились SENAR (открытый стандарт инженерного процесса для разработки с ИИ‑агентами) и фреймворк TAUSIK к нему. Первая статья из шести рассказывает, из какой конкретно боли они выросли.

Меня зовут Илья Чебарев, я химик-технолог с большой примесью экономиста. В СИБУРе я руководил проектом по внедрению мультивариантного анализа. Это математический метод, который помог нам разобраться, что на самом деле влияет на обрастание реакторов. Расскажу, как мы собрали команду, нашли инструмент и прошли путь от перебора 70 параметров до конкретных рекомендаций как реже останавливать реактор и сэкономить много миллионов.

Недавно я, не выдержав микроскопических лимитов Cursor (в остальном прекрасный инструмент!) по доступу к передовым моделям Anthropic, захотел получить их по плоским тарифам от фирмы-разработчика. Это такие тарифы с помесячной/годовой оплатой, а не с оплатой за каждый запрос к API.

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

В итоге я всё настроил: Claude работает как родной, и в этой статье — мой опыт, а также тесты разных VPS-локаций.

Я опишу настройку под Linux-десктоп, но в конце в качестве бонуса будет настройка и под Windows.

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

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

Многие команды продолжают использовать приложения на платформе CUBA, которые хорошо работают и ежедневно решают реальные бизнес‑задачи. Но со временем неизбежным становится вопрос: стоит ли продолжать поддерживать приложение на старом стеке или лучше перенести его на Jmix?

В этой статье я хочу показать, как такая миграция выглядит на практике. Мы перенесли приложение‑пример Timesheets с CUBA Platform на Jmix и записали процесс шаг за шагом. Timesheets — это не маленькое демо с несколькими сущностями и CRUD‑экранами. Это приложение для учета рабочего времени с согласованиями, несколькими способами ввода времени, кастомным UI‑поведением, календарем, диаграммами и немалым объемом бизнес‑логики.

Всем привет, это моя первая статья, в рамках которой захотелось поделиться необычным для меня опытом. Возможно, кто-то найдёт здесь для себя что-то полезное. По работе пришлось столкнуться с крайне необычной микросхемой для коммутации высокочастотных (RF) сигналов.  Одна проблема – проприетарный интерфейс управления MIPI RFFE. Появился вопрос “А как этим управлять, не имея специализированных средств?”. Ответ узнаем вместе.

Недавно наша команда столкнулась с необычным поведением системы, которая начала использовать избыточное количество CPU-ресурсов.

В начале года мы запустили миграцию сервиса в новое хранилище PostgreSQL с существующего NoSQL-решения. Сервис среднестатистический, не High-Load, но занимает ключевое место в обработке бизнес-процессов, отвечает за генерацию заданий для коммуникаций с клиентами. Без проблем держит поступающие 30 RPS, ежедневно обрабатывает около миллиона джобов, хранит сотни миллионов строк данных и в среднем потребляет 125ms CPU.

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