Browser Policy Manager: распаковка

В предыдущих публикациях я уже рассказывал, зачем вообще появился Browser Policy Manager, почему я начал с Firefox Enterprise Policies и почему не стал делать «просто генератор policies.json ». Эта статья — более техническая. Здесь я хочу разобрать, как Browser Policy Manager устроен внутри на версии 0.8.8. Версия 0.8.8 для проекта важна тем, что в ней фактически сложилась основная архитектура продукта:

https://habr.com/ru/articles/1051206/

#firefox #browser_policy_manager #корпоративные_политики #policiesjson #fastapi #sqlalchemy #json_schema #системное_администрирование #информационная_безопасность #open_source

Чтобы ваши тесты работали быстрее, нужен простой советский… xdist. Я измерил. Часть 2

В первой части я ускорил большой интеграционный pytest-сьют с получаса до полутора минут за счёт инфраструктурных правок. Во второй проверяю следующий очевидный слой оптимизации — pytest-xdist. Результат оказался не магическим, но полезным: -n auto дал ещё ×3.4 локально и около ×2.7 в CI. В статье показываю, почему xdist не заменяет дешёвый setup, а только домножает его; как разводить БД и Redis по воркерам; где упираются соединения Postgres; и почему память Docker VM и тюнинг Postgres не сдвинули потолок.

https://habr.com/ru/articles/1047134/

#pytest #pytestxdist #python #xdist #интеграционные_тесты #ускорение_тестов #параллельное_тестирование #postgresql #sqlalchemy #redis

Ваши тесты медленные не из-за базы данных. Я измерил

Есть устойчивое поверье: интеграционные тесты медленные, потому что ходят в настоящую базу. «Подними SQLite в памяти», «замокай репозитории», «не гоняй Postgres в CI» — стандартный набор советов. Мокать я не люблю, но крыть упрёк «настоящая база — это медленно» было нечем. Поэтому я сел, спрофилировал и померил: 3316 интеграционных тестов, прогон 30 минут. После трёх правок инфраструктуры — 109 секунд. База оказалась ни при чём, а совет «чисти базу через TRUNCATE, это быстрее DELETE» у меня работал ровно наоборот — обидно вдвойне, потому что эта рекомендация уже лежала в черновике моей следующей статьи.

https://habr.com/ru/articles/1045923/

#pytest #pytestasyncio #интеграционные_тесты #Python #sqlalchemy #postgresql #fixtures #asyncio #cprofile #event_loop

nORM — ORM, но есть одно «no»

Если вы работаете с базами данных и используете ORM, вы, вероятно, сталкивались с той же проблемой, что и я. ORM отлично подходят для отображения таблиц на объекты. Но они начинают мешать, когда запрос становится сложным: агрегации, тщательно продуманные JOIN’ы, формы отчетов, которые не соответствуют одной модели на таблицу. Вы боретесь с ORM, переходите на сырой SQL, а затем вручную пишете связующий код (маппинг). Не каждый SELECT возвращает то, что подходит под одну ORM-модель. SQL - это лучший язык для доступа к данным. Лучшие ORM, которые я использовал, такие как Drizzle , побеждают, потому что они остаются близки к SQL. Я хотел пойти дальше: хранить SQL в системе контроля версий и генерировать из него типизированный Python. Именно поэтому я создал nORM (no ORM - не ORM) и выпустил версию v0.1.0 на этой неделе (мой первый опенсорс проект).

https://habr.com/ru/articles/1044020/

#ОРМ #sql #sqlalchemy #кодогенерация

novo post no blog: suas queries do sqlalchemy podem ser cacheadas sem redis manual

pool configurado, índices no lugar, mas o endpoint de relatório ainda é caro demais pra rodar a cada requisição. o lru_cache não resolve porque os argumentos variam. o redis resolve, mas você acaba escrevendo código de infraestrutura no meio da lógica de negócio.

o dogpile.cache é a abstração que faltava: regiões configuráveis, invalidação por chave, e um mecanismo de lock que evita o dogpile effect quando o cache expira sob carga.

https://www.riverfount.dev.br/posts/dogpile_cache_sqlalchemy/

#python #sqlalchemy #cache #performance

GigaIDE Pro для FastAPI, Flask и SQLAlchemy

Наш предыдущий обзор касался поддержки в GigaIDE — возможно, самого популярного фреймворка Python, который, однако, восходит к эпохе шаблонизаторов, когда веб-страницы формировались на бэке. Кстати, обзор, как реализована поддержка идеологических братьев Django в Java, есть здесь . Сегодня мы рассмотрим поддержку других популярных Python-фреймворков: FastAPI, Flask, SQLAlchemy и немного Pydantic. В отличие от Django, все из них стали популярны благодаря своей легковесности и узкой специализации. Первые два — это веб-фреймворки, третий — ORM-фреймворк.

https://habr.com/ru/companies/sberbank/articles/1040482/

#gigaide #python #fastapi #flask #sqlalchemy #pydantic

Как за один вечер я написал сервис инвентаризации оргтехники для филиальной сети из 16 локаций

Знакомая работает в IT-департаменте организации с 16 филиалами и ~5000 единиц оргтехники на балансе. Попросила: “Сделай сервис, чтобы загрузить фотку шильдика, и он сказал, у кого эта железка стоит”. Звучит просто. На практике это вылилось в production-сервис с распознаванием по фото через Claude vision, ETL из бухгалтерских .xls (привет, xlrd 1.2), нормализацией грязных инвентарных номеров и автопушем в Google Sheets. Рассказываю про все грабли — от deadlock pandas vs xlrd до бага, который считал две разные железки одной

https://habr.com/ru/articles/1039940/

#Python #FastAPI #SQLite #ETL #pandas #инвентаризация #Claude_vision #OpenRouter #SQLAlchemy

I think #SQLAlchemy is a magnificent software project, worthy of great respect. But oh my god is it sapping my energy on a hobby project.

The biggest point of friction is that for various reasons, I want my domain objects to be driven by attrs plus cattrs. It's a combination I know well, and it lends itself perfectly to some of the things I'm doing.

But of course, the SQLAlchemy ORM wants to be the source of truth for my object graph. There being multiple layers at which you can do any given thing is also pretty exhausting.

I'm considering my alternatives. Do I keep SA but not use the ORM? Fall back to executing SQL statements directly via a lower-level, simpler library? Use a completely different type of datastore?

#python #programming