Привет, Хабр! Если вы работаете с Python дольше пары недель, вы наверняка сталкивались с конструкцией, начинающейся с символа @. Это декораторы — мощный инструмент, который делает код чище, читабельнее и соответствует принципу DRY (Don't Repeat Yourself). Но за элегантным синтаксисом скрывается несколько ключевых концепций языка, которые важно понимать.
За последние ~5 лет я много раз сталкивался с задачей собирать логи: обычно из маленьких или средних по размеру кодовой базы проектов. Отправлять логи из кода не проблема, у Java и Go для этого есть библиотеки практически из коробки. А вот разворачивать что-то для их сбора — головняк. Понятно, что решаемый (ещё до ChatGPT, а сейчас так тем более), но всё же. Все системы логов, прежде всего, ориентированы на большой-большой enterprise мир и его требования, а не на простых смертных с несколькими палками, клеем и дедлайном "вчера".
Запуск ELK для меня каждый раз испытание: куча настроек, нетривиальный деплой, а при заходе в UI разбегаются глаза от вкладок. С Loki и Graylog — немного проще, но всё равно функций сильно больше, чем мне нужно. При этом разделять логи между проектами, добавлять других пользователей в систему так, чтобы они не видели лишнего — тоже не самый очевидный процесс.
Поэтому примерно год назад я решил, что сделаю свою систему для сбора логов для себя: максимально простую в использовании и запуске. Чтобы разворачивалась на сервере одной командой, вообще без настроек и без лишних вкладок в интерфейсе. Собственно, так появился и теперь вышел в open source Log Bull: система для сбора логов для разработчиков с проектами middle-sized размера.
(спойлер: в конце будет ссылка на GitHub)
Таск-менеджеры вроде Jira — хороший инструмент для ведения проектов. Вот только есть одна проблема — на них очень быстро забивают. В первую очередь — проектные менеджеры (на всякий случай: я тоже забиваю). Когда проект стартует, менеджер с командой, как правило, делают волевую попытку декомпозировать его на эпики и задачи. Каждая задача получает красивое описание, а иногда даже назначенных исполнителей и дедлайны.
Потом проект стартует…
Внезапно меняются требования и бэклог, появляются дополнительные зависимости. Часть задач внезапно оказывается ненужной, ещё более внезапно меняются менеджеры и ключевые участники. Рано или поздно таски начинают зарастать мхом: апдейты не комментируются, статусы не двигаются.
В какой-то момент наиболее ответственный член команды решает устроить субботник и позакрывать то, что уже сделано. Отсюда — популярность следующих вопросов в поддержке Jira:
Привет, Хабр! Каждый, кто хоть раз искал подержанную технику, знает эту боль: часы ручного мониторинга Avito, десятки страниц и попытки на глаз определить, адекватна ли цена. Выгодные предложения улетают за минуты.
Я решил подойти к этой задаче как инженер и создать личного ассистента, который бы делал всю грязную работу за меня: 24/7 сканировал Avito, сам оценивал адекватность цены и присылал мне в Telegram только самые сливки.
Так родилась идея проекта Intelligent Deal Finder. В этой статье я познакомлю вас со своим проектом, который решает эту задачу. Эта статья будет ознакомительной.
Мир программирования разнообразен, и новичкам сложно выбрать первый язык. Важно понять свои цели и предпочтения, чтобы сделать правильный выбор и уверенно начать.
Сложность языка зависит не только от его особенностей, но и от вашего опыта и готовности разбираться в материалах. Объективного критерия нет.
Часто сложность связывают с уровнем языка: низкоуровневые ближе к машинному коду и требуют работы с памятью и процессором, что сложнее, но даёт больше контроля. Высокоуровневые проще в использовании благодаря большим стандартным библиотекам и готовым решениям. Однако эта классификация не всегда однозначна и вызывает споры.
AI генерирует тесты, но 95% из них не работают — галлюцинирует классы,
путает поля, использует несуществующие API. Знакомо? Мы в отделе RAPID прошли через
это на проекте с биржевым протоколом TWIME. Делимся итеративным подходом:
как за 3 шага превратить хаос из 307 тестов в 109 работающих.
С конкретными промптами, метриками и выводами.
Привет! Это команда Яндекс Практикума. В первой половине года мы провели исследование рынка Python-разработки и узнали, как меняются требования работодателей и к чему стоит готовиться джуниору при трудоустройстве. Рассказываем самое важное.
Предисловие. Я тут работаю с lmstusio сервером и мне нужно было приложение на andriod которое бы с ним работало быстро и без всяких дополнительных танцев с бубном. Сделав его я подумал почему бы не предложить другим может кому то же надо. Выглядит он так
Привет, чемпионы! Мы детально разобрали природу проблемы и изучили арсенал методов. Теперь перейдем к самому важному — практическим результатам. Я протестировал каждый подход на реальной задаче создания инфографики "Agentic AI Explained" и готов показать, что действительно работает.
Представьте опытного трейдера: наверняка он не говорит котировками и не рассказывает про индикаторы — он просто говорит «сильный тренд», «пробой уровня» или «ложный отскок». Для него график это язык: свечи, объёмы и уровни складываются в понятные фразы о том, что сейчас происходит на рынке. Именно от этой человеческой интуиции я и отталкивался в своём эксперименте.
Идея была такая: а что, если научить искусственный интеллект понимать этот язык? Не подавать модели сырые числа, а переводить бары и объёмы в текстовые описания наблюдаемых паттернов и кормить ими языковую модель. Гипотеза была что в тексте уже будет содержатся достаточно данных, чтобы модель научилась связывать недавнюю торговую историю с тем, пойдёт ли цена вверх на следующий день.
Инструмент эксперимента — модель distilbert‑base‑uncased с Hugging Face и это облегчённая, быстрая версия BERT для понимания языка. Мне показалось это практичным выбором для прототипа — позволяет быстро проверять разные способы текстовой разметки без гигантских ресурсов. Цель была чёткая: по текстовому описанию недавней истории торгов предсказать рост цены на следующий день.
Но это исследование моя попытка представления рыночных данных как языка, а не попытка сразу создать алгоритм для автотрейдинга. Ещё важно: это мой личный эксперимент, проведённый одним человеком и выполненный однократно. Результаты дали интересные наблюдения.
Расскажу, как происходила разметка графиков в текст, какие шаблоны сработали лучше и какие метрики использовались. Также отмечу ограничения подхода и идеи для повторных экспериментов.
А ещё весь код уже на GitHub.
Рассматриваются встроенные в Python возможности декларативного программирования и их развитие в библиотеках SQLAlchemy, NumPy, Pandas. Показывается применение трех видов декларативного программирования с помощью библиотеки DecPy: аналогов SQL, QBE и Prolog. В том числе приводятся рекурсивные запросы.
Краткое содержание:
2025 год. Эпоха, когда ИИ генерирует код, модели меняются каждые полгода, а техлид должен разбираться не только в паттернах, но и в условиях лицензионного соглашения.
Всем привет. Недавно пришлось решать проблему идентификации пользователя по номеру телефона в маленьком стартапе, позволяющим оформлять и оплачивать заказы онлайн. Почему именно номер телефона, а не электронная почта, например, или авторизация через соц. сети? Телефон сейчас, как мне кажется, де-факто стандарт для таких кейсов - это во-первых, а во-вторых, используя телефонный номер, можно подключать разные варианты его подтверждения: от смс до звонков с дальнейшим вводом либо кода из смс, либо последних цифр звонившего номера. Думаю, тут всем знакомы подобные механики.
Изначально я сразу и предложил использовать механику с СМС-шлюзом, но так как я тут имею дело со стартапом без инвестиций, то меня попросили придумать как на первоначальном этапе можно сэкономить (в идеале обойтись на этом этапе совсем без затрат), так как основной целью запуска было тестирование бизнес-идеи.
По предварительным исследованиям целевая пользовательская аудитория продукта является пользователями мессенджера Telegram. Вот в эту сторону я и начал думать. “Коробочный” механизм авторизации через виджет Telegram не отдает номер телефона пользователя, а нам именно он и нужен. Городить велосипед по получению номера телефона по id пользователя идея не самая лучшая, поэтому я решил сделать своего ТГ-бота для механики авторизации. Я на паре сайтов уже видел подобные решения, быстрый поиск по примерам реализации этой механики не дал внятных результатов. При поиске “авторизация telegram” я наткнулся на сайт, который был первым в поисковой выдаче. Пошел смотреть как у них все устроено, рассмотрим по шагам:
В мире, где существуют десятки специализированных библиотек для парсинга HTML, XML, JSON и других форматов, может показаться,- что регулярные выражения — это устаревший инструмент. Однако такое мнение ошибочно. Регулярные выражения, или RegEx, остаются фундаментальным и незаменимым навыком в арсенале любого разработчика, работающего с текстовыми данными.
Их сила заключается в универсальности и мощи. Когда речь заходит о неструктурированных или полуструктурированных данных — лог-файлах, пользовательском вводе, конфигурационных файлах или больших текстовых корпусах — регулярные выражения часто оказываются самым прямым и эффективным решением. Они предоставляют лаконичный язык для описания сложных текстовых шаблонов, позволяя выполнять такие задачи
Приветствуем, коллеги. На связи Олег Сивченко @OlegSivchenko.
Уместен и закономерен ваш интерес, как мы обзаводимся правами на перевод зарубежных книг и где берём новинки. Такой вопрос задал нам читатель @PopovGP. Действительно, книгоиздательская отрасль не один год приспосабливалась к современным реалиям, но один интересный новый тренд действительно стоит раскрыть подробнее: мы стали активнее искать и рассматривать небольшие издательства, настроенные на сотрудничество. Так, уважаемый коллега @Holmogorov завершил длительный поиск базовой книги по Jetpack Compose, найдя в небольшом американском издательстве «Payload Publishing» отличный труд Нила Смита «Основы JetPack Compose: Разработка приложений для Android с помощью Jetpack Compose, Android Studio и Kotlin». Эта книга вышла в августе.
О другой очень похожей находке я хочу рассказать вам сегодня. Это совсем свежая новинка «Программирование бэкенда на Python. Практическое руководство» под авторством Тима Питерса. Обнаружили мы её в каталоге маленького индийского издательства «GitForGits».
Блог Михаила | Python | Разработка | Best Practices
"Всем привет! Меня зовут Михаил, я веду Telegram-канал «Python Шпильки», где делюсь изящными приемами программирования. Сегодня хочу показать один из самых полезных паттернов..."
В этом уроке мы сделали общение с ботом значительно более выразительным и профессиональным. Вы освоили два ключевых навыка: форматирование текста с помощью HTML и MarkdownV2 через параметр parse_mode, и отправку медиафайлов с локального диска, используя класс FSInputFile. Теперь ваш бот способен не только обмениваться информацией, но и представлять её в наглядном, структурированном и визуально привлекательном виде.
Для закрепления полученных навыков мы подготовили несколько практических заданий. Они помогут вам увереннее работать с форматированием и отправкой файлов в рамках нашей модульной архитектуры. Нажмите на любое из заданий, чтобы раскрыть его условия.
Нельзя стать отличным программистом без глубокого понимания структур данных, потому что программирование - это написание алгоритмов и выбор подходящей структуры данных для этого алгоритма. Алгоритм говорит компьютеру, что делать, а структура говорит компьютеру, как хранить данные из алгоритма. В этой статье мы рассмотрим такие структуры данных как: списки, кортежи и словари.
Команда Python for Devs подготовила перевод статьи о том, как с помощью LlamaIndex и Pydantic можно превратить сканы чеков в структурированные данные. Минимум кода — и у вас готовый CSV для анализа.
Представьте инженера по добыче на центральном объекте в Permian Basin (прим.перев. крупнейший нефтегазовый бассейн США), которому до рассвета нужно успеть десятки дел. Одна скважина работает ниже нормы. Для другой нужно принять решение о капитальном ремонте. Данные разбросаны по электронным таблицам, SAP, PDF‑документам и полевым логам. Знакомая ситуация? А теперь представьте, что у инженера есть помощник, который читает все файлы по скважинам, анализирует сигналы SCADA, понимает исторические тенденции добычи, проверяет наличие запчастей на складе, формирует рекомендацию и отправляет краткий отчет руководителю операций — ещё до второй чашки кофе.
