Разработка

Обновляем платформу SourceCraft и открываем доступ к ней для всех разработчиков

Сегодня Yandex B2B Tech открыла публичный доступ к платформе для разработки SourceCraft и представила её новые возможности. В платформу интегрированы инструменты безопасности, которые обеспечат защищённую разработку программных продуктов. А в ИИ‑помощнике SourceCraft Code Assistant появился чат‑режим, что увеличит скорость и эффективность разработки.

Удобство командной работы повысится за счёт бранч‑ и ревью‑политик, встроенных в интерфейс, а также аутентификации через SSO. Также появляется возможность зеркалирования репозиториев с GitHub и публичный API.

Инструменты безопасности

На платформе стали доступны инструменты безопасной разработки: сканер секретов в коде и анализ зависимостей в кодовой базе.

По данным исследования аналитиков Forrester интеграция инструментов безопасности в разработку на 81% снижает трудозатраты на ИБ‑поддержку всего проекта.

Чат‑режим в SourceCraft Code Assistant

ИИ‑помощником SourceCraft Code Assistant пользуются десятки тысяч разработчиков. Теперь в нём доступен чат‑режим, интегрированный непосредственно в среду разработки. В диалоговом режиме на естественном языке можно задать вопрос ИИ‑ассистенту, сгенерировать код, юнит‑тесты, документацию. Это ускорит поиск необходимой информации и оценку предлагаемых решений. Функциональность доступна в плагинах для VSCode и IDE от JetBrains.

Зеркалирование и бесшовная миграция

Миграция проектов с GitHub становится бесшовной — кроме кода переносятся Issues, PRs, Labels, Milestones, Comments. Также можно выбрать ветки для зеркалирования — непрерывной синхронизации кода.

Также появился федеративный доступ к платформе для компаний — авторизация через SSO.

Публичный API

Благодаря появлению публичного API платформа становится расширяемой. Пользователь сможет взаимодействовать с SourceCraft и обеспечивать автоматизацию и интеграцию с другими приложениями. Первая версия публичного API доступна для управления задачами, список будет пополняться.

Правила работы с ИТ‑проектами

В интерфейсе платформы появились бранч‑ и ревью‑политики — правила работы с ветками и проверками кода, которые интегрируются в систему контроля версий и процессы CI/CD.

Опенсорс

Появился анонимный доступ к публичным репозиториям платформы. Пользователи SourceCraft смогут создавать независимые копии репозиториев (forks) опенсорс‑проектов. Это позволит вносить персональные изменения, не затрагивая напрямую исходную кодовую базу. При этом копия сохраняет связь с оригиналом для получения обновлений.

Удобство работы с кодом

Интерфейс платформы теперь позволяет просматривать структуру файлов для шести языков программирования: Python, C++, Java, Go, TypeScript и JavaScript. Функциональность навигации по коду стала умнее и аналогично теперь поддерживает 6 языков.

Автоматизация CI/CD‑процессов

Среди обновлений, связанных со сборкой и развертыванием кода, появились self‑hosted runners — теперь можно запускать задачи как на виртуальных машинах Yandex Cloud, так и в своём окружении. Также появились flavours — теги для пользовательских задач, за счёт которых можно выбирать, где запускать задачу. Помимо этого в интерфейсе платформы появилась возможность не только разрабатывать, но сразу публиковать мобильные приложения в App Store, Google Play, RuStore, Huawei AppGalery.

Packages

Появилась возможность создавать и использовать собственные программные пакеты популярных форматов: наборы кода, библиотек, модулей или компонентов. Разработчик сможет хранить их в персональном облаке, привязанном к организации SourceCraft, и использовать в своих проектах. Packages также интегрированы с CI/CD платформы.

Вход в SourceCraft реализован через Яндекс ID аккаунт. Зайти на обновлённую платформу можно на сайте SourceCraft.

Тест на собеседовании на должность проектировщика интерфейсов

Ставим перед соискателем большую коробку с конструктором типа Лего. Задача: собрать его за час. А дальше наблюдать.

1. В коробке должно быть шесть пакетов и инструкция по сборке. В инструкции должно быть указано, что для успешной сборки понадобится семь пакетов. Если соискатель заметит это перед тем, как распечатает первый пакет, и укажет на невыполнимость задачи — он молодец.

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

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

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

А вот ещё один теоретический способ, с помощью которого я бы проверял квалификацию соискателей. Там про цепляние к мелочам.

Спасибо друзья!

🚀 +32 подписчика в наш телеграм канал, это значит вам понравилась моя статья в рамках челленджа 12 проектов за 12 месяцев, которую я вчера опубликовал.

Кто еще не видел - оцените

На днях в офисе я столкнулась с коллегами из направления системного программирования в «Криптоните». Они пишут на С++ — а ошибки на этом языке у нас ещё не было!

Поэтому я попросила их придумать код с ошибкой специально для Хабра — и вот что получилось!

Итак, есть ли в этом коде проблема кроме narrowing conversion? Ждём ваши варианты в комментариях.

#include <cstdint>
#include <vector>

struct Type
{
    Type(uint16_t, uint32_t = {}) 
    {}
};

int main()
{
    std::vector<Type> vector;
    std::uint32_t object_id{};

    // Есть предупреждение о narrowing conversion
    vector.insert(vector.begin(), {0, object_id}); 

    // Нет narrowing conversion
    vector.push_back({0, object_id}); 

    // Нет narrowing conversion
    vector.insert(vector.begin(), Type{0, object_id}); 
}

АККУРАТНО, ДАЛЬШЕ СПОЙЛЕР!

Проблема в том, что в строке

 vector.insert(vector.begin(), {0, object_id});

в вектор вставляется 2 элемента типа Type, а не один, как ожидает программист.

Причина в том, что метод insert у вектора имеет перегрузку (номер 5), которая вторым параметром принимает std::initializer_list. А компилятор, видя фигурные скобки в коде, в первую очередь пытается создать объект такого типа.

И тут ему это удается, потому что у конструктора Type второй параметр имеет значение по умолчанию, следовательно, Type умеет создаваться, если в конструктор передали только один аргумент. В итоге компилятор успешно создает std::initializer_list с двумя элементами типа Type.

Так как создание std::initializer_list выполняется с использованием uniform initialization, то компилятор следит за корректностью преобразований. В примере объект типа std::uint32_t передается в конструктор Type, который принимает первым параметром std::uint16_t. То есть, возникает риск потери точности (32 бита не могут поместиться в 16 бит).

Об этом компилятор и предупреждает. Вот упрощенный пример, где видим то же самое предупреждение.

Может возникнуть вопрос, почему создание Type от 0 не вызывает предупреждение, ведь 0 - это int, а он, скорее всего 32 бита и тоже не помещается в 16 бит. Но тут литерал. Компилятор видит, что 0 вмещается в 16 бит и не предупреждает. Но если поместить int в переменную, то также возникает предупреждение.

ГК InfoWatch — победитель премии CIPR Digital 2025 в номинации «Легенды инфобеза»

Рады поделиться новостью — проект ГК InfoWatch стал победителем премии CIPR Digital в номинации «Легенды инфобеза». Итоги подвели на ЦИПР-2025.

Для участия в премии компания представила кейс с крупным промышленным предприятием, где реализована интеллектуальная система защиты персональных данных сотрудников на базе DLP-системы InfoWatch Traffic Monitor. В основе проекта — новый способ автоматического анализа выгрузок из баз данных, который запатентован в 2024 году.

Разбор представленного на премию кейса — в нашем блоге на Хабре.

Positive Technologies представляет новую версию PT NAD 12.3. 

Главное в продукте: повышение производительности, плейбуки и возможность хранения метаданных в облаке.

🗓️ 5 июня на онлайн-запуске PT NAD 12.3 вы сможете узнать, как команда продукта трансформирует подход к обнаружению сетевых атак за счет централизованного управления, опции хранения метаданных в облаке и плейбуков. 

📌 Добавляйте слот в календарь: 5 июня, 14:00.

В программе:

🔻 Экспертиза: обновленные модули, репутационные списки и плейбуки — чтобы ваша команда могла быстрее реагировать на угрозы;

🔻 Центральная консоль: как сократить затраты на команду мониторинга и контролировать атаки во всех филиалах из единой точки;

🔻 «Облако» vs локальные хранилища: гибкое хранение метаданных для экономии денег без потери скорости;

🔻 Скорость: оптимизация производительности для ускорения анализа угроз и обработки трафика даже в крупных сетях. 

✍️ Регистрируйтесь на онлайн-запуск PT NAD 12.3 по ссылке.

📌 Добавляйте слот в календарь: 5 июня, 14:00

RPA 2025: Как программные роботы меняют бизнес уже сегодня

ITFB Group и Primo RPA приглашают на вебинар, посвященный роботизации бизнес-процессов в 2025 году.

Когда: 10 июня, 11:00

Формат: онлайн

➡️ Зарегистрироваться

Технологии RPA стремительно меняются, и мы разберём, как максимально эффективно использовать их сегодня.

Обсудим:

• Как изменилось отношение к Роботизации за последние годы и почему компании продолжают внедрять RPA.

• Как программные роботы помогают ИТ-отделам справляться с растущим потоком задач, а бизнесу — быстро получать измеримые результаты.

• Российские кейсы: реальный опыт внедрения, ошибки и успехи.

Спикеры:

• Илья Кочетов, директор по технологическому развитию платформы Primo RPA.

• Николай Чекин, директор по развитию отношений с партнёрами ITFB Group.

Для кого вебинар:

• ИТ-директора и руководители цифровой трансформации.

• CEO, коммерческие и исполнительные директора.

• Директора по продажам, клиентскому сервису и маркетингу.

• ИТ-эксперты и интеграторы.

Узнайте, как RPA помогает бизнесу уже сегодня, и какие возможности откроются завтра. Регистрируйтесь сейчас!

➡️ Зарегистрироваться

🦥 RxJS defer — ленивая инициализация Observable

defer — это фабрика, которая создает Observable только при подписке, а не во время объявления. Идеально подходит для:

• HTTP-запросов (чтобы избежать преждевременного выполнения)

• динамических данных (которые должны быть свежими при каждой подписке)

• условных потоков (когда Observable зависит от состояния времени выполнения)

📌 Основные варианты использования

1. Свежие данные при каждой подписке

   const freshData$ = defer(() => of(Date.now()));

   // Новая временная метка при каждой подписке()

2. Работа с изменяемым состоянием

   const token$ = defer(() => of(localStorage.getItem('token')));

   // Всегда получает текущий токен, даже если обновлен

3. Условные наблюдаемые

   const api$ = defer(() => isLoggedIn ? http.get('/user') : http.get('/guest') );

4. Генерация случайного значения

   const random$ = defer(() => of(Math.random()));

   // Новое случайное число на подписку

🚫 Ограничения defer

• нет кэширования → используйте shareReplay, если вам нужно повторно использовать результаты.

• нет отмены запроса → объедините с switchMap/takeUntil для управления отменой

⚡Когда следует выбирать defer вместо обычных наблюдаемых?

• данные должны быть свежими при каждом subscribe()

• cоздание наблюдаемого стоит дорого и должно быть отложено

• поток зависит от изменяемых условий (флаги функций, статус аутентификации и т. д.)

Больше об 🅰️ngular в моём Telegram-канале

Тестируете сайты вручную? Ваша девушка не хочет знакомить вас с родителями? Ваши друзья-курьеры и ваша морская свинка смотрят на вас свысока?

Специально для вас наш эксперт по end-to-end тестам Даниил Дунайчук записал  гайд по старту в E2E атвотестах с помощью популярного фреймворка Playwright.

• Видео №1 «Запуск и селекторы» на YouTube и на VK

• Видео №2 «Проверки и организация кода» на YouTube и на VK

• GitHub репозиторий с примерами из видео

• Список литературы по Playwright и TypeScript

Теперь даже ваша морская свинка разберется 🐹❤️

Шпаргалка о системном дизайне. Саму статью читаем тут: https://habr.com/ru/articles/915376/

На GitHub опубликовали новый инструмент для обнаружения протоколов маскировки TLS Он получил название Aparecium и способен выявлять ShadowTLS v3 и REALITY, которые маскируют зашифрованный трафик под легитимный TLS 1.3.

Aparecium использует особенности реализации TLS, чтобы обнаружить аномалии в поведении протоколов маскировки. ShadowTLS и REALITY, например, часто не обрабатывают отправляемые сервером сообщения NewSessionTicket должным образом, что позволяет выявить их использование.

Серверы на базе OpenSSL отправляют два сообщения NewSessionTicket одинаковой длины в одном TCP‑пакете, что также является характерной особенностью, отсутствующей в протоколах маскировки.

Кибербез из атомной отрасли: как Гринатом участвовал на Positive Hack Days Fest 2025

PH Days Fest — одна из крупнейших площадок по кибербезопасности в России. Для Гринатома участие — это возможность показать подходы, команды и экспертизу в ИБ, а также рассказать, как мы развиваем стажёрские программы для будущих специалистов.

Ниже — короткий разбор.

С чем пришли

Доклады наших экспертов затронули ключевые направления ИБ и цифровых решений в госсекторе:

1. Сергей Живоглядов: Централизованное управление доступами через МСЭ разных вендоров — без хаоса и ручной рутины.

2. Александр Любинский: Цифровизация Северного морского пути — как IT ломает лёд и прокладывает маршруты.

3. Павел Аленчев: Отраслевой VDI «КУРС 2.0» в Росатоме — как построить безопасную и устойчивую виртуализацию.

4. Наталья Пичугина: Дискуссия о карьере в ИБ — как зайти в отрасль, что важно на старте, как подать свой опыт после госсектора.

Как выступили на кибербитве

StandOff — международная кибербитва, где команды защищают или атакуют реалистичные цифровые инфраструктуры.

От Гринатома участвовали:

Amanita — в составе атакующих (red team)

GreenWallTeam — защитники (blue team)

GreenWallTeam взяли сразу несколько номинаций:

- лучшее расследование и обнаружение инцидентов;

- самое быстрое реагирование;

- самая сплочённая команда.

Стенд

На PH Days мы не только делились опытом от наших экспертов, но и рассказывали, как студентам, выпускникам и молодым специалистам попасть в нашу команду через стажёрские программы Росатома. 

Это 8–14 недель практики на реальных проектах, с наставниками, оплатой и гибким форматом работы. На сайте ИТ-стажировок Росатома больше деталей.

А еще с нами был один из наших опорных вузов-партнеров — НИЯУ МИФИ. Вместе разработали игру «Припаркуй ледокол» (симуляция навигации в сложных условиях), показывали на стенде научные фокусы, делали вкусное азотное мороженое, разыгрывали мерч. Не забыли и про юных юных гостей — для них был подготовлен "Морской бой". Но главное — были разговоры по делу: про ИБ, учёбу и карьеру, подходы и инструменты.

Написали подробный разбор запуска второго продукта в рамках челленджа 12 проектов за 12 месяцев - браузерное расширение Save Emails from Gmail as PDF.

В статье рассказали про:

• выбор идеи,

• разработку,

• SEO и размещение на UGC-платформах,

• текущее кол-во пользователей.

👉🏻 https://habr.com/ru/articles/915050/

Конвейер функций в Python

В данном примере мы создаём класс Pipe с перегрузкой метода __or__.

Метод __or__. был добавлен для поддержки синтаксиса X | Y, как замена typing.Union и также используется для указания, что переменная или функция могут принимать несколько различных типов значений.

import typing

int | str == typing.Union[int, str]  # True

class Pipe:

    def __init__(self, value):
        self.value = value

    def __or__(self, other):
        if callable(other):
            return Pipe(other(self.value))
        else:
            raise ValueError("Right operand must be callable")


def multiply_2(x):
    return x * 2


def add_3(x):
    return x + 3


changed_num = Pipe(5) | multiply_2 | add_3  # 5 * 2 + 3
print(changed_num.value)  # 13

Более "сложный" пример добавил в статью как вариант для валидации атрибутов класса.

Задача об анализе ответа сервера

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

Условие
На веб-сервере спрятан флаг. Отправьте правильный запрос, чтобы получить к нему доступ. Будьте внимательны при анализе ответа.

Задача
Найдите флаг — строку в формате slcctf{}. Чтобы выполнить задание, перейдите на страницу http://attention.slcctf.fun/.

Делитесь решением в комментариях. А правильный ответ можно посмотреть в Академии Selectel.

Обновления в Terraform 🆕

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

Рассказываем, где и какие фичи теперь доступны:

1. Kubernetes. Добавили поддержку конфигуратора воркер-нод, тейнтов и лейблов для групп нод, установку аддонов и редактирование манифестов. А также теперь можно передавать идентификатор VPC-сети при создании кластера и фильтровать пресеты по локациям.

2. S3. Добавили поддержку конфигуратора для стандартного и холодного хранилища.

3. Балансировщики. Добавили поддержку плавающих IP-адресов и новые параметры для гибкой настройки: maxconn, connect_timeout, client_timeout, server_timeout, httprequest_timeout.

4. И, конечно, не обошлось без багфиксов и улучшений. Оставим для вас списком:

• Теперь можно менять логин в twc_database_user

• Поправили создание сервисов с токеном доп пользователя

• Добавили обработку ошибок при устаревших типах баз данных

• Исправили проблемы с кластерами PostgreSQL и Redis

• is_autoscaling в Kubernetes больше не обязателен

• В документации по базам данных добавили пример привязки к приватной сети

Уже бегу тестить обновы →

💥 Майская версия Gramax 💥

Что нового мы добавили в open source-платформу для управления технической документацией Gramax.

• ИИ-поиск для портала документации. Раньше поиск по документации был ограничен точным совпадением слов, теперь можно подключить ИИ-поиск от любого провайдера (например, OpenAI, Anthropic и др.) и искать по смыслу. Даже при неточном запросе пользователь получит релевантные результаты. Поддерживается как облачное подключение, так и запуск собственного сервера — для тех, кому важна приватность.

• ИИ для создания и редактирования текста. В пространстве редактора можно также подключить ИИ. Он позволит написать текст с нуля: например, если не удается придумать структуру статьи. А также отформатировать существующий текст. В случаях, если его нужно сократить, сделать более формальным или структурированным.

• Шаблоны. Добавили возможность создавать шаблоны со свойствами и использовать их в статьях. 

• Заметки. Теперь можно прямо в каталоге сохранять идеи и предложения для изменения документации. Заметки сохраняются в репозитории, но не отображаются на портале для чтения. 

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

• Выбор формата для исходных файлов. Добавили 2 дополнительных формата хранения статей — XML и GitHub Flavored Markdown. Изменить формат можно в настройках каталога.

• Вход для внешних пользователей в Gramax Enterprise Server. Добавили возможность настроить вход на портал для чтения по почте: таким читателям не нужно иметь учетную запись в SSO. Достаточно указать свою почту при входе и ввести одноразовый код.

О других изменениях читайте в статье — https://gram.ax/resources/docs/whats-new

Чек-лист для проектирования API

За 5 лет, что я проектирую API, вывела для себя шесть базовых принципов, которых стараюсь придерживаться:

1. Проектировать для потребителя

   • Ориентироваться на потребности клиентов API, а не на простоту реализации или устройство базы данных. Об этом, кстати, подробно написано в отличной книге Лоре Арно “Проектирование веб-API”.

   • Учитывать интересы всех клиентов. Не забывать, что могут появиться новые клиенты.

   • Сложную логику реализовывать на сервере. Искать баланс между универсальностью API и нагрузкой на клиента, исходя из реалий проекта.

2. Проектировать понятные API-схемы

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

   • Избегать обобщающих наименований, типа “flag”. Описывать в названии, какой бизнес-смысл несет этот параметр или метод. Например, флаг с признаком пустой упаковки можно назвать “isEmpty”.

   • Человек при прочтении схемы должен без дополнительной документации понять, зачем нужен этот API и что он делает.

   • Отдавать адекватные текстовые коды ошибок, из которых будет однозначно понятно, что поправить в запросе для успешного его выполнения. Например, отдавать не 400 BAD_REQUEST, а 400 PRODUCT_NOT_FOUND.

3. Принять конвенции и придерживаться их

   • Использовать везде либо snake_case, либо camelCase, либо kebab-case, не менять правила от метода к методу.

   • Стандартизировать формат ошибок - во всех методах отдавать их в одинаковой структуре.

   • Если это HTTP, то зафиксировать, в каких случаях какие коды ответов будут возвращаться. Например, иногда возвращается всегда 200, а потребители ориентируются только на тело ответа.

   • Договориться о формате версионирования API.

   • Стандартизировать типы данных: формат дат, UUID и пр.

4. Думать о безопасности, производительности и надежности

   • Использовать аутентификацию, авторизацию и ACL. Разграничивать доступ на уровне конкретных методов и даже параметров.

   • Оценивать количество запросов и объем ответов.

   • Индексировать БД по тем полям, по которым собираются выборки данных для API.

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

   • Делать обратную совместимость везде, где это возможно.

5. Документировать

   • Сначала писать документацию, а только потом разрабатывать. Такой подход минимизирует количество ошибок и проблем с API.

   • Помечать изменения тегами задач и, при необходимости, цветом.

   • Описывать логику работы методов/топиков/очередей. При необходимости добавлять диаграммы последовательности и маппинги данных.

6. Мониторить и анализировать

   • Понимать, какие методы как часто вызываются и как быстро работают. Как быстро обрабатываются сообщения в очередях и топиках, какое их количество и размеры. Это важно для принятия решений о дальнейших доработках API.

   • Смотреть в консоли разработчика на проде, как быстро отрабатывают те или иные запросы и т.д.

   • По возможности настраивать системы мониторинга и алертинга. Это помогает прогнозировать рост нагрузки и отслеживать эффективность системы.

У каждого API‑проектировщика со временем появляется свой набор правил. Было бы интересно сравнить — добавляйте свои пункты в комментариях.

Другие мои материалы можно почитать в телеграм-канале breakfront.

ВЫШЛА КНИЖКА САЙМОНА ПРИНСА

Как обещал, сообщаю о выходе в издательстве "Бомбора" на русском языке (в моем переводе) монографии Саймона Принса, которую я неоднократно упоминал в своих публикациях. Оригинал называется "Understanding Deep Learning (2023)", перевод вышел под заглавием "Машинное обучение. От основ до продвинутых моделей (2025)".

Судя по тому, что на Литрес книга передана 19 мая 2025 года, из типографии вышла совсем недавно.

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

В "электронных библиотеках" книжки пока не вижу, когда украдут увижу - сообщу дополнительно.

Буду признателен за любые отклики на книгу, в том числе за указания на ошибки перевода, просмотры, опечатки и все в этом роде.

Приглашаем на бесплатный вебинар «Принципы построения архитектуры фронтенд-приложений».

Разберём, что собой представляет архитектура приложений, а также какие задачи она решает и какие ограничения накладывает на разработку. Также детально обсудим три ключевых принципа для фронтенда, включая методологии Solid и Grasp, которые помогут вам создать более эффективные и масштабируемые проекты.

📅 Дата: 05.06.2025

⏰ Время: 17:00-19:00 (Мск)

Содержание:

✔️ Архитектура

✔️ Solid

✔️ Grasp

👨‍🎓 Спикер: Щербаков Александр — эксперт в области фронтенд-разработки.

✍️ Записаться на вебинар