Разработка

Бесплатно делюсь своими наработками в маркетинге за 10 лет! Легко собери себе воронку по шаблонам и инструкциям без маркетолога и без расходов.

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

Давно надо было так сделать, но сделал только сегодня. Вот сам канал, где я всё выложил с подробнейшими инструкциями и демонстрациями на реальных бизнесах: t.me/algrigowave

Зацени, как оформил канал YouTube. Всё в едином стиле теперь. Прикол в том, что это всё без дизайнера, вот так можно прям своими руками делать обложки.

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

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

А ещё сделал перелинковку на тг канал, где предлагаю дополнительную ценность — даю конспекты и все шаблоны ментальных карт, которые использую в каждом видео.​ Т.е. можно как с канала на ютюб зайти и скачать нужную карту или конспект, так и через тг канал можно найти нужное видео, чтобы посмотреть, как именно работать с нужным шаблоном.

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

По сути, он будет работать как маркетолог. То, за что обычно от 100к берут (а вообще-то сильно больше), тут можно будет сделать самому в привычном боте в тг за пару часиков работы.

И всё это не просто из головы, а прям по проверенным алгоритмам, по которым я сам работаю, по всяким умным книжкам и вот это вот всё.

Как будет готово, туда же, в канал закину: t.me/algrigowave

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

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

В общем, в канале будет много полезного, так что заходи, подписывайся​, получай пользу

Вышло обновление DLP-системы InfoWatch Traffic Monitor 7.12

Выпустили обновление DLP-системы InfoWatch Traffic Monitor. Агент новой версии получил поддержку работы с новыми версиями ОС.

Для соответствия требованиям госструктур агент InfoWatch Traffic Monitor версии 7.12 протестирован и поддерживает новые версии распространенных российских ОС — РЕД ОС 8 и Astra Linux 1.8.

Также в бета-версии агента добавлена поддержка macOS c возможностью контролировать HTTPS-трафик и события печати.

Бета-тестирование: обновлённый парсер для анализа кода на языках C и C++

Уже несколько месяцев наша команда активно тестирует новую версию парсера, и мы достигли значительного прогресса. Благодаря отзывам пользователей, мы смогли выявить и устранить множество неточностей в работе анализатора. Однако наша цель — создать максимально надёжный инструмент, поэтому мы продолжаем процесс тестирования и приглашаем вас присоединиться.

Уже больше года команда разработки PVS-Studio кропотливо работает над обновлением собственного парсера для анализа кода на языках C и C++. Это большое обновление, хоть и не видно для большинства пользователей. Оно служит фундаментом для дальнейших усовершенствований анализатора.

Отличная новость для пользователей Linux: по вашим многочисленным просьбам мы добавили возможность тестирования на Linux! Теперь пользователи обеих операционных систем (Windows и Linux) могут помочь нам в улучшении продукта. Если вы ещё не участвовали в тестировании, сейчас самое время присоединиться!

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

Как присоединиться к тестированию?

Просто заполните специальную форму на нашем сайте. В ответном письме вы получите подробную информацию о тестировании, инструкцию по установке тестовой версии и, при необходимости, временную лицензию на PVS-Studio.

Расскажите о своём опыте!

Если во время использования анализатора вы заметите баги, падения, странные срабатывания или замедление, пожалуйста, сообщите нам об этом! Для этого вы можете ответить на письмо, которое мы присылали ранее, или написать через форму обратной связи. Любые отзывы, баг-репорты и предложения будут очень полезны для нас.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Mikhail Gelvikh. Beta testing: updated parser for C and C++ code analysis.

Управление методами в зависимости от окружения в 🅰️ngular

Бывают случаи, когда нужно, чтобы определенные методы работали только:

• 🛠️ В dev-режиме (например, фича-тогглы, дебаг-логи, экспериментальные функции)

• 🚀 В prod-режиме (аналитика, мониторинг, продакшен-логика)

Вместо того чтобы писать if (isDevMode()) {...} везде, можно использовать декораторы Angular для более чистого и декларативного подхода.

_____

Одно из решений:

export function EnvMode(mode: 'dev' | 'prod') { return function (_: unknown, __: string, descriptor: PropertyDescriptor) { const originalMethod = descriptor.value; descriptor.value = function (...args: unknown[]) { const shouldExecute = mode === 'dev' ? isDevMode() : !isDevMode(); if (!shouldExecute) return; return originalMethod.apply(this, args); }; return descriptor; }; }

_____

Как использовать:

@EnvMode('dev') public setFeatureToggle(): void { // Сработает только в dev-режиме } @EnvMode('prod') public sendAnalytics(): void { // Сработает только в prod-режиме }

_____

🤔 А вы создавали кастомные декораторы? Зачем?

Больше про Angular в тг канале

29 мая 2025 года состоится ежегодная студенческая конференция направления «Гейм‑дизайн» Школы дизайна НИУ ВШЭ. Для участия в мероприятии нужна регистрация. Адрес проведения: г. Москва, ул. Пантелеевская, д.53.

В программе — практические доклады по системному гейм‑дизайну, UX, нарративу, истории и этике видеоигр. Свои проекты и исследования представят студенты разных курсов, смежных направлений и других вузов, а завершится день выступлениями экспертов индустрии.

Тематические блоки:

• Игра как система / общий гейм‑дизайн;

• Нарративный дизайн и игровая сценаристика;

• Опыт игрока: UI/UX, level design, art & sound;

• История видеоигр и индустрии.

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

На конференции в пространстве HSE CREATIVE HUB выступят студенты-дизайнеры разных курсов, а также учащиеся смежных специальностей и студенты из других вузов.

Привет! 27 сентября 2025 года мы вновь соберёмся на Practical ML Conf — ежегодной конференции Яндекса о практическом применении ML‑технологий. Открываем приём заявок для тех, кто хочет выступить с докладом.

Основные темы конференции в этом году: CV, RecSys, MLOps, NLP, Speech и Data Science. Мы ждём глубокие технические доклады о прикладных решениях, которые уже приносят пользу в реальных проектах.

Как проходит работа со спикерами Practical ML Conf 2025:

• при подготовке доклада вы получите поддержку от экспертов программного комитета;

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

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

• вы сможете посетить конференцию вместе с +1 без прохождения отбора слушателей;

• ваш доклад привлечёт внимание сообщества и экспертов: можно будет получить обратную связь, идеи для развития решения и проекта;

• мы поддерживаем спикеров не только на конференции — ваши доклады будут промоутироваться через каналы Яндекса до и после мероприятия.

Приём заявок открыт до 9 июня 2025. Решение о включении доклада в программу примет программный комитет на основе четырех критериев: полезность, новизна, сложность и практичность.

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

BI-проекты: 5 причин, почему они выходят за рамки бюджета (и как этого избежать)

Если вы хоть раз участвовали во внедрении BI-системы — знаете, как легко проект может уйти не туда:
– бюджет трещит по швам,
– сроки съедены интеграцией и доработками,
– пользователи по-прежнему делают аналитику в Excel.

Мы в GlowByte собрали в статье практический разбор типичных ошибок, которые чаще всего приводят к перерасходу бюджета и снижению отдачи от BI-проектов.

Плюс: даём самодиагностический чек-лист и PDF-гайд, где перечислены все организационные, финансовые и технические риски BI-проектов.

Заходите почитать! Статья здесь → Скрытая стоимость BI: что не учитывают 8 из 10 компаний при внедрении аналитических систем.

Открытый проект редактора Neovim имеет уже более 100 ИИ-плагинов сейчас. Их список привёл разработчик решение Colin Kennedy. Некоторые из плагинов в списке находятся в разработке или могут быть не полностью ориентированы на редактор Neovim.

🪙 Крипта никому не нужна, и блокчейн тоже (или нет?)

Другое дело AI — за ним БУДУЩЕЕ! А что этот ваш блокчейн криптоскамерский 🤢? Столько лет ему, а толку нет: одни спекуляции, пользоваться неудобно, никому не нужна децентрализация и т.д.

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

🅰️Ⓜ️Ⓜ️ Как появился AMM и почему я считаю, что это важно

Не хочется строить из себя Виталика (враньё — ещё как хочется), но давайте порассуждаем на бытовом уровне: так ли AI, к примеру, круче блокчейна? Сначала расскажу о том, что меня впечатлило (и без Виталика тут всё равно не обойтись).

Наверное, все слышали про whitepaper от Сатоши Накамото. Хочу заметить, что это уже готовый документ, который стал импульсом к рождению блокчейна. Но есть вещи не менее крутые и менее «оформленные» — например, пост Виталика на Reddit, который послужил началом появления различных формул AMM (Automated Market Makers) и DEX на их основе: «Let's run on-chain decentralized exchanges the way we run prediction markets».

Контекст такой: 2016 год, экосистема Ethereum активно развивается, но децентрализованные биржи сталкиваются с рядом проблем — низкая ликвидность, высокие спреды между покупкой и продажей, а также дороговизна и сложность управления ордерами непосредственно на блокчейне. В таких условиях очень сложно конкурировать с CEX, где всё быстрее и удобнее.

Виталик предлагает перенести модель автоматизированных маркет-мейкеров, уже используемую в предсказательных рынках (например, Augur), в сферу децентрализованных бирж. Вместо традиционной книги ордеров, где покупатели и продавцы вручную устанавливают цены, AMM использует математические формулы для автоматического определения цен активов на основе их предложения и спроса в пуле ликвидности.

А в конце делает приписку, мол, тут Martin Köppelmann предложил упростить формулу и использовать инварианту «x * y = k». Мартин Кёппельман — это сооснователь и CEO Gnosis (Safe, CoW Protocol, CFT и др.). А формула, как мы знаем, стала фундаментом, на котором построены такие гиганты, как Uniswap, Curve, Balancer и другие.

👤 Кто (или что) стоит за блокчейном?

Так что же меня в этом впечатлило? Одна простая математическая формула способна создать огромный рынок и поменять правила игры. Всё это можно свести к простому тезису: математика и её производные в виде блокчейна, криптографии, в конце концов AI (куда без него) — могут значительно улучшать процессы за счёт повышения их эффективности.

А где конкретно блокчейн улучшает эффективность? Он уменьшает трансакционные издержки.

Трансакцио́нные изде́ржки (transaction cost) — затраты (в том числе с использованием рыночных механизмов); издержки, сопровождающие взаимоотношения экономических агентов.

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

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

🏁Что в итоге?

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

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

@yarlykovrv

NotCVE - ещё одна база уязвимостей

В процессе подготовки будущей статьи искал информацию об уязвимостях, которые не были признаны разработчиками. И натнулся на проект NotCVE (он же !CVE). Проект появился как минимум с октября 2023 года. Удивительно, что в рунете практически нет упоминания этого проекта (нашёл только ссылку на этот ресурс на сайте БДУ).
Миссия проекта - предоставить общее пространство для уязвимостей, которые не признаны производителями, но при этом представляют собой серьезные проблемы безопасности. Если исследователь столкнулся с трудностями при присвоении CVE, авторы проекта готовы помочь - содействуя присвоению CVE. Либо, если это окажется безуспешным, присвоив NotCVE. База уязвимостей, которым присвоили NotCVE, пока скромная (всего 5 штук). Есть 3 варианта поиска, производящих поиск одновременно по базам CVE и NotCVE: с поддержкой фильтра по версиям, CVSS, наличию эксплоита, типу воздействия (у меня, правда, поиск по версиям плохо отработал - может, неверно составил запрос).

В часто задаваемых вопросах на сайте проекта приводят такой список причин обращаться к NotCVE:

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

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

• Отклонения CVE по причине окончания срока службы и поддержки.

• Проблема, которая может считаться уязвимостью по мнению MITRE, но не по мнению поставщика.

• Опубликованная проблема безопасности, которой не присвоен CVE по истечении 90 дней.

• Опубликованная проблема безопасности без присвоенного CVE.

Также есть опубликованное электронное письмо от представителей NotCVE (от 2023 года). Среди прочего там указано:

В некоторых случаях MITRE выступает за присвоение CVE, но вендор против. В таких случаях MITRE ничего не может сделать. По опыту мы можем сказать, что в итоге CVE не будет присвоен. Обратите внимание, что «проблема безопасности» не может быть даже названа «уязвимостью», потому что не является таковой (только у поставщика есть такие полномочия) в соответствии с правилами MITRE. Если что-то не является «уязвимостью», то нечего исправлять, нечего отслеживать и т. д. Поскольку такие проблемы остаются незамеченными, к ним следует относиться еще более осторожно, поскольку они, скорее всего, не будут исправлены. Поэтому платформа !CVE - это далеко не развилка, но она раскрывает проблемы безопасности, которые в противном случае останутся скрытыми для большинства из нас. Также платформа признает усилия исследователей безопасности, отдавая им заслуженное должное.

Моя личная практика это тоже подтверждает: разработчики Hyperledger Fabric всячески отказываются называть найденную мной проблему уязвимостью (CVE-2024-45244). И даже предлагали мне самому отозвать CVE (а когда я отказался - пытались оспорить назначение CVE, но безуспешно). Более того, проблему исправили в версии 3.0.0 (см. поиск по тексту "TimeWindowCheck" в описании релиза 3.0.0) - вышла 20.09.2024. И не хотят исправлять в ветке 2.5.х (в которой продолжается выпуск новых версий после 20.09.2024). В связи с чем описание CVE-2024-45244 (в части уязвимых версий) сейчас не актуально.

Возможно, и я обращусь к NotCVE по нескольким потенциальным проблемам:

• IBM отказался признавать уязвимость в Instana, о которой я им сообщил на днях (подробностей пока сообщать не буду - как раз уточняю точно ли они не будут заводить CVE);

• MITRE назначила CVE (CVE-2024-57695) найденной мной уязвимости 13-летней давности (сообщил им лишь в декабре 2024) ещё в январе 2025. Но, статус до сих пор RESERVED (подробнее об этом статусе);

• Docker отказался присваивать CVE (эту уязвимость нашёл не я, но я не смог пройти мимо и обратился в MITRE).

P.S. По такому случаю сделал ключевое слово "не бага а фича" - надеюсь, в дальнейшем по этому выражению на Хабре станет проще находить соотвествующие статьи\посты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Энтузиаст воссоздал обои установки Windows 95 в 4K. Все фотографии сделал он сам, вот папка со всеми изображениями, включая файлы PSD для Photoshop.

Арестован Владимир Смеркис — сооснователь крипто-игры Blum и бывший глава Binance в СНГ. Его обвиняют в мошенничестве и заключили под стражу по решению Замоскворецкого районного суда Москвы. Команда Blum уже заявила, что Смеркис больше не является директором по маркетингу и не имеет отношения к проекту (не участвует в разработке проекта или в качестве соучредителя). Blum — это криптоигра, аналог Hamster Combat, где пользователи могут зарабатывать реальную крипту за игровые монеты. Релиза монеты ждали уже год, но листинга до сих пор не случилось.

Terraform and Ansible is not enough

Helm and YAML templating was a mistake: A Makefile Manifesto

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

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

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

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

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

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

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

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

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

Ozon запустил бесплатный инструмент OzonGenerator для автоматической генерации описаний товаров — он встроен в личный кабинет продавца и доступен в приложении Ozon Seller. Использовать функцию можно до 50 раз в месяц, при этом сторонние сервисы больше не нужны.

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

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

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

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

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

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

Работаем с событиями без плагина или как перехватить редирект в Joomla 5

В расширении быстрого заказа для JoomShopping. Я создаю экземпляр модели Checkout и вызываю метод checkStep().

$checkoutModel = JSFactory::getModel('checkout', 'Site');
$checkoutModel->checkStep(2);

В методе checkStep есть условия, при выполнении которых происходит установка сообщения и редирект.

if (!$check)
{
    JSError::raiseNotice('', 'Message');
    $mainframe->redirect('Url');
    exit();
}

Но мне надо получить результат метода checkStep или исключение. И продолжить работу.

Смотрим какое событие вызывается при редиректе — ApplicationEvents::BEFORE_RESPOND.

Подписываться на события могут не только плагины, но и любые другие callable объекты.

Создадим функцию которая получает заголовки редиректа, удаляет их и бросает исключение:

$onApplicationBeforeRespond = function()
{
	$app = Factory::getApplication();
	$response = $app->getResponse();
	$status = $response->getHeader('Status');
	$location = $response->getHeader('Location');
	$response = $response->withoutHeader('Status');
	$response = $response->withoutHeader('Location');
	$app->setResponse($response);

	throw new RedirectCaughtException($status[0], $location[0]);
};

Перед вызовом $checkoutModel->checkStep(2); подпишем нашу функцию на прослушивание события, а после отпишем. И обернём вызов в try/catch.

$dispatcher->addListener(
	ApplicationEvents::BEFORE_RESPOND,
	$onApplicationBeforeRespond
);

try
{
	$checkoutModel->checkStep(2);
}
catch (RedirectCaughtException $e)
{
    // Обрабатываем исключение
}

$dispatcher->removeListener(
	ApplicationEvents::BEFORE_RESPOND,
	$onApplicationBeforeRespond
);

Таким образом мы можем перехватывать редиректы внутри блока try.

Преимущества реализации цикла 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 предпочтительным выбором для задач, где важна надёжность и читаемость кода.