Разработка

Читатели на Хабре знают, что кубик Рубика — это не простая игрушка. За его разноцветными гранями скрывается целая вселенная математики. Сегодня поговорим о кубике Рубика как портативной шифровальной машине. Механика популярной головоломки основана на последовательности перестановок элементов, что делает его естественным объектом для изучения с точки зрения теории групп. В классическом кубике 3×3×3 существует более 43 квинтиллионов возможных состояний, и каждый поворот грани приводит кубик из одного состояния в другое. Именно это свойство и привлекло внимание криптографов: если кубик может генерировать такое огромное пространство перестановок, может ли он использоваться для шифрования сообщений?

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

Но вот однажды пользователи стали жаловаться, что не могут найти ранее подписанные документы. Бывало, пользователь подписал файл, долго к нему не возвращался, а спустя время уже не смог его отыскать. Переустановил приложение или авторизовался с другого устройства, и все файлы как в воду канули. 

Меня зовут Георгий Левченко, я Android-разработчик в ПСБ. Начал я искать источник бед пользовательских. Оказалось, виной всему было то, что все файлы хранились в кэш-директории приложения. Понял я: чтобы файлы не пропадали, им нужен менеджмент для файлов. Отыскался у Android для таких целей готовый инструмент — Storage Access Framework (SAF), он служит для доступа к файлам через стандартный интерфейс без управления разрешениями вручную. Поведаю под катом, как я решал с его помощью эту задачу. 

Привет, Хабр! Меня зовут Никита Трофимов, я старший менеджер Цифрового консалтинга Т1. Мы провели исследование российского стартап-ландшафта и хотим поделиться тем, что нашли. Не столько самим инструментом (хотя о нём тоже расскажу), сколько конкретными данными и технологическими решениями, которые обнаружили в процессе.

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

Есть момент, когда компания внезапно понимает: «мы уже не стартап на коленке, у нас продукт, клиенты, релизы, ответственность — и, кажется, пора взрослеть». Вот примерно там и появляется РБПО — разработка безопасного программного обеспечения.

В выпуске CrossCheck говорят: РБПО — не «для галочки» и не «для регулятора». Это про то, чтобы выжить в реальности, где код растёт, команды меняются, а рынок всё чаще спрашивает: «а вы вообще понимаете, из чего и как собраны ваши решения?».

С 1 марта 2026 года в России вступят в силу новые правила, запрещающие онлайн-сервисам автоматически списывать деньги за подписки. Что действительно меняется в законе, какие штрафы и как теперь работать бизнесу по подписке, чтобы сохранить выручку — расскажу в этой статье.

Привет, Хабр! Меня зовут Андрей Шафоростов, и я тот самый зумер-айтишник на заводе. Конечно, айтишник — понятие многогранное. Тут трудятся и разработчики, и сисадмины, и тестировщики, а конкретно моя должность связана с сопровождением проектов: компания выпускает решение, а я и мои коллеги поддерживаем его дальнейшую жизнь. 

С 2024 года я ведущий специалист в отделе сопровождения систем управления производством НТМК в компании «ЕвразТехника ИС». В этой статье расскажу о том, как прошёл мой первый год в промышленной разработке, чем я занимался, чему учился. А ещё, когда работаешь на заводе для конечных пользователей, то есть своих коллег, начинаешь повсюду видеть места, где можно прикрутить какое-нибудь решение и улучшить жизнь всем. Так я взял на себя проекты и по своей личной инициативе. Про них тоже расскажу. В общем, если интересно, как выглядят будни разработчика в промышленности, заглядывайте под кат!

Взгляд CPO на дистрибуцию B2B-IT-продуктов и опыт построения SaaS-экосистемы

В статье обсуждается гипотеза о том, что часть B2B-продуктов можно быстрее и дешевле выводить на рынок, если вынести повторяющийся back-office слой (доступы, аудит, биллинг, административный UI) в общую SaaS-платформу, оставив backend и данные у вендоров.

Модель не универсальна, предполагает осознанный vendor lock-in и требует жёстких правил экосистемы. Текст — приглашение к обсуждению применимости такого подхода, а не утверждение, что он подходит всем.

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

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

Типичный сценарий: бизнес приходит с задачей "Если в корзине три товара категории "Электроника", положи в подарок чехол, но только если регион доставки не "Дальний Восток". Звучит как if-else на пять строк. Но в распределённой системе это превращается в такой себе квест: BasketService синхронно обращается к Catalog, затем к Warehouse, затем к GeoService. Где-то посередине случается таймаут, где-то - сетевой сбой, и в коде начинают появляться саги, компенсации и ретраи.

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

Я приглашаю сегодня взглянуть на проблему под другим углом. Что если пересмотреть не инструменты, а саму парадигму управления состоянием?

Один из самых ярких споров нашего времени — что лучше: iOS или Android? И с той, и с другой стороны есть представители, готовые с пеной у рта доказывать, что их выбор лучше. Одни обвиняют других в том, что у них нет денег, другие доказывают, что их выбор лучше технически.

Пользователи Android в этом споре чаще всего начинают оперировать фактами, характеристиками, доказывать, что их POCO X6 Ultra (я только что выдумал этот телефон) лучше последнего iPhone 17 Pro Max, а стоит в два раза дешевле. Но для типичного фаната яблочной продукции это вообще не аргумент, он мыслит другими категориями.

У многих есть старые гаджеты которыми уже сложно пользоваться из‑за их возраста, но они до сих пор работают, причём выкинуть их жалко, а дорого уже не продать. У меня так валялся планшет Amazon Fire HD 6 (Ariel), он 2014 года. На досках объявлений такой стоит около тысячи рублей — ищется по фразе «amazon fire планшет».

Как‑то раз я увидел в магазине фоторамку и сразу же подумал про этот старый планшет. Но конечно, самое простое было просто купить готовую фоторамку. Или попробовать без всякой перепрошивки воспользоваться Fire Toolbox чтобы получить расширенный контроль над системой. Но FireOS заточена под amazon, а для меня это не актуально.

А ещё мне было интересно не только увеличение скорости от чистого Android вместо FireOS, но и сам процесс перепрошивки, потому что раньше были времена, когда я активно менял прошивки (ROMs) на своем основном телефоне, экспериментировал с ядрами и модами.

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

Каждый Qt-разработчик начинает знакомство с фреймворком с магической строчки qDebug() << "Hello World". Но задумывались ли вы, что происходит внутри этого вызова? Как Qt обрабатывает логи, какие есть ограничения, и главное — как это можно расширить под свои нужды?

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

2026 год. Нейросети — теперь рабочий инструмент, который есть почти у каждого.

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

Мы решили помочь и протестировали 25 нейросетей для самых разных задач: от генерации текста и видео до создания музыки и презентаций. В этом обзоре вы найдёте не только известных гигантов вроде ChatGPT 5.2 или Gemini 3, но и другие решения: ChatPDF для документов, SlidesAI для слайдов, Suno для музыки и отечественный «Кандинский» для изображений.

Если вы устали от поиска «той самой нейросети» — эта статья станет вашей картой сокровищ.

Пришло время поговорить о главной функции сборщика мусора в CPython. В предыдущих частях (1, 2, 3) мы говорили о поколениях, инкрементальной и полной сборке мусора — но все они в итоге вызывают главную функцию, которая и реализует основной алгоритм циклического сборщика мусора — находит и разрывает циклы у объектов, которые уже вышли из использования.

В первой статье на тему устройства сборщика мусора я написал, что история началась, когда я попробовал исправить ошибку в CPython. И вот, в четвёртой статье, я наконец‑то добрался до функции, в которой была ошибка.

Если вам интересно, давайте посмотрим, как работает «сердце» сборщика мусора.

Начиная писать данную статью, меня не покидало ощущение, что я открываю “Ящик пандоры”. Холивар. Так как ну кто признается, что он плохой проектный менеджер? Кто скажет - я плохо управляю проектами? Ну я же… (дальше сами подставьте необходимый спич:))

Тем не менее, в рамках цикла статей по управлению рисками в GameDev данную область просто необходимо рассмотреть.

Четкое понимание целей, целевого состояния проекта, продукта, позволяет лучше понять присущие риски. Эффективное управление игровым проектом и присущими рисками, дает конкурентное преимущество тому, кто знает, как управлять и эффективно этим пользуется.

Мы все часто слышали: “Нужно задержаться”, “Нужно выйти в субботу”, “Вся команда пашет, а ты домой собрался”, “У нас дедлайн, нужно сделать и все”, “It is the Crunch time, baby!” и т.д. в подобном ключе. Я сам, бывало, работал и по выходным, и до утра. Иногда это было дико интересно, а иногда у тебя был просто выбор - либо поработать как просят, либо уволиться.

Давайте разберемся, почему так происходит?

20 января была зафиксирована атака на цепочку поставок, затронувшая индийскую компанию MicroWorld Technologies, разработчика антивирусного продукта eScan. Представители компании позднее сами сообщили изданию BleepingComputer о том, что злоумышленники взломали один из региональных серверов и подменили там файл обновления антивируса, который был доставлен клиентам. Атака была обнаружена «снаружи» — специалистами из компании Morphisec, которые проинформировали производителя через день после начала атаки.

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

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

Почему одним все, другим почти ничего? 

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

Open Source Analysis: зачем нужен и как его проводить

В мире современной разработки приложений программное обеспечение с открытым исходным кодом (open source) стало неотъемлемой частью практически любого приложения. Open source библиотеки, фреймворки и компоненты ускоряют разработку, снижают затраты и способствуют инновациям. Но при этом существует серьёзная проблема: каждая зависимость — это не только ускорение разработки, но и дополнительные риски. В этой статье я постараюсь разобрать, что такое анализ открытого исходного кода (Open Source Analysis, или OSA), зачем его необходимо проводить, как он выполняется и как выглядит на практике.

Почему же open source — это одновременно благо и риск?

По разным исследованиям, от 70 до 90% кода в современных приложениях – это open source компоненты. Обычный сервис может тянуть за собой в проект сотни транзитивных зависимостей, о существовании которых разработчик может иногда даже не подозревать.

Примечание: транзитивная зависимость – это косвенная зависимость, пакет или библиотека, на которую ПО зависит косвенно через другую зависимость, это «зависимость от зависимости».

И в этом моменте у нас уже появляются проблемы. А именно:

Обычно обезьяны решают головоломки с удовольствием, но получив за это изюм, начинают ошибаться. Когда школьникам дают деньги за хорошие оценки, их интерес к учебе исчезает. Интересно, что и взрослые ведут себя так же. Когда программистам платят за каждую закрытую задачу, производительность команды падает примерно на 20%. Возможно, есть другой вид мотивации, когда само выполнение задачи служит вознаграждением?

Что ж, попробуем в этом разобраться.

Меня зовут Костя Дубровин. Я веду канал про книги.

Я активно использую на проекте Kafka Connect Framework и в частности Kafka JDBC Sink Connector для быстрого сохранения данных из Kafka Topic в БД PostgresSQL. Для большинства задач достаточно написать простую JSON-конфигурацию и все стабильно и быстро работает из коробки. Нет необходимости в написании собственного кода. Однако в нетиповых ситуациях расширяемость Kafka Connect тоже помогает - можно переопределить и написать один из компонентов.

В конфигурации JDBC Sink Connector Task существует настройка dialect.name, которая отвечает за выбор диалекта для работы с конкретной БД. Как правило, в 99% случаев используется один из уже реализованных для популярных БД диалектов, как например в моем случае PostgresSqlDatabaseDialect для PostgreSQL.

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

В данной статье я хочу показать идеи того, как реализация своего DatabaseDialect может помочь при имплементации нестандартных сценариев для вполне себе популярной БД Postgres, для которой существует PostgresSqlDatabaseDialect.

Всем привет! Когда речь заходит о разработке высоконагруженных систем, многие предлагают: «python, сделать проще и быстрее». Но есть проблема: Скорость разработки != скорость и качество работы сервиса. Когда мы делаем любой продукт, важны: Масштабируемость, стабильность работы под большой нагрузкой, предсказуемость поведения системы — особенно когда речь идет о тысячах одновременных пользователей, лентах новостей в реальном времени, уведомлениях и сложных связях между разными сущностями.

Именно поэтому и выбрана Java и Spring Boot как основа. Банки, сервисы видео, они работают именно на Java и Spring.

Одна из особенностей: строгая типизация, качественные инструменты для многопоточности, мощная экосистема и предсказуемое потребление памяти делают Java идеальным выбором для систем, где падение = полная потеря пользователей.
Попробую сделать цикл статей по разработке соцсети, которая будет объединять в себе ВК, пикабу, и иже с ними. Не ради «создания продукта который затмит всех и вся», а ради самого программирования.

Итак, начну, среда разработки Intellij Idea. О, точно, весь проект будет доступен из gitLab. Нам необходимо создать файлы с конфигурацией. можно сказать что их обычно 3. Да, я про application.yml. один из них общий, который так и называется: application.yml, и еще два: application-dev.yml и application-prod.yml