Продолжаем разговаривать про класс, предоставляющий данные для источников в OsEngine. А именно про класс ConnectorCandles. И в данной статье поговорим о его коде. Что там есть.
Сам класс находится в проекте вот здесь:
Изменения, баг-фиксы и улучшения, которые были внесены в проект за последний месяц.
В данной статье поговорим об использовании циклов. Какие нужны, а какие смогут уронить наш замечательный терминал. Кроме того, поговорим о синтаксическом сахаре из библиотеки LINQ, которая, как не сложно догадаться по динамике этих записей, тоже под запретом. Почему и как?
Один из самых быстрых циклов, которые существуют. Это основная боевая единица, которую нужно использовать.
Данный цикл не создаёт дополнительных методов в памяти и не является потоконебезопасным. Практически любую ситуацию внутри него можно обработать. Также он позволяет ставить внутри себя точки останова.
Бесконечный цикл с условием продолжения.
Также разрешён к использованию. Имеет все плюсы цикла for.
Этот цикл создаёт метод внутри памяти и не даёт контролировать выбор объекта. В случае, если есть какие-то проблемы с перечислением или листом, выбрасывается неконтролируемое исключение.
Данный цикл нельзя использовать в многопоточном окружении при работе с листами.
Продолжаем разбираться со слоями в OsEngine. И впереди у нас три статьи про класс ConnectorCandles.
Смотрим на картинку:
Класс, предоставляющий данные для источников в роботе. Хранит в себе информацию по подключению. Содержит внутри процедуры для переподключения к серверам в случае разрыва соединений и изменении настроек со стороны пользователя.
Находится в проекте вот здесь:
Сегодня рассмотрим историю появления индикатора 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. Таблица общих результатов.
История возникновения индикатора SMA связана с развитием технического анализа на фондовых рынках.
Брокер ALOR запускает акцию для сообщества Old School Algo. Для тех, кто будет переходить от другого брокера или открывать счета в АЛОР по нашей ссылке. В этом посте поговорим о том, что это и как это работает.
Пробила Россия мне два колеса.
На неё обижаться не стану!
Открываю Авито. Звоню, красота!
В выездной шиномонтаж, Богдану.
Пуховик до пояса в грязище весь.
Ржу. Дым пускаю в звёздное небо!
Хорошо, что Россия будущего ЗДЕСЬ!
И хорошо, что в либеральной ты не был!
Был в командировке, запускал роботов для заказчика в Москве. Проект сдал, нефтяники довольны. Будем дальше удалённо поддерживать товарищей. Но не об этом сейчас.
Ездил на машине. Так вот
Возвращался из Москвы в Васюринскую. Пробил две покрышки вчера ночью...
Просто кусками разлетелись в разные стороны...
Чуть не запаниковал. ОДНАКО!
1) Через 5ть минут подъехала ДПС. Узнать, что случилось.
2) Через 15 минут выездной шиномонтаж был на месте.
3) Через 30 минут дорожные рабочие латали дырку на дороге.
4) Через полтора часа я ехал дальше с полным осознанием, что живу в прекрасной стране. Чуть не прослезился.
Unreal.
Цените то, что у нас есть. Как я понимаю, у города Шахты сразу после победы демократических сил году в 90 — 99, меня бы сбросили в кювет с ножом под ребром, а на машине уже сегодня ездил какой-нибудь поборник демократии, голосовавший за Ельцина. Ельф, так сказать, наказавший Москаля, ехавшего на юг. Навальнёнок по нашим временам. Хорошо, что это всё в прошлом. А такую Россию надо беречь, которую я видел вчера ночью.
OsEngine невозможно ускорить многопоточностью в коннекторе. 98% всех задержек находятся в самих роботах. И от того, как их пишут пользователи, зависит скорость работы программы.
Так было не всегда… Были времена, когда казалось, что это не так. Но годы шли, OsEngine шлифовался и ускорялся. С модификацией Aserver, журналов и прочего всё больше становилось очевидно, что задержки именно в роботах.
На сегодняшний момент, даже подписка на 200 или 400 бумаг не ложат стандартную поточную архитектуру сервера, предложенную ниже.
Поэтому делаем, как тут написано. Время экспериментов закончено.
Полный и достаточный список потоков, которые могут и должны быть в любом сервере:
Никакие другие потоки создавать не нужно. Только если этого требует само АПИ. Плюс, это должен быть THREAD, а не Task.
Проблема, о которой поговорим сегодня – генерация хитрых архитектур для коннектора. Сразу же скажу, что коннектор в рамках OsEngine, насколько бы он для вас сложным не был, — очень простая штука, если пользоваться моими советами и вести тесты. Настолько простая, как складной нож. Он очень прост и не нуждается ни в каких дополнениях.
Складной нож не нужно прикручивать к палке, чтобы им управлять.
Складной нож не требует постоянного отмачивания в машинном масле.
И конечно же, складной нож не нуждается в перевязывании изолентой с другими предметами — топорами или вилками. В этом нет смысла.
Самое худшее, что можно сделать, – придумать класс, который будет использоваться разными коннекторами для парсинга данных. Сколько бы я этого не видел, это почти неизбежно приводит к неработоспособности коннектора.
Всё это заканчивалось переделыванием с нуля.
Поэтому:
Совместные классы-парсеры, вёбСокет-обёртки и рест-оболочки для коннекторов запрещены.
Короткая статья о методах и их оформлении. Данная часть стандартов направлена на людей в разной стадии понятия дзена программирования. Людей, которые находятся в стадии эксперимента на уровне написания самого кода внутри методов, обработчиков и свойств. Их, абсолютно также, как и во время именования переменных, можно написать так, что другие программисты понимать не будут. Поговорим об этом…
Некоторые программисты целенаправленно делают вместо 10 методов по 100 строк, 200 методов по 10 строк, искренне считают, что это хорошо. Суть в том, что разбитый на такие мелкие части код легче тестировать, когда у Вас в команде есть тестеры, и вероятно в больших коммерческих проектах это чистое благо. Однако. Имея в команде пару человек, которые не будут за Вами писать тесты, это ЧИСТОЕ ЗЛО.
Некоторые программисты, кто делает вместо 10 методов Один, также искренне полагают, что это круто. Используют тонну синтаксического сахара, вызовы методов в методах и прочее… Это в свою очередь вызвано юношеским максимализмом и увлечением языками вроде Питона, что провоцирует людей на эксперименты с сахаром. Добавляя такое в проект, Вы также наносите ему непоправимый ущерб.