обмен данными

Облачный сервис Snowflake успешно дебютировал на бирже: инвесторы оценили его в $70,4 млрд, компания привлекла более $3 млрд.
Акции облачного сервиса Snowflake подорожали вдвое в ходе первичного публичного размещения на Нью-Йоркской фондовой бирже.
Накануне IPO компания оценила акции в $120 за штуку, на бирже они торговались по $245 на открытии торгов и по $253 — на закрытии.
Инвесторы оценили компанию в $70,4 млрд — в пять раз дороже, чем в феврале 2020 года.

Snowflake появилась в 2012 году. Компания предоставляет клиентам технологию быстрого анализа и обмена большими массивами данных. В числе её партнёров есть Cisco. В первом полугодии 2020 года выручка Snowflake составила $242 млн (+130% год к году), убытки достигли $171,3 млн (в 2019 году — $177,2 млн).

Мне нравится Lua. Lua хороший компактный язык на котором можно сделать индикаторы, различные вспомогательные программы, помогающие трейдеру и даже несложные торговые системы (ТС, роботы). Пожалуй единственная книга по Lua — Роберту Иерузалимски: Программирование на языке Lua. Ее можно найти в интернете.

Lua имеет также несложный C-API позволяющий связать программы Quik Lua с внешним миром через DLL и получить доступ практически ко всему, в том числе к любым математическим библиотекам обработки данных, что необходимо для сколь-нибудь сложным ТС. Однако, для этого уже необходимо знание не только Lua, но и Lua C-API, языка С/С++, а также умения писать DLL. При этом надо будет решить еще ряд проблем, которые возникнут по ходу пьесы в процессе этой деятельности. Далеко не каждый пользователь Quik и Lua может все это реализовать в обозримое время.
У Quik Lua (QLua) есть еще недостатки — все события терминала в Lua работают в потоке терминала, и получив из них данные надо как можно быстрей завершать функции обработки этих данных и освобождать поток терминала, иначе терминал просто повиснет. Единственная функция QLua работающая в собственном потоке — это main() и вся сколь-нибудь сложная обработка может находиться только в ней.
Кроме того, для Lua крайне мало библиотек, а существующие работают оч не быстро. В принципе, это и не нужно, если можно организовать связь с внешним миром через C-API. Но нам от этого легче не становится.) Короче, для написания хорошей сложной ТС нам надо выйти за пределы QLua и установить связь с внешним миром, и сделать это доступными средствами.
Сейчас наиболее продвинутым языком, включающим в себя массу библиотек обработки данных является Python. По применимости для обработки данных он, пожалуй, занимает первое место в мире, а по распространенности входит в первую пятерку. В числе библиотек — математические, статистические, машинного обучения и пр., и пр. Таких библиотек более тысячи только в Anaconda, большинство из которых устанавливается при ее инсталяции. Вы можете не использовать Anaconda и скачать Python с сайта

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

По мотивам прошлого поста.

Выбрал два пути для реализации: TCP/IP и RabbitMQ. Сейчас в процессе выбора между, но пока что флоп в пользу первого решения. От хелоуворлда текстовиков я отказался, хотя ninjatrader оказывается напрямую предлагает часть функционала реализовывать через файлы. (0_о)

Почему TCP/IP — потому что коллега пообещал на пальцах показать как это работает.
Почему RabbitMQ — ну уж ооооочень хорошо описан, для филологов.

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

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

Вот еще бы кто подсказал простой путь к сердцу OEC API (надо при получении ответа на GET открывать/закрывать ордера, вся математика в NT). ))) Коннектор там запилить я смог, а вот ордерпостилка не получается, не смотря на примеры…

Господа кодеры, прошу идейного совета, но с практическими направлениями. Есть задача портировать генерируемые стратегией в NT трейды на OEC Trader. Т.к. я сишарплю, а парни за стенкой ноудджиесят, получить у них качественный совет не получилось.

Текущее решение сделано в режиме хелоуворлда — пишем генерируемые трейды StreamWriter'ом в ТХТ, потом слушаем ТХТ файл FileSystemWatcher'ом и торгуем в ОЕС.

Когда работает одна стратежка, то все выглядит чин-чин, но ессно когда одновременно работают 2+ стратежки, то при вызове StreamWriter по концу часа несколькими идеями код матерится (файл блаблабла занят другим процессом). Делать многопоточный кастыль для передачи трейдов через ТХТ? Мне кажется это некошерно… Смотрю в сторону WCF… Но там не нашел применимых примеров. Там только калькуляторы, которые я не могу в мозгу перевернуть в то, что мне нужно.

Так вот вопрос — абстрагируясь от NT и ОЕС (они умеют обычный C# без проблем), что лучше выбрать для решения задачи? Если аргументы в пользу ТХТ+Thread, то я готов подвинуться религией. Если в сторону WCF, то пните в нормальный пример. Не калькулятор, а где через службу одна прога отправляет что-то как команду, а вторая прога глотает как команду.

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