Я буду очень рад, если кто может поделиться опытом решения подобных задач
Предоплата. Рекурентный платеж в качестве предоплаты.
или аргументированно указать на недочеты в моём анализе.
Попросите юриста аргументированно рассказать вам что такое "слабая сторона" договора и что такое "предпринимательский риск".
Компания может выделить время и ресурсы на доказывание факта неоплаты и мошенничества.
А ещё Хабр это не жалобная книга. Этот сайт всё-таки технический, а не юридический.
По существу, все процессинговые центры должны отказаться от проведения рекуррентных платежей платежной системы "МИР", так как нет возможности защитить компании от мошеннических действий клиентов.
Я так понимаю вся статья ради вброса этого тезиса?
Вот только в итоге 404 страница отдается со статусом 200. Не делайте так, это заметание проблемы "под ковёр". В мониторинге должен быть виден правильный статус.
Jaeger, OpenTracing, и хранение в Cassandra - устаревают.
Сейчас появляются решения на Clickhouse, с дополнительной возможностью по агрегации трейсов, перцентилями и статистикой. Также идёт переход на OpenTelemetry.
А я считаю что идея правильная. Ваше недовольство сводится к двум пунктам
Никто не хочет брать самое дешёвое, прекрасно понимая, что через год-два оно посдыхает полностью, расходников и запчастей к нему нет и никогда не будет, а на борьбу с его глюками придётся отрядить половину IT-отдела
Фиксится обязательной гарантией лет эдак на 5-10. Как часть закупки. Со штрафами и УК РФ за несоблюдение. Сразу уменьшится кол-во желающих подать заявку с таким Г.
не закупишь больше принтеры под заблаговременно поставленную ранее нестандартную бумагу (реальный случай), не закажешь уникальные моноблоки без внешнего блока питания (реальный случай), не пропишешь в требованиях к ноутбуку наличие сервисных центров производителя в городах с населением от 200 тыс. человек
Государство это очень большая система, управляемость которой очень сильно зависит от стандартизации. Не должно оно иметь какое-то очень уникальное оборудование. Если это уникальное оборудование так сильно важно, то оно пойдёт новым пунктом в этой КТРУ и станет стандартом для всей системы, а не где-то в её отдельной части.
Из экспериментального сырья, недавно полученного на такой же экспериментальной установке, нужно получить сверхпрочный битум, подобрать режим, верифицировать установку
Мне кажется вы некорректно понимаете суть исследовательской деятельности. Результатом такой работы является заключение, можно ли получить этот битум из этого сырья или нет. Если да, то как. А не гарантия, что вы получите этот битум любой ценой. Т.е. вы продаёте немного не то, и ещё позволяете себя прогибать по условиям, цене и срокам.
Итог закономерен:
И вот, пройдя через все круги ада, мы возвращаемся к разбитому корыту. R&D-бизнес в нефтехимии - это здорово, но прибыль мизерная. Зачастую ее даже нет.
Это не бизнес. Это какое-то увлекательное хобби, за которое иногда что-то платят.
Каждое решение имеет свои ограничения, и наше — не исключение.
Мы не поддерживаем автоматический решардинг (пока).
Мы не поддерживаем multi-shard операции JOIN.
Мы не поддерживаем распределенные транзакции.
С учётом получившихся ограничений, и если отказаться от попыток эти ограничения обойти, то всё можно сделать гораздо проще.
Считаем offset = CalculateHash(shard_key) % BucketNumber. По этому номеру получаем ConnectionString из конфига (не нужно для этого держать отдельную мастер базу и иметь доп.риски отказа), по ConnectionString идём в нужную БД. BucketNumber определяется как константа один раз. А вот количество серверов может быть разным. Перенос отдельной базы на новый сервер это более простая задача, после которой всё что надо будет сделать это поменять соответствующий ConnectionString.
Мы исходим из ситуации, в которой мы приняли решение, что для конкретного проекта сервер ASP.NET должен между запросами не только хранить какие-то статические данные, но и возможно выполнять какую-то полезную работу.
Хранить данные между запросами - как правило для этого используют БД, но можно и кэш.
Статья в основном про кэш. Он может быть: на клиенте, в redis и аналогах, просто in-memory. На тему кэширования написано много статей и лучше. Тема инвалидации кэша вообще не затронута.
"выполнять какую-то полезную работу" в фоне - это background jobs или scheduled jobs.
У вас в статье это всё смешано в кучу и ещё добавлено про DI и юнит тесты.
По большому счёту претензия - "зачем, о чём статья"? Как обучающая - нет, всё поверхностно и "новичково". Как демонстрация лично вашего опыта? Ну не знаю, не хватает чего-то, что нельзя прочитать в учебнике по .Net.
Со временем я конечно привык. Привык и к идее того, что Observable - это новый Promise. <...> А http запросы? Ну почему, если я хочу принести данные и вызываю функцию getData, я должен делать subscribe?<...> А потом чешешь затылок и думаешь: и как теперь принести вторую страницу? Ну или просто обновить данные? Снова вызывать getData? Так зачем? Оно же не запускает запрос, а возвращает Observable, и он то у нас уже есть в руках. Вроде уже не получается. Значит нужен subscribe? И тут ещё многие стараются делать unsubscribe запросу в onDestroy. Видимо не понимают, что observable "заканчивается" после запроса.
Я настоятельно рекомендую вам разобраться (почитать или пройти курс) с RxJS и Observable. Там объснят что некоторые observable не "заканчиваются", как кешировать данные стандарным shareReplay и на другие ваши вопросы.
Сейчас пишу проект с RxJS - совсем по другому приходится мыслить и компоновать код, и у этого способа есть свои плюсы. Некоторые вещи становятся очень простыми. Но иногда когнитивная сложность становится большой, впрочем, такое на любом фреймворке можно наговнокодить.
Это оверинжиниринг, на мой взгляд. Ещё и акторы зачем-то.
В .net есть BackgroundService и всё сводится к 3м сервисам:
Общая очередь (можно в памяти, синглтон или статик ConcurrentQueue) с данными для таски
BackgroundService который смотрит эту очередь и запускает таску
Сервис с бизнес-логикой самой таски. Паттерн стратегия.
Формально вы правы, а по сути - издевательство.
Вы отказываетесь от ответственности за ложные срабатывания.
Меня сильно раздражает ваша капча, перестал пользоваться вашим подсайтом недвижимости.
Вы попробуйте вообще сами попользоваться своими сервисами.
Предоплата. Рекурентный платеж в качестве предоплаты.
Попросите юриста аргументированно рассказать вам что такое "слабая сторона" договора и что такое "предпринимательский риск".
Компания может выделить время и ресурсы на доказывание факта неоплаты и мошенничества.
А ещё Хабр это не жалобная книга. Этот сайт всё-таки технический, а не юридический.
Я так понимаю вся статья ради вброса этого тезиса?
Эээ, нет. Оплата по времени использованию - это привязка карты и разовая оплата (несколько разовых оплат, в разные моменты времени, на разные суммы).
Вы пишете про рекурентные платежи, это периодическая оплата одной и той же суммы, одного и того же периода длительности - это абонентская плата.
Вот только в итоге 404 страница отдается со статусом 200. Не делайте так, это заметание проблемы "под ковёр". В мониторинге должен быть виден правильный статус.
Jaeger, OpenTracing, и хранение в Cassandra - устаревают.
Сейчас появляются решения на Clickhouse, с дополнительной возможностью по агрегации трейсов, перцентилями и статистикой. Также идёт переход на OpenTelemetry.
Посмотрев на код запросов, у меня сложилось впечатление что их автор умеет в Sql но плохо знает Clickhouse.
Оставлю Вам эту ссылку - https://clickhouse.com/docs/ru/sql-reference/aggregate-functions/reference/argmax
А я считаю что идея правильная. Ваше недовольство сводится к двум пунктам
Фиксится обязательной гарантией лет эдак на 5-10. Как часть закупки. Со штрафами и УК РФ за несоблюдение. Сразу уменьшится кол-во желающих подать заявку с таким Г.
Государство это очень большая система, управляемость которой очень сильно зависит от стандартизации. Не должно оно иметь какое-то очень уникальное оборудование. Если это уникальное оборудование так сильно важно, то оно пойдёт новым пунктом в этой КТРУ и станет стандартом для всей системы, а не где-то в её отдельной части.
Мне кажется вы некорректно понимаете суть исследовательской деятельности. Результатом такой работы является заключение, можно ли получить этот битум из этого сырья или нет. Если да, то как. А не гарантия, что вы получите этот битум любой ценой. Т.е. вы продаёте немного не то, и ещё позволяете себя прогибать по условиям, цене и срокам.
Итог закономерен:
Это не бизнес. Это какое-то увлекательное хобби, за которое иногда что-то платят.
Некоторые аналогии подобны котёнку с дверцей - такие же странные.
Возвращаясь к программированию - добавьте idempotency key и retry. И будет вам exatly once.
Как бы вы обучали своих детей?
Мы не поддерживаем автоматический решардинг (пока).
Мы не поддерживаем multi-shard операции
JOIN.Мы не поддерживаем распределенные транзакции.
С учётом получившихся ограничений, и если отказаться от попыток эти ограничения обойти, то всё можно сделать гораздо проще.
Считаем offset = CalculateHash(shard_key) % BucketNumber. По этому номеру получаем ConnectionString из конфига (не нужно для этого держать отдельную мастер базу и иметь доп.риски отказа), по ConnectionString идём в нужную БД. BucketNumber определяется как константа один раз. А вот количество серверов может быть разным. Перенос отдельной базы на новый сервер это более простая задача, после которой всё что надо будет сделать это поменять соответствующий ConnectionString.
Их открытое письмо к президенту почему-то потёрли (https://vc.ru/u/1150867-rossiyskie-investory/394149-otkrytoe-pismo-prezidentu-rossiyskoy-federacii-vladimiru-vladimirovichu-putinu)
Про дело - https://www.rbc.ru/finances/28/04/2022/6260010f9a79471b86b82008
Хранить данные между запросами - как правило для этого используют БД, но можно и кэш.
Статья в основном про кэш. Он может быть: на клиенте, в redis и аналогах, просто in-memory. На тему кэширования написано много статей и лучше. Тема инвалидации кэша вообще не затронута.
"выполнять какую-то полезную работу" в фоне - это background jobs или scheduled jobs.
У вас в статье это всё смешано в кучу и ещё добавлено про DI и юнит тесты.
По большому счёту претензия - "зачем, о чём статья"? Как обучающая - нет, всё поверхностно и "новичково". Как демонстрация лично вашего опыта? Ну не знаю, не хватает чего-то, что нельзя прочитать в учебнике по .Net.
Я слышал другое: там было не плечо, а пирамида РЕПО на облигациях, всё по классике.
У них были клиенты с сегрегированными счетами, и НКЦ продал бумаги с этих счетов.
Возбуждено два уголовных дела в особо крупном размере.
Я настоятельно рекомендую вам разобраться (почитать или пройти курс) с RxJS и Observable. Там объснят что некоторые observable не "заканчиваются", как кешировать данные стандарным shareReplay и на другие ваши вопросы.
Сейчас пишу проект с RxJS - совсем по другому приходится мыслить и компоновать код, и у этого способа есть свои плюсы. Некоторые вещи становятся очень простыми. Но иногда когнитивная сложность становится большой, впрочем, такое на любом фреймворке можно наговнокодить.
Понятно, спасибо.
А расскажите чуть подробнее. Для каких целей у вас кликхаус и из-за чего потери.
В продакшене, как правило, запускается несколько инстансов. Предвижу проблемы агрегации счетчиков.