Программирование *

Обновляем платформу 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.

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

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

Итак, есть ли в этом коде проблема кроме 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 в переменную, то также возникает предупреждение.

Конвейер функций в 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

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

Открытый проект Cursor Free VIP позволяет получить бесплатный доступ к нейросети Сursor Pro для исследовательских целей. Решение я активирует бесконечный триал с откатом данных.

Новое средневековье.

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

Известно, что когда Аристотель написал, что у мухи 8 ног, то почти полторы тысячи лет это утверждение воспроизводилось со ссылками на авторитет, и никому в голову не приходило пересчитать (ну он там вроде на самом деле писал про подёнок с 4 ногами и 4 крыльями, но кому какое дело). Сейчас эти времена вернулись, любой ребёнок спросит: “Алиса, сколько ног у мухи?” вместо натурного эксперимента.

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

Пруфов не будет.

Несмотря на кадровый голод в IT занято огромное количество лишних людей деятельность которых в общем-то бесполезна. А все что бесполезно как известно приносит только вред. Возьмем к примеру новомодную отрасль UI/UX которая по задумке должна улучшать пользовательский опыт - так называемый "экспириенс". На планете существует целый зоопарк разных форматов дат: 1 ноября 2000, 01.11.2000 и т.д и т.п. Это мелочь, но и в мелочах можно тот самый "экспириенс" взять да и улучшить. И он был повсеместно "улучшен" до формата "3 года назад". Как правило без какой либо возможности вернуть нормальную дату.

Теперь просто хочется простереть руки к небу и крикнуть за что это мне?

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

Опыт использования Claude для написания готового приложения

Ну вот и я сподобился - написал приложение полностью на Claude.

Приложение на SwiftUI, не enterprise, но достаточно сложное, из категории Favorite.

Начал на Claude Sonnet 3.7, потом вышел 4, закончил на нем.

Всего 1156 строк кода и без ошибок!

Естественно было несколько итераций. Причём практически все - это уточнение промта.

Кода он наворотил много, по мне так можно было и проще. Но он уж развернулся по полной - структуры, классы, вью, перечисления, состояния, published, state и т.д. и т.п.

Как оно там внутри вертится крутится даже не смотрел. Главное - работает и этого достаточно.

В общем, впечатлён. Не ожидал. Предполагал, что будут ошибки, заторы, что придётся с ними разбираться. Ан нет, все зашло без глюков, с первого раза.

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

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

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

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

Как не только быстро развернуть бота в облаке без сложных настроек, но и сэкономить на его поддержке? Обсудим на предстоящем вебинаре 🖥️

Архитектор решений Cloud.ru Илья Смирнов расскажет:

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

• в чем особенность развертывания бота;

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

А еще покажет демо по настройке вебхука для Telegram-бота, обработке событий и хранению данных в облаке.

📆 Когда: 5 июня в 11:00 мск

📍 Где: онлайн

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

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

Я устал от форматирования 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 чуточку более управляемым. А если и вы сталкивались с подобной проблемой, буду рад, если сервис поможет и вам!

TUI Rust, это Хабр. Хабр, я нашёл тебе годноту.

По этой ссылке https://www.youtube.com/watch?v=rWMQ-g2QDsI обнаружилось видео (11:16) с тучей прелюбопытнейших отсылок объединённых идеей использования Rust для написания консольных приложений.

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

• не плоди сущности без необходимости

• используй меньше чтобы сделать больше

• велик C и Rust наследует ему

• всё преходяще, кроме вечного

Рекомендуется к ознакомлению вкатунам и начинающим пользы ради, а остальными удовольствия для.

Конкретика: Uutils, Fish, Nushell, Ripgrep, Fd, Bat, Eza, Zoxide, Xh, Zellij, Gitui, du-dust, dua, starship, yazi, hyperfine, evil-helix, bacon, cargo-info, fselect, ncspot, rusty-man, delta, ripgrep-all, tokei, wiki-tui, just, mask, mprocs, presenterm, kondo, bob-nvim, rtx, espanso.

«Первая Форма» заняла третье место в рейтинге no-code платформ CNews

Портал Cnews опубликовал рейтинг и обзор российских no-code платформ. No-code — это способ разработки ПО без написания кода и участия программиста. С помощью встроенного конструктора и шаблонов в таком решении можно реализовать работу с задачами, кастомизировать интерфейс и не только.

При составлении рейтинга эксперты учитывали следующие критерии:

1. Возможности для автоматизации бизнес-процессов.

2. Безопасность и управление доступами.

3. Интерфейс и персонализация.

4. Интеграция, документы и обработка данных.

5. Аналитика, отчётность и визуализация.

BPM-система «Первая Форма» заняла в рейтинге третье место. Эксперты высоко оценили её возможности для автоматизации, интерфейс и множество инструментов для работы с данными. Решение позволяет:

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

• расширять библиотеку функций под потребности компании;

• просматривать логи по сервисам для оперативного решения проблем;

• конструировать экранные формы под любые задачи;

• интегрировать любые внешние сервисы по API и не только.

Полный рейтинг доступен на сайте Cnews.

Опять попробовали React Native и снова решили, что не хотим его внедрять у себя 🧐

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

Перед нашей командой стояла задача: написать код один раз, собрать под три платформы и встроить в существующие нативные и веб-приложения. Решили поэкспериментировать с React Native: до этого мы «щупали» фреймворк в 2018-м, но делали новое приложение, опыта разработки SDK у нас не было. Отправились гуглить и узнавать, как это сделать. Начали с разработки под Android, потом подключили в веб, и уже финально — iOS, в котором практически всё заработало по дефолту.

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

Вот что мы поняли при разработке:

● Обязательно нужна единая дизайн-система под все три платформы под React Native и библиотека компонентов. А ещё — команда из фронтенд и мобильных разработчиков под iOS и Android: одни будут поддерживать часть React Native, которая относится к нативной платформе, другие — писать бизнес-логику и UI.

● React Native может подойти для проектов, которые начинаешь с нуля и нужно охватить мобильные платформы и веб сразу.

Результаты нашего эксперимента

Хоть и ушло на работу с React Native несколько кварталов, мы решили не внедрять его. Было ли нам обидно? Нет, потому что благодаря эксперименту мы:

✔ Закрепили опыт, что фронтенд-разработчики могут писать на React Native.

✔ Поняли, как всё работает изнутри, какие у фреймворка плюсы и минусы.

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

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

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

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

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

Дели код на области (scope) - второй принцип. Полный список принципов здесь

Получил задачу, нужно подумать о области реализации. Иерархия областей такая: бизнес домен -> поддомен -> ... -> поддомен -> модуль(пакет) -> функция.

Чем глубже задача в иерархии декомпозиции, тем глубже область реализации в иерархии областей/слоев. Если ты разработчик, твоя зона: поддомен -> модуль(пакет) -> функция. Может быть так:

• эпик содержит общее описание, покрывает несколько поддоменов, про модули тут ничего не понятно

• история(сторя) в эпике описывает конкретный вариант использования, покрывает модуль поддомена. Если история покрывает больше одного модуля или поддомена, нужно подумать над декомпозицией.

• техническая задача из истории - слой вниутри модуля на фронте или модуль на бэке.

Сore domain и всякие другие domain - это лирика-теория для аналитиков. Для разработчика это лишний информационных шум.

Здесь нужно быть внимательным, потому что:

1. границы субъективны, зависят от понимания смысла, целей, отвественности компонента,

2. для бэка и фронта границы областей проходят по разному в рамках одной системы:

   • для бэка поддомен->модуль совпадает с сервис->модуль/пакет или микросервис. Сервисы типа BFF и GraphQL - исключения, их можно считать частью глобального слоя контроллеров;

   • для фронта в слое контроллеров UI компоненты имеют свои границы, отличные от границ поддомен->модуль, но в остальных слоях совпадают.

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

Допустим, я разработчик бэка. Задача: сделать фасетный и текстовый поиск товаров. Есть сторя с описанием контракта. Тогда моя зона: поддомен -> модуль(пакет) -> функция модуля. Мысли такие:

1. Поддомен уже понятен - обсудил в процессе декомпозиции эпика с аналитиком. Это будет Каталог. Сделаю его отдельным сервисом.

2. Модуль примерно понятен: мне нужно сделать фасетный поиск. Скорее всего кроме поиска Каталог-сервис будет выдавать категории, продукты по отдельности и еще что-то. Фасетный поиск - модуль.

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

На фронте эта же задача выглядит по другому: это будет страница поиска, в ней фасетые фильтры, список товаров, страницы, сортировка. А еще где-то в шапке поле для ввода текста. Тут нет речи о Каталоге, потому что по смыслу это страница и какие-то элементы ввода. Это не страшно. Пусть структура UI компонент соответствует интуитивным ожиданиям фронт разработчиков. Важно, что бы ожидания были у всех одинаковые. Это в слое контроллеров.
В слое приложения лежит логика построения запроса по контракту. Вот здесь появляется Каталог, как поддомен, и модуль фасетного поиска. Позже тут будет модуль категорий и отдельного продукта. Слой контроллеров будет использовать их в разных UI компонентах.

Область и ограниченный контекст - разные вещи. Поэтому мы здесь его не обсуждаем.

Деление на слои и области выглядит как "решётка":

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

Как физически организовать решетку и общие пакеты разберемся дальше.

О компиляторах.

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

Ядро Linux по этому определению может называться очень большим проектом. Под него специально затачивается gcc.

У IBM есть даже специальный язык PL/S, используемый специально для написания операционной системы. Компилятор PL/S не доступен вне IBM.

О языках программирования.

Язык программирования обычно становится конфеткой через 40-50 лет активного использования, когда из него устраняются все абстрактные идеи авторов и привносятся свойства, реально нужные программистам.

Исключением из этого правила является C++, который, несмотря на довольно почтенный возраст, до сих пор представляет собой полигон для игры ума авторов.

С другой стороны, стандарт Scheme принимают голосованием программистов по спорным вопросам.

Чем дольше живу, тем больше ценю Лисп и Фортран.

Магические квадраты с произведением

 О магических квадратах известно, наверное, всё. А возможны ли магические квадраты, в которых равны не суммы значений в строках, столбцах и на диагоналях, а их произведения? Оказывается – возможны. В дальнейшем буду называть такие квадраты «магическими квадратами с произведением» (сокращённо – МКП).

Интересно, что, как и «обычных» магических квадратов, возможно бесчисленное множество вариантов МКП. В общем случае для трёх чисел a, b и n МКП размером 3 × 3 имеют вид:

При этом a ≠ b, a ≠ 1, b ≠ 1, a ≠ b², b ≠ a²,

Интересно, что любой МКП размером 3 × 3 может быть основой для формирования бóльших МКП. Одно из возможных решений заключается в том, чтобы поместить такой  квадрат в центр квадрата 5 × 5 и потом подобрать такие остальные числа, чтобы они соответствовали свойствам МКП. Это означает, что МКП являются также так называемыми «рамочными магическими квадратами» – магическими квадратами, которые сохраняют свое магическое свойство, если в них отбросить окаймляющие «полосы» в две клетки.

После комментариев  @miksoft я удалю сей свой пост

Преимущества реализации цикла FOR в Modula-3

Цикл FOR в Modula-3 был значительно улучшен по сравнению с его аналогами в Pascal и Modula-2. Эти изменения сделали его более безопасным, гибким и удобным для разработки. Вот ключевые преимущества:

1. Гибкость диапазона и шага

В Modula-3 цикл FOR позволяет задавать произвольные начальное, конечное значения и шаг, а не только ±1, как в Pascal.
Пример:

FOR i := 10 TO 1 BY -2 DO
  ...  // обратный счёт с шагом -2
END;

Это упрощает итерации с нестандартными шагами, что особенно полезно в научных вычислениях или обработке данных.

2. Локальная область видимости переменной цикла

Переменная цикла объявляется непосредственно в конструкции FOR, ограничивая её область видимости телом цикла. Это предотвращает случайные конфликты имён и уменьшает риск ошибок.
Пример:

FOR i := 1 TO 10 DO
  ...  // переменная i существует только здесь
END;

3. Защита от модификации переменной цикла

Переменная цикла внутри тела цикла доступна только для чтения. Её нельзя изменить, что исключает случайные ошибки, характерные для Pascal и Modula-2.

FOR i := 1 TO 5 DO
  i := 10;  // Ошибка компиляции: присваивание запрещено
END;

4. Поддержка различных типов данных

Цикл FOR в Modula-3 работает не только с целыми числами, но и с другими типами, такими как:

• Перечисляемые типы (ENUM).

• Диапазонные типы (например, поддиапазоны [1..10]).

• Даже символы (CHAR), если это имеет смысл.

Пример с перечислением:

TYPE Color = {Red, Green, Blue};
FOR c := FIRST(Color) TO LAST(Color) DO
  ...  // итерация по всем элементам перечисления
END;

5. Безопасность и контроль типов

Modula-3 строго проверяет границы цикла на этапе компиляции. Если начальное значение превышает конечное при положительном шаге (или наоборот), цикл не выполняется, что предотвращает бесконечные циклы или ошибки времени выполнения.

6. Улучшенная читаемость

Синтаксис FOR в Modula-3 более выразителен, особенно при работе с массивами или списками. Например:

FOR i := 0 TO LAST(a) DO
  a[i] := ...  // явный обход массива
END;

Это делает код понятнее, чем использование циклов WHILE.

Сравнение с другими языками

• Pascal/Modula-2:

  • Ограничен шагом ±1.

  • Переменная цикла может быть модифицирована внутри тела.

  • Неопределённое поведение после завершения цикла.

• Ada:
  Modula-3 позаимствовал многие принципы безопасности из Ada (например, защита переменной цикла), но сохранил простоту синтаксиса.

Итог

Цикл FOR в Modula-3 сочетает гибкость, безопасность и выразительность. Его реализация отражает общие принципы языка: строгий контроль типов, минимизацию ошибок и удобство для разработчика. Это делает Modula-3 предпочтительным выбором для задач, где важна надёжность и читаемость кода.

3 ключевые метрики, которые спасут микросервисный проект

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

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

• Количество рестартов.

• Фейлы readiness/liveness проб.

• Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

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

• Конверсию платежей (например, от корзины к оплате).

• Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

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

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

• Время отклика API (p95, p99).

• Частоту ошибок 5xx/4xx.

• Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.