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

В этой статье я расскажу, на какие подводные камни я споткнулся при разработке своего пет‑проекта — мониторинга сайтов на Golang, аналог UptimeRobot.

Начнем издалека... Я хотел разработать пет‑проект, но не банальный todolist, а что‑то свежее, интересное в плане архитектуры и реализации. Шерстя по просторам интернета, я наткнулся на UptimeRobot — сервис для мониторинга сайтов. Азарт и любопытство взяли верх и я начал продумывать, как буду разрабатывать «свой» UptimeRobot. Думал — делов на пару недель от силы. Ведь принцип прост: дергать URL по таймеру и проверять код ответа и всё. Но на практике все оказалось намного сложнее, чем я изначально представлял...

Код работает, тесты зелёные — а читать его невозможно.

Документация «содержит всё» — а в голове после неё не остаётся ничего.

Привычный диагноз «плохо обучили» объясняет не всё: человек и LLM мыслят по-разному устроенными механизмами, и значительная часть «низкого качества» — это столкновение двух когнитивных архитектур.

Где на самом деле предел внимания LLM, почему у человека сложность болит, а у модели нет, и кто в системе «человек + LLM» заметит момент потери контроля.

Спойлер: никто.

Привет, Друзья!

Хотел написать короткий пост по мотивам одного казалось бы простого ПР-а, который мы недавно получили в рамках Axelix: Open Core продукта для решения основных известных болей при разработке Spring Boot приложений (кстати, give us a star!).

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

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

Давайте с места в карьер. Посмотрите на этот код:

BGPLite — open-source BGP route-server на C# и .NET 10. Он принимает BGP-сессии, динамически загружает префиксы через RIPE Stat и управляется через HTTP API. В статье разберём архитектуру проекта и реализацию собственного BGP-сервера с нуля.

После выхода первой части прошло 2 месяца, и наши многоуважаемые американские партнёры из Anthropic и Google что-то подхимичили, и новые версии Claude Code и Antigravity перестали работать.

А так хочется попробовать новые чудо-модели типа Fable 5 и Opus 4.8! Поэтому нам придётся осваивать новые хитрости для настройки VPS, чтобы быть на острие прогресса.

Приветствуем, уважаемые читатели! На связи Олег Сивченко @OlegSivchenko.

Пару месяцев назад мы анонсировали выход русскоязычного издания знаменитой в узких кругах книги Дениса Бахвалова, которая в оригинале называется «Performance Analysis and Tuning on Modern CPUs» или просто «perf-book». Теперь она, наконец, в продаже и на полках магазинов. Русское издание называется «Оптимизация производительности современных процессоров. 2-е изд.». Это один из моих наиболее сложных, выстраданных, многоэтапных и при этом ценных проектов за последние четыре года. Уверен, он бы не состоялся без активного участия автора, его искренней заинтересованности и содействия в редактуре, проверке терминологии и в целом качества перевода, а также при составлении глоссария.

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

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

Модели класса Mythos (такие как Claude Fable 5) изменили рабочий процесс многих из нас в Anthropic. Хочу поделиться двумя советами, как работать с этим классом моделей эффективнее.

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

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

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

Затем первый сложный проект, где ты отвечаешь единолично за все. Требуется реализовать бизнес идею. Спустя боль и страдания, эта проблема тоже поддаётся и поднимает твои навыки и ЧСВ еще выше.

И тут появляется ChatGPT. Вопросы теперь задаются не в StackOverflow или гугл, а напрямую в нейронку, где ты сразу получаешь ответ. Да, он не идеален, местами нарушает все правила хорошего кода одновременно, но все же работает. Ты тратишь дополнительное время на его улучшение, но общее решение все же принимаешь. Хороший инструмент!

Салют, Хабр!

Я Марк, Android-разработчик, работаю над мобильным приложением для управления умным домом Салют. Для мира Android-разработки вопросы архитектуры, её надёжности и качества актуальны, но… на самом деле не так уж интересны. Интересно, чтобы приложения были надёжными, устойчивыми к ошибкам, поддерживаемыми и легко масштабируемыми. Самый популярный подход — по-прежнему архитектурные паттерны (MV* паттерны) и разделение архитектуры по слоям. Что никак не избавляет от ошибок.

При этом существует множество подходов, которые делают архитектуру надёжнее, а в перспективе исключают целый класс ошибок, как введение в Котлине Null Safety избавило от класса ошибок NPE. Это проектирование на основе состояний (state-oriented programming), логика Хоара, программирование по контракту Бертрана Мейера. Возможно, и более серьёзные — например, формальные методы верификации. Отмечу, что в целом это общие принципы computer science, независимые от платформы. Но мой фокус — Android-разработка клиент-серверных приложений.

Сейчас хотел бы поговорить, как создание своей системы типов в проекте исключает популярный класс логических ошибок — semantic type error. Поехали!

Всем привет, меня зовут Михаил, я работаю главным экспертом в ОТП Банке.

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

В какой-то момент я сказал себе: «Стоп. Хватит. Пора уходить в компанию, где всё организовано правильно». Мне казалось, что там не будет хаоса, бессмысленных авралов и вечной гонки за дедлайнами.

Ну что могу сказать - я попал.

Только вот ожидания и реальность оказались совершенно разными.

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

Всем привет! Я Дмитрий Милов, Python-разработчик компании МУЛЬТИФАКТОР в команде продукта MULTIDIRECTORY, мы разрабатываем собственную службу каталогов.

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

Почему продолжается путаница в концепциях, которые давно описаны и формализованы?

В реактивной системе все состояния связаны друг с другом инвариантами в единый граф. Когда мы изменяем что-то с одной стороны этого графа, рантайм обеспечивает каскадный пересчет зависимых состояний. Такие последовательности пересчетов — это ничто иное, как потоки информации (data-flow). Чем прямолинейнее эти потоки, чем меньше они разветвляются и затрагивают состояния, не относящиеся к изменениям, тем эффективнее работает система. И здесь есть два подхода к оптимизации потоков информации…

Она умерла в воскресенье вечером, и никто не услышал ни звука. Детективная история о том, как поставить прослушку на собственное приложение: Prometheus, Grafana, Micrometer, алерты, SLO. Все улики в комплекте, демо-проект прилагается. Совпадения с вашим продакшеном не случайны.

Мне было интересно проверить GigaChat/GigaCode не в обычном чате, а в нормальной агентной среде разработки. То есть не “ответь на вопрос”, а вот это всё: tools, function calling, streaming, MCP-инструменты, история диалога и работа внутри реального проекта.

Для проверки я подключил GigaChat к OpenCode через TypeScript-плагин. Простой текстовый запрос завёлся быстро, а дальше началось самое интересное: OpenAI-like API оказался похожим на совместимый агентный протокол только снаружи. Внутри пришлось собирать отдельный слой совместимости.

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

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

Отовсюду постоянно вылезают новые истории успеха. Кто-то показывает, как сократил время разработки в несколько раз. Кто-то рассказывает, что теперь пишет за день столько кода, сколько раньше писал за неделю. Иные вообще собирают полноценный продукт за выходные и искренне не понимают, почему раньше на это уходили месяцы. Честно говоря – раньше читал, но в последнее время просто игнорирую такие заголовки (почему – надеюсь станет понятно из статьи).

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

И мы, с моей командой проходим через те же изменения, что и вся индустрия.

Строка “false” в PHP равна true. Я узнал это, когда рубильник, которым я выключаю фичи перед живыми игроками, полгода отказывался выключаться. Два года в одиночку пилю текстовую MMORPG на CodeIgniter 4: мир дышит раз в минуту по крону, 485 выживших, 45 тысяч боёв. Пять багов — и за каждым стоял реальный человек по ту сторону экрана.

Недавно знакомый попросил помочь с небольшой задачей по проверке внешнего периметра сети компании. Сразу уточню: речь шла об инфраструктуре, на проверку которой было разрешение.

Под внешним периметром обычно понимают всё, что доступно из интернета: публичные IP-адреса, домены, поддомены, облачные или VPS-серверы, а также сервисы, которые слушают внешние порты.

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

17-й выпуск IT-новостей от OpenIDE!

Anthropic за одну неделю успели опубликовать страшную статью про рекурсивное самосовершенствование ИИ и выпустить публичную версию Mythos. В России на несколько часов заблокировали Python, GitHub продолжает страдать от 17 млн AI-сгенерированных PR в месяц, а разработчики отказались работать без AI даже ради эксперимента.