Python *

Каждый бэкенд-разработчик рано или поздно сталкивается с ситуацией, когда база данных MySQL внезапно ложится при резком пиковом наплыве пользователей. Классическая ошибка на старте - создавать новое независимое соединение с СУБД на каждый чих приложения, выполнять один короткий запрос и закрывать коннект. Когда на сайт одновременно залетают сотни людей, сервер моментально упирается в системный лимит max_connections и падает с ошибкой OperationalError: (1040, 'Too many connections'), попутно забивая всю доступную оперативную память.

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

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

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

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

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

По условиям кейса организация Meridian, вымышленный крупный B2B-маркетплейс услуг для среднего бизнеса с клиентской базой более 4 млн компаний и оборотом 180 млрд рублей в год, столкнулась с падением выручки и ростом оттока клиентов, а руководству не хватало скорости принятия решений.

Команда победителей хакатона разработала AI-платформу для бизнес-аналитики, объединяющую возможности BI-систем и мультиагентного ИИ.

Как они подошли к решению кейса, почему начали с бизнес-анализа, а не технологий, какие выводы сделали на этапе исследования данных и как это повлияло на архитектуру всей системы?

Хочу рассказать про недавний кейс из своей практики и своих трудовых будней.
Заказчик пришёл с задачей: «Хочу QR-код на сертификатах, чтобы можно было проверить подлинность». У него в голове это выглядело так: он дает мне гугл таблицу с перечнем фамилий, датой, и номером сертификата, скрипт генерирует QR единый для всех сертификатов и как бы этот вопрос закрывается по его мнению. Но при этом должна закрываться самая главная боль - защита от подделки путем переноса QR на другой сертификат. Фактически получалась фикция. С моими возражениями заказчик согласился и я расскажу как мы пришли к криптографическому решению без бэкенда, и покажу конкретный код.

Проблема
Мне как бэкэнд-разработчику приходится работать с деплоем своих проектов, каждый раз одна и та же рутина: настройка сервера, nginx, ssl, безопасность сервера(fail2ban, user), CD и многое другое. Это отнимает очень много времени.

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

Обычный LLM-агент, которого просят писать Python-скрипты под КОМПАС-3D, ошибается системно: придумывает несуществующие методы, путает две ветки COM API, ссылается на отменённые ГОСТы, подставляет невалидные значения в аргументы. Промпты и примеры это не лечат. В статье разбираю другой подход: контекст-слой из нескольких механизмов, где каждый класс ошибок ловится отдельно ещё до того, как код дойдёт до живого CAD. Внутри граф API на 47 тысяч узлов, справочник валидных значений, база действующих и отменённых стандартов, проверка сгенерированного кода настоящим C#-компилятором и разбор ошибок исполнения на живом КОМПАС-3D. С примерами кода и реальным фидбеком, который получает агент. Заодно объясняю, почему для такой задачи отказался от MCP.

Один User сначала кажется удобным: его можно принять в запросе, вернуть из API, сохранить в базу и передать дальше.
Но со временем такой класс смешивает разные границы и перестаёт защищать код.

Разбираю на Python-примерах, чем отличаются DTO, schema, model и entity — и когда отдельные классы действительно нужны.

Безопасный AI-мониторинг Oracle в закрытом контуре с использованием Python, Ollama и V$WAITCLASSMETRIC

Введение

В существующей системе мониторинга Oracle уже использовалось разработанное мной решение, которое с интервалом в 1 минуту собирало метрики производительности из представления V$WAITCLASSMETRIC и отображало их в Grafana. Графики наглядно показывали изменения времени ожиданий в классах User I/O, Commit, Concurrency и других, однако они показывали лишь сам факт изменения нагрузки, не объясняя его причины.

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

Так появился небольшой эксперимент — дополнить существующую систему мониторинга Oracle локальным AI-ассистентом.

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

Я заинтересовался ML и AI в 2019 году, и с тех пор количество статей и примеров кода в Интернете выросло многократно, но одно, к сожалению, так и осталось неизменно — стиль кодирования примеров и их математичность.

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

Это история про пет-проект, который я делал ради трёх вещей одновременно: прогноз приземной температуры на неделю вперёд из данных одной метеостанции, честные интервалы неопределённости вместо голой точки, и работа на железе уровня Raspberry Pi без всякого GPU. По дороге я несколько раз ошибся, один раз откатил целый эксперимент, и в итоге понял про свою же модель больше, чем когда её проектировал.

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

Код лежит в репозитории (ссылка в конце). Данные не выкладываю, брал часовые ряды из Open-Meteo, их можно тянуть самому; в репозитории есть синтетический генератор, чтобы прогнать весь конвейер за пару минут.

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

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

Именно поэтому архитектура проекта получилась такой.

Делюсь опытом: собрал прод-агента на Claude для небольшой студии дизайна интерьера. Чат отвечает на Haiku 4.5, генератор концепций — на Sonnet 4.6, фото из Pexels вместо DALL-E. Без LangChain, без векторной базы, без RAG-фреймворка. Один файл main.py на 712 строк, два промпта. В статье разбираю развилки: почему именно так, на каких граблях постоял (порог кэша 4096 у Haiku, парсинг JSON-обёртки от Sonnet), где этот подход начнёт ломаться. Не «гайд от эксперта» — скорее дневник развилок.

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

Привет, Хабр! Меня зовут Никита Трунов, я — разработчик команды инфраструктурных сервисов K2 Cloud. Сегодня расскажу вам о нашем новом облачном сервисе управления ключами KMS и как он помогает с шифрованием данных в облаке. В этом материале мы разберемся, какие данные приходится защищать, какие существуют модели доверия к облачному провайдеру и как устроена архитектура современного сервиса управления ключами.

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

Доброго времени суток . Спасибо всем заинтересовавшимся моей статьей. Задача коммивояжёра — одна из самых известных задач комбинаторной оптимизации. Её суть заключается в поиске самого выгодного маршрута, который проходит через указанные города по одному разу с последующим возвратом в исходный город. Уже при небольшом числе городов >20 задача не может быть решена методом перебора вариантов за приемлемое время.

Для решения задачи коммивояжёра существует большое количество методов и алгоритмов, самые распространённые — поисковые алгоритмы. Лидеры среди них — генетические алгоритмы и алгоритмы колонии муравьёв.

Я придумал свой вариант.

В статье «Сравнение производительности генетических алгоритмов и муравьиных алгоритмов применительно к задаче коммивояжера Авторы: Sabry Ahmed Haroun, Benhra Jamal, El Hassani Hicham Лаборатория LISER, ENSEM, UH2C Касабланка, Марокко.» от May 2015. Приводятся результаты тестов. Генетический алгоритм был разработан на C++. Муравьиный алгоритм оптимизации был написан на C#.

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

При взаимодействии разработки с менеджментом или бухгалтерией регулярно всплывает одна и та же задача. Нужно либо выгрузить таблицу из базы в Эксель для отчёта, либо, наоборот, залить обратно в СУБД тяжелый xlsx. файл со свежими ценами или списком контрагентов. Настраивать тяжелые ETL-системы ради разовой выгрузки неэффективно. Проблема решилась написанием короткого CLI-скрипта на Python - mysql_bridge. Утилита обеспечивает сквозную двустороннюю конвертацию данных, автоматически анализирует структуру и сохраняет исходные типы на лету. Исходный код скрипта и Readme Здесь. Если Вас заинтересовала или статья была полезна, поддержите звездочками.

Как устроен двусторонний мост

Вся логика инструмента умещается за счёт связки pandas, sqlalchemy и движка openpyxl. Скрипт работает с файлами Эксель напрямую на уровне бинарного кода, поэтому его можно запускать на серверах без установленного офисного софта. Утилита работает в двух режимах.

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

Стандартные модели сегментации хорошо решают задачу выделения объектов, U-Net стала фундаментом в медицинской нише. Но не всегда достаточно просто выделить границу области: маска может давать хорошее покрытие, быть близкой к целевой, однако иметь неадекватный контур — слишком сглаженный или, наоборот, рваный. Функции потерь покажут низкий loss, но на самом деле этот один пиксель, который в реальности переносится в миллиметры распространения, определяет будущее человека.

BISCUIT-Net стремится решить именно эту проблему. Работая как стандартный U-Net, он добавляет легковесное внимание на контур. Модель буквально делает набросок, после чего аккуратно выстраивает границу. Философия модели: «граница это не побочный эффект, а цель».

Конвейер на Python + Hydra, который превращает папку с аудио в богато размеченный датасет: качество речи, просодия, разборчивость, спикер, транскрипция — по колонке на запись. От одной видеокарты до кластера, карты под нагрузкой, и он не падает на «длинном хвосте» записей, на которых обычно рассыпается наивный скрипт.

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