Вообще, я менеджер.

Но когда-то писал код и всегда любил это занятие. Серьезно прогал мобильные приложения, и даже заработал за один из ответов на SO больше 100 звездочек.

Но с тех пор прошла куча времени.

И последнее время меня вновь увлекла эта тема. А как она может увлечь современного человека, измученного миллиардом фреймворков и отставшего от прогресса лет на 15?
Конечно-же курсором и вайб-кодингом.

И я начал кодить.

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

Но в процессе всего этого неизменно сталкивался с двумя проблемами

1) Cursor (и брат его Windsurf) паршивейшим образом обходится с нетипизированными и слабо-типизированными языками. Изобретает названия переменных, меняет их по ходу, и вообще, забивает на это огромный и толстый... За пределами этого кодит он неплохо. Но данная штука лично у меня порождает 90% багов.
2)...

Казалось бы, совсем недавно мир только начал знакомиться с тем, что такое большие языковые модели (LLM). Вскоре после этого появились их многочисленные вариации — на любой вкус и цвет, от узкоспециализированных до универсальных моделей. Затем началась волна интеграций: LLM начали встраивать в различные сервисы, приложения и API, упрощая и автоматизируя рутинные процессы.

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

И вот, компания Anthropic представила решение этой задачи — новый протокол Model Context Protocol (MCP), который стандартизирует взаимодействие агентов с различными сервисами и между собой.

Давайте разберёмся, что такое MCP, и с чем его едят!

Всем привет! Меня зовут Бодров Иннокентий. Я — продакт, аналитик и архитектор с более чем 17-летним опытом в разработке информационных систем, построении успешных продуктов в телеком-индустрии, финтехе, электронном документообороте и корпоративных порталах.

Последние несколько лет я активно продвигаю идеи работы на основе здравого смысла, бережливости и современного, гибкого (в хорошем смысле слова) продуктового подхода. И один из инструментов, который мне помогает в этом — это Domain-Driven Design (DDD).

Многие считают DDD чем-то исключительно для разработчиков. Я же уверен: это прежде всего коллаборативная техника. Она полезна аналитикам, продактам, архитекторам, менеджерам. Но особенно важно, чтобы в DDD погружались те, кто ближе к бизнесу. Потому что именно у них есть шанс выстроить мост между миром предметной области и кодом.

О том, как это сделать — и будет эта статья.

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

Делюсь опытом, шагами, ошибками и первыми результатами.

Не гайд, не обучалка — скорее дневник погружения и разбор, как всё это устроено изнутри.

Архитектура программного обеспечения — основа, от которой зависят качество, производительность и масштабируемость систем. В статье шаблон от экспертов в области архитектуры программного обеспечения с типовыми описаниями и примерами архитектурных представлений. Шаблон доступен для скачивания.

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

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

При расчёте доходности торговли валютными парами и ациями pre-IPO всегда нужны актуальные валютные курсы. Постоянно открывать сайт Центробанка РФ (ЦБ РФ) и копировать валютные курсы в Excel становится лень – и тут на помощь приходят Excel и VBA.

Наипростейшее решение – сделать в Excel выпадающий список с выбором валюты и написать макрос, который сам подтянет нужный курс с сайта ЦБ РФ. Тогда можно просто выбрать, например, USD или EUR, и таблица сама подставит актуальный курс в расчет. Звучит классно, пора делать.

По следам:

Как я сделал RAG для своей компании

Как я сделал RAG для своей компании (часть 2). И как начал делать AI Агента

AI агенты — клоны сотрудников (часть 3)

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

В этой статье я покажу как можно самому, бесплатно и без смс, нарисовать черную дыру при помощи OpenGL, в полном соответствии с ОТО.

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

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

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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

• Сначала в GPT 4.5 провёл продуктовые исследования и сформулировал требования.
• Попросил превратить это в архитектурный план.
• Отревьюил, поправил тупые ошибки.
• Затем этот план (как метапромпт) скормил Sonnet в VS Code через плагин Cline. Попросил сначала создать общую структуру, шаблонные имплементации, документацию, спецификации API (protobuf для gRPC, REST API).
• Архитектурно сразу заложил микросервисы. Sonnet для каждого сервиса подобрал и обосновал оптимальную базу данных (где-то Postgres, где-то ClickHouse и т.д.).
• Сгенерировал SDK для взаимодействия, примеры использования. Сразу заложил observability: централизованные логи, метрики Prometheus, трейсинг Jaeger/Tempo, дашборды для Grafana.
• Потом итерационно генерировал код: сначала тесты (End-to-end, BDD), потом имплементацию под эти тесты.
• Написал манифесты для Kubernetes и Docker Compose для локального запуска.
• Сгенерировал даже скрипты для тестов REST API через curl и gRPC через gRPCurl.

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

Однажды мне стало интересно: а что будет, если отправить пакет с несуществующим транспортным протоколом? Не TCP, не UDP, не ICMP — вообще что-то выдуманное. Пропустит ли его ОС? Дойдет ли он хотя бы до сетевого интерфейса? Не зарежет ли его какой-нибудь промежуточный маршрутизатор? А вдруг он еще и быстрее обычного дойдет, потому что никто не знает, что с ним делать?

Ответа у меня не было. Так что я решил проверить.

Postgres Professional продолжает публиковать книги о возможностях СУБД PostgreSQL. В этот раз представляем учебное пособие для тех, кто хочет стать маэстро в управлении базами данных.

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

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

Сегодня мы погрузимся в результаты этого исследования, то есть вместо того, чтобы визуализировать код, мы поговорим о визуальных паттернах кода - тех, которые буквально заставляют мой мозг болеть!

Предупреждение! Это туманная и плохо изученная область. В исследовании использовались различные источники: популярные метрики, научные статьи и практические мнения (включая мое собственное). Но в конце пути мы сведем всё ниже к 8 визуально различимым свойствам, которые помогут программистам любого языка улучшить читаемость кода.