buybackoff

QUIKSharp почти достиг 1.0, so what?

QUIKSharp - самый удобный и единственный действительно open-source коннектор к Квику — приближается к версии 1.0 и к трехлетию (OMFG, как быстро крипторынок растет время течет!). Правда 1.0-beta уже почти как полноценный 1.0.

Прошлое предновогоднее обновление  — благодаря Prophetic  — было очень продуктивным, закрыло важные для многих дыры, и добавило примеры. С тех пор мы допилили еще, а коннектором воспользовались приличное количество пользователей на ГитХабе, а также:
  • TSLab — спасибо, что добавили ссылку! Верю на слово, не скачивал после этого ;)
  • OsEngine — очень интересный проект. Виден серьезный подход к делу практикующими людьми. Спасибо за лучи поддержки, добрые слова в Readme (и за тот email, Alex)!
  • Liquid.Pro — идут по пути TSLab, игнорируют Apache 2.0 и не ставят ссылку, но все равно спасибо за подтверждение валидности решения!
  • Ряд других проектов, которые поленились отметиться тут.
За последние полгода-год не было серьезных сообщений об ошибках, абсолютное большинство не касалось QUIK#, а C# и Visual Studio (сейчас всё упаковано в формат VS2017/.NET Core чтобы быстро паковать в NuGet, VS2015 и ниже не будут работать — один из частых вопросов). Вероятно после добавления просьбы о том, какие issues стоит оставлять в репо, а какие на StackOverflow, вопросов к проекту почти не осталось, всё «работает из коробки».

За все три года остался огромный вопрос к ARQA Technologies — неужели так сложно сделать нативный быстрый JSON-RPC интерфейс!? В эпоху, когда Биткоин по $18k, Эфир по $700, и все работают через этот протокол, — это epic fail! Если работа над ним идет, то пожалуйста где-то напишите! Я не ленюсь периодически (после очередного сообщения о странной ошибке QUIK#) читать release notes, но там этого нигде нет.

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

Подарки пользователям в новом году:

  • Хотите ли вы JSON-RPC с полным соответствием протоколу (что подразумевает паралелльных клиентов)? Тогда можно будет работать из любого языка, а быстрое и удобное C# решение останется снаружи как есть сейчас.
  • Хотите ли вы встроенное супер быстрое хранилище данных с мощной компрессией, интегрированное с QUIK#? Вмещает терабайты с random-access без падения скорости.
  • Хотите ли вы быстрый движок расчетов временных рядов в реальном времени, интегрированный с QUIK#? Тот самый, но сильно повзрослевший и ускорившийся еще в несколько раз. Мышкой кубики рисовать не получится, но гибкость максимальная. (Старый пример тривиальной стратегии для передачи смысла/духа тут).
  • Хотите ли вы true open source и адаптированные под местный рынок коннекторы FIX/FAST/TWIME/PLAZA (или наоборот, хотите ли, чтобы их не было в открытом доступе и за сколько ;) )? На самом деле на ГитХабе почти всё есть, только нужно докручивать (есть совсем профи вещи). Сложно упаковать так, чтобы работало из коробки и на всех платформах. А те, кому это действительно нужно — или сами умеют, или понимают, что надежность вполне стоит тех денег, за которые её можно купить уже готовую. Так что вопрос — неужели это кому-то может быть еще нужно, например с (A)GPL для всех, и за подарки в ответ на другую лицензию? (пока себе ответил, что нет)
  • Самое главное — хотите ли вы, чтобы ваши пожелания по проекту сбылись в новом году и попали в версию 1.0!? Если да — пожалуйста, оставьте свои комментарии тут и подробно расскажите, что вам не хватает от QUIK# в текущем виде, или какую боль создают другие коннекторы и не торопятся ее решать. Если вы не манипулировали рынком и клиентами в этом году — то Санта Клаус придет к вам с подарками в следующем! Но он должен знать, что дарить :)

Что могут подарить текущие и будущие пользователи, оставшись при своих и повысив шансы на подарки себе:

  • Пожалуйста, — пробуйте, тестируйте, оставляйте комментарии и issues. Последний пункт из подарков вам является не менее важным подарком нам!
  • Звездочки дают больше энергии завсегдатаям ГитХаба и апологетам open source сильнее, чем солнце дает энергию Амазонке через фотосинтез. Иногда за вечер пятницы/субботы можно захакать больше функционала, чем ленивые корпораты выкатывают за полгода-год (хотя бы в пересчете на человека). Проблема найти эти свободные вечера, но накопленные звездочки в репо копят мотивацию в голове, чтобы в один прекрасный weekend пофиксить и ускорить всё в несколько раз...
  • Pull requests — это ядерная энергия! Уже давно коллективных коммитов от смелых пользователей больше, чем моих, и проект уже давно общественный и жив и вырос благодаря этим прекрасным людям. Там особо нечего уже менять, но в случае чего — смело добавляйтесь в этот список и мы вас всячески поддержим!


С наступающим и всех благ!

Увидимся на каком-нибудь рынке, где есть стакан, и ГитХабе :)

★12
29 комментариев
позитивный пост =)
avatar
Андрей К, спасибо! НГ же скоро :) А это же Вы парсите FAST руками то ли в Луа, то ли близко? Когда писал пост изначально была фраза «парсить протоколы руками просто, если умеючи», и вспоминал пост тут об этом. Я тоже могу, но не «настолько» на лету, как там было :)
avatar
buybackoff, lua под wireshark. Не думал, что это кто то читает. Но вы уже второй серьезный разработчик, кто мне об этом пишет =)
Парсер делал, чтобы дамп в удобном виде полистать и выгрузить в excel. В принципе на лету он тоже сможет, но у меня c++ для этого
avatar
Андрей К, а можете прислать «на позырить» на Луа часть, если она не секретная? Очень любопытно было. Помимо QUIK# я еще писал Луа в Редисе (у меня есть другой публичный проект на ГитХабе Ractor), но глубже не копал. Много думал ставить («как ставки») на Луа или нет, в итоге чистый C победил, но он «нужен только когда действительно нужен»
avatar
buybackoff, без проблем, там ничего секретного нет. И сложного тем более. У wiresharka легкое API. Завтра скину ссылку, сейчас я уже дома.
avatar
buybackoff, twime кстати тоже этот скрипт парсит. Но он то еще проще.
avatar
Андрей К, TWIME это SBE, я когда-то в очередную «продуктивную пятницу» type provider к нему написал на F# (кроме var length полей). TWIME/SBE — это как должно было быть в самом начале, чтобы не мучили нас!
avatar
buybackoff, у меня есть мнение, что биржа начала свое существование с Delphi программистов. Так как вакансии у них до сих пор есть для дельфийцев (возможно из за оракла). Да и если посмотреть на их первые разработки.
Там идеология другая, мышление чуть другое, поэтому с твайма наверное никак не могло пойти. А придумали плазу. А фикс тупо купили у стороннего разраба.
avatar
Андрей К, на самом деле Плаза по смыслу была почти SBE/Twime. Даже на какой-то конфе их лид подтвердил, да и по code gen tool видно было. Смысл и идея по крайней мере та же — flighweight поверх потока из сети. Что еще может в принципе быть быстрее!? Особенно если как в SBE — главные части идут первые, и их можно парсить до полного прихода сообщения. Для меня Delphi мало что значит, застал только его затухание, но этот чувак открыл глаза на всё важное в таком контексте (Вам наверное представлять его не надо): https://www.infoq.com/profile/Martin-Thompson
avatar
buybackoff, 
«парсить протоколы руками просто, если умеючи»

кстати некоторый нужный fast от валютки, я давно уже в хексе читаю, глаз привык. Как в фильме Матрица =))
avatar
buybackoff, напишу, почему я лично прошел мимо вашего проекта.

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

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

Я не могу себе лично позволить развивать свою инфраструктуру, базируюсь на бесплатном ПО. Сегодня это ПО есть, а завтра автор удалит его из сети. Возиться с его не всегда хорошим кодом нет абсолютно ни малейшего желания.

Желаю в новом году пересмотреть подход и сделать действительно востребованным ваш проект. Возможно, я вернусь.
avatar
Sergey, «он не живой» — это коннектор со стабильным API. Чем меньше изменений, тем больше стабильности. В какую сторону развивать, если все работет? Этот пост был о направлении развития.

"… завтра автор удалит его из сети..." снова печалька, что в этой стране мало кто понимает, чем открытый код отличается от бесплатного ПО. Я не могу позволить развивать любые свои решения на закртытом коде. Платность ортогональна открытости, а открытый код не может никуда деться.
avatar
buybackoff, «В какую сторону развивать, если все работет?» видимо в эту https://github.com/finsight/QUIKSharp/issues

«снова печалька, что в этой стране мало кто понимает» если под «этой стране» подразумевается Россия, то я не из России.

«открытый код отличается от бесплатного ПО» почему вы решили что это не понимаю для меня загадка

«Я не могу позволить развивать любые свои решения на закртытом коде» а ваши решения чем интересны? я писал о своих решениях

«открытый код не может никуда деться» а чем он мне поможет? напишу я робота, и при следующего обновлении терминала QUIK он перестанет работать. Вы недоступны, ответить может через несколько дней (если ответите), а убытки я получаю в реальном времени. Ковыряться в чужом коде? А смысл? У меня время, например, сейчас стоит 200 евро в час. Зачем мне тратить на низкооплачиваемую работу свое время? Мне проще заплатить 50 евро в месяц, и быть уверенным, что по моему запросу будут отвечать.

Мы говорим о торговых роботах. Программах, оперирующих деньгами. О финансовом мире. А не калькуляторах и прочих альтруистиках. Вы не трейдер, вам не понять, почему ваше решение не применимо к реальным торгам.

Открытый код не решает никакой проблемы в финансах. Это популярное заблуждение. Важно не открытость или закрытость — важно поддерживается решение или нет. Кому платить и сколько, чтобы мне отвечали в течении разумного времени. Вот что действительно важно.
avatar
Sergey, QUIK# — это не продукт, я писал со дня #1 о том, что не собираюсь пытаться из него делать продукт. Это building bloсk как открытое ПО. Открытое — это значит, что вы можете изменить код как вам нужно в любой момент и не бояться, что вендор уйдет с рынка или повысит цены на support в 10 раз. Это кирпичик, в котором сделано много повторной работы, которую иначе всем бы пришлось переделывать заново. Очевидно вы не целевая аудитория проекта.

Про страну мне не важно, имел в виду менталитет — в нашем пространстве не принято здороваться в подъездах и коллабоционировать в open source так широко, как на западе. Моё личное давнее наблюдение, и хотелось бы в нем заблуждаться.
avatar
buybackoff, «Очевидно вы не целевая аудитория проекта.» я алготрейдер, пишущий роботов на C#. Да, видимо я не ЦА.

«имел в виду менталитет» мне не интересны подобные темы. Для этого есть другие сайты. Я предпочитаю оставаться профессионалом, и обсуждать только профессиональные темы.
avatar
Liquid.Pro — идут по пути TSLab, игнорируют Apache 2.0 и не ставят ссылку,
у них возможно разработчик один и тот же. Мое личное предположение
avatar
Андрей К, очевидно, что другой. Но я передам.

А что за «хранилище на терабайты данных»? Я таких только 2 знаю.
avatar

ch5oh, терабайты в наши дни так мало, что главное SQL в чистом виде не использовать. Я успел протестировать свое на 2.5TB, BigO того же порядка, что в начале — где-то 25-30% в конце конечно хуже, — на запись, чтение почти стабильное. Но не берите мои слова за чистую монету, я в следующем году всё буду доказывать with reproducible tests, если более интересных дел не будет. Пришлось заморозить основной проект по многим прининам.

А какие два вы знаете? Я на ГитХабе знаю гораздо больше, только на Go например Prometheus, Influx вполне «масштабируемые» (но дьявол в деталях, про latency там или ни слова, или плохо).

avatar

buybackoff, диски как раз у всех разные. Помню много лет тому покупал топовые SSD и ставил их в рейд, для снижения латентности из-за дисковой подсистемы.

 

Ну, возможно, у меня однобокий взгляд. Меня интересуют только решения с качественной интеграцией к .NET.

Полноценно такими можно считать Оракл и MsSQL (начиная с 2012-й версии).

У других СУБД есть изъян серьёзный: они или очень быстрые, но без транзакционности. Или дают транзакционность, но становятся очень медленными.

А Вы же понимаете, что живете в реальном мире: рано или поздно Вам перережут силовой кабель и СУБД ляжет аварийно. И если при этом есть риск потерять 2-5 терабайт накопленных рыночных данных — то СУБД без поддержки транзакционности и журналирования отпадают сразу.

avatar
ch5oh, сейчас сеть быстрее записи диска, даже на SSD, поэтому проще дублировать на соседние ноды важные данные. В контексте рыночных котировок транзакционность каждой единицы не нужна, так как все данные идут от биржи и их можно запросить заново. Поэтому если делать batching+compression и относится к хранилищу как к кэшу с удобной схемой, то запись/чтение могут быть на порядки быстрее. В текущем дизайне у меня риск потерять незакоммиченный (fsync) последний батч. И то, он сначала пишется в mmaped WAL, если падает приложение, но OS жива или в диске есть аккумулятор и данные успевают flush to disk from mmap, то WAL жив. Но это тонкое хитрое место, которое надо доводить до ума. Надежно нужно хранить команды от роботов и логи, но все равно fsync на каждый чих невозможно делать и надо как-то верить, что кабель не отрежут сразу на всех нодах :)
avatar

buybackoff, докачать можно в лучшем случае текущий торговый день.

А если, условно, «bad block» в куске данных месячной давности?

В целом, как понял, решения на уровне: "Быстро, но никаких гарантий". Каждый выбирает для себя. В любом случае, если буду интересоваться этой темой еще раз, придется делать новый ресеч по свежим софтинкам. =)

 

avatar
ch5oh, WAL batch размером с 1-4 страницы файловой системы на каждый поток, остальное всё надежно как в любой ДБ, потому что и так хранится в любой ДБ :) 
avatar
ch5oh, часто люди думают, что технология для трейдинга какая-то особенная — а всё упирается в hardware & tradeoffs: realiability vs speed. Во многом вопрос дизайна для данной задачи, диски у всех одинаковые.
avatar
1. Почему используете lua, а не lua api на си или делфи? Получается быстрее.
2. Зачем использовать JSON — это все же текстовый формат? Может использовать какой-то двоичный формат типа protocol buffers от google?
avatar
Александр, вы делали бенчмарки и производительность QUIK# оказалась проблемой!?
avatar
С наступающим и всех благ!
Увидимся на каком-нибудь рынке, где есть стакан
Новый год без стаканА невозможен. )
Вас также с наступающим!
avatar
Про «супер быстрое хранилище данных» — хотелось бы узнать подробнее, о чем идет речь (то ли о чем я думаю, или что-то иное). У меня часто запущено одновременно 10-20 роботов по повторяющимся инструментам + 1 стратегия, работающая одновременно на 30+ бумагах. Для работы с таким количеством  данных, а также принимая во внимание особенности организации одновременной работы множества роботов под QUIK#, мне пришлось создать собственное хранилище данных, к которому и обращаются мои роботы вместо постоянных запросов к квику. Если Вы предлагаете некую альтернативу, то я бы на нее посмотрел.
Что касается всего остального: как уже написал buybackoff, QUIK#, на сегодняшний день, это единственный полнофункциональный и полностью бесплатный коннектор к квику. И я рад, что смог внести свою лепту в развитие этого проекта. В моем видении, туда уже давно нечего добавлять. Последние изменения (багфиксы) были более 4-х месяцев назад, а расширение функционала еще раньше закончилось. Так что я обращаюсь к коллегам алготрейдерам (в том числе начинающим): QUIK# — это отличная возможность начать написание своих собственных роботов, на собственных условиях, без зависимости от разработчиков мультифункциональных продуктов.

З.Ы.: Надо будет на досуге Os.Engine посмотреть. Вдруг и там «напакостить» получится. :)

З.З.Ы.: Перечитал свой коммент, и показалось, что пишет товарищ, которому проплатили рекламу :).
Это не так. Я проходимец, случайно нашедший для себя QUIK#, и теперь нещадно его эксплуатирующий. С наступающим всех!
avatar

теги блога buybackoff

....все тэги



UPDONW
Новый дизайн