1. Копирайтер хочет изменить шаблон краткого описания товара: сместить картинку, вёрстку текста, добавить название производителя. Копирайтер делает файл с новым шаблоном, загружает на сервер, и приложение использует новый шаблон уже так прямо на лету?
2. Копирайтер хочет добавить функцию сравнения цен товаров. Делает шаблон сравнения, прикладывает к техническому заданию, отправляет программисту. Программист реализует функцию сравнения, прикручивает шаблон, вводит переменную, по которой модуль можно запросить (к примеру из другого шаблона), и теперь тэгом {price-compare} копирайтер может вставить нужный модуль куда надо.
А именно биткоины в деле фигурируют в качестве валюты?
Новость на официальном веб-сайте МВД о деталях дела не говорит, из текста неясно на каких основаниях выдвинуто обвинение, каковы результаты экспертиз и оперативной деятельности до задержания. Неясно даже на какие валюты вёлся обмен биткоинов. Указано только: «путем использования одной из международных платежных систем и площадки по обмену биткоинов», «По версии следствия … незаконно обналичили более 500 млн рублей». Если для вас этого достаточно, чтобы сделать выводы — наздоровье. Лично я, не ознакомившись с материалами дела, не в силах установить сколько американских, зимбабвийских и австралийских долларов парни обналичили, кому, обналичили ли вообще, и вели ли торговлю иными ценными бумагами (по сути векселя, расписки, облигации по закону приравниваются к валютам).
Перевод: на территории РФ обмен любой валюты, не являющейся валютой РФ — исключительное право государства. Государство может наделить этим правом конкретное юридическое или физическое лицо (представьте что это действует как лицензия). Пока это полномочие формально конкретному лицу не вверено — любой обмен внешних валют и ценных бумаг производящийся этим лицом незаконен.
Следствие очевидно сбор материалов окончило, пусть к ним обвинения прилагает прокурор, а приговор пусть выносит суд.
Задача математическая, и к непосредственно торту относится довольно абстрактно.Такой алгоритм можно применять к разделу земли, бюджетов, доходов, расходов, времени презентаций и вообще чего угодно. Очень трудная задача — уравнять разности приоритетов, к примеру насколько важнее получить 35 минут на свой доклад, чем получить 30 минут в периоде до 11:00 утра?
Делайте валидацию в бэкэнде, не грузите клиент-приложение бизнес-логикой. Мухи отдельно, котлеты отдельно. Аякс на все элементы ввода, запросы на валидацию всей формы, ответы в джсоне, раскидывайте нужную информацию джаваскриптом по каждому полю. Ато решите потом написать приложение-клиент для телефонов и будет у вас две валидации, и будете потом гадать, делают ли они одно и то же.
Для того чтобы продолжать деятельность на территории Канады, Гугл должен подчиниться. Если не подчиняется — лишается „гражданских“ прав (насколько это применимо к юридическому лицу) на территории Канады. Грубо говоря, не может продолжать деловую деятельность.
Если же Гугл предъявляет доказательства того, что это ограничение противозаконно на территории какой-то страны, то Гугл может подать встречную заявку для уточнения деталей, типа предварительного приговора до дальнейшего выяснения обстоятельств. Но это выписка из апелляционного суда провинции, а окончательный приговор уже вынесен верховным федеральным судом (то есть уже после описанного выделенным текстом случилось следующее: дело в суде провинции было уже окончено, приговор вынесен, аппелляция подана в верховный суд, дело рассмотрено, вынесен приговор в верховном суде). Так что дальнейшая процедура разбирательств несколько другая. Но если это ограничение будет противозаконно на территории какой-либо страны, то государство не сможет лишить Гугл прав ведения деловой деятельности даже если Гугл нарушит это ограничение на территории той самой страны (но именно той самой, а не всех в общем). Поскольку как юридическое лицо зарегистрированное на территории Канады, Гугл связан обязательством соблюдать законы Канады даже в ведении дел вне Канадских границ.
Так же стоит упомянуть что в верховном суде рассматривалось не дело, а аппелляция, которую подал Гугл против Еквустека, и всё, что верховный суд имел сказать — это то, что вынесенный приговор соответствует закону, не нуждается в поправках, и вообще всячески компетентный и валидный. Вот ссылка на описание дела в верховном суде: http://www.scc-csc.ca/case-dossier/info/parties-eng.aspx?cas=36602 Интересно количество интервентов, прямо как в гражданской войне 1917-1922.
Фактически — только на своей территории. По сути тут действует обычная схема шантажа (на котором основана вообще вся государственная деятельность в мире):
Гугл либо подчиняется решению суда, либо теряет все права на ведение деятельности на территории Канады (или сферического государства в вакууме), возможно облагается штрафом (который может и проигнорировать, поскольку более деятельности не ведёт).
Предположим: какой-нибудь Судан постанавливает запрет Гуглу на публичный показ фотографий женщин без паранжи на территории всего мира. Гугл закрывает деловую деятельность на территории Судана, ликвидирует активы, снимает гарантии на доступ к услугам. Верховный суд постанавливает штраф в размере половины миллиарда $США. Гугл не выплачивает штраф. Дальше что? Верховный суд Судана приговаривает весь штат исполнительных директоров к 10 годам каторги? Требует у других стран экстрадиции? Устанавливает мораторий на экспорт нефтепродуктов/хлопка/сахара? Какие рычаги давления имеет суверенное государство вне пределов своих границ, которые могут принудить информационного гиганта соблюдать подобные условия по всему миру и на использование которых способно это суверенное государство пойти ради … репрессирования одного юридического лица?
Тут действует, как правильно указал roboq6, юрисдикция над конкретным лицом, а не территориальная. По аналогии с лицом физическим, которое совершает преступление вне границ своего государства, но может подвергнуться преследованию властей внутри него, и как следствие лишиться гарантии собственных прав и подвергнуться репрессиям. Точно так же и лицо юридическое. Так что опасность прецедента заключается не в нарушении границ собственной юрисдикции, а в преследовании посторонних лиц, вместо преследования собственно нарушителей.
Ну и налицо маразм, охвачивающий руководство означенного производителя сетевого оборудования. Вместо того, чтобы преследовать производителя контрафакта, будем преследовать поисковик, который его может найти.
Существенная проблема в постановке задачи перед судом, поскольку иск против конкретно Гугла, то и результат будет только между Гуглом и производителем. Если бы иск был против другого производителя, то и результат бы существенно отличался.
Ваше приложение должно отображать фотографию, когда пользователь удаляет уведомление.
Когда пользователь удаляет уведомление — уведомление должно удалиться. Любые другие действия просто морально недопустимы. Я как пользователь немедленно удалю приложение, которое делает такие фокусы. Как лид, потребую изменения ТЗ. Как руководитель отдела разработки, подниму вопрос о некомпетентности UX дизайнера. С собеседования я просто уйду.
Я не вижу причин, чтобы кидать outofmemory прежде, чем insufficientmemory. Надо иметь возможность обработать ошибку/исключение прежде, чем программа войдёт в условно нерабочее состояние. Платформа должна знать, хватит ли ресурсов на предстоящую загрузку, а исключениями могут стать только уж совсем маргинальные случаи, когда ни памяти, ни кэша не хватает даже на оценку предстоящей задачи.
За примерами далеко ходить не надо, к примеру тот же outofmemoryerror, для которого во многом и сделан данный топик. Дело в том что в джаве эта ошибка не всегда означает реальное истощение памяти, и появляется в том числе при попытке выделения. В этом случае память ещё не занята, но выделить память для обработки у вас уже не получится, и в результате придётся причинять нестабильность к приложению или полагаться на рестарт после вылета. Нестабильность в приложении можно сделать, к примеру, выкинув контекст текущей задачи и извинившись перед пользователем в стиле «Звёзды так сошлись, и что-то случилось неправильно, может результаты твоей задачи есть частично, может она развалилась по дороге, и у тебя в окружении теперь в неизвестном месте валяется половина пепелаца.» В то же время, есть платформы, которые делают outofmemory значительно реже, чем insufficientmemory (который имеется и в джаве, но почему-то не используется во всех подходящих для неё случаях.
А вот примеров нестабильности не связанных с памятью я не знаю. Может просто потому, что я ещё не всех монстров повидал. Наверняка есть сырые платформы которые и работают ещё кое-как, но я ими не пользуюсь.
Что касается исключений, то это чистая правда, стабильность приложения как такового всецело в руках самого разработчика. И я думаю именно оттого родилось описанное в статье решение: разработчику в некоторых проектах выгоднее стабильно ронять приложение, чем распространяться в десяти томах мемуаров об исключениях. А это решение позволяет очень чётко рамки этой стабильности падения определить. С точки зрения традиций, это скорее хак, но полезный в своей нише.
А вот что касается стабильности платформы, то я полагаю некоторые деятели из каких-нибудь больших данных и распределённых вычислений с вами бы поспорили. Впрочем даже такие споры в конце концов сведутся не к самой платформе, а к требованиям самого процесса разработки, ибо любая платформа стабильна, если она зависит от измеримых показателей и статистически постоянна.
По-моему тут как раз смысл в том, чтобы оно чётко вырубалось, а не тормозило по пол-года перед окончательным падением. Скорее всего, как автор и указал, в продакшне это годно только для вот тех самых специфичных умных унитазов, которым нужно произвести CTD+restart в кратчайшие сроки, в погоне не за стабильностью аптайма, а за суммой тактовых сигналов, потраченных на непосредственно исполнение рабочей задачи. Как вы справедливо заметили, джава и стабильность не очень сочетаются.
Если у вас есть проект, решающий реальную рыночную задачу, то обязательно есть специалист, который разбирается в рынке достаточно, чтобы решать эту задачу не частным образом, а понимать как она решается принципиально. Этот специалист курирует проект. Вот он, если не может сам создать реальный, рабочий набор данных, пусть и фиктивных, то должен как минимум объяснить команде разработчиков природу этих данных достаточно доходчиво, чтобы они их создали сами, или сделали генератор, который на это способен.
А если у вас нету возможности сделать прикладной тест, то вы всегда будете производить кота в мешке. Все юнит тесты пройдут хоть тысячу раз, а реальный юз-кейс типа “ввёл стопку чеков, нажал кнопку, и получил годовой отчёт” всё равно может не пройти. А если ваша рабочая задача сделать экспорт из своего приложения в другое, и процесс экспорта подразумевает обработку данных? А если на выходе этих данных должно быть несколько гигабайт? С рандомно намоканной абракадаброй (а я такое видел) это не протестируешь, а внедрять всё это в определение какого-нибудь мега-монстро-теста кто угодно сойдёт с ума.
Для любых приложений нужны тестовые базы данных, будь то финансовая отчётность, учёт инвентаря, автоматизация рабочих процессов, машинное обучение, прогнозирование любой фигни от потребления птичьего корма до расхода топлива.
А я всегда тестирую приложение с тестовой базой, на реальных данных, всегда в дополнение к юнит тестам. Юнит тесты это очень хорошо, но написать юнит тест, который проведёт настоящие, рабочие данные от начала до конца процесса и проверит получился ли приемлемый результат вы задолбаетесь. В то же время, тестовая платформа, рабочие данные, и ожидаемый результат у вас есть всегда.
Всё как всегда. Фоновые задачи выполняют квалифицированные специалисты на престижных позициях, они же берут продлённые отпуска и отгулы перед выходными. А многочисленные плебеи работают на кассе с окошком, пользовательский интерфейс не требует квалификации, работа не престижная, и доступно окошко круглосуточно и круглогодично.
Правда стоит повторить вопрос из собственно поста: как же всё-таки выглядит выдача 58 миллионов? Это ж целый грузовик банкнот. Ну разве только платиновыми слитками, но полторы тонны платины вряд ли просто так выдадут даже в головном отделе банка.
Так и есть, так и случается. Опасно, но не очень. В худшем случае — не будет исполнено. Ну если особый талант есть, то можно сделать так чтобы исполнить с ошибками, и тут начинается самая веселуха. Можно и данные напортить. Многое зависит от бизнес-логики приложения и от архитектуры. На старые задачи рассчитывать нельзя, а на новые — вполне можно. Естественно, можно предусматривать закрытие старых задач при создании нового рантайма, оповещение пользователей, и прочую инфраструктуру. Для того и есть архитектор приложения, чтобы этими вопросами заниматься, а разработчики — его информировать и внедрять эти решения. Да и в любом вопросе рефлексии идеальных решений нет, зыбкая область, нужно быть готовым ко всему.
По-хорошему и переделал. Одно дело “не рекомендуется” и совсем другое “не получится, даже если очень захочешь”. Если честно, то я как старший должен был изучить документацию прежде, чем оставлять внедрение коллегам, но тут уж как вышло. Танцы на граблях хорошему учат.
Да, бывают такие случаи, когда вы занесёте в планировщик задачу с рефлектом, а потом обновите код программы. Обработка ошибок должна быть предусмотрена непосредственно в планировщике. В худшем случае тред будет оборван, а задача “зависнет” с каким-нибудь статусом. В лучшем случае, планировщик сможет словить ошибку, записать в результат, и перезапустить задачу максимум N раз (согласно настройкам планировщика).
Был у меня случай когда я использовал сущность из EF в качестве аргумента для задачи, отправленной в планировщик. Естественно, после обновления новый рантайм, и стало быть новые типы (особенность EF). Hangfire словил исключение, записал его, и так пять раз кряду, а потом забил, записав задачу как Failed. Мне, соответственно пришлось выяснить почему не работает функционал (спасибо тестерам), ну вот и закрутилось колесо дебага.
В общем-то “облегчает программирование” тут ни при чём. Ясное дело, что взять готовый инструмент и прикрутить его к вашему приложению — легче, чем написать инструмент с нуля или даже собрать его из каких-то модулей, но не в этом суть самого инструмента.
Вот вам юз-кейс:
Вы администратор. Ваша сеть расширилась и уже влом запускать бэкапы вручную. Вы пишете скрипт, который обращается в сеть, находит на данный момент включенные в сеть машины (у вас ведь могут быть и кочевые ноутбуки, и что угодно ещё), и отправляет их бэкапиться на ваш бэкап-сервер. Потом вы устанавливаете скрипт в крон бэкап серверу и вот у вас есть запланированная задача. Крон — это планировщик задач, он не облегчает жизнь разработчику ОС, он облегчает жизнь конечному пользователю, в данном случае администратору системы.
Планировщики задач существуют в большей степени не для того, чтобы “выполнить по некому событию”, а для того, чтобы “выполнить тогда, когда конечный пользователь укажет”. Иногда в бизнес-логике приложения бывают ситуации, когда это предрешено самой бизнес-логикой. Ну к примеру, у вас есть генератор отчётов и настройка времени действительности отчёта. Допустим отчёт действителен только в течение двух недель, а через две недели он теряет смысл. В приложении есть процедура генерации отчёта и процедура удаления отчёта. Генерация отчёта предусматривает занесение в планировщик задачи удаления конкретно этого отчёта через две недели. Процедура занесения задачи в планировщик предусмотрена разработчиком, но точное время исполнения назначает конечный пользователь при запросе нового отчёта. Всё для того, чтобы список результатов не раздувался за счёт устарелых данных. То есть опять же для облегчения жизни конечному пользователю.
В данном контесте «fire-and-forget» относится именно к пользователю. Он просто жмёт кнопку. Ему не нужно ждать, смотреть на полоску “loading” внизу окна браузера, пока метод вернёт результат. Метод исполнится тогда, когда для этого будет свободная мощность, примерно в то время, в которое положено, и пользователь об этом будет оповещён (с поправкой на дизайн интерфейса и логики метода). А пользователь может работать дальше и заниматься своими делами.
1. Копирайтер хочет изменить шаблон краткого описания товара: сместить картинку, вёрстку текста, добавить название производителя. Копирайтер делает файл с новым шаблоном, загружает на сервер, и приложение использует новый шаблон уже так прямо на лету?
2. Копирайтер хочет добавить функцию сравнения цен товаров. Делает шаблон сравнения, прикладывает к техническому заданию, отправляет программисту. Программист реализует функцию сравнения, прикручивает шаблон, вводит переменную, по которой модуль можно запросить (к примеру из другого шаблона), и теперь тэгом {price-compare} копирайтер может вставить нужный модуль куда надо.
Новость на официальном веб-сайте МВД о деталях дела не говорит, из текста неясно на каких основаниях выдвинуто обвинение, каковы результаты экспертиз и оперативной деятельности до задержания. Неясно даже на какие валюты вёлся обмен биткоинов. Указано только: «путем использования одной из международных платежных систем и площадки по обмену биткоинов», «По версии следствия … незаконно обналичили более 500 млн рублей». Если для вас этого достаточно, чтобы сделать выводы — наздоровье. Лично я, не ознакомившись с материалами дела, не в силах установить сколько американских, зимбабвийских и австралийских долларов парни обналичили, кому, обналичили ли вообще, и вели ли торговлю иными ценными бумагами (по сути векселя, расписки, облигации по закону приравниваются к валютам).
Перевод: на территории РФ обмен любой валюты, не являющейся валютой РФ — исключительное право государства. Государство может наделить этим правом конкретное юридическое или физическое лицо (представьте что это действует как лицензия). Пока это полномочие формально конкретному лицу не вверено — любой обмен внешних валют и ценных бумаг производящийся этим лицом незаконен.
Следствие очевидно сбор материалов окончило, пусть к ним обвинения прилагает прокурор, а приговор пусть выносит суд.
Для того чтобы продолжать деятельность на территории Канады, Гугл должен подчиниться. Если не подчиняется — лишается „гражданских“ прав (насколько это применимо к юридическому лицу) на территории Канады. Грубо говоря, не может продолжать деловую деятельность.
Если же Гугл предъявляет доказательства того, что это ограничение противозаконно на территории какой-то страны, то Гугл может подать встречную заявку для уточнения деталей, типа предварительного приговора до дальнейшего выяснения обстоятельств. Но это выписка из апелляционного суда провинции, а окончательный приговор уже вынесен верховным федеральным судом (то есть уже после описанного выделенным текстом случилось следующее: дело в суде провинции было уже окончено, приговор вынесен, аппелляция подана в верховный суд, дело рассмотрено, вынесен приговор в верховном суде). Так что дальнейшая процедура разбирательств несколько другая. Но если это ограничение будет противозаконно на территории какой-либо страны, то государство не сможет лишить Гугл прав ведения деловой деятельности даже если Гугл нарушит это ограничение на территории той самой страны (но именно той самой, а не всех в общем). Поскольку как юридическое лицо зарегистрированное на территории Канады, Гугл связан обязательством соблюдать законы Канады даже в ведении дел вне Канадских границ.
Так же стоит упомянуть что в верховном суде рассматривалось не дело, а аппелляция, которую подал Гугл против Еквустека, и всё, что верховный суд имел сказать — это то, что вынесенный приговор соответствует закону, не нуждается в поправках, и вообще всячески компетентный и валидный. Вот ссылка на описание дела в верховном суде: http://www.scc-csc.ca/case-dossier/info/parties-eng.aspx?cas=36602 Интересно количество интервентов, прямо как в гражданской войне 1917-1922.
Гугл либо подчиняется решению суда, либо теряет все права на ведение деятельности на территории Канады (или сферического государства в вакууме), возможно облагается штрафом (который может и проигнорировать, поскольку более деятельности не ведёт).
Предположим: какой-нибудь Судан постанавливает запрет Гуглу на публичный показ фотографий женщин без паранжи на территории всего мира. Гугл закрывает деловую деятельность на территории Судана, ликвидирует активы, снимает гарантии на доступ к услугам. Верховный суд постанавливает штраф в размере половины миллиарда $США. Гугл не выплачивает штраф. Дальше что? Верховный суд Судана приговаривает весь штат исполнительных директоров к 10 годам каторги? Требует у других стран экстрадиции? Устанавливает мораторий на экспорт нефтепродуктов/хлопка/сахара? Какие рычаги давления имеет суверенное государство вне пределов своих границ, которые могут принудить информационного гиганта соблюдать подобные условия по всему миру и на использование которых способно это суверенное государство пойти ради … репрессирования одного юридического лица?
Тут действует, как правильно указал roboq6, юрисдикция над конкретным лицом, а не территориальная. По аналогии с лицом физическим, которое совершает преступление вне границ своего государства, но может подвергнуться преследованию властей внутри него, и как следствие лишиться гарантии собственных прав и подвергнуться репрессиям. Точно так же и лицо юридическое. Так что опасность прецедента заключается не в нарушении границ собственной юрисдикции, а в преследовании посторонних лиц, вместо преследования собственно нарушителей.
Ну и налицо маразм, охвачивающий руководство означенного производителя сетевого оборудования. Вместо того, чтобы преследовать производителя контрафакта, будем преследовать поисковик, который его может найти.
Существенная проблема в постановке задачи перед судом, поскольку иск против конкретно Гугла, то и результат будет только между Гуглом и производителем. Если бы иск был против другого производителя, то и результат бы существенно отличался.
Когда пользователь удаляет уведомление — уведомление должно удалиться. Любые другие действия просто морально недопустимы. Я как пользователь немедленно удалю приложение, которое делает такие фокусы. Как лид, потребую изменения ТЗ. Как руководитель отдела разработки, подниму вопрос о некомпетентности UX дизайнера. С собеседования я просто уйду.
А вот примеров нестабильности не связанных с памятью я не знаю. Может просто потому, что я ещё не всех монстров повидал. Наверняка есть сырые платформы которые и работают ещё кое-как, но я ими не пользуюсь.
А вот что касается стабильности платформы, то я полагаю некоторые деятели из каких-нибудь больших данных и распределённых вычислений с вами бы поспорили. Впрочем даже такие споры в конце концов сведутся не к самой платформе, а к требованиям самого процесса разработки, ибо любая платформа стабильна, если она зависит от измеримых показателей и статистически постоянна.
А если у вас нету возможности сделать прикладной тест, то вы всегда будете производить кота в мешке. Все юнит тесты пройдут хоть тысячу раз, а реальный юз-кейс типа “ввёл стопку чеков, нажал кнопку, и получил годовой отчёт” всё равно может не пройти. А если ваша рабочая задача сделать экспорт из своего приложения в другое, и процесс экспорта подразумевает обработку данных? А если на выходе этих данных должно быть несколько гигабайт? С рандомно намоканной абракадаброй (а я такое видел) это не протестируешь, а внедрять всё это в определение какого-нибудь мега-монстро-теста кто угодно сойдёт с ума.
Для любых приложений нужны тестовые базы данных, будь то финансовая отчётность, учёт инвентаря, автоматизация рабочих процессов, машинное обучение, прогнозирование любой фигни от потребления птичьего корма до расхода топлива.
Правда стоит повторить вопрос из собственно поста: как же всё-таки выглядит выдача 58 миллионов? Это ж целый грузовик банкнот. Ну разве только платиновыми слитками, но полторы тонны платины вряд ли просто так выдадут даже в головном отделе банка.
Был у меня случай когда я использовал сущность из EF в качестве аргумента для задачи, отправленной в планировщик. Естественно, после обновления новый рантайм, и стало быть новые типы (особенность EF). Hangfire словил исключение, записал его, и так пять раз кряду, а потом забил, записав задачу как Failed. Мне, соответственно пришлось выяснить почему не работает функционал (спасибо тестерам), ну вот и закрутилось колесо дебага.
В общем-то “облегчает программирование” тут ни при чём. Ясное дело, что взять готовый инструмент и прикрутить его к вашему приложению — легче, чем написать инструмент с нуля или даже собрать его из каких-то модулей, но не в этом суть самого инструмента.
Вот вам юз-кейс:
Вы администратор. Ваша сеть расширилась и уже влом запускать бэкапы вручную. Вы пишете скрипт, который обращается в сеть, находит на данный момент включенные в сеть машины (у вас ведь могут быть и кочевые ноутбуки, и что угодно ещё), и отправляет их бэкапиться на ваш бэкап-сервер. Потом вы устанавливаете скрипт в крон бэкап серверу и вот у вас есть запланированная задача. Крон — это планировщик задач, он не облегчает жизнь разработчику ОС, он облегчает жизнь конечному пользователю, в данном случае администратору системы.
Планировщики задач существуют в большей степени не для того, чтобы “выполнить по некому событию”, а для того, чтобы “выполнить тогда, когда конечный пользователь укажет”. Иногда в бизнес-логике приложения бывают ситуации, когда это предрешено самой бизнес-логикой. Ну к примеру, у вас есть генератор отчётов и настройка времени действительности отчёта. Допустим отчёт действителен только в течение двух недель, а через две недели он теряет смысл. В приложении есть процедура генерации отчёта и процедура удаления отчёта. Генерация отчёта предусматривает занесение в планировщик задачи удаления конкретно этого отчёта через две недели. Процедура занесения задачи в планировщик предусмотрена разработчиком, но точное время исполнения назначает конечный пользователь при запросе нового отчёта. Всё для того, чтобы список результатов не раздувался за счёт устарелых данных. То есть опять же для облегчения жизни конечному пользователю.
В данном контесте «fire-and-forget» относится именно к пользователю. Он просто жмёт кнопку. Ему не нужно ждать, смотреть на полоску “loading” внизу окна браузера, пока метод вернёт результат. Метод исполнится тогда, когда для этого будет свободная мощность, примерно в то время, в которое положено, и пользователь об этом будет оповещён (с поправкой на дизайн интерфейса и логики метода). А пользователь может работать дальше и заниматься своими делами.