торговый софт

Сегодня рассмотрим историю появления индикатора Sma.

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

Оглавление.

1.      История появления индикатора Sma.

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

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

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

4.1.   Стратегия на пересечение цены и линии индикатора Sma.

4.2.   Пересечение двух индикаторов Sma.

4.3.   Пересечение трех индикаторов Sma.

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

4.5.   Стратегия основанная на пяти индикаторах Sma.

5.      Таблица общих результатов.

 

1. История появления индикатора Sma.

История возникновения индикатора SMA связана с развитием технического анализа на фондовых рынках.

( Читать дальше )

Всем добрый день! Подскажите, кто-то уже успел протестировать терминал Трейд-радар ? 

Брокер ALOR запускает акцию для сообщества Old School Algo. Для тех, кто будет переходить от другого брокера или открывать счета в АЛОР по нашей ссылке. В этом посте поговорим о том, что это и как это работает.

1. Условия.

Фондовый рынок МБ.

( Читать дальше )

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

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



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

На сегодняшний момент, даже подписка на 200 или 400 бумаг не ложат стандартную поточную архитектуру сервера, предложенную ниже.

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

 

 

Один коннектор – оптимально два потока.

 

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

1. Проверка жизни Вёбсокета. Это поток номер один. Если есть вёбСокет, данный поток должен быть в обязательном порядке.
2. Конвертер сообщений. Поток номер два. В бесконечном цикле занимается разбором входящих сообщений от биржи/брокера.

Никакие другие потоки создавать не нужно. Только если этого требует само АПИ. Плюс, это должен быть THREAD, а не Task.

( Читать дальше )

Бесплатный трекер аномальной инсайдерской активности на рынке + поиск аномалий. Пользуйтесь.

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

Это сделано с помощью

Metatrader 5 (MQL5) -> ETL -> ClickHouse -> Яндекс DataLens

Брокер Финам

 

Данные в процессе уточнения!

 

1) Берем облигацию (ОФЗ или корпоративную)

2) Считаем сколько будет денег в конце погашения

3) Пересчитываем на количество дней владения

4) Пересчитываем прирост доходности на каждый день

 

Например

Среднее дневное значение % в день 0,09, умножаем на весь год владения, 365 дней

 

Это если бы все так хорошо покупал и гасил.

То

365 * 0,09 = 32,85% годовых по счету к концу погашения

 

Прошу не считать эти выводы и расчеты за чистую монету. Ведутся исследования.

Если есть конструктив или ваши примеры, прошу в комментарии.

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

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

Складной нож не требует постоянного отмачивания в машинном масле.

И конечно же, складной нож не нуждается в перевязывании изолентой с другими предметами —  топорами или вилками. В этом нет смысла.

Совместные классы-парсеры для разных коннекторов.

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

Всё это заканчивалось переделыванием с нуля.

Поэтому:

Совместные классы-парсеры, вёбСокет-обёртки и рест-оболочки для коннекторов запрещены.

( Читать дальше )