Kurgan-Telecom Ru | Информационные технологии

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

Я пользуюсь MAD CATZ S.T.R.I.K.E. 7, которая всем чудо как хороша, кроме того, что вышла больше 10 лет назад, её производитель обанкротился в 2014 и её софт на Win 11 уже надо ставить с бубном. Все мы смертны, клавиатуры - тем более, так что я стал задумываться над заменой. Но проблема в том, что я привык к россыпи макроклавиш, которые позволяют одним нажатием, не задействуя мозг, переключать ветки гита, исправлять криво введённые команды или вбивать пароли в окошки по 15 раз за день (о боги хаоса, как я "люблю" параноиков-безопасников). А современные клавы имеют в лучшем случае 4-5 макроклавиш (что вдвое меньше, чем нужно), а некоторые ещё и стоят как приватный остров. И тут в унынии я наткнулся на это...

Привет, Хабр! Сегодня мы часто говорим про разные тренды в разработке — ИИ‑агентов, тестирование на ранних стадиях, прослеживаемость изменений, автоматизацию пайплайнов… Все эти тренды звучат убедительно, пока не упираются в реальность: требования лежат в на общих дисках, схемы — в картинках, контракты — в разных версиях, а история изменений размазана по инструментам.

Что делать с этим?

Лев Немировский, руководитель направления по развитию инструментов внедрения ПСБ, рассказал, чем полезен в этом случае подход GitOps и о том, как и в каких случаях это может упростить жизнь команде.

Терминалы сбора данных (ТСД) - это не смартфоны. Производители корпоративного оборудования, такие как Urovo, стараются намертво закрывать систему: нет открытых прошивок, а Fastboot ведёт себя нестандартно, нет мануалов.

C# я до сих пор считаю одним из самых удобных языков для backend разработки. В нём много вещей к которым быстро привыкаешь: свойства, LINQ, async/await, generics без type erasure, хороший tooling и понятная модель разработки.

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

Так я оказался в ситуации где C# мне субъективно нравится больше, но Java объективно стала полезнее в конкретном банковском контуре.

Эта статья не про холивар C# vs Java. Это попытка спокойно разобрать почему backend разработчику в enterprise иногда приходится расширять стек, даже если текущий язык его полностью устраивает.

Хочу написать небольшую заметку про биткоин на Московской бирже. Надо понимать что на Московской бирже торгуется не сам биткоин, а фьючерсный контракт на индекс Московской биржи биткоина. То есть вы не покупаете BTC, у вас не появляется кошелёк, вы не можете вывести монеты и вы не попадаете под регулирование криптовалют.

Это обычный расчетный фьючерс Московской биржи. То есть биржа просто начисляет или списывает рубли в зависимости от движения цены индекса.

В заметке рассмотрю экономику контракта и структуру издержек, сравню с другими инструментами Московской биржи.

Всем привет! Apple удалила «РСХБ Онлайн» из App Store в 2022 году. С тех пор мы выпустили пять новых iOS-приложений — «Учёт надоя», «Ягодный фест», «АгроСкан», «PRO Зерно» и «ПРО Жарка». Каждое рано или поздно удаляли. И каждый раз перед нами вставала одна и та же задача: перевести клиентскую базу со старого приложения на новое. Без App Store. Без возможности обновить бинарник. Без push-уведомлений в устаревшем клиенте.

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

Баги — неизбежная часть разработки. 

В этой статье расскажу наш опыт: как мы внедрили Zero Bug Policy в нашем стартапе (B2B fintech) и за месяц сократили backlog с 77 до 18 багов. А главное — как это изменило культуру и отношения с клиентами.

Восемь из десяти офисных сотрудников уже пользуются публичными нейросетями — часто без ведома IT. Запрет не работает: 90% руководителей ИБ сами заходят в несанкционированные ИИ-инструменты. Мы два года живём с этим на команде в 90+ человек — не через блокировки, а через матрицу из трёх зон: красной, зелёной и серой. Разбираем, как она устроена и почему держится без полиции.

Восемь из десяти офисных сотрудников уже пользуются публичными нейросетями — часто без ведома IT. Запрет не работает: 90% руководителей безопасности сами заходят в несанкционированные ИИ-инструменты. Мы у себя в команде на 90+ человек два года живём с матрицей из трёх зон — красной, зелёной и серой. Рассказываем, как она устроена и почему держится без полиции.

Введение: как я решил заняться разработкой силовой установки для тяжелых мультироторных БАС (взлетный вес 1–2 тонны) как к этому пришел, где я сейчас, и что вообще делать дальше.

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

Упрощенно, стоимость доставки 1 кг груза считают так: Цена доставки = (Амортизация железа + Энергия + Ремонт + Обслуживание) / (Вес груза × Дальность полета).

Для тяжелых коптеров требуются моторы мощностью от 50 кВт. Они выделяют колоссальное количество тепла и требуют высокой точности при производстве. Такие моторы делают, например, YASA, EMRAX, T-Motor. Но стоимость их решений делает применение распределенной тяги (например, 8 моторов на октокоптер) коммерчески бессмысленным: летный час становится дороже найма пилотируемого вертолета.

Накидываем моторы на умозрительный коптер и считаем по приведенной формуле с допущениями:

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

Его оставил пользователь Alexey_Kangin: Не исключено, что ответ на поставленный вопрос гораздо проще. Менеджер хакнул систему. Он понял, что решения можно просто не принимать, и это не оказывает существенного влияния на его позицию и доход. А в таком случае, зачем напрягаться? Думать больно, установленный нейронаукой факт.

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

Дальше — развёрнутый ответ. Ты прав в каждом пункте. Но в систему зашёл фактор, который многие считывают как угрозу, а он открывает дверь — в том числе тому самому менеджеру. Расскажу, какую.

Рудольф

Назову этого менеджера Рудольфом. Восьмой год в роли. Решения не форсирует — даёт ситуации дозреть, и к моменту, когда «решение» оформилось, обстоятельства уже выбрали за него. Доход индексируется, позиция стабильна, с руководителем ровно.

Сразу договоримся: Рудольф — это диагноз, а не приговор. Не «плохой работник». Человек, который точно определил среду и выбрал под неё разумную стратегию. Среда восемь лет за это и платила. Узнали себя — отлично, с этого начинается разговор. Дальше увидим: у этой стратегии открывается продолжение.

Почему это работало

Две причины, и обе про устройство среды.

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

В первой части я разбирал, почему spec-driven development начинает ошибаться, когда фича проходит через несколько микросервисов. Проблема не в том, что LLM плохо читает код или не умеет писать спеку. На уровне отдельных сервисов всё может выглядеть аккуратно: есть описание, план, реализация и тесты. Но правила, которые связывают сервисы между собой, часто не записаны в одном месте. Часть таких правил спрятана в реализации, часть известна только команде, а часть всплывает уже на ревью. Обычный Markdown не решает эту проблему: его легко написать неполным, сложно проверить автоматически и почти невозможно ревьюить как структурный контракт.

Отсюда родилась идея: нужен машиночитаемый контракт на каждый сервис, который фиксирует межсервисные правила, проверяется на коммите и даёт LLM структурный контекст вместо набора Markdown-файлов. Для этого я собрал open source плагин для Claude Code — archspec.

В этой части я покажу, как работает /archspec:init на одном сервисе из демо-проекта freelance-marketplace, разберу сгенерированные артефакты и объясню, как archspec поддерживает их в актуальном состоянии. Напомню, это Go-проект с 12 микросервисами для поиска фрилансеров. Вот схема сервисов, которую я использую на протяжении всего цикла:

Привет. В прошлой статье мы в основном говорили про чтение — кэш в controller-runtime, informer’ы, Reflector, DeltaFIFO, почему r.Get в реконсайле не ходит в apiserver. Сегодня поговорим больше про запись.

Kubernetes по своей природе спроектирован так, что одним и тем же объектом могут управлять разные контроллеры — и это нормально. На один Deployment смотрят и deployment-controller (правит status), и HPA (правит spec.replicas), и admission-мутаторы (расставляют labels), и cert-manager (дописывает свои аннотации), и пользователь с kubectl apply. Каждый из них отвечает за свои поля и не лезет в чужие. И всё это работает.

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

10 новых российских продуктов для стриминга с прямой монетизацией, помощи с SEO для Яндекса с ИИ, учета заказов клиентов подразделениям, поиска работы с помощью ИИ, генерации уникальных курсовых, рефератов, эссе или докладов без следов ИИ и многого другого. Битва за «Продукт недели» началась!

Product Radar — здесь каждую неделю публикуются лучшие онлайн-сервисы и железки от русскоязычных команд.

Привет, Хабр!

Меня зовут Василий, я директор SaaS-направления в Аспро — мы разрабатываем систему управления проектами Аспро.Cloud. В этой статье расскажу, зачем мы интегрировали MCP в собственный продукт, как определяли сценарии для внедрения и что из этого получилось.

Всем привет! Меня зовут Данила Максишко, я руковожу командой продуктовых исследователей в hh.ru. В статье расскажу, как мы работаем с обратной связью через важный инструмент — бэклог болей пользователей.

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

С момента последней (и вроде единственной) статьи о brec прошло какое-то время, и мне кажется, что будет полезно лишний раз напомнить о проекте. Даже неожиданно для меня самого он продолжает развиваться. Пусть я пока не могу похвастаться значимым интересом со стороны сообщества, но в паре локальных проектов он уже появился. Да, скорее как эксперимент. Тем даже лучше: можно провести, что называется, полевые испытания.

Топовые AI-модели с 95% на SWE-bench показывают 0% и 3% на ProgramBench бенчмарке, где задачи специально не пересекаются с обучающей выборкой. Не «упали на десять пунктов» - обнулились.

Параллельно: в мае 2025 Anthropic опубликовали safety-эксперимент, где Claude Opus 4 в 84-96% случаев пытался шантажировать инженера приватной перепиской, чтобы избежать отключения. В мае 2026 они же выпустили разбор причин и инженерное решение - production-модели на этом тесте теперь 0%.

Две истории, одна структура: модель предсказуема в обучающем распределении и непредсказуема за его пределами. Это не «AI плох» - это инженерная задача со своими правилами, и у нее есть решение.

Глава 4 серии «Путь разработчика», вторая часть про границы AI в проде. Что я переделал в Lexis после двух разборов - внутри.

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

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

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

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

Подобные сценарии редко являются следствием низкой квалификации разработчиков или недостатков конкретного фреймворка. Основная причина кроется в пропуске этапа системного проектирования и игнорирования вопроса безопасности на старте. Отсутствие четкого контракта и продуманной архитектуры превращает API из инструмента масштабирования в узкое место всей системы.

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

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

Что есть: одна потолочная fisheye-камера, которая покрывает весь зал. Это идеальный выбор для ритейла: угол обзора 180 градусов, не нужно ставить десятки обычных камер, не нужно сшивать панорамы. Но за этот комфорт приходится платить.