Очень интересная статья и картинки классные, спасибо.
Вы пишете, что смотрите из мира out source, а не было желания поработать в продуктовой компании, где все же есть некая свобода в выборе стека технологий и их обновления? К тому же, многие продуктовые компании выпускают свои разработки в качестве open source проектов, или все же для вас это не равносильные варианты?
Да, в одном проекте действительно граница будет заметна. Но с другой стороны, многие проекты написаны на Java и Scala (та же Kafka, Apache Flink, Apache Mahout) и судя по всему Java там используется не только для обеспечения совместимости.
Вообще интересно получилось, что большая часть выбранного мной так или иначе связана со скалой, я даже не заметила.
В любом случае, смысл был скорее не в инструментах, а в задачах, которые можно с их помощью решить (то есть машинное обучение, работа с большими данными, потоки данных, хранение без жесткой структуры). Тут уже можно выбрать, что больше нравится, для этого и привела в статье похожие проекты.
Я бы не сказала, что Spark и Kafka из мира Scala. То есть да, Spark, конечно, больше адаптирован под скалу, и примеров кода на Scala гораздо больше. Но это не означает, что на Java его применять не нужно. Я с его помощью написала полноценное приложение и осталась очень довольна, знание скалы мне не понадобилось.
Kafka я использовала именно в Java-приложении и никакой связи со скалой в процессе поиска и настройки я не замечала. Видимо, я чего-то не знаю, поделитесь, пожалуйста, почему это брокер из мира Scala?
А вот насчет Akka я соглашусь, на Java ее используют скорее в специфических случаях, а на Scala это достаточно распространенный подход. Но опять же, я слышала об успешных примерах использования этой технологии и в Java приложениях.
Мне кажется, языки и технологии уже так сильно пересекаются друг с другом, что выделить отдельный "мир Scala" или "мир Java" достаточно проблематично. Почему бы не изучить хорошие идеи из других языков, если они вполне применимы и в выбранном вами языке? [риторический вопрос]
«не как успешный трейдер» — вот как раз истории провалов тоже интересны
"Не как успешный трейдер" было к тому, что я вообще не трейдер. Из "провалов" разве что был случай, когда мне надо было проверить обработку частично исполненных заявок и я просадила пол-миллиона рублей на тестовом счете. А если серьезно, то на бирже с целью заработка или проверки успешных стратегий я торговать не пробовала.
Я пишу как разработчик, имеющий опыт в создании приложения для торговли, а не как успешный трейдер. Поэтому и пишу о протоколе FIX и его использовании в Java-приложениях, а не о том, как заработать свой первый миллион на бирже или разработать торгового робота за 30 минут.
У меня был небольшой опыт, поскольку я разрабатывала ПО для размещения заявок на MOEX и в процессе тестирования общалась со специалистами и разбиралась, как там все устроено, почему некоторые заявки проходят быстро, а некоторые "зависают", почему биржа отклоняет некоторые запросы и т.д. Именно в рамках выполнения этой задачи мне не хватало хорошей теоретической базы и про протокол FIX, и про основное устройство биржи и процесса торгов.
P.S. А про женщин-трейдеров нечем с вами поделиться, к сожалению...
Это ведь не завершённая статья, это первая часть из цикла. Моя основная цель — рассказать об устройстве биржи и о базовых понятиях (сделках, фьючерсах и т.д) в рамках работы с FIX. Я в своё время работала с MOEX, сначала использовала MiniFIX, чтобы просто подключиться посмотреть, как работает, потом писала полноценный микросервис для работы с этой биржей (поэтому я в дальнейшем и буду освещать два этих способа) И, честно говоря, единственное отличие — это кастомные теги и форматы некоторых полей.
Мне не хватало какой-то комплексной информации по теоретическим вопросам и по совмещению этой теории конкретно с FIX-ом, поэтому захотелось структурировать все это в один цикл статей и помочь тем, кто не знает, с чего начать.
Здесь используется собственная простая биржа на основе примера из репозитория QuikFIX/J, поскольку каждая реальная биржа имеет свои особенности (дополнительные теги, ограничения и т.д). Я же хотела рассмотреть базовый пример, на основе которого уже можно будет работать с конкретными биржами.
Очень интересная статья и картинки классные, спасибо.
Вы пишете, что смотрите из мира out source, а не было желания поработать в продуктовой компании, где все же есть некая свобода в выборе стека технологий и их обновления? К тому же, многие продуктовые компании выпускают свои разработки в качестве open source проектов, или все же для вас это не равносильные варианты?
Да, в одном проекте действительно граница будет заметна. Но с другой стороны, многие проекты написаны на Java и Scala (та же Kafka, Apache Flink, Apache Mahout) и судя по всему Java там используется не только для обеспечения совместимости.
Вообще интересно получилось, что большая часть выбранного мной так или иначе связана со скалой, я даже не заметила.
В любом случае, смысл был скорее не в инструментах, а в задачах, которые можно с их помощью решить (то есть машинное обучение, работа с большими данными, потоки данных, хранение без жесткой структуры). Тут уже можно выбрать, что больше нравится, для этого и привела в статье похожие проекты.
Я бы не сказала, что Spark и Kafka из мира Scala. То есть да, Spark, конечно, больше адаптирован под скалу, и примеров кода на Scala гораздо больше. Но это не означает, что на Java его применять не нужно. Я с его помощью написала полноценное приложение и осталась очень довольна, знание скалы мне не понадобилось.
Kafka я использовала именно в Java-приложении и никакой связи со скалой в процессе поиска и настройки я не замечала. Видимо, я чего-то не знаю, поделитесь, пожалуйста, почему это брокер из мира Scala?
А вот насчет Akka я соглашусь, на Java ее используют скорее в специфических случаях, а на Scala это достаточно распространенный подход. Но опять же, я слышала об успешных примерах использования этой технологии и в Java приложениях.
Мне кажется, языки и технологии уже так сильно пересекаются друг с другом, что выделить отдельный "мир Scala" или "мир Java" достаточно проблематично. Почему бы не изучить хорошие идеи из других языков, если они вполне применимы и в выбранном вами языке? [риторический вопрос]
Да, логично
Но к MOEX, насколько я поняла, можно просто по заявке подключиться, без каких-то страшных контрактов. Но может я и ошибаюсь.
"Не как успешный трейдер" было к тому, что я вообще не трейдер. Из "провалов" разве что был случай, когда мне надо было проверить обработку частично исполненных заявок и я просадила пол-миллиона рублей на тестовом счете. А если серьезно, то на бирже с целью заработка или проверки успешных стратегий я торговать не пробовала.
Я пишу как разработчик, имеющий опыт в создании приложения для торговли, а не как успешный трейдер. Поэтому и пишу о протоколе FIX и его использовании в Java-приложениях, а не о том, как заработать свой первый миллион на бирже или разработать торгового робота за 30 минут.
У меня был небольшой опыт, поскольку я разрабатывала ПО для размещения заявок на MOEX и в процессе тестирования общалась со специалистами и разбиралась, как там все устроено, почему некоторые заявки проходят быстро, а некоторые "зависают", почему биржа отклоняет некоторые запросы и т.д. Именно в рамках выполнения этой задачи мне не хватало хорошей теоретической базы и про протокол FIX, и про основное устройство биржи и процесса торгов.
P.S. А про женщин-трейдеров нечем с вами поделиться, к сожалению...
Мне не хватало какой-то комплексной информации по теоретическим вопросам и по совмещению этой теории конкретно с FIX-ом, поэтому захотелось структурировать все это в один цикл статей и помочь тем, кто не знает, с чего начать.