Торговые роботы

Всем доброго времени суток !

Пост https://smart-lab.ru/blog/969242.php из раздела «Торговые роботы» заставил меня вспомнить, как по годичным данным Финама дневок фьючерса Si я пытался анализировать примитивную стратегию, основанную на ожиданиях трейдеров на выходных какого-нибудь негатива.

Торгуем склеенный фьючерс Si.

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

По пятницам. По цене закрытия.

Закрываем позицию. По понедельникам. По цене открытия.

Профит за год очень даже неплохой.

Но, если просто открыть в начале года лонг и просто «перекладываться», профит гораздо больше.

Идея отброшена.

А потом я решил сравнить профит от простого лонга с разными своими ТС, на создание которых потрачены время и здоровье, где «обсасываются» разные умные слова типа «Диверсификация», «Шарп», «Прибыль/Риск», «Арбитраж», «Выделенный сервер», «Автооптимизация» и т.д.

✅Результат за 15.12: $359,12 (+1,80%)

💵Результат с начала месяца Декабрь: +$1 221,68 (+6,11%)

💵Результат с начала 2023 года: +$28 144,69 (+140,72%)

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

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

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

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

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

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

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

Поэтому:

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

✅Результат за 14.12: — $161,37 (-0,81%)

💵Результат с начала месяца Декабрь: +$889,40 (+4,45%)

💵Результат с начала 2023 года: +$27 812,41 (+139,06%)

▶баланс $27 678,06 / Эквити $27 570,99

___________________

🕯Описание стратегии: smart-lab.ru/blog/925228.php

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

Количество строк в методах.

Некоторые программисты целенаправленно делают вместо 10 методов по 100 строк, 200 методов по 10 строк, искренне считают, что это хорошо. Суть в том, что разбитый на такие мелкие части код легче тестировать, когда у Вас в команде есть тестеры, и вероятно в больших коммерческих проектах это чистое благо. Однако. Имея в команде пару человек, которые не будут за Вами писать тесты, это ЧИСТОЕ ЗЛО.

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

✅Результат за 12.12: $216,69 (+1,08%)

💵Результат с месяца Декабрь: +$968,42 (+4,84%)

💵Результат с начала 2023 года: +$27 891,43 (+139,46%)