Можно ли с помощью Python и математических метрик лучше понять поэзию? В этой статье я покажу, как с помощью кода можно количественно сравнить стили Александра Пушкина и Михаила Лермонтова.
Положа руку на сердце, давайте признаемся: когда вы только начинали учить 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-х часов.
Именно это пришлось оптимизировать...
Кейс по оптимизации затрат на Claude API в проекте по автоматизации поиска работы. AI анализировал вакансии и генерировал сопроводительные письма. При 100 пользователях затраты достигали $180/месяц. Решение: Prompt Caching от Anthropic. Экономия 52% ($0.51 → $0.245 за batch из 50 вакансий). Теперь можно делать в 2 раза больше AI-вызовов с тем же бюджетом.
Кому полезно: всем, кто работает с LLM API и хочет оптимизировать затраты.
На крипто рынке у бессрочных фьючерсов существует специальный механизм: ставка финансирования (funding rate) - периодический платёж между держателями длинных (long) и коротких (short) позиций, который служит для выравнивания цены фьючерса с ценой спота.
Арбитраж по ставке финансирования - стратегия, цель которой не столько угадать движение цены, сколько извлечь выгоду из разницы в ставках финансирования на разных площадках или между контрактом и спотом.
Здравствуйте. Я не айтишник — я учитель истории с более чем десятилетним стажем. Но информационные технологии всегда были моей страстью и надёжным инструментом в работе.
В этой статье я хочу рассказать о собственном опыте внедрения системы тестирования в школьной практике. Моя программа предельно проста — она написана на Python в духе unix-way: делает одну вещь, но делает её хорошо. Опытные разработчики вряд ли увидят в ней что-то новое, но цель текста — показать, как принципы системного администрирования и инженерного мышления могут помочь в решении педагогических задач.
Мы устали слушать звонки.
Не из-за любопытства — просто это занимало слишком много времени.
Из 5 минут разговора рождались 20 минут отчёта в Excel, где человек вручную отмечал:
«вежлив ли оператор», «упомянул ли цену», «отработал ли возражение».
Мы построили систему, которая делает это автоматически:
Whisper → QLoRA → отчёт → BI.
Она оценивает звонки, считает метрики и не жалуется на переработки.
Анализ стоит $0.0003 за звонок, и работает это лучше, чем ожидалось.
Но не идеально.
вот обновлённый фрагмент раздела 1. «От Excel к первому прототипу» — с твоей логикой, цепочкой инженерных и управленческих рассуждений: как команда шаг за шагом пришла к тому, что не всё нужно обучать, и где провести границу между здравым смыслом и GPU.
стиль остался естественный, сдержанно ироничный, как будто вы действительно сидели вечером в переговорке и писали архитектуру на доске, а не пыжились быть «инновационными».
MCP Protocol — это новый стандарт. Как HTTP для интернета, только для искусственного интеллекта.
Что это даёт:
Экономия времени: 70-95% на рутинных задачах
Экономия денег: Окупается за 2-4 месяца
Быстрое внедрение: 1-2 недели вместо месяцев
Гибкость: Работает с любым AI
Безопасность: Ваши данные остаются у вас
Кому подойдёт:
У вас есть CRM с повторяющимися задачами
Менеджеры тонут в рутине
Хотите масштабироваться без найма
Нужна быстрая обработка лидов
Аналитика занимает слишком много времени
Введение: Кризис смысла в эпоху больших данных
Начну немножко издалека. Мы живем в парадоксальное время. Искусственный интеллект окружает нас повсюду: он пишет тексты, рисует картины, решает сложные задачи. Но за этим фасадом цифрового всемогущества скрывается фундаментальная, почти метафизическая проблема: наши самые продвинутые модели не понимают ровным счетом ничего. Те, кто сколько-либо погружен в сферу ML, это прекрасно знают. Представьте библиотеку, где каждый книга идеально описана, проиндексирована и взаимосвязана, но нет ни одного читателя, способного понять смысл написанного. Это - точная метафора современного ИИ. GPT-4, Gemini, Claude - это блестящие имитаторы, статистические попугаи, оперирующие символами без малейшего представления об их значении. Они могут рассуждать о физических явлениях, но не понимать их, анализировать метафоры, но не схватывают их суть, генерировать тексты о боли и радости, оставаясь абсолютно пустыми внутри.
Этот разрыв между формой и содержанием, между синтаксисом и семантикой, является последним крупным барьером на пути к настоящему искусственному интеллекту. Но, возможно, есть решение как это обойти. Что если вместо того, чтобы заставлять машины имитировать мышление, создать для них среду, где мышление возникает естественно - как возникают волны в океане или мысли в человеческом мозге?
SemantML: От статистики к семантической нейродинамике
Хочу вас познакомить с проектом под названием SemantML - радикально новый подход к созданию ИИ, который отказывается от парадигмы "обучения на текстах" в пользу "мышления в смыслах". Гипотеза проста и одновременно нова: сознание - это не алгоритм, а динамический процесс в семантическом пространстве, и чтобы создать искусственный разум, нужно сначала создать для него "дом" - среду, где могут рождаться и взаимодействовать смыслы.
