Однако, очень неудобно, что не все сервисы позволяют удобно пользоваться сторонними приложениями для хранения паролей и продвигают свои — например, Майкрософт и «Стим». В авторизация через собственное приложение, конечно, есть свои плюсы, но лично мне не хочется держать несколько приложений для этих целей.
Но... У Яндекса буквально своя кастомная реализация hmac otp и внешние приложения адекватно не могут сгенерить 6 цифр. Потому что 8 букв. https://github.com/WhiteApfel/pyYaOTP/blob/c7b5dc45293c12ba1907c45fe5e579093151b03e/pyYaOTP/main.py
То есть правильный ответ: нет, такой код не выполнится. И это не про подвох, не про тонкости, не про магию. Это просто базовая логика работы типов данных в Python. То, что должен понимать любой человек, который пишет код больше полугода
Ну... Некоторые не склонны писать говнокод. И могут писать крутые штуки, но да, не иметь представления, почему какая-то неведомая выдуманная фигня не работает. Мне за 6 лет ни разу не приходило в голову сувать в ключ словаря что-то нехешируемое. И нет, я не читал учебник по питону. И да, знаю об этом только из подготовки к собесам уже на должности повыше. Наверное, я просто профнепригоден был всё это время и отсутствие этих ценнейших знаний мешало решать бизнес-задачи...
Там и архитектурно были проблемы, но трогать код не сильно хотелось в моменте. Пошли по пути наименьшего сопротивления.
Замена на проде реально была тупо изменением кредов для подключения. Попробовать можно, это не страшно. Под новые проекты выбор уже сомнений не вызывает. Dragonfly показывает себя не хуже. Но опять же зависит от сценария использования из-за особенностей df.
Тестов не осталось, удаляю всё после ухода из компании. Но кейс был следующий: ~250 экземпляров микросервиса в не пиковую нагрузку, кеширование запросов из базы данных + хранилище глобальных переменных. Примерно 180 тысяч запросов к redis в секунду, и это было норм в базе, но в часы пик приводило к "пробкам" внутри микросервисов. Так как данные не обязаны сохраняться в кеше, нам холодный запуск был норм, замена на Dragonfly дала примерно +35К запросов. Ну и в "простое" ускорило время выполнения общего процесса на 7%, в пиках до 45%, но тут именно общее время смотрели, не обращения к df.
Это ограничение, конечно, затрагивает Selectel, потому что запрещает продажу доступа к своему продукту. Но это же не затрагивает "99%" остальных компаний, которые работают с хайлоадом 👀
Dragonfly по опыту прекрасно показывает себя в продакшене, давая +19% к RPS без танцев с бубном
Ну и многопоточность для cpu bound... Если уж и решили извращаться, то уж лучше через асинхронность. Хоть меньше потеряете на переключении контекста и системных вызовах
Там в конфиг файле написано, что можно отключить часть систем, чтобы снизить нагрузку. Например, тот же solr. Всегда можно попробовать и затестить. Уверяю, запустится без проблем. Впрочем, solr и сам отключится, если ему покажется, что не хватает пространства
Ну, логика есть, на самом деле. Одни из основных условий реализации качественного бот-детектирования и человек-детектирования — покрытие большого количества интернет-пространства и сбор Big Data для скоринга посетителей. Большое покрытие тяжело сделать, если нет безусловно бесплатного тарифа. Вот и получается, что платные пользователи платят за бесплатных, чтобы у платных всё работало лучше.
Справедливости ради, и на "2 ядра, 2 гига" mailcow прекрасно работает и тянет порядка 500 активных пользователей одновременно. Активных, именно что активных, а не получающих одно письмо в день.
Но... У Яндекса буквально своя кастомная реализация hmac otp и внешние приложения адекватно не могут сгенерить 6 цифр. Потому что 8 букв. https://github.com/WhiteApfel/pyYaOTP/blob/c7b5dc45293c12ba1907c45fe5e579093151b03e/pyYaOTP/main.py
Поэтому пошёл Яндекс в пень.
ClickHouse... То есть виноваты русские)))
Вакуумный сферический конь, но это норм практика, если "a: bool". Лучше всё писать явно. Так же, как и "is None" и "is not None".
Можно вообще пройтись по всем PEP'ам. Там достаточно чего есть либо уже, либо никогда не используемого(
Ну... Некоторые не склонны писать говнокод. И могут писать крутые штуки, но да, не иметь представления, почему какая-то неведомая выдуманная фигня не работает. Мне за 6 лет ни разу не приходило в голову сувать в ключ словаря что-то нехешируемое. И нет, я не читал учебник по питону. И да, знаю об этом только из подготовки к собесам уже на должности повыше. Наверное, я просто профнепригоден был всё это время и отсутствие этих ценнейших знаний мешало решать бизнес-задачи...
Там и архитектурно были проблемы, но трогать код не сильно хотелось в моменте. Пошли по пути наименьшего сопротивления.
Замена на проде реально была тупо изменением кредов для подключения. Попробовать можно, это не страшно. Под новые проекты выбор уже сомнений не вызывает. Dragonfly показывает себя не хуже. Но опять же зависит от сценария использования из-за особенностей df.
Тестов не осталось, удаляю всё после ухода из компании. Но кейс был следующий: ~250 экземпляров микросервиса в не пиковую нагрузку, кеширование запросов из базы данных + хранилище глобальных переменных. Примерно 180 тысяч запросов к redis в секунду, и это было норм в базе, но в часы пик приводило к "пробкам" внутри микросервисов. Так как данные не обязаны сохраняться в кеше, нам холодный запуск был норм, замена на Dragonfly дала примерно +35К запросов. Ну и в "простое" ускорило время выполнения общего процесса на 7%, в пиках до 45%, но тут именно общее время смотрели, не обращения к df.
Это ограничение, конечно, затрагивает Selectel, потому что запрещает продажу доступа к своему продукту. Но это же не затрагивает "99%" остальных компаний, которые работают с хайлоадом 👀
Dragonfly по опыту прекрасно показывает себя в продакшене, давая +19% к RPS без танцев с бубном
Пришёл в комментарии написать "Уже писали про dragonfly?", а тут пусто...
Ещё не понятно, зачем вообще в приведённом коде асинхронность. Оно бы ± так же работало и без неё
Ну и многопоточность для cpu bound... Если уж и решили извращаться, то уж лучше через асинхронность. Хоть меньше потеряете на переключении контекста и системных вызовах
И вообще не понял прикола про сложность чтения и нелинейность выполнения. Код внутри асинхронных функций всё так же выполняется строчка за строчкой...
Намешали всего в кучу.
async def function— обычная функция, которая возвращает корутину.
function() вернёт <coroutine object>, это не Future.
await <coroutine object> не возвращает Future. Оно возвращает сразу результат корутины.
Future возвращает только вызов event_loop.create_task(), и то в виде более комплексного объекта типа Task, который лишь унаследован от Future.
Разработчик почти никогда не работает с Future напрямую.
Новичкам для работы с ботами в это всё вникать не надо
Имхо, pytelegrambotapi был плох ещё лет восемь назад. Aiogram намного лучше
Как хорошо, что ребята из Т-Банк хорошо подумали над неймингом и назвались "Т-Мобайл". Так ведь точно никакой путаницы не будет ✨
Там в конфиг файле написано, что можно отключить часть систем, чтобы снизить нагрузку. Например, тот же solr. Всегда можно попробовать и затестить. Уверяю, запустится без проблем. Впрочем, solr и сам отключится, если ему покажется, что не хватает пространства
CRM Пачка стоит в углу, грустно ингалирует глицерин и смотрит на происходящее с ноткой ностальгии
Ну, логика есть, на самом деле. Одни из основных условий реализации качественного бот-детектирования и человек-детектирования — покрытие большого количества интернет-пространства и сбор Big Data для скоринга посетителей. Большое покрытие тяжело сделать, если нет безусловно бесплатного тарифа. Вот и получается, что платные пользователи платят за бесплатных, чтобы у платных всё работало лучше.
Справедливости ради, и на "2 ядра, 2 гига" mailcow прекрасно работает и тянет порядка 500 активных пользователей одновременно. Активных, именно что активных, а не получающих одно письмо в день.
Вроде как, речи о передаче mac/imei не идёт, так?
Ip адрес, географический адрес — из интересного