Мы запускаем новый цикл вебинаров "Надёжность, качество, безопасность ПО: методология и инструменты" ⚡️
В предыдущем цикле вебинаров "Вокруг РБПО" мы рассмотрели 25 процессов из ГОСТ Р 56939—2024, направленных на создание безопасных программных решений. Теперь поговорим не только о безопасности, но и в целом о создании качественного и надёжного ПО.
Вместе с экспертами из разных компаний мы поговорим про развитие DevSecOps практик, подходы к написанию качественного кода, вопросы регуляторики, ИИ, функциональную безопасность встраиваемого ПО, а также про инструменты композиционного, статического, динамического анализа.
parquet - данные лежат в открытом формате - казалось бы, бери кто хочешь. Но есть неприметный артефакт, от которого зависит, увидите вы таблицы или мусор из файлов и кого вообще к ним подпустят. Это каталог. Разбираю просто, что такое Apache Iceberg, зачем ему каталог - и почему новость про Polaris важнее, чем кажется. В продолжение анонса новостей…
Правительство РФ утвердило перечень приложений, обязательных для предустановки в 2027 году на смартфоны, компьютеры и смарт‑ТВ. Документ опубликовали на официальном портале правовой информации. Среди прочих в списке числятся RuStore, «Госуслуги», «ВКонтакте», «Дзен», разные приложения «Яндекса» и мессенджер «Макс».
Хотите ли вы, чтобы ваш кастомер был доволен своим саксесом? Мы — очень, поэтому собирались купить систему, чтобы отслеживать использование наших продуктов и услуг, улучшать опыт клиентов и предупреждать их отток.
Посмотрели варианты и поняли две вещи. Первая: отдельный инструмент создаст больше проблем, чем решит. Вторая: нужные функции можно собрать внутри сервис деска, который мы продаем.
Рассказываем, что и как настроили и какие получили результаты — со скринами и цифрами.
Не очередной рейтинг зарплат. Я разбираюсь, как опыт связан с грейдом, какие навыки сопутствуют более высокому доходу, от чего зависит удовлетворённость работой и кто открыт к переходу.
В анализ были взяты анкеты из 29 вопросов дата-сайентистов всех уровней, от стажёров до Head of DS. Я посмотрел, как связаны их опыт, грейд, доход и условия работы. В опросе я спрашивал об образовании и способе входа в профессию, навыках и типах данных, с которыми работают специалисты, времени на встречах, переработках, бэкграунде руководителя, удовлетворённости работой, готовности сменить компанию и ожидаемой прибавке к зарплате.
В банке всё, что не даёт измеримый эффект, рано или поздно называют «лишним ИТ‑решением» и выносят на оптимизацию. База знаний попадает в эту категорию особенно часто: сначала её делают «на энтузиазме», потом годами дорабатывают, а сменившийся операционный директор «внезапно» выясняет, что никто толком не знает, сколько она приносит денег и что будет, если её отключить.
Спросите любого, что делает ?, и услышите примерно одно: «сахар для match, который при ошибке делает ранний return». В целом, тут есть правда. Разворачивается ? и правда в match с return, но прячется за этим match целый трейтовый механизм — он умеет конвертировать типы, работает с вашими собственными типами и не имеет ничего общего с try/catch, хоть и выглядит похоже.
Давайте посмотрим, что компилятор на самом деле пишет вместо вашего вопросика, что такое residual в нынешнем дизайне, почему ошибке нужен отдельный тип, и как прикрутить ? к своему типу. И сразу скажу: пользоваться ? на Result и Option можно давно и на стабильном Rust, а вот реализовать поддержку ? для своего типа — это до сих пор nightly. Дальше будет видно почему.
Мы очень активно используем Кайтен — и почти не заходим в него руками. Туда ходят наши боты.
У нас на основной доске 19 этапов, в работе одновременно десятки текстов, и реальная жизнь команды идёт в чатах, а не в трекере. Вот как мы научились почти не заходить в трекер руками — и при этом ничего не терять.
Привет, я Катя Берестовая из агентства Loft. С 2008 года мы делаем контент-маркетинг для компаний. За каждым текстом — интервью с инженером, который «на встрече всё расскажет», фактчекинг, согласования с юристами клиента и редактура. Кайтен попросил рассказать, что мы про них думаем. История получилась нетривиальная: мы очень активно используем сервис управления процессами Кайтен — и почти не заходим в него руками. Туда ходят наши боты, а боты уже разговаривают с редакторами там, где им удобнее — в привычных чатах в Телеграме. Расскажу, как мы к этому пришли.
Один оператор сравнения чуть не удалил тысячу пользователей
На днях наводил порядок в логике автопродления подписок Telegram-бота. Казалось, задача на полчаса.
Если кратко: у пользователя заканчивается подписка, и бот проверяет дату планируемой оплаты. Если срок подписки истёк и продления нет, то пользователь попадает в очередь на удаление. Всё просто.
Проблема обнаружилась случайно. Я решил прогнать сценарий сразу на нескольких тестовых пользователях. Один из них только что оплатил подписку, но бот всё равно пометил его как кандидата на удаление.
Сначала я подумал, что платёж не успел записаться в базу. Проверил – платёж записался.
Потом начал искать проблему в часовом поясе.Тоже нет.
Дальше полез смотреть SQL-запросы, логи, время выполнения задач. Потратил на это больше часа и уже начал подозревать, что где-то появилась гонка между обработчиком платежей и задачей проверки подписок. Стал разбираться…
Причина оказалась намного проще: в фундаменте не стоял тот оператор сравнения.
Вместо subscription_end < now я написал subscription_end <= now.
Из-за этого подписка была просроченной не только после истечения срока, но и ровно в момент его окончания. Если время проверки и обновления совпадало, пользователь попадал в удаление по граничному условию.
Если задача проверки запускалась в тот же момент, когда обновлялась дата окончания подписки, пользователь попадал в удаление при совпадении времени окончания и времени проверки .
В большинстве случаев этого не происходило, но иногда баг воспроизводился. Именно такие баги самые неприятные, потому что они появляются случайно. И чем больше пользователей становится, тем чаще начинают всплывать.
В тот момент у меня была тестовая база, поэтому последствия не были бы критичными. Максимум, произошло бы несколько некорректных удалений. Но я сразу представил, что было бы в продакшене. Если бы ошибка попала в релиз, задача удаления прошлась бы по всем пользователям, которые удовлетворяли этому условию.
И если совпали бы время запуска задачи и обновление подписок, ошибочно удаленных пользователей было бы несколько сотен или тысяч.
Что изменил:
1. Перенастроил удаление: теперь оно происходит не сразу.
Пользователь сначала получает статус "ожидает удаления", а сама операция выполняется отдельной задачей через некоторое время.
2. Настроил перепроверку актуального состояния подписки через x часов, чтобы отсечь ложные срабатывания.
Если пользователь оплатил доступ или подписка продлилась, удаление отменяется.
3. Добавил тест на этот сценарий, чтобы избежать повторения <=ошибки.
Раньше я проверял только обычные случаи. Теперь отдельно проверяются пограничные значения времени.
Мораль: даже очевидные условия нужно проверять на границах.
Смотришь на условие и кажется, что ошибиться невозможно. Но однажды выясняется, что была допущена элементарная ошибка, которая убила тонну времени.
Всегда нужно помнить о границе условий. Именно там чаще всего и живут самые неприятные ошибки.
Есть ощущение, что подобные баги зачастую находятся не в сложной логике, а в самых очевидных местах? Интересно, как вы предостерегаете себя от таких стыдных ошибок?
Открытый проект .MD this page позволяет преобразовать веб-страницу в чистый Markdown, готовый для ChatGPT, Claude, Gemini и других нейросетей. Решение очищает код сайта от рекламы, баннеров и другого мусора для отправки на обработку в ИИ. Есть предпросмотр, экспорт в .md и опция для мгновенного копирования сайта.
Почти любая распределенная платформа рано или поздно сталкивается с необходимостью синхронизировать данные между своими системами. И чем выше требования к надежности и скорости доставки изменений, тем меньше остается простых решений. Бизнес-пользователям при работе с интерфейсом одной из платформ нужно знать о сущностях, заведённых во второй. Первая хранит их в реляционной СУБД (неважно, какой именно), а вторая - в документоориентированной MongoDB. До кучи, обе платформы разнесены по сети. Можно, конечно, предложить открыть оба интерфейса бок о бок и сверять данные глазами. Но это справедливо негативно скажется на финансовом обеспечении команды разработки, да и как-то не по-человечески так относиться к своим коллегам. Поэтому приходится зарабатывать доверие в коллективе честным трудом.
Встаёт вопрос: как в условиях распределённой структуры наладить транспортировку данных для взаимодействия независимых систем? Прикручивать ко всем продуктам кастомные интеграции дорого и непродуктивно.
В данной статье хочется представить вам, как мы реализовали интеграцию двух независимых платформ со своими базами данных при помощи инструментов MongoDB для мониторинга данных и брокера сообщений. Описать путь от самого простого решения на примитивных выгрузках метаданных одной пачкой до реализации на событиях Change Stream посредством брокера сообщений.
Из новостей: ждём сиквел Pragmata, Double Fine уволила 23 сотрудника, продажи Subnautica 2 достигли 5 миллионов копий, NVIDIA и AMD повышают цены на GPU для партнёров.
Из интересностей: перевод King’s Bounty 1990 для DOS на русский язык, техники рендеринга воксельного мира на мобильном устройстве в Unity, как левел-дизайнеру играть в игры.
Как Kubernetes, Jira и Keycloak не помогли выпустить продукт
Небольшой повод похвастаться: меня начали звать на технические аудиты не только по работе, но и просто как специалиста.
Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.
У заказчика уже есть работающий продукт примерно на 3000 активных пользователей в месяц. Пользователи покупают подписку и получают доступ к текстам, фотографиям и видео.
Заказчик решил обновить приложение и нанял отдельную команду. Прошло довольно много времени, но внятного результата он так и не увидел.
Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.
Меня позвали разобраться.
Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.
Когда доступ появился, меня встретила авторизация через Keycloak.
Напомню: разработчиков трое.
Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.
Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.
Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.
Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.
Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.
Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.
Получается странная картина. Инфраструктура уже сложная. Репозиториев много. Инструментов ещё больше. А общего понимания, что считается готовым продуктом, до сих пор нет.
Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.
Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.
Поэтому моя первая рекомендация заказчику простая: упростить инфраструктуру до уровня, который команда реально может поддерживать. Уменьшить количество движущихся частей и сначала научиться стабильно доставлять продукт пользователям.
Забавно, что это полная противоположность истории с The Signal.
Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.
Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.
Обе крайности плохие. Можно месяцами строить идеальную инфраструктуру и не выпустить продукт. А можно выкатиться за вечер, забыв про безопасность, логи и бэкапы.
Нормальный вариант где-то между ними: работающий пользовательский сценарий, понятные критерии готовности, минимальная безопасность, логи, метрики и повторяемый деплой.
Друзья, я просто обязан сказать огромное спасибо всему сообществу Хабра за вашу поддержку и активность под статьей о моем проекте Kakehashi!
Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.
Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.
Но мне особенно приятно и дорого то, что самый первый импульс, первые звезды и конструктивный фидбэк проект получил именно здесь. Вы дали Kakehashi тот самый стартовый заряд, благодаря которому он смог громко заявить о себе на международной арене.
Огромное вам спасибо!
P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!
Знакомая ситуация: созвон закончился, все обсудили, о чём-то договорились и разошлись работать дальше. А через пару дней начинается: «Подождите, а кто вообще должен был этим заниматься?» В лучшем случае у кого-то сохранились хаотичные заметки, в худшем — всё держится на человеческой памяти. А ведь встречи бывают не только онлайн, но и очные, с десятком участников и часами обсуждений.
Мы в компании Софрос столкнулись с этой проблемой в полный рост. Внутренние планёрки, встречи с клиентами, технические синхронизации — контекст терялся постоянно. Кто-то записывал аудио на телефон, кто-то конспектировал в блокноте, а потом всё это нужно было как-то собрать в единый протокол. На расшифровку часовой встречи вручную уходит около трёх часов — непозволительная роскошь, когда встреч десятки.
Так родился SOFROS AI Секретарь — система, которая автоматически превращает любую встречу в структурированный протокол с задачами и ответственными. Расскажу, как мы это сделали и что из этого вышло.
С 1 августа 2026 года Microsoft повысила цены на Xbox по всему миру. Цена консолей увеличится на $100 для моделей с 512 ГБ памяти и на $150 для моделей с 1 ТБ. Кроме того, прекратится выпуск модели с 2 ТБ памяти.
Команда Qwen выпустила Qwen3.8-Max, новую флагманскую MoE-модель на 2,4 трлн параметров. На каждом токене активируются 95 млрд параметров, размер контекста составляет 1 млн токенов.
В API модель стоит $2 за миллион входных и $6 за миллион выходных токенов. Это в 2,5 раза дешевле Kimi K3 по генерации и больше чем в четыре раза дешевле Claude Opus 5.
Веса Qwen3.8-Max обещают опубликовать на Hugging Face и ModelScope на следующей неделе. Это будет первая модель Max-класса от Qwen с открытыми весами. Вместе с ней команда пообещала открыть веса Qwen3.8-27B.
В начале августа 2026 года состоялся релиз мультиплатформенного видеоредактора с открытым исходным кодом Shotcut 26.8, созданного на основе MLT Multimedia Framework. Исходный код проекта написан на C++ и QML (интерфейс на виджетах, а не на qml) и опубликован на GitHub под лицензией GNU General Public License v3.0. Разработка проекта этого видеоредактора началась более десяти лет назад. Предыдущая стабильная версия Shotcut 26.6 вышла в июне 2026 года.
По данным Computer Weekly, исследователи обнаружили, что предприятия тратят больше времени на устранение неполадок с подключением к облаку из‑за возросшей нагрузки на системы искусственного интеллекта. Суммарно на эти процессы может уходить до 11 часов в неделю.
