Python *

Что сработало хорошо

MQTT — надёжный и простой протокол для умного дома

Плагин-архитектура — легко добавлять новые устройства

Обработка ошибок — система устойчива к сбоям

Очередь команд — предотвращает конфликты

Что можно улучшить

Поддержка больше протоколов — Zigbee, Z-Wave, Matter

Голосовая обратная связь — подтверждение команд голосом

Сценарии — поддержка сложных сценариев (макросов)

Машинное обучение — адаптация под привычки пользователя

Советы для разработчиков

Начинайте с простого — начните с одного устройства, затем масштабируйте

Тестируйте надёжность — тестируйте в реальных условиях

Обрабатывайте ошибки — устройства могут быть недоступны

Документируйте API — облегчает добавление новых устройств

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

При запуске MVP считаем вначале не клики вообще, а деньги и время. Деньги потому, что до серьёзных вложений полезно быстро и по возможности бесплатно проверить, нужен ли проект рынку. Время потому, что его легко потратить не на сам MVP, а на подключение Яндекс.Метрики, Google Analytics, событий, воронок, отдельной базы и прочей обвязки. В итоге идея ещё не проверена, а вокруг неё уже начинает расти аналитическая система.

Рассмотрим простую схему с 1-2 быстрыми метрики, которые напрямую проверяют УТП или главный пользовательский сценарий. Пользователь нажал кнопку покупки. Начал создавать проект. Зарегистрировался. Перешёл в Telegram. Этого уже хватает, чтобы понять, работает ли сценарий и есть ли живой отклик.

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

Разберем именно такой вариант. Маленький Django-бэк один раз деплоится на простом хостинге, принимает события через пиксель, хранит их в SQLite и отдаёт статистику JSON-ответом. Дальше во всех новых фронтах меняются только названия event и src.

Особенно удобно это в тех случаях, когда фронт живёт на бесплатном или засыпающем хостинге. У free web services на Render сервис уходит в spin-down после 15 минут простоя, а файловая система там ephemeral, поэтому локальный SQLite для таких счётчиков работать не будет. В качестве простого примера отдельного маленького бэка можно использовать PythonAnywhere, где есть бесплатный аккаунт с одним web app. Но сама идея не привязана к этим площадкам и повторяется практически где угодно.

Я работаю с OpenAI Codex в двух режимах. Дома — за мощным ПК с двумя экранами и в поездках на дачу/отдых/по работе — с ноутбука

И довольно быстро столкнулся с неожиданной проблемой:
контекст, сессии и история Codex не синхронизируются между устройствами. OpenAI этого просто не предусмотрели!

Ниже история о том, как я решил данную проблему.

Николай Заболоцкий эмоционально переживал за атомную бомбардировку в Японии, написал стихотворение про березы и про птицу иволгу, а получилась у него молитва. Я убедился в этом с помощью Python.

Привет, Хабр. Компаниям часто приходится подписывать договоры и акты с клиентами. Полноценный ЭДО — это долго и дорого для простых задач, а сканы по почте и личные визиты — неудобны.

Закон № 63-ФЗ разрешает использовать простую электронную подпись (ПЭП). Это обычный код из СМС на телефон. Такой способ подтверждает согласие клиента и подходит для большинства гражданских договоров.

В статье расскажем, как собрать на Python сервис для подписания документов. Вы сможете встроить его в свои ИТ-процессы.

Проект PhotoMentor создавался как ИИ-ментор для фотографов. Механика простая: пользователь загружает снимок, а под капотом Gemini выступает в роли арт-директора — анализирует композицию, работу со светом, цветовую гармонию и выдает детальный фидбек с оценкой.

С главной проблемой Vision-моделей я столкнулся в первый же день закрытых тестов. Я скормил Gemini свой тестовый снимок: крупный портрет собаки, положившей морду на лапы.

Модель уверенно выдала:

Предыстория. Ну как ИИ-стартап, в общем-то обычный SaaS но с ключевыми задачками в бизнес-процессах для LLM. 

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

На первом этапе архитектура ИИ-слоя выглядела очень просто и типично:

user request ⭢ RAG retrieval ⭢ LLM ⭢ answer

В прототипе все работало отлично. Но после запуска в реальном продукте начались первые проблемы. Именно тогда этот стартап и попал ко мне.

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

Одна жалоба повторялась достаточно часто: «Когда что‑то падает, приходится обходить несколько серверов, смотреть логи по отдельности и пытаться сложить картину вручную. ELK/syslog решают, но ради пары сервисов это перебор.»

После этого я решил собрать небольшой прототип LogRanger — CLI‑утилиты, которая по SSH забирает логи с нескольких серверов и открывает их в lnav одной командой. Ниже коротко расскажу, какую проблему хочу закрыть и что именно делаю.

Пока IT-директор «Магнита» ищет способы сэкономить 200 млн рублей на серверах и обновляет техрадары, в их логистике ежегодно «сгорает» 2,5 миллиарда. Я пришел в комментарии к CIO с готовым алгоритмом, который пакует фуры со скоростью 500 000 объектов в секунду с учетом LIFO, развесовки и крена, но получил лишь игнор и минус в рейтинг. Что ж, переходим к публичному вызову: 168 часов против 2,5 миллиардов. Кто быстрее — математика или корпоративный TOGAF?

Как я заменил Excel-сводные на Telegram-бота и ускорил контроль потерь на складе

Я автоматизировал рутинный процесс, который постоянно отъедал время: сбор выгрузок, построение сводных в Excel, перенос результатов в Google Sheets и ручной контроль повторений. Теперь всё делается одной кнопкой в Telegram: бот берёт последний файл из папки на Яндекс.Диске, обрабатывает данные и выкладывает готовую витрину в Google Sheets. Отдельно он показывает товар, который начнёт списываться в ближайшие 24 часа — это стало не просто ускорением, а новым инструментом управления потерями.

Раз в несколько месяцев я вижу одни и те же обсуждения:
«Manual QA больше не нужны»,
«Рынок перегрет»,
«Всё автоматизируют и заменят».

Если коротко — нет, QA никуда не исчезает.
Но профессия действительно сильно меняется. И тем, кто работает в тестировании, важно понимать в какую сторону.

В этой статье расскажу. Что нужно делать, чтобы не остаться у мусорки без работы 👇

История о том, как я создал свою соцсеть. И у меня даже получилось что-то. Видеохостинг, мессенджер, короткие ролики, стена и многое другое

Всем привет! В этой статье расскажу про свои ошибки и новшества во время работы над проектом, а точнее его улучшением. Эта статья является продолжением серии статей про данный проект.

Речь пойдет о моем проекте edge-weather-forecast — лёгкой нейросетевой модели прогнозирования температуры, которую можно запускать прямо на метеостанции или на простом CPU-устройстве вроде Raspberry Pi.

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

Если вы хотите узнать ещё больше об организации процессов ML-разработки, подписывайтесь на наш Телеграм-канал Варим ML

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

Привет, Хабр!

Если вас заинтересовал заголовок, то вы, скорее всего, уже знакомы с разработкой Telegram или Discord-ботов. И что также вероятно: для получения обновлений вы используете обычный polling. Сегодня же я вам предлагаю ознакомиться с другим способом получения обновлений - через webhook.

В «городском каньоне» GPS-сигнал подвержен эффектам многолучевого распространения и экранирования, что порождает аномалии в измерениях псевдодальности.
Классические фильтры Калмана, предполагающие аддитивный гауссовский шум, в таких условиях демонстрируют резкое падение точности оценки позиционирования.

В статье сравниваются два нелинейных фильтра Калмана:

классический Fusion UKF (централизованный мультисенсорный UKF с фиксированной гауссовской моделью шума)
мультисенсорный Variational Bayes Fusion UKF, в котором шум измерений моделируется распределением Стьюдента через вариационное байесовское приближение, а итеративная оценка скрытой масштабирующей переменной позволяет автоматически подавлять аномальные GPS-измерения.

В сценариях с имитацией GPS-аномалий по типу городского каньона Variational Bayes Fusion UKF более чем вдвое превзошёл Fusion UKF по RMSE позиционирования.

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

Чтобы алгоритм работал лучше и искал только тех, кто вероятнее готов к сделке, между собой связываются рекламное объявление, звонок и итоговая сделка. Для этого в Яндекс через офлайн-события возвращается звонок или уже факт сделки. 

В этом гайде разберём MVP на Python: он добавляет номер на лендинге под yclid, хранит выдачу в SQLite, принимает вебхук звонка от МТС Exolve, создаёт конверсию и формирует CSV под импорт в Яндекс.Метрику. Получается повторяемый поток данных от рекламного клика до офлайн-цели без ручной склейки.

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

Привет, сообществу Habr!

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

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

Чтобы удовлетворить ожидания заказчика, выполнить вверенную нам работу и достичь высоких результатов при разработке функционала, нам нужны данные для тестирования, близкие к реальным. Тут возникает сложность – на тестовом контуре либо небольшой срез не консистентных промышленных данных, на которых нельзя протестировать полноценно функционал (например, витрину по операциям определенного сегмента клиентов с глубиной месяц, квартал), либо мы начинаем генерировать синтетику, не всегда попадая в нюансы вариативности данных, тратя на это дополнительные ресурсы.

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

Когда строим бэкенд по DDD и CQRS, роуты и OpenAPI обычно собираем вручную. Urich делает иначе: описываешь ограниченный контекст одним объектом — маршруты и документация появляются сами. Обзор фреймворка на Starlette и примеры кода.