Я Java разработчик.
Делаю программу загрузки исторических биржевых данных. Это часть другого проекта — побольше. И пока бесплатная и открытая — как долго не знаю.
Летом 2015 года написал программу поиска свечных закономерностей вот по
этому алгоритму. В моем проекте, длинна искомого паттерна варьируется от 1 до 15, эти цифры хардкодятся в коде, остальное все делается автоматически. Сейчас проектом не занимаюсь. Исходный код открыт, но сразу предупреждаю там
кровь и кишки. Ну да ладно. В конце разработки этого проекта родился модуль, который быстро и удобно грузит исторические данные с финама в текстовый формат. В этих кишках его вполне можно найти.
Сейчас мне надо отдельно быстро и удобно загружать историю.
Текущее положение дел с загрузкой исторических данных не устраивает.
1. Мой код с ошибками, он не всегда корректно приклеивает обновленные данный к имеющимся, там немного поправить, но не вижу смысла. Забрать только часть загрузки истории — трудно. Слишком большая связность с другими частями проекта. Проще написать новый!
2. Гидра — там много проблемм: память, дикие настройки (видос на полтора часа чтоб научиться грузить историю?!), скорость загрузки.................
3. Другие программы которые призваны делать тоже самое, глючат, требуют внимания в процессе работы (зачем? включили — работай!)
Чтоб сразу делать с учетом потребностей обозначу что я хочу чтобы сразу было:
1. Данные грузит с финама (потому что уже умею).
2. Формат сохранения yyyymmdd,hhmmss,o,h,l,c,v например: 20100111,110000,501.21,518.00,495.00,512.00,3019 количество нулей после запятой определяется автоматически на основе всех загруженных данных этого инструмента
3. При загрузке программа просканирует каталог где хранится история и сразуже начнет обновлять уже имеющие данные не дожидаясь действий от пользователя, отключаемо конечно. Пишет сообщение какие именно инструменты обнаружены и обновление происходит успешно и ожидаемо.
4. Java позволяет писать мультиплатформенные программы, без специальных действий со стороны разработчиква — воспользуемся. Будет работать на Windows, Linux, MacOS.
5. Не знаю зачем надо GUI, но можно и сделать — например чтобы выбирать из списка какие инструменты и таймфреймы грузить.
6. Вообще по умолчанию грузим все таймфреймы. В разные файлы.
7. По умолчанию формат наименований файлов: FINAM-MTLR-21018-3.txt где «MTLR» и «21018» это коды инструмента а «3» это код таймфрейма в API(?) финама.
хотелки после основного релиза:
хранить в sql тоже
p2p обмен историческими данными между пользователями (просто меня прёт от p2p технологий, хочу их куда-нибудь прикрутить)
API чтобы к ней можно было обращаться как к источнику данных, получать сообщения о поступлени новых данных.
грузить не только свечки
грузить с других источников, в том числе и с терминалов
Налетайте с советами и своими хотелками! Я к тебе обращаюсь, ты зашел - значит интересно — пиши!
p2p не нужен, нет у нас такого кол-во трейдеров, хостинг проще и дешевле обойдётся. один раз загрузили разложили по минимальным барам и раздавай всем желающим, только новые добавляй.
паттерны изъезженная тема, прибыли не будет даже если есть совпадения, рынок просто вас пережуёт и пойдёт по другому пути. тестировать стратегию на истории это плохая идея, даже демо доступ полной картины не даст.
только реальная торговля иначе никак.
кроссплатформенность только звучит красиво, а на деле пшик, если брать нашу биржу то есть только один шлюз до биржи к которому сможете подключиться не на windows, но он дорогой и клиентов не найдёте.
в общем как хобби проект интересный, а как бизнес маловероятно что выгорит, но наши люди и в ммм участвовали :-)
KNK, спасибо за ответ.
К сожалению, для меня это звучит, как китайская грамота… :)
-сканирование и автоматическая дозагрузка(3) — самая интересная фича из перечисленного.
GUI нужен, по крайней мере для того чтобы пользователь смог быстро вспомнить че происходит, че у него есть и понять что что-то пошло не так.
можно еще сделать генерилку разно-секундных баров из загруженных тиков… но тогда id финама для таймфреймов не подойдут… а придется опуститься до чегонить типа количества секунд в баре… что несколько непривычно
если будете корячить p2p — думайте как гарантировать подлинность файлов...
имхо sql просто нахер не нужен для хранения котировок(неудобно и медленно)… разве что только файлы в нем целиком хранить в виде зазипленных блобов.
вот автоматического сканирования и дозагрузки и не хватает больше всего. Чтоб запустил программу — сразу она докачивает, как торрент клиент.
GUI — думаю да. Конечно да, надо как-то показать пользователю что все ОК.
Генерилка разносекундных — даже уже начинаю понимать зачем надо генерить и постоянно хранить. Раньше считал что можно каждый раз расчитывать.
p2p — хэш. Вообще посмотреть как реализованы протоколы битторент.
SQL — не так все просто. Уж очень он удобен в коде.
Меня больше интересует библиотечная сторона проблемы, т.е. что подключать в своем коде без GUI. Так что возможно есть смысл разбить на core и gui модули. Посмотрим, чем могу помочь.