DevOps
Хочу показать вам, как легко создавать своих торговых роботов для фондового рынка. Вы сможете протестировать ваши торговые стратегии на истории цен акций/фьючерсов, вам нужно только написать алгоритм принятия решений вашей стратегии на покупку или продажу актива — т.к. весь основной каркас робота уже написан. А добавив всего 4 строчки кода, ваша протестированная стратегия на истории сможет работать в live на реальном рынке, выставляя заявки на покупку и продажу в рынок.
После майского flash crash-а, обвалившего биткоин за сутки на 33%, а общий обвал котировки с ATH превысил 50%, цена консолидируется в диапазоне 30к$ - 41к$. Куда же будет выход после консолидации? Продолжится ли to the moon, или же это начало медвежьего рынка? Когда покупать, а когда продавать? Как именно фондовый рынок влияет на крипту? Что такое эра инстуционалов? Вниманию читателя предлагаю изучить данную статью, в которой есть ответы на все вышеуказанные вопросы.
Всем привет, меня зовут Константин. Я занимаюсь разработкой на Java в Tinkoff.ru и люблю SOLID. В этой статье мы сформулируем принцип подстановки Лисков, покажем его связь с принципом Открытости-Закрытости, узнаем, как правильно формировать иерархию наследования и ответим на философский вопрос о том, является ли квадрат прямоугольником.
Привет, Хабр!
Я потихоньку перевожу статьи Маркуса Винанда из блога use the index luke.
Первой статьей в цикле был манифест Маркуса о важности использования безофсетной пагинации на ключах. Мы рассмотрели всего один пример, как этот подход работает на практике. В этой и следующих статьях я буду обосновывать такой подход — с графиками и примерами, как все любят.
Привет, Хабр.
Недавно я поделился опытом о том, какие параметры мы в команде чаще всего используем для Kafka Producer и Consumer, чтобы приблизиться к гарантированной доставке. В этой статье хочу рассказать, как мы организовали повторную обработку события, полученного из Kafka, в результате временной недоступности внешней системы.
Современные приложения работают в очень сложной среде. Бизнес-логика, обернутая в современный технологический стек, работающая в Docker-образе, который управляется оркестратором вроде Kubernetes или OpenShift, и коммуницирующая с другими приложениями или enterprise-решениями через цепочку физических и виртуальных маршрутизаторов. В таком окружении всегда что-то может сломаться, поэтому повторная обработка событий в случае недоступности одной из внешних систем — важная часть наших бизнес-процессов.
Всем привет! Я бэкэнд-разработчик, пишу микросервисы на Java + Spring. Работаю в одной из команд разработки внутренних продуктов в компании Тинькофф.
У нас в команде часто встает вопрос оптимизации запросов в СУБД. Всегда хочется еще чуть-чуть быстрее, но не всегда можно обойтись продуманно выстроенными индексами — приходится искать какие-то обходные пути. Во время одного из таких скитаний по сети в поисках разумных оптимизаций при работе с БД я нашел бесконечно полезный блог Маркуса Винанда, автора книги SQL Performance Explained. Это тот самый редкий вид блогов, в котором можно читать все статьи подряд.
Хочу перевести для вас небольшую статью Маркуса. Ее можно назвать в какой-то степени манифестом, который стремится привлечь внимание к старой, но до сих пор актуальной проблеме производительности операции offset по стандарту SQL.
Привет!
В Angular CDK в седьмой версии появился виртуальный скролл.
Он отлично работает, когда размер каждого элемента одинаков, — причем прямо «из коробки». Мы просто задаем размер в пикселях и указываем, к какому элементу нужно прокрутить контейнер, сделать ли это плавно, а также можем подписаться на индекс текущего элемента. Однако что делать, если размер элементов меняется? Для этого в CDK предусмотрен интерфейс VirtualScrollStrategy, реализовав который мы научим скролл работать с нашим списком.
В моем случае требовалось сделать календарь для мобильного представления, который можно прокручивать непрерывно, а количество недель в месяце всегда разное. Попробуем разобраться, что представляет собой стратегия виртуального скролла и напишем свою.
Всем привет! Меня зовут Роман, и сегодня я поделюсь своим опытом работы в распределенной команде верстки. Расскажу о процессах, которые мы построили, и как команда из четырех человек покрывает потребности в верстке целого подразделения, состоящего из 30+ продуктов и 20+ продуктовых команд.
Еще расскажу о том, как:
Привет, Хабр!
Я работаю в команде Tinkoff, которая занимается разработкой собственного центра нотификаций. По большей части я разрабатываю на Java с использованием Spring boot и решаю разные технические проблемы, возникающие в проекте.
Большинство наших микросервисов асинхронно взаимодействуют друг с другом через брокер сообщений. Ранее в качестве брокера мы использовали IBM MQ, который перестал справляться с нагрузкой, но при этом обладал высокими гарантиями доставки.
В качестве замены нам предложили Apache Kafka, которая обладает высоким потенциалом масштабирования, но, к сожалению, требует практически индивидуального подхода к конфигурированию для разных сценариев. Кроме того, механизм at least once delivery, работающий в Kafka по умолчанию, не позволял поддерживать необходимый уровень консистентности из коробки. Далее я поделюсь нашим опытом конфигурации Kafka, в частности расскажу, как настроить и жить с exactly once delivery.
Генри Форд однажды сказал: «Лучшая машина — новая машина». Так и мы в группе компаний Тинькофф думаем про релизы софта. Инертность в процессе доставки фич и срочных фиксов рано или поздно приводит к большой технической задолженности перед заказчиком и чаще всего заканчивается стагнацией проекта в целом.
Гарантировать высокий показатель time to market, сохранив качество, — непростая задача. C моей точки зрения, нельзя сразу построить рельсы, по которым можно будет быстро и удобно доставлять изменения и спустя много месяцев после старта. Рост проекта обычно сопровождается ростом числа людей, работающих над ним, а значит, создает потенциальный источник хаоса внутри ваших релизов.
Наш опыт вряд ли стоит расценивать как инструкцию для достижения успеха, однако ряд идей показался мне достаточно интересным, чтобы поделиться с вами. Начнем.
