Python *

Привет, котики и котолюбы! В первой части нашего кошачьего приключения мы выбрали инструменты (Litestar вместо FastAPI, Granian вместо Gunicorn, KeyDB вместо Redis), настроили uv и заложили фундамент проекта. Во второй части мы построили полноценное CRUD API для резюме котиков (или людей, если вам так ближе), подружили его с PostgreSQL через SQLAlchemy, настроили миграции с Alembic и написали тесты с Pytest. У нас уже есть стены и фундамент, но пора ставить крышу и готовиться к продакшену! 🏠

Сегодня мы сделаем наш API ещё круче: вынесем конфиги в отдельный модуль с помощью msgspec, добавим аутентификацию через встроенный JWT в Litestar, ускорим API с KeyDB, проверим покрытие тестами с coverage, упакуем всё в Docker и нарисуем резюме котиков с помощью Jinja. К концу статьи наш кошачий проект будет готов к реальной жизни — поехали! 🚀

Данная статья навеяна мнением о том, что все участки биржевых графиков в прошлом уже повторялись, потому что поведение участников рынка подчиняется типовым сценариям. И если оцифровать все графики, то можно находить похожие участки в текущий момент времени и предполагать, какое движение будет в ближайшее время.

Статья продолжает обсуждение пространственных признаков в Python. Здесь мы рассматриваем пространственные объединения — аналог обычного объединения в мире геоданных, основанный на топологических отношениях между объектами, таких как пересечение, вложение или касание. Также мы узнаем, как правильно рассчитывать различные типы расстояний (и иногда это не просто евклидово расстояние между двумя точками). Например, геодезическое расстояние учитывает кривизну Земли, что особенно важно для анализа данных на больших территориях; расстояние маршрута учитывает направление: оптимальный маршрут от A до B не всегда равен маршруту от B до A. 

Создание цветовых градиентов для дашбордов в Dash/Plotly

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

Решение: автор делится методом создания адаптивных цветовых схем‑градиентов, которые автоматически подстраиваются под количество категорий без ручного задания цветов.

В статье вы узнаете:

Как избежать проблем с ручным назначением цветов

Как предотвратить «заканчивание» заранее подготовленных цветовых палитр

Как создать равномерные цветовые градиенты в рамках заданной схемы

Практические примеры реализации на Plotly и Dash

Для кого: разработчики дашбордов, работающие с Plotly и Dash, которые хотят оптимизировать процесс визуализации категориальных данных.

Что внутри: готовые решения для автоматического создания цветовых градиентов, которые можно легко интегрировать в свои проекты.

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

Время — это одна из самых нестабильных переменных в коде (и не только). Оно безжалостно к CI, случайным багам и здравому смыслу. Особенно если вы пишете логику, где участвует datetime.now(), time.time() или utcnow(): TTL, крон-задачи, дедлайны, отложенные события, idempotency-окна, подписки, отложенная отправка писем, повторная авторизация — всё это работает с временными сдвигами. И всё это будет ломаться, если не заморозить время в тестах.

В этой статье рассмотрим, как выстроить адекватную архитектуру контроля времени: от простых фиксаций до внедрения Clock-абстракции.

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

С чего все начиналось: с типичного дня сметчика

Однажды мне поставили задачу — подготовить сметы для нового объекта, включая раздел вентиляции. Как многие сметчики знают, вентиляция — это один из самых трудоемких разделов.

Ранее я уже делал статью про запуск в пару кликов моделей Stable Diffusion в Google Colab с помощью Fooocus (способ актуальный), сегодня мы проделаем похожее с моделью FLUX 1 Dev, но без web интерфейса.

Многие новички, которые только начинают свою карьеру в программировании, не совсем понимают что такое CRUD. CRUD (Create, Read, Update, Delete) — термин, исходя из обычного перевода (Создавать, читать, обновлять, удалять), обозначает четыре базовые операции для управления данными в системах. Я хочу, попытаться, объяснить на простом примере что же это такое и как с ним можно работать.

Сегодня мы напишем классический десктопный менеджер задач с графическим интерфейсом. Это отличный способ изучить и закрепить:

Как и многие фанаты автоспорта, я внимательно слежу за жаркими дискуссиями вокруг жесточайшего клиппинга (исчерпания заряда батареи) в рамках нового технического регламента Формулы-1.

В этом контексте вспомнил про открытую библиотеку fastf1 с сырыми данными с телеметрии болидов и решил посмотреть в цифрах на этот самый клиппинг. Длинная 1.2-километровая задняя прямая в Шанхае (между 13 и 14 поворотами) показалась мне идеальным полигоном, чтобы на цифрах проверить, насколько сильно машины задыхаются в конце скоростных участков.

Работая с аналитикой, мы часто сталкиваемся с одной и той же проблемой: данные есть, но исследовать их неудобно.

Представим типичную ситуацию. Есть таблица с десятками колонок и миллионами строк. Нужно понять, почему изменился какой-то показатель — например, выручка или конверсия. Обычно это превращается в цепочку SQL-запросов: сначала агрегируем данные по стране, потом по городу, потом по конкретному сегменту пользователей и тд.

Если таких гипотез несколько, количество запросов быстро растёт с геометрической прогрессией. Каждый новый уровень детализации требует отдельного SQL.

В какой-то момент хочется просто кликнуть по графику и мгновенно увидеть более детальные данные. Без написания нового запроса.

Именно здесь на помощь приходят BI-инструменты. Один из самых популярных open-source инструментов для аналитики — Apache Superset.

По данным Data Insight 30% отказов от покупок связано с заказным негативом. Раньше ботов вычисляли по шаблонным фразам, но сейчас спамеры массово генерируют жалобы через LLM. Модерация геосервисов пропускает такой контент. Формально отзывы уникальны и не нарушают правила площадок. Ручная проверка тысяч комментариев требует десятков часов работы аналитика и не исключает человеческий фактор. Визуально отличить качественный фейк от мнения реального клиента стало невозможно.

Противостоять генеративным сетям можно только программными методами. Автоматизировать поиск аномалий в поведении пользователей помогают скрипты на Python. Этот контур защиты включает парсинг данных с обходом лимитов API, вычисление временных выбросов через Z-оценку и семантический анализ текстов с учетом морфологии русского языка (через библиотеку Natasha). Это базовый алгоритм, который позволяет перевести защиту репутации из ручной разметки в измеримый технический процесс.

Python славится своей гибкостью. Мы можем передавать функции как аргументы, возвращать их из других функций и даже "записывать" внутрь них состояние. Но как это работает под капотом? И при чем тут странное слово nonlocal?

В этой статье мы проследим эволюцию: начнем с глобальных переменных, разберемся с замыканиями (closures), поймем магию nonlocal, а затем соберем всё это вместе, чтобы понять, как работают декораторы — один из самых элегантных механизмов Python.

Привет, Хабр! Меня зовут Владимир и это вторая часть материала о трассировке LLM-агентов. В первой части мы настроили инфраструктуру: подняли LangFuse, организовали трассировку и научились управлять промптами как кодом. Если вы ещё не читали — рекомендую начать с неё.

В этой части перейдём от теории к практике: соберём агента, который пишет сказки. В графе будут задействованы инструменты, условные переходы и циклы обратной связи.

Привет, Хабр! Меня зовут Владимир и в последнее время я занимаюсь разработкой агентов на LangGraph. Отладка LangGraph-агента - это отдельная боль: когда граф начинает жить своей жизнью, а LLM уходит в бесконечные циклы, понять, что случилось, становится сложно. В этой статье я покажу, как связать LangGraph с LangFuse для трассировки и покажу как управлять промптами как кодом (версионирование и миграция).

Хочу рассказать о том, как я создавал tg бота на локальной LLM Ollama и с какими проблемами я столкнулся. Бот написан на python и библиотеке telegram.

Почему выбрал именно Ollama? Потому что она бесплатна, есть множество открытых моделей и её очень просто развернуть в своем проекте. Если брать облачные решения от других компаний например ChatGPT, то тут можно упереться в то, что за них нужно платить.

Модели я подбирал под свой компик: 5070 и 32 гб оперативы. Сервера своего нету, поэтому бот работает только когда я дома.

Бот продолжает развиваться. Следить за обновлениями и новыми фичами можно в моем Telegram-канале: https://t.me/rocet_0

На своем тг-канале я предлагаю подписчикам выбор, какую бредовую идею запилить следующей. На этот раз подписчики выбрали новый челлендж: сделать Git в Telegram. Чтобы можно было через бота инитить проекты, пушить файлы, коммитить — и всё это в публичном канале с тредами.

С практической точки зрения этот проект нахуй не нужен. Есть гитхаб, есть гитлаб, есть куча нормальных инструментов. Но как эксперимент — почему бы и нет? Чисто посмотреть, можно ли заставить Telegram работать как VCS.

Я тогда подумал: «Ну, бот на aiogram, база данных, пара команд — делов то))»

Словари, датаклассы и прочая е*атория

Когда я только начинал, первая мысль была: «Положу всё в JSON, на кой мне база данных?» Ну серьёзно, проектов мало, пользователей немного, файлы текстовые че заморачитватся.

Подергал JSON туда-сюда пару дней и понял: не варик.

Во-первых, конкурентный доступ. Два юзера одновременно коммитят — один из них перезаписывает файл другого. Во-вторых, целостность данных. Если бот упал в середине записи — JSON остаётся в невалидном состоянии. В-третьих, версионность. Хранить историю изменений в JSON — это просто перенести проблему из кода в структуру файла.

Короче, JSON — для конфигов, а не для данных, которые меняются каждую секунду.

Выбор пал на SQLite.

Почему:

Ввиду серьёзных ограничений, которые могут быть введены для Telegram, а также возможной блокировки сервиса, я решил сделать простой скрипт для сохранения информации из диалогов. В первую очередь — из Saved Messages (Избранное).

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

Всем привет. В ходе этого материала вы узнаете:

1. Как сделать простой рендер на c# в MonoGame

2. Что использовать, чтобы вызвать python из c#

3. Почему пункт 2 - это плохая идея

4. Как MonoGame игру сбилдить в web/html с помощью его форка KNI

Пристёгивайтесь, будет весело!

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

Но есть более фундаментальный вопрос - кто в системе определяет правила игры?

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

- часть проверок живeт во фронтенде

- часть - в API,

- часть - в промежуточных сервисах

- часть — во временных проверках, добавленных после инцидентов

Добавили новый сервис в цепочку - и изменилось поведение.

Вынесли проверку в отдельный процессинг - и появились состояние гонки.

Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.

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

Для финтеха это особенно критично. Допустимость действия - это не просто проверка прав. Это функция состояния процесса, версии правил, контекста операции и регуляторных ограничений. Если эта допустимость зависит от связности сервисов или порядка их вызова, система становится хрупкой и уязвимой, и тогда, начинается разговор о подходе, в котором бизнес-логика централизуется, версионируется и становится инвариантной к физической архитектуре.

Мы отвлекаем существенные ресурсы в поисках решения для проблем.

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

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

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

Добро пожаловать в обсуждение! Буду рад конструктивной критике и дополнениям.