Python *

Как мы превратили цифровое ТВ в радар

Open Source проект по мониторингу воздушного пространства на SDR

Зачем вообще делать радар из телевизора?

Традиционные радиолокационные системы (РЛС) — это огромные антенны, киловатты мощности, разрешения на частоты и бюджеты уровня «военного отдела». Нам же хотелось видеть небо, не нарушая ни законов физики, ни законодательства.

Так родилась идея собрать пассивную когерентную локацию (PCL) — систему, которая ничего не излучает, а просто слушает уже существующие сигналы в эфире.
FM-радио, LTE, цифровое ТВ — всё это мощные «осветители», которые и так покрывают территорию. Почему бы не использовать их?

Мы выбрали сигнал DVB-T2 (546 МГц) — стабильный, мощный, и что особенно приятно — с известной структурой (OFDM).

Результат? Получился радар без передатчика, который можно запустить хоть на балконе. И да, всё это — на полностью open source стеке.

Как «Про это» стало первой киберпоэмой. Стихотворение, которое впервые в истории использовало фотоколлаж, разбивку строк по принципу «лесенки» и типографские эксперименты, напоминающие современные веб-дизайн?

Практичные Python-привычки: явное состояние и мемоизация, асинхронность для продакшн, ошибки и raise, типизация и валидация, ленивая загрузка и кеширование

На данный момент я прохожу 5-дневный интенсив по AI‑агентам от Google. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В этой статье вы узнаете как сделать так, чтобы ИИ не просто «отвечал», а «понимал» и «запоминал»? И если вы когда‑либо задумывались о том, как научить LLM‑агентов вести осмысленные, долгосрочные беседы, эта статья станет вашим проводником в мир сессий и памяти, которые формируют ИИ агентов.

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

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

Можно ли с помощью Python и математических метрик лучше понять поэзию? В этой статье я покажу, как с помощью кода можно количественно сравнить стили Александра Пушкина и Михаила Лермонтова.

Злоумышленник успешно обошёл средства контроля безопасности компании. Ему не пришлось взламывать репозиторий напрямую. Вместо этого он использовал доверительные отношения между AI-моделью и высокопривилегированным MCP-сервером.

Положа руку на сердце, давайте признаемся: когда вы только начинали учить Python, вам наверняка на первом же занятии вам сказали: «Списки (list) — изменяемые, а кортежи (tuple) — нет. Запомнили? Молодцы».

И большинство из нас кивнуло и пошло дальше. Казалось бы, всё просто: если данные могут меняться — берём квадратные скобки [], если это константа — круглые (). Задача решена.

А что, если я скажу, что на этом простом правиле заканчивается Python для новичков и начинается Python для профессионалов?

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

Всем привет! Меня зовут Бронислав Алексеев, я разработчик и один из организаторов сообщества Python-разработчиков в Новосибирске — PythoNSK.

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

И да, нам удалось привлечь Никиту Соболева, core-разработчика CPython. Рассказываю, как это было с нуля: бронирование помещения, поиск участников, составление расписания.

Кстати, эта статья написана в преддверии второго митапа PythoNSK - он будет в субботу 22 ноября, а в этой статье мы разберем плюсы и минусы нашего первого митапа, проведенного 13 сентября 2025 года!

Но обо всём по порядку. Всех интересующихся - просим под кат.

Классический сценарий: есть база данных и приложение на бэкенде. Для подключения достаточно знать адрес, порт, имя пользователя, пароль — и прямой доступ перед вами. Но что делать, если необходимо подключить no-code базу данных, которой можно управлять только через REST API? Есть ли способ интегрировать такие подключения в логику «красиво», не поломав архитектуру?

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

Маршак хорошо переводил Шекспира, но насколько он был близок к оригиналу? Сохранен ли у него ритм, размер, смысл и структура? Установлю это математически точно с помощью Python.

Технический разбор процесса разработки торговой платформы с использованием Gemini, Claude и ChatGPT. С настоящими постановками задач, архитектурными проблемами и выводами.

Всем привет! Меня зовут Артём, и последние 6 месяцев я создавал полноценную веб-платформу для алготрейдинга. Около 95% кода было сгенерировано c использованием современных LLM, большая часть с помощью Gemini 2.5 Pro, ручные правки составили менее 5%

Речь о проекте Depth Sight. Это платформа с гибким визуальным конструктором торговых стратегий, бэктестингом, реальной/бумажной торговлей, мобильной pwa версией и нативно встроенным Ai ассистентом для помощи в создании и объяснении торговых стратегий, а также анализа результатов бэктестов. Эта статья не столько об алготрейдинге, сколько о новом подходе к созданию сложных программных продуктов. Это кейс о том, как человек с видением продукта может в одиночку создать платформу промышленного уровня. Или нет? Предлагаю разобраться вместе.

У знакомого есть консалтинговая компания по внедрению продуктов 1С в бизнес и он поделился болью - у его заказчика - среднего размера строительной компании необходимо внести в систему порядка нескольких сотен смет в xlsx формате в 1С конфигурацию, которую они внедряют.

Сложность в том, что другие инженерные отрасли сильно отстают от IT в плане культуры разработки. Во времена моей юности по ФИДО ходила присказка "Если бы строители строили дома, как программисты пишут программы, то первый же залетевший дятел разрушил бы цивилизацию". Скорее всего автор этого афоризма никогда не был знаком с реальными строителями. Сейчас скорее наоборот - если бы строители писали программы, мы бы не вышли из эпохи арифмометров. Мы в IT приучены к тому, что ревью кода не пропустил коммит с лишним пробелом.

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

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

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

Есть два способа, которые позволяют вашему боту получать обновления от серверов Telegram. Это long polling и вебхуки. Давайте разберемся, что это такое и когда какой вариант лучше использовать.

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

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

Вы бежите к колодцу, поднимаете тяжеленную крышку, а там... уже всё плавает. А через пару минут доходит осознание: насос благополучно проспал момент включения. Привет, внеплановые 20 минут откачки и «удобрение» участка самым неожиданным способом.

Я посмотрел в сторону готовых решений за 3000+ рублей (используют емкостной метод (измеряют точный уровень 0-100%), имеют качественный корпус, готовое приложение и гарантию), но обнаружил, на мой взгляд, подводные камни: мало отзывов — устройства довольно новые на рынке, закрытая система — нельзя ничего доработать под свои нужды.

А мне было нужно простое, как лопата, решение. Чтобы устройство оповестило меня: «Колодец полный, не желаешь ли включить насос? ПОЖАЛУЙСТА 😠» — и желательно в Telegram, где я точно замечу это сообщение.

В нашей компании AnyMaint, которая занимается разработкой софта для управления техническим обслуживанием и ремонтом (CMMS) промышленного оборудования, одной из главных задач является нормализация имён тулов (инструментов). Под «тулом» мы подразумеваем любой промышленный актив: машины, станки, приборы, оборудование и т.д.

Предисловие. Продолжаю публиковать свои наработки и мысли по работе с ИИ. На этот раз я решил что просто собирать информацию с сервисов или агентов генерировать ответ это интересно, но скучно. Надо что бы система могла делать сложные действия. Для выполнения сложного действия нужен программа или я как это назвал сценарий. Сценарий работает исходя и списка доступных сервисов который есть у него. Доступные сервисы предполагают не только получения информации но и действия . К примеру отправка письма или приведение в действие какого либо устройства с необходимый для работы параметрами. Генерация сценария это только первый этап работы по обработки сложных запросов. Но начнем с него. Дальше с полученным json кодом будет работать интерпретатор. Его я буду рассматривать в следующих статьях. Наверное. Но это не точно может мне будет лень продолжать. Так что начнем вот сама статья.

Каждый, кто прошел путь от print("Hello, World!") до своего первого серьезного проекта на Python, знает и любит списки и словари. Но как часто мы задумываемся, почему они работают именно так, а не иначе? Эта статья — для тех, кто готов пойти дальше поверхностного использования API и заглянуть в реализацию CPython. Мы разберем, почему list — это на самом деле динамический массив, а не связанный список, и как хеш-таблицы позволяют словарям творить свою магию с амортизированной сложностью O(1). Это знание не только интересно само по себе, но и критически важно для оптимизации производительности в высоконагруженных приложениях.

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

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

Наш проект был именно таким: монорепозиторий, десятки микросервисов, сотни зависимостей и общие библиотеки для всего подряд. В кодовой базе было около 220 Python-пакетов и примерно 70 Docker-контейнеров, которые собирались из них. Всё хранилось в одном репозитории, а полный пайплайн для pull request’ов проходил в Azure TFS до 4-х часов.

Именно это пришлось оптимизировать...