Бэкенд

От ядра Linux до дообучения языковых моделей: открытые вебинары недели

Как устроить обмен сообщениями между сервисами, найти причины сбоев в распределённой системе, превратить бизнес‑требования в понятные задачи или подготовить модель к работе в реальной среде?

С 3 по 6 августа эксперты OTUS проведут 24 бесплатных демо-урока по разработке, инфраструктуре, архитектуре, аналитике, машинному обучению и другим направлениям. Выбирайте интересующую область и присоединяйтесь.

Системное администрирование, сети и безопасность

• 3 августа, 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться

• 3 августа, 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться

• 3 августа, 20:00. «Какие результаты должен давать DevSecOps‑проект бизнесу и команде». Записаться

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

Разработка и программирование

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 3 августа, 20:00. «Оживляем код: первые шаги в ООП на Python». Записаться

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python: асинхронность, процессы, потоки». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 5 августа, 20:00. «Как AI меняет работу C#‑разработчика». Записаться

Архитектура, системный и бизнес‑анализ

• 4 августа, 19:00. «Будущее корпоративного архитектора: навыки, тренды, технологии». Записаться

• 4 августа, 20:00. «Как аналитику работать с рисками». Записаться

• 5 августа, 20:00. «Влияние нефункциональных требований на архитектуру». Записаться

• 5 августа, 20:00. «MVP глазами бизнес‑аналитика: от идеи до первых функций». Записаться

• 6 августа, 20:00. «Пользовательские сценарии на реальном примере: от бизнес‑требования заказчика до формулирования задачи для разработчика». Записаться

Машинное обучение и работа с данными

• 4 августа, 20:00. «PostgreSQL как память ИИ‑агентов: MVCC, очереди и партиции под нагрузкой». Записаться

• 5 августа, 20:00. «Сделайте модель своей: дообучение LLM методом QLoRA без кода». Записаться

• 6 августа, 18:00. «Практика работы с Docker — ввод модели в эксплуатацию». Записаться

• 6 августа, 20:00. «Базовая структура ML: задачи, pipeline, метрики и функции потерь». Записаться

Битрикс24

• 3 августа, 20:00. «Кастомизация компонентов в Битрикс24». Записаться

• 4 августа, 19:00. «Эффективная работа с диском Битрикс24». Записаться

Управление проектами

• 5 августа, 20:00. «Оценка проекта: от интуитивных догадок к системному подходу». Записаться

Тестирование игр

• 4 августа, 20:00. «Как стать тестировщиком игр: первый шаг в GameDev». Записаться

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

Один оператор сравнения чуть не удалил тысячу пользователей 

На днях наводил порядок в логике автопродления подписок Telegram-бота.
Казалось, задача на полчаса.

Если кратко: у пользователя заканчивается подписка, и бот проверяет дату планируемой оплаты.
Если срок подписки истёк и продления нет, то пользователь попадает в очередь на удаление. Всё просто.

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

Сначала я подумал, что платёж не успел записаться в базу. Проверил – платёж записался.

Потом начал искать проблему в часовом поясе. Тоже нет.

Дальше полез смотреть SQL-запросы, логи, время выполнения задач. Потратил на это больше часа и уже начал подозревать, что где-то появилась гонка между обработчиком платежей и задачей проверки подписок. Стал разбираться…

Причина оказалась намного проще: в фундаменте не стоял тот оператор сравнения.

Вместо subscription_end < now
я написал subscription_end <= now.

Из-за этого подписка была просроченной не только после истечения срока, но и ровно в момент его окончания. Если время проверки и обновления совпадало, пользователь попадал в удаление по граничному условию.

Если задача проверки запускалась в тот же момент, когда обновлялась дата окончания подписки, пользователь попадал в удаление при совпадении времени окончания и времени проверки .

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

В тот момент у меня была тестовая база, поэтому последствия не были бы критичными.  Максимум, произошло бы несколько некорректных удалений.
Но я сразу представил, что было бы в продакшене. Если бы ошибка попала в релиз, задача удаления прошлась бы по всем пользователям, которые удовлетворяли этому условию.

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

Что изменил:

1. Перенастроил удаление: теперь оно происходит не сразу.

Пользователь сначала получает статус "ожидает удаления", а сама операция выполняется отдельной задачей через некоторое время.

2. Настроил перепроверку актуального состояния подписки через x часов, чтобы отсечь ложные срабатывания.

Если пользователь оплатил доступ или подписка продлилась, удаление отменяется.

3. Добавил тест на этот сценарий, чтобы избежать повторения <=ошибки.

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

Мораль:
даже очевидные условия нужно проверять на границах. 

Смотришь на условие и кажется, что ошибиться невозможно. Но однажды выясняется, что была допущена элементарная ошибка, которая убила тонну времени.

Всегда нужно помнить о границе условий. Именно там чаще всего и живут самые неприятные ошибки.

Есть ощущение, что подобные баги зачастую находятся не в сложной логике, а в самых очевидных местах?
Интересно, как вы предостерегаете себя от таких стыдных ошибок? 

Друзья, я просто обязан сказать огромное спасибо всему сообществу Хабра за вашу поддержку и активность под статьей о моем проекте Kakehashi!

Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.

Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.

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

Огромное вам спасибо! 

P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!

Проект: https://github.com/wie-project/kakehashi

Статья на Хабре: https://habr.com/ru/articles/1065502/

Пост на Hacker News: https://news.ycombinator.com/item?id=49145937

🔥 Основы FastAPI: собираем сервис «прочитать позже»

У каждого есть свалка ссылок «прочитаю потом»: 40 вкладок, сохранёнки в Telegram, закладки с 2022 года. Проблема не в том, что нечего читать, — а в том, что всё это невозможно найти и разгрести.

Решим по-инженерному: напишем свой Read-Later сервис и с нуля освоим FastAPI.

6 августа, 19:00–20:30 МСК — бесплатный воркшоп с Ольгой Пичужкиной, Middle Python Developer (S-Cats).

За 1.5 часа:
⚡️ Поймёте, что такое FastAPI и почему он удобен
🧱 Опишете модель данных (SQLAlchemy + Pydantic)
🔁 Напишете полный CRUD
🔍 Научитесь фильтровать через query-параметры
📄 Получите Swagger UI бесплатно
🌐 Подключите простой фронтенд

Для кого: знаете Python, но ещё не писали API.

🛠 Куда дальше — дорожная карта: FastAPI — не просто фреймворк. На нём построен наш MCP Knowledge Server (Qdrant + семантический поиск) — ядро AI-ассистента сообщества, который «помнит» всё изученное.

Цепочка: 🐳 Docker (25.07) → 🐍 FastAPI (06.08) → 🧠 MCP Knowledge Server (сентябрь). В сентябре — отдельный воркшоп: поднимем такой сервер вместе.

📖 Pre-read: за 3 дня до воркшопа — инструкция по установке uv и Python.

🔗 Подробнее: https://debugskills.ru/content?article=labs-fastapi-workshop

#DebugSkills #FastAPI #Python #Backend

Подключайся к онлайн-митапу MWS — эксперты поделятся опытом организации стабильных Go-сервисов ⚙️

MTC Web Services (MWS) приглашает на митап для Go-разработчиков. Подключайтесь онлайн к встрече 11 августа в 15:00, чтобы узнать, как эксперты из MWS и Cloud.ru строят высоконагруженные системы. Спикеры разберут три ключевых слоя Go-сервисов на реальных кейсах и продакшн-опыте.

Вас ждет три технических доклада:

1. «Построение агентов на A2A с изолированным исполнением на Go»

Go-разработчик Вера Касьяненко из MWS расскажет, как построить ИИ-агентов  с выполнением потенциально опасных действий в изолированной среде, используя A2A и Client-go, и какие ограничения необходимы для этой изоляции. Она разберет модель угроз, жизненный цикл задачи и ограничения для безопасного исполнения.

2. «Как разрабатывать эффективные и экономичные Kubernetes-операторы на Go»

Алексей Ковалев из Cloud.ru на примере реального cluster-wide оператора покажет, как снизить потребление памяти с 7,5 ГБ до 400 МБ, а P95 цикла согласования —- со 150 до 40 мс. Он расскажет о кешировании, индексации и балансе между производительностью и стоимостью.

3. «Точный Rate Limiting на API Gateway в мульти-ЦОД инфраструктуре»

Андрей Пушкарев из MWS Octapi расскажет, почему готовые решения Redis, In-Memory Data Grid и Gossip-протокол — не выдерживают требований по нагрузке и латентности в их инфраструктуре, и как они написали собственную систему шеринга состояния и алгоритм ограничения нагрузки на бэкенд.

📅 Когда: 11 августа (вторник) в 15:00, онлайн

👉 Регистрируйся, чтобы послушать про опыт инженеров, задать вопросы и обсудить собственные кейсы.

Перенёс пет-проект с хоумсервера в облако. Что удивило:

Года два держал несколько ботов и сервисов на старом ноуте. Работало. Но надоело: отключение света, перегрев летом, динамический IP, ngrok который иногда падал.

Решил переехать в Яндекс Облако. Думал займёт выходные. Занял три выходных.

Не потому что сложно. Потому что пришлось разобраться с вещами которые дома работали сами собой.

Secrets. Раньше у меня токены лежали в .env файле. В облаке сразу захотелось сделать через Lockbox. Потратил конечно же время, но теперь не страшно что репозит случайно станет публичным.

CI/CD. Дома деплой был «зашёл по SSH, git pull, перезапустил». В облаке настроил GitHub Actions: пуш в main - автоматически собирается образ и обновляется сервис. Первый раз в жизни сделал нормальный пайплайн. Оказалось не так страшно как казалось.

Мониторинг. Дома я узнавал что бот упал когда кто-то писал «почему не работает». Теперь есть алерты. Мелочь, но разница ощутимая.

Стоимость для пет-проекта маленькая, несколько сотен рублей в месяц на небольшой инстанс. Для хоббийных вещей вполне ок.

Какие ещё подобные решения есть?

Открыли доступ к курсам по ML-системам от основ до продакшна. И да: это бесплатно

Кто-то смотрит на ML как на способ оперативно занять рыночную нишу, не понимая, какой технический фундамент необходим для реализации идеи очередного прорывного продукта. Кто-то запускает идеальный эксперимент в ноутбуке, но выясняется, что он не работает в продакшене. Это две крайности одной и той же проблемы: мало кто понимает, как работают ML-системы от первого винтика данных до последней шестеренки мониторинга. Чтобы глобально исправить это, мы собрали весь свой опыт провайдера облачных и ИИ-решений в линейку курсов Cloud.ru ML System Design и сделали доступ к ней открытым.

Какие курсы есть в линейке? 

• «Машинное обучение в облаке»⏳15 ч — как использовать облачную инфраструктуру для разработки, обучения и эксплуатации ML-систем.

• «ML в продакшене»⏳2 ч — база, которую нужно знать, чтобы довести модель от эксперимента до стабильной работы в боевой среде с учетом инфраструктуры, данных и процессов.

• «Основы ML‑систем и обработки данных» ⏳3 ч — базовое устройство ML-систем, пайплайнов данных и ключевых компонентов end-to-end решения.

• Training Data⏳3 ч — как собирать, очищать, версионировать и поддерживать обучающие данные без деградации качества.

• Feature Engineering ⏳4 ч — как проектировать и поддерживать признаки, которые работают не только в обучении, но и в проде.

• Model Development ⏳3 ч— как разрабатывать модели с учетом требований к качеству, воспроизводимости и дальнейшему деплою.

• «Офлайн-оценка ML‑модели»⏳3 ч — как корректно валидировать модели до продакшена и не переоценивать их качество.

• Model Training⏳4 ч — как строить надежные и масштабируемые процессы обучения моделей.

• Inference⏳4 ч — как организовать инференс (онлайн и батч) с учетом latency, нагрузки и архитектурных ограничений.

• Model Monitoring⏳3 ч — как отслеживать деградацию моделей, data drift и аномалии в проде.

• MLOps⏳4 ч — как выстроить процессы, CI/CD и инфраструктуру для жизненного цикла ML-моделей.

• «Проектирование ML-системы»⏳2 ч — практический кейс для отработки навыков, который поможет персонализировать ленту новостей.

Курсы рассчитаны на менеджеров проектов и продуктов, фронтенд- и бэкенд-разработчиков, продуктовых дизайнеров и дата-сайенс специалистов.

Проходите курс и создавайте зрелые ML-продукты! 

Через час расскажем, как настроить аварийное восстановление с возможностью георезерва

Сегодня в 12:00 мск вместе Хайстекс Акура проведем практический вебинар «Как настроить аварийное восстановление с возможностью георезерва». На нем представим готовый сервис, который по клику обеспечивает запуск копий систем в облаке. Решение поможет в случае поломок, кибератак и аварий.

Вы узнаете, как организовать георезерв в облаке Selectel, пройти внедрение под ключ и подтвердить фактические RTO/RPO тестовым восстановлением. Особенно ждем системных администраторов, DevOps- и SRE-инженеров, CTO и руководителей IT-департаментов.

Программа вебинара

• Почему бэкап не равен аварийному восстановлению: где заканчивается резервное копирование и начинается восстановление сервиса 

• Почему аварийное восстановление сложно внедрять самостоятельно 

  Подробнее о докладе

• Как устроен DRaaS от Selectel на базе Хайстекс Акура 

• Георезерв Москва-Санкт-Петербург как один из сценариев аварийного восстановления ИТ-инфраструктуры 

• Как подтвердить реальную готовность аварийного восстановления: тестовое переключение и проверка фактических RTO/RPO 

• Ответы на вопросы

А если спросите нас по теме вебинара и ваш вопрос запомнится спикерам, подарим легендарного плюшевого Тирекса.

Присоединяйтесь через час →

Где бэкенд начинает тормозить: 18 открытых уроков по языкам, данным и архитектуре

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

В августе и сентябре преподаватели OTUS проведут бесплатные уроки для бэкенд‑разработчиков. В программе — Python, Go, C# и JVM, микросервисная архитектура, PostgreSQL, брокеры сообщений, наблюдаемость и контейнеризация. Выбирайте свою тему и присоединяйтесь к практическим разборам.

Архитектура и взаимодействие сервисов

• 3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться

• 4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться

• 12 августа, 20:00. «Паттерны отказоустойчивости и масштабируемости микросервисной архитектуры». Записаться

• 13 августа, 20:00. «Управление данными в MSA — дыра в бюджете или актив для ИИ-трансформации?». Записаться

• 19 августа, 20:00. «Монолит или микросервисы? Руководство для архитекторов, которые ценят свои нервы». Записаться

• 24 августа, 20:00. «Основные шаблоны проектирования в системном дизайне». Записаться

Языки, память и конкурентность

• 3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться

• 4 августа, 20:00. «Многозадачность в Python. Асинхронность, процессы, потоки». Записаться

• 5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться

• 18 августа, 20:00. «Python asyncio: gather, wait, TaskGroup на практике». Записаться

• 18 августа, 20:00. «Горутины и каналы: базовые принципы параллелизма в Go». Записаться

• 18 августа, 20:00. «Архитектурные ошибки, которые совершают даже опытные C#-разработчики». Записаться

Базы данных и работа с состоянием

• 11 августа, 20:00. «Работа с SQLAlchemy и Alembic в FastAPI». Записаться

• 19 августа, 20:00. «PostgreSQL на стероидах: большие данные, высокие нагрузки и масштабирование без боли». Записаться

• 1 сентября, 20:00. «PostgreSQL 18: асинхронный I/O и io_uring на практике». Записаться

• 16 сентября, 20:00. «Темпоральные данные в PostgreSQL 18: история и версии без триггеров». Записаться

Наблюдаемость и контейнеризация

• 4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться

• 20 августа, 20:00. «Docker для Python-разработчика». Записаться

Что почитать перед практикой

1. Создаём HTTP/2-сервер на C++ и хостим на нём свой сайт
   _{Путь от чтения RFC и реализации обработчика запросов до запуска сервера в контейнере. Внутри — защита исполняемого файла, ограничения для HTTP/2, работа с облачными площадками и поиск утечки памяти в OpenSSL.}

2. std::expected в C++23: гайд по миграции с исключений на функциональный error handling
   _{Как сделать ошибку явной частью сигнатуры функции, выстраивать цепочки операций и постепенно внедрять std::expected в существующий проект.}

3. Move-семантика в C++: пять задач, в которых легко ошибиться
   _{Разбор ловушек, которые успешно компилируются, но приводят к лишним копированиям, замедлению программы или неопределённому поведению.}

4. Миграция на Spring Boot 4 и Java 25: пошаговый план, чтобы обновиться и не уронить прод
   _{План обновления рабочего сервиса с промежуточными этапами, автоматизированными проверками, канареечным развёртыванием и заранее подготовленным сценарием отката.}

Дорогие статическо-системные-ловлевел-бояре я вас напугаю - в новых системных языках программирования есть… интерпретаторы!

А как это выглядит внутри? Чем крут Jai?

🤓 Новый мини пост в моём блоге про всё это: тык

▶️ А ещё есть в видео формате: ютуб

На этой неделе подборка задач для 1С-разработчиков и консультантов получилась довольно прикладной: заказчикам нужно ускорить складские операции, настроить фискализацию, доработать интерфейсы и перенести данные между конфигурациями.

Часть задач можно выполнить как отдельную доработку, другие предполагают регулярное сопровождение. В списке есть проекты по УНФ 3.0, УТ 11.5, РИБ, «Альфа-Авто», 1С 7.7, ЕГАИС, «Честному знаку», ТС ПИоТ и электронным перевозочным документам.

• Адаптировать расширения в 1С:УНФ 8. Управление предприятием общепита, редакция 3.0 (3.0.13.278)

• УНФ 3: ускорение оприходования товара

• Настроить автоматическую фискализацию на облачной кассе по оплатам СБП в УНФ 3.0

• Заказ по статье «Пример адаптации УТ 10.3 для работы с ТС ПиОТ (ESM): используем модули из УПП 1.3»

• УТ 11.5: в список заказов добавить две новые колонки с возможностью фильтрации

• УТ 11.5 РИБ: при подборе товара в заказе и отчете по остаткам показывать остатки центральной базы

• Настроить интерфейс для пользователя только с журналом «Электронные перевозочные документы»

• Перенос картинок в «Альфа-Авто 6»

• Загрузить приходные и расходные накладные из 1С 7.7 в 1С:Розницу

• Регулярные доработки по работе 1С с ЕГАИС, ЧЗ и ТС ПИоТ

Спрос сохраняется не только на разработку нового функционала. Заказчикам нужны специалисты, которые умеют разбираться в уже работающих системах: адаптировать расширения, исправлять узкие места, настраивать обмены и оборудование, переносить данные и поддерживать интеграции после изменений в требованиях и форматах.

На Бирже заказов Инфостарта исполнители могут откликаться на подходящие проекты и напрямую обсуждать с заказчиками объем работ, сроки и стоимость. Комиссия за работу не взимается, а безопасную сделку стороны могут использовать по своему выбору.

Как рождается цифровой продукт: практикум от преподавателей МФТИ

5 августа приглашаем на практикум, где всего за один вечер вы пройдете путь от формулировки проблемы пользователя до короткого питча продукта.

Практикум проведут преподаватели МФТИ. Каждый эксперт разберет один инструмент из своей дисциплины, покажет, как он используется в работе над продуктом, а затем участники сразу применят его к своему проекту.

В начале встречи вы получите шаблон Product One-Pager с 4 полями. Заполняя его по ходу практикума, вы соберете описание продукта на одной странице.

Что будем делать

🔹 Сформулируем проблему с помощью JTBD Разберем схему «Когда [ситуация], я хочу [мотивация], чтобы [результат]» и определим задачу, которую продукт должен решать для пользователя.

🔹 Выберем приоритетное решение по RICE Оценим 2–3 варианта по критериям Reach, Impact, Confidence и Effort. Затем выберем приоритетное решение и зафиксируем в Product One-Pager его RICE Score и краткое обоснование.

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

🔹 Подготовим питч продукта Разберем, как результаты предыдущих этапов превращаются в короткий и убедительный питч. Затем каждый участник сформулирует 3 предложения по структуре «Проблема → Решение → Почему это сработает».

Можно работать со своей идеей. Тем, кто придет без проекта, мы предложим 3–4 заготовки с проблемами из индустрии.

Результат практикума

К концу встречи вы получите готовый Product One-Pager, в котором будут собраны:

• проблема пользователя и JTBD;

• выбранное решение с RICE Score и кратким обоснованием;

• экономика продукта в 2–3 цифрах;

• короткий питч.

В финале преподаватели разберут 1–2 работы в прямом эфире: отметят сильные стороны и подскажут, что можно улучшить.

Остальные участники смогут отправить свой Product One-Pager через специальную форму и получить персональный комментарий в течение недели.

🗓 5 августа

🕖 19:00 (Мск)

📍 Онлайн

⏱ Продолжительность: 1,5–2 часа

Практикум бесплатный, необходима регистрация.

ВКонтакте: https://vk.com/app6379730_-224205661#l=32&auto=1

Telegram: https://t.me/mipt_events_bot?start=dl-17853126801d83d138f3b5

Ваш проект живёт дольше трёх месяцев? Код начинает сопротивляться изменениям: одна фича тянет правки в пяти файлах, тесты падают без внятного объяснения. Знакомо?

На бесплатном вебинаре «Антипаттерны в Python: как не превратить код в спагетти» разберём, где именно возникают эти точки напряжения, и что с ними делать.

📆 Когда: 30 июля, 16:00–17:00 (Мск)

👨‍🎓 Спикер: Читалов Дмитрий, специалист в области Python разработки

В программе:

✔️ Глобальные переменные

✔️ God Object

✔️ Spaghetti Code

✔️ Наследование ради наследования

✔️ Primitive Obsession

✔️ except: pass

✔️ Копипаста

✔️ Магические числа

✔️ Вложенные циклы O(n²)

✔️ Over-engineering

По каждому пункту — плохой код, разбор проблемы и готовый рефакторинг.

✍️ Регистрация

Программирование с явно выделенным состоянием

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

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

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

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

Backup 2.0 в «Хайстекс Акура»: дедупликация на уровне хранения и новый уровень эффективности

Когда объемы данных растут, увеличиваются и требования к корпоративным системам резервного копирования. Компаниям необходимо хранить больше резервных копий, соблюдать установленные сроки хранения и при этом контролировать затраты на инфраструктуру. Чтобы решить эту проблему, мы переработали слой хранения в платформе «Хайстекс Акура» и выпустили обновление Backup 2.0.

Что изменилось:

• Дедупликация данных на уровне хранилища для снижения объема хранения и оптимизации использования дисковых ресурсов.

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

• Шифрование данных при хранении, обеспечивающее базовую защиту резервных копий в состоянии покоя.

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

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

В ближайших версиях:

• Гибкие сценарии резервного копирования.

• Отчуждаемые резервные копии.

• Долгосрочное архивное хранение.

Если хотите примерить Backup 2.0 на свою инфраструктуру, оставьте заявку — инженеры «Хайстекс» помогут рассчитать параметры хранилища для вашей инфраструктуры.

Задача о вирусе и 1 000 серверах

Представим, что в вычислительном кластере из 1 000 серверов одна машина заражена неизвестным вирусом. Он не нагружает процессор, не генерирует подозрительный сетевой трафик и не оставляет следов в системных журналах. Только раз в сутки вирус незаметно повреждает один файл резервной копии.

Для поиска зараженного узла начинающий сисадмин Олег написал анализатор логов. Скрипт проверяет любое количество серверов одновременно, объединяя их журналы в единый пул. Результат проверки может быть только двух видов:

• Status: 500 — если среди проверяемых серверов есть зараженный;

• Status: 200 — если зараженного сервера в группе нет.

При этом анализатор нагружает сеть и системы хранения данных, поэтому его разрешено запускать не более 10 раз в сутки. Все проверки должны быть спланированы заранее и отправлены в расписание на весь день. Изменять состав очередной проверки после получения результатов предыдущей нельзя.

Задача

Помогите Олегу определить — предложите решение, которое позволит определить один зараженный сервер из 1 000 возможных за 10 запусков анализатора. Напишите код на Python, который по результатам проверок сможет определить номер зараженного узла.

Посмотреть решение

Мой опыт работы с Selectel: первые впечатления от российского облачного провайдера

Когда проект начинает расти, рано или поздно возникает вопрос инфраструктуры. На старте многие используют самые простые решения: обычный хостинг или виртуальный сервер с минимальными настройками.

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

Именно в этот момент я решил попробовать Selectel.

Почему выбрал Selectel

До этого я рассматривал разные варианты. Главными критериями были:

• стабильность работы;

• удобное управление сервером;

• понятная документация;

• возможность быстро менять конфигурацию;

• наличие необходимых инструментов.

Хотелось получить не просто сервер, а платформу, с которой можно спокойно развивать проект.

Первое знакомство

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

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

Что понравилось

За время использования больше всего обратил внимание на несколько моментов:

Скорость запуска.
Не нужно ждать длительных настроек - необходимые ресурсы можно получить достаточно быстро.

Гибкость.
Можно менять конфигурацию под текущие задачи, не покупая лишнее оборудование.

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

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

При этом идеальных сервисов не бывает.

Например, новичкам может понадобиться больше объяснений по некоторым техническим моментам. Облачная инфраструктура сама по себе сложнее обычного хостинга, поэтому порог входа выше.

Итоги

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

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

Привет!

Появилась идея: локальная база знаний, строящаяся по коду проекта на вашем компе и способная человеческим языком отвечать на вопросы по проекту, помогающая джунам быстро вкатиться в суть, а синьорам бегло проверить что они сломают очередным обновлением. Интересно ли было вам таким пользоваться? Помогло ли бы оно?

Поделитесь в комментариях)

Upd. Спасибо за комментарий, важная оговорка: проект работает локально на вашем компе, без утечек в инет)

Агент Ануфрий получил красивый вывод в терминал (отключаемый через конфиг).

Как всегда, ничего сложного, используются две библиотечки Rich + Prompt Toolkit. Вся эта красота хранится в отдельном модуле console, легко сможете разобраться, переделать, или подчерпнуть что-то для своих проектов. Кода там совсем немного.

Репозиторий: AgentAnufry

Есть идея в отдельной ветке Ануфрия запилить “кибербезопасника”, вырезав все лишнее и напихав скилов под инструменты Kali Linux. Мне кажется, тут LLM может проявить себя с хорошей стороны, если грамотно предоставить инструментарий.

Возможно что-то похожее уже кто-то реализовывал? Если да, поделитесь информацией об успехах.

P.S.: Ануфрий - это мой проект простого конструктора для создания собственных ассистентов на Python.

NYSTHI VectorMixer

Хочу просто поделиться шикарным модулем для VCV Rack - NYSTHI VectorMixer. Это графический микшер. Можно просто сводить, а можно изменять параметры звука во времени, по любой траектории.

Справа в Keyframe Animator:

• Можно выбрать одну точку и затем нажать Snap KF!

• Можно сразу нарисовать весь паттерн вручную, нажав сначала AUTOREC KFs.

• Для паттерна также можно использовать LFO (X Position, Y position,… ) и т. д.

• Для воспроизведения нажать RUN, для зацикливания - ещё и LOOP.

• DELETE ALL KF очищает память.

• TOT TIME меняет скорость паттерна.

И вот пример моего патча для перкуссии с этим модулем: