Сергей Шашков @ShashkovS
Менеджер продукта, методист, разработчик
Информация
- В рейтинге
- 5 089-й
- Откуда
- Россия
- Дата рождения
- Зарегистрирован
- Активность
Специализация
Бэкенд разработчик, Менеджер продукта
Ведущий
Python
Управление проектами
Алгоритмы и структуры данных
Asyncio
Зато диверсификация. Нет завязки на конкретную платформу, хоть и разработка с поддержкой дороже.
Маркетинг. Если данные есть, то в день рожденья можно предложить всем контактам купить в подарок премиум.
А-ха-ха-ха. Они что, думают, что компании гоняют в контейнерах
print('Hello, world!')?Примерно любой мало-мальский бекенд — от десятка до нескольких десятков библиотек. У каждой зашиты ограничения на версии, и иногда это python<=3.10.
И вот ты уже не можешь просто перещёлкнуть версии, тебе нужно бампить версии библиотек. А там начинаются потери обратной совмести. Обновил условный bcrypt, и вот твой бекенд падает, когда пользователь вводит длинный пароль. Потому, что в старой версии просто брались первые 72 символа пароля, а в новой он кидает тебе exception, который ты не ждал.
И это если вообще получилось разрешить зависимости, и код запустился.
Или был у меня бекенд на Sanic ещё на Python 3.9. Памяти жрёт мало, работает быстро.
Обновляю на Python 3.12, нужно обновить Sanic. Обновил Sanic, тесты проходят. Пускаем в прод.
Смотрю графички: а он жрёт в два раза больше оперативки, причём по ней очень скачет, и в два раза больше нагрузка на CPU. То есть все тесты прошли, но по факту стало гораздо хуже.
Без правда хорошего набора тестов и ручного контроля после обновления — вообще никах.
То есть затраты времени и риски совершенно неиллюзорные — и уже прямо сейчас, до какого-либо профита. А выигрыш — может быть когда-нибудь потом, если повезёт, и если дев.опсы смогут "поджать" контейнеры.
Ну, может и мудак, но я очень одобряю идею не писать
make_u32_from_two_u16вместо(a << 16) + b, в том числе по причине, описанной в его комментарии.Могу сказать как краевед, который считал эти копейки много лет (и как математик).
Ни в коем случае нельзя считать проценты на остаток добавляя какую-то дополнительную точность (условно 3 знака после запятой): всё разъедется через некоторое время с вероятностью 100%.
Правильное вычисление выглядит так:
Нужно каждый раз считать полную сумму с нужной итоговой разрядностью «как бы заново» и вычитать предыдущее значение.
Условно, если у нас на вкладе 10.00 рублей и ставка, скажем, 16.5%, и прошло, условно, 17 дней месяца, то должно быть добавлено 10.00 * 16.5 * 17 / 100 / 365 (или 366 в високосный год).
Вот эта штука
10.00 * 16.5 * 17 / 100 / 365, если в результате нужно округлить к целому по математическим правилам, считается точно при помощи несложной арифметики в целых числах.Получится 0.08 (8 копеек). Значит после 17 дней, у нас 10.08.
После 18 дней слова будет 10.08. А вот уже после 19-го дня будет 10.09 рублей.
Такие расчёты гарантируют, что не будет накопления ошибок округления, и на любой конкретный день сумма будет правильной.
Код не обфусцирован, просто открывайте и читайте
Уж лучше через связывание в параметр по умолчанию. Читается получше...
Там мультиподпись. Нужно передать "файлик" через всех подписывающих. Там же наверняка "серьёзные" дяти, не через тележечку они его перекидывают? Значит, есть какой-то программный интерфейс для передачи его по кругу. И на этот интерфейс можно совершить атаку.
Может и не веб, конечно, но веб просится первым.
Насколько я понимаю, устроено всё так.
Там холодные кошельки с мультиподписью.
У каждого из N человек есть девайсина.
На одном из устройств создаётся черновик транзакции.
Дальше файл с черновиком транзакции должен пройти через холодный кошелёк каждого подписанта, и каждый её должен подписать.
В конце файл с подписанной всеми транзакцией переносится на устройтво с доступом к интернету, проверяются подписи, делается транзакция.
Скорее всего передача черновика транзакции происходит тупо через интернет, и данные транзакции отображаются в каком-то веб-интерфейсе.
Соответственно если получится атаковать этот веб-интерфейс, а также компьютер создающего транзакцию, то дело в шляпе. Сначала создаётся кривая транзакция (на кривую сумму и кривой счёт), после чего у всех подписантов в сломанном веб-интерфейсе отображается не содержимое подписываемой транзакции, а то, что вводил первый человек.
С современным вебом с тысячими завимостей под капотом представить себе атаку на веб-приложение легко. Про первую часть с атакой на этап создания транзакции не очень понятно. Но если там тоже веб...
Немного другое решение (на самом деле близкое к поиску циклов, потому как их очень похожим образом можно искать).
Сначала делаем обход в глубину с отметаками времени входа-выхода для дорог одного типа.
Это позволяет за O(1) отвечать на вопрос "является ли эта вершина предком этой", что для нашего графа эквивалентно "если ли из первой ж/д первого типа во вторую".
Дальше делаем обход по железным дорогам второго типа, но проверяем соединённость по первому типу при помощи отметок времени.
А где хоть какое-то сравнение производительности по сравнению с однопоточным вариантом?
Ну а куда они могут без юр.лица в РФ и без "помощи" визы или мастеркарда деть сунуть рубли?
Хотя бы по ip не банят --- уже хорошо.
Это --- временное ограничения из-за атаки на их инфрастуктуру.
У вас устаревшие данные.
У меня максимум на 4 одновременных процессах --- 70К транзакций в секунду.
Дальше до 20 процессов --- около 30К транзакций в секунду. И это в режиме, когда все процессы только и делают, что пишут в одную общую нагруженную таблицу.
Если вы пишете асинхронный вебсервис, то там будет столько воркеров, сколько у вас физических ядер. То есть до 20 воркеров --- всё ок, это достаточно высокая нагрузка.
Не high load, конечно, но..
Более того: Т-банк по комиссиям не присылает уведомлений (никаких и нигде). Их можно обнаружить только в выписке по своей прямой инициативе. Так что среднее число оплат комиссии на человека будет гораздо больше единицы.
Бизнес, ничего личного.
Про API так вообще очевидно: они для доступа к API используют библиотеку openai, и типичный код выглядит так:
То есть их публичные API совместимы с OpenAI'шными. Что просто супер-удобно, ведь имеющийся для OpenAI-код можно легко применить к их модели.
Ой, ещё как считают. У нас есть специальный чатик, куда мы double-дичь с денежками скидываем. Кажется уже пару десятков примеров.
Ой, да, спасибо, поправил.
Но в целом оно криво работает только на экстремальных числах.
То есть в условном банке или при расчёте денег такое писать не нужно: обязательно на копеечку когда-нибудь разъедется. А если считаешь пиксели на экране, то идеально.
Строго говоря x+0.5 не всегда работает правильно.
Вот, кстати, решение на Python через эту формулу. Только оно ощутимо медленнее:
Код на Python