Python *

Привет! Меня зовут Владимир Суворов, я Senior Data Scientist в Страховом Доме ВСК и core-разработчик нашей библиотеки машинного обучения OutBoxML.

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

Приятного прочтения!

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

Привет, Хабр! Меня зовут Максим Попов, я инженер по автоматизированному тестированию внутренних продуктов в Сбере — в том числе SCPL. В этой статье расскажу, как упростить настройку клиент-сервер взаимодействия в рамках фреймворка автотестирования.

Задавались ли вы когда-нибудь вопросом, что происходит под капотом обучения, например, линейной регрессии? Если вы до сих пор не нашли ответ на этот вопрос, то эта статья для вас. Сегодня простым языком разберём, что такое градиентный спуск — от интуиции до полноценного обучения линейной регрессии с нуля.

В мире Data Science написание нейронных сетей, кажется чем‑то очень трудоёмким, доступным для понимания лишь математикам с многолетним опытом. Многие руководства, начинаются со сложных объяснений backpropagation, градиентного спуска и т.п, от которых у новичков складывается впечатление, что написание нейросетей — им не по силам. В данной статье, я хочу развеять подобные убеждения и показать пример, написания простейшей нейронной сети на python. Мы не будем углубляться в теоретические основы высшей математики. Вместо этого, мы просто возьмем данные, напишем код, посмотрим на результат и проанализируем его.

Любому веб-приложению нужен веб-сервер для доступа извне. На самом деле, многие даже не уделяют выбору веб-сервера для своего приложения достаточного внимания: на Django берут "популярный" Gunicorn (а кто-то ещё и обвязывает его Uvicorn'ом), а для FastAPI Uvicorn практически стандарт. Тут "на сцену" выходит Granian, представляющий впечатляющие результаты производительности с простой настройкой.

В своём проекте "Код на салфетке" я использовал uWSGI, но недавно узнал про новый Granian и мне стало интересно на что он способен. Так появилась идея для этой статьи.

В этой статье узнаем:

В этой статье мы разберём, как написать свой многопоточный TCP-порт-сканер на Python. Несмотря на то, что существуют готовые инструменты вроде nmap или masscan, иногда требуется минималистичное решение: встроить проверку в CI/CD, автоматизировать аудит небольшой сети или использовать сканер как обучающий пример. Мы рассмотрим два подхода — на ThreadPoolExecutor и на asyncio, добавим баннер-граббинг, HTTP-проверку и TLS-детекцию. В результате получится компактный инструмент с поддержкой JSON/CSV-вывода, возможностью тонко настраивать параллелизм и таймауты, а также учитывать нагрузку на сеть. Такой сканер удобен для внутренних задач админа и для изучения сетевого программирования.

Если вы только начинаете изучать Python и слышите слово дженерики, скорее всего в голове сразу каша: «что это вообще такое?». На самом деле дженерики - это очень простая идея. Представьте, что у вас есть коробка. В коробку можно положить игрушки, яблоки, книжки - всё что угодно.

Но иногда вы хотите, чтобы в коробке лежали только яблоки. А иногда - только игрушки. И вот тут вам помогают generics.

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

В одной из московских школ мы сделали Telegram-бота, который автоматизировал «операционку»: согласия на мероприятия, запись на кружки, заявки в хозчасть/ИТ, массовые оповещения, анонимный канал психолога и контур директора с согласованиями и дашбордами. Я старался максимально упростить сложную и разрозненную модель управления.

Проект реально сработал, но его пришлось закрыть: с 2025/26 учебного года все школьные коммуникации перевели в национальный мессенджер «Макс» (MAX), а Telegram оказался «под запретом».

Команда Python for Devs подготовила перевод статьи о шести библиотеках Python для визуализации данных. Matplotlib, seaborn, Plotly, Altair, Pygal и Bokeh — у каждой свои сильные и слабые стороны: от академических статичных графиков до интерактивных дашбордов для бизнеса. Выбираем самую подходящую для различных кейсов.

Привет, Хабр! Меня зовут Олег Милосердов, я руковожу проектами по компьютерному зрению в ВТБ. В июле мы с коллегами приняли участие в научно-технологической программе «Большие вызовы» от образовательного центра «Сириус» в качестве наставников. Мы предложили школьникам спроектировать и внедрить автономный модуль распознавания MRZ-зоны документов, удостоверяющих личность, прямо на мобильном устройстве под Android, которое работает без интернета, серверов и облака. В этой статье расскажу, как талантливые старшеклассники справились с задачей, какой опыт получили и какие выводы мы можем сделать как наставники.

Я не делал «крутой ИИ».
Я сделал систему, которая не давала людям уйти обратно к старым процессам.

Первый этап — показал простоту. Второй — показал надёжность. Третий — показал интеллект.

Именно поэтому этот проект стал основой для всей команды ИИ в компании.
Потому что мы доказали:

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

Если вы тоже работаете в корпорации, где «это невозможно», где «нет бюджета», где «это не наша задача» —
начните с каркаса.
Сделайте так, чтобы сегодня стало легче.
И завтра — уже сами будут просить: «А теперь ты сможешь…?»

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

оставлю пища для размышлений и задел на развитие бота

Несколько лет назад наш корпоративный слой данных жил на проприетарных технологиях. Данных было много, а основная СУБД — MPP-система Sybase IQ — долго не обновлялась. Мы регулярно сталкивались с тем, что у кластера «падали» ноды, каталог базы повреждался, порой даже терялись данные, а вендор не спешил выпускать исправления или даже признавать проблему. ETL-процессы работали через IBM DataStage, который также перестал развиваться. Все решения были закрыты, и мы не могли влиять на их улучшение. Vendor lock-in означает, что вы зависите от поставщика: если вендор не поддерживает нужные возможности, развитие замедляется, а долгоживущие ошибки остаются нерешенными. Такое положение становилось критичным.

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

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

В этой статье рассмотрим, как с помощью Python собирать и обрабатывать новости с сайта, имеющего RSS.

В нашей статье мы создадим скрипт на Python, который за заданный период (например, за последние 4 часа) соберёт все записи из нескольких лент сайта BBC, отфильтрует их по ключевому слову «Трамп» и опубликует итоговый подбор в наш Telegram-канал. Далее рассмотрим код, вы легко сможете адаптировать его под любую другую ленту или ключевое слово.

Продолжаем анализировать паттерны проектирования промтов агентов из репозитория https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools и после разбора XML-тегов в первой части переходим к следующему ключевому элементу.

1. Проклятие размерности

Человек эволюционировал в 3 пространственных измерениях, и в них мы себя шикарно чувствуем. В них мы живем, радуемся, грустим, да и все драмы жизни проходят в этих измерениях. Правда в первой половине 20 века Теодор Калуца и Оскар Клейн нашли еще одно измерение, но оно маленькое и его людям не видно. После струнные теоретики, такие как Леонард Сасскинд, Герард т`Хофт, Яу Шинтун, Александр Виленкин  и другие, опять сильно усложнили картину мира, и к 4 пространственным измерениям добавили еще 6 (это минимум), но они все где то не пойми где, и влияют на жизнь только физиков-теоретиков, а остальным n-миллиардам людей на Земле, нет никакого дела до этих измерений, им и в 3 хорошо живется.

Другое дело математика и наука о данных, тут измерений может быть сколько угодно, например вот:

Ночью (а точнее уже утром), я не мог уснуть, из-за навязчивой мысли в голове..

А что если спарсить часть статей с хабра и представить их в виде obsidian графа, будет ли это выглядеть, как красивая база знаний?

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

Я не раз писал об этом: «Python и нечеткое сопоставление: решение проблемы разнобоя в адресах» показывал, как автоматизировать проверку и выравнивание адресов; а в другой статье - «С бумаги на цифровую карту: генерация файла из таблицы для импорта на карту и геокодирование адресов с помощью Python» - речь шла о том, как ускорить перевод бумажных данных в цифровой формат.

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

Почему локальные инструменты не спасают

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

Но реальность большинства проектов другая: сотни файлов, регулярные партии данных от подрядчиков, ежедневные правки от полевых инженеров и требования выдавать отчёты руководству. В таких условиях «локальный» подход быстро превращается в набор костылей.

В этой статье будет рассказано об эмббедингах и методах работы с ними. Расскажу немного математики и приведу много примеров на Python.