@hikkidg

Микросервисы - про границы, а не про масштабирование

2026-03-11T23:47:27.179Z

Несколько лет назад меня позвали в стартап переписывать Django-монолит на микросервисы.

Монолит при этом не работал в продакшене. Это даже нельзя было назвать MVP — реализовано было совсем немного, часть сценариев не закрыта, тестов почти не было.

Поэтому решение “срочно перейти на микросервисы” выглядело… неожиданным.

Просто в какой-то момент техлид решил (а менеджмент поддержал), что нам нужно сразу строить правильную архитектуру — чтобы потом не переделывать (спойлер: 3 раза “не переделывали”).

Он ушел делать отдельный сервис с ключевой бизнес-логикой. Я же начал переписывать монолит:

перевел его на FastAPI
сделал из него BFF
начал покрывать тестами
и параллельно начал еще выделять из него отдельный сервис.

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

Рис. 1. С чего мы начинали

Что получилось через несколько месяцев?

У нас стало 4 сервиса.

Формально — красиво:

разные репозитории
разные пайплайны
отдельные деплои.

Это же главные критерии микросервисной архитектуре!

По факту — между ними постоянно асинхронно и синхронно летали одни и те же сущности: User, Profile, Wallet, Order, Subscription и еще пара вспомогательных моделей.

Сервис A знал детали статусов из сервиса B.

Сервис B частично модифицировал данные сервиса C и посылал их обратно.

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

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

Немного HTTP-запросов туда-сюда для синхронизации. Пара раздутых моделей в событиях брокера. Ничего страшного.

Но через полгода любое изменение стало занимать 2-3 раза больше времени, чем должно было.

Мы уже не могли точно предсказать, где всплывет побочный эффект, какой контракт придется менять, и кто вообще “владеет” конкретной бизнес-логикой.

В какой-то момент надо пойти потрогать траву, вернуться свежим взглядом к нашим сервисам и признать: “Мы построили распределенный монолит”.

На самом деле этот ужас выглядит еще хуже, тут только часть связей

Что такое распределенный монолит в реальности?

Буквально то, что у нас получилось:

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

Сетевая сложность появляется. Архитектурная изоляция отсутствует.

Нам удалось сесть на худшие стулья из двух миров:

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

Как это выглядит концептуально

Как мы из этого выбирались?

Начался долгий и неприятный процесс рефакторинга.

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

Мы вырезали куски логики в отдельные сервисы (в какой-то момент у нас было 7 сервисов, потом мы сократили их до 5 обобщая логику), запретили менять “чужие” данные напрямую, пересмотрели границы доменов, убрали пересечения по сущностям.

По-настоящему “чистыми” микросервисами у нас сейчас можно назвать только 2 из 5. Они прошли несколько архитектурных итераций. Сначала были написаны на Python. Когда мы убедились, что правильно все выделили, доменная модель не меняется — переписали их на Go.

Сейчас это:

~4-5k строк бизнес-кода
~5-7k с тестами
80% покрытие,
метрики Prometheus,
четкая зона ответственности.

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

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

Отрефакторенная часть нашей архитектуры

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

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

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

Заранее подстелить себе солому с помощью микросервисов не получится. Подумайте лучше в сторону модульного монолита.

🧮 Финансовые расчёты в Python и Go: как не потерять деньги из-за одного нуля или кавычек

2026-02-28T15:57:10.032Z

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

🐍 Python: лучший вариант работать через встроенный `decimal`

Если вам нужны расчеты до копеек (2-х знаков после запятой), то самый простой вариант использовать int. Это наиболее эффективно с точки зрения производительности, точности и хранения в БД.

Если нам нужна большая точность, то определенно наш выбор - decimal.Decimal.

На тему "почему float это плохо для точных расчетов?" написано очень много материалов. Достаточно вспомнить, что в Python:

0.1 + 0.1 + 0.1 == 0.3  # False

и больше про float не вспоминать.

Инициализация `Decimal`

Главное правило - создавать Decimal через строку (Decimal('0.1')) или int (Decimal(1)), а не через число с плавающей точкой (Decimal(0.1)). Этот способ убивает всю магию точности еще до создания объекта.

from decimal import Decimal
price = Decimal('19.99')   # ✅ правильно
tax_rate = Decimal('0.08') # ✅ правильно
total = price * (1 + tax_rate)
print(total)  # 21.5892

price = Decimal(19.99)   # ❌ неправильно
tax_rate = Decimal(0.08) # ❌ неравильно
total = price * (1 + tax_rate)
print(total)  # 21.58919999999999834504049723

Управление округлением: метод `quantize()`

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

from decimal import Decimal, ROUND_HALF_UP
value = Decimal('10.125')
value.quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)  # 10.13

Контекст выполнения

Если нужно управления точностью расчетов во всем приложении, используйте getcontext().prec глобально при старте приложения.

from decimal import Decimal, getcontext
getcontext().prec = 20
print(getcontext().prec) # 20

Если тебе нужно временно повысить точность для сложного расчета, используйте менеджер контекста with localcontext(). Это безопасно изолирует изменения от остального приложения.

from decimal import Decimal, localcontext

with localcontext() as ctx:
	ctx.prec = 27
	a = Decimal('123.45')
	b = Decimal('6.789')
	result = a * b

Сравнение значений

Decimal умный и сравнение с другими типами поддерживает, но такие операции могут дать непредсказуемый результат, поэтому всегда используем с Decimal другие Decimal.

Decimal("10.0") == 10.0  # True
Decimal("10.01") == 10.01  # False
Decimal("10.01") == Decimal(10.01) # False, потому что см. про инициализацию

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

ZERO = Decimal('0')
ONE = Decimal('1')

🐹 Go: точность под высокими нагрузками

В Go нет встроенного decimal. Стандартный float64 такой же неточный, как в Python. Аналогично если есть возможность использовать integer scaling, то это лучший вариант. В противном случае выбираем стороннюю библиотеку. И тут выбор встает между скоростью и удобством.

shopspring/decimal

Самая популярная библиотека - shopspring/decimal. Она простая и удобная, но под капотом использует math/big, что приводит к аллокациям в куче и доп расходам на GC, что может быть критично для high-load.

govalues/decimal

Недавно наткнулся на govalues/decimal. Она создана специально для транзакционных финансовых систем. Фишки:

Иммутабельность - безопасна для конкурентного доступа
Нулевые аллокации - все операции без выделения памяти в куче
Без паник - все ошибки возвращаются явно.
Банковское округление
Поддержка до 19 десятичных знаков - хватит для большинства валют (и крипты)

Пример:

package main

import (
    "fmt"
    "github.com/govalues/decimal"
)

func main() {
    // Инициализация из строк — тоже безопасно
    price, _ := decimal.Parse("19.99")
    taxRate, _ := decimal.Parse("0.08")
    
    // Вычисления
    tr, _ := taxRate.Add(decimal.One)
    total, _ := price.Mul(tr)
    fmt.Println(total.Round(2)) // "21.59"
}

По бенчмаркам govalues быстрее shopspring и не создает мусора. Если в вашем сервисе много операций по расчетам - присмотритесь.

💡 Выводы

Используйте специализированные типы в любом языке
В Python - Decimal со строковой инициализацией, явным округлением и типобезопасными константами
В Go - выбирайте решение под нагрузку:

int64 если позволяет задача для максимальной скорости
shopspring/decimal если нужное простое и массовое решение
govalues/decimal для производительности

Как я отлавливал утечку памяти в высоконагруженном Go-сервисе

2026-01-25T23:13:48.510Z

Как возникла проблема?

Мы в компании постепенно переходим на Go, и одна из первых задач — переписать самые узки места, узлы, где качество решения влияет на всю систему целиком.

Недавно я взялся за Gateway-сервис, который стоит на входе: принимает запросы, подписывает его секретами, шлет дальше и возвращает ответ. Проще говоря, это прокси-слой между остальными сервисами и внешними API.

Раньше он у нас был на Python, но был заметно тяжел — потреблял сотни мегабайт памяти, медленно отрабатывал пиковые нагрузки и работал только на подпись запроса и не отправлял сам запрос, т. к. мы боялись, что если он полностью будет этим заниматься, то просто не справится (там надо было про горизонтальное масштабирование через процессы или поды, т. к. одного не хватало бы и т. д.). Поскольку скоро дело идет в продакшен, я переписал его на Golang с фреймворком chi, сделал базовое кэширование и минимизировал бизнес-логику. Это также был хороший выбор для перевода на Go, т. к. у него был четко определен круг задач вокруг одной бизнес сущности и он целиком полностью отвечал только за нее — буквально одна таблица в БД, один репозиторий, один сервис.

Сначала это казалось победой: после запуска сервис едва потреблял 20-30 МБ RAM, что резко отличалось от прежних 200-300 МБ. Но к вечеру я заметил тревожный рост — через несколько часов работы сервис уже жрал почти 1 ГБ памяти.

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

Профилирование с помощью pprof

Go уже из коробки включает мощный профайлер pprof, который легко активируется и даёт очень подробную картину распределения памяти и поведения горутин.

Добавить его в сервис можно буквально за пару строк:

import _ "net/http/pprof"

func main(){
    go func() {
        http.ListenAndServe("0.0.0.0:6060", nil)
    }()
}

После этого в работающем сервисе становятся доступны эндпоинты:

/debug/pprof/heap — снимок текущего распределения памяти;
/debug/pprof/allocs — распределение аллокаций;
/debug/pprof/goroutine — текущие горутины;
/debug/pprof/profile — CPU-профиль

Эти данные можно анализировать как локально, так и в браузере.

Команды, которые реально помогают

Анализ heap-снимка:

go tool pprof http://localhost:6060/debug/pprof/heap

В интерактивной консоли pprof команды вроде top, top -cum, list <func> позволяют быстро найти функции, которые потребляют наибольшую часть памяти.

Для аллокаций используем:

go tool pprof http://localhost:6060/debug/pprof/allocs

Это полезно, когда память вроде освобождается, но общее выделение растет со временем.

Чтобы посмотреть, сколько горутин живёт и где они зависают:

go tool pprof http://localhost:6060/debug/pprof/goroutine

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

go tool pprof -http=:8081 http://localhost:6060/debug/pprof/heap

Как смотреть профили из Kubernetes?

Очень часть проблема проявляется только под нагрузкой в staging или даже в prod. Поскольку pprof слушает порт, его легко использовать внутри Kubernetes через перенаправление портов:

kubectl port-forward pod/your-pod 6060:6060

Локально становятся доступны профили по localhost:6060, и дальше можно использовать те же команды go tool pprof или открыть интерфейс в браузере. Это работает без изменения конфигурации ingress, без проброса портов наружу, просто через доступ к кластеру.

Что показал анализ?

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

Как только я зафиксировал и вернул стабильную версию библиотеки (спасибо ишью на Github, где указали на какой версии все работает правильно) — рост памяти прекратился, и сервис занял устойчивое плато, колеблясь лишь на уровне обычного поведения GC.

Какие ошибки я нашёл в собственном коде?

Пока искал корень проблемы, нашёл и собственные промахи:

в некоторых местах response.Body закрывался только при успешном результате — при ошибках тело оставалось висеть;
я создавал HTTP клиент на каждый вызов функции, что просто заставляло выполнять лишнюю работу сервис и выделять на каждый запрос доп память.

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

Наблюдаемость — не "фича", а необходимость

Здесь важно подчеркнуть: инструменты вроде pprof помогают только в моменте, тогда как системный мониторинг показывает динамику.

Я интегрировал в сервис Prometheus-метрики через мидлварь: статистика по вызовам роутов, текущее потребление памяти, скорость аллокаций, поведение GC и количество горутин. Эти метрики легко визуализируются в Grafana, и на графиках чётко видно, когда начинается рост, когда он останавливается, и как ведёт себя сервис с течением времени.

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

Если вы не можете сделать даже этого, то хотя бы периодически снимайте метрики через curl или kubectl top pod <your-pod>. Вы уже сможете видеть подозрительное изменение ресурсов.

Наглядно видно, что левая часть уходит в космос, а правая после второго обновления на устойчивом плато

Финальные мысли

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

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

🎯 Как работать с несколькими SSH-ключами в Git и GitHub (личный + рабочий аккаунт)

2025-12-02T07:57:27.410Z

Если вы используете GitHub и у вас есть личный и рабочий аккаунты, то быстро появляется боль:
Git не понимает, какой SSH-ключ подставить, и начинает всё ломаться — от доступа к репо до установки зависимостей.

Разбираем, как это решить красиво и автоматизировано.

🔐 Проблема

Git работает по SSH через ключи.
Обычно всё просто:

генерируете приватный + публичный ключ,
добавляете публичный в GitHub,
клонируете по git@github.com:user/repo.git.

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

SSH ключи есть, но Git напрямую ими не управляет.

✅ Шаг 1. Создаём alias для SSH

В файле ~/.ssh/config настраиваем «виртуальный сервер» — алиас, который будет использовать нужный ключ:

Host github-company
  HostName github.com
  User git
  IdentityFile ~/.ssh/your-company-private-key
  IdentitiesOnly yes

Проверяем:

ssh -T git@github-company
# Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Теперь можно клонировать репозитории через:

git clone git@github-company:company/repo.git

Но… так делать неудобно.

❗ Почему

Потому что внутри проекта могут быть другие SSH-ссылки, например в Python-зависимостях, которые тоже ведут на git@github.com:company/....
И их приходится вручную менять на alias — иначе не скачивается.

Это ломает lock-файлы, требует ручных правок и очень легко случайно закоммитить.

✅ Шаг 2. Пусть Git сам подменяет адреса

Git умеет включать дополнительные конфиги в зависимости от пути к репозиторию.

Открываем (или создаём) ~/.gitconfig:

[user]
  name = Your Name
  email = your.email@example.com

[includeIf "gitdir:~/workspace/work/"]
  path = .gitconfig-work

Теперь создаём файл .gitconfig-work в домашней директории:

[user]
  name = Your Name
  email = your.email@work.com

[url "ssh://git@github.com-company/company/"]
  insteadOf = ssh://git@github.com/company/

[url "git@github.com-company:company/"]
  insteadOf = git@github.com:company/

🧠 Что теперь происходит

Если вы работаете внутри ~/workspace/work/, Git:

видит SSH-ссылку вида git@github.com:company/...
автоматически заменяет её на git@github-company:company/...
SSH автоматически использует правильный ключ
вам вообще ничего менять не нужно

🎉 Итог

Вы можете одновременно работать:

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

Вся магия — это связка:

~/.ssh/config
~/.gitconfig
includeIf + insteadOf

Сервер на коленке для простых задач: Raspberry Pi + Portainer

2025-03-28T00:14:44.771Z

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

Для таких случаев я приноровился использовать Raspberry Pi c веб-приложеним Portainer для более удобного управления своими приложениями. С помощью этих двух инструментов можно держать дома полтора десятка простеньких веб-сервисов, баз данных, Телеграм ботов для личных нужд.

Raspberry Pi
Docker + Portainer
Разработка и развертывание приложений
Ресурсы

Raspberry Pi

Это, наверное, один из самых известных одноплатных компьютеров, которые можно питать от USB C разъема и использовать без активного охлаждения для не особо требовательных задач.

На него есть огромное множество дистрибутивов Linux, с графической оболочкой и без. Есть даже версии Android и Windows 10/11 для тех, кому хочется особо пострадать.

Последнюю (на момент написания статьи) версию "Малинки" я в руках не держал. У меня Raspberry Pi 4B 8 Gb. Её хватает для большинства задач в качестве сервера. Если хочется графическую оболочку, то лучше посмотреть в сторону 5-й версии, где уже и загрузку с SSD можно сделать и подключить доп. перефирию через PCI-E.

Я использую ее с SD картой на 128 Гб, на которой установлена Ubuntu Server 24.04 LTS.

Самый простой вариант установки - Rpi Imager. Утилита есть на все возможные системы в нашей галактике и прямо в ней можно найти Ubuntu Server нужной версии, чтобы не скачивать ее отдельно.

Замечу, что в ней сразу можно указать имя пользователя и пароль, а также запуск SSH сервера (который нам позже пригодится) и подключение к Wi-Fi. Но будьте готовы, что SSH и Wi-Fi не заведется сразу после установки. Не имею представления с чем это связано, но после установки до настройку лучше проводить с помощью внешнего монитора и проводной клавиатуры. Wi-Fi настраивал по инструкции отсюда.

После подключения к Wi-Fi мы можем подключиться к "Малинке" по ssh. IP адрес можно найти в админке роутера или через ip a

ssh user@your_ip_here

Docker + Portainer

Docker

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

Чтобы установить Docker на RPi с Ubuntu, можно воспользоваться стандартным скриптом:

curl https://get.docker.com | sudo sh
docker info

Portainer

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

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

Интерфейс

Для установки Portainer на официальном сайте предлагается использовать docker образ, чтобы развернуть его всего за пару отдельных команд: https://docs.portainer.io/start/install-ce/server/docker/linux

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

services: 
  portainer: 
    image: portainer/portainer-ce:lts 
    ports: 
      - 8000:8000 
      - 9443:9443 
    restart: always 
    volumes: 
      - portainer_data:/data 
      - /var/run/docker.sock:/var/run/docker.sock 
  
volumes: 
  portainer_data:

docker compose up -d

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

Разработка и развертывание приложений

Развертывание готовых контейнеров

Для работы с контейнерами в Portainer у нас есть дво пункта меню - отдельные контейнеры и стеки.

Основные

Соответственно, для простых одиночных вещей удобнее настраивать отдельные контейнеры. Если у нас есть docker-compose.yaml на 10 контейнеров с healthcheck и очередностью запуска, то наш выбор - стек. Стеки соответственно поднимают контейнеры.

Другие вкладки отвечают за работу с образами, сетями, хранилищами и хостами доступными Docker.

По умолчанию образы берутся из глобального Docker Hub, но можно указать и собственные реестры (например, если разворачиваете для в рабочей сети).

Разработка

Т. к. Raspberry Pi построена на базе ARM процессора, то компилируемые программы не совместимы с обычными компьютерами. Например, если вы пишите серверное приложение на C++ или Go, то учтите, что его нужно собирать специально под ARM64 платформу.

Скриптовые языки типа Python чувствуют себя в этом плане гораздо лучше, т. к. у них обычно используются мультиплатформенные образы, а т. к. скрипты не надо компилировать, они переносятся as-is.

Для сборки под несколько платформ на обычном ПК нам понадобится buildx:

docker buildx create --name multiarch --driver docker-container --use
docker buildx build --platform=linux/amd64,linux/arm6
4 . -t some_tag --push

Так мы можем собрать приложение под две платформы и сразу запушить в публичный Docker Hub.

Теперь мы можем развернуть наше приложение на RPi.

Итого наш путь:

Написать сервис
Собрать под RPi + залить в Docker Hub
Развернуть на RPi через docker-compose.yaml

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

P. S.

Есть у Portainer еще одна полезная фича, которой я активно пользуюсь - подключение нескольких железок к одной панели через агентов.

Суть:

У вас есть несколько железок, которые можно приспособить под разные нужды.
На все ставим Linux и Docker
На самую слабую ставим основной Portainer (из шагов выше)
На остальные ставим агенты

Таким образом получаем дополнительные среды (Environments), которыми можем управлять из одной админ панели.

У меня так подключен Orange Pi Zero 3, на котором отдельно запущены Телеграм боты с менее требовательными ресурсами.

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

Ресурсы

Стратегии с автоследованием

2025-03-13T06:34:41.271Z

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

План

Что такое автоследование?

Как это работает?
Подводные камни

Мой опыт

Стратегия №1 (вроде неплохо)
Стратегия №2 (чет не пошло)
Мой собственный портфель

Выводы

Что такое автоследование?

Это автоматизированная торговля, во время которой на вашем счете в реальном времени совершаются сделки, повторяющие сделки другого трейдера или управляющего.

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

Как это работает?

Обычно все платформы предоставляют примерно одинаковый процесс работы с автоследованием:

Выбираем стратегию. Внимательно смотрим на все доступные стратегии, изучаем статистику доходности, просадок, уровень риска, саму идею стратегии.
Подключаем капитал. Необходимо выделить некоторое количество средств на счете или даже создать отдельный счет к стратегии. Средства все еще ваши, но вы таким образом определяете их будущее предназначение и не сможете потратить на что-то еще.
Копирование сделок. Все сделки выполняются на счете как в указанной стратегии в соответствии с долей выделенного капитала: условно на счету трейдера, за которым вы следите, было 100 000 р, вы выделили на стратегию 10 000 руб - в 10 раз меньше, соответственно все сделки будут выполняться пропорционально этому соотношению капитала.
Контроль и отключение. Обычно можно пополнять и снимать деньги, управляя выделенным капиталом, или вообще отключить стратегию, когда захочется.

Подводные камни

⚠️ нет гарантий прибыли: идея этого процесса в том, что трейдер не просто советует, что купить, а сам является участником процесса, рискуя своим капиталом. Это должно заставлять людей ответственно подходить к таким решениям, но все могут ошибаться.
⚠️ комиссии: если мы выбрали удачную стратегию и она приносит прибыль, то мы платим налог на прибыль + комиссию платформе/трейдеру за автоследование.

Мой опыт автоследования

Самый главный вопрос, можно ли на этом реально заработать? Я вложился в две стратегии ради эксперимента чуть больше месяца назад. Выбирал не самые рисковые (где 100500% прибыли, а за все время сделали 70-90%).

При чем в приложении брокера отображаются 2 числа: реальный процент за все время (вот это маленькое зеленое число) и прогноз, который ставит сам автор стратегии (естественно пальцем в небо). У топовых стратегий процент за все время обычно опережает прогноз, но учтите что это именно ВСЁ ВРЕМЯ существования стратегии, в нее можно провалиться и посмотреть график прибыли.

Стратегия №1

Решил выбрать относительно консервативную историю без фьючерсов и вот этого всего. Заходил изначально на минималке - 12 000 рублей. Затем когда понял, что история перспективная докинул еще + поставил автопополнение.

Но есть интересный момент с доходами. На скрине выше брокер показывает 1 480 р 19 коп, но если открыть в приложении банка стратегию, то будет следующая картина.

Внезапно на ~5 000 руб. больше. Получается что доходность портфеля в 4.5 раза выше и это уже прям отличный результат. Всего за месяц 22%.

Чему верить?

Если выкачать статистику по всем операциям портфеля, то получается, что я счет пополнил всего на 25 200 руб, что сильно меньше 31 929 руб, значит второе число верное. Но это все еще не чистая прибыль, т. к. при продаже портфеля и закрытии счет автоследования нужно будет еще заплатить налог (комиссии за автоследование списываются регулярно). Даже с учетом налога в 13% получаем примерно 19% прибыли за месяц.

Стратегия №2

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

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

Как мы уже знаем, что цифрам на сайте или в ленте счетов верить нельзя, проваливаемся в саму стратегию и видим реальный результат:

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

Мой портфель за тоже время

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

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

Выводы

Если суммировать обе стратегии как один эксперимент по автоследованию, то картина такая: общая сумма капитала 46 943 руб, из них 5 900 руб чистой прибыли, доходность ~12.5% за 1.5 месяца. Считаю результат неплохим, но это везение. Поэтому помните, что:

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

Пирамида тестирования в Python

2025-03-13T05:19:00.334Z

После опубликации предыдущей статьи получил комментарий: "Я удивлён, что есть тесты, на которые нужно разворачивать докер для имитации сторонних сервисов". И тут я задумался, что возможно стоит немножко рассказать про тесты в целом в экосистеме Python.

План

В начале была... пирамида? Нет!
Пирамида!

Unit тестирование
Интеграционное тестирование
End-2-End
Смешение уровней

Покрытие тестами
Тестирование и формальная верификация программ
Полезные материалы

Так сказать основа!

В начале была... пирамида? Нет!

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

Начнем с определения:

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

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

В этом материале рассмотрим именно аспекты касающиеся автоматизированного тестирования.

Пирамида!

Как масоны управляют управляют тестированием на самом деле

Всё почалось с книги "Scrum: гибкая разработка ПО" Майка Кона, где были представлены 3 уровня тестов. Но мы будем разбирать конкретную пирамиду в контексте Python разработки.

В общем про тесты и про пирамиду можно сказать следующее:

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

сложней в реализации, и соответственно, дороже в реализации;
важнее для бизнеса и критичней для пользователей;
замедляют скорость прохождения тестовых наборов

Unit тестирование

(их еще называют модульными тестами, компонентными тестами)

На этом уровне мы тестируем минимальные части кода – функции, методы, классы. Обычно ограничиваются публичными функциями и классами. В Python начинающие разработчики пренебрегают этим и лезут в функции, которые начинаются с нижнего подчеркивания. Если вам приходится этим заниматься, подумайте (!) возможно где-то процесс пошел не туда.

Также обычно в тестах не происходит тестирование "чужого" кода – стандартной библиотеки и модулей Python или сторонних зависимостей.

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

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

В 99% разработкой модульных тестов занимается сам разработчик.

Есть довольно известная в среде программистов концепция TDD (Test Driven Development). Ее можно описать фразой: "Сначала – тесты, потом – код". И ее очень удобно применять именно на уровне Unit тестирования, когда вы можете представить себе ожидаемую работу небольшого компонента программы и начать с описания ожидаемого поведения.

А что там в Python?

У нас есть стандартная библиотека unittest, которая предоставляет базовые классы для написания модульных тестов. Также есть модуль mock в ней, который позволяет делать моки (заглушки) объектов для проверок вызовов отдельных методов, или наоборот позволяет иммитировать работу объектов, которые мы не хотим явно вызывать.

Тесты в unittest представляют собой наследников класса TestCase внутри, которых содержатся отдельные методы, начинающиеся со слова test - собственно сами тесты. Еще есть методы setUp() и tearDown(), которые позволяют подготовить тестовые данные и выполнить какую-то очистку после выполнения тестов.

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

Для примера напишем юнит тесты для кусочка игры "Виселица:

Почему это юнит тесты?

Тестируется поведение одного отдельно взятого класса
В этих тестах не используются какие-либо сторонние сервисы, службы, не происходят какие-то side effects (например, работа с файловой системой)

Интеграционное тестирование

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

Сюда относят:

работу с базой данных
работу с файловой системой
работу с внешними службами и сервисами
API тесты

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

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

В интеграционном тестировании выделяют 3 подхода:

Снизу вверх: все мелкие части модуля собираются в один модуль (функцию или метод) и тестируются. Далее собираются следующие мелкие модули в один большой и тестируются с предыдущим и т. д.
Сверху вниз: сначала проверяем работу крупных модулей, спускаясь ниже добавляем модули уровнем ниже. На этапе проверки верхних уровней могут использоваться моки для сиумляции данных от уровней ниже.
Большой взрыв: собираем все реализованные модули всех уровней в систему и тестируем. Если что-то не работает или не доработали, то фиксим и дорабатываем

А что в Python?

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

В каждом популярном фреймворке есть тестовый клиент для тестирования запросов к API, а для работы с файловой системой вам придет на помощь тот же pytest.

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

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

И вот на интеграционном уровне уже можно почувствовать существенные плюсы от использования pytest для тестирования, а именно систему фикстур. По сути фикстуры выполняют роль dependency injections в тестировании, когда необходимо получать подготовленный объект в нужном месте с минимальными усилиями. Это существенно упрощает код самих тестов и делает их более читабельными. Также это позволяет сэкономить ресурсы, т. к. можно управлять жизненным циклом этих объектов и создавать их не на каждый тест, а на модуль, сессию или пакет.

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

Для решения проблемы тестирования внешних API есть два подхода:

Подменять наш клиент, который должен работать с внешним миром на фейковый (например, по флагу test или debug), который соответствует по интерфейсам, но реальных запросов не делает
Подменять сервер, на который отправляются запросы (например, с помощью указания корневого URL сервиса и замены его на тестовый самописный сервер, API которого соответствует реальному, но с фейковыми данными)

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

Для второго пути могу посоветовать собственную небольшую библиотеку для построения клиентов к внешним API и их тестирования.

End-2-End

(E2E, сквозное, приемочное)

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

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

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

А что в Python?

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

E2E тесты могут состоять из простых действий пользователей в системе, которые иммитируют выполнение конкретной User Story с помощь API запросов или если нас интересует UI подсистема, иммитация работы пользователя в браузере с помощью какого-нибудь Selenium. Но нужно помнить, что такие API тесты будут зависеть от конкретных путей роутов и формата передаваемых данных, которые довольно быстро можно поправить или вынести в библиотеку, чтобы сделать их менее хрупкими, то с UI тестами это невозможно и тут уже нужна устоявшаяся кодовая база и дизайн.

Сами тесты удобно писать и запускать с помощью pytest.

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

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

Хороших примеров в OpenSource нет и сам пока не написал, так что приложить пока нечего.

Смешение уровней

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

Не стоит ставить терминологию в главу угла и спорить с коллегами, что и как называть. Лучше всего руководствоваться здравым смыслом и смотреть в суть происходящего в тестах.

Покрытие тестами

Когда pipeline не пропускает PR из-за низкого процента покрытия

Количество тестов само по себе мало говорит о том, насколько хорошо тесты написаны.

В качестве базовой метрики для оценки количества тестов на "достаточность" принято брать процент покрытия тестами.

Буквально эта метрика говорит о том, какая часть исходного кода охвачена тестами.

Этот показатель можно посчитать как:

Покрытие функций: сколько объявленных функций было вызвано
Покрытие веток: сколько выполнено веток структур if
Покрытие условий: какая доля логических подвыражений была протестирована на истину/ложь
Покрытие строк: сколько строк исходного код протестировано

О чем надо помнить?

Главный инструмент для расчета покрытия в Python – Coverage.py
Выберите к какому проценту стремиться и по какому критерию
Хотите поднять покрытие – пишите unit тесты
Используйте покрытие в pipeline Pull Request, чтобы можно было видеть как меняется процент покрытия и какие участки кода забыли покрыть
Высокое покрытие тестами не говорит о том, что в приложении не нарушена целостность системы и приложение может запуститься

Тестирование и формальная верификация программ

Как ни странно даже 100% покрытие тестами не гарантирует нам отсутствие в программе ошибок. Оно только гарантирует ожидаемое поведение при указанных в тестах параметрах.

Если мы хотим убедиться, что код корректен в общем случае (условно при любых ожидаемых вводных), используется формальная верификация программ.

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

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

Полезные материалы

AsyncIO и синхронные вызовы

2025-03-13T05:19:45.052Z

С чего все началось

Недавно на работе столкнулся с интересным багом связанным с асинхронностью во время написания тестов. Мне нужно было залогиниться в сервисе несколько раз с неправильными данными, чтобы получить блокировку аккаунта (собственно механизм блокировки я и тестировал).

Немного про технологический стек: Python 3.11, FastAPI, Redis, PostgreSQL. Тесты — синхронные на PyTest. Есть своя обвязка для запуска интеграционных тестов с запуском необходимого окружения с помощью Docker и самого тестируемого сервиса в контейнере.

Довольно типичная задача. Пишу тест — делаем несколько POST запросов по роуту входа с правильным юзернеймом и неправильным паролем и потом пробуем сделать запрос с полностью корректными данными.

План теста

Внезапная проблема

При запуске тестов в первый раз все нормально - тест отработал за 20 сек, вроде кажется долго, но там специфическая система подготовки окружения, спишем на нее эту задержку. Готовлю Pull Request, прогоняю все тесты вместе с моим новым и получаю ошибку TimeoutError — запрос к роуту логина завершился неудачно, т. к. сервер не ответил в течении 60 сек на запрос, то клиент автоматически его завершил по таймауту.

Как тест работал реально

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

Можно было забить и списать это все на плохой проект, среду, организацию тестов и т д, но что-то здесь было не так...

Локализация проблемы

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

Внезапно сервис на самом деле нормально отвечал и воспринимал запрос как вполне обычный. Да, он отвечал на него 67 сек., но статус был правильный — 401 Unauthorized (не смог войти). Почему он не мог мне ответить в тесте быстро?

Первая мысль, т. к. речь шла о веб-сервисе — где-то происходит блокировка сервиса, а потом его отпускает. Смотрим в код, а код роута логина полностью синхронный, там что-то типа:

@router.get("/login")
def login(...):
    ...
    settings = settings_provider.get_settings()
    if settings.count_failed_login_attempts:
        account_locker = account_locker_factory.get_or_create(...)
        # processing
    ...

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

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

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

Цель обнаружена

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

Через пару десятков запусков было понятно, что время задержки ответа строго варьируется от 0 до 60 сек. Довольно не случайное число, скорее всего где-то стоит таймаут выполнения задачи, которая должна выполняться не более 60 сек и потом она или выполняется успешно, или ее завершают извне. Внезапно помог обычный поиск числа 60 по проекту.

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

Полная схема запросов

Но это совсем другой роут, другая функция-обработчик отвечающя за проверку доступов сервиса /healthchecks. Эти запросы напрямую никак не участвовали в логине.

Так, код синхронный обнаружен, но ведь я уже выше писал: "FastAPI его оборачивает в асинхронную корутину и выполняет в отдельном потоке". В чем же может быть проблема? Обертка написана криво? Может быть неправильно определено место?

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

@route.get("/healthcheck")
async def healthcheck_services(...):
    ...
    PortChecker.check(...) # 60 сек пытаемся получить ответ и на это время блокируем весь сервер
    ...

Это один из немногих случаев, когда решение бага состоит не в написании нового кода, а только в удалении старого. Если FastAPI роут написан как синхронная функция, то он его вызывает в потоке и во время этого вызова не блокируется работа всего сервера. (ссылка на исходники)

async def run_endpoint_function(
   *, dependant: Dependant, values: Dict[str, Any], is_coroutine: bool
) -> Any:
    ...
    if is_coroutine:
       return await dependant.call(**values)
    else:
       return await run_in_threadpool(dependant.call, **values)

После исправления

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

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

Полезные материалы

Программистские собеседования в 2024

2025-03-13T05:19:58.786Z

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

Я собрал некоторые из них для разбора.

1. Map

Условие

Необходимо написать класс, который хранит в себе по уникальному ключу некоторый набор значений и наиболее эффективно реализует четыре операции: set, get, remove и is_all_values_unique.

Решение

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

Т. к. у нас есть операции set и get и уникальный набор ключей, то в качестве контейнера для данных лучше всего выбрать класс dict. У него операции вставки и поиска по ключу происходят за O(1).

Таким образом, мы можем сделать первый набросок:

Для реализации последнего условия можно пойти двумя путями:

Реализовать метод "в лоб" просто добавлением всех значий словаря в set и потом проверить равна ли длина множества значений количеству ключей словаря. Сложность по времени O(n) и по памяти тоже O(n).
Добавить в класс Map еще один словарь, в котором будут инвертированы ключи и счетчик значений, чтобы можно было быстро отвечать на вопрос: "Все ли добавленные значения уникальны?". Дополнительно необходимо добавить в методы обновления и удаления дополнинельные операции с новым словарем. В таком случае мы получим сложность по времени O(1) и по памяти O(n)

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

2. Поиск симметрии

Эту задачу в разных формулировкх получал на 4-х собеседованиях минимум.

Условие

Дан набор точек на плоскости с координатами (x,y), необходимо найти такую точку на оси X, через которую можно провести ось симметрии параллельную оси Y.

Решение

Если ось симметрии можно провести, то она должна лежать ровно по середине между самой левой и самой правой точками. Для того чтобы их найти, можно отсортировать массив точек по X sorted(a, key=lambda point: point[0]) сложность O(n log n). Или просто в цикле найти min/max, в таком случае сложность будет O(n).

После нахождения потенциальной точки симметрии по X необходимо проверить, действительно есть ли для каждой точки в массиве своя симметричная пара. Решение в лоб - перебор массива вложенным циклом и поиск для каждой точки (x+/-symmetric_x;y). Чтобы уменьшить сложность алгоритма, можем воспользоваться множеством - поиск элемента во множестве O(1).

Решение целиком выглядит так:

3. Больше половины

Условие

Дан массив элементов. Гарантируется, что в этом массиве есть такой элемент, который встречается больше n / 2 раз. Необходимо найти этот элемент.

Решение

Здесь можно пойти двумя путями:

Отсортировать массив и выбрать центральный элемент. Сложность по времени O(n log n), потребление памяти - O(1).
Через счетчик элементов в виде словаря. Сложность по времени O(n), потребление памяти - O(n).

4. Дороги

Условие

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

>>> ([[1,2], [2,4], [1,3], [3,4], [1,4]], 4) => 3

Решение

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

Про Obsidian

2025-03-13T05:20:15.678Z

Установка

Obsidian можно найти тут https://obsidian.md/

Для Windows и MacOS можно скачать прям с официального сайта. Для Linux лучше использовать flathub.

Для iPhone и Android есть фирменные приложения.

Как пользоваться?

Создать первое хранилище в виде обычной папки и просто начать.

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

В качестве отправной точки можно начать с этих видео:

Синхронизация

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

Подписка Obsidian Sync
Сервис хостинга проектов с использованием системы контроля версий (Gitlab, Github)
Настройка синхронизации через облачные диски (Яндекс, Google и проч)

Синхронизация через Github/Gitlab

Идея данного метода очень проста - Github и Gitlab хорошо умеют работать с текстовыми файлами и предоставляют возможность бесплатного хранения папки с файлами причем с историей изменения благодаря Git. Таким образом, можно создать папку (репозиторий) в сервисе и с помощью утилиты git синхронизировать ее с локальной папкой.

Чтобы реализовать такую синхронизацию можно воспользоваться расширением https://github.com/Vinzent03/obsidian-git.

Гайд как это можно сделать https://desktopofsamuel.com/how-to-sync-obsidian-vault-for-free-using-git

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

Синхронизация через облачные диски

Наиболее простой и универсальный метод.

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

Просто создаем хранилище Obsidian внутри этой папки и всё. Это без проблем работает с ноутбуками/компьютерами, но мобильные версии таких программ обычно не дают возможность синхронизации обычной папки с файлами на диск. Но есть программа FolderSync Pro, которая позволяет настраивать синхронизации с различными облачными хранилищами локально на телефоне.

Мною было активно использована на платформе Andorid на нескольких устройствах одновременно. Как дела обстоят у iPhone, не знаю.

Как пользуюсь сам?

Т. к. на ноутбуке у меня стоит Linux, то пришлось искать облачные диски с поддержкой данной платформы. Выбор стоял между Яндексом и Mega. У обоих неплохие приложения, которые без проблем ставятся на большинство современных дистрибутивов. В силу внешнеполитической обстановки выбрал Яндекс, т. к. шанс, что от него отключат очень низкий. (Если съедает паранойя на этот счет, то лучше поднять собственный сервер и сделать синхронизацию с ним по SFTP, SMB). На телефоне и планшете под Android стоит Folder Sync Pro, скачанный c 4PDA. На ноутбуке под управлением Fedora Yandex Disk для Linux.

@hikkidg

Микросервисы - про границы, а не про масштабирование

Что получилось через несколько месяцев?

Что такое распределенный монолит в реальности?

Как мы из этого выбирались?

🧮 Финансовые расчёты в Python и Go: как не потерять деньги из-за одного нуля или кавычек

🐍 Python: лучший вариант работать через встроенный `decimal`

Инициализация Decimal

Управление округлением: метод quantize()

Контекст выполнения

Сравнение значений

🐹 Go: точность под высокими нагрузками

shopspring/decimal

govalues/decimal

💡 Выводы

Как я отлавливал утечку памяти в высоконагруженном Go-сервисе

Как возникла проблема?

Профилирование с помощью pprof

Команды, которые реально помогают

Как смотреть профили из Kubernetes?

Что показал анализ?

Какие ошибки я нашёл в собственном коде?

Наблюдаемость — не "фича", а необходимость

Финальные мысли

🎯 Как работать с несколькими SSH-ключами в Git и GitHub (личный + рабочий аккаунт)

🔐 Проблема

✅ Шаг 1. Создаём alias для SSH

❗ Почему

✅ Шаг 2. Пусть Git сам подменяет адреса

🧠 Что теперь происходит

🎉 Итог

Сервер на коленке для простых задач: Raspberry Pi + Portainer

Raspberry Pi

Docker + Portainer

Docker

Portainer

Разработка и развертывание приложений

Развертывание готовых контейнеров

Разработка

P. S.

Ресурсы

Стратегии с автоследованием

Что такое автоследование?

Как это работает?

Подводные камни

Мой опыт автоследования

Стратегия №1

Стратегия №2

Мой портфель за тоже время

Выводы

Пирамида тестирования в Python

В начале была... пирамида? Нет!

Пирамида!

Unit тестирование

Интеграционное тестирование

End-2-End

Смешение уровней

Покрытие тестами

Тестирование и формальная верификация программ

Полезные материалы

AsyncIO и синхронные вызовы

С чего все началось

Внезапная проблема

Локализация проблемы

Цель обнаружена

Полезные материалы

Программистские собеседования в 2024

1. Map

Условие

Решение

2. Поиск симметрии

Условие

Решение

3. Больше половины

Условие

Решение

4. Дороги

Условие

Решение

Про Obsidian

Инициализация `Decimal`

Управление округлением: метод `quantize()`