Доброго времени суток, товарищи, эта статья, так скажем, продолжение предыдущей статьи об SQLAlchemy 2.0 для новичков, в этой статье мы узнаем что такое Python Generic и как его можно использовать в наших целях при взаимодействии с БД.

Вы, наверное, хотите сказать: "Ну отказался и отказался, что тут такого?". Чтобы добавить контекста, расскажу немного о себе. Ещё год назад я новоиспечённый гофер, только начинаю познавать основы языка, делаю свои первые пет-проекты и начинаю делать свои первые отклики. Естественно получаю кучу отказов. В тот момент я готов хвататься за любые возможности, лишь бы получить бесценный коммерческий опыт, даже работать бесплатно. По сути обучение и самообразование - это такая же неоплачиваемая работа. Если бы тогда я получил подобное предложение, я бы не смел отказаться и согласился бы на любые условия. Забавно, как быстро растут аппетиты, когда знаешь себе цену и на что ты способен.

Друзья, сегодня мы погрузимся в мир Pydantic 2 – мощного инструмента для валидации данных в Python! Узнаем, почему эта библиотека стала незаменимой в 30% Python-проектов и как она упрощает работу с данными. От базовых концепций до продвинутых техник – мы охватим всё, что нужно знать современному Python-разработчику. Готовьтесь к практике – ведь только так можно по-настоящему освоить Pydantic и сделать ваш код более надёжным и эффективным.

ORM были призваны восполнить пробел между объектно-ориентированными языками программирования, которые предоставляют разработчикам возможность работать с сущностями путем обращения к их интерфейсам, определяемым их чертежами (интерфейсы, классы, структуры), и процедурным подходом, реализуемым движками SQL-серверов. В некоторых случаях сюда же пытаются включить и адаптеры NoSQL хранилищ, вроде MongoDB, но конкретно с ней сильно проще, поскольку документ и так, в целом, предствляет из себя вполне себе сносно организованный объект с полями, маппинг которых в объекты языка программирования весьма тривиален, по сравнению с SQL.

Другая проблема, которую пришлось решать ORM в процессе решения первой — сформировать инструмент, который позволил бы составить правильный SQL-запрос в терминах языка программирования, при этом постараться не потерять в доступных "в сыром виде" средствах выражения на соответствующем SQL-серверу диалекте.

Привет! Меня зовут Дима, я архитектор в Купере. Сегодня расскажу о шаблоне проектирования Strangler, который мы использовали для поэтапного выноса бизнес-логики из монолитной системы в отдельный сервис. 

Сначала обратимся к первоисточнику, а затем перейдем к практическим моментам, с которыми столкнулись в процессе работы. Поехали!

Продолжаем цикл статей по асинхронной SQLAlchemy в стиле ORM!

Если вы ещё не успели ознакомиться с первой частью, настоятельно рекомендую сделать это, так как сегодняшний материал будет опираться на уже освоенные знания.

Что нас ждёт сегодня?

- Сессии и фабрики сессий: Узнаем, как эффективно управлять сессиями для взаимодействия с базой данных.

- Добавление данных в таблицы: Освоим безопасные методы добавления новых записей с использованием ORM-методов.

- Извлечение данных из таблиц: Погрузимся в мир извлечения данных. Рассмотрим простые запросы и более сложные фильтры для работы с данными.

После прочтения этой статьи вы сможете уверенно добавлять и извлекать данные с помощью SQLAlchemy для любых табличных баз данных.

Не пропустите, будет интересно и полезно!

Наконец-то пришло время взяться за то, что я давно планировал — подробный гайд по асинхронной версии SQLAlchemy 2.0 в стиле ORM. В этой серии статей я подробно расскажу обо всех аспектах: от создания моделей и установления связей между ними до миграций с Alembic и взаимодействия с данными в базе. Мы будем шаг за шагом разбирать ключевые моменты работы с асинхронной базой данных, что позволит вам глубже понять SQLAlchemy и применить эти знания на практике.

Для начала, давайте разберёмся, что такое SQLAlchemy и почему каждый разработчик, работающий с реляционными базами данных (такими как SQLite, PostgreSQL, MySQL и т. д.), должен знать о ней. После этого — настройка. Мы будем работать с PostgreSQL, но не переживайте: код, который мы напишем, универсален для всех реляционных баз данных. Мы начнем с базовой настройки SQLAlchemy для асинхронного взаимодействия, а затем перейдём к созданию таблиц в современном декларативном стиле.

Хабр, привет!

В этом материале будем настраивать кластер PostgreSQL с Patroni и etcd. Видели множество статей на эту тему, но наше отличие в том, что мы устанавливаем кластер в виртуальной среде, используя новые компоненты.

Немного теории. Patroni — это инструмент для управления высокодоступными кластерами PostgreSQL. Он упрощает настройку и управление репликацией благодаря автоматическому переключению на резервные узлы и восстановлению после сбоев.

В нашем материале мы рассмотрим настройку такого кластера с использованием etcd для координации, а еще будем использовать только пакеты для ручной установки. Потому что частенько в локальных репозиториях преобладают старые пакеты, в которых есть уязвимости. В таких случаях лучше устанавливать пакеты вручную.

Зачем мы это делаем?

Во-первых, интересно. Во-вторых, это нам позволит установить последние версии пакетов без открытого доступа в интернет с серверов. Во многих компаниях изолированная сетевая среда — поэтому вот вам памятка по такой задаче.:)

Итак, приступим.

Хотите сделать процесс тестирования более эффективным и покрыть больше случаев с меньшим количеством кода? Тогда параметризованные тесты в Pytest — именно то, что вам нужно. В этой статье мы разберёмся, как с помощью параметризации можно существенно ускорить и упростить тестирование вашего приложения.

Привет, хабравчане!

В первой части были рассмотрены паттерны проектирования Repository и Unit of Work.

Это вторая часть цикла о DDD. В ней расскажу, как добавить к проекту событийно-ориентированную архитектуру.

Код подопытного приложения ищите в репозитории по ссылке. Подробнее о DDD и паттернах Repository и Unit of Work читайте в первой части по ссылке...

И вот настал тот день, когда я наконец соизволил встать с дивана и дописать следующую статью о микросервисах. Кто не в теме - в прошлой части мы выяснили, как сильно неправильная пунктуация и тупые приколы могут раздражать. Ну и немного обсудили что такое микросервисы и зачем они вообще нужны. Не будем мы отходить от трендов и в этой части - продолжим погружаться в этот дивный машинного перевода, шуточек за 300 и микросервисов.

В контексте разговоров о больших языковых моделях (LLM) все чаще возникает аббревиатура RAG – Retrieval-Augmented Generation, или если переводить на русский язык, то «поисковая дополненная генерация». В этом тексте попробуем в общих чертах разобраться, как работает RAG, и где он может быть применим на практических задачах.

Облачные сервисы на сегодняшний день стали неотъемлемой частью ландшафта ИТ. Множество различных приложений размещается и успешно функционирует в облаках. У облачных решений есть целый ряд преимуществ, например, мы можем легко масштабировать решение в случае, если увеличилась нагрузка. Также можем выполнить поэтапное обновление компонентов приложения прозрачно для пользователей решения благодаря использованию нескольких экземпляров сервиса.

Но при проектировании систем, основанных на облачных сервисах, важно правильно выбрать архитектуру решения. Конечно, никто не мешает самостоятельно придумывать свою архитектуру, но, скорее всего, то, что вы «изобретете», уже кто-то придумал до вас. Так наиболее успешные реализации приложений получили распространение в качестве шаблонов проектирования.

Привет, Хабр! Меня зовут Андрей Бирюков, я эксперт в области информационной безопасности, эксперт Учебного центра IBS. В этой статье я расскажу о лучших шаблонах и паттернах для облачного проектирования, которые помогут вам создать масштабируемые и надежные приложения.

Имея за плечами опыт работы с Kubernetes в различных облачных провайдерах вроде AWS и Yandex Cloud я столкнулся с необходимостью развертывания кластера вне облака на виртуальных машинах. 

В статье расскажу про то, как подготовить high-availability кластер, используя инструмент под названием RKE2 - Rancher Kubernetes Engine.

Масштабирование ИТ-инфраструктуры и переход к высоконагруженным многокомпонентным сервисам дает бизнесу не только преимущества, но и сложности. Одна из основных — необходимость обеспечения для сервисов возможности отказоустойчиво и надежно обмениваться тысячами сообщений без риска их потери или повреждения. И в этих задачах часто не обойтись без реализации очередей сообщений.

Рассказываем об основных сложностях развития высоконагруженных ИТ-систем и способах их преодоления с помощью очередей сообщений на примере Tarantool Queue Enterprise.

Материал подготовлен по мотивам вебинара «Как создавать высокопроизводительные очереди сообщений с различной архитектурой». Вы можете посмотреть его здесь.

Привет! Меня зовут Вадим Клеба, я руковожу командой бэкенд-разработки в Телемосте. Последние девять лет я разрабатываю высоконагруженные распределённые системы. Раньше я разрабатывал search-as-a-service-решение с эффективным полнотекстовым поиском с учётом релевантности.

В статье расскажу, как в Яндекс 360 строили API в течение десяти лет без дропа обратной совместимости, выдерживающий сейчас сотни тысяч RPS. Вы узнаете, какие подходы мы изначально закладывали, чтобы наш API прожил так долго. 

Существует мнение, что основная проблема больших языковых моделей — в склонности к галлюцинациям. Когда нейросеть генерирует текст с информацией, не связанной с запросом.  

Меня зовут Полина, я инженер по разработке ПО искусственного интеллекта в YADRO. Вместе с коллегами я разрабатываю системы на базе генеративных моделей, в том числе вопросно-ответных ассистентов. В рамках одного из проектов мы вместе с экспертом команды Андреем Соколовым задались вопросом: действительно ли проблема галлюцинаций так актуальна для современных предобученных LLM в вопросно-ответном сценарии.

Для этого мы провели эксперимент на собранном датасете. Попутно рассказали про модели-трансформеры и дали строгое определение понятию «галлюцинации LLM». Все подробности — под катом.

Есть в Айти стандартные грейды: Джун, Мидл, Синьор.

И всех руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии 😊

Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.

Unit of Work отслеживает все объекты, которые были загружены в память и изменены в ходе выполнения программы. Он управляет их состояниями и сохраняет изменения в базе данных в конце транзакции. Это делается с использованием сессий, которые действуют как контейнеры для всех изменений.

Когда работа завершена, Unit of Work выполняет commit для всех изменений, сохраняя их в базе данных. Если что-то пошло не так, выполняется rollback, и база данных возвращается в состояние до начала транзакции.

В данной статье рассмотрим, как реализовать паттерн Unit of Work с использованием SQLAlchemy.

Статья является заметкой про библиотеку aioquic и ее использование для WebTransport. Заметка была ранее написана как разбор чужого примера, при знакомстве с aioquic. Заметка описывает события QUIC и HTTP/3 реализованные в aioquic, опираясь на старый рабочий демонстрационнай пример. В худших академических традициях, к старой заметке была добавлена "вода" про кликер - о создании простейшего приложения которое увеличивает число по запросу пользователя.
Для тех, кому не не интересна "вода", лучше начать с раздела [Работа с WebTransport в Python используя aioquic].