В нескольких предыдущих постах серии мы разговаривали про IServer, свойства и методы, которые в нём есть. Их много и довольно разных. При этом каждое отдельно взятое API что-то поддерживает, а что-то нет. О том, что конкретно коннектор поддерживает, OsEngine должен знать ДО того, как начнёт запрашивать неработающий функционал. Для этого ServerPermission и существует.

Например, данные могут быть только свечные, или может не быть 15 минутных свечек. Или API может вообще не поддерживать скачку глубоких исторических данных. Или API не поддерживает какие-то торговые операции: нет Market ордеров, не работает перестановка цены ордера.

1. Расположение интерфейса в проекте.

Cлой автотестов для коннекторов переживает в OsEngine уже ВТОРОЕ пришествие. Увеличившись с первой версии в 10 раз. Про что и будет данная мини-серия статей внутри серии «Коннекторы к OsEngine». АЖ НА 20 Постов. Так надо…

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

Так вышло, что ядро OsEngine тестируется почти без остановки с разных сторон одновременно. И тестером, и оптимизатором и роботами в реальных боях. В какой-то момент дошло до того, что команда в офисе узнаёт о багах, если таковые есть, после их пуша в ядро через 10 – 20 минут.

Выглядит это так:

Рис. 1. Модули, тестирующие слои, поддерживающие работу роботов. 

Поэтому само ядро OsEngine стабильно.

Проблемы в другом месте… В коннекторах. Чем мы с Вами и будем весь 2024 год заниматься.

1. Зачем это всё? И почему будет так много внимания тестам?

Это самая важная часть создания коннекторов. «Наговнить немного кода, чтобы как-то что-то заработало» — дело нехитрое. Однако при таком подходе пользователи будут не довольны, т.к. коннектор будет работать плохо. Поэтому надо делать хорошо, чтобы коннектор начал проходить автоматические тесты. И для этого придётся попотеть.

Сегодня рассмотрим интерфейс с названием IServer, через который осуществляется доступ к коннекторам в OsEngine. Посмотрим, что у него там есть внутри.

IServer. Общие сведения.

IServer – интерфейс для доступа к реализациям серверов почти во всём проекте. Нужен для того, чтобы унифицировать методы и свойства, нужные для роботов и OsData.

Вероятно, для каких-то молодых камрадов это будет откровением, ибо каждая книжка по Шарпам уже с первых глав нас знакомит с тем, что в C# за сборкой мусора следить не надо. Однако это маркетинговая выдумка. В высоко нагруженных проектах вроде OsEngine, как только ты не проследил за удалением объектов и выкинул это из головы, началась утечка памяти.

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

И в этом посте поговорим о том, какие штуки надо обязательно подчищать за собой при удалении коннектора. А вернее при вызове его обязательного к перегрузке метода DISPOSE();

Dispose в коннекторе.

Очень часто коннектор нуждается в перезапуске. Это обусловлено свойствами работы сети интернет. В этот момент у ServerRealization вызывается метод Dispose. Все манипуляции по очищению памяти и переменных нужно делать из этого метода. И ни из какого другого…

Сборщику мусора нужна помощь.

Сегодня мы рассмотрим индикатор VWMA. Узнаем историю создания индикатора и то, как он рассчитывается.

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

Оглавление

1.    История создания индикатора.

2.    Как проводятся расчеты индикатора VWMA.

3.    Какие сигналы может подавать индикатор.

4.    Роботы для OsEngine на индикаторе VWMA.

4.1. Стратегия основанная на пересечении индикатора VWMA с ценой.

4.2. Стратегия основанная на пересечении двух индикаторов VWMA.

4.3. Стратегия основанная на трех индикаторах VWMA.

4.4. Стратегия на пересечение индикатора VWMA и VWMA со сдвигом.

4.5. Стратегия с двумя индикаторами Ema и двумя VWMA.

5.    Итоговая таблица результатов. 18

1. История создания индикатора.

Индикатор Volume Weighted Moving Average (VWMA) был разработан в 90-х годах. Этот индикатор используется для определения трендов на финансовых рынках, учитывая объем торгов при расчете скользящей средней.

Надеюсь, все отдохнули! С прошедшими! Поговорим о том, что нас ждёт в этом году.

О чём ещё говорят астрологи…

1. Февраль всё ближе! Чаты расцветут!

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



Напоминаю, 9 декабря 2023 года мы собирались на митап алготрейдеров из сообществ OsEngine и Смартлаб: https://smart-lab.ru/company/os_engine/blog/965467.php

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

Внезапно, нашлись люди (спасибо Вам!), которые идею поддержали. В итоге собрали 36 т.р.

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

1. Стиральная машина.

У них недавно сломались две стиральные машины из четырёх. И чтобы дети были отстираны, нужна была срочно замена.

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

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

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

RateGate.

Объект, который отвечает за задержки между запросами, называется RateGate и находится у нас в проекте вот здесь:

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

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

Работающая библиотека.

WebSocket4Net.

Данная библиотека и реализация вёбсокетов хорошо себя показывают в работе. Её и нужно использовать.

Сегодня мы рассмотрим индикатор EMA, узнаем историю создания индикатора и то, как он рассчитывается.

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

Оглавление

1.    История создания индикатора.

2.    Как проводятся расчеты индикатора ADX.

3.    Какие сигналы может подавать индикатор.

4.    Роботы для OsEngine на индикаторе ADX (Average Directional Index).

4.1. Стратегия пробой канала из двух Ema и Adx.

4.2. Торговая система ADX и EMA.

4.3. Стратегия с ADX, Stochastic Oscillator и три ЕМА.

4.4. Стратегия торговли на пересечении +DI и –DI.

5.    Итоговая таблица результатов.

1. История создания индикатора.

EMA с времени её разработки стала одним из наиболее часто используемых индикаторов в техническом анализе.

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