Бэкенд

Консольное приложение - не самая очевидная вещь для разработки на планшете. Ни полноценного терминала, ни файловой системы, к которой привыкли на десктопе, ни нормальной многозадачности - так было ещё пару лет назад. Но если вынести сам процесс исполнения кода на удалённый Linux-сервер, а iPad превратить в тонкий клиент для управления AI-агентом и просмотра результата, картина меняется полностью. Ниже - рабочий процесс, который у меня сложился для разработки CLI-инструментов на Python: VPS + AI Coding Agent (Claude Code) в tmux + Remote IDE как единая точка входа, всё на iPad со Stage Manager. Для такого цикла нужно немного: SSH-доступ к серверу, где крутится агент, и способ параллельно смотреть на файлы и на diff, не теряя сессию агента при переключении между окнами. Дальше - как это выглядит по шагам.

Хабр, привет! Меня зовут Андрей Пронин, я руководитель «бирюзовой» студии заказной разработки ProninTeam и наставник на курсе по управлению командой разработки в Яндекс Практикуме.

Несколько лет назад я запустил YouTube-канал с публичными мок-собеседованиями по Python для джунов из Практикума. В этом материале расскажу, как так вышло, чем мок-интервью отличается от настоящего — и как формат помогает начинающим разработчикам.

Идеи аспектно-ориентированного программирования до сих пор широко используются в современных языках и фреймворках — достаточно вспомнить их роль в экосистеме Spring. Однако при всей практической востребованности сама парадигма остается как будто в тени. Чтобы немного это исправить, мы публикуем перевод текста Грегора Кизалеса и его коллег из Xerox PARC — первого полноценного манифеста АОП, представленного на конференции ECOOP ’97 и заложившего основы для дальнейших исследований в этой области.

Про Kafka в этой серии уже было. Теперь — RabbitMQ, и с упором на то, как им пользоваться. Коннектор redb.Route.RabbitMQ — поверх официального RabbitMQ.Client 7.x, но писать вам придётся не «клиент», а маршруты, где весь брокер задаётся одной строкой-URI:

Хабр, привет! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками в Яндексе и эксперт онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндекс Практикумом. Приёмная кампания в нашу онлайн-магистратуру уже идёт, программа рассчитана на опытных разработчиков и на тех, кто идёт с нуля. Поэтому, если хотите программировать на JavaScript, Python, Java или С++ — ждём вас. А в этой статье я хочу поговорить о том, почему работа с ИИ постепенно перестаёт сводиться к написанию промптов, зачем разработчику учиться мыслить процессами, а не отдельными запросами, и почему именно такой подход позволяет получать качественный результат.

Добрых дней, товарищи хабравчане! Изначально я писал этот текст как конспект по асинхронности в пайтоне для самого себя, потому что вещь эта довольно хитрая и не хотелось бы в будущем растерять и забыть знания о ней, когда буду работать с другими языками программирования и фреймворками. Но потом решил попробовать переделать это в формат статьи и опубликовать, потому что сами знаете — когда кому‑то объясняешь, сам начинаешь лучше понимать. Очень надеюсь на конструктивную критику в комментариях, так как хочу сделать эту статью хорошим пособием для новичков или просто людей, которые хотят повторить и закрепить фундаментальные концепции, потому что без их понимания никуда. Итак, приступим.

Привет! На связи Влад, разработчик product-facade — сердца витрины Ozon и одного из самых высоконагруженных сервисов, который выдерживает до 2,2 млн RPS. В прошлой моей статье я рассказывал об одном из архитектурных вызовов, с которым мы столкнулись в процессе работы. В этот раз продолжим тему микросервисной архитектуры и поговорим о том, что происходит, когда привычная строгость контрактов начинает мешать.

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

Агент в Сан-Франциско тратит двадцать минут на то, чтобы пофиксить баг, который агент в Лондоне решил пять минут назад. Опыт первого умрёт вместе с сессией: завтра тот же баг будет с нуля решать кто-то третий. В Stack Overflow это называют Ephemeral Intelligence Gap — и 10 июня 2026-го компания запустила под эту проблему отдельную платформу: Stack Overflow for Agents, площадку, где опытом обмениваются не люди, а агенты.

На Хабре про запуск уже писали в паре статей, а в опросе под одной из них 59% проголосовали за «проект закроется». Мне есть что к этому добавить: я почти сразу после запуска завёл туда агента — научил его ходить на площадку по API — и спустя месяц он в топ-8 лидерборда. Всё это время я смотрел на платформу не из новостей, а изнутри — и встраивал её в свой пайплайн агентной разработки.

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

На примере PHP хорошо видно, как внутренние оптимизации динамически типизированного языка развиваются и усложняются.

PHP‑массив выглядит универсальным, но внутри него скрыто множество оптимизаций и ветвлений, в их числе оптимизации для хранения и работы с массивами: Packed List & HashTable. Взаимодействие между ними и copy‑on‑write дают иногда неожиданное и непрозрачное поведение с точки зрения PHP программиста.

Событийно-ориентированная архитектура красиво выглядит на схеме — пока не встречается с требованиями реального времени.

В переводе от команды Spring АйО разбирается опыт масштабирования Java-платформы контакт-центра: почему локальные кеши начали расходиться, как повторное воспроизведение Kafka-событий почти сделало бесполезным автомасштабирование, откуда взялось получасовое отставание потребителей и почему часть критических путей пришлось вернуть к синхронному взаимодействию.

Без войны с Kafka и без универсальных рецептов — только архитектурные компромиссы, которые становятся видны под рабочей нагрузкой.

Асимптотика на практике: Сравнение алгоритма сортировки вставками и выбором

Автор: Шуравин Александр, к. т. н., доцент, в IT более 20 лет.

Введение

В теории алгоритмов мы привыкли оперировать абстракциями: O(n²), O(n log n), O(1). Но что скрывается за этими обозначениями в реальном продакшене? Насколько критичен выбор алгоритма для вашей системы?

В этой статье я исследую два классических алгоритма сортировки — сортировку выбором (Selection Sort) и сортировку вставками (Insertion Sort) — на трёх типах входных данных:

1. Случайный массив.

2. Уже отсортированный массив (best case).

3. Массив, отсортированный в обратном порядке (worst case).

 Эксперимент проведён на Python с замером времени выполнения для размеров массива от 100 до 1000 с шагом 100.

Теоретическая справка

Сортировка выбором (Selection Sort)

Идея: На каждой итерации находим минимальный элемент в неотсортированной части массива и меняем его с первым элементом этой части.

Создаю собственный DSL на C#: рассказываю о том, как я добавляю семантическую модель. Рассказываю архитектуру семантической модели.

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

Меня зовут Илья Новиков, я технический директор компании «Исходный код».

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

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

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

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

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

Docker Gitlab + Gitlab runners на Fedora 44. Как настраивал у себя и немного каких приколов может быть.

В мире разработки программного обеспечения редко можно увидеть, как зрелый, динамический язык добавляет мощную, статическую систему типов без ущерба для своей философии и существующего кода. 3 июня 2026 года команда Elixir сделала именно это, выпустив версию 1.20. Главное нововведение — постепенная типизация (gradual typing), которая обещает найти в вашем коде «верифицированные баги» (verified bugs — ошибки, гарантированно ведущие к падению в рантайме) без необходимости писать аннотации типов.

Но почему это должно волновать вас, если вы пишете на Python, Java или Go? Команда Elixir поставила перед собой цель, которую многие считают «святым граалем». На практике сочетание всех трёх свойств почти не встречается.

И я считаю, что это отличный повод присмотреться к Elixir, даже если вы никогда не писали на нём ни строчки. Зрелый и интересный язык, работающий на виртуальной машине Erlang (BEAM) и исповедующий функциональную парадигму. Он известен своей отказоустойчивостью и конкурентностью, но, увы, остается малоизвестным языком, и я надеюсь что эта статья заставит вас заинтересоваться Elixir.

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

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

Как одна фича сократила число системных вызовов на TUN-интерфейсе моего VPN почти вдвое — а на bulk-трафике до 44 раз.

В этой статье пойдет речь о том как работает TUN GSO, зачем нужен virtio_net_hdr, какие подводные камни встретились во время реализации и почему эта технология способна заметно снизить нагрузку на VPN-сервер. Статья будет полезна разработчикам VPN серверов и клиентов.

Я уволился! Все задрало! Поздравляйте! :) Чуть позже расскажу, что да как.

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

Скатал в Турцию, залез на Эльбрус(весело, чуть позже расскажу,теперь хочу туда заехать на электровеле), достал жену до печёнок, зафигачил забор на даче и замостил всю дачу плиткой. Но экзистенциальная тоска, деградация и декаданс маячат на горизонте.

Кстати, кому интересно, как дела у моего человека-соседа — никак. Стаья про него тут https://habr.com/ru/articles/857774/. Дом так и не пригоден для жилья. Вчера он сказал, что мечтает в нём успеть пожить в этой жизни, но не факт.

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

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

Да шучу. Это будет прям альфа-тестостерон-самец-хобби с блестящими глазами и бессонными ночами. Представляете: вы знакомитесь с девушкой, и она спрашивает вас: «А какие у тебя хобби?» — и ты не говоришь там какие-то бег, сноуборд, оверпрайсовые велики или, боже упаси, падл. Ты говоришь: «На прошлой неделе нам с пацанами было скучно, и мы открыли свою пивнуху».

Да я уже открывал свою пивнуху и ностальгирую по этим моментам. Статья тут https://habr.com/ru/articles/739630/

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

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