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

Всем привет! 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 после двух разборов - внутри.

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

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

Apple выложила на GitHub исходники corecrypto, которая отвечает за шифрование, цифровые подписи, хеширование и генерацию случайных чисел (своей низкоуровневой криптографической библиотеки) и подробно рассказала, как проверяет защиту iPhone, macOS от будущих квантовых атак.

Именно через неё работают Security framework, CryptoKit и CommonCrypto. В репозитории появились реализации ML-KEM и ML-DSA — двух постквантовых алгоритмов, которые Apple выбрала для своей криптографии. Первый нужен для безопасного обмена ключами шифрования, второй — для цифровых подписей.

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

Обычных тестов им оказалось мало: пришлось строить собственную систему формальной верификации, потому что существующие инструменты не покрывали все сценарии. Проблема в том, что corecrypto работает сразу на множестве устройств с разными версиями Apple Silicon, а часть кода написана не только на C, но и вручную оптимизирована под ARM64. В итоге Apple утверждает, что формальная верификация уже помогла найти критические ошибки, которые обычное тестирование пропустило. К примеру, apple обнаружила пропущенный шаг в ранней реализации ML-DSA. В некоторых случаях это могло приводить к некорректным криптографическим вычислениям.

 apple, corecrypto

Опубликован релиз Sway 1.12 — новой версии тайлингового Wayland-композитора, совместимого по идеологии и конфигурации с i3. Выпуск состоялся 25 мая 2026 года. По данным проекта, в Sway 1.12 вошло 138 изменений от 50 участников, а для сборки теперь требуется wlroots 0.20.0.

Главным пользовательским изменением стала поддержка HDR10 при работе через Vulkan-рендерер. Это не означает автоматическое включение HDR во всех конфигурациях: возможность привязана именно к Vulkan backend/renderer в wlroots/Sway и к поддержке со стороны драйверов, монитора и остального графического стека. Тем не менее для Sway это важный шаг в сторону полноценной работы с современными HDR-дисплеями в Wayland-среде.

( читать дальше... )

 sway, wayland

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

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

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

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

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

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

Привет, хабражители!

Я уже писал тут о своём открытом сервисе для скриншотов кода (и простого текста), который позволяет красиво отобразить фрагмент вашего кода в статьях, презентациях, примерах до-после и т.п., насколько хватит вашей фантазии.

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

Наконец, я могу сделать почти то, что хотел когда-то:

Больше всего мне не нравятся короткие созвоны. Когда мне говорят: «У меня есть окно завтра в 11:30, давай созвонимся на 10 минут». Для собеседника это просто очередной созвон, которых у него десятки за день. А для меня событие, вокруг которого начинает строиться весь день.

Введение

Content Pipeline — это официальный способ работы с ассетами в MonoGame. Однако в сообществе уже давно существует немалая группа разработчиков, которые его не любят и предпочитают загружать ассеты в «сыром» виде. Особенно это заметно в сообществе FNA(ещё одной реализации XNA4) — там такой подход используют практически все.

Я тоже давно в этой «партии» и в этой статье объясню, почему…