Python *

В мире 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.

Кольца Барромео — это конструкция из трёх колец, обладающая интересным свойством: эти кольца не сцеплены попарно между собой, но полная конструкция из трёх колец неразделима. Ну или если перефразировать: вся конструкция неразделима, но если любое из колец магическим образом пропадает, то оставшиеся два можно разделить. Единственное известное мне практическое применение этих колец — использование в качестве логотипа пива Ballantine. В прошлом году в моей практике повстречался интересный алгоритмический баг, который у меня ассоциируется именно с этой конструкцией.

Команда Python for Devs подготовила перевод статьи о том, как автор выбирает способ написания представлений в Django. Он считает, что обобщённые классовые представления (CBV) скрывают слишком много магии, усложняют чтение кода и отладку. Вместо них он использует базовый View, чтобы сохранять контроль, но при этом избегать громоздких if в функциях.

MSK144 — цифровой протокол, разработанный Джо Тейлором (K1JT) и его командой в 2016 году для проведения связей через метеорное рассеивание. В этой статье будут рассмотрены подробности работы протокола.

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