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

Может я не знаю чего-то, но в обычном приложении врядли будет какая-то разница между последовательным исполнением тасков через Channels и этой очередью, async/await не требует дополнительной синхронизации, если не выполнять таски параллельно. Может для работы с какой-то нативной либой это может понадобится.

Тут по-лучше обьяснение - https://github.com/borland/SerialQueue

И что-то мне кажется можно было бы просто использовать Channels.

Пользовался RestSharp, перешел на Flurl, а потом обе эти либы начали ломать свое АПИ, релизить несовместимые версии и так далее. И ладно бы лучше что-то сделали, но нет, еще и багов добавили. И теперь я подумываю использовать голый HttpClient, потому как от этих либ больше вреда, чем пользы.

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

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

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

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

Flash это виртуальная машина оптимизированная для работы с анимацией и графикой, она запускалась в браузере через плагин Flash Player, на десктопе и мобилах через обертку Adobe Air. Для флеша была куча инструментов и фреймворков для формошлепства, игр, анимаций. Adobe Flex, который вышел 20 лет назад до сих пор во многом превосходит современные JS фреймворки, с точки зрения удобства для разработчика и полноты возможностей (декларативное описание ui, анимаций, данных, качественная ui библиотека, нормально сделанные формы, односторонний и двухсторонний биндинг, разделение логики и представления, компилируемый язык и как следствие компактные размеры приложения, разделяемые библиотеки, ленивая подгрузка модулей, бинарный протокол общения с сервером, встроенная поддержка e2e тестов, локализаций, xml и json и так далее).

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

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

То, что сервисы еще работают и учетки не поблочили, это не плюс и не минус, доверия больше нет. Платить и все равно рисковать блокировкой?

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

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

Эти примеры не подходят для нашего случая, по-моему это очевидно. Если игру можно купить легально без испанских карт, то пиратство наносит ущерб продавцу игры, он получает меньше денег, если игра в принципе не продается на территории РФ/РБ - пирать сколько угодно. Грабеж магазина также наносит прямой ущерб продавцу.

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

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

Вобще-то, можно прийти к неожиданным выводам. Они решили не принимать оплату из РБ, РФ (но технически проблем с этим нет), то есть сознательно отключили доход из этих стран. В этом случае речь не может идти даже об упущеной выгоде, а значит пиратство не может в принципе нанести никакого ущерба.

Да, спасибо им за ценный урок и всего хорошего.

Уже как-то не интересно.

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

Есть datomic, в ней можно смотреть данные в разрезе времени и отдельных транзакций. Можно перейти на события и строить агрегаты за любые периоды.

Нужно просто разделять на даты по их использованию, даты событий ложаться на UTC идеально, для календарных дат, расписаний и тп нужны таймзоны (и то если таймзон больше одной).

Решение сомнительное - это да, но учить там особо нечего.

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