Блог им. elogunov

Некоторые аспекты проектирования платформ для торговых роботов

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

Введение

Предположения:
1. У вас имеются какие-то навыки программирования или же вы хотите сформулировать техническое задание для программиста;
2. У вас есть некая стратегия (принцип принятия торговых решений), которую вы хотите автоматизировать; в противном случае — рекомендую не торопиться, а взять исторические данные и отбэктестить свои идеи;
3. У вас есть хорошее понимание того, почему вас не устраивают существующие платформы (TSLab, StockSharp, MetaTrader и т.д.) и вы готовы тратить время и средства на поддержку своего решения.

Если все предположения выполнены и вы настроены решительно — эта статья для вас. Если вы ксорите DWORD'ы в уме, угораете по lock-free алгоритмам и регулярно задаете CPU affinity потокам своего кода — проходите мимо; вам, скорее всего, будет неинтересно))

Брать ли что-то за основу

Иногда люди делают так (источник): 
Некоторые аспекты проектирования платформ для торговых роботов

Если вам очень нужен какой-то пример, то можете поискать на GitHub'е — там полно поделок под разных брокеров и на разных языках программирования. В большинстве случаев вы найдете бесполезный мусор, но встречаются и интересные проекты, которые могут помочь вам передумать разрабатывать своё решение и вместо этого допилить под себя одно из найденных. Либо вы можете извлечь пользу, подсмотрев идеи или детали реализации какой-то фичи.

Тем не менее, у вас должно быть собственное понимание того, что нужно именно вам.

Определяем основные требования к платформе

0. Быстродействие.

Этой темы я особо касаться не буду, т.к. статья точно не для борцов микросекундного фронта ;)

1. Разделение стратегий и шлюзов.

Если вы куда-то торопитесь — в принципе, можно не заморачиваться над выделением промежуточного API, а напрямую использовать в стратегии типы данных и методы брокерского/биржевого API:
Некоторые аспекты проектирования платформ для торговых роботов

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

2. Количество стратегий и шлюзов.

Возможные варианты: одна стратегия — один шлюз («1 / 1»), одна стратегия — несколько шлюзов («1 / M»), несколько стратегий — один шлюз («N / 1»), несколько стратегий — несколько шлюзов («N / M»). Очевидно, вариант «1 / 1» (см. предыдущую картинку) является самым простым, но в то же время — и наиболее ограниченным. Наиболее универсальным является вариант «N / M», он же — и наиболее сложный, особенно, если множества торгуемых инструментов у стратегий пересекаются и у вас нет возможности разнести позиции по разным счетам:
Некоторые аспекты проектирования платформ для торговых роботов
В такой схеме стратегии не зависят от брокерского/биржевого API, а шлюзы в свою очередь не зависят от стратегий. Промежуточный слой может реализовывать дополнительную логику; эта тема будет затронута позже.

3. Разделение по процессам.

Каждая из вышеуказанных компонент может быть реализована в виде отдельного приложения, а компоненты между собой могут взаимодействовать через файлы, сокеты, разделяемую память и т.д. Например, шлюз можно вынести в отдельный процесс, если его надежность низкая и периодически он падает, а стратегию можно вынести в отдельный процесс и запускать на другой машине, если ей требуется производить некие тяжелые вычисления или вам страшно размещать логику своего Грааля на арендованном VPS ;)

По идее, эта задача не требует никаких изменений по сравнению со схемой выше.

4. Асинхронность и многопоточность.

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

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

В первом случае запрос стакана стратегией схематично выглядит так:
стратегия: эй, шлюз, дай стакан по Si-12.10!
шлюз: ща, погодь… вот, держи

Во втором так:
стратегия: эй, шлюз, держи коллбэк. хочу получать в него состояние стакана по Si-12.10!
шлюз: окей.

шлюз: коллбэк, держи стакан по Si-12.10.


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

5. Механизм конфигурирования отдельных сущностей.

У каждой стратегии и у каждого шлюза наверняка будут какие-то параметры: периоды средних скользящих :D / логин+пароль+адрес для подключения к брокеру / ограничения на кол-во транзакций / настройки логгирования и т.д. Также, возможно, вся платформа целиком будет обладать некоторой конфигурацией: список конфигураций стратегий и шлюзов, которые необходимо загрузить при запуске платформы / настройки риск-менеджмента. Конфигурации могут храниться в текстовых файлах (plain-text, ini, xml, yml, ...) или в базе данных; хранить конфигурации в бинарном формате неудобно, т.к. сложно быстро отредактировать. Для удобства и простоты желательно остановиться на одном способе хранения конфигураций.

Типичные операции, которые конфигурируемая сущность может захотеть сделать с конфигурацией:
— прочитать/записать целое число по заданному ключу: config.readInt(«param1», default_value), config.writeInt(«param1», value);
— прочитать/записать вещественное число по заданному ключу: config.readDouble(«param2», default_value), config.writeDouble(«param2», value);
— прочитать/записать строчку по заданному ключу: config.readString(«param3», default_value), config.writeString(«param3», value);
— перечитать конфиг из файла; сохранить текущую конфигурацию в файл.

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

Для версионирования конфигураций, хранящихсяя в файлах, потребуется придумать какой-то процесс, например: делаем копию последнего конфига, переименовываем в формате «configurable_entity.timestamp.ext» (например, «strategy_ma_cross.2020-10-08 02:25:00.xml»), меняем необходимые параметры, коммитим новый конфиг в репозиторий (svn/git/mercurial/...), заменяем ссылку на конфиг где это требуется, рекурсивно повторяя процесс сохранения конфигов при необходимости. Этот вариант неудобен, если сущность может вносить изменения в конфигурацию (например, по команде управления).

6. Логгирование.

В платформе обязательно должен быть реализован надежный механизм логгирования. Обычный набор требований к логгеру:
— работоспособность в многопоточной среде (записи, происходившие из одного потока, должны в логе следовать строго в том порядке, в котором они были инициированы; текст сообщений из разных потоков не должен перемешиваться внутри одной строки лога);
— настраиваемая детализация (на время разработки и отладки включаем подробное логгирование; в «боевом» режиме снижаем уровень детализации логов, если их объём получается слишком велик);
— быстродействие (запись в лог должна минимально тормозить работу кода, который инициировал эту запись);
— надежность;
— настраиваемый способ ротации логов (удаление слишком старых логов; создание отдельного файла для записи логов конкретного часа/дня/недели).

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

7. Механизмы контроля и управления торговой платформой во время исполнения.

Простейшим способом контроля является вывод в консоль логов с фильтрацией важных сообщений при помощи утилит командной строки tail и grep: «tail -f my-very-important.log | grep -i error» или «tail -f my-very-important.log | grep -i warn». Будучи за монитором можно поглядывать краем глаза в консоль и если там что-то зашевелится — стрелять думать над дальнейшими действиями:
Некоторые аспекты проектирования платформ для торговых роботов

Торговая платформа может быть реализована в виде приложения, не обладающего графическим интерфейсом. В таком случае для управления можно использовать следующие механизмы:
— обработка Ctrl+C и сигналов;
— удалённо подключаемый GUI, взаимодействующий с платформой через сокет или базу данных;
— торговая платформа, а, при необходимости, и каждая её компонента — шлюз / стратегия / промежуточный слой — могут обладать встроенным HTTP сервером, поднимающемся на каком-либо порту; в таком случае управление осуществлять можно будет из под любой современной ОС с веб-браузером и даже с мобильного телефона, без дополнительных усилий на разработку GUI под каждую из платформ;
— отслеживать изменения файлов конфигураций и подхватывать их либо автоматически, либо по команде, переданной каким-либо образом;
— джависты могут использовать механизмы JMX; возможно, вы найдёте аналог и для своего любимого языка программирования.

8. Динамическая загрузка / выгрузка компонентов.

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

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

Чем ещё может заниматься промежуточный слой

1. Обеспечивать упорядоченность прихода событий.

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

Некоторые аспекты проектирования платформ для торговых роботов

2. Обеспечивать возможность для бэктестинга стратегий.

Для этого на уровне платформы должна быть сущность, возвращающая время (реальное или виртуальное). Все остальные сущности должны использовать только её, когда им нужно узнать текущие дату/время.

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

В совокупности, это позволит вести разработку стратегий внутри торговой платформы, не прибегая к сторонним инструментам (Excel, R, ...).

3. Направлять запросы маркетдаты и операции с ордерами разным шлюзам.

Каждый шлюз должен предоставлять информацию о реализованном функционале. Тогда, если, например, вы хотите получать информацию через один API, а торговать через другой — вам не придётся запихивать в один шлюз два разных API; вместо этого можно будет сделать два шлюза на разных брокерских/биржевых API.

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

4. Реализовывать флуд-контроль.

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

С одной стороны, можно предусмотреть соответствующий механизм в шлюзе. С другой стороны, такой механизм можно реализовать однократно и сделать его конфигурируемым — либо из конфигурации платформы, либо добавив метод, возвращающий параметры flood control, в API шлюза.

5. Реализовывать виртуальные позиции и неттинг ордеров.

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

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

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

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

6. Осуществлять запись данных в БД.

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

7. Реализовывать дополнительные механизмы безопасности.

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

8. Присваивать внутренний идентификатор каждому ордеру, выставляемому стратегией.

Идентификаторы ордеров, возвращаемые брокерским / биржевым API, могут быть неудобны для использования внутри платформы, т.к. в одном API это строка одного формата, в другом — строка другого формата, в третьем — вообще число. Поэтому область жизни «реальных» идентификаторов имеет смысл ограничить шлюзами (ну, ещё из шлюзов можно в лог записать эти идентификаторы, на случай необходимости разбора полётов или лёгкого бодания с техподдержкой брокера).

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

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

Углубляемся в детали

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

1. Механизм оповещения об ошибках.

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

2. Запуск и остановка компонентов.

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

Например, каждая из компонент может иметь следующие состояния:
— STOPPED (остановлена);
— STOPPING (в процессе остановки);
— STARTED (запущена);
— STARTING (в процессе запуска).

После создания компонент находится в состоянии STOPPED. Запуск уже запущенного компонента или остановка уже остановленного должны вызывать ошибку. При запуске компонент переходит из состояния STOPPED в STARTING, и, по готовности, в STARTED, после чего возвращает управление. При остановке компонент переходит из состояния STARTED в STOPPING, и, по готовности, в STOPPED, после чего возвращает управление.

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

Такими сущностями являются:
— идентификатор инструмент;
— спецификация инструмента;
— позиция;
— портфель;
— стакан;
— котировка;
— сделка;
— бар;
— собственный ордер;
— отчёт об исполнении собственного ордера;
— возможно, вам нужно что-то ещё?

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

3.1. Идентификатор инструмента.

Может быть числом (для быстродействия) или строчкой (человекочитаемо) вроде STK:AAPL.NASDAQ@IB.

Шлюз должен содержать тайные знания о том, как этот идентификатор превратить в набор связанных идентификаторов, необходимых для работы с соответствующим брокерским / биржевым API (пример, ещё пример). Распространять эти знания по всей торговой платформе, на мой взгляд, плохая идея.

3.2. Спецификация инструмента.

Может включать:
— тип инструмента (акция, валютная пара, фьючерс, опцион и т.д.);
— тикер;
— название торговой площадки;
— расписание торгов;
— возможность торговли в настоящий момент;
— шаг цены;
— стоимость шага цены;
— шаг размера ордера;
— минимальный размер ордера;
— минимальная и максимальная цена;
— базовый актив;
— контрактный множитель;
— дата и время экспирации;
— тип опциона (call / put);
— стиль опциона (европейский / американский);
— страйк опциона;
— и т.д.

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

3.3. Позиция.

Включает:
— идентификатор инструмента;
— размер позиции.

3.4. Портфель.

Включает:
— дата и время получения информации обо всех позициях;
— набор позиций.

3.5. Стакан.

В данном случае я буду говорить об агрегированном стакане. Потребуется вспомогательная сущность: «уровень стакана», имеющая три аттрибута — цену, кол-во и сторону (bid или ask).

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

3.6. Котировка.

Включает:
— дату и время её получения;
— идентификатор инструмента;
— лучшую цену покупки;
— лучшую цену продажи;
— возможно, объёмы по лучшим ценам покупки/продажи.

3.7. Сделка.

Включает:
— дату и время её получения;
— идентификатор инструмента;
— цену сделки;
— объём сделки.

3.8. Бар.

Включает:
— дату и время окончания бара;
— период бара;
— идентификатор инструмента;
— цены Open, High, Low, Close;
— объём.

3.9. Собственный ордер.

Включает:
— внутренний идентификатор ордера (номер ордера внутри торговой платформы);
— возможно, идентификатор стратегии, отправившей ордер;
— идентификатор инструмента;
— возможно, идентификатор счёта;
— дату и время создания;
— дату и время последнего обновления информации об ордере;
— сторону ордера (bid / ask);
— цену ордера;
— исходный объём ордера;
— исполненный объём ордера;
— тип ордера (limit, market, …);
— срок действия ордера (day, gtc, fok, ioc, …);
— статус ордера (unknown, pending, rejected, active, filled, cancelled);
— ….

3.10. Отчёт об исполнении собственного ордера.

Включает:
— внутренний идентификатор ордера (номер ордера внутри торговой платформы);
— возможно, идентификатор стратегии, отправившей ордер;
— идентификатор инструмента;
— возможно, идентификатор счёта;
— сторону сделки (bid / ask);
— цену сделки;
— объем сделки.

4. Поддержка торговли на нескольких счетах через один шлюз.

При необходимости торговли на нескольких счетах объект типа Order также должен включать информацию о счёте, на котором идёт торговля.

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

5. API шлюза.

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

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

Группа методов «получение рыночных данных» может включать:
— (sync) получение текущего состояния стакана;
— (sync) получение текущей котировки по инструменту;
— (sync) получение сделок, прошедших с момента последнего запроса;
— (sync) получение баров на заданном таймфрейме за заданный период;
— (async) подписка на обновления стакана;
— (async) подписка на котировки;
— (async) подписка на сделки;
— (async) подписка на бары.

Группа методов «работа с ордерами» может включать:
— постановка ордера;
— отмена ордера;
— модификация ордера;
— (необязательно) массовая отмена ордеров;
— (sync) получение списка активных ордеров;
— (async) подписка на изменения активных ордеров;
— (async) подписка на отчёты по исполнению собственных ордеров;
— (async) подписка на обновления статуса ордеров.

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

От группы методов «получение информации о доступных инструментах» требуется:
— (sync) получение списка инструментов;
— (sync) получение спецификации конкретного инструмента;
— (async) подписка на список инструментов и изменения их спецификаций.

От группы методов «получение информации о текущих позициях» требуется:
— (sync) получение текущих позиций;
— (async) подписка на изменения текущих позиций.

Также шлюз может реализовывать вспомогательные методы:
— (sync) запрос текущего состояния шлюза (online, offline);
— (async) подписка на изменения состояний шлюза.

6. API стратегии.

Стратегия должна иметь методы для запуска и остановки (см. пункт 2 этого раздела). Это отличное место, чтобы подписаться/отписаться от всех необходимых данных.

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

Логика стратегии может вызываться при получении какого-либо события: обновления стакана / обновления котировок / получения баров / прихода сделок, произошедших на рынке / исполнения собственных ордеров.

Кроме того, интерфейс стратегии может реализовывать следующие методы:
— метод для информирования стратегии о необходимости заново считать параметры из конфигурации;
— получение списка параметров (имя, тип, значение (текущее или по-умолчанию));
— получение MBean для стратегии (для любителей JMX);
— получение строки состояния стратегии;
— т.е. по большей части, методы, необходимые для контроля стратегии и управления ею.

Примеры интерфейсов

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

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

Пример интерфейса асинхронного шлюза:
Некоторые аспекты проектирования платформ для торговых роботов

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

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

Итого

1. Вкратце продемонстрирован возможный ход мысли по выработке требований к самописной торговой платформе.
2. Рассмотрено возможное содержимое сущностей, которые могут использоваться для обмена данными между компонентами платформы;
3. Приведены простые примеры интерфейсов компонентов платформы;
4. Таким образом, идея «напишу-ка я робота» обретает более конкретную форму. Определившись с требованиями и используемыми технологиями (языки, библиотеки, субд) можно приступать к воплощению идеи. Надеюсь, кому-то поможет.

Некоторые аспекты проектирования платформ для торговых роботов

Усё.
★76 | ₽ 113
   Вас ещё не приковали наручниками к батарее в уютном подвале с джакузи и массажистками?
avatar

ch5oh

ch5oh, Йа живым не дамся! :)
avatar

Eugene Logunov

Eugene Logunov, живым массажисткам?
avatar

bwc

bwc, И живым массажисткам — тоже :)
avatar

Eugene Logunov

ch5oh, главное соблюдать в сауне масочно-перчаточный режим и социальную дистанцию )
avatar

Врач-бондиатОр

а потом на все это выпустить документацию… т.к без нее года через 3 вообще забудешь что там кодилось...

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


avatar

ves2010

ves2010, 
а потом на все это выпустить документацию… т.к без нее года через 3 вообще забудешь что там кодилось...
Это какой-то очень стрёмный код надо писать, чтобы через 3 года не суметь в нём разобраться))

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

Насчёт багов — тоже спорно. Аскетичный подход к функциональности сильно снижает вероятность ошибок.
avatar

Eugene Logunov

Eugene Logunov, проблема всех собственных разработок, что начиная сегодня и заканчивая через год, проходит условно 1 человеко-лет. А платные компании за год могут проходить и до 50 человеко-лет (как тот же QUIK). Тоесть есть очень не малый шанс морально отстать от всего нового. Опять же при сложности системы есть шанс скатиться в непрерывный баг-фикс без возможности выделения времени на хоть какое-то развитие.

Удачи, проходил.
avatar

Sergey

Sergey, ага… только написал код и тут внезапно поменяли коннектор у брокера… или апи брокер перепилил... 
avatar

ves2010

ves2010, да и в этом так же.

Моя первая программа, которую я создавал для себя начиналась именно с мыслей Майкрософт и ИБМ не правы, я знаю как лучше. Через примерно пол года я понял, что те мысли вначале были неправильные. И я не до конца проанализировал системы. И они как раз правы, а то что я написал, оказалось заточенным только под ситуацию пол-года назад. Фиаско и занавес.
avatar

Sergey

Sergey, ну естественно, это классика жанра. Нубы всегда смотрят «промышленный» код и думают, что он избыточный, сложный и неэффективный, а они типа могут написать круче и эффективнее. Но он поэтому и такой, что легко расширяем, а твое мега-эффективное решение заточено под твои текущие потребности, которые через полгода изменятся, и все придется переписывать заново.
Этим и отличается опытный software architect от начинающего программиста, даже при том, что язык могут знать на одинаковом уровне.
avatar

MadQuant

MadQuant, дело не в квалификации отдельно программиста. Дело в квалификации в области. Это другое.
avatar

Sergey

Sergey, ну я имел в виду именно даже квалификацию программиста базово. Квалификация в области — это еще сложнее. Как правило, хорошие прогеры вообще неквалифицированны в области трейдинга.
avatar

MadQuant

Eugene Logunov, после 50-го проекта вы будете забывать не только код который написали 3 года назад, но и вообще с трудом вспомните что это вообще такое было 
avatar

Аркадий

Аркадий, надуманная проблема - нормальные стратегии именования и структурирования кода сильно помогают, даже если что то и забывается — есть предположения как это реализовать и обычно они совпадают с кодом. а как по Вашему ядро линукса пишут там миллионы LOC?
avatar

My Shadow

My Shadow, ну не знаю, последние лет 30 я писал на куче языков и на двух десятках разных платформ. Нормальные стратегии есть в каком-то одном месте, а если мест много, то хрен… Сами попробуйте, сегодня на Си микроконтроллер, завтра сервис на Java, послезавтра тесты на питоне, потом на C# под Windows, потом микросервисы на Kotlin, потом Android, потом скрипты на Bash и так по кругу много раз… От такого разнообразия голова быстро становится квадратной и очень усталой 
avatar

Аркадий

Аркадий, я писал на не меньшем кол-ве языков и не раз убеждался что кол-во разных идей и концепций в языках программирования довольно конечно. да и у меня в наборе даже коммерчески эксплуатируемый софт на common-lisp-е есть…
avatar

My Shadow

My Shadow, Лисп у нас был в моде в конце 80-х. Эта болезнь нас мучила вместе с языком Форт. Тогда еще можно было писать свой инструментарий и не умереть с голоду. Сейчас это могут позволить себе далеко не все. Рынок быстро отучил от всякой экзотики в программировании.

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

Аркадий

Аркадий, лет 10 назад писал, библиотек конечно не много, но сами реализации довольно серьезны и очень производительны для языка с динамической типизацией, тот же SBCL, а объектная система CLOS родом из 90-х в разы мощнее всего что есть в современных маинстримных языках с динамической типизацией по сей день.
avatar

My Shadow

My Shadow, сейчас нужен готовый продукт, денег в притык, разработчики деревянные, разработка как правило делается по кратчайшему пути от точки А до точки Б. Удивляюсь, как в Jetbrains решились Kotlin придумать…
avatar

Аркадий

Аркадий, Jetbrains особо ничего и не придумывали, они сделали kotlin как сильно упрощенную копию scala, причем реального смысла использовать kotlin когда есть scala — не вижу.
avatar

My Shadow

My Shadow, есть, у него низкий порог вхождения =)  Кроме того он потихоньку расползается всюду, например на Android. Я на Котлине делаю далеко не первый проект для бекэнда, мне пока очень нравится. Scala заумная, а Kotlin простой как кирпич (соотношение наверно как у С++ и Oberon), лаконичный и при этом не хуже обычной Java. Ну а такая фишка как старые, добрые сопрограммы (они же корутины)… Никогда в жизни программирование асинхронных серверов не было столь простым. Попробуйте, не пожалеете.
avatar

Аркадий

Аркадий, в scala порог вхождения сильно зависит что и как планируется писать, а писать можно сильно по разному — в том числе просто как на java с феничками, если не хочется большего, тут подробней www.scala-lang.org/old/node/8610
avatar

My Shadow

Eugene Logunov, можно забыть саму проблему, решение которой закодировано.
avatar

bwc

ves2010, всё делается постепенно.

Аккуратно наращивается, используется и таким образом тестируется.

Да и принцип функциональной простоты никто не отменял.

В мире масса сложных инженерных систем, которые работают стабильно.

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

avatar

FinSerfing

Плюсанул!
Единолично велосипед написать — от 10 лет, 4 раза переписать.
Отличный уже есть, он даже с моторчиком, тест-драйв здесь: http://o-s-a.net
avatar

(1:10) || algo

(1:10) || algo, не рекомендую. Глюк на глюке.
avatar

Sergey

Sergey, А я вот пользуюсь не один год уже, все устраивает, на порядок лучше чем всякие платные(и закрытые) решения. У платформы уже есть не малое сообщество пользователей, все проблемы решаются в оперативном порядке
avatar

Lexuz77

Lexuz77, проблемы там не решаются, потому что основная проблема — сырая основа. Мне хватило двух недель понять, что править там ошибки можно бесконечно. Для финтех это поделка.
avatar

Sergey

Sergey, есть ли что-то другое открытое и большое по по функционалу, кроме OS и S#?
avatar

Павел Ку

(1:10) || algo, 
от 10 лет
Я видел профессиональные платформы для исполнения стратегий, написанные за три года. Только там ещё был некий упор на low latency :)
avatar

Eugene Logunov

(1:10) || algo, у меня Ваш коннектор к SmartCOM в принципе не взлетел. Загрустил.

Ну, то есть как: написал «Подключился, всё ништяк». И никакой маркет-даты не смог нарисовать.

 

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

avatar

ch5oh

ch5oh, у меня там ничего не взлетело толком. Ни QUIK, ни INTER BROK. Написал им чат, мне ценник за саппорт и что я сам дурак и надо самому править. Вот такой «бесплатный» софт оказался.
avatar

Sergey

Sergey, tashik часто его рекомендует. Надо у нее спросить, как дела
avatar

Андрей К

Андрей К, не торгую через Осу сейчас, но слежу за проектом, он развивается, туда пришли интересные разработчики. Торговала я последнее время через TransaqConnector, сама его подпиливала, код же открыт. На мой глаз проект развивается в сторону криптобирж и ориентируется «на широкую публику». Варианта потереть волшебную лампу и оттуда выпорхнет джинн и все для нас сделает Ося не предоставляет. Непрограммисту или человеку, не готовому взять напильник, не подойдет она совсем. Есть ли альтернативы? С открытым кодом их нет. Деньги за поддержку считаю нормальной практикой — это время, которое потратит разраб на дебаг вместо человека. С учетом открытого кода вполне справедливо тут за время платить, раз не хочешь свое время тратить.  
avatar

tashik

tashik, надеюсь это шутка. На ГитХаб проектов под трейдинг море! К примеру под INTER BROK коннекторы в значительной части лучше и стабильнее, чем в этом. И QUIK у них не свой.

Под крипто биржи просто огромное количество проектов достойных. https://github.com/jjxtra/ExchangeSharp И там код родной, а не надерганный с разных мест как в осе с признаком сборной солянки и сопутствующих багов.
avatar

Sergey

Sergey, Какой ценник за саппорт если не секрет?
В час или в месяц?
avatar

Антон Б

Антон Б, они впаривают обучение. Я сам то умею программировать, а саппорт отдельно не продается. А какой саппорт (сколько по норма-часов) — этого нет. В теории будут помогать какое-то время. Но с учетом того, что автор проекта за многие вопросы о багах активно банит, назойливость в вопросах закончится плачевно. И деньги не вернут, и доступ порежут.
avatar

Sergey

Sergey, впишусь всё-таки. Потому что Ваш коммент — это ваш угол зрения. Может быть и другой. Автор на моих глазах банил не за баг-репорты, а за тон и посыл, что кто-то должен это исправить быстренько, ну какого фига. А в open source это так не работает. Видишь проблему — реши проблему, поделись с сообществом. Если не по душе стиль open-source — не надо пользоваться open-source. Про то, что на гитхабе есть куча кода в тему — да есть, конечно, только с ним Вам даже написать будет некому и сообщества не будет. А так берите, делайте, о чем речь. Вместо того, чтобы пасквили в комментах писать и негодовать — сделайте, выложите — люди спасибо скажут (на самом деле нет, на самом деле получите такие же комментарии, как сейчас Алексей от Вас )))
avatar

tashik

tashik, то что вы написали — это не опен сорс. Посмотрите что такое GitHub и что такое Issues. Нормальные руководители проектов только привествуют баг репорты. Они не пытаются сделать что-то на быструю руку ради продажи курсов или роботов.

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

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

Sergey

Sergey, в чате есть JohnDoe, есть еще ребята, я не видела ситуации, когда бы John не помог там, где действительно человек дебажил и получил какой-то затык. Но я видела кучу примеров того, как человек приходит в чат, открывает дверь с ноги и начинает предъявлять претензии, не ткнув ни разу на точку останова, как будто мы должны сделать это за него, раз он почтил нас своим присутствием в телеге. Если у Вас и правда какая-то проблема, и Вы дебажили и не можете найти решение — опишите, вместе разберемся. Я не получаю от Os.Engine ничего вообще. Но я тоже разраб открытых штуковин, если не в плане алгоритмов, то в плане бесплатности использования. Ничего не продаю. Но очень хорошо на собственном опыте с ребятами знаю: если хочешь решить проблему  — можно ее решить.
avatar

tashik

tashik, вы не поняли мою ситуацию. Проблемы все я знаю, я же программист. И писал я не о себе, я там почти ничего не пишу.

Программа очень сырая. Основа неверная. Я могу любой баг исправить. Но смысл? Я прекрасно понимаю, что для вычищения и исправления программы нужен не один год. Зачем мне тратить это на чужой проект? Есть и нормальные платные и бесплатные. С открытым кодом и без. Альтернатив, как вы пишите неверно, масса.
avatar

Sergey

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

tashik

tashik, https://github.com/QuantConnect — отличнейший тестер с готовыми данными (не нужно искать что откуда качать, покупать).

github.com/StockSharp/StockSharp (если не брать крипту за неадекватную цену, но QUIK и INTER BROK бесплатны)

github.com/jjxtra/ExchangeSharp — готовые крипто коннекторы на C#
avatar

Sergey

Sergey, спасибо за ссылки. StockSharp код закрыт. Вы, кстати к ним в техподдержку не обращались, не имели удовольствия? А в их телегу токсичную не писали? )) QuantConnect для рисёрча хороша. Где только коннекторы — не смотрела, погляжу
avatar

tashik

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

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

Sergey

Sergey, вот и хорошо, что не приходится заниматься. Но, знаете, у меня свой софт (не Оса, но некоторый наследный чужой код (не Осы) есть), и я занимаюсь баговычищением регулярно. Поэтому да, это прекрасная реальность, где все работает всегда. Я просто в другой. И в ней то MOEX спектру обновит, то еще какая-нибудь беда или потребность. И вот с этим экспириэнсом я далека от мысли в чем-то кого-то обвинять, кто бесплатно вписывается и код свой открывает. Удачи Вам там, пусть и дальше работает все работает как по маслу.
avatar

tashik

tashik, вот видите. Вы в качестве основы выбрали сырой продукт. Поэтому вам теперь теперь и мучатся до конца. Я же ведь такой ошибки не совершил.
avatar

Sergey

Sergey, )) ок
avatar

tashik

tashik, А вдруг как раньше, возможно, Марс был цветущим и приятным для жизни, а щас пустыня, так и раньше StockSharp был цветущим и приятным. Ну т.е.… Земля тоже когда-то угаснет).
avatar

Replikant_mih

Replikant_mih, «Всё проходит. И это пройдёт» © кольцо царя Соломона.
avatar

tashik

tashik, Ничего не продаю. 


подсказываю вариант как действует TradingView — инкубатор, комбинатор, и вы стартап сто миллионный $, если TechCrunch не врет

avatar

Денис Трофимов

Sergey, это опенсорс с поправкой на российскую всеховатную нищету общества в целом.
даже разработчики относительно западных нищие.
а просто инвесторы вообще заходят на рынок с в среднем МЕНЕЕ 1500 usd.
По этому и приходится фильтровать нищебродов платой за поддержку.

Иначе будешь тратить время на поддержку мудака с 500 usd счетом.
а он еще и будет недоволен.

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

Антон Б

Антон Б, тогда и не нужно вводить в заблуждение что это бесплатно. За обучение там такой ценник, что многие программы за год просят. А коммерческий продукт имеет качество, в отличие от псевдо-бесплатного. Возьмите тот же MT. Бесплатен и на десятилетия вперед ушел. Я его не использую, но как пример.
avatar

Sergey

Sergey, Код бесплатный.
Качай и пользуйся, изучай.
Твори, выдумывай, пробуй.
А работа не бесплатная.
Логично.

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

и брокер целиком контролирует клиент.
в том числе может все что угодно сделать на вашем компютере.
Скачать стратегию)

+ не работает с криптой.

30000 рублей вроде ценник на обучение или в районе этого.
Какие такие некоторве программисты просят 30к рублей в год?
по 2500 в месяц?
avatar

Антон Б

Антон Б, это не бесплатно. Код кривой и с багами. Как минимум я буду платить своим депозитом. Раз. Саппорт платный. Два. Время на вычищение ошибок — бесценно.
avatar

Sergey

Sergey, Код бесплатный.
А вы свое время цените, а время поддержки нет?

Конечно время не бесплатно.
Идея торговая не бесплатная)

Это =торговля на бирже — не бесплатно.))

Только код.
avatar

Антон Б

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

Это аморально брать за такой сырой софт даже копейку. Или нормальное качество или ничего не предлагайте.
avatar

Sergey

Sergey,
1)Там есть клиенты которые ценят свое время.
Они платят ценник за поддержку и получают под ключ.
И тогда глюки тоже входят в эту поддержку.

2) там есть клиенты которые не будут платить, но ИЗРЕДКА коммитят в проект и пользуются.
И тогда глюки они же сами и чинят и коммитят в ОБЩИЙ проект.

3) и есть БОЛЬШИНСТВО нищебродов которые пришли на биржу с 1500usd ничего не умеют и не хотят учится.
3.1) их особенно много в рф из-за повальной нищеты, и при этом достаточно хорошего остаточного от ссср образования.
3.2) в проекте они просто не нужны, их удел заказать роботов в mt4 на форекс за 50usd. получить там поделку с мартингейтом и запустить с 100 плечем.
avatar

Антон Б

Антон Б, да это сказки. Я спросил про ценник на саппорт и мне дали ссылку на обучение.

Продукт сырой и качество низкое. Лучше бы давали за деньги и нормальное качество. Чем вот это бесплатное, где надо несколько лет потратить чтобы это сделать хоть мало мальски стабильным.
avatar

Sergey

Sergey, 
1) то что продукт сырой я согласен.
это факт, и я с ним не спорю.

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

Если вы попросите поддержку и показите что вас стоит поддерживать.
То вас поддержат.
И будет ценник на поддержку.

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

Антон Б

Антон Б, 
и может изменить графики задним числом.
вот так просто. графики просто перечитаются и шпильки пропадут
это кто так делает?
avatar

Андрей К

Андрей К, mt4 и mt5
Сам лично видел НА БОЕВОМ ( реальном не демо )СЧЕТЕ
Именно по этому тестировать на истории скаченной из мт4 и мт5 это соглашатся что история сглажена.
и шпилек там нет.
а реально они там были)
avatar

Антон Б

Антон Б, а кто делает? не терминал, а брокер
avatar

Андрей К

Андрей К, finam. (его кухни разные).
они по разному называются.

но могут делать ВСЕ БРОКЕРЫ.
И я думаю делают.
Когда надо.
Это встроено в платформу mt4 mt5
За платформу платит брокер.
И брокер клиент.
Все для него.
А вы клиент брокера а не метатрейдера
avatar

Антон Б

Антон Б, понятно, это я и хотел услышать, что речь про форекс. А не про броков
avatar

Андрей К

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

Антон Б

Андрей К, это действительно было, но было у кухонь и на FX. Думаю, Антон ошибается.
avatar

Sergey

Sergey, Это заложено в платформу метатрейдера.
Я это видел на реальных деньгах.
О чем и говорю.
Конечно это были кухни.
Но mt4 и мт5 технически позволяет из всего сделать кухню.

Было указано как ответ на «бесплатный» метатрейдер.
Против osa который ещи и с открытым кодом.
В рамках той дискуссии.
Такой бесплттный (для трейдера) метатрейдер обходится ОЧЕНЬ дорого.
Именно в такой момент.
Один такой момент может стоить дороже чем все время и деньги вложенное в osa.
Потому что клиент metatrader это брокер (брокер-кухня)
avatar

Антон Б

Спасибо, интересно! Только слово «шлюз» несколько режет слух :) В программировании распрастронен иной схожий термин — адаптер. Вообще паттерны в подобных системах необходимы от и до, ибо поддерживать такого монстра через несколько лет будет не реально.

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

Dmitryy

Dmitryy, да, изучаем Kafka/RabbitMQ/Apache Flink, добавляем микросервисы с балансировкой нагрузки и автоматическим масштабированием нодов, еще не забыть про сетку из серверов кросс-мониторинга работы и нагрузки :D
Ну и конечно автоматическую DevOps раскатку всего, привет Ansible/Terraform/Kubernetes/Docker
И Грааль запущен :D
avatar

Павел Ку

Павел Ку, работать будет, но будет ли торговать в плюс?)) А чтобы проверить, будет ли торговать в плюс достаточно менее 100 строк кода в R или Matlab :)
avatar

Dmitryy

Dmitryy, ну все зависит от стратегии, если трендовуха, то там может и 50 хватитить, а если что-то более сложное, то и 1000 мало, и в R будете считать годами.
Ну и опять же, это две стороны одной медали: идеи стратегий и надежные их реализации.
Причем часто стратегии ломаются именно по причине плохой реализации: ненадежность и рандомные отказы, недостаточная мощность инфраструктуры (слишком большие проскальзывания, или вообще не-входы) ну и тд.
avatar

Павел Ку

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

Dmitryy

Dmitryy, все стратегии зарабатывают и сливают, для оценки результативности есть куча параметров: ProfitFactor, Sharpe, Sortino, Ulcer и тд
«не существует стратегии существенно обгоняющей индекс на большом промежутке времени» — смотря что вы понимаете под «существенно», и на каком промежутке времени. И опять же, есть разные временные фреймы, ведь есть стратегии про заработать на краткосрочной неэффективности, а есть про методично (медленно, но стабильно) увеличивать основной капитал.
Ну и, конечно, есть такие стратегии, если вы про индекс говорите. Торгую пул таких у амеров. Доходность 10.5%, просадка макс. с 1970 года 6.5%. Кризис только на руку ей пошел. Сравните с индексом SP500. И да, все в конце концов сломается ;)
avatar

Павел Ку

Павел Ку, интервал более 10 лет. Люди часто ошибочно верят в свои стратегии, т.к. тестируют их на бычьем интервале или на медвежьем, в общем интервале имеющем выраженный тренд. А покажите мне стратегию, которая пережила пару дефолтов и осталась в плюсе, не существует такой, уже не раз тут поднимали такие темы :)
avatar

Dmitryy

Dmitryy, интервал более 10 лет — на 50 годах просчитано, и таких стратегий не одна. И там были и кризисы, и взлеты, и все в порядке.
avatar

Павел Ку

Dmitryy, Существуют. но понятно что для доказательства нужно предьявить.
Для существования достаточно одну.
Вот 1 выше индекса я и приведу.

1) покупай акции 1 октября
2) продавай акции 30 апреля (без шортов)
3) с 30 апреля по 1 октября в облигациях которые закончатся до 1 октября.

Дает доходность +2-3% в год выше индекса.
А главное дает бету НИЖЕ индекса.
ОДНОВРЕМЕННО.

(торгую с 2009, два лчи в плюс так что это не просто треп)

Есть и другие с более высокой доходностью идеи.
А главное с меньшим риском.
avatar

Антон Б

Dmitryy, Вообще-то существуют.
И их дофига.
Особенно если стараться не альфу набрать побольше, а бету придавить посильнее.
И потом раскидать на кучу.

В индексе бета тоже совсем!!! не фонтан.
Именно оптимизировать надо бету.
Даже если в результате альфа будет как у индекса. а бета как у облигации.
Это супер.
avatar

Антон Б

Антон Б, а где про такие почитать?
avatar

Dmitryy

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

Может поменьше приносить, но все равно ГЛАВНОЕ бету срезать. и альфу по чуть-чуть приносить.

Математика нужна для проверки идей которые уже есть.
Ищите идеи сами.

А для поиска идей математика НЕ ПРИГОДНА.

avatar

Антон Б

Dmitryy, Вы же утверждали что их нет и не может быть.
Я привел одну.
Рабочую.
Рабочую в смысле обгоняет индекс на истории.
и при этом имеет просадку dd ниже индекса на истории.
Тоейесть нормированная на просадке (по риску вниз, а не вообще по риску) заметим еще одна фишка.)
Даст при том же риске еще больший доход.

Но это делать не надо.
Основная ценность лучше индекса по просадке. (по риску вниз, а не по риску вообще)

Более того объяснил почему эта неэффективность
1) существует. эк обоснование;
2) не была убита, и не будет убита арбитражем. хотя конечно арбитраж ее смазывает.
Потому что она лежит в экономике, которая циклична с циклом год.
Это вся экономика планеты и ее цикл арбитражить целиком не может ни один игрок.
avatar

Антон Б

Антон Б, это всё очень интересно, но пока не попробую не поверю, надо пробовать :)
avatar

Dmitryy

Dmitryy, конечно. можешь заплатить когда проверишь мне 500usd.
Если хочешь)
Я могу тебе код проверки скинуть за те же 500 usd.

это общеизвестные вещи.
Но есть но)
Клиент обычно недофинансирован.
Хочет 100% годовых.
А 2% выше индекса для него это смешно.

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

Антон Б

Dmitryy, вряд ли достаточно. =)
avatar

ch5oh

ch5oh, вам виднее :)
avatar

Dmitryy

Dmitryy, дак тут шлюз искустувенное понятие предметной области, а адаптер — волне конкретный паттрен, например шлюз для виртуальной торговли — какой он адаптер?, поэтому у автора все ок.
avatar

My Shadow

My Shadow, ок, возможно это у меня деформация, из-за того что в своей работе я с этим понятием сталкиваюсь в другом контексте. Ху ноуз.
avatar

Dmitryy

Dmitryy, 
Но порог входа в такие системы к сожалению большой.
Что Вы имеете в виду?
Я не вижу ничего сложного, паттерн один и тот же везде. У меня все сделано на службах c очередями. Сделано лет 10 назад, когда появилась мода на SOA.
avatar

_sg_

_sg_, видимо вы обладали достаточными знаниями, для начинающих разработчиков принципы DDD не постижимы. Не в силу своей сложности, а в силу отстутствия опыта. Без опыта их просто не возможно прочувствовать.
avatar

Dmitryy

Dmitryy, 
Только слово «шлюз» несколько режет слух :)
В индустрии их называют adapter'ами, connector'ами и gateway'ами. Мне привычен последний вариант :)
avatar

Eugene Logunov

Dmitryy, зависит от рода деятельности. Если команда разработчиков делает всю систему целиком (софт + железо), то термин «шлюз» слух не режет. 
avatar

Аркадий

Монументально!
avatar

tashik

tashik,
Монументальность только в объеме написанного.
Ничего особенного не обнаружил.
Для тех кто занимался большими проектами это обычный среднестатистический проект средней сложности.
Новизны нет, обычная рутина.
Главная трудность здесь, только в программировании терминальных точек (коннекторы итд).
avatar

_sg_

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

Eugene Logunov

Eugene Logunov,
тогда могу взять Вас в компаньоны.
Вы пишете терминальные точки (коннекторы итд и прочие хэндлеры), а я пишу всю остальную архитектуру, распределенную.
Думаю, за полгода-год справимся.
Да забыл, с Вас еще постановка задачи по математической части.
avatar

_sg_

_sg_, Я лучше в сторонке постою :)
avatar

Eugene Logunov

Eugene Logunov,
самое интересное, что, если кто-нибудь сделает самую лучшую в мире, идеальную систему трейдинга  по самым высоким канонам, то продать ее все равно будет невозможно. Потому что, как правильно пишут ниже, Заказчику нужна кнопка «Бабло» или мне больше нравится «Где деньги, Зин».
Поэтому и я уже давно расслабился на этот счет и юзаю, то что написал еще очень давно. А Вам за пост спасибо. Было интересно почитать.
avatar

_sg_

_sg_, я оставлю Ваш комментарий без ответа, если позволите, просто контексты разные сейчас у нас. Вы внутри своей экосистемы, а мне пришлось выйти и на мир поглядеть, что и как люди делают. Материал, который Евгений написал — задает планку. Мне нравится та планка, которую он задаёт. Имею право.
avatar

tashik

tashik, 
Вы внутри своей экосистемы, а мне пришлось выйти и на мир поглядеть, что и как люди делают.
Я не понял этого.
Люди делают хорошо или плохо? Выше или ниже Вашей планки.
avatar

_sg_

_sg_, ниже. Если бы на том уровне, как Евгений описал, люди делали — было бы уже здорово. 
avatar

tashik

tashik, ну эта ситуация мне знакома.
Делают быстро.
Получают деньги.
Смываются.
Система быстро загибается.
Заказчик нанимает Пенсионеров вроде меня на зарплату меньшую раз в пять, чтобы в его (заказчика) понимании «ИСПРАВИТЬ КОЕ-ЧТО».
А там не только ВЕСЬ КОД ПЕРЕПИСЫВАТЬ надо, а заново ПРОЕКТИРОВАТЬ всю систему.

Стандарт де факто.
avatar

_sg_

Надеюсь, кому-то поможет.

Не тратить время зря и сразу прогнать свою лаймерскую мыслишку — да я побырому ща набрасаю, а там улучшайзерами пулять буду =)))

Отличная статья! Особенно для чудиков, которые думают, что вот прочитали 100500 книг и теперь в одиночку сделают хороший продукт по принципу «хочешь сделать хорошо — сделай это сам».

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

Антон Денисков (Fry), тут какие то общие критерии типа хорошая/адекватная не совсем подходят — есть люди которые имеют свое виденье как и что должно работать чтоб это их устраивало и если они обладают способностями писать большие программы (именно большие программы, и не теряться в них, а не просто уметь программировать) то появляются подобные вещи и это хорошо. 

avatar

My Shadow

Антон Денисков (Fry), В принципе, можно и в одиночку. Только надо иметь уйму разнообразного опыта, кучу свободного времени и «жирка подкопить», чтобы урчание пустого желудка не отвлекало.
2) Как юридически и фактически удержать все модули и всех людей в команде, чтобы не разбежались как тараканы?
NDA + ограничения доступа к коду (в проекте должно быть по-минимуму разработчиков, которые видят всю картину).
3) Как обойтись без этого (перекупить разбежавшихся тараканов с готовым решением, найти команду, которая уже прошла путь и готова к сотрудничеству на разумных условиях...)?
Знаю два случая, когда люди, разработав платформу для личного (внутрикомандного) использования затем предлагали её в аренду желающим или работали в партнерстве с другой компанией, у которого подобной платформы не было, а им очень хотелось.
avatar

Eugene Logunov

Eugene Logunov, и я знаю :) питерские и воронежские. Они? :) 
Антон Денисков (Fry), Одна команда СПб/Мск, другая вроде как с Кипра.
avatar

Eugene Logunov

Антон Денисков (Fry), не всегда командное. Известно, что производительность программистов отличается раз в 20. Если программист уникум (производительность + IQ + опыт + понимание архитектуры), то он сделает такую систему в одно жало за 2-3 месяца. С отрывом от всей остальной деятельности, понятное дело. Вопрос в том, когда это чудо окупится, потому как зарплата у таких программистов ооочень большая. 
avatar

Аркадий

Аркадий, 2-3 месяца очень крутой срок. Под ключ. 
avatar

Андрей К

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

tashik

tashik, ну если вспомнить волшебный квадрат Брукса, то речь идет об этаком «гаражном» варианте, а не о законченном продукте. Вариант для себя на порядок проще сделать.
В данном случае речь о разработке платформы исключительно для собственного использования.
avatar

Аркадий

Андрей К, ну я знаю пару-тройку людей, которые это могут. Но это гении. Таких 1 на 1000 обычных программистов. 
avatar

Аркадий

Аркадий, я бы такой проект, как в топике, наверное месяцев 8 делал, со всеми нужными шлюзами и летенси. И потом бы еще месяца 3 тестировал.

Сейчас вообще высокотехнологичный делаю третий год. Ужас.
avatar

Андрей К

Андрей К, там не настолько все ужасно. Если есть опыт создания микросервисов, то технически это не сложно. Для меня основной проблемой была бы прикладная часть. Ожидаемо скудный результат делает написание такой хреновины (уже два года лениво об этом думаю) убыточной. За то время, которое я потрачу на доводку алгоритмов торговли я заработаю много денег привычным способом.
У меня знакомый делал такую штуку на ПЛИС. Оно работало прямо в датацентре, на бирже. Соревноваться с ними в скорости я бы не стал =)
avatar

Аркадий

Аркадий, соревноваться я люблю =)
avatar

Андрей К

Андрей К, с аппаратно реализованным алгоритмом, который берет данные  из гигабитной сети прямо на бирже соревноваться тоскливо…
avatar

Аркадий

Аркадий, нормально, самое то =) сеть только десятигигабитная
avatar

Андрей К

Андрей К, не знаю, я стоимость аренды посмотрел и на этом интерес закончился =)
avatar

Аркадий

Аркадий, ну да, тыщ 300-500 ежемесячно надо отдавать
avatar

Андрей К

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

Аркадий

Аркадий, Такие люди есть, но вот засада.
ВСЕ ЭТИ ЛЮДИ сами ищут разработчиков.
Пример та-же оса.
Разработчик вот такой.
Только он не продает труд разработчиков в рынке а ПОКУПАЕТ! его.
Создавая вам конкуренцию за разработчиков.

Вместо того чтобы по вашему рассказу продавать свой труд.)))
avatar

Антон Б

Антон Б, причем большая часть этих товарищей делает это в силиконовой долине. Почти все, кого я знаю, там сидят.
avatar

Аркадий

Аркадий, Ну так откуда у вас уверенность что их можно нанять людям со сотороны?
Они сами НЕТТО ПОКУПАТЕЛИ часов разработки.
И конкуренты для тех кто пытается купить разработчика.

А вы говорите что их можно нанять с улицы.)
За зарплату разработчика.

А раз их нанять нельзя то на рынке труда их нет.
И ссылаться на них нет смысла.
avatar

Антон Б

Антон Б, да упаси господь их нанимать… У них обычно характер такой, что если у вас даже денег на зарплату хватит, этот монстр вас в могилу сведет. Имелось ввиду, что если посчастливилось (или нет, не знаю) самому таким быть, тогда проект для одного вполне подъемный. 
avatar

Аркадий

Аркадий, Вы просто описали так что нанимаешь звезду и он тебе кодит.
я же написал.
что так не получится.
потому что звезда сам в рынке ПОКУПАЕТ часы разработки.
И является при найме разработчиков не ресурсом а ВАШИМ ПРЯМЫМ КОНКУРЕНТОМ на ресурс.
Ресурс — часы разработки.
avatar

Антон Б

Аркадий, проект вполне подъемный если у вас есть торговая идея.
Например вы торгуете ее руками годами.
И можете показать стейт.

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

Антон Б

Eugene Logunov, спасибо, классная статья!

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

А вообще превратить платформу (например, S#) во что-то рабочее (зафиксить баги, добавить нужное), это тоже от года работы, и да, потом поддержка.
avatar

Павел Ку

Павел Ку, 
система тестирования должна работать точно(!) также
Это очень непростая задача))
разделение капитала — крайне важно, когда есть оркестраторы стратегий
Их проще объединить на уровне сигналов и торговать по некоему «композитному» сигналу.
удаленный мониторинг работы серверов-сервисов, этакий Дэшборд, чтобы следить на верхнем уровне, нужно ли вмешательство человека, т.к. умер брокер
Достаточно добавить подсистему уведомлений (email / sms / telegram) и подключить к ней шлюзы через IGatewayStatusListener, который как раз и задуман для отслеживания падений шлюзов. Через неё же можно будет слать сигналы о срабатывании проверок в промежуточном слое.

Ну или просто скрипт на Python'е, который будет выискивать в свежезаписанных в лог строчках подстроки «error», «exception» и «fatal» и засылать их куда надо через telegram.
avatar

Eugene Logunov

Eugene Logunov, 
Это очень непростая задача))
мне кажется, если это изначально не заложить, то будут огромные проблемы с тем, что два разных кода нужно поддерживать. Да и точность расчетов не будет соответствовать реальным торгам.
Их проще объединить на уровне сигналов и торговать по некоему «композитному» сигналу.
Честно говоря, не понимаю, как это можно сделать, если одной стратегии нужно вот именно сейчас войти, не через 5 минут или секунд, то как поможет композит? Тем более разные же классы активов… Было бы здорово, если вы сможете пояснить, какой тут принцип.
Ну или просто скрипт на Python'е, который будет выискивать в свежезаписанных в лог строчках подстроки «error», «exception» и «fatal» и засылать их куда надо через telegram.
Часть проблем этим можно решить, но что, если нода сама падает? Никто не пришлет ничего в телеграм. Тут нужен сервис, также на отдельной ноде, который будет следить за живостью рабочих нод. И желательно пару таких сервисов, чтобы они друг друга кросс-мониторили.
avatar

Павел Ку

Павел Ку, 
Тем более разные же классы активов… Было бы здорово, если вы сможете пояснить, какой тут принцип.
Допустим, есть две простые стратегии и три инструмента. Каждая из простых стратегий говорит, с каким весом нужно взять каждый из инструментов в каждый момент времени:
w_base_1(t) = [wb_1_1(t); wb_1_2(t); wb_1_3(t)];
w_base_2(t) = [wb_2_1(t); wb_2_2(t); wb_2_3(t)].

Пусть также есть ещё одна стратегия, которая отвечает за распределение капитала между простыми стратегиями. Она тоже возвращает вектор весов:
w_comp(t) = [wc_1(t); wc_2(t)].

Тогда можно сосчитать суммарные целевые веса инструментов относительно всего выделенного капитала:
w_total(t) = [wb_1_1(t)*wc_1(t)+wb_2_1(t)*wc_2(t); wb_1_2(t)*wc_1(t)+wb_2_2(t)*wc_2(t); wb_1_3(t)*wc_1(t)+wb_2_3(t)*wc_2(t)].

При отклонении целевого веса инструмента от фактического нужно выставить некие ордера, чтобы скорректировать величину позиций. С каким шагом по времени каждая из стратегий w_base_1(t), w_base_2(t), w_comp(t) принимает решения — не имеет значения.
Часть проблем этим можно решить, но что, если нода сама падает?
Обеспечить абсолютную надежность скорее всего невозможно или очень затратно. Но какой-то уровень надежности обеспечить можно:
1) установкой ИБП;
2) резервированием интернет-каналов;
3) дублированием сообщений по разным каналам (telegram vs slack vs sms);
4) использованием механизма heartbeat'ов;
5) автоматического перезапуска упавших нод (по таймауту heartbeat'а или исчезновению процесса с заданным pid из списка активных);
6) проверкой наличия связи с важными машинами и доступности расположенных на них сервисов из другой локации.
avatar

Eugene Logunov

Eugene Logunov, 
Допустим, есть две простые стратегии и три инструмента
Да, тут все понятно, спасибо, мета-менеджер, который контролирует распределение капитала. Я поэтому вернулся раньше в треде, к исходной фразе:
объединить на уровне сигналов и торговать по некоему «композитному» сигналу.
И вот тут меня озадачило, зачем объединять именно торговлю? Контролировать капитал — однозначно нужна сущность. Но имхо каждая стратегия должна быть полностью независимой, иначе в случае сбоя прослойки, лягут все стратегии.
Обеспечить абсолютную надежность скорее всего невозможно или очень затратно.
Да, да, все так :) А еще может брокер упасть, либо торги на бирже встать, и тут вся инфра сходит с ума и начинает себя перезагружать ;)
avatar

Павел Ку

Павел Ку, объединять очень удобно, а иногда и просто необходимо. Когда не один десяток роботов, замучаешься прикручивать к каждому свой исполнитель. Кроме того, растут расходы в случае возможности сальдирования встречных заявок. Если же немалая часть роботов попробует одновременно купить или продать, они будут толкаться локтями. Не-е-ет. Так не пойдет.
Поэтому сначала считаем требуемую совокупную позицию, а уж потом сальдо с наличной посылаем на исполнитель. И исполнитель можно делать при этом интеллектуальнее, чем обычно принято «выплюнул-проверил». 
avatar

SergeyJu

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

исполнитель можно делать при этом интеллектуальнее
А можно поподробнее? Тут про динамическое временнОе и сайзо-образование ордеров?

Спасибо!
avatar

Павел Ку

Павел Ку, не вижу проблем с системами на разных скоростях, если я отслеживаю виртуальную (совокупную) позицию мгновенно и отрабатываю её с той задержкой, какой может достигать мой исполнитель. Единственно, чему тут нет места — это ХФТ. А замесить в кучу системы на дневках  и системы на минутках, даже на секундах (на акциях таких у меня нет, или пока нет) не вижу проблем.
Что касается интеллекта исполнителя. Обычные вещи, не супер ни разу. Определение размера ордера (не валить все сразу в кучу), определение цены, правила перестановки неисполненных ордеров, учет объема ближних поз в в стакане и так далее. 
Да, я не торгую сетки, у меня нет отложек, поэтому нет и проблем с совмещением трендовых и контртрендовых торговых систем в одном исполнителе. Но и это решаемо, если чуть напрячься. 
avatar

SergeyJu

SergeyJu, со всем согласен в целом. Спасибо за пояснение.
Про ХФТ — тут, наверное, вопрос терминологии, насколько это действительно Х.

И вот как раз про «правила перестановки неисполненных ордеров» — тут явное размытие ответственности между сущностями. Только стратегия должна (и может) знать, на сколько по времени может быть отложен ее ордер, можно ли его переставлять или лить по рынку. Соответственно, срочность выхода влияет на необходимость расчета размер ордера, учета плотности стакана и т.п.

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

То есть я ни в коем случае не говорю, что исполнитель (в вашем смысле — с довольно сложной логикой), это однозначное зло. Все зависит от стратегий, если в их логике выход в течение 15 секунд и 10 минут не влияет на результат, вай нот, лучше доверить это более умному исполнителю, который оптимизирует просадку стакана. Логика стратегии упрощается (она только говорит, что хочу изменить позу с Х на Y), а манипуляции делает исполнитель.
avatar

Павел Ку

Павел Ку, чем больше объем средств, тем, в среднем, приходится работать с системами, у которых время удержания позиции больше (сделки реже). Поэтому системы, для которых критично время исполнения «немедленно или никогда», я не использую. 
avatar

SergeyJu

сколько по времени и деньгам займет создание? ну условно 2 бек прогера по 200к на каждого в месяц   на фултайм на 4 месяца?
avatar

Vladimir Soloviev

Vladimir Soloviev, нереально, они пару месяцев будут только курить предметную область. 2 прогера на год хотя бы. А ведь еще стратегии нужно пилить, дебажить и тестить.
avatar

Павел Ку

Vladimir Soloviev, прогеры — это последняя стадия.

Сначала идёт архитектор.

avatar

FinSerfing

Vladimir Soloviev, прогерами тут не обойтись, тут либо 1 как Евгений нужен, фанат своего дела) Либо куча людей, с грамотным манагером, итого мне видится такая команда:
— манагер
— математик
— риск менеджер
— фин. аналитик
— прогеры х2 (бек)
— прогеры (фронт, графики рисовать)
(это еще без девопсов)

И это всё года на 2, просто чтобы сделать. И 200к это нет гарантии что их за 2 года не переманят) Надо 300-500 :)
avatar

Dmitryy

Dmitryy, да, все верно описали, чувствуется опыт) Стартануть нормальный алготрейдинг — это дорого и долго. И далеко не факт, что даже с составом выше взлетит. Это, в целом, такой стартап-стартап, с невысокой вероятностью успеха. Поэтому в России, при довольно большом количестве попыток, всего 3.5 конторы закрепились на долгосрок (по крайней мере, относительно крупные про которые я знаю).
avatar

MadQuant

Dmitryy, немного не так.
так-как проект не веб.
то нужны c# дисктоп.
Фронты вообще не нужны.
Беки это те же C#.

разработчиков может быть и один.
или 2.
сколько позволит бюджет.
но целиком.
никакого фриланса и прочее.
avatar

Антон Б

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

Дмитрий К

chizhan, золотые слова насчет от простого к сложному. А насчет копипасты,  вот я наивняк, думал чел сам такой труд на гора выдал. Еще думаю,  нифига гений,  тока предыдущий пост был про книжки по программировнию,  и такой развернутый ответ
avatar

Дмитрий К

Дмитрий К, да скомпилировал все сам, но многое взято «оттуда».
avatar

chizhan

chizhan, 
многое взято «оттуда».
В основном взято из 10 лет разнообразного опыта))
avatar

Eugene Logunov

Нельзя ли перевести на русский:
ксорите DWORD'ы в уме
вот нутром чую, что-то примитивное, но терминов не знаю. 
Прежде, чем углубляться во все эти занимательные вещи, неплохо бы на коленке прикинуть, какие вопросы более высокого уровня должна решать вся эта конструкция. 
1. Что торгуется — портфель, один актив, как происходит управление включением/отключением торговых систем, их весами и так далее.
2. Это делается под один свой портфель или под множество клиентских портфелей.
3. Каковы функции и полномочия человека-оператора, как обрабатываются нештатные ситуации, возникшие вне взаимодействия проги и бирж.  
Ну и так далее. 
avatar

SergeyJu

XOR — исключающее ИЛИ.
avatar

Khan Tengri

SergeyJu, DWORD — Double Word в MS Windows или unsigned 32-bit integer. 
avatar

wot

SergeyJu, 
вот нутром чую, что-то примитивное, но терминов не знаю. 
Выше правильно подсказывают. Речь про исключающее ИЛИ над 32-битными числами.
какие вопросы более высокого уровня должна решать вся эта конструкция. 
При наличии ответственности за чужие средства или торговлей множеством алгоритмов надо будет ещё много над чем подумать.
avatar

Eugene Logunov

Eugene Logunov, понял. Слава Богу, лет 30-40 это уже практически никому не нужно. 

avatar

SergeyJu

chizhan, именно поэтому возник ООП, как этап разделения ответственности.

High cohesion / low coupling и пр.

А после двинулись в сторону сервисов и микросервисов.

Впрочем, платформа для алготрейдинга даже близко к такой сложности не приближается.

avatar

FinSerfing

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

broker25

Это уже не робот, а космический корабль)
У меня 4 строчки торговой логики и около 1000 строк исполняющего кода) но даже с ними гемороя хватает)
avatar

robomakerr

1. Сервисы и  микро сервисы
2. Шина данных
3. Service discovery, DNS служб
5. Push — технологии взаимодействия
6. Тотальный Контроль на уровне служб, потоков, компонентов
7. Тотальное логирование для каждой службы
8. Службы хранения и восстановления данных
итд итп
Вобщем, что-то похожее на SОА надо. У меня это все реализовано лет 10 назад.
Система расширяется добавлением необходимой службы.

Ну вот, например логи для 3x отдельных служб. Trading, Storage, TradeTerminаls



avatar

_sg_

Мне такие мауналы хотелось писать, когда морально был опустошен и на рынке болото =). Сейчас не до них.

Может как нить накидаю, что нынче нужно для hft, когда нить.

Спасибо за топик, под кофеек зашел, понастальгировал над своим прошлым =)
avatar

Андрей К

chizhan, ну ккак бы всегда находится тот кому не нравится вид кнопочек… и хочет вместо круглых квадратные
avatar

ves2010

Масштабненько)). Обычно когда кто-то пишет про свою архитектуру — в комментах обязательно найдется несколько человек с комментариями по шаблону «тут так-то главное стратегии, можно и руками торговать, время на стратегии-то останется?»), но тебе будет чем отбиться).

 

Вообще тема очень интересная, творческая, мне нравится свое пилить — тоже можно интересные идеи воплощать.

avatar

Replikant_mih

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

 

Это все круто, чувствуется, что не нагуглил), но это примерно про то, куда надо прийти, но ни слово про то как идти). Заделать мега-тз и долго-долго пилить до первого запуска — это очень сложно. Поэтому надо действовать через MVP, через MVP отдельных блоков, вернее так, MVP системы в целом и сначала болванки отдельных блоков. Т.е. стратегическую архитектуру этого хозяйства продумываешь, а дальше делаешь отдельные работоспособные блоки, а остальные вставляешь легкими в реализации болванками, интерфейс есть, но по факту ничего не происходит, ну например, какой-то риск модуль, который может вмешиваться и там будет интересная сложная логика, но по факту сначала там ветер гуляет, он принимает передает данные, но не вмешивается.

А ты кстати присутствовал/участвовал в то время когда эта система была в активной фазе жизненного цикла? Понятно, что любая система постоянно допиливается, но у любой системы есть этап когда все происходит… крупными мазками)). Мне вот очень интересно было бы послушать про этот путь. 

 

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

avatar

Replikant_mih

Replikant_mih, 
фак, у меня даже палец устал это листать, сколько же сил надо на то чтобы такое запилить!
К 15 страницам текста и картинок ещё 12 страниц комментов настрочили))
Поэтому надо действовать через MVP, через MVP отдельных блоков, вернее так, MVP системы в целом и сначала болванки отдельных блоков.
Для начала можно и монолитно всё сделать. Но распиливать такое — я пас.
А ты кстати присутствовал/участвовал в то время когда эта система была в активной фазе жизненного цикла?
В данном случае речь не о какой-то конкретной системе. Присутствовал / участвовал я во всяком; лапу, правда, в основном к шлюзам прикладывал в 2010-2012.

Вот сложные бэктестеры мне было проще bottom-up разрабатывать, т.к. было понятно как должно быть сделано глубоко внутри, а api для использования додумывался на ходу.
avatar

Eugene Logunov

Eugene Logunov, А, так кроме всего прочего можно сказать, что это вообще гипотетический вариант)), ты так и пиши, а-то ж демотивирует)).
avatar

Replikant_mih

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

avatar

Replikant_mih

Самое главное так и не освещено в статье. )))

1. Как сделать что бы эта каша выигрывала деньги?
2. И если первый пункт не работает, кому это все добро продать?

Без этих двух ответов это все не имеет смысла. ))

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

Susanin

Susanin, 
1. Как сделать что бы эта каша выигрывала деньги?
Найти зарабатывающего трейдера и позволить ему себя укусить! ;)
avatar

Eugene Logunov

Eugene Logunov, ах, если бы все было так просто мой друг. если бы все было так просто. ))))
avatar

Susanin

Susanin, где у нее кнопка «БАБЛО!» ??? вот же упущение-то! ))))
avatar

tashik

tashik, Это самая главная кнопка в любом деле )))
avatar

Susanin

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

Сергей

В методах интерфейса не обязательно писать модификатор доступа public, т.к. все методы по умолчанию публичные. Помните про clean code ))
 в тексте не хватает обещанных ранее котиков…
avatar

Врач-бондиатОр

Врач-бондиатОр,


avatar

Eugene Logunov

chizhan, это несущественно конечно
АПИ — это это набор правил для чего-то (в узком смысле топика - доступа кудато)
ШЛЮЗ — это готовая программа использующая некий АПИ
я про это stocksharp.ru/news/12030/otmenyaem-kripto-litsenzii!/
avatar

Сергей

все что написано, мне как ни странно понятно. раз я уж выступил «мотиватором/триггером» данного поста в какой то степени — система №1 (которая как бы есть)  это комбайн, в котором есть все что описано здесь, но мне очень не помешает скорость исполнения. + анализ торговых данных БД на питоне. огромный респект за пост.
avatar

kvazar

kvazar,
Вы правы.
Этот пост «спровоцировали» Вы.
avatar

_sg_

Хорошая статья. Можно более наглядной сделать.
— разделить Архитектуру на проектирование (вопрос что?) и строительство (вопрос как?)  

avatar

Jkrsss

Еще хотелось бы измышления на тему безопасности почитать (для параноиков).
Типа, как всё организовать, что б комп с граалью удалённо хакнуть не могли).
В начале статьи приводятся ссылки на api для ineractivebrokers, может кому попадались api для ВТБ и Сбербанк брокеров?
avatar

Brent Goldman

Brent Goldman, Про сбер — хз. По ВТБ:


Многие через квик делают. API есть у некоторых других брокеров: алор, iti, Тинькофф, Exante. Также см. варианты, предоставляемые мосбиржей: www.moex.com/s329
avatar

Eugene Logunov

Eugene Logunov, спасибо за достаточно подробный ответ.
avatar

Brent Goldman

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

Alex Smirnov

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

Сейчас (и 10 лет назад тоже были, но не для России или я не нашел) есть новые готовые инструменты, где достаточно быть трейдером — бизнесменом. Минимум что вам потребуется, это формализовать правила ТС. Написать индикатор или собрать из готовых кирпичей. Будут у вас сигналы, бэктестинг, автомат торговый, все что захотите.

Никакого клиент — серверного программирования, АПИ и пр частному трейдеру не нужно, пока он не брокер / дилер.

Не хотел конкретики ибо посчитают рекламой, но мне нравится TradingView, вы не могли не видеть графики что в нем сделаны на всех ресурсах. Его  впилили в Тинькофф.Инвестиции и investing.com

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

avatar

Денис Трофимов

Денис Трофимов,
Скрипт в TradingView НЕ СОВЕРШАЕТ РЕАЛЬНЫХ СДЕЛОК.
Это скрипт для весьма! посредственного бектеста.

Дизайн графиков отличный.
Роботов для реала приходится переписывать на C#.

avatar

Антон Б


теги блога Eugene Logunov

....все тэги



2010-2020
UPDONW