Может я не знаю чего-то, но в обычном приложении врядли будет какая-то разница между последовательным исполнением тасков через Channels и этой очередью, async/await не требует дополнительной синхронизации, если не выполнять таски параллельно. Может для работы с какой-то нативной либой это может понадобится.
Пользовался RestSharp, перешел на Flurl, а потом обе эти либы начали ломать свое АПИ, релизить несовместимые версии и так далее. И ладно бы лучше что-то сделали, но нет, еще и багов добавили. И теперь я подумываю использовать голый HttpClient, потому как от этих либ больше вреда, чем пользы.
С Polly тоже самое, взяли и поменяли апи - иди переписывай, а апгрейд гайд очень скромный.
Это просто вахтеры, по поводу и без, и за нормальный принципе ответ меня минусовали, мол ужас, ссылка без копипасты по этой ссылке, хотя там был всего лишь пример.
Flash это виртуальная машина оптимизированная для работы с анимацией и графикой, она запускалась в браузере через плагин Flash Player, на десктопе и мобилах через обертку Adobe Air. Для флеша была куча инструментов и фреймворков для формошлепства, игр, анимаций. Adobe Flex, который вышел 20 лет назад до сих пор во многом превосходит современные JS фреймворки, с точки зрения удобства для разработчика и полноты возможностей (декларативное описание ui, анимаций, данных, качественная ui библиотека, нормально сделанные формы, односторонний и двухсторонний биндинг, разделение логики и представления, компилируемый язык и как следствие компактные размеры приложения, разделяемые библиотеки, ленивая подгрузка модулей, бинарный протокол общения с сервером, встроенная поддержка e2e тестов, локализаций, xml и json и так далее).
Постоянно смотрю в эту сторону, но насколько я понимаю, все совсем не так радужно. Проблемы со звуком, микрофоном, вебкой, сном, внешним моником, рефреш рейт дисплея только 60гц, может быть часть из них уже решена.
Я не так много написал, чтобы можно было понять по-другому. Если продавец отказывается продавать цифровой продукт на какой-то территории (я расцениваю это именно так, поскольку технических ограничений нет), то он автоматически отказывается от прибыли, а значит пиратство не может ему нанести уже никакого ущерба, он уже добровольно отказался от нее. Я считаю, что мысль свою донес.
То, что сервисы еще работают и учетки не поблочили, это не плюс и не минус, доверия больше нет. Платить и все равно рисковать блокировкой?
И с точки зрения покупателя, если продавец создает искусственные трудности с оплатой, то какой может быть мотив платить или даже просто продолжать пользоваться этим продуктом? Раньше оплатить было проще и удобнее, чем пиратить, сейчас уже нет.
Очевидно, что в случае обычного магазина ущерб понесет страховая.
Эти примеры не подходят для нашего случая, по-моему это очевидно. Если игру можно купить легально без испанских карт, то пиратство наносит ущерб продавцу игры, он получает меньше денег, если игра в принципе не продается на территории РФ/РБ - пирать сколько угодно. Грабеж магазина также наносит прямой ущерб продавцу.
В контексте инструмента, каждый решает для себя, что выбрать и как пользоваться. И мне кажется, зарабатывают все же больше головой, а не редактором кода :)
Вобще-то, можно прийти к неожиданным выводам. Они решили не принимать оплату из РБ, РФ (но технически проблем с этим нет), то есть сознательно отключили доход из этих стран. В этом случае речь не может идти даже об упущеной выгоде, а значит пиратство не может в принципе нанести никакого ущерба.
Проблема с этой задачей в том, что она простая, но решение, которое он хочет, скорее всего будет хуже в реальной жизни, чем банальная загрузка в бд. Вместо хранения множества страниц за первый день можно было бы использовать фильтр блума.
Нужно просто разделять на даты по их использованию, даты событий ложаться на UTC идеально, для календарных дат, расписаний и тп нужны таймзоны (и то если таймзон больше одной).
Какого рода эти уязвимости, реально ли вообще ими воспользоваться ?
Может я не знаю чего-то, но в обычном приложении врядли будет какая-то разница между последовательным исполнением тасков через 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 идеально, для календарных дат, расписаний и тп нужны таймзоны (и то если таймзон больше одной).
Решение сомнительное - это да, но учить там особо нечего.
Мне кажется этот подход чужеродным, это какая-то шаблонизация поверх компонент, не очень естественная вещь.