PyLounge - программирование на Python и всё о Айти 🐍

Намедни Никита Соболев сделали папку с крутыми каналами ребят из нашего Python сообщества! Если Вам интересен Python и все что связано с разработкой, то смело заглядывайте в подборку, делитесь с коллегами и друзьями. https://t.me/addlist/o2_hXmp5nSUyODNi 🆙 🆙 🆙

Панки — лохи, готы — дуры, я фанат вайбкод культуры Загадываем желание между двумя Никитами и смотрим на гигавайбкодинг security компонентов для DJANGO MODERN REST https://www.youtube.com/watch?v=laJQcNAqxc0

ЧТО?! НЕайтишный гость которого интересно послушать? @metodkina - Алина Кинаревская - методолог, экс-юрист ЦБ и владелица школы танцев. Поговорили о том, почему эксперты саботируют собственный успех, как искать ту самую боль клиента, почему "дошел до финала" не всегда главная метрика обучения, а также почему анализ ЦА ключевой фактор успешного продукта https://www.youtube.com/watch?v=Ts5GQZQBjyk

Впитываем МУДРОСТЬ СТО https://www.youtube.com/watch?v=F6syfmQtT2E

На просторах заблокированных в GTA RP социальных сетей наткнулся на django-nova Typed, unified, and async-first toolkit for Django 5+ https://github.com/Artem7898/django-nova Мнение?

Сегодня у нас в гостях Александр Кондратьев - Senior Software Engineer, Open-Source enthusiast, Django evangelist и просто разнорабочий в мире IT. Погорим про то, какое осознание приходит после нескольких лет карьеры в Айти. Ну ШТОЖ поехали https://www.youtube.com/watch?v=6IWyUz4iWkg

Новый выпуск философских-айти размышлений. Сегодня я расскажу про 4 столпа выживания в айти индустрии (и не только в ней). Вашему вниманию представляется - 4 ПРАВИЛА ЛЕСА https://habr.com/ru/articles/1052108/

12 лет в университете Так уже вышло, что 12 лет назад я поступил в университет в моем городе. Успел и поучиться, и попреподавать, и пописать диссертацию по техническим наукам. Поэтому тема образования не дает мне оставаться равнодушным. За 12 лет я повидал многое - от невероятных историй успеха до бесконечно грустных потухших глаз. Потухшие глаза и полная потеря мотивации студентов это следствие разрушенных ожиданий. К сожалению, как говорил Аршавин, наши ожидания это наши проблемы. Поэтому я подготовил материал, который поможет вам снять розовые очки и выправит ожидания) Я не буду говорить нужно ли получать образование в ВУЗе или нет. Это тема для бесконечного холивара. Просто я попытаюсь управлять вашими ожиданиями, если вы уже приняли решение поступить в университет или только раздумываете об этом. Я бы очень хотел, чтобы этот материал попался раньше мне и всем моим студентам, но рад, что он попался вам и, надеюсь, чем-то помог🙂 https://habr.com/ru/articles/703290/

Пришел, почистил, положил или как сбросить кэш и не уронить бэкенд Базовая ситуация - фронт кэширует отрендеренные страницы в Redis. Катим новый релиз, поменялся контент, по хорошему кэш надо инвалидировать. Не медля ни секунды, полный газ redis.flushdb() НО независимо от того, удаляет Redis ключи синхронно или асинхронно, с точки зрения приложения ключи исчезают одновременно (почти). Значит тысячи запросов одновременно промахиваются мимо кэша и отправляются прямиком на бэкенд. В общем (и целом) случае это cache stampede. Накладывает на союзника пик нагрузки на БД. Прежде чем чинить, давайте решим какие конкретно проблемы мы решаем: 1. Массовый cache miss после flushdb = все ключи протухают в одну секунду. Лечится это "размазыванием" инвалидации во времени. 2. Реальный Stampede на одном горячем ключе, то есть проблема когда именно один популярный ключ протухает, и N одновременных запросов все попадают (🤡) в miss и все бегут перегенерировать одно и то же. Тут нужно что-то типо single-flight или stale-while-revalidate. Размазываем протухание во времени В данном случае не просто delete, а expire с разными короткими TTL, чтобы промахи размазывались по окну, а не ударили разом. Окну? Хорошей идеей кажется взять что-нибудь типо log(n), но реальное ограничение - не размер кэша, а сколько страниц в секунду способен снова отрендерить бэкенд. Эмпирически неплохой считается стартовая оценка n / rebuild_rate, где rebuild_rate это пропускная способность бэкенда по перерендеру страниц. В реальности пропускная способность бэкенда плавающая. Она зависит от текущей нагрузки на БД, лунных суток и сложности рендеринга конкретной страницы. В идеале rebuild_rate сделать адптивным. Брать его из метрик (утилизация connection pool базы, p95 latency эндпоинта рендера). Размазываем def stagger_expiry( redis, pattern="malutka-frontend:*", window_seconds=None, rebuild_rate=200, batch_size=2000, ): keys = list({k for k in redis.scan_iter(pattern, count=1000)}) n = len(keys) if n == 0: return 0 if window_seconds is None: window_seconds = max(1, math.ceil(n / rebuild_rate)) random.shuffle(keys) pipe = redis.pipeline(transaction=False) for i, key in enumerate(keys, start=1): ttl = max(1, math.ceil(i / n * window_seconds)) pipe.expire(key, ttl, lt=True) if i % batch_size == 0: pipe.execute() pipe = redis.pipeline(transaction=False) pipe.execute() return n Хитрость в том, что ключам ставится короткий TTL, промахи размазываются по окну без единоразового дропа. shuffle - гарантирует, что распределение TTL не зависит от порядка обхода. А что по stampede на горячем ключе? Размазывание выше лечит только массовый синхронный промах. Один горячий ключ всё равно протухнет в свой момент, и в эту секунду по нему прилетит столько промахов, сколько было одновременных запросов. Это отдельная задача и решать ее надо отдельно: 1. через single-flight / лок на регенераци - когда N одновременных промахов по одному ключу схлопываются в один перерендер, остальные ждут результат. 2. stale-while-revalidate - отдаём устаревший контент, пока один воркер под локом строит свежий. По сути компромис между актуальностью и эффективностью, но на практике один из самых разумных способов убрать stampede. 3. probabilistic early expiration (XFetch) - это алгоритм перестраивает ключ вероятностно, тем чаще, чем ближе TTL и чем дороже пересчёт. Тоже достаточно популярный способ, но со своими нюансами. Так тривиальная на первый взгляд задача по сбросу кеша (с ростом RPS на проекте) превращается в увлекательное расследование и инженерную задачу. И здорово когда ты "на глаз" и заранее сможешь это заметить 🙂

Намедни прочитал "Чёрную книгу менеджера" от Славы Панкратова Основные тезисы кратко: 0. О проблемах и задержках нужно сообщать сразу, а не надеяться, что они исчезнут сами 1. Менеджера оценивают по результату, а не по оправданиям. 2. Настоящий руководитель берёт ответственность на себя, а не ищет виноватых. 3. Важно понимать, как бизнес зарабатывает деньги, и связывать работу команды с пользой для компании и клиента. 4. Главная задача менеджера - работа с людьми, их развитие, мотивация и организация команды. 6. Если сотрудник не справляется, сначала нужно выяснить: не понял, не умеет, не может или не хочет. 7. Основа управления - уважение к сотрудникам, коллегам и заказчикам. 9 из 10 стоматологов менеджеров в IT строго игнорирую все это :( Если вы ПМ или тимлид - строго рекомендасьен к чтению. Книжечка очень короткая, можно прочитать буквально за полчаса Сверху можно еще шлифануть моим материалом про говорение ртом :)

ФиналОчка по слою данных в Django - Proxy и Абстрактные модели

Продолжаем обсуждения слоя данных. Сегодня поговорим про Manager и QuerySet в лучшем фреймворке современности - Django