Программирование для меня это хобби и любимое дело. А так я сертифицированный системный архитектор. Поэтому прошу не особо ругать за код :-)

В настоящее время я увлекаюсь написанием торговых роботов. Постепенно изучаю нейросети для их применения к анализу цен/объемов акций/фьючерсов.

Обычно я писал торговых роботов для работы с Брокерами и делал авто-торговлю Акциями или Фьючерсами, но вдруг возникла мысль:

- А что, если уже готовый код можно применять и на других активах??? Например на крипто активах для Биткоина или Эфира или других?

Уже изучив много библиотек и примеров за долгое время написания своих торговых роботов, решил сделать небольшую библиотеку backtrader_binance для интеграции API Binance и библиотеки тестирования торговых стратегий Backtrader.

Вот с помощью backtrader_binance, сейчас и создадим алго-робота для торговли BTC и ETH.

Центральной частью биржи являются торговые системы и их торговые ядра, в которых происходит matching заявок участников рынка и формируется order_log

Именно к торговому ядру (вернее к шлюзу) подключаются участники торгов. При этом, чтобы торговая система (ТС) могла работать, в неё к началу ежедневной торговой сессии должны попасть описания торговых инструментов и описания клиентов и их параметров подключения к ТС.

Если в двух словах описать эти процессы: они долгие и сложные.

Почему так?

Приведем пример – допустим, пришла к нам мошенническая фирма, выпустила облигации, участники рынка купили эти облигации, а фирма вместо того, чтобы исполнять обязательства перед держателями облигаций, перевела все полученные от рынка средства на офшор на Каймановых островах и была такова. Кто за это ответит? Кого будут сажать в тюрьму?

Чтобы избежать подобных ситуаций, как при допуске к торгам финансовых инструментов, так и при допуске к торгам участников этих торгов, выполняются KYC проверки и тех и других, причем в зависимости от роли в торгах и  от рынка (например, валютный, фондовый, рынок деривативов) – процессы, по которым биржа будет проверять участника торгов или эмитента финансовых инструментов, будут свои и будут состоять из разных шагов и разных наборов проверок.

Keycloak для нас – центральная система авторизации и аутентификации всех внешних и внутренних пользователей. Мы «подружили» ее с другими системами и сервисами, гоняли с различными нагрузками и хотим поделиться общим впечатлением.

Под катом рассказ про то, как у нас все устроено под капотом, а также плюсы и минусы работы с Keycloak, которые мы подметили за последние два года.

Что такое поток мультимедиа? Обычно это потоковое аудио или видео.

Существует множество источников таких данных:

 — Веб‑камеры, сетевые ip‑камеры
 — Звонки из call‑центров (записываются и анализируются!)
 — Стримы игр на ютуб
 — и т. д.

Все мы знаем, как трудно управлять современными приложениями, которые состоят из микросервисов со сложным взаимодействием между ними. Причём управлять одними только микросервисами будет недостаточно, нужен комплексный подход.

В этой статье мы под разными углами рассмотрим управление сервисами и узнаем, как решать эти задачи с помощью service mesh, Istio, eBPF и RSocket Broker.

Всем привет. Меня зовут Нина Пакшина, я разработчик “Лента Онлайн” и часть операционной команды в сервисе доставки продуктов.

В данной статье на примере языка Go я расскажу о том, как мы внедряли Kafka в связке с Schema Registry и Protobuf в качестве формата сообщений.

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

Всем привет. Меня зовут Женя, я работаю, как это сейчас модно говорить, DevOps-инженером в компании Garage Eight. 

В этой статье я бы хотел поделится опытом внедрения и эксплуатации брокера сообщений NATS в нашей инфраструктуре — настолько понравилась эта технология. 

Однажды перед нами встала задача максимально быстрой доставки сообщений из пункта A в пункт B. Условия были таковы:

* Перед тем как сообщение достигнет пункта назначения, оно проходит ряд сервисов;

* Каждый сервис выполняет определенный набор действий над этим сообщением;

* Скорость прохождения сообщений через весь путь должна быть минимальной;

* Брокер сообщений должен работать стабильно 24\7.

В статье я расскажу, как мы это делали

Есть такая интересная книга – «High Performance Browser Networking» Ильи Григорика, в которой описаны основы работы сетей и способы оптимизации передачи данных. В этой книге автор пишет про CDN следующее:

Сервисы по доставке контента (CDN) приносят много пользы, но основаны они на простом наблюдении, что, распределив контент по всему земному шару и доставляя его к пользователю из точки, которая как можно ближе к нему, можно значительно уменьшить время загрузки.

Если подумать, то наверное можно согласиться с тем фактом, что CDN улучшают UX, потому что ускоряют загрузку сайта. Но... минуточку. А как именно CDN это делает?

Вы можете сказать: «Ну, когда пользователь запрашивает файлы с CDN, они загружаются с ближайшего к пользователю сервера. Легко и просто». Да, но ведь эти данные загружаются всегда с одного домена. Как тогда запрос может приходить на разные сервера?

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

Привет, Хабр! Меня зовут Николай Суворов. Я – профессиональный менеджер, руководитель направления Delivery Management в МТС Digital. Занимаюсь Enablement Platform – единой платформой для быстрого создания продуктов в экосистеме МТС. Сегодня я расскажу о своем pet-проекте и о том, как я заменил привычный, но такой недоступный Evernote прекрасным менеджером заметок Obsidian. Статья будет интересна прежде всего тем, кто хочет обладать «вторым мозгом» и ни о чем не забывать.

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

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

Торговая система QUIK ^{_{[ссылка удалена мод.]}} для большинства серьёзных игроков рынка является очень популярной системой предоставления своим клиентам интерфейса для торговли ценными бумагами. Но в большинстве своём внутренности этой системы, как и любого коммерческого продукта являются закрытыми, в связи с чем могут возникать проблемы интеграции во внутреннюю инфраструктуру предприятия. В этой статье будут рассмотрены возможные механизмы интеграции QUIK в системы предприятия являющегося клиентом брокера или самостоятельным брокером.

Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".

Как какой из двух категорий относится эта статья — решать вам.

В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.

Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.

Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).

Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.

Моделирование базы данных в графовых БД существенно отличается от реляционных. В этой статье я расскажу о best practices, тонкостях и нюансах моделирования данных в Neo4j.

Привет, Хабр! Меня зовут Сергей, я руководитель команды поиска в Ozon. Сегодня я расскажу об эволюции наших поисковых систем: как всё начиналось более 20 лет назад с обычных SQL-запросов, как мы осваивали Sphinx и Elasticsearch и как сейчас наш собственный поисковый движок O2 на базе Apache Lucene выдерживает нагрузку в десятки тысяч RPS в сезон распродаж. Исторические хроники восстанавливались по воспоминаниям современников и представлены для полноты картины. Новейшая история описана на основе собственного опыта, поэтому подробностей будет на порядок больше. Поехали!

Инвесторов часто учат, дескать «ваши ценные бумаги надежно защищены, даже если с брокером что-то случится – они точно будут в безопасности!» На практике, правда, в России это справедливо далеко не всегда. В этой статье мы разбираемся, какими удивительными способами ушлые брокеры всё-таки могут лишить вас ваших денег.

Сами по себе логи, трейсы, метрики - это очень узкие артефакты состояния нашего объекта наблюдения и обслуживания. Для понимания общей картины нужен взгляд сверху, сбор всех важных сигналов в одну систему и работа с большими данными в ней. Зонтичный подход близок по своим целям к RED и Golden Signals, но по своей сути является противоположным по принципу работы с данными. В Golden Signals мы отслеживаем Latency, Traffic, Errors отдельных сервисов и по ним можем быстро, но очень поверхностно определить их состояние. В случае зонтичного мониторинга или AIOps мы собираем данные о всех логах, событиях систем мониторинга метрик и трейсов, далее выстраиваем там топологию сервиса и определяем алгоритмически состояние здоровья, основываясь на сотнях и тысячах событий, метрик и трейсов. И два подхода, кстати, друг друга не исключают. В этой статье я постараюсь сравнить четыре бесплатных инструмента, которые могли бы дать такую зонтичную картину: ELK, Graylog, Grafana Loki и Monq.

Уже три года, как мы постепенно передаем солюшн-архитектуру в команды разработки. Приходится часто объяснять, как сделать архитектурное решение коллегам, которые раньше подобными вещами не занимались. Отсюда родилась идея этой статьи – поделиться опытом, который сложился у меня и моих коллег за 10 лет практики. Важная часть этого опыта – шаблон архитектурного решения с пояснениями как его заполнять и почему именно так. По сути, шаблон - это структура необходимых знаний. Если вы нашли ответы на все вопросы шаблона, значит вы продуманно подошли к созданию архитектуры. А еще, сделали хороший документ, с которым удобно работать.

Статья расскажет, как правильно оформить ваши мысли, и что должно содержать качественное архитектурное решение. Статья не научит делать архитектуру.

Статья будет полезна:

• Аналитикам, тимлидам, программистам, которые уже делают или собираются делать архитектурные решения;

• Архитекторам, чтобы улучшить качество выпускаемых документов;

• Главным архитекторам с целью посмотреть «а как там у них».

Что мы подразумеваем под умственным развитием