Бэкенд

Чек-лист для проектирования 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.

Бесплатный вебинар в рамках нового проекта FinOps

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

Поговорим об этом на бесплатном вебинаре в рамках нового проекта FinOps.

11 июня, в 17:00 по МСК встречаемся с технологическим евангелистом VK Cloud Станиславом Погоржельским и будем обсуждать облачные решения: как снизить затраты и повысить эффективность.

Вместе:

• разберём частые ошибки компании при использовании облачных технологий;

• оценим важность сетевых сервисов;

• посмотрим на примере ПО, как неверный выбор ресурсов для приложения может привести к непредсказуемым последствиям;

• обсудим резервное копирование и как его игнор может поставить под угрозу весь бизнес.

➡️ Занять место на вебинаре — в боте.

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

Устройство компилятора (кратко) на LLVM
Компилятор - инструмент конвертации исходного кода, написанного на высокоуровневом языке программирования в машинный код, который может исполнять компьютер.

Компилятор делится на 3 этапа:

• FRONTEND - анализирует текст исходного кода и преобразует его в IR.

• MIDDLE - анализирует и оптимизирует этот сгенерированный код IR.

• BACKEND - преобразует IR в машинный код.

Сам компилятор, и собственно язык программирования состоит из нескольких частей.

Lexer - лексер

Лексер сканирует и превращает сырой текст в токены. То есть сам исходный код разбиваеты на набор токенов (такие как литералы, идентификаторы, ключевые слова, операторы, разделители)
Лексер читает исходный код символ за символом и идентифицирует последовательности символов, соответствующие определённым правилам языка.

Парсинг

Парсинг немного сложнее чем лексический анализ. Существует множество паресров и парсеров-генераторов.

Парсеры в компиляторах обычно принимают входные данные в форме токенов и строят определенное дерево - AST или дерево парсинга.

Обычно компиляторы строятся из множества маленьких компонентов, которые берут входные данные, меняют их или преобразуют их в различные выходные данные. Это одна из причин, по которым функциональные языки хорошо подходят для создания компиляторов. Другие причины — прекрасное сопоставление с эталоном и довольно обширные стандартные библиотеки. Прикольный факт: первая реализация компилятора Rust была на Ocaml.

Советую держать эти компоненты как можно более простыми и автономными — модульность сильно облегчит процесс. По-моему, то же можно сказать и о многих других аспектах разработки ПО.

AST

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

IR

Эта часть занимается созданием [[1.2 IR]]. Через примитивы LLVM мы можем сгенерировать промежуточное представление. Каждому типу в AST дается метод, называемый codegen, который всегда возвращает объект значение LLVM, используемый для представления одного регистра присваивания (single assignment register), который является переменной для компилятора, которая может быть назначена только один раз. Интересно, что в этих примитивах IR то, что в отличии от ассемблера, они не зависят от какой-либо конкретной архитектуры машины, и это значительно упрощает работу для разработчиков языков, которым больше не нужно сопоставлять вывод в набор инструкций процессора. Теперь, когда фронтенд может генерировать IR, инструмент LLVM Optimizer используется для анализа и оптимизации сгенерированного кода. Он выполняет несколько проходов по IR и выполняет такие действия как устранение мертвого кода и скалярная замена агрегатов, и, наконец, это приводит нас к бекенду, где мы пишем модуль, который принимает IR в качестве входных данных, который выдает объектный код, который может работать на любой архитектуре.

Декоратор, Фасад и их основные преимущества

В новом эпизоде отрытого курса «Паттерны и практики написания кода» вместе с бэкенд-инженером Авито Юрой Афанасьевым продолжаем тему Структурных Паттернов. Разберём два новых подхода — Декоратор и Фасад, поговорим про UML-диаграммы паттернов и их реализацию в коде, а также рассмотрим основные преимущества подходов.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Как грамотно управлять IT-инфраструктурой в облачном сервисе?

Облака — это уже не будущее, а настоящее. Можно развернуть сервер за минуты, не тратясь на железо, можно быстро адаптировать инфраструктуру под нагрузку. Главное — знать, как это делать правильно. Облака — это про гибкость, масштабируемость и экономию ресурсов.

👉 Слёрм совместно с Selectel, ведущим провайдером IT-инфраструктуры, подготовил бесплатный курс «Работа с облаком и IT-инфраструктура проекта».

На курсе практикуемся на платформе Selectel и разбираем важные темы: от подбора облачного сервиса до сохранения медиафайлов. После обучения вы сможете:

• подбирать оптимальные параметры виртуальных серверов;

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

• развёртывать проекты на облачных мощностях;

• использовать облачные инструменты в реальных задачах.

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

Использование MVC-фабрики в плагинах Joomla 5

Обычно, концепция Model‑View‑Controller используется в компонентах Joomla, но я хочу поделиться опытом её применения в плагинах.

Для чего это надо? — Сделать код более простым и понятным.

Задача плагина Joomla — подписываться на события и выполнять определенные действия. Но не стоит размещать весь код в классе плагина, лучше разделить его на несколько классов. Особенно, если для ваших задач Joomla предлагает готовые родительские классы.

Почему я предлагаю использовать MVC-фабрику? - Она не только создаёт экземплр класса, но и устанавливает основные зависимости из DI контейнера.

Например, плагин должен ответить на AJAX-запрос и вернуть массив данных. Для этого надо написать свой класс модели, наследующий Joomla\CMS\MVC\Model\ListModel.

Как это сделать? - Примерно так же как и в компонентах.

Классу плагина подключаем трейт Joomla\CMS\MVC\Factory\MVCFactoryAwareTrait.

В файле provider.php плагина регистрируем сервис-провайдер MVC-фабрики и передаём ему пространство имён плагина.

$container->registerServiceProvider(new MVCFactory('Joomla\\Plugin\\RadicalMart\\WishboxCdek'));

Устанавливаем плагину экземпляр фабрики, полученный из контенера.

$plugin->setMVCFactory($container->get(MVCFactoryInterface::class));

В src папке плагина, создаём папку Administrator, в ней папку Model и в ней файл с классом модели. То есть классы моделей будут расположены по пути Root\plugins\radicalmart\wishboxcdek\src\Administrator\Model.

Обратите внимание на папку Administrator, метод создания моделей обязательно требует либо Site либо Administrator в namespace.

namespace Joomla\Plugin\RadicalMart\WishboxCdek\Administrator\Model;

Ещё в класс модели надо установить свойство option:

protected $option = 'com_radicalmart';

Теперь мы можем получать экземпляр модели плагина Orders , следующим образом:

/** @var OrdersModel $ordersModel */
$ordersModel = $app->bootPlugin('wishboxcdek', 'radicalmart')
	->getMVCFactory()
	->createModel('Orders', 'Administrator');

В своём плагине я наследовал класс модели от BaseDatabaseModel, для работы с другими классами может потребоваться переопределение каких-либо свойств и методов.

Задачи Структурных Паттернов: Адаптер и Компоновщик — в чём суть?

В пятой серии открытого курса «Паттерны и практики написания кода» мы начинаем новую объёмную тему — изучение Структурных Паттернов. Она состоит из семи подходов. В эпизоде вместе с бэкенд-инженером Юрой Афанасьевым погрузимся в особенности работы Адаптера и Компоновщика.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

«Мы же всё пофиксили!» — но инциденты повторяются?

6 признаков «токсичного» процесса безопасности:

• В CI/CD нет автоматических проверок безопасности, только ручные ревью

• Уязвимости находят не сканеры, а пользователи в проде

• Отчёты от SAST/SCA просто лежат в почте или Jira

• Dev и Sec не взаимодействуют напрямую, всё через багтрекер

• После каждого инцидента «делаем выводы», но всё повторяется

• Любая интеграция в пайплайн вызывает страх: «только бы не сломать»

Это не история про «плохую команду» или «плохих людей». Это признаки системы, в которой безопасность живёт отдельно. От этого страдают все: Dev, Sec, Ops и бизнес.

Что можно сделать:

• Настроить автоматические проверки в CI/CD

• Добавить чеклист ревью по безопасности

• Согласовать зону ответственности за уязвимости

• Наладить процесс triage: кто, когда и как разбирает отчёты

• Обсудить на ретроспективе: как снизить риск, а не тушить

📎 А если вы хотите собрать из всего этого рабочую систему — приходите на DevSecOps Bootcamp. Мы не говорим «ставьте сканер, и будет хорошо». Мы помогаем выстроить устойчивый DevSecOps-процесс внутри вашей команды.

Подробности — на сайте.

В Облаке Рег.ру запустили услугу резервного копирования

Добавили в облачной платформе возможность автоматизированного создания, хранения и восстановления резервных копий. Этот релиз — первый шаг по запуску полноценного Backup as a Service в Облаке Рег.ру.

Что внутри нового сервиса:

• настройка расписания бэкапов и снапшотов;

• удаленное хранение бэкапа;

• восстановление сервера до нужного состояния, если возникнет такая необходимость;

• создание снапшотов. 

Теперь пользователи могут сами настраивать политику хранения бэкапа — от ежемесячной до ежедневной. На случай локальных сбоев предусмотрели защиту от потери данных — консистентные резервные копии хранятся в удаленном объектном хранилище S3. Отсюда и повышенная катастрофоустойчивость инфраструктуры пользователей в целом. Тарификация происходит по модели pay-as-you-go за фактический объем хранения.

Следите за нашими новыми обновлениями!

До и после DevSecOps: что реально меняется

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

⚠️ До DevSecOps

• Уязвимости всплывают на продакшене

• Сканы лежат в почте

• Ревью на «чутьё»

• Безопасность — задача ИБ-отдела

• Реагируем, когда уже поздно

Можно жить и так. Но в какой-то момент команда устанет тушить, а бизнес — терять.

Хорошо, что сейчас можно иначе.

✅ После DevSecOps

• Уязвимости отсеиваются ещё на этапе pull request

• У каждого отчёта — приоритет и ответственное лицо

• Ревью с чеклистами и знаниями по secure coding

• У всей команды есть зоны ответственности

• Предотвращаем — автоматически и по процессу

🔍 Всё начинается с небольших сдвигов:

— добавить pre-commit хуки,

— внедрить триаж для уязвимостей,

— вынести работу с секретами в Vault.

📎 Всё это — и десятки других шагов — мы собираем в стройную систему на DevSecOps Bootcamp.

Для чего нужен атрибут useglobal в полях форм и как его применять в Joomla 5

В официальной документации есть краткая статья Conditional Field Display Customizing Forms Based on Global Settings, у меня не получилось перевести её дословно, поэтому расскажу своими словами.

Давайте разберёмся что это такое на примере компонента com_contact. Посмотрим настройки компонента.

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

Видим что параметр Contact Category в положении Hide (у вас может быть в другом).

Теперь откроем страницу создания/изменения контакта и перейдём на вкладку Display.

Мы видим что параметр Category имеет первый вариант Use Global (Hide). То есть нам не надо помнить значение из общих настроек компонента, оно перед нами. Если мы изменим его в компоненте, то оно изменится и здесь.

Как это использовать разработчику компонентов

У меня есть простой компонент для экспорта товаров из JoomShopping в XML com_wishboxjshoppingxmlexport.

Добавлю в настройки компонента поле test_mode в файле: Root/administrator/components/com_wishboxjshoppingxmlexport/config.xml

<field
		name="test_mode"
		type="list"
		label="COM_WISHBOXJSHOPPINGXMLEXPORT_FIELD_TEST_MODE_LABEL"
		default="0"
>
	<option value="0">JNO</option>
	<option value="1">JYES</option>
</field>

И добавлю такое же поле в сущность (item) в файле: Root/administrator/components/com_wishboxjshoppingxmlexport/forms/item.xml

<field
		name="test_mode"
		type="list"
		label="COM_WISHBOXJSHOPPINGXMLEXPORT_FIELD_TEST_MODE_LABEL"
		default="0"
>
	<option value="0">JNO</option>
	<option value="1">JYES</option>
</field>

Добавим полю в форме Item атрибут useglobal="true"

<field
		name="test_mode"
		type="list"
		label="COM_WISHBOXJSHOPPINGXMLEXPORT_FIELD_TEST_MODE_LABEL"
		default="0"
        useglobal="true"
>
	<option value="0">JNO</option>
	<option value="1">JYES</option>
</field>

Готово! На странице создания/изменения Item‑а экспорта у поля test_mode появилась опция Use Global (Yes). То есть достаточно добавить атрибут useglobal="true".

Из каких глобальных настроек берётся значение

• из настроек компонента (компонент определяется параметром option в URL, кроме редактирования пункта меню, для меню подставляется компонент из ссылки пункта меню);

• из общих настроек Joomla если не получили из настроек компонента.

В каких типах полей стандартных полей работает этот атрибут

• ListField — Добавляется опция Use Global (...);

• NumberField — Значение из глобальных настроек отображается как placeholder;

• TextField — Placeholder.

А так же во всех полях, которые наследуют одно их вышеперечисленных.

Я устал от форматирования JSON файлов

Я много и часто просматриваю JSON-файлы: от конфигураций сервисов до API ответов и логов. Каждый раз, открывая очередной файл, я форматирую содержимое, чтобы было удобнее читать (ведь JSON не только machine-readable, но и human-readable). И каждый раз я грущу, что все сервисы (онлайн, встроенные средства IDE и даже плагины) предоставляют лишь две крайности: форматировать всё или ничего (минифицировать в одну строку).

Но что, если я хочу отформатировать JSON лишь до определённого уровня? Что, если у меня есть огромный список словарей (возможно, даже глубоких), который при форматировании выглядит как-то так:

[
    {
        "id": 1,
        "name": "Alice",
        "birthday": {
            "day": 5,
            "month": 4,
            "year": 1983
        }
    },
    {
        "id": 2,
        "name": "Bob",
        "birthday": {
            "day": 6,
            "month": 2,
            "year": 1945
        }
    },
    {
        "id": 3,
        "name": "Eve",
        "birthday": {
            "day": 10,
            "month": 11,
            "year": 1978
        }
    }
]

Что, если я хочу оставить каждый словарь в более компактном (не совсем минифицированном) виде? Например, таком:

[
    {"id": 1, "name": "Alice", "birthday": {"day": 5, "month": 4, "year": 1983}},
    {"id": 2, "name": "Bob", "birthday": {"day": 6, "month": 2, "year": 1945}},
    {"id": 3, "name": "Eve", "birthday": {"day": 10, "month": 11, "year": 1978}}
]

Или я хочу, чтобы в каждом словаре развёрнуты были только внешние ключи?

[
    {
        "id": 1,
        "name": "Alice",
        "birthday": {"day": 5, "month": 4, "year": 1983}
    },
    {
        "id": 2,
        "name": "Bob",
        "birthday": {"day": 6, "month": 2, "year": 1945}
    },
    {
        "id": 3,
        "name": "Eve",
        "birthday": {"day": 10, "month": 11, "year": 1978}
    }
]

Да, многие текстовые редакторы вроде Sublime Text или VS Code дают возможность свернуть контент до определённого уровня. Но что, если я хочу оставить файл в этом промежуточном виде и просматривать его прямо в терминале, подключившись по ssh? Или я хочу посмотреть файл на гитхабе с телефона? Да, возможно, мои вкусы весьма специфичны, но в существующих реалиях я вынужден грустно довольствоваться лишь полностью развёрнутым вариантом (или делать это вручную). Встроенные средства форматирования JSON в JS или Python также не предоставляют простой возможности ограничить глубину (либо я так и не научился их готовить).

Поэтому я собрался с силами и написал свой форматтер с возможностью ограничить глубину. Помимо базового функционала вроде валидации, минификации и настройки количества отступов, в нём есть настройка максимальной глубины (по умолчанию она равна нулю, что соответствует привычному форматированию без ограничений).

Да, он вряд ли подойдёт, чтобы редактировать на лету гигантские JSON файлы. И он уж точно не пытается стать убийцей какого-либо из существующих онлайн сервисов. В первую очередь он призван решить мою проблему: сделать форматирование JSON чуточку более управляемым. А если и вы сталкивались с подобной проблемой, буду рад, если сервис поможет и вам!

Задача о габаритном файле и ошибке

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

Условие

В компании «Доки.Онлайн» выкатили обновление: теперь пользователи могут загружать PDF-файлы с отсканированными договорами. Все работало отлично в локальной среде — разработчик протестировал загрузку больших файлов, убедился, что API обрабатывает их корректно, и спокойно отправил изменения в продакшн.

Но радость была недолгой. На боевом сервере при попытке загрузить файл система выдавала ошибку 413 Request Entity Too Large. Причем происходило это до того, как пользователь получал какой-либо отклик от самого приложения.

Разработчик Геннадий Завров начал искать причину. Он проверил логи всех четырех компонентов системы:

• фронтенда;

• API Gateway (определяет, в какой микросервис послать запрос);

• микросервиса загрузки файлов;

• микросервиса обработки документов.

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

Геннадий начал подозревать сетевые сбои, перегрузку API Gateway и баг в коде фронтенда. Однако простые тесты с маленькими файлами работали стабильно. Проблема проявлялась только при загрузке чего-то «потяжелее».

В какой-то момент он задал себе вопрос: а точно ли запрос доходит до приложений?

Задача

Почему при загрузке большого файла система возвращает ошибку 413, если сами сервисы даже не видят входящий запрос? Кто может остановить запрос еще до бэкенда?

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

Порождающие паттерны Prototype и Singleton: а минусы будут?

В новой серии открытого курса «Паттерны и практики написания кода» мы завершим изучение порождающих паттернов знакомством с двумя шаблонами — паттерном Прототип и паттерном Синглтон. Вместе с бэкенд-инженером Юрой Афанасьевым разберемся, почему паттерн Prototype — простой в реализации — используется редко, а паттерн Singleton — самый критикуемый.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Разработчики в одиночку дизраптят вертикальные рынки создавая AI-native компании

Помимо самого ИИ, который как снег на голову, мы находимся на пороге беспрецедентного передела бизнес-рынков.

Лидеры мнений говорят, что AI-native компании будут достигать соответствия продукта рынку быстрее, всего с одним основателем, но с более высоким уровнем автоматизации, чем когда-либо прежде.

Консалтеры предсказывают появление лидеров рынка “из ниоткуда”, управляемых одним человеком. И это в общем то уже не будущее, сегодня один разработчик с правильными навыками может в одиночку создать продукт, способный конкурировать с многомиллиардными корпорациями, а уж с малым бизнесом и подавно. И я как раз в основном про МСП.

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

Пару слов о себе. Я более 20 лет в инновационном и стратегическом консалтинге, а последние 5 лет параллельно ментор стартапов в Сколково. Только за последние несколько лет через меня прошло более полутора сотен продуктовых команд и стартапов, с которыми мы обсуждали как развивать, усиливать или менять их продукт с приходом ИИ.

Год назад я придумал и затем запустил движение айвенторов, технологических предпринимателей нового поколения, которые готовятся к реализации новой бизнес-модели соло-предпринимателей, окруженных пулом ИИ-агентов и MAS.

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

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

Но сегодня об иллюзиях.

Зона иллюзий: Какие мифы породила эта революция?

Миф первый: "Любой может создать AI-стартап"

Реальность жестче. Порог входа сместился с денег на компетенции. Да, вам больше не нужны миллионы долларов стартового капитала. Но теперь нужно разбираться в архитектуре LLM, понимать ограничения различных моделей, уметь проектировать “новую автоматизацию” и работать с векторными базами данных. Плюс RAG, управление контекстом в MAS, оптимизация inference.

Это уже не классическое программирование, а скорее инженерия интеллектуальных систем. Т.е. технический порог не исчез, он трансформировался.

Миф второй: "Теперь всё просто, нажал кнопку и готово"

На самом деле, AI-native продукты требуют глубокого понимания предметной области. Создать чат-бота может каждый, но создать AI-агента, а тем более мультиагентную систему, которая реально решает бизнес-задачи, – это уже искусство. Нужно знать, как настроить модель под конкретные задачи, как обучить её на ваших данных, как интегрировать с существующими системами.

Миф третий: "Конкуренция стала проще"

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

Миф четвертый: "Независимость от крупных корпораций"

Ирония в том, что AI открывает рынки, но делает игроков более зависимыми от крупных вендоров. OpenAI, Google Cloud, Azure – это все новые монополисты. Один измененный API, один повышенный тариф, и ваш новый бизнес может оказаться под угрозой. Независимость обернулась новой формой зависимости. Однако, тренд на демократизацию интеллекта, решает и эту проблему.

Что я еще упустил из иллюзий?

Это по сути анонс большой статьи, в которой раскрою тему подробно. Опубликую в понедельник.

unraisable exceptions в питоне

Мы все с вами привыкли, что в питоне можно "зарайзить" исключение в любой момент: raise Exception
Но, что если в какой-то момент времени мы не можем вызывать исключение?

Простейший пример: что произойдет при запуске такого скрипта?

# ex.py
class BrokenDel:
    def __del__(self):
        raise ValueError('del is broken')

obj = BrokenDel()
del obj
print('done!')  # будет ли выведено?

Тут может быть два варианта:

1. Или del вызовет ValueError и программа завершится

2. Или случится какая-то магия, ошибка будет вызвана, напечатается, но программа продолжится

Ну и так как мы с вами на том канале, где мы с вами, то конечно же будет второй вариант.

» python ex.py
Exception ignored while calling deallocator :
Traceback (most recent call last):  File "/Users/sobolev/Desktop/cpython/ex.py", line 3, in __del__    raise ValueError('del is broken')
ValueError: del is broken
done!

Знакомьтесь – unraisable exceptions 🤝

Как оно работает?

В некоторых местах C кода у нас есть необходимость вызывать исключения, но нет технической возможности. Пример, как выглядит упрощенный dealloc для list?

static void
list_dealloc(PyListObject *op)
{
    Py_ssize_t i;
    PyObject_GC_UnTrack(op);  // убираем объект из отслеживания gc
    if (op->ob_item != NULL) {
        i = Py_SIZE(op);
        while (--i >= 0) {
            // уменьшаем счетчик ссылок каждого объекта в списке
            Py_XDECREF(op->ob_item[i]);  
        }
        op->ob_item = NULL;
    }
    PyObject_GC_Del(op);
}

А, как вы можете знать, чтобы в C коде вызвать ошибку, нужно сделать две вещи:

• Взывать специальное АПИ вроде PyErr_SetString(PyExc_ValueError, "some text")

• И вернуть NULL как PyObject * из соответствующих АПИ, показывая, что у нас ошибка. Если вернуть NULL нельзя, то мы не можем поставить ошибку в текущий стейт интерпертатора. А тут у нас void и вернуть вообще ничего нельзя. Потому приходится использовать вот такой подход с unraisable exception

Ошибку мы "вызываем" через специальные АПИ:

• PyErr_WriteUnraisable

• PyErr_FormatUnraisable

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

В питоне оно используется где-то 150 раз. То есть – прям часто. Примеры:

• Ошибки при завершении интерпретатора, попробуйте сами:

import atexit
def foo():
    raise Exception('foo')
atexit.register(foo)

• Ошибки внутри sys.excepthook

• Ошибки внутри gc

• Ошибки внутри логики установки ошибок (вдруг память кончилась, например) 🌚️️️️

• И многое другое

Пользовательское АПИ

Ну и конечно же, есть специальный хук для обработки таких ошибок: sys.unraisablehook

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

Например, pytest использует кастомный хук, чтобы валить тесты при возникновении такой ситуации. Что логично.

Нравится контент про технику и устройство технологий? Присоединяйся к каналу @opensource_findings в телеге; там много такого.

Обсуждение: знали ли вы про такую особенность? Приходилось ли где-то в мониторинге особо настраивать?

На нашу материнскую компанию Southbridge была совершена атака 😱

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

Так родился интенсив DevSecOps Bootcamp, до которого остался всего месяц.Мы активно готовимся и ждём команды, готовые встраивать безопасность в свои процессы.

4 июня встречаемся на бесплатном вебинаре, где разберём:

• Dev vs Sec: всё ещё не разговаривают — почему?

• Что DevSecOps может, а что не может?

• Где DevSecOps реально помогает бизнесу, а где мешает?

• Time to market — вечная басня, которая не про DevSecOps

• Где в DevSecOps сейчас Ops, если DevSecOps это AppSec?

А ещё — расскажем больше про интенсив, и как мы с его помощью хотим повлиять на инженерную культуру.

Когда: 4 июня в 19:00 мск

Занять место на вебинаре — через бота.

Каковы задачи Абстрактной Фабрики?

Новая серия курса «Паттерны и практики написания кода» целиком посвящена разбору достаточно громоздкого паттерна — Абстрактной Фабрики. Вместе с бэкенд-инженером Юрой Афанасьевым на примерах разберем, что это такое и как она реализуется.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Isar и еще 8 систем сборки для создания дистрибутива на Linux

Isar — система сборки, представляющая собой набор скриптов для создания пакетов и дистрибутивов на базе Debian с возможностью настройки. Организация проекта Isar похожа на Yocto Project, для сборки используется Bitbake.

Перед сборкой можно настроить параметры файловой системы, ядра, модификации списка пакетов (добавление и удаление пакетов, в том числе и собственных, изменение существующих пакетов). Систему сборки разрабатывает компания ilbers GmbH.

Архитектура системы

Так как Isar основан на Bitbake, архитектура решения состоит лишь в нескольких слоях для Bitbake, реализующих сборку и установку пакетов в соответствии с конфигурацией сборки. В основе всех этих слоев и рецептов лежат утилиты Debian Build Toolchain, которые ответственны за непосредственную сборку пакетов, разрешение зависимостей и т.д.

Особенности решения

• Аналогично Yocto требует усилий на начальных этапах для освоения инструмента.

• Поддерживает загрузку готовых пакетов из репозиториев Debian.

• Подходит для embedded-дистрибутивов, где необходимо сочетание Debian-экосистемы и глубокой конфигурации.

О других embedded- и desktop-решениях решениях рассказали студенты и преподаватели СПБГЭТУ «ЛЭТИ» в обзоре систем для создания Linux-дистрибутивов.  

Полезное про учёбу в Слёрме

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

Как купить обучение выгодно? 4 варианта, как приоберсти курс в Слёрме и сэкономить. 

Как убедить начальника купить курс? Мы уже рассказывали о том, что вы можете попросить работодателя оплатить обучение на профильных курсах. Но как это организовать? Куда идти и что говорить? Рассказываем в статье. 

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

Как выбрать комфортный формат обучения? Мы указываем в своих материалах формат курса: поток или видеокурс, но не всегда эта разница понятна. Разбираем подробнее, чтобы вы точно определились, какой вариант для вас удобнее. 

Корпоративное обучение IT-команд. Рассказываем о специальных условиях для корпоративных клиентов. Если вы тимлид, HR, CTO или L&D специалист в IT-компании — эта информация для вас.

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

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