Да, я думаю, это частый кейс, квоты на API, например, бесплатный тариф 10 тыс. запросов в месяц. Делали чтобы каждый сервис часто не дергал базу, синхронизация была раз в минуту чтобы у пользователя графики были красивые. Отдельное ограничение на количество запросов тоже делали, но с фиксированным окном. Я понял в чем различие в вашим кейсом, у нас нет своих кластеров, но если было бы нужно, мы могли бы тоже настроить чтобы через пару минут поднимались доп. контейнеры в облаке. Раз в секунду слишком часто для нас.
Только к исчерпанию квоты относился более лояльно, не хранил локально значения, позволял пока делать запросы до следующей синхронизации. Но я получается хранил списки тех, кто исчерпал свою квоту на это месяц. Переполнение счетчиков тоже не волновало, т.к. если они переполнились, то значит это наш косяк и можно простить.
Спасибо за статью, пришел к такому же решению. Делал свой middleware на go c локальными счетчиками и синхронизацией, идентификатор брал из jwt-токена или сессии. Надо будет обдумать ваше решение с lowBurst и highBurst, мне помимо счетчиков нужен был именно sliding window rate limiter, но я вроде не стал его реализовывать.
Не получиться, из этих 51% часть проголосует за ЕР, к ним просто докинут часть из 49% отсутсвующих и опять будет большинство. Надо ключи выдавать всем, даже тем кто не голосует, чтобы они могли проверить, что не голосовали. Тогда уже особо не добавишь мертвых душ, т.к. население страны более менее известно.
Евгения Ильина, руководитель исследований, рассказала, что для определения оптимального размера слоя алюминия исследователи взяли три образца толщиной 10, 50 и 150 нанометров. При помощи метода вакуумного осаждения ученые отметили, что образец толщиной 150 нанометров показал оптимальную плотность соприкосновения анода и электролита, что обеспечивает стабильную границу раздела между ними в любых температурных условиях.
Может тогда еще попробовать 100 и 200 нанометров? Или они на графиках увидели, что стремится к оптимальному?
Когда то давно хотел на лету парсить конкретные csv файлы из zip-архива чтобы не тратить много памяти. Позже выяснилось, что нужно полностью скачивать весь архив, т.к. важные для распаковки метаданные находятся в конце этого файла (central directory). Но недавно на хабре видел статью, где автор утверждал, что его библиотека на js (https://github.com/greggman/unzipit) умеет это делать (статью похоже удалили). Я немного изучил его реализацию, похоже это действительно возможно, есть несколько путей: 1) Считывать архив дважды (возможно будет долго, но не придется хранить целиком) 2) Использовать метаданные файлов (local file header), которые тоже встречаются в архиве (но как понял, на них не стоит рассчитывать). 3) Если сервер поддерживает HTTP Range requests, то можно сразу обратиться к концу файла и сразу получить нужные метаданные для распаковки. В любом случае, я думаю вам стоит попробовать эту библиотеку. Отпишитесь, если найдете решение получше.
Думаю, настройку этих параметров нужно тоже оставить для UUIDv8. Надеюсь, скоро появится расширение для постгреса, но и сейчас вроде можно сортировать как строки или числа, просто генерировать не в базе. Раньше приходилось парсить для сортировки.
Robinhood следовало использовать стандартный механизм заморозки торгов в обе стороны на более длительное время, чтобы все успокоились. Помимо прямой связи с фондами, они скорей всего хотели угодить ребятам с WallStreet, потому что те помогают им готовиться к IPO, которое можно уже похоронить, наверное. Не нашел информацию про возврат акций, скорей всего это не так просто сделать, все сделки уже прошли через биржу, многие люди уже закрыли сделку с убытком. Вижу только информацию, что они собираются немного возобновить торги.
Интересное развитие. Думаю, то что они натворили намного хуже, хоть и под хорошим предлогом, скорей всего они сами это поняли. По сути, они заблокировали движение цены вверх, оставили только вниз. Такое уже не останется без внимания контролирующих органов, учитывая их связаны с этими фондами. Доверие к приложению скорей всего будет подорвано, оно напичкано такими фразами как «Democratizing finance for all.» и тд.
На самом деле там история еще интереснее, т.к. это было уже третье манипулирование:
По данным компании S3 Partners, участники коротких позиций потеряли 14,3 миллиарда долларов только в среду, а один фонд, Melvin Capital, потребовал от дружественных фирм почти 3 миллиарда долларов в виде финансовой помощи, чтобы избежать банкротства.
Одна из фирм, оказавших помощь Melvin Capital, Citadel Securities, также способствует сделкам, заключенным на Robinhood, работая в качестве своего рода посредника между приложением и биржами Уолл-Стрит. Таким образом, комментаторы обвинили Robinhood в том, что он выполнил приказ Citadel по закрытию торговли.
Roobinhood — это самое популярное для торговли приложение среди физиков, вчера его рейтинг слили ровно до 1 звезды.
Также в работу маркетмейкера входит предотвращение таких резких обвалов, это официальный участник торгов, с которым биржи заключают договор. Поэтому, если ему выгодно, то он просто не даст такому случиться. Ему для этого даже не нужно видеть график, т.к. он видит все позиции в книге заявок. Достаточно просто свозить резким объемом цену в другую сторону, тогда у многих людей закроются стопы в минус, часть людей сами закроют свои позиции, когда увидят, что все пошло не по плану. Таким образом разгружается книга заявок. Они никогда не работают в минус, но по договору иногда обязаны закрывать сделки себе в убыток чтобы поддерживать ликвидность.
Знаю только, что часть паттернов придумал торговец рисом в 17 веке, у него вроде получилось закрыть с прибылью больше 100 сделок подряд, японские свечи пришли на запад только в ХХ веке. Среди этих паттернов есть аналоги известных, которые можно увидеть на старшем таймфрейме.
Да, я думаю, это частый кейс, квоты на API, например, бесплатный тариф 10 тыс. запросов в месяц. Делали чтобы каждый сервис часто не дергал базу, синхронизация была раз в минуту чтобы у пользователя графики были красивые. Отдельное ограничение на количество запросов тоже делали, но с фиксированным окном. Я понял в чем различие в вашим кейсом, у нас нет своих кластеров, но если было бы нужно, мы могли бы тоже настроить чтобы через пару минут поднимались доп. контейнеры в облаке. Раз в секунду слишком часто для нас.
Только к исчерпанию квоты относился более лояльно, не хранил локально значения, позволял пока делать запросы до следующей синхронизации. Но я получается хранил списки тех, кто исчерпал свою квоту на это месяц. Переполнение счетчиков тоже не волновало, т.к. если они переполнились, то значит это наш косяк и можно простить.
Спасибо за статью, пришел к такому же решению. Делал свой middleware на go c локальными счетчиками и синхронизацией, идентификатор брал из jwt-токена или сессии. Надо будет обдумать ваше решение с lowBurst и highBurst, мне помимо счетчиков нужен был именно sliding window rate limiter, но я вроде не стал его реализовывать.
Микроиглы - ножки микрочипа
Не получиться, из этих 51% часть проголосует за ЕР, к ним просто докинут часть из 49% отсутсвующих и опять будет большинство. Надо ключи выдавать всем, даже тем кто не голосует, чтобы они могли проверить, что не голосовали. Тогда уже особо не добавишь мертвых душ, т.к. население страны более менее известно.
Тут просто не написали, что подрядчику нужно будет самому туда для замеров летать
Может тогда еще попробовать 100 и 200 нанометров? Или они на графиках увидели, что стремится к оптимальному?
Мне кажется, наоборот, положить сайт проще, если он выполняет дополнительные вычисления
Да, это же всего лишь сервисы Google, они каждый день падают, просто совпадение
Когда то давно хотел на лету парсить конкретные csv файлы из zip-архива чтобы не тратить много памяти. Позже выяснилось, что нужно полностью скачивать весь архив, т.к. важные для распаковки метаданные находятся в конце этого файла (central directory). Но недавно на хабре видел статью, где автор утверждал, что его библиотека на js (https://github.com/greggman/unzipit) умеет это делать (статью похоже удалили). Я немного изучил его реализацию, похоже это действительно возможно, есть несколько путей:
1) Считывать архив дважды (возможно будет долго, но не придется хранить целиком)
2) Использовать метаданные файлов (local file header), которые тоже встречаются в архиве (но как понял, на них не стоит рассчитывать).
3) Если сервер поддерживает HTTP Range requests, то можно сразу обратиться к концу файла и сразу получить нужные метаданные для распаковки.
В любом случае, я думаю вам стоит попробовать эту библиотеку. Отпишитесь, если найдете решение получше.
Думаю, настройку этих параметров нужно тоже оставить для UUIDv8. Надеюсь, скоро появится расширение для постгреса, но и сейчас вроде можно сортировать как строки или числа, просто генерировать не в базе. Раньше приходилось парсить для сортировки.
Похоже на обычный фильтр, можно не создавать для этого отдельный роут:
GET /tickets?status=booked
Некоторые также не любят заворачивать ответы в структуры с полями status, success и т.д., предполагается, что у нас уже есть для этого HTTP-статусы.
Идея прикольная, но нужно было собрать датасет из голивудских фильмов. Немецкие регистраторы создают такое себе впечатление.
Roobinhood — это самое популярное для торговли приложение среди физиков, вчера его рейтинг слили ровно до 1 звезды.
Лучше наладить энергетику и вместо майнинга продавать нефть за крипту